[Разработка робототехники, Разработка под Arduino, Робототехника, DIY или Сделай сам] Народная платформа для роботов на ROS
Автор
Сообщение
news_bot ®
Стаж: 6 лет 4 месяца
Сообщений: 27286
Статья написана для только входящих в сам ROS и имеющих необходимость в постройке реального робота для обучения или выполнения реальных задач.
Приступая к изучению ROS обычно сразу хочется работать с физическими платформами, а не с моделями в симуляторе. На самом деле для изучения просто алгоритмов движения или просто обучению самому ROS достаточно и Gazebo, но работа с реальной платформой сразу дает возможность на практике понять все проблемы с колесным движением. Ну и часто платформа нужна просто как обязательное условие проекта.
На будущее — лучше начинать с круглого, т.к. по очевидным причинам разворот у такой конфигурации возможен вокруг оси без учета размера выпирающей части. Прямоугольник для разворота гораздо менее удобен, например в узких коридорах — иногда становится необходимо разворачиваться 3 и более приемов, автомобилисты думаю поймут.
Покупка готовых платформ
На рынке не так много готовых платформ, их список приведен на сайте ROS.
При этом стоимость их в России достаточно высока для начала работ, самый дешевый вариант это Turtlebot Burger 3 — 549 долларов. У реселлеров непосредственно в России мы нашли за сумму около 90000 т.р.
В Китае можно купить за 45-50 т.р… В любом случае, это будут платформы малого размера и грузоподъемности, не способные выполнять реальные задачи.
Платформу можно собрать самому платформу, тут есть масса разных гайдов и конфигураций. Но в среднем получается что-то вроде:
- Лидар класса Slamtech A1-А2
- Дешевые колеса на базе коллекторных двигателей с редукторами
- Управление драйверами на базе разных пакетов, которые обычно включают связку PWM управления с управляющего компьютера, либо через Ардуино с управлением через UART порт + rosserial.
- Single Board Computer — Raspberry, Jetson Nano
- 2 колеса
- связка gmapping + amcl/rosbot_ekf + move_base
Коллекторные двигатели нам не понравились потому что шумные, имеют высокое потребление и необходим редуктор. Тут надо сказать, что рассматриваются платформы достаточно тяжелые — т.е. сблокированные редукторы + двигатели что-то вроде двигателя с фото не подойдут.
Соответственно, как движители были выбраны BLDC мотор-колеса. Самый доступный на текущий момент вариант — это гироскутерные колеса 6.5. Осталось только ими управлять из ROS.
Но тут всплыла одна проблема: еще при работе с гольф роботами была замечена существенная проблема с поворотом такой платформы на низкой скорости — робот достаточно дерганно разворачивался.
Причины такого поведения просты: в развороте существенную роль сопротивлению движения работают силы трения скольжения. А у них есть особенность — сопротивление зависит от массы и характера самих поверхностей — именно поэтому маленький болтик первыми 2-3 витками держит большие конструкции.
Поэтому делать колеса узкими в центре становится чтобы он разворачивался достаточно бессмысленно — сопротивление изменится очень мало. Колесо из резины трется о траву и грунт, которые совсем не ровные и сила может резко меняться, в итоге было сделано что-то вроде коробки передач — на малой скорости контролируем момент на колесе, а при прямом движении — саму скорость.
Извините, данный ресурс не поддреживается. :(
Казалось бы при движению по паркету или линолеуму ситуация должна быть лучше, но увы коэффициент трения почти такой же(вспомним, что противоскользящая обувь делается тоже из резины).
И в итоге робот весом в 10-15 килограмм уже начинает разворачиваться с ощутимыми рывками.
Вторую часть проблемы добавляет пакет ROS diff_drive в сочетании с достаточно слабыми SBC платами.
Вот список того, что удалось понять
Управление ведется с использованием real-time реализации, но никак не учитывается, что прочие пакеты должны ожидать данный подход при работе с управлением.
Тут надо вспомнить, что real-time не мгновенная реакция на событие, а гарантия того, что обработка события пройдет в гарантированные интервалы физического времени. Т.е. условная ГЭС, регулируемая каждую минуту (обязательно каждую) — это тоже real-time система.
Появляется шанс того, что сообщениями будут забиты топики планировщика маршрута, а для подсистем позиционирования и планирования маршрута подобное поведение обычно приводит либо к останову и рестарту обработки потока, либо к попыткам отрегулировать на ходу процесс.
В итоге на слабых SBC возникает ситуация с беспрерывным пересчетом пути, либо поиск локализации отъедает достаточно большое процессорное время — и чем больше делается попыток успеть за RT компонентой — тем больше накапливается разбег по времени. В чистом виде положительная обратная связь, которая в данном случае совсем не нужна.
Дополнительно к этому gmapping при резких изменениях положения платформы и слабом лидаре тоже начинает работать совсем не быстро — наблюдались паузы до полсекунды, что тоже сильно озадачивает планировщик маршрута.
Управление двигателями идет раздельно, поэтому при использовании SBC и наивной реализации драйверов колеса будут управляться с некоторой задержкой.
Тут проблема еще проще — нам нужно управлять 2-4 колесами через канал связи, который. Соответственно, сигналы управления выстраиваются в очередь и начинают передаваться друг за другом — левое колесо, правое колесо, левое колесо, правое колесо.
В итоге сами колеса, а хуже того — и положения колес с энкодеров начинают вносить свою лепту в образование ПОС между планированием пути и управлением моторами
Встроенная одометрия реализована весьма упрощенно
Как мы не искали простого способа синхронизировать подачу команды и отдачу одометрии — не нашелся. Синхронизация всегда связана с ожиданием каких-то команд на входе, а они не регулярны во времени и в итоге одометрия начинает задерживаться на выходе. Возможно читатели подскажут простой способ — тут мы не считаем себя гуру в ROS.
Добиться того, чтобы подобная сборка вела себя хорошо, нам не удалось. Точнее удалось занизив ускорения перемещения до 0,05-0,1 м/c^2 и угловой скорости до 0,03 рад/с.
Подумалось что хорошо бы иметь :
- Дешевая платформа
- Синхронное управление колесами
- Расчет одометрии с учетом поведения колес и управления
- Режимы поворот-движение с разным управлением
- Разные ограничения в разных режимах
Что в итоге вышло
Был взят контроллер с гироскутерных плат и написано управление колесами таким образом, чтобы при старте движения и поворотах использовалось управление по моменту. А если тележка едет прямо и разогналась до определенной скорости — то включается режим управления именно по скорости. В обоих режимах данные с энкодеров обрабатываются внутри контроллера с учетом скорости и режима и наружу выдаются данные с некоторым предсказанием вперед на 10-15 мс.
Энкодеры же читаются в контроллере всегда, скапливаются в буфере в 2-3 элемента и передаются с задержкой. Суть в том, чтобы при получении управление отклик пошел только после того как команда будет выполнена — т.е. выполняется блокировка буфера до того как придут изменившиеся значения энкодеров. Но выдача одометрии идет, просто использует последнее уже переданное значение.
Т.к. все вышеприведенные проблемы сводились к тому, что надо в любом случае синхронизировать управление на синхронной приеме-передаче с UART порта, то вводить принудительный синхронизатор в пакет diff_drive мы сочли неразумным, поэтому написан свой пакет управления.
Находится здесь github.com/Shadowru/hoverboard_driver и на текущий момент активно дорабатывается:
Пакет включается в launch файл как :
<node name="hoverboard_driver" pkg="hoverboard_driver" type="node" output="screen">
<param name="uart" value="{имя порта}"/>
<param name="baudrate" value="115200"/>
<param name="wheel_radius" value="0.116"/>
<param name="base_width” value="0.43"/>
<param name="odom_frame” value="odom"/>
<param name="base_frame” value="base_link"/>
</node>
Сам uart порт должен быть с соответствующими правами доступа, на некоторых платформах он не всегда имеет доступ для пользователя. Как пример — для Jetson Nano в каталоге hoverboard_driver/scripts/jetson_nano_serial.sh приложен скрипт проставляющий права при старте ОС.
В самом пакете есть чтение потока данных с контроллера и выдача в топики соответствующей информации:
hoverboard_driver/hoverboard_msg с пакетом типа hoverboard_msg
Структура сообщения такова :
int16 state1 — внутренняя информация по колесу 1
int16 state2 — внутренняя информация по колесу 2
int16 speed1 — мгновенная скорость колеса 1
int16 speed2 — мгновенная скорость колеса 2
int16 batVoltage — напряжение батареи
int16 boardTemp — температура контроллера
int16 error1 — ошибка колеса 1
int16 error2 — ошибка колеса 2
int32 pulseCount1 — счетчик энкодера колеса 1
int32 pulseCount2 — счетчик энкодера колеса 2
Кроме этого в топик hoverboard_driver/odometry выдается типовое сообщение nav_msgs::Odometry
Рассчитывается положение так :
Исходя из параметров wheel_radius — радиус колеса в метрах, base_width — расстояние между центрами колес мы рассчитываем насколько каждое колесо сдвинулось за время между предыдущим положением и и считанным.
double curr_wheel_L_ang_pos = getAngularPos((double) feedback.pulseCount1);
double curr_wheel_R_ang_pos = getAngularPos((double) feedback.pulseCount2);
double dtime = (current_time - last_time).toSec();
double delta_L_ang_pos = curr_wheel_L_ang_pos - raw_wheel_L_ang_pos;
double delta_R_ang_pos = -1.0 * (curr_wheel_R_ang_pos - raw_wheel_R_ang_pos);
После чего рассчитываем ускорение каждого из колес
wheel_L_ang_vel = delta_L_ang_pos / (dtime);
wheel_R_ang_vel = delta_R_ang_pos / (dtime);
Далее считаем линейное ускорение робота по каждой из осей
robot_angular_vel = (((wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width) - robot_angular_pos) / dtime;
robot_angular_pos = (wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width;
robot_x_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * cos(robot_angular_pos));
robot_y_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * sin(robot_angular_pos));
В итоге получается полный набор — линейное ускорение, угловое ускорение и перемножив их на время — смещение позиции робота.
robot_x_pos = robot_x_pos + robot_x_vel * dtime;
robot_y_pos = robot_y_pos + robot_y_vel * dtime;
После чего на отправляется сообщение одометрии плюс tf трансляция между фреймом одометрии и базовым.
Контроллер на входе управляется одним пакетом с 2 параметрами — скорость и поворот, пакет транслируется из twist почти нативно — скорость делится на длину окружности и получаются обороты.
double v = vel.linear.x;
double rps = v / rpm_per_meter;
double rpm = rps * 60;
int16_t speed = static_cast(rpm);
а угловое ускорение переводится в разницу скоростей колес в виде умножения на коэффициент, в дальнейшем добавится пересчет с учетом базы колес, но по практике это нужно только для достаточно больших и тяжелых роботов.
double w = vel.angular.z;
int16_t steer = static_cast<int>(-1 * w * 30);
В итоге удалось добиться весьма стабильного управления тележки на дешевых компонентах.
Мы создаем роботов, как и подавляющее большинство из Вас. У нас есть наш основной продукт, который мы активно развиваем. Провели пилотные испытания и готовы к производству. Это робот для сбора мячей для гольфа.
Мы разрабатываем роботов и производные решения на заказ. Иногда это работа от ТЗ и скетча до готового продукта, иногда часть работ.
В большинстве случаев для взаимодействия с внешним миром роботу необходимы колеса. Чаще всего это бесколлекторные двигатели, ввиду возможности точно управлять скоростью и положением.
Для роботов малых размеров часто используют колеса от гироскутера, это оправдано ввиду массового производства и цены данного решения. Кто видел прайс на российские двигатели понимает значение массового производства.
Что касается контроллера чаще всего это модельные esc, vesc, odrive, BLD-300B или самодельные решения.
Для легкого входа в создание реальных роботов и снятия проклятия Gazebo большинству разработчиков требуется кит для легкого входа. Многое в реальном мире происходит не так как в идеальном.
Иногда происходят непредсказуемые вещи, зашумленность датчиков, реалтайм, перезаполнение буферов. На это видео устройство, которое мы до этого тестировали с контактором и удаленным килсвитчом.
Извините, данный ресурс не поддреживается. :(
Мы предлагаем то, что помогло бы нам сэкономить нервы в свое время, это кит для сборки корпуса(параллелепипед и цилиндр), два мотор-колеса, батарея, зарядное устройство и перепрошитый контроллер, который выдает одометрию и работает с нашим пакетом ROS из коробки за 19.000 руб. Это дешевле чем фрезерная резка, стоимость композитного материала, крепежа и поворотного колеса с амортизацией.
Позвоните нам или оформите заявку на платформу для ROS online. Давайте делать роботов вместе.
Подробнее о платформе мы расскажем на митапе, посвященный Robot Operating System 5 декабря. Регистрация для участников уже открыта.
→ Регистрация для зрителей
===========
Источник:
habr.com
===========
Похожие новости:
- [Машинное обучение, Учебный процесс в IT, Развитие стартапа, Биотехнологии, DIY или Сделай сам] Диагностика крови с помощью Deep Learning: Как превратить проект с хакатона в стартап и поднять $20,5 млн (перевод)
- [Информационная безопасность, Платежные системы, Криптовалюты] Битва платёжных систем: криптовалюта и карты. На чьей стороне ты?
- [Работа с видео, Копирайт] Премьеры всех фильмов Warner Bros. 2021 года пройдут на стриминговом сервисе HBO Max
- [Разработка под Arduino, Киберпанк, Носимая электроника, DIY или Сделай сам, Лайфхаки для гиков] Telogreika v1.0 — носимое устройство персонального обогрева на Arduino
- [Промышленное программирование, Программирование микроконтроллеров, Разработка под Arduino, Производство и разработка электроники] Кому в микроконтроллере жить хорошо?
- [IT-инфраструктура, Робототехника, Транспорт, Сотовая связь] 5G для железных монстров
- [Схемотехника, Производство и разработка электроники, Звук, Электроника для начинающих] Разработка своего устройства от А до Я. Часть 2: Создание устройства
- [Энергия и элементы питания, DIY или Сделай сам] Проверь свои клеммники
- [Разработка робототехники, Конференции, Робототехника, Искусственный интеллект, DIY или Сделай сам] Проект SweetieBot: компактный шагающий робот под управлением ROS
- [Информационная безопасность, Управление персоналом, Удалённая работа] Microsoft пообещала поменять систему слежки за сотрудниками Productivity Score после волны критики от экспертов
Теги для поиска: #_razrabotka_robototehniki (Разработка робототехники), #_razrabotka_pod_arduino (Разработка под Arduino), #_robototehnika (Робототехника), #_diy_ili_sdelaj_sam (DIY или Сделай сам), #_ros, #_robot (робот), #_diy, #_blog_kompanii_golf_robotics (
Блог компании Golf Robotics
), #_razrabotka_robototehniki (
Разработка робототехники
), #_razrabotka_pod_arduino (
Разработка под Arduino
), #_robototehnika (
Робототехника
), #_diy_ili_sdelaj_sam (
DIY или Сделай сам
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 02-Июл 13:27
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 4 месяца |
|
|
Статья написана для только входящих в сам ROS и имеющих необходимость в постройке реального робота для обучения или выполнения реальных задач.  Приступая к изучению ROS обычно сразу хочется работать с физическими платформами, а не с моделями в симуляторе. На самом деле для изучения просто алгоритмов движения или просто обучению самому ROS достаточно и Gazebo, но работа с реальной платформой сразу дает возможность на практике понять все проблемы с колесным движением. Ну и часто платформа нужна просто как обязательное условие проекта. На будущее — лучше начинать с круглого, т.к. по очевидным причинам разворот у такой конфигурации возможен вокруг оси без учета размера выпирающей части. Прямоугольник для разворота гораздо менее удобен, например в узких коридорах — иногда становится необходимо разворачиваться 3 и более приемов, автомобилисты думаю поймут. Покупка готовых платформ На рынке не так много готовых платформ, их список приведен на сайте ROS. При этом стоимость их в России достаточно высока для начала работ, самый дешевый вариант это Turtlebot Burger 3 — 549 долларов. У реселлеров непосредственно в России мы нашли за сумму около 90000 т.р.  В Китае можно купить за 45-50 т.р… В любом случае, это будут платформы малого размера и грузоподъемности, не способные выполнять реальные задачи. Платформу можно собрать самому платформу, тут есть масса разных гайдов и конфигураций. Но в среднем получается что-то вроде:
 Коллекторные двигатели нам не понравились потому что шумные, имеют высокое потребление и необходим редуктор. Тут надо сказать, что рассматриваются платформы достаточно тяжелые — т.е. сблокированные редукторы + двигатели что-то вроде двигателя с фото не подойдут. Соответственно, как движители были выбраны BLDC мотор-колеса. Самый доступный на текущий момент вариант — это гироскутерные колеса 6.5. Осталось только ими управлять из ROS. Но тут всплыла одна проблема: еще при работе с гольф роботами была замечена существенная проблема с поворотом такой платформы на низкой скорости — робот достаточно дерганно разворачивался. Причины такого поведения просты: в развороте существенную роль сопротивлению движения работают силы трения скольжения. А у них есть особенность — сопротивление зависит от массы и характера самих поверхностей — именно поэтому маленький болтик первыми 2-3 витками держит большие конструкции. Поэтому делать колеса узкими в центре становится чтобы он разворачивался достаточно бессмысленно — сопротивление изменится очень мало. Колесо из резины трется о траву и грунт, которые совсем не ровные и сила может резко меняться, в итоге было сделано что-то вроде коробки передач — на малой скорости контролируем момент на колесе, а при прямом движении — саму скорость. Извините, данный ресурс не поддреживается. :( Казалось бы при движению по паркету или линолеуму ситуация должна быть лучше, но увы коэффициент трения почти такой же(вспомним, что противоскользящая обувь делается тоже из резины).  И в итоге робот весом в 10-15 килограмм уже начинает разворачиваться с ощутимыми рывками. Вторую часть проблемы добавляет пакет ROS diff_drive в сочетании с достаточно слабыми SBC платами. Вот список того, что удалось понять Управление ведется с использованием real-time реализации, но никак не учитывается, что прочие пакеты должны ожидать данный подход при работе с управлением. Тут надо вспомнить, что real-time не мгновенная реакция на событие, а гарантия того, что обработка события пройдет в гарантированные интервалы физического времени. Т.е. условная ГЭС, регулируемая каждую минуту (обязательно каждую) — это тоже real-time система. Появляется шанс того, что сообщениями будут забиты топики планировщика маршрута, а для подсистем позиционирования и планирования маршрута подобное поведение обычно приводит либо к останову и рестарту обработки потока, либо к попыткам отрегулировать на ходу процесс.  В итоге на слабых SBC возникает ситуация с беспрерывным пересчетом пути, либо поиск локализации отъедает достаточно большое процессорное время — и чем больше делается попыток успеть за RT компонентой — тем больше накапливается разбег по времени. В чистом виде положительная обратная связь, которая в данном случае совсем не нужна. Дополнительно к этому gmapping при резких изменениях положения платформы и слабом лидаре тоже начинает работать совсем не быстро — наблюдались паузы до полсекунды, что тоже сильно озадачивает планировщик маршрута. Управление двигателями идет раздельно, поэтому при использовании SBC и наивной реализации драйверов колеса будут управляться с некоторой задержкой. Тут проблема еще проще — нам нужно управлять 2-4 колесами через канал связи, который. Соответственно, сигналы управления выстраиваются в очередь и начинают передаваться друг за другом — левое колесо, правое колесо, левое колесо, правое колесо. В итоге сами колеса, а хуже того — и положения колес с энкодеров начинают вносить свою лепту в образование ПОС между планированием пути и управлением моторами Встроенная одометрия реализована весьма упрощенно Как мы не искали простого способа синхронизировать подачу команды и отдачу одометрии — не нашелся. Синхронизация всегда связана с ожиданием каких-то команд на входе, а они не регулярны во времени и в итоге одометрия начинает задерживаться на выходе. Возможно читатели подскажут простой способ — тут мы не считаем себя гуру в ROS. Добиться того, чтобы подобная сборка вела себя хорошо, нам не удалось. Точнее удалось занизив ускорения перемещения до 0,05-0,1 м/c^2 и угловой скорости до 0,03 рад/с. Подумалось что хорошо бы иметь :
Что в итоге вышло Был взят контроллер с гироскутерных плат и написано управление колесами таким образом, чтобы при старте движения и поворотах использовалось управление по моменту. А если тележка едет прямо и разогналась до определенной скорости — то включается режим управления именно по скорости. В обоих режимах данные с энкодеров обрабатываются внутри контроллера с учетом скорости и режима и наружу выдаются данные с некоторым предсказанием вперед на 10-15 мс. Энкодеры же читаются в контроллере всегда, скапливаются в буфере в 2-3 элемента и передаются с задержкой. Суть в том, чтобы при получении управление отклик пошел только после того как команда будет выполнена — т.е. выполняется блокировка буфера до того как придут изменившиеся значения энкодеров. Но выдача одометрии идет, просто использует последнее уже переданное значение. Т.к. все вышеприведенные проблемы сводились к тому, что надо в любом случае синхронизировать управление на синхронной приеме-передаче с UART порта, то вводить принудительный синхронизатор в пакет diff_drive мы сочли неразумным, поэтому написан свой пакет управления. Находится здесь github.com/Shadowru/hoverboard_driver и на текущий момент активно дорабатывается: Пакет включается в launch файл как : <node name="hoverboard_driver" pkg="hoverboard_driver" type="node" output="screen">
<param name="uart" value="{имя порта}"/> <param name="baudrate" value="115200"/> <param name="wheel_radius" value="0.116"/> <param name="base_width” value="0.43"/> <param name="odom_frame” value="odom"/> <param name="base_frame” value="base_link"/> </node> Сам uart порт должен быть с соответствующими правами доступа, на некоторых платформах он не всегда имеет доступ для пользователя. Как пример — для Jetson Nano в каталоге hoverboard_driver/scripts/jetson_nano_serial.sh приложен скрипт проставляющий права при старте ОС. В самом пакете есть чтение потока данных с контроллера и выдача в топики соответствующей информации: hoverboard_driver/hoverboard_msg с пакетом типа hoverboard_msg Структура сообщения такова : int16 state1 — внутренняя информация по колесу 1 int16 state2 — внутренняя информация по колесу 2 int16 speed1 — мгновенная скорость колеса 1 int16 speed2 — мгновенная скорость колеса 2 int16 batVoltage — напряжение батареи int16 boardTemp — температура контроллера int16 error1 — ошибка колеса 1 int16 error2 — ошибка колеса 2 int32 pulseCount1 — счетчик энкодера колеса 1 int32 pulseCount2 — счетчик энкодера колеса 2 Кроме этого в топик hoverboard_driver/odometry выдается типовое сообщение nav_msgs::Odometry Рассчитывается положение так : Исходя из параметров wheel_radius — радиус колеса в метрах, base_width — расстояние между центрами колес мы рассчитываем насколько каждое колесо сдвинулось за время между предыдущим положением и и считанным. double curr_wheel_L_ang_pos = getAngularPos((double) feedback.pulseCount1);
double curr_wheel_R_ang_pos = getAngularPos((double) feedback.pulseCount2); double dtime = (current_time - last_time).toSec(); double delta_L_ang_pos = curr_wheel_L_ang_pos - raw_wheel_L_ang_pos; double delta_R_ang_pos = -1.0 * (curr_wheel_R_ang_pos - raw_wheel_R_ang_pos); После чего рассчитываем ускорение каждого из колес wheel_L_ang_vel = delta_L_ang_pos / (dtime);
wheel_R_ang_vel = delta_R_ang_pos / (dtime); Далее считаем линейное ускорение робота по каждой из осей robot_angular_vel = (((wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width) - robot_angular_pos) / dtime;
robot_angular_pos = (wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width; robot_x_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * cos(robot_angular_pos)); robot_y_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * sin(robot_angular_pos)); В итоге получается полный набор — линейное ускорение, угловое ускорение и перемножив их на время — смещение позиции робота. robot_x_pos = robot_x_pos + robot_x_vel * dtime;
robot_y_pos = robot_y_pos + robot_y_vel * dtime; После чего на отправляется сообщение одометрии плюс tf трансляция между фреймом одометрии и базовым. Контроллер на входе управляется одним пакетом с 2 параметрами — скорость и поворот, пакет транслируется из twist почти нативно — скорость делится на длину окружности и получаются обороты. double v = vel.linear.x;
double rps = v / rpm_per_meter; double rpm = rps * 60; int16_t speed = static_cast(rpm); а угловое ускорение переводится в разницу скоростей колес в виде умножения на коэффициент, в дальнейшем добавится пересчет с учетом базы колес, но по практике это нужно только для достаточно больших и тяжелых роботов. double w = vel.angular.z;
int16_t steer = static_cast<int>(-1 * w * 30); В итоге удалось добиться весьма стабильного управления тележки на дешевых компонентах.  Мы создаем роботов, как и подавляющее большинство из Вас. У нас есть наш основной продукт, который мы активно развиваем. Провели пилотные испытания и готовы к производству. Это робот для сбора мячей для гольфа. Мы разрабатываем роботов и производные решения на заказ. Иногда это работа от ТЗ и скетча до готового продукта, иногда часть работ.  В большинстве случаев для взаимодействия с внешним миром роботу необходимы колеса. Чаще всего это бесколлекторные двигатели, ввиду возможности точно управлять скоростью и положением. Для роботов малых размеров часто используют колеса от гироскутера, это оправдано ввиду массового производства и цены данного решения. Кто видел прайс на российские двигатели понимает значение массового производства.  Что касается контроллера чаще всего это модельные esc, vesc, odrive, BLD-300B или самодельные решения. Для легкого входа в создание реальных роботов и снятия проклятия Gazebo большинству разработчиков требуется кит для легкого входа. Многое в реальном мире происходит не так как в идеальном. Иногда происходят непредсказуемые вещи, зашумленность датчиков, реалтайм, перезаполнение буферов. На это видео устройство, которое мы до этого тестировали с контактором и удаленным килсвитчом. Извините, данный ресурс не поддреживается. :( Мы предлагаем то, что помогло бы нам сэкономить нервы в свое время, это кит для сборки корпуса(параллелепипед и цилиндр), два мотор-колеса, батарея, зарядное устройство и перепрошитый контроллер, который выдает одометрию и работает с нашим пакетом ROS из коробки за 19.000 руб. Это дешевле чем фрезерная резка, стоимость композитного материала, крепежа и поворотного колеса с амортизацией.  Позвоните нам или оформите заявку на платформу для ROS online. Давайте делать роботов вместе. Подробнее о платформе мы расскажем на митапе, посвященный Robot Operating System 5 декабря. Регистрация для участников уже открыта. → Регистрация для зрителей =========== Источник: habr.com =========== Похожие новости:
Блог компании Golf Robotics ), #_razrabotka_robototehniki ( Разработка робототехники ), #_razrabotka_pod_arduino ( Разработка под Arduino ), #_robototehnika ( Робототехника ), #_diy_ili_sdelaj_sam ( DIY или Сделай сам ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 02-Июл 13:27
Часовой пояс: UTC + 5