roboforum.ru

Про проблемы с режимом энергосбережения приходилось слышать ранее.
В принципе, сейчас с новым донглом на RTL8191 и Orange Pi PC проблема с пингами исчезла.
Теперь запускаю hector_slam прямо на Orange Pi, скорости работы вполне хватает, карта получается более-менее сносная для самодельного дальномера.

А вот навигация (move_base) работает как-то не очень.
Около препятствий, особенно в узких коридорах, в процессе движения робот может немного сбиться с глобального пути, и оказаться слишком близко к препятствиям. После этого он начинает по-всякому крутиться и подергиваться на месте, и на глобальный путь возвращается с большим трудом. Проблема явно связана именно с близостью препятствий, на открытых площадках навигация идет нормально.
Насколько я понял, base_local_planner вообще не умеет выдавать команды "двигаться назад", а команды "вращение на месте" он выдает как-то странно.
В симуляторе stage все описанные проблемы повторяются.

base_local_planner
...
~<name>/holonomic_robot (bool, default: true)

Determines whether velocity commands are generated for a holonomic or non-holonomic robot. For holonomic robots, strafing velocity commands may be issued to the base. For non-holonomic robots, no strafing velocity commands will be issued.

у вас что?


сорри, похоже это действительно про голономного робота (на омни-колесах) а не эмуляцию

вот так вроде должно быть

Код: Выделить всё

# Differential-drive robot configuration
  holonomic_robot: false
  max_vel_y: 0.0
  min_vel_y: 0.0
  acc_lim_y: 0.0
  vy_samples: 0

вот ещё http://answers.ros.org/question/225835/ ... ward-only/

вот как в turtlebot
https://github.com/turtlebot/turtlebot_ ... launch.xml
https://github.com/turtlebot/turtlebot_ ... arams.yaml
https://github.com/turtlebot/turtlebot_ ... arams.yaml

holonomic_robot: false и так у меня был установлен,

max_vel_y: 0.0
min_vel_y: 0.0
acc_lim_y: 0.0
vy_samples: 0

добавил, при этом робот иногда действительно начал ездить задом, хотя вроде бы и не должен - обычный local_planner это вроде не позволяет.
Я пробовал использовать dwa_local_planner, как советуют nswers.ros.org, но он у меня как-то криво работал, нужно будет еще поэкспериментировать с симулятором.
Есть подозрения, что у меня еще и что-то с настройками частот всей системы навигации не так.

turtlebot тоже использует dwa_local_planner
Вот тут делятся информацией какие параметры важны для двухколёсного робота https://www.youtube.com/watch?v=LzyMQVSJvzY

Кстати, судя по первому сообщению в этой теме forum10/topic12095.html
у вас есть две конструкции робота, одна самодельная вторая на базе робота пылесоса, какую сейчас используете?

В случае работы с ROS конструкция всегда одна и та же - пылесос roomba 400 и самодельный дальномер. На самодельного робота я дальномер только в самом начале экспериментов ставил, пока ROS еще не использовал.

вот тут в блоге ребята также переделывали roomba чтобы работал как Turtlebot
http://robocraft.ru/blog/976.html
там целая серия статей как они всё делали. (правда некоторые команды будут отличаться в новой версии ROS)

я советую идти тем же путём, по сути требуется небольшая модификация ланчфайлов Turtlebot и всё есть в блоге, а для Turtlebot очень много примеров, в том числе рабочая навигация которая сразу должна заработать, так что можно будет сосредоточиться на решении сложных задач а не воевать с ROS.

полезные туториалы
http://learn.turtlebot.com/

в итоге всё должно свестись к примерно вот таким командам

Код: Выделить всё

export TURTLEBOT_BASE = roomba
export TURTLEBOT_STACKS = circles
export TURTLEBOT_3D_SENSOR = asus_xtion_pro
export TURTLEBOT_SIMULATION = false
export TURTLEBOT_SERIAL_PORT = / dev / ttyUSB0
export ROS_IP = 192.168.1.16

