То что вы проделали называется Hand-to-eye calibration. Существует множество способов его сделать, и ваш кажется не очень то уж и точный.
Можно использовать какой-нибудь объект, в котором легко посч
Один профессор, на лекции которого я имел честь присутствовать, рассказал отличный принцип как отличать ML от AI: если система принимает сложные решения без участия человека, то это AI. Если просто предсказывает/классифицирует, но при этом не делает ничего рискованного, то это ML.
Это помогает хоть как-то различать эти два термина, которые иначе размазаны маркетологами.
В данном случае я бы лично хотел чтобы последнее слово всегда оставалось за врачем. Т.е. чтоб описанная система была бы ML, которая помогает врачу принять правильное решение.
Хотя кто знает, может лет через 10, когда доказательная медицина докажет что нейросеть лечит лучше чем обычный врач, то может я и доверю свое здоровье такому ИИ. А ренгенологи станут младшим медицинским персоналом ))))
Вам нужно определиться какая конечная (или промежуточная) цель вашего проекта.
Если вы просто хотите изучать робототехнику, то все можно делать в ROS и в симуляторах — там можно достигнуть результатов гораздо быстрее.
В ROS вообще зачастую писать ничего не надо — просто конфигурировать существующие модули. Launch файлы и urdf (кинематика робота) написаны в XML.
Но при этом надо понимать что и как вы используете — т.е. нужны знания, и, соответственно, будете обучаться.
Код можно писать в Python, что особенно хорошо для новичков. Если не хватает производительности, можно всегда перейти на C/C++.
Теперь о вашем проекте. Если предположить, что у вас уже есть карта пространства (2D) то SLAM (Localiztion & Mapping) вам не нужен, а нужен только Localization.
В таком случае, можно использовать обычный Monte Carlo Localization / Particle Filter. И обычные ультра-звуковые сенсоры, смонтированные на роботе, (а не ваша супер-система) могут вам помочь гораздо больше.
Идея MCL в том, что если у вас 4 сенсора со всех сторон и они показывают какие-то значения, то на карте всего-лишь одна или несколько областей соответствует таким измерениям. (предпологается что на карте есть множественные стены/коридоры). MCL кидает множество рандомных точек с произвольной ориентацией (всевозможные позы робота) на карту и сверяет предсказанные измерения датчиков с существующими. Те позы, что дают минимальные ошибки запоминаются и используются на следующей итерации. Если робот двигается, и вы с помощью одометрии знаете как именно, то это значит что изменения в измерениях тоже можно предугадать. И если все правильно, то MCL сходтится к верному решению в течении нескольких фреймов/итераций.
По поводу вопроса о Raspberry: наверное стоит оставить Arduino как real-time контроллер, а на Raspberry крутить ROS, чтобы он локализацию считал, Калманы, одометрию и тому подобное.
В том то и дело что только одним IMU не получится восстановить траекторию. Это как раз из-за постоянного дрифта у IMU сенсора. Гуглите IMU Dead Reconing. Шаговый двигатель это не тоже что я имею ввиду. Для одометрии энкодер нужен на пассивном колесе (или лучше двух), а не на моторе.
Но, команды, поданные на шаговый двигатель — уже что то.
Короче, как я понимаю у вас есть: (1) самодельный сенсор на ультразвуке, (2) не очень хорошая odometry из комманд к устройству/роботу, (3) 6-DoF IMU сенсор (теоретически).
Этого уже вполне достаточно чтобы сделать fusion с помощью Kalman Filter, и уже тогда получить хорошую траекторию движения.
Дрифт все-равно останется, но будет гораздо меньше.
1-я проблема — Arduino это ни о чем. Нужен хотя бы Raspberry Pi, или что то подобное.
2: Используйте ROS, там эти проблемы уже решены. Статьи по ROS есть даже на хабре, но лучше конечно читать в оригинале.
3. Если у вас будут Raspberry Pi + ROS, то ультра-звуковые сенсоры уже можно использовать для построения карты проходимости вокруг робота. https://www.youtube.com/watch?v=eSeLW9Hkjhc
Вот тут как раз энкодеры + лидар… Уже что-то можно сделать… Мда, наверно я погорячился с ультра-звуковыми :-))
SLAM вам правильно подсказали. И Kalman filter может подойти. Особенно, если у вас есть odometry хоть какая. Пусть даже команды поданные роботу — уже odometry. Wheel encoder конечно лучше будет, ну или хотя бы imu sensor. Короче читайте, изучайте, тут много математики, но все решается.
Просто охренительно, вместо бинарного сигнала можно отсылать что-нибудь вроде QR кодов, которые несут во много раз больше информации. Как тебе такое, Котельников?
А решить проблему температурного/физического сдвига можно с помощью постоянной динамической калибрации. Передатчик раз в секунду/минуту отсылает зараннее извесные калибровочные изображения, а приемник соответственно каждый раз дообучается. Ну а в остальное время передаются полезные данные.
Если что не так, fallback на более низкое разрешение, вплоть до бинарного сигнала.
И даже тогда оно работает не хуже чем текущие решения :)
На мой взгляд градиентный спуск тут излишен, и более того, если перемудрить то он может сойтись куда-нибудь в локальный минимум. Задача (если я правильно понял) — линейная, так что если у вас уже есть матрица связности графа (квадратная), то PCA (Principal Component Analysis) решает именно то что вам надо. Находим Eigen вектора (mean-subtracted) матрицы связности, выбираем 3 вектора с максимальным Eigen значением, которые собственно и будут соответствовать искомым координатам в 3Д пространстве.
К сожалению не могу проверить это в Питоне, но если кто захочет заимплементить — с удовольствием гляну/подскажу
Для крутящихся Velodyne-подобных лидаров это не проблема. Очень маловероятно что один лидар засветит пучком света прямо в другой такой-же лидар. Если и случится, то в данных второго лидара может появиться одна ошибочная точка, что не повлияет ни на что. Для лидаров с модуляцией (кстати это уже не лидары, а Time-of-Flight камеры), для них — да, могут начаться проблемы.
Для видимого диапазона световых волн никуда не денется.
Но что если вам нужен какой-нибудь необычный диапазон, например ультрафиолет или рентген. Какая тут оптика или где взять мегапиксельный сенсор — не подскажете?
Если бы совместить такие гибридные компьютеры с мемристорами (не знаю научились ли их делать на кремнии или еще нет), то такая бы бомба была!!! Все эти модные Deep Neural Networks можно будет запускать в аналоге, а не в цифре. Это вапще будет вынос мозга, супер-скоростной вынос. Прощай Nvidea со своими печками, да здраствует цифровой коммунизм! Долой органические мозги! Вся власть роботам и киборгам!
Куча китаёзов и других организаци выпускают свои говно-шлемы. А у вас есть супер квалификация и опыт по поддержке современного API для таких поделок. Я имею ввиду ваш Oculus Rift compatibility. Вы сидите на золотой жиле, китаезы очень плохи в написании софта, так что ваша competence будет очень востребована у них.
Про Виолу-Джонс что-то не вспомнили совсем. Чтоб вам сразу не воспользоваться альфа-маттингом? Получили 62 точки, гарантированно на морде лица, по-бокам бэкраунд — и вперед, альфаматить. Современные методы вытворяют чудеса www.alphamatting.com
У меня старые игры из стима не работают на Windows 8.1. Чтоб не быть голословным эти:
Call of Duty (самая первая) и Call of Duty 2. Чего я только не вытворял с настройками совместимости и драйверами видеокарт, ничего не помогает.
Может ли так случиться что из-за лучшей совместимостью с XP они когда нибудь пойдут на ReactOS?
То что вы проделали называется Hand-to-eye calibration. Существует множество способов его сделать, и ваш кажется не очень то уж и точный.
Можно использовать какой-нибудь объект, в котором легко посч
Это помогает хоть как-то различать эти два термина, которые иначе размазаны маркетологами.
В данном случае я бы лично хотел чтобы последнее слово всегда оставалось за врачем. Т.е. чтоб описанная система была бы ML, которая помогает врачу принять правильное решение.
Хотя кто знает, может лет через 10, когда доказательная медицина докажет что нейросеть лечит лучше чем обычный врач, то может я и доверю свое здоровье такому ИИ. А ренгенологи станут младшим медицинским персоналом ))))
Если вы просто хотите изучать робототехнику, то все можно делать в ROS и в симуляторах — там можно достигнуть результатов гораздо быстрее.
В ROS вообще зачастую писать ничего не надо — просто конфигурировать существующие модули. Launch файлы и urdf (кинематика робота) написаны в XML.
Но при этом надо понимать что и как вы используете — т.е. нужны знания, и, соответственно, будете обучаться.
Код можно писать в Python, что особенно хорошо для новичков. Если не хватает производительности, можно всегда перейти на C/C++.
Теперь о вашем проекте. Если предположить, что у вас уже есть карта пространства (2D) то SLAM (Localiztion & Mapping) вам не нужен, а нужен только Localization.
В таком случае, можно использовать обычный Monte Carlo Localization / Particle Filter. И обычные ультра-звуковые сенсоры, смонтированные на роботе, (а не ваша супер-система) могут вам помочь гораздо больше.
Идея MCL в том, что если у вас 4 сенсора со всех сторон и они показывают какие-то значения, то на карте всего-лишь одна или несколько областей соответствует таким измерениям. (предпологается что на карте есть множественные стены/коридоры). MCL кидает множество рандомных точек с произвольной ориентацией (всевозможные позы робота) на карту и сверяет предсказанные измерения датчиков с существующими. Те позы, что дают минимальные ошибки запоминаются и используются на следующей итерации. Если робот двигается, и вы с помощью одометрии знаете как именно, то это значит что изменения в измерениях тоже можно предугадать. И если все правильно, то MCL сходтится к верному решению в течении нескольких фреймов/итераций.
По поводу вопроса о Raspberry: наверное стоит оставить Arduino как real-time контроллер, а на Raspberry крутить ROS, чтобы он локализацию считал, Калманы, одометрию и тому подобное.
Но, команды, поданные на шаговый двигатель — уже что то.
Короче, как я понимаю у вас есть: (1) самодельный сенсор на ультразвуке, (2) не очень хорошая odometry из комманд к устройству/роботу, (3) 6-DoF IMU сенсор (теоретически).
Этого уже вполне достаточно чтобы сделать fusion с помощью Kalman Filter, и уже тогда получить хорошую траекторию движения.
Дрифт все-равно останется, но будет гораздо меньше.
1-я проблема — Arduino это ни о чем. Нужен хотя бы Raspberry Pi, или что то подобное.
2: Используйте ROS, там эти проблемы уже решены. Статьи по ROS есть даже на хабре, но лучше конечно читать в оригинале.
3. Если у вас будут Raspberry Pi + ROS, то ультра-звуковые сенсоры уже можно использовать для построения карты проходимости вокруг робота.
https://www.youtube.com/watch?v=eSeLW9Hkjhc
Вот тут как раз энкодеры + лидар… Уже что-то можно сделать… Мда, наверно я погорячился с ультра-звуковыми :-))
SLAM вам правильно подсказали. И Kalman filter может подойти. Особенно, если у вас есть odometry хоть какая. Пусть даже команды поданные роботу — уже odometry. Wheel encoder конечно лучше будет, ну или хотя бы imu sensor. Короче читайте, изучайте, тут много математики, но все решается.
А решить проблему температурного/физического сдвига можно с помощью постоянной динамической калибрации. Передатчик раз в секунду/минуту отсылает зараннее извесные калибровочные изображения, а приемник соответственно каждый раз дообучается. Ну а в остальное время передаются полезные данные.
Если что не так, fallback на более низкое разрешение, вплоть до бинарного сигнала.
И даже тогда оно работает не хуже чем текущие решения :)
как оно работает?
К сожалению не могу проверить это в Питоне, но если кто захочет заимплементить — с удовольствием гляну/подскажу
Но что если вам нужен какой-нибудь необычный диапазон, например ультрафиолет или рентген. Какая тут оптика или где взять мегапиксельный сенсор — не подскажете?
Call of Duty (самая первая) и Call of Duty 2. Чего я только не вытворял с настройками совместимости и драйверами видеокарт, ничего не помогает.
Может ли так случиться что из-за лучшей совместимостью с XP они когда нибудь пойдут на ReactOS?