Comments 21
В статью специально не стал вставлять, но моим первым роботом было вот это чудо, строил все самостоятельно, шасси от сломанной детской радиоуправляемой игрушки:
Солнечные панели, AI и на Марс
1. Пожалуйста проверьте орфографию.
2. Текст ни о чём.
2. Текст ни о чём.
1. поправил.
2. не завидуйте :)
2. не завидуйте :)
2. Действительно ни о чём!
Краткое содержание статьи:
Делал то не зная для чего, а потом понял, что лучшее исход сего действия продать, что самому не пригодилось. Покупатель понял, что тоже погорячился с покупкой и тоже продал от греха подальше. Новый покупатель решил понять, что же за чудо попалось ему в руки и решил обратиться к авторскому замыслу.
А, автор понял, что делал это чтобы опубликовать статью на хабр.
Профит! :)
P.S. STM32, например, не рассматривали как замену Ардуин подходу?
Краткое содержание статьи:
Делал то не зная для чего, а потом понял, что лучшее исход сего действия продать, что самому не пригодилось. Покупатель понял, что тоже погорячился с покупкой и тоже продал от греха подальше. Новый покупатель решил понять, что же за чудо попалось ему в руки и решил обратиться к авторскому замыслу.
А, автор понял, что делал это чтобы опубликовать статью на хабр.
Профит! :)
P.S. STM32, например, не рассматривали как замену Ардуин подходу?
"Гелиевые" аккумуляторы?
Почему зачастую роботостроители стараются делать свои машины полностью автономными?
Как минимум электронную начинку нужно выносить наружу, тогда для управления хватит телефона и простой платы с драйверами на ардуино (полностью эффективной сетевую коммуникацию делать самостоятельно сложно, пусть этим телефон занимается) или что-нибудь на основе роутера, ведь тогда компьютер для распознования изображения и многих других вещей может быть снаружи и питаться от того же автомобильного аккумулятора или от розетки в доме. Это сильно развязывает руки и дает больше питания двигателям.
Как минимум электронную начинку нужно выносить наружу, тогда для управления хватит телефона и простой платы с драйверами на ардуино (полностью эффективной сетевую коммуникацию делать самостоятельно сложно, пусть этим телефон занимается) или что-нибудь на основе роутера, ведь тогда компьютер для распознования изображения и многих других вещей может быть снаружи и питаться от того же автомобильного аккумулятора или от розетки в доме. Это сильно развязывает руки и дает больше питания двигателям.
А нет вариантов для доступных каналов связи для подобных систем. Там нужен какой-никакой реал-тайм, да еще и довольно развитые и не шибко медленные протоколы. Bluetooth просто медленный и на малом расстоянии только, у wifi латентность прыгает в больших пределах, а из протоколов есть только ROS, который, прямо скажем, сильно перегружен и крайне неоптимален во многих местах.
Так вы не тики драйверов передавайте с мегагерцовыми частотами, где фазовый или частотный сдвиг определяет на какой угол повернуть сервомотор, а логическое задание на следующие сотни миллисекунд или даже секунду, чтобы потеря связи на это время не создавала проблем.
На практике нет необходимости роботу (а обычно это тележка максимум с манипулятором, и то это уже скачок на пару уровней вперед) реагировать так быстро, обычно это проехать очередной отрезок в несколько сантиметров. Внешнее управление позволит разместить внешние же измерители координат, а точнее их уточнение, а локальные пусть работают от менее точных акселемометров и гироскопов, но в пределах секунды накопленная ошибка будет достаточно низкой.
Как я уже сказал, очень многое уже есть в дешевых и очень легких смартфонах, достаточно прикрутить по usb плату управления двигателями и вынести более сложную логику 'в облако'
На практике нет необходимости роботу (а обычно это тележка максимум с манипулятором, и то это уже скачок на пару уровней вперед) реагировать так быстро, обычно это проехать очередной отрезок в несколько сантиметров. Внешнее управление позволит разместить внешние же измерители координат, а точнее их уточнение, а локальные пусть работают от менее точных акселемометров и гироскопов, но в пределах секунды накопленная ошибка будет достаточно низкой.
Как я уже сказал, очень многое уже есть в дешевых и очень легких смартфонах, достаточно прикрутить по usb плату управления двигателями и вынести более сложную логику 'в облако'
Ну, вот берем IMU — нужно данные компаса/акселерометра/гироскопа передавать модулю навигации несколько десятков (а лучше сотен) раз в секунду. Коррекция PWM моторов — тоже минимум 10-50 раз в секунду. А это, в общем-то, почти 90% от всех задач езды. Так и получаем, что либо локально все обрабатываем и считаем (да еще придумываем свой протокол для выдачи команд), либо нужен поток с гарантированным временем доставки и протокол соответствующий, что гораздо сложнее. Возьмите тот же ROS, где все пытаются считать «удаленно» — сложность во многих местах просто зашкаливает, спасает только то что благодаря открытости — многое уже в готовом виде есть.
Я не говорю про готовые реализации, я не очень понимаю зачем нужно заниматься простым роботостроением если все брать готовое, я думал ради 'написать что то свое' этим и занимаются.
Надо быть очень странным, чтобы передавать по беспровоной сети сырой поток с датчиков на роботе, обрабатывать их на сервере и гнать назад управление с такой же частотой. Естественно лаги и разрывы связи будут сказываться.
На робота нужно передавать высокоуровневые задания, например — не дольше 3 секунд ехать до этих координат (а после до тех), если нет координат — остановиться… а робот на основе датчиков, пытается определить свои координаты и положение и тупо двигает по вектору в сторону цели (алгоритм чуть посложнее, чтобы исключить биения вокруг точки), с этим справится слабый процессор смартфона.
То же самое для манипуляторов, вы передаете, например, последовательность векторов углов для сервомоторов с ограничениями (время, возможно ответы от датчиков, например концевики и прочее) а локально процессор последовательно исполняет эти векторы углов для всех указанных сервомоторов одновременно.
Таким образом по сети передаются команды не чаще раз в секунды! но чтобы уменьшить ошибку определения координат, можно передавать постоянно коррекцию ото вешних измерительных приборов (например определение положения по внешним видеокамерам), частота переданных данных определит минимальную ошибку, но если случится потеря или задержка пакета, особой проблемы это не создаст.
Надо быть очень странным, чтобы передавать по беспровоной сети сырой поток с датчиков на роботе, обрабатывать их на сервере и гнать назад управление с такой же частотой. Естественно лаги и разрывы связи будут сказываться.
На робота нужно передавать высокоуровневые задания, например — не дольше 3 секунд ехать до этих координат (а после до тех), если нет координат — остановиться… а робот на основе датчиков, пытается определить свои координаты и положение и тупо двигает по вектору в сторону цели (алгоритм чуть посложнее, чтобы исключить биения вокруг точки), с этим справится слабый процессор смартфона.
То же самое для манипуляторов, вы передаете, например, последовательность векторов углов для сервомоторов с ограничениями (время, возможно ответы от датчиков, например концевики и прочее) а локально процессор последовательно исполняет эти векторы углов для всех указанных сервомоторов одновременно.
Таким образом по сети передаются команды не чаще раз в секунды! но чтобы уменьшить ошибку определения координат, можно передавать постоянно коррекцию ото вешних измерительных приборов (например определение положения по внешним видеокамерам), частота переданных данных определит минимальную ошибку, но если случится потеря или задержка пакета, особой проблемы это не создаст.
Ха. Выяснить текущие координаты робота — это вообще 99.5% от всего процесса. Помимо того, что большинство простых самоделок этого просто не умеют (нечем физически обычно), чтобы их посчитать — как раз и нужно все обрабатывать на роботе, так как даже просто видеопоток от камер по wifi прогнать с приемлимой задержкой (хотя бы не больше 100-200 мс) — это серьезная проблема.
А вы не ставьте камеру на робота ;) это худшее место для этой задачи, ее сильно трясет, малый обзор и сложность анализа.
Координаты и положение.
Расставьте камеры в помещении, чтобы они покрывали всю область, в идеале по две камеры на каждую точку. Например это qr-код на спинке робота и 3-4 отражателя выставленных в углах куба (для точного определения угла поворота) и внешние камеры, после калибровки можно вычислять координаты с точностью меньше сантиметра, и не важно что лаг будет до секунды, у каждой координаты будет временная метка, передаете их поток на робота, где на их основе корректируется вычисление координат на основе акселемометра и гироскопа.
Координаты и положение.
Расставьте камеры в помещении, чтобы они покрывали всю область, в идеале по две камеры на каждую точку. Например это qr-код на спинке робота и 3-4 отражателя выставленных в углах куба (для точного определения угла поворота) и внешние камеры, после калибровки можно вычислять координаты с точностью меньше сантиметра, и не важно что лаг будет до секунды, у каждой координаты будет временная метка, передаете их поток на робота, где на их основе корректируется вычисление координат на основе акселемометра и гироскопа.
почему вы не используете мотор колеса от гироскутера? Получается же компактней, за счет что мотор уже в колесе (стоят 900р, или купить убитый гироскутер.)
Мда… ни я один с ума схожу. Мне кажется это какая то болезнь… синдром ДаВинчи… все пацаны хотят своего робота, своего маааленького терминатора )
Жесткий у тебя НАНОбот, с пропорциями метр на метр
Я думал, что я один такими глупостями занимался в молодости :)
А потом он подъедет и скажет — «Мне нужна твоя одежда и твой мотоцикл»…
Здравствуйте, скажите, а как вы заряжали аккумулятор? Был ли контроль разряда, ведь батарейки этого типа боятся глубокого разряда, был ли контроль напряжения в вэб интерфейсе?
Sign up to leave a comment.
Возвращение блудного сына