Press Roomba largest middle button "CLEAN", execute the following script to start turtlebot

  $ Roslaunch turtlebot_bringup minimal.launch


вот ещё пример, посвежее http://cyberworks.cocolog-nifty.com/blo ... -5f32.html

Вот тут ещё можно посмотреть примеры скриптов https://github.com/vicoslab/vicos_ros
скрипты используются в учебном курсе так что максимально автоматизируют процесс установки и настройки https://github.com/vicoslab/vicos_ros/b ... p_setup.sh

Все равно воевать с ROS приходится.
Вот например, здесь: https://github.com/turtlebot/turtlebot_ ... arams.yaml
указано - transform_tolerance: 0.5
В большинстве остальных примеров примерно так же, иногда ставят 1.0.
У меня даже при 1.0 move_base постоянно выдает warning:

Costmap2DROS transform timeout. Current time: 1463223582.6300, global_pose stamp: 1463223581.5903, tolerance: 1.0000
[ WARN] [1463223582.630455929]: Could not get robot pose, cancelling reconfiguration

У меня используется Roomba 400, а в turtlebot - Roomba 500, у них заметно протоколы обмена различаются. Для Roomba 400 официального пакета ROS нет, мне удалось найти какой-то полурабочий и переделать его.
Также для turtlebot все примеры с навигацией базируются на gmapping/amcl, а у меня прилично только hector_slam работает.

вот тут говорят это из-за того что /odom слишком редко публикуется нужно 20гц или более http://ros-users.122217.n3.nabble.com/C ... 35497.html
а какой пакет используете для 400 румбы?

такой пробовали? https://github.com/autonomylab/create_autonomy даже deb пакет должен быть

правда 400я с пометкой

* Not verified. Anyone who is able to verify that this driver works or not is encouraged to contact Jacob with their findings or open an issue.

В обсуждении "Costmap2DROS transform timeout." у человека было выставлено - tolerance: 0.2000, а одометрия была то ли 1.25, тол ли 2 Гц.
Очевидно, что при такой низкой частоте выдавался warning.
У меня частота одометрии - 10 Гц, но из warning видно, что где-то возникает практически секундная задержка.
При симуляции в stage такие сообщения не появляются (частота симуляции - 10 Гц).

Пакет для roomba 400 брал здесь: https://github.com/dpiet/robotsindc-ros-pkg но его пришлось переделать - там одометрия какая-то кривая была.

В описании create_autonomy прямо заявляют:

This package wraps the C++ library libcreate, which uses iRobot's Open Interface Specification.

У roomba 400 протокол - sci, так что можно получить проблемы с совместимостью протоколов.

понятно, я бы попробовал увеличить с 10 до 20 герц. не поможет, см ниже

вот тут рассказано что не сильно отличается http://hackingroomba.com/?s=irobot

если я правильно понял в robotsindc-ros-pkg одометрия вычисляется по тикам энкодеров,

Код: Выделить всё

// Calculate Roomba odometry
void irobot::SerialCommInterface::calculateOdometry()
{   
   double dist = (encoder_counts_[RIGHT]*ROOMBA_PULSES_TO_M + encoder_counts_[LEFT]*ROOMBA_PULSES_TO_M) / 2.0;
   double ang = (encoder_counts_[RIGHT]*ROOMBA_PULSES_TO_M - encoder_counts_[LEFT]*ROOMBA_PULSES_TO_M) / -ROOMBA_AXLE_LENGTH;

   // Update odometry
   this->odometry_yaw_ = NORMALIZE(this->odometry_yaw_ + ang);         // rad
   this->odometry_x_ = this->odometry_x_ + dist*cos(odometry_yaw_);      // m
   this->odometry_y_ = this->odometry_y_ + dist*sin(odometry_yaw_);      // m
}

