roboforum.ru

К тому же Kinect XBox не рассчитан на разглядывания близких предметов.
forum68/topic13936.html?hilit=kinect#p297516

AndreiSk писал(а):хм, а зачем брать этот вид кинекта. Продается же для ПК второй кинект, стандартный USB3 и питанием. У меня такой стоит, ничего паять не пришлось.

Насколько мне известно, Майкрософт уже довольно давно перестала выпускать вторые кинекты для ПК. Теперь они продают специальный адаптер с блоком питания за 50 зеленых. С учетом доставки в наш регион не знаю из какого далека, т.к. ничего поблизости я не нашел, это выходит в некоторую лишнюю для меня сумму и время. Я посчитал, что быстрее и дешевле взять в соседнем магазине стандартный Кинект. Но при этом потребовалась некоторая его доработка.

Добавлено спустя 12 минут 36 секунд:

Scorpio писал(а):К тому же Kinect XBox не рассчитан на разглядывания близких предметов.
forum68/topic13936.html?hilit=kinect#p297516

Это справедливо для первого кинекта. Второй прекрасно работает с расстояния 50 см.

Да, Вы правы. http://www.3dnews.ru/912092 Перестали выпускать Kinect v2 for windows.
Ну значит я успел прикупить. Хотя написано что есть что-то взамен. Но раз у вас получилось припаяться,
то по идее все нормуль. Единственно что огорчает - здоровая штука этот кинект

AndreiSk, Intel RealSense. http://iq.intel.co.uk/drone-delivery-services-with-realsense-3d-cameras/

В силу обстоятельств мне пришлось подойти к созданию моего робота немного с другой стороны. В декабре 2015 и начале января 2016 года я занимался и продолжаю заниматься аватарной технологией. Основные элементы у меня уже работают, но предстоит их соединить вместе. В результате эта подсистема должна будет состоять из двух частей.
Первая - это робоголова с камерой. Предполагается ее поворот по трем осям с помощью сервоприводов.
Вторая - пользовательский модуль, основной частью которого будут очки виртуальной реальности с отслеживанием положения головы человека.
Работать это должно просто: в какую сторону пользователь повернул голову, туда должна немедленно повернуться робоголова. При этом должна обеспечиваться бесперебойная передача потокового видео с минимально возможными задержками. Робоголова может быть основной на роботе, либо дополнительной, наблюдательной, не мешающей роботу выполнять свои автономные функции.
Вот такой макет робоголовы я начал делать сегодня вечером.
На фото виден бортовой компьютер Raspberry PI 2, USB хаб, WiFi свисток для беспроводной связи. Еще я добавлю литиевую батарею и преобразователи напряжения до 5 в. Камера пока обычная USB Logitech C270. Позже планирую заменить ее на родную камеру Raspberry PI, т. к. она работает быстрее благодаря отдельной параллельной шине.
Такая система обеспечивает потоковое видео 30 к/с в H. 264 по сети с очень маленькой нагрузкой на процессор благодаря использованию GPU.
В качестве клиентского процессора также выбран Raspberry PI. К нему я подключил платку гироскопа-акселерометра GY-521. Правда, в ней нет компаса. Но учитывая его большую шумность, надеюсь, что смогу обойтись без него. Нужно лишь будет почаще калиброваться.
Еще я подключил к клиентскому компьютеру 7 дюймовый экран. Макет очков я еще не начал делать, но на столе основные составные части работают.

Вот результат моих трудов:
С виду все простенько, но потребовалось много усилий, чтобы заставить все это работать. В макете желательно заменить камеру на родную Raspberry PI, т. к. через USB сейчас подключена и видеокамера и сеть. Здесь самое узкое место в макете камеры. Частично поэтому при высоком разрешении изображения не всегда передается нужное количество кадров. Есть и еще кое-что, над чем нужно потрудиться. Но это уже дело дальнейшей разработки.
Видео озвучивает программный синтезатор речи.

Круто! Узнаю, ставший уже родным, голос акапеловской Алёны . Вроде есть небольшая, но заметная, задержка по видео? Использовать вместо шлема смартфон не проще?

Scorpio писал(а):Круто! Узнаю, ставший уже родным, голос акапеловской Алёны .

Да,это голос Алены.

Scorpio писал(а): Вроде есть небольшая, но заметная, задержка по видео?

Задержка имеется. Самая заметная проблема - это несовершенство механической поворотной части подвеса камеры. В данном макете подвес не прорабатывался и в случае дальнейшей разработки этот узел может быть значительно улучшен.
Но главное - задержка зависит от времени компрессии в камере, передачи по USB к компьютер макета камеры, времени расжатия там отдельных кадров, нового сжатия в H264, передачи по WiFi а затем по обычной локальной сети в макет шлема. И от разжатия потокового видео там. Вот такая цепочка передачи видео по цифровому каналу связи. Если передавать 640х480 а тем более 320х200 то задержка существенно меньше ввиду значительного уменьшения потока данных и как следствие - более быстрой обработки каждого кадра. Поэтому то я и хочу убрать первые несколько этапов из этой цепочки заменой типа камеры. Тем самым уменьшатся задержки во всей системе. Можно даже попробовать переработать макет камеры на FPGA, только придется столкнуться с аппаратной компрессией H264.

Scorpio писал(а):Использовать вместо шлема смартфон не проще?

Я со смартфона и начал разработку. Но там возникли разные технические проблемы включая разношерстность в точности сенсоров и постоянно мешающаяся Java.

