Так считайте что он уже удешевлен — приложение изначально под Андроид писалось, и именно в кардборде и тестировалось.
UPD> Насчет второго вопроса про задержку — сейчас около 0,1 секунды. Уменьшить можно только исключив вайфай и передавая картинку по проводам. Придется серьезно кодить, но в принципе реально. Нужно будет Raspberry соединить шнурком USB с телефоном и включить поддержку обмена данными.
Да, мне тоже потом народ говорил что надо было синхронно записывать картинку с камер и на видео ее в уголке показывать, чтобы были видны движения человека и то что он видит.
В данном случае картинка шла по WiFi, это добавляло задержку около 0,1 секунды. Можно сделать вариант с передачей по проводу, тогда задержки практически нет (сотые доли секунды).
Ну и камеру мы сознательно закрепили на спине, а не на голове сзади, хотя такой вариант рассматривали. Цель была избежать постоянных резких движений камеры, это добавляет дискомфорта в ощущения.
Ну в нашем случае персонаж и есть человек — компьютерной графики нет. Он просто видит себя со стороны. На видео я иногда снимал ноутбук, на котором шла трансляция того-же видео, что человек получал в Oculus Go. Оно дает представление о том, что видит игрок.
Да, знаем про похожие эксперименты. Это уже полноценный AR получается, у нас цель была просто лайвстрим получить. А вообще на алиэкспрессе по словам типа 3rd person view можно найти серийные крепления камер сзади-сверху для гопрошек и других смотрелок.
Да, вычисления на Пи сразу. Пока мы делали proof-of-concept на питоне, за скоростью не гонялись, получалось около 25 FPS при 640х480 и подкрученных настройках карты глубин (там много параметров). В планах прогнать всё на сишечке, с разными разрешениями. Вообще пиковый FPS захвата картинки до 90 fps (заявленный в официальных доках), неофициальный в аппаратных ветках малинового форума — до 120 fps (с соняшными сенсорами). Будем пробовать сделать так, чтобы расчет карты глубин успевал за камерой.
Ну если у Texas Instruments были две критичные ошибки в документации (обе четырехлетней давности на тот момент), то что говорить про китайцев :-)
Поэтому да, тот факт что оно работает из коробки, и практически на любой вопрос есть ответ — определяющий факторы.
Мультиплексор это «некрасивое» решение с кучей головной боли по аппаратной части (там закрытые бинарники по работе с камерой и нештатное использование I2C у малины при работе с видеочастью). А с новыми IMX219 еще и крипточип туда воткнут — броадком какие-то секреты свои бережёт. Учитывая, что мы сейчас будем «разгонять» карту глубин до теоретических 90FPS — мультиплексирование выглядит совсем тупиковой веткой. Если нужна третья камера — в крайнем случае её можно по USB зацепить (например, сделав PiZero с камерой дочерним устройством в режиме клиента через usbgadget).
Хороший вопрос. Как я упоминал, мы обычно затачиваем наши железки под решение своих задач. Нам нужна была компактная плата, с которой хорошо и удобно делать две вещи:
1. Комфортно отлаживаться. Поэтому у нас полноразмерные USB на борту, полноценный коннектор сетки и полноразмерный HDMI.
2. Удобно встраивать на борт в готовом решении. Поэтому плату сделали маленькой, и предусмотрели «слим» версию (я её показывал на видео) без больших разъемов и колодки GPIO, которые просто не паяются при производстве.
Касательно китайских GPIO — это клоны отладочной борды от самой Raspberry с вариациями на эту тему. Они очень удобны для прототипирования при разработке своего железа, но никак не годятся для наших целей. Они просто для других задач, с которыми кстати хорошо справляются.
Варианты с двумя распберри пробовались еще в эпоху первых малин. Идея интересная, особенно с малявками типа PiZero. Но, к сожалению, к моменту «сбора» двух картинок по сетке в одну стерео набирается гарантированный рассинхрон в несколько кадров — карта глубин рассыпается. А касательно цены — мы не Raspberry Foundation, тираж прикидывали небольшой. Будут миллионы устройств — будет копеечная цена. :-)
А это зависит от стереобазы (расстояния разнесения камер) и разрешения, с которым будете работать. Это конечно не миллиметры или сантиметры на расстоянии десятков метров, как, например, у лидаров типа Lidar Lite v3 HP, зато за один кадр вы сканируете сразу большой кусок пространства — до полусферы (при широкоугольных камерах).
Согласен, вопрос только в определении «серьезный процессинг». Джетсон штука очень злая, с малиной сравнивать нечестно :-) Ну и цена у самого джетсона (без кроватки и обвязки) примерно в 13 раз выше.
Для задач «изучить», «быстро спрототипировать» малина больше подходит. И получается хороший вариант пощупать технологии перед тем, как переходить на предложенную вами тяжелую артиллерию.
пы.сы.: Google умудрился на PiZero (с очень старым процом) запихнуть нейронку и распознавание образов, так что тут еще и вопрос оптимизации решения под платформу.
Я ниже ответил, что все виртурильные наработки перенесены на малину. Стерео у нас поддерживается «из коробки» — менять ничего не надо. Собственно мы уже летали и катались со стерео, еще с прошлой ревизией стереопи с первым компьют-модулем. На форуме для радиомоделистов я небольшой обзорчик делал.
upd> сейчас прикручиваем это всё к Oculus Go, но тут Gol подробнее рассказать может
Наработки все перенесены на другие платформы (чаще с малиной работаем), саму железку прошлую уже выпускать не будем — время идет, много нового появляется. Можно считать что stereopi это витртурилка 2.0
Ну как выпустим тираж — можно будет купить. Пока мы пытаемся понять интерес народа. Продвинутые товарищи разгадали квест в статье и смогли встать в очередь. :-)
Вообще мы железо обычно разрабатываем для своих задач, когда не можем найти на рынке готовое решение, подходящее под наши задачи. Если решение вызывает массовый интерес — уже организовываем тираж.
У нас немного иная логика — камеры малины родные, по шинам CSI-2 обе воткнуты напрямую в проц, поэтому всё шустро. Это не две отдельные камеры по USB или через платы видеозахвата. И, кстати, у обеих малиновых на лету синхронизируются настройки — балансы белого, яркость и прочие вещи. С независимыми камерами это большая проблема.
UPD> Насчет второго вопроса про задержку — сейчас около 0,1 секунды. Уменьшить можно только исключив вайфай и передавая картинку по проводам. Придется серьезно кодить, но в принципе реально. Нужно будет Raspberry соединить шнурком USB с телефоном и включить поддержку обмена данными.
В данном случае картинка шла по WiFi, это добавляло задержку около 0,1 секунды. Можно сделать вариант с передачей по проводу, тогда задержки практически нет (сотые доли секунды).
Ну и камеру мы сознательно закрепили на спине, а не на голове сзади, хотя такой вариант рассматривали. Цель была избежать постоянных резких движений камеры, это добавляет дискомфорта в ощущения.
Поэтому да, тот факт что оно работает из коробки, и практически на любой вопрос есть ответ — определяющий факторы.
1. Комфортно отлаживаться. Поэтому у нас полноразмерные USB на борту, полноценный коннектор сетки и полноразмерный HDMI.
2. Удобно встраивать на борт в готовом решении. Поэтому плату сделали маленькой, и предусмотрели «слим» версию (я её показывал на видео) без больших разъемов и колодки GPIO, которые просто не паяются при производстве.
Касательно китайских GPIO — это клоны отладочной борды от самой Raspberry с вариациями на эту тему. Они очень удобны для прототипирования при разработке своего железа, но никак не годятся для наших целей. Они просто для других задач, с которыми кстати хорошо справляются.
Для задач «изучить», «быстро спрототипировать» малина больше подходит. И получается хороший вариант пощупать технологии перед тем, как переходить на предложенную вами тяжелую артиллерию.
пы.сы.: Google умудрился на PiZero (с очень старым процом) запихнуть нейронку и распознавание образов, так что тут еще и вопрос оптимизации решения под платформу.
upd> сейчас прикручиваем это всё к Oculus Go, но тут Gol подробнее рассказать может
Вообще мы железо обычно разрабатываем для своих задач, когда не можем найти на рынке готовое решение, подходящее под наши задачи. Если решение вызывает массовый интерес — уже организовываем тираж.