а в libcreate , через команыд DISTANCE,ANGLE

Код: Выделить всё

    if (model == CREATE_1) {
      /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
       * Angle returned is NOT correct if your robot is using older firmware:      *
       * http://answers.ros.org/question/31935/createroomba-odometry/              *
       * TODO: Consider using velocity command as substitute for pose estimation.  *
       * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
      deltaDist = ((int16_t) GET_DATA(ID_DISTANCE)) / 1000.0; //mm -> m
      deltaYaw = ((int16_t) GET_DATA(ID_ANGLE)) * (util::PI / 180.0); // D2R
      deltaX = deltaDist * cos( util::normalizeAngle(pose.yaw + deltaYaw) );
      deltaY = -deltaDist * sin( util::normalizeAngle(pose.yaw + deltaYaw) );
      leftWheelDist = deltaDist / 2.0;
      rightWheelDist = leftWheelDist;

    }

в тоже время в robotsindc-ros-pkg есть команды parseDistance, parseAngle.
так что я бы сказал что должно работать

ещё, как мне кажется, в robotsindc-ros-pkg реализовано всё в один поток, а в create_autonomy общение с роботом отдельно, публикация отдельно, полагаю это имеет большое значение, поэтому тупо подправить robotsindc-ros-pkg не получится

Пока не стал переходить на create_autonomy - есть подозрение, что сборка этого пакета будет долгой на Orange Pi, и как всегда, куча ошибок повылезает.
Насколько я понял, в create_autonomy нет способа переключаться между протоколами, так что create_autonomy может послать не поддерживаемый запрос на roomba.
Еще поковырялся с ROS.
Заметил, что если запустить tf_monitor для практически любых frame (например odom и map, или odom и base_link), то пока не запущена навигация, времена преобразования (TF) находятся в норме.
После того, как запускаю пакет навагации, и он получает карту от hector_slam, сразу же все времена преобразований начинают резко возрастать (до 10 раз и более).
После остановки навигации времена приходят в норму.
Загрузка процессора при этом - не более 60%.
Если запускать симуляцию, то такого роста времен преобразований не происходит.
Каким образом навигация влияет на TF, если она даже не публикует TF преобразований, совсем не понятно.

Насколько я понял, в create_autonomy нет способа переключаться между протоколами

задаётся в ланч файле, https://github.com/AutonomyLab/create_a ... e_1.launch

, так что create_autonomy может послать не поддерживаемый запрос на roomba.

теоретически да, но если вас интересует только одометрия и управление движением то остальное легко отключается комментированием

Код: Выделить всё

