[CFC] Sensor board compatible with dynamixel protocol

Technology
, , , ,
1

#Call for contribution

At the moment, add a new sensor to a poppy creature it’s a little bit tricky. For example if you want to have a distance sensor into the poppy-humanoid hand, you have to put an arduino into the hand and link the odroid with a long wire. This long wire will be really difficult to integrate properly into the arm and he could create many mechanical problems.

A good solution could be to develop a little library compatible with dynamixel motors. With that we could plug a new sensor after the last motor of the popy arm, give an address to this sensor and use it directly with Pypot.

To do that we need to have an arduino (or something else) library RS485 Robotis with simple acces and configuration.

2

It’s okey the proposed solution, but I think that another solution would be to use bluetooth modules(£6.00) for data communication, and use the connector of dynamixel motor only for energy connection.
I worked with this modules for control an servo and leds, you can see the response time HERE

a+

3

@Xevel works on this subject. See this link

4

Yep, I have stuff like that in the works, though I cannot say when they will be ready as product…

Software / libs

I know of at least 5 open-source code bases (2 of which are mine :wink: ) that more or less do this:

  • DynaBan, from Rhoban Project. You guys might know more than I do about it given who develops it. I haven’t really looked at the code yet, I learned about it only recently. Too bad I did not find out before starting my own lib :confused:
    The idea seems to make an alternative firmware for the Dynamixel servos, so it probably has much more stuff than what is needed for this application.
    Th eproject seems to have started at the end of last year and looks to be under active development.

  • dxld_lib, my new Dynamixel Device lib for Cortex M. It’s quite new and not yet extremely stable (I started it for a project 2 months ago, and this repo has a branch lagging by a few days behind the main development) but I beleive it’s the most advanced one out there. It’s even more feature-rich than what is used in the servos, as it’s intended as a basis for general-purpose dynamixel devices (sensors, actuators, bridge to other communication bus or platforms).
    You can create multiple virtual devices (so it’s possible for example too put multiple hobby servos and address them as each as a different AX-12s, and virtual devices do not need to be all the same type).
    It handles all the regular Dxl 1.0 commands (REG_WRITE and Action are optional, you can save some RAM if you don’t wat to use them), including sync_write.
    In a Cortex-M0 at 48MHz it should be able to work up to 3Mbps.
    This lib is under active development.

I also created a bootloader (for LPC1114 but could be ported to any Cortex M) that talks with Dynamixel commands to update the firmware in place without any risk of upsetting the servos. The bootloader has not been released yet but I hope to do that soon.

  • HUV Robotics made AVR-based Dynamixel devices a few years back. To my knowledge they were the first to make 3rd party Dynamixel stuff. Their code is available here (loooots of stuff in this repo, have alook at “common” and “avr” mostly), though I have found a few little bugs here and there (I still need to make that pull-request :x ). The website is still up though they do not sell these anymore, and I got an error when I tried it (They are looking into it).
    They made an USB to Dynamixel interface (long before the USB2AX!), an IMU, an IO board, a foot-sensor board and some more stuff. Even though the Eagle files are not uploaded, the boards themselves are open-hardware and they’ll happily send you the files if you ask (+ they might have some blank PCBs left if you feel like assembling some for yourself).
    Their libs seem full-featured. There are still some fixes applied from time to time (not abandoned), but they are not actively developed. The repo is so full of stuff that there might be some more gems here and there, I haven’t looked at all of it.

  • Morpheus Firmware, developped by Actuated Character (a kind of research project created by Robosavvy). Source. They had a different type of communication similar to the bulk-read IIRC. Seems dead.

  • my first dynamixel devices using AVR (I used them in Pololu Baby Orangutan 328p and Arduino Pro Mini boards). More or less working, lacks sync_write support, probably have some small bugs and not maintained anymore.

I know of at least 2 other ones that are not open or could be but have not been publicized, not counting ROBOTIS nor any other manufacturer of protocol-compatible servos ( :frowning: ).

Unfortunately, I don’t know any Dynamixel 2.0 Device lib out there yet…

Hardware

In terms of hardware, there are actually very few options at this time.

Out of these 5 projects, 2 are made to run on the servos, 2 run on AVR boards (arduino or HUV Robotics boards) and 1 runs on Cortex M, the board not being finished yet.
My previous boards that @Thot linked to have never seen a line of code in their life :frowning: I could probably have my lib running on the latest one pretty quickly and easily (lib developed on LPC1114 and the board has a LPC11A04 IIRC).

Please note that out of these, only the HUV Robotics boards are designed to work directly with the DXL bus, you would need some modifications/additional components to connect an Arduino.

I can think of 2 valid approaches to the basic hardware architecture:

  1. use one MCU and have it do everything. In this case, there is a risk of having to do some substancial changes each time you use a sensor with different ressources requirement. This is the cheapest approach in terms of hardware but it can cost more in terms of software development and maintenance in the long run. On a 16MHz AVR, reading packets on a busy Dynamixel bus could easily take more than 50% of the processing time, and any timing-critical application would very quickly become a difficult piece of code.
  2. use 2 MCU, one as a Dynamixel bridge, and the other one as the application processor. Doing it like this has numerous advantages:
  • the Dxl bridge could be developped once (as a module for example) and re-used as-is. Bonus: decrease in manufacturing risk and cost.
  • the application MCU could be an arduino-compatible one (ATmega328p, 2560, 32u4, …etc), running vanilla Arduino code and accessing the other one through a lib
  • if they are connected through SPI, then we can put ICSP code in the DXL bridge and use that to reprogram the application MCU through the DXL bus, with code similar to the one I already use for the DXL-compatible bootloader.
  • the bridge MCU could handle communications faster than the App MCU, making it possible to use talk at 3Mbps despite the application code running on a 16MHz AVR (which starts to be very busy at 1Mbps and cannot speak at 3Mbps at all)

For the power question : a clean-ish, powerful, cheap power supply to deliver 5V / 3V3 to the module and whatever is connected to it would be necessary.
You really don’t want a big LDO regulator to provide power to your board, all the more if you want to put that thing into a battery powered robot or one with 3D printed parts (a LDO could easily produce enough heat to softened PLA under certain circumstances).
I already developed something like that, see the Dynext board files for a 1A version, and I have a smaller 0.5A version too that I need to publish.

What I am developing, and which is outlined in the link @Thot posted, is a Dynamixel-enable Arduino-compatible board. This way, you get the power of all Arduino libs and examples, the non-threatening feeling that goes with it (at the cost of an horrible IDE and bad coding practices, but who cares: “if it’s stupid and it works, it’s not stupid”) without the problems of sharing your code with the very demanding Dxl device code. That’s a huge amount of code that you do not have to maintain (contrary to the approach Robotis took with their IDE for the OpenCM9.04, where they basically cloned everything and now have to maintain everything…).
I’m doing it because I need it and I want it to be completely open-source / open-hardware. However it has lower priority than the projects I do for my clients, so every time I get a new contract it can stall progress for a few month…

2 Likes