Вчера мне удалось сделать стековый Soft - процессор J1 http://www.excamera.com/sphinx/fpga-j1.html внутри FPGA и запустить простую тестовую программу - при нажатии кнопки гасить светодиод на отладочной плате.
Попытаюсь продвнуться в сторону аппаратноаго AI путем реализации в FPGA моей Мегатронной сети.

Вот только сейчас удалось в терминале через UART получить взаимодействие с интерпретатором Форта в процессоре J1. Что-то я сильно устал от бодания с фортовским кодом. Все прошедшее время - более двух месяцев, боролся с ошибками и моим непониманием прототипа. Нужно еще много чего поправить, но что-то уже дышит и живет.
Пока имеются вот такие слова:
init quit blink. s does> evaluate refill accept char ' postpone literal abort chars char+ r@ r> >r depth io@ @ nip over drop dup swap u< < = invert or and xor
+ hex decimal unloop j i +loop loop? do leave do recurse does> until again then begin if ahead; exit: noname: [ ] immediate sliteral s, compile, c, allot parse parse-name \ source 2! 2@ cmove> cmove fill >number sfind align um/mod m* *um* d2* d0= m+ s>d dabs dnegate d+ aligned /string here abs words forth tth >in state base type bounds count c! c@ max min 2over 2swap +! 2dup ?dup 2drop tuck -rot rot true false execute. x. x2 bl cr space emit key key? leds io! ! u> 0> 0< > 0<> <> cells cell+ 0= 1- 2/ 2* - negate 1+

С этим процессором я теперь могу двигаться дальше и реализовать захват видео с камерного модуля и вывод контрольного изображения на HDMI монитор. И все это силами всего одной микросхемы. Таких процессоров в этой FPGA можно разместить несколько.

Все последние три месяца я продолжал работать над моим автономным роботом. Полностью отладил работу FPGA с камерой OV7670. Пришлось переписать драйвер из Linux на Forth. Очень потрепала нервы отладка всяких временных диаграмм.
Несколько дней назад я взялся за 3G модем SIM5360E. У меня имеется отладочная плата SIM5360E-EVM. Кроме беспроводного интернета с ее помощью можно получить GPS/ГЛОНАСС навигацию. Начал стыковать этот модуль с моим FPGA проектом.

Это все конечно замечательно, но вот смотрю я что очень долго... с 2000 года длится?
Есть одна китайская очень мудрая пословица:
"результат без качества - скучен, а качество без результата - глупо".
Важно найти баланс - золотую середину во всем чего вы касаетесь, а иначе и одной жизни человеческой не хватит... и зачем оно тогда все это?

1 сентября я полностью завершил разработку и испытания программно-аппаратного стенда, в котором изображение с камеры поступает в FPGA, а оттуда в 3G модем, из которого по UDP протоколу через интернет пересылается на сервер где-то в Голландии. На этом сервере работает моя эхо-программа, посылающая назад все поступившие к ней UDP пакеты. Этот же имеющийся у меня 3G модем принимает пакеты, передает их обратно в FPGA. В свою очередь внутри FPGA все пришедшие из интернета UDP пакеты преобразуются в видеоданные и направляются через HDMI порт на монитор, на котором я наблюдаю с некоторой задержкой то, что поступает в камеру.
Испытания показали вполне предсказуемые результаты:
1. Видеоданные нужно очень и очень хорошо сжимать перед пересылкой через интернет-канал.
2. Суммарные задержки транспортировки видеосигнала могут достигать критических зачений, не позволяющих сделать комфортную систему телеприсутствия наподобие той, макет которой я приводил выше на видео в данной теме.
Однако в качестве беспроводного средства общения с помощью высокоуровневых команд с автономным роботом разработанная система очень даже годится.

Сейчас только ленивый не занимается беспилотными автомобилями. То, чем я занимаюсь сейчас, можно отнести к этому же роду занятий. Если удастся создать автономного передвигающегося робота, то впоследствии, установив на него манипуляторы, можно получить робокентавра и продолжить работы с манипулятором. Про двуногих роботов можно на время забыть, т. к. это очень непростая задача - сделать в домашних условиях робота, обладающего способностью ходить как человек, а не как механическая кукла. Да это мне пока и не требуется.
Разработкой автономного транспортного средства (АТС) я занялся в начале сентября. Первой задачей я для себя поставил создание простейшего экспериментального движущегося робота для разработки его "мозгов". Поэтому на внешний облик, механическую составляющую проекта на данном этапе буду обращать мало внимания.
В качестве основы я взял гусеничное шасси от игрушки - вездехода, который валялся без дела у меня около 20 лет:
Отдельно я сначала на большом компьютере, а затем и на микрокомпьютере Raspberry Pi3 установил операционную систему для роботов ROS.
Сложным оказался процесс установки требуемых программных пакетов в Raspberry. В настоящее время у меня заработала распределенная система, состоящая из 3D сканера пространства Kinect XBox360, микрокомпьютера Raspberry Pi3 с ROS и стационарного компьютера, на который также установлен ROS. Компьютеры объединены по локальной сети в единое целое и позволяют запускать под ROS систему навигации RTABMap. В 3D окне на экране большого компьютера теперь видно, как, вращая и перемещая Kinect, который подключен к Raspberry Pi3, строится объемная карта всего того, что видит Kinect, а также видна траектория движения самого Kinect в этом пространстве.
Теперь нужно к Raspberry Pi подключить другие сенсоры, а также двигатели гусеничного шасси. И только после этого можно будет все соединять воедино на мобильной платформе.

Платформа с виду не большая. Kinect потянет?