dmitrydzz

[dmitrydzz]

I think there’s a bug in HerkuleX DRS-0101 smart servo’s firmware. Workaround.

First of all – I love these servos. There’s a great user manual, small sized, an enormous number of features, etc. etc.

But there was one issue I've finally solved! Maybe two. The second one is that there is not much information about this servo in the Net. Some people have been faced the same problem. So I decided to share my humble experience.

But - in order… The first quest was to find a library to use it in my code. I found one dead Python project, some more or less alive Arduino libraries and one C++ Windows library (with dll and with no source code). My plan was to control HerkuleX servos in C++ ROS node, so Python was my plan “B”, Windows library was useless in Ubuntu, and the only suitable way was to edit the open source Arduino library. Of course, I could write my own library from scratch, but that’s the warrior’s way.

I think I had chosen one of the most popular Arduino library and the only thing I changed in it was the implementation of serial port communication since it is very “Arduino oriented”. When the library was completed, I included it in my code and all functions I’d used were working fine except one… GetAngle() was unstable. Sometimes it worked correctly, sometimes it returned -166.72°.

I tried three servos HerkuleX DRS-0101 with the same result. It was definitely a software issue.

I dived deep into the servo’s manual and attentively checked the code of GetAngle() function. It seemed everything is fine with the function. So I wrote a Python script to send data packets to the servo and receive response packets from it. Finally, I noticed that sometimes packets with the servo’s position have wrong size byte.

Here is a “good” packet:

FF FF 0D FD 44 B2 4C 3A 02 1F 62 00 42

And this is a broken one:

FF FF 0A FD 44 B2 4C 3A 02 1F 62 00 42

First two bytes are the header.

0D(13) is the length of the packet. 13 – exactly the size of this sequence of bytes. And 0A(10) – is the core of my problem.

FD is the servo’s unique identifier.

44 identifies the response on Read RAM command.

B2 – checksum1 (bold text).

4C – checksum2 (bold text).

3A – address in the RAM Registry we are reading (address of the current calibrated position).

02 – number of bytes we are reading.

1F 62 – the servo’s angle (I’ll explain these numbers in a moment).

00 – status error (0 is a good sign).

42 – status detail.

Just a short off-topic about 1F 62 value. These two bytes are a flipped 2-byte integer 0x621F. Significant bits for calibrated servo position is 10 lowest bits, so the final value is 0x021F. To get the angle in degrees we can use the table in the manual or just calculate this expression:

(0x021F - 512) * 0.325 = (543 - 512) * 0.325 = 10.075°.

So when the servo sends a packet with the wrong length byte, the GetAndle() function fails while testing the packet’s checksums. The returned value -166.72 is a consequence of this fail.

The thing is that if we change the length byte from 0A to 0D, the checksums will be correct! Note that checksums in both correct and broken packets are the same. I believe that there is a bug in servo’s firmware that this byte with the packet’s length value sometimes is not set and it is filled with garbage. That’s why sometimes GetAngle() works, sometimes doesn’t.

I checked the firmware version in my servos: 090. Unfortunately, it’s the latest available firmware. It is dated May 10, 2012. What is the manufacturer waiting for? Today it is December 2017.

And now the worst thing. GetAngle() is a high-level function from Arduino library that reads two bytes from RAM Register starting with address 0x3A. I mean that GetAngle() uses a low-level firmware function that reads data from RAM Register. So I assume that reads of any other RAM Register addresses don't work properly either.

That's the time for good news. Here is the workaround I promised in the title. We can change the byte with the packet length in the received data packet. Only one single byte. After that, both checksums will become valid.

Here is the original Arduino library I’ve used. User Rambo made a GitHub copy and some improvements in it and I made a fork just to fix the firmware bug. See the changes in my GitHub commit.

By the way. There’s another issue with this library while running on Arduino Uno. It uses SoftwareSerial, thereby I noticed the communication is unstable on 115200 baud rate and should be reduced to 57600. But that’s another story.

[dmitrydzz]

Архитектура робота Мити III

Всё о чём я пишу ниже и буду писать в ближайших постах должно находиться в Вики проекта. Но я пока не придумал что это будет за Вики, в каком сервисе, на каком языке (русский? английский? оба?). Чтобы не растерять во времени свои знания о проект�� временно сделаю это в блоге.

Митя III - это робот, построенный на ROS. А значит, его архитектура распределённая и наращиваемая. Я опишу пока то что уже есть и то, что планирую делать во что бы то ни стало. На сегодняшний день можно сказать, что аппаратно Митя III готов. Есть пара незавершённых штрихов: фары и хвост, но функционально они действуют (фары заменены пока на маломощные светодиоды, хвост выглядит как просто качалка на серводвигателе). В фоне буду придумывать какими будут эти элементы, а сейчас переключаюсь на разработку ПО.

Описывая архитектуру системы, перечислю и ROS-узлы - но не более того. Подробней о ROS-узлах, топиках, типах сообщений и системе команд напишу в другом посте.

Итак, какие основные архитектурные узлы у Мити III:

сам мобильный робот - это связка Raspberry Pi 3, Arduino-совместимого контроллера, мобильной платформы и подсистемы питания,

голова Мити - это смартфон, закреплённый на "сервошее" робота с двумя степенями подвижности,

пульт управления. Это может быть PC- и/или Android-приложение. В программе-максимум сделать приложение для управления роботом в Google Cardboard/Daydream.

