Но в этом ведь и суть патентной системы - дать возможность заработать и "поделиться" с нужными людьми - теми же "экспертами" в суде. Законы вовсе не направлены на поддержку технического развития, а судьи - не могут выступать в роли экспертов по технологиям.
Но это не пассивный, а активный трекинг. Устройство ведь само посылает свои координаты! И Android может сам отслеживать положение телефона ребенка, если его аккаунт связан с вашим.
100-200 нм - это не 386-е, это уже 4-е пентиумы с гигагерцами. И их, на самом-то деле вполне достаточно для выполнения большинства. Нужна многоядерность и софт, который на всякие "всплывалки-финтифлюшки" не будет отжирать гигантскую часть производительности. Но все так радостно побежали изучать Python, потому что "модно-молодежно", вместо того, чтобы грызть Assembler и C, что надежды на хороший исход весьма немного.
Я бы сказал, что "слава богу, что был Itanium". Это был масштабный научный эксперимент и теперь у всех есть детальное понимание того, что делать не нужно. Ну почти у всех. Intel пробует разное, существуя в логике первопроходца, когда не ясно, куда нужно идти. В AMD, напротив, до сих пор мыслят как "догоняющие" - важно только быстродействие, важно догнать и обогнать.
У Tesla есть и Roadster, и Tesla Model S Plaid+ - этого более чем достаточно. Плэд идет воровень с трековой версией Porshe 911 Turbo S на Нюрбургринге. Вполне-себе трековый автомобиль.
Есть ли информация от какой-нибудь из команд, освещающая особенности именно их решения? На уровне хотя бы публикаций, которые делали команды "Робокросса"?
Накладные расходы (конструктивные) на регистровые файлы намного меньше, чем на конвейеризацию. Это прямо - бинго в плане размена, на что тратить логические ячейки. Однако "обычные" процессоры давным давно изобрели кэш третьего уровня, работающий на частоте ядра. Меня вот смущает реализация многопоточности. Одно дело, когда компилятор собирает код единственного потока - тут можно оптимизировать сколько угодно. И регистровый файл тут в масть. Но совсем другое дело - жонглирование большим количеством потоков. Явно, что переключаться туда-сюда нельзя будет, поскольку одно дело, хранить для каждого потока один указатель на вершину его собственного стека, и совсем другое - где-то брать уникальную копию регистрового файла в самом железе процессора. Ведь нет никакой гарантии, что к моменту переключения потоков (завершения кванта, выделенного потоку) стек будет хотя бы приблизительно в том же месте, где при входе в этот самый квант.
Ну они (эти 8704 ядра) не совсем параллельны как бы. Особенности архитектуры CUDA как раз в том, что это как раз вычисления (расчеты), а не работа АЛУ в чистом виде. Алгоритмы биткоина действительно нацелены на "прямые" вычисления. Но есть ведь и другие криптовалюты.
У вас же коллекторный электромотор, какое ещё векторное управление? И задумайтесь лучше о двигателе без редуктора. Одно дело - крутить колесо велосипеда с постоянной скорость, а другое - испытывать постоянные толчки при "танковом" управлении. В вашем случае даже может не BLDC нужен, а чистопородный асинхронник.
И ни одна из команд не попробовала погуглить, как на самом деле решаются подобные задачи в беспилотных автомобилях (или хотя бы в мобильной робототехнике)…
Был запрещено?
Хотя бы банальное исправление сферичности изображения и последующая проекция на плоскость пола изображения с камеры решала бы уйму проблем команд
«Вот эта улица 100500 лет назад выглядела так» в большинстве вариантов — всё же не AR, а VR проект, поскольку подразумевает полную виртуальную реконструкцию всего вида (видимой сцены). И не важно, что при этом не используется VR-шлем для визуализации.
AR — это именно дополнение части сцены. Например, «вот тут стоял памятник, посмотрите, каким он был».
В основном проблема музеев (помимо отсутствия средств) в том, что разработчики VR пытаются перенести опыт «игровой» индустрии, цепляясь за логику наличия VR-шлема.
Нужны какие-то иные идеи в реализации «музейных» проектов.
Эта задача на использование виртуальных датчиков линии. FPS будет близко к быстродействию камеры. Поэтому вы сможете разогнаться до любой разумной для вашей машинки скорости.
Если сильно упрощенно, то проводите несколько горизонтальных линий и ищите на них «пики» яркости. Это и есть ваши линии разметки. Дальше думаете как их объединять в логике движения. Если они стоят «в линию», то стараетесь удержать середину между разметками, если уходят вправо или влево, то активируете режим поворота.
Ну заявлена установка десктопных дистрибутивов, даже Windows 10. А поскольку зоопарка по вариантам железа не предвидится, то и особой поддержки и не нужно.
Примерно за те же деньги можно попробовать Rock Pi X или LattePanda примерно в том же форм-факторе и работать с полноценной операционной системой для x86. И при этом сохранится возможность экспериментировать с GPIO, если возникнет желание.
И важное дополнение — встроенный SSD у LattePanda — это уже совсем другой взгляд на проблему применения микрокомпьютера именно как полноценного десктопа.
Но в этом ведь и суть патентной системы - дать возможность заработать и "поделиться" с нужными людьми - теми же "экспертами" в суде. Законы вовсе не направлены на поддержку технического развития, а судьи - не могут выступать в роли экспертов по технологиям.
Но это не пассивный, а активный трекинг. Устройство ведь само посылает свои координаты!
И Android может сам отслеживать положение телефона ребенка, если его аккаунт связан с вашим.
100-200 нм - это не 386-е, это уже 4-е пентиумы с гигагерцами.
И их, на самом-то деле вполне достаточно для выполнения большинства.
Нужна многоядерность и софт, который на всякие "всплывалки-финтифлюшки" не будет отжирать гигантскую часть производительности.
Но все так радостно побежали изучать Python, потому что "модно-молодежно", вместо того, чтобы грызть Assembler и C, что надежды на хороший исход весьма немного.
Здравствуй сила Кориолиса, помноженная на Теорию относительности... Давно мы о тебе не слышали.
Я бы сказал, что "слава богу, что был Itanium". Это был масштабный научный эксперимент и теперь у всех есть детальное понимание того, что делать не нужно. Ну почти у всех.
Intel пробует разное, существуя в логике первопроходца, когда не ясно, куда нужно идти. В AMD, напротив, до сих пор мыслят как "догоняющие" - важно только быстродействие, важно догнать и обогнать.
У Tesla есть и Roadster, и Tesla Model S Plaid+ - этого более чем достаточно. Плэд идет воровень с трековой версией Porshe 911 Turbo S на Нюрбургринге. Вполне-себе трековый автомобиль.
Есть ли информация от какой-нибудь из команд, освещающая особенности именно их решения? На уровне хотя бы публикаций, которые делали команды "Робокросса"?
Накладные расходы (конструктивные) на регистровые файлы намного меньше, чем на конвейеризацию. Это прямо - бинго в плане размена, на что тратить логические ячейки. Однако "обычные" процессоры давным давно изобрели кэш третьего уровня, работающий на частоте ядра.
Меня вот смущает реализация многопоточности. Одно дело, когда компилятор собирает код единственного потока - тут можно оптимизировать сколько угодно. И регистровый файл тут в масть.
Но совсем другое дело - жонглирование большим количеством потоков. Явно, что переключаться туда-сюда нельзя будет, поскольку одно дело, хранить для каждого потока один указатель на вершину его собственного стека, и совсем другое - где-то брать уникальную копию регистрового файла в самом железе процессора.
Ведь нет никакой гарантии, что к моменту переключения потоков (завершения кванта, выделенного потоку) стек будет хотя бы приблизительно в том же месте, где при входе в этот самый квант.
Ну они (эти 8704 ядра) не совсем параллельны как бы. Особенности архитектуры CUDA как раз в том, что это как раз вычисления (расчеты), а не работа АЛУ в чистом виде.
Алгоритмы биткоина действительно нацелены на "прямые" вычисления. Но есть ведь и другие криптовалюты.
У вас же коллекторный электромотор, какое ещё векторное управление?
И задумайтесь лучше о двигателе без редуктора. Одно дело - крутить колесо велосипеда с постоянной скорость, а другое - испытывать постоянные толчки при "танковом" управлении.
В вашем случае даже может не BLDC нужен, а чистопородный асинхронник.
Был запрещено?
Хотя бы банальное исправление сферичности изображения и последующая проекция на плоскость пола изображения с камеры решала бы уйму проблем команд
AR — это именно дополнение части сцены. Например, «вот тут стоял памятник, посмотрите, каким он был».
В основном проблема музеев (помимо отсутствия средств) в том, что разработчики VR пытаются перенести опыт «игровой» индустрии, цепляясь за логику наличия VR-шлема.
Нужны какие-то иные идеи в реализации «музейных» проектов.
Всё что показано — это уже довольно сильно обработанные данные
Если сильно упрощенно, то проводите несколько горизонтальных линий и ищите на них «пики» яркости. Это и есть ваши линии разметки. Дальше думаете как их объединять в логике движения. Если они стоят «в линию», то стараетесь удержать середину между разметками, если уходят вправо или влево, то активируете режим поворота.
И важное дополнение — встроенный SSD у LattePanda — это уже совсем другой взгляд на проблему применения микрокомпьютера именно как полноценного десктопа.