Спасибо! А у меня и есть НИИ. Только ооооочень небольшой :) И пусть всё это я, но в команде "у нас": разработчик софта и 3D моделей; инвестор, директор, менеджер по всему, видеоредактор, диктор, надеюсь популяризатор роботостроения! Вернулся из недельного отпуска. Теперь продолжу собирать следующий этап робота. Хочу сменить два задних мотор-колеса на одно подруливающее. И провести повторные тесты движения по газону и тропинкам вокруг дома. Нужно закончить тестирование готового этапа задачи "следи за персоной, подходи к ней" - th-cam.com/video/hjU896aZHzI/w-d-xo.html и переходить к следующему! Планов очень много.
Выглядит интересно и много обещающе, так держать. Сам тоже увлекаюсь робототехникой и детей привлекаю. Сейчас в основном балуюсь с Lego Spike. Хочу прикрутить к нему OpenMV, хочу понять на сколько он будет крут для навигации. Несколько соображений: 1) На мой взгляд такой большой робот на ранних стадиях испытания, может быть неудобным, что то поменьше было бы предпочтительней для прототипирования, т.к. в ходе испытания он может куда то погнать и что то поломать в доме) Было бы логично начать с чего то меньшего и уже обкатанное склонировать на вариант побольше 2) По камере - судя по видео она прям очень посредственная. Сильные засветы при контр свете, экспозиция плохая. Хоть картинка и ужимается в 640 на 480, на маой взгляд это даже больший повод взять камеру получше, т.к. нейронке может быть сложно работать с таким изображением, вы же ей скармливаете свой дата сет снятый наболее менее приличный фотоаппарат/телефон, по факту расхождения еще сильней из за качества камеры. 3) УЗ датчики очень не точны, погрешности, игнорируют многие материалы, лучше поменять на лазерные дальномеры, недорогие, а так же прикрутить лидар. В общем это просто мысли, к чему я скорее всего приду со временем) Подписался, буду следить)
Привет! По камере: Это б/у Intel RealSense D435. Это т.н. камера глубины. Или RGBD камера. То есть кроме RGB она даёт канал того же разрешения с 16 бит (0...65535) значениями. Где 0 = очень близко и 65535 = очень далеко (в реале чуть не так, но упростим теорию для начального понимания). Это не обработка RGB снимка. Это отдельный поток, в моём случае 640x480 на 6 кадров в секунду (может глубину гнать до HD@30, но мне столько не нужно). Этот массив 640х480 int16 значений моя python нода Safety обрабатывает так: - уменьшает разрешение; - убирает мёртвые зоны (особенности этой камеры, с поиском глубины по стереопаре); - строит маску значений до 50 см; - отбрасывает мелкие пятна (
По безопасности: О да! Я отлично понимаю, что первое, чему учат начинающего горнолыжника - это торможение падением :) То есть как прекратить неконтроллируемое движение. Поэтому у меня уже пяток мер безопасности и уже запланированы ещё три. С кучей ограничений и предохранителей. Пока что в роли Большой Красной Кнопки рубильник на морде бота, да многочисленные проверки в коде. Будет ещё и связь с пультом через LoRa и BT связь с мобилой.
По УЗ. Согласен с тобой полностью. Поэтому я почти не задействую их в логике контроллера. Их данные, если они обнаружили препятствие на расстоянии до полуметра, используются модулем безопасности - любое движение сразу останавливается до устранения тревоги. Но не они определяют саму программу. Лишь помогают ей. Камера глубины - это считай тот же лидар, только не круговой и бьёт на ограниченное расстояние. Приличный лидар денег стоит, а за 2 тыщи от Xiaomi пылесоса на улице слепнет. Однако, его тоже буду пробовать, когда закончатся мои идеи. Я больше налегаю на YOLO и распознавание объектов, да самописную картографию на основе триангуляции по найденным ориентирам на участке. Впрочем, это пока только планы. Сегодня собрал прототип слежения за персоной. Сейчас залью видео по ссылке, покажу.
Вот сегодняшнее. Из неопубликованного (доступно по ссылке) th-cam.com/video/hjU896aZHzI/w-d-xo.html Погода будет нормальная, начну настраивать ПИДы на улице. Досниму и оформлю в новый ролик.
@@olegmilantievВыглядит круто, я такое же планирую на OpenMV как доедет сделать. Еще думаю было бы бы неплохо поставить фронтальную камеру на платформочку с двумя сервами по XY и удерживать человека в кадре, это должно помочь. Плюс сделать режим поиска, если объект только что пропал из поля зрения, сделать попытку восстановить покрутив немного камерой.
Очень круто! Вы молодец я тоже в процессе создания похожего робота но в качестве мозгов использую старый ноутбук, в качестве драйвера выступает ардуино с точки зрения энергоэффективности все плохо но с точки зрения удобства лучшее что можно придумать, + не нужно тратиться на на малинки и т.д!
@@olegmilantiev да действительно можно но хочется без лишних трат, тем более когда дома в виде хлама валяется пара ноубуков с убитым корпусом но вполне рабочие, вы в качестве драйвера используете платы от гироскутора с foc прошивкой? я использую цепочку ноут -> ардуино -> плата гироскутера -> колеса, на ноуте стоит pycharm с питоном, пробывал уйти от arduino с помощью uart usb переходника но плата гироскутера по какой то причине отказывается принимать сигнал от него!
Интересный проект. Хотел поинтересоваться - чем обусловлено управление драйверами моторов через отдельные ардуинки? Не проще ли было реализовать управление внешними драйверами моторов через порты GPIO на плате Orange Pi ?
Спасибо за хороший вопрос. Отдельные арду (а скоро переход на STM32) в проекте нужны для реалтайм ПИД управления с высокой частотой по точному энкодеру. Используемый мною debian / Ubuntu Linux не реалтайм система и не гарантирует миллисекундные тайминги. Да и в STM32, как я недавно узнал, есть встроенная железная поддержка энкодеров.
Спасибо за ответ. Если нужна точность перемещений, может стоит рассмотреть шаговые двигатели? - никаких энкодеров, наличие недорогих моторов и драйверов готовых на рынке, управление через порты GPIO. По-моему проще конструкция/схематика/кол-во кода будет.
@@constantinch.1193 Да, схема с шаговиками хорошая. У меня знакомый большим шаговиком крутит не то что колесо, но целый купол обсерватории. Через редуктор, конечно. Однако, в этом решении (пока что) цена заметно отличается. Если делать робота в серию с нуля, однозначно, не подойдут б/у колёса от гироскутера и может стоит глянуть в сторону каких-то серв / шаговиков / гибридных шаго-серв. Но цена неминуемо вырастет.
Вопрос в том, для чего нужна высокая точность передвижений? Если говорить о перемещениях по площадям в гектары и расстояния в километрах, то вполне можно движки постоянного тока с редукторами без всяких энкодеров, передвижение по координатам GPS/GLONASS, для этого использовать систему Ardupilot(Pixhawk etc.) а вместо батареек прикрутить бензогенератор :)
@@constantinch.1193 Не точность, но плавность передвижения. Изнчаально в этом моторе 15 полюсов и три датчика Холла. На подъёме и спаде импульсов трёх датчиков можно было бы получить 90 тиков на оборот. К сожалению, используемый мною контроллер снимал данные только с одного датчика Холла. То есть 15/30 тиков на оборот. Этого, плюс 10 Гц коррекции ПИД-регулятора, оказалось недостаточно для плавного движения. Бот дёргался, как не настраивай коэффициенты регулятора. Тогда я сильно увеличил и частоту коррекции (до 1..2 кГц), и разрешение энкодера (до 4 тыщ импульсов на круг). Это, судя по всему (ещё не успел проверить) даст равномерную скорость движения при наличии внешних возмущений (что-то попало под колесо, сменился уклон, колесо спущено и т.п.).
Очень интересно и увлекательно смотреть ваше видео!❤🎉😊 Вам в НИИ работать нужно с такими знаниями!)😃👍 Подписалась!💥🤩
Спасибо!
А у меня и есть НИИ. Только ооооочень небольшой :) И пусть всё это я, но в команде "у нас": разработчик софта и 3D моделей; инвестор, директор, менеджер по всему, видеоредактор, диктор, надеюсь популяризатор роботостроения!
Вернулся из недельного отпуска. Теперь продолжу собирать следующий этап робота. Хочу сменить два задних мотор-колеса на одно подруливающее. И провести повторные тесты движения по газону и тропинкам вокруг дома. Нужно закончить тестирование готового этапа задачи "следи за персоной, подходи к ней" - th-cam.com/video/hjU896aZHzI/w-d-xo.html и переходить к следующему! Планов очень много.
@@olegmilantiev Отлично, восхитительные у вас знания🤩 Конечно будем смотреть всей семьёй продолжение!💯😃👍
Очень круто, но сложновато немного))
Выглядит интересно и много обещающе, так держать. Сам тоже увлекаюсь робототехникой и детей привлекаю. Сейчас в основном балуюсь с Lego Spike. Хочу прикрутить к нему OpenMV, хочу понять на сколько он будет крут для навигации. Несколько соображений:
1) На мой взгляд такой большой робот на ранних стадиях испытания, может быть неудобным, что то поменьше было бы предпочтительней для прототипирования, т.к. в ходе испытания он может куда то погнать и что то поломать в доме) Было бы логично начать с чего то меньшего и уже обкатанное склонировать на вариант побольше
2) По камере - судя по видео она прям очень посредственная. Сильные засветы при контр свете, экспозиция плохая. Хоть картинка и ужимается в 640 на 480, на маой взгляд это даже больший повод взять камеру получше, т.к. нейронке может быть сложно работать с таким изображением, вы же ей скармливаете свой дата сет снятый наболее менее приличный фотоаппарат/телефон, по факту расхождения еще сильней из за качества камеры.
3) УЗ датчики очень не точны, погрешности, игнорируют многие материалы, лучше поменять на лазерные дальномеры, недорогие, а так же прикрутить лидар.
В общем это просто мысли, к чему я скорее всего приду со временем)
Подписался, буду следить)
Привет!
По камере:
Это б/у Intel RealSense D435. Это т.н. камера глубины. Или RGBD камера.
То есть кроме RGB она даёт канал того же разрешения с 16 бит (0...65535) значениями. Где 0 = очень близко и 65535 = очень далеко (в реале чуть не так, но упростим теорию для начального понимания). Это не обработка RGB снимка. Это отдельный поток, в моём случае 640x480 на 6 кадров в секунду (может глубину гнать до HD@30, но мне столько не нужно).
Этот массив 640х480 int16 значений моя python нода Safety обрабатывает так:
- уменьшает разрешение;
- убирает мёртвые зоны (особенности этой камеры, с поиском глубины по стереопаре);
- строит маску значений до 50 см;
- отбрасывает мелкие пятна (
По безопасности:
О да! Я отлично понимаю, что первое, чему учат начинающего горнолыжника - это торможение падением :) То есть как прекратить неконтроллируемое движение.
Поэтому у меня уже пяток мер безопасности и уже запланированы ещё три. С кучей ограничений и предохранителей. Пока что в роли Большой Красной Кнопки рубильник на морде бота, да многочисленные проверки в коде. Будет ещё и связь с пультом через LoRa и BT связь с мобилой.
По УЗ. Согласен с тобой полностью. Поэтому я почти не задействую их в логике контроллера. Их данные, если они обнаружили препятствие на расстоянии до полуметра, используются модулем безопасности - любое движение сразу останавливается до устранения тревоги. Но не они определяют саму программу. Лишь помогают ей.
Камера глубины - это считай тот же лидар, только не круговой и бьёт на ограниченное расстояние. Приличный лидар денег стоит, а за 2 тыщи от Xiaomi пылесоса на улице слепнет. Однако, его тоже буду пробовать, когда закончатся мои идеи.
Я больше налегаю на YOLO и распознавание объектов, да самописную картографию на основе триангуляции по найденным ориентирам на участке. Впрочем, это пока только планы.
Сегодня собрал прототип слежения за персоной. Сейчас залью видео по ссылке, покажу.
Вот сегодняшнее. Из неопубликованного (доступно по ссылке)
th-cam.com/video/hjU896aZHzI/w-d-xo.html
Погода будет нормальная, начну настраивать ПИДы на улице. Досниму и оформлю в новый ролик.
@@olegmilantievВыглядит круто, я такое же планирую на OpenMV как доедет сделать. Еще думаю было бы бы неплохо поставить фронтальную камеру на платформочку с двумя сервами по XY и удерживать человека в кадре, это должно помочь. Плюс сделать режим поиска, если объект только что пропал из поля зрения, сделать попытку восстановить покрутив немного камерой.
Очень круто! Вы молодец я тоже в процессе создания похожего робота но в качестве мозгов использую старый ноутбук, в качестве драйвера выступает ардуино с точки зрения энергоэффективности все плохо но с точки зрения удобства лучшее что можно придумать, + не нужно тратиться на на малинки и т.д!
Ноуты бывают достаточно малопотребляющие. Можно попробовать в сторону ARM ноутов глянуть для этого.
От ардуины я отхожу в сторону blue pill (stm32)
@@olegmilantiev да действительно можно но хочется без лишних трат, тем более когда дома в виде хлама валяется пара ноубуков с убитым корпусом но вполне рабочие, вы в качестве драйвера используете платы от гироскутора с foc прошивкой? я использую цепочку ноут -> ардуино -> плата гироскутера -> колеса, на ноуте стоит pycharm с питоном, пробывал уйти от arduino с помощью uart usb переходника но плата гироскутера по какой то причине отказывается принимать сигнал от него!
Вот это мозгоделка!!!! Предлагаю Добавить фотки лис, Зайцев, Орлов, куропаток, Курей, лошадей и « соседа- психа».
🤣
😂
Интересный проект. Хотел поинтересоваться - чем обусловлено управление драйверами моторов через отдельные ардуинки? Не проще ли было реализовать управление внешними драйверами моторов через порты GPIO на плате Orange Pi ?
Спасибо за хороший вопрос.
Отдельные арду (а скоро переход на STM32) в проекте нужны для реалтайм ПИД управления с высокой частотой по точному энкодеру.
Используемый мною debian / Ubuntu Linux не реалтайм система и не гарантирует миллисекундные тайминги.
Да и в STM32, как я недавно узнал, есть встроенная железная поддержка энкодеров.
Спасибо за ответ. Если нужна точность перемещений, может стоит рассмотреть шаговые двигатели? - никаких энкодеров, наличие недорогих моторов и драйверов готовых на рынке, управление через порты GPIO. По-моему проще конструкция/схематика/кол-во кода будет.
@@constantinch.1193 Да, схема с шаговиками хорошая. У меня знакомый большим шаговиком крутит не то что колесо, но целый купол обсерватории. Через редуктор, конечно. Однако, в этом решении (пока что) цена заметно отличается. Если делать робота в серию с нуля, однозначно, не подойдут б/у колёса от гироскутера и может стоит глянуть в сторону каких-то серв / шаговиков / гибридных шаго-серв. Но цена неминуемо вырастет.
Вопрос в том, для чего нужна высокая точность передвижений? Если говорить о перемещениях по площадям в гектары и расстояния в километрах, то вполне можно движки постоянного тока с редукторами без всяких энкодеров, передвижение по координатам GPS/GLONASS, для этого использовать систему Ardupilot(Pixhawk etc.) а вместо батареек прикрутить бензогенератор :)
@@constantinch.1193 Не точность, но плавность передвижения. Изнчаально в этом моторе 15 полюсов и три датчика Холла. На подъёме и спаде импульсов трёх датчиков можно было бы получить 90 тиков на оборот. К сожалению, используемый мною контроллер снимал данные только с одного датчика Холла. То есть 15/30 тиков на оборот. Этого, плюс 10 Гц коррекции ПИД-регулятора, оказалось недостаточно для плавного движения. Бот дёргался, как не настраивай коэффициенты регулятора.
Тогда я сильно увеличил и частоту коррекции (до 1..2 кГц), и разрешение энкодера (до 4 тыщ импульсов на круг). Это, судя по всему (ещё не успел проверить) даст равномерную скорость движения при наличии внешних возмущений (что-то попало под колесо, сменился уклон, колесо спущено и т.п.).
Следующая часть - th-cam.com/video/rZEGWZdr8zA/w-d-xo.html