Ну так каждая дыра в дорожном покрытии дает прекрасно-видимый артефакт в получаемых данных. Будут своеобразными ключевыми точками на карте дорожных подземелий.
Более того, можно будет решать обратную задачу — оценивать качество дороги по данным.
— Дорогой, УЗИ дороги показало что у нас будет асфальтоукладчик!
Можно было бы пролистать страницу результатов гугл-поиска чуть дальше. Такие конфигурации как у вас тоже вполне обыденная ситуация для Hand-Eye Calibration.
Что-ж, я не ругаю за афинное преобразование (подумаешь, 12 степеней свободы, когда их должно быть только 6 :). Если оно позволяет решать ваши задачи — это прекрасно. Пусть и не совсем правильно с точки зрения физики. Просто ваше утверждение об универсальности вашего подхода для всех роботов и камер слишком уж… хм… наивно.
Кстати говоря, вы не пробовали добавить и/или удалить одно-два измерения и пересчитать матрицу? Далеко убегает решение? В пределах обозначенной точности хотя бы?
Кстати на счет точности. Один пиксел может и дает большую ошибку, но когда будете фиттить какую-либо поверхность, тот же шар к примеру, точность может многократно возрасти за счет усреднения ошибок.
В вашем же случае вы решаете крайне нелинейную и сложную задачу по поиску трансформа (6 DoF) используя только точечные изменения (3 DoF). Я думаю что и аффинное преобразование вы используете только потому что не смогли найти настоящий трансформ удовлетворительного качества. Короче читайте, дерзайте и у вас все получится.
В свое время я сумел скалибровать промышленный робот с repeatability accuracy меньше миллиметра и absolute accuracy около пяти. Но там ошибки всей связки подсчитывалось: ошибки самого робота + ошибки hand2eye + ошибки tool calibration.
Кстати вопрос как измерять погрешности для роботов сам по себе является не тривиальным. И просто так на глаз утверждать точность не представляется возможным
Упс… случайно кнопку нажал…
Раз уж вы используете 3д камеру, то я бы на вашем месте сразу использовал объект у которого можно найти 3D Pose напрямую. Например кирпич известных размеров.
Робот, тоже ( в теории) должен выдавать 3D Pose для гриппера/руки. Пусть даже если меняться будут только 4 степени свободы. Таким образом можно получить пары соответствующих поз/трансформов для камеры и руки, и уже классическими методами найти решение. Там будет задача вида AX=XB, которая не очень то линейная, но решить можно.
То что вы проделали называется 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 со своими печками, да здраствует цифровой коммунизм! Долой органические мозги! Вся власть роботам и киборгам!
Более того, можно будет решать обратную задачу — оценивать качество дороги по данным.
— Дорогой, УЗИ дороги показало что у нас будет асфальтоукладчик!
Что-ж, я не ругаю за афинное преобразование (подумаешь, 12 степеней свободы, когда их должно быть только 6 :). Если оно позволяет решать ваши задачи — это прекрасно. Пусть и не совсем правильно с точки зрения физики. Просто ваше утверждение об универсальности вашего подхода для всех роботов и камер слишком уж… хм… наивно.
Кстати говоря, вы не пробовали добавить и/или удалить одно-два измерения и пересчитать матрицу? Далеко убегает решение? В пределах обозначенной точности хотя бы?
Кстати на счет точности. Один пиксел может и дает большую ошибку, но когда будете фиттить какую-либо поверхность, тот же шар к примеру, точность может многократно возрасти за счет усреднения ошибок.
В вашем же случае вы решаете крайне нелинейную и сложную задачу по поиску трансформа (6 DoF) используя только точечные изменения (3 DoF). Я думаю что и аффинное преобразование вы используете только потому что не смогли найти настоящий трансформ удовлетворительного качества. Короче читайте, дерзайте и у вас все получится.
В свое время я сумел скалибровать промышленный робот с repeatability accuracy меньше миллиметра и absolute accuracy около пяти. Но там ошибки всей связки подсчитывалось: ошибки самого робота + ошибки hand2eye + ошибки tool calibration.
Кстати вопрос как измерять погрешности для роботов сам по себе является не тривиальным. И просто так на глаз утверждать точность не представляется возможным
Упс… случайно кнопку нажал…
Раз уж вы используете 3д камеру, то я бы на вашем месте сразу использовал объект у которого можно найти 3D Pose напрямую. Например кирпич известных размеров.
Робот, тоже ( в теории) должен выдавать 3D Pose для гриппера/руки. Пусть даже если меняться будут только 4 степени свободы. Таким образом можно получить пары соответствующих поз/трансформов для камеры и руки, и уже классическими методами найти решение. Там будет задача вида AX=XB, которая не очень то линейная, но решить можно.
То что вы проделали называется 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 на более низкое разрешение, вплоть до бинарного сигнала.
И даже тогда оно работает не хуже чем текущие решения :)
как оно работает?
К сожалению не могу проверить это в Питоне, но если кто захочет заимплементить — с удовольствием гляну/подскажу
Но что если вам нужен какой-нибудь необычный диапазон, например ультрафиолет или рентген. Какая тут оптика или где взять мегапиксельный сенсор — не подскажете?