bool CreateDriver::update()
{
  publishOdom();
  publishBatteryInfo();
  publishButtonPresses();
  publishOmniChar();
  publishMode();
  publishBumperInfo();
  publishWheeldrop();
....

После того, как запускаю пакет навагации, и он получает карту от hector_slam, сразу же все времена преобразований начинают резко возрастать (до 10 раз и более).
После остановки навигации времена приходят в норму.
Загрузка процессора при этом - не более 60%.
Если запускать симуляцию, то такого роста времен преобразований не происходит.
Каким образом навигация влияет на TF, если она даже не публикует TF преобразований, совсем не понятно.

с точки зрения ядра линукс ROS это процессы, чем больше одновременно запущенных процессов тем меньше каждый из них получает времени на работу.

У вас 4х ядерный проц соответственно как только становится больше 4х одновременно работающих процессов так сразу производительность проседает.

В таком случае можно попробовать поиграться риоритетами, посмотрите документацию на команду nice

You could use the launch-prefix flag in a .launch file, with a value something like "nice -n -1" (nice being the UNIX command for setting priority).

Второй мощный инструмент cgroups, вот тут подробнее про методы
http://blog.scoutapp.com/articles/2014/ ... nd-cgroups

кроме того не стоит забывать про
- возможность разогнать процессор http://www.orangepi.org/orangepibbsen/f ... ad&tid=673
- отключить энергосбережение, переключить управление частотой процессор в состояние performance
- отключить все ненужные процессы и демоны, само собой выключить иксы
- оптимизировать всё что только можно с точки зрения производительности, например добавить опцию noatime это довольно сильно ускорит некоторые операции с fs , https://lonesysadmin.net/2013/12/08/gai ... -relatime/

вообще посмотрите как выжать максимальную производительность из Orange Pi PC

если линкусом не очень владеете можем вместе поискать решения.

есть подозрение, что сборка этого пакета будет долгой на Orange Pi, и как всегда, куча ошибок повылезает.

я думаю соберётся бысто, это простой пакет, ошибки наверное возможны, но пакет вроде как довольно свежий, поэтому маловероятно, хотя в свете того что у вас есть проблемы и покруче, пока можно остаться на старом пакете

Добавлено спустя 8 минут 6 секунд:
Re: Самодельный робот на базе ROS - Custom mobile robot with ROS
вот тут есть всё про разгон http://linux-sunxi.org/Orange_Pi_PC#CPU ... peed_limit

Добавлено спустя 1 час 48 минут 56 секунд:
Re: Самодельный робот на базе ROS - Custom mobile robot with ROS
я ещё подумал, а памяти то хватает? можно посмотреть через htop

В том-то и дело, что у меня навигация на ноутбуке крутится, а на orange pi только hector_slam, узел roomba и узел дальномера. В этой теме ранее упоминалось, что навигация очень прожорлива и ее на ARM запустить проблематично, так что я даже не пробовал.
Так что при запуске навигации нагрузка на orange pi не должна меняться.
При работе с симулятором stage (в этом случае orange pi не используется) все времена преобразований в норме (даже если ноутбук загрузить другим софтом на 90% более).

**********
В ходе экспериментов обнаружил, что времена возрастают и при запуске rviz. Начал разбираться и заметил, что опять вылезла проблема с большим пингами - более 300 мс.
Как оказалось, пинги резко возрастают при передаче большого объема данных - достаточно включить в rviz отображение карты, поток данных через сеть становится более 600 кбайт/сек и сразу пинги становятся очень большими.
Специально проверил - если запустить навигацию и hector_slam на ноутбуке, то с пингами все нормально - поскольку в таком случае по сети идет только одометрия и данные дальномера.
Теперь буду пытаться что-то с настройками wifi адаптера сделать.

понятно, ну про разгон и прочее советы всё равно актуальны

по идее, если мастер ros у вас будет на ноутбуке то таких проблем быть не должно.

Ещё вариант использовать multimaster_fkie, http://wiki.ros.org/multimaster_fkie , чугунный дятел выше советовал его post298560.html#p298560.

Добавлено спустя 1 час 35 минут 16 секунд:
Re: Самодельный робот на базе ROS - Custom mobile robot with ROS
вот так можно посмотреть какая возможна максимальная частота

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
1536000

тут есть ссылка на образ где такая частота по умолчанию http://www.cnx-software.com/2015/09/01/ ... nt-boards/
но не обязательно ставить весь образ, достаточно поправить скрипт инициализации переферии в /boot

если кто будет подбирать плату для ROS вот неплохое сравнение raspbery pi + другие
https://www.loverpi.com/blogs/news/94801153-raspberry-pi-3-banana-pi-m3-oran%20ge-pi-plus-2-odroid-c2-spec-comparison
я бы смотрел в сторону 8ми ядерного banana pi или odroid XU4 или tegra TK1/TX1 + arduino или roomba

кстати интересный факт, hardkernel сделали odroid w - полный аналог pi zero в 2014 году,
http://www.hardkernel.com/main/products ... 0610189490
но им тогда перестали продавать чипы, https://plus.google.com/102407583165771 ... tSaVYwT3UH
интересно кто же здесь злодей?