Прежде чем опишу детальней каждый архитектурный узел, скажу несколько слов о том, что мне нравится и что не нравится в такой конфигурации робота. Идея Мити I заключалась в минимизации узлов и цены. Был только смартфон для "мозга" и сенсоров робота, Arduino-контроллер для исполнительных механизмов, ну и пульт управления в самом простом исполнении. Я и сейчас считаю, что это самая правильная архитектура для дешёвого домашнего робота телеприсутствия.

Однако погрузившись в ROS, я узнал, что её реализация в ОС Android ограничена и далека от реализации в Ubuntu. Я не смогу использовать многие уже готовые решения. Сам процесс разработки и отладки оказался не всегда удобен и прост. Так я принял решение ввести в систему Raspberry Pi 3 с Ubuntu и полноценным ROS на борту. Я не исключаю, что со временем фунуции робота, выполняемые на Raspberry Pi, переместятся в смартфон. Но также не исключаю и вариант, что функции смартфона перейдут в Raspberry Pi и Митя откажется от смартфона. Посмотрим что будет, а сейчас такая избыточность только придаёт проекту гибкость.

Вернусь к описанию архитектурных узлов.

Мобильный робот

Аппаратное обеспечение:

Raspberry Pi 3

Функции:

управление серводвигателями головы

мониторинг состояния серводвигателей головы

обработка данных сенсора ориентации головы

трансляция команд в/из контроллер Hercules Dual 15A 6-20V Motor Controller

ROS-узлы:

herkulex_node

mpu6050_node

arduino_node

Hercules Dual 15A 6-20V Motor Controller

Функции:

управление ходовыми двигателями

управление светом фар (две независимые линии)

управление серводвигателем хвоста

передача данных о скорости движения

передача данных о пройденном пути

передача данных о напряжении батареи питания

передача данных о напряжении питания Raspberry Pi 3

Голова Мити III

Аппаратное обеспечение:

Android-phone (опционально)

Функции:

эмоции на лице

тач и жесты на лице

траснляция видео с камеры телефона

трансляция звука с микрофона телефона

воспроизведение звука

передача данных о состоянии батареи питания телефона

WiFi роутер (опционально)

трансляция данных датчика ориентации головы (опционально)

Пульт управления

Аппаратное обеспечение:

Ubuntu-desktop/Android-tablet/Android-phone

Функции:

обработка данных состояния джойстика

отображение видео с камеры Мити

воспроизведение звука с микрофона Мити

отображение состояния частей системы (напряжение батареи, скорость, пройденный путь и т.д.)

передача (стриминг) звука

Android-phone + Cardboard/Daydream

Функции:

обработка данных ориентации головы

отображение видео с камеры Мити

воспроизведение звука с микрофона Мити

отображение состояния частей системы (напряжение батареи, скорость, пройденный путь и т.д.)

передача (стриминг) звука

ROS-узлы:

joy

joystick_node

[dmitrydzz]

Я закончил аппаратную часть Мити III. Осталась пара мелочей: вместо фар пока маломощные светодиоды, вместо хвоста - качалка сервомотора. Фоном буду думать какими их вижу, а теперь ныряю в ПО.

[dmitrydzz]

Митя переезжает в Tumblr?

После долгого молчания решил возобновить свою писанину. Точно не знаю зачем, но почему-то хочется сохранять всю эту хронологию метаний и поиска смысла Робота Мити. Возможно это ещё и графоман во мне просится наружу. Тем не менее, есть какие-то темы и решения, относящиеся к проекту, но выходящие за рамки технической документации. Попробую использовать Tumblr для этих целей.

Кратко о проекте. Началось всё со статей на Хабре:

Android + Arduino + 4 колеса

Android + Arduino + 4 колеса. Часть 2

Android + Arduino + 4 колеса. Часть 3 – передача видео и звука

Затем был блог Робохобби, потом сайт robot-mitya.ru. Это был период, когда я активно пытался привлечь других участников к проекту. Я не смог совместить пиар, поддержку сайта, документироние и развитие проекта и в конечном счёте выбрал только две последние позиции, надолго пропав из эфира.

Теперь о концепции проекта. Митя - это робот телеприсутствия. Проект открытый, задумывался как максимально простой для вхождения участников и дешёвый в реализации. Идея была такова - использовать любую мобильную платформу (тележку) с Arduino Uno и драйвером моторов и Android-телефон для всего остального:

WiFi-роутер,

Bluetooth,

видеокамера,

микрофон,

динамик,

сенсорный дисплей,

память,

датчики ориентации.

Что-то из этого получилось, но в ходе развития проекта появлялись части Мити, усложняющие архитектуру, повышающие его стоимость и затрудняющие вход в проект новых участников. И однажды вопрос встал ребром: Митя остаётся дешёвым или Митя будет умным? Я не хочу заниматься коммерческой стороной проекта - это прежде всего хобби-проект, поэтому моя главная цель: интерес и разнообразие. И так как на первом месте получение удовольствия от проекта, а не удешевление, оптимизация, популяризация и прочее и прочее, я выбрал "Митя будет умным".

Это в корне поменяло архитектуру Робота Мити, в связи с чем, я начал работать над третьим "поколением" Мити. Митя III, другими словами. Думаю, архитектуру робота я опишу в следующем посте.