Dynamixel Devices

[Xevel]

Hi,

In another thread, I briefly touched on the Dynamixel Devices that I was working on.

First, the idea is not new. Creating a board that can be connected to a Dynamixel bus and used to expose a sensor or actuator has been done multiple times, from the Dynamixel IO Board and IMU boards by HUV Robotics, to multiple closed source ones that have never been talked about freely, to my own multiple attempts (4 already). But so far nothing stuck, and it’s still not possible to buy one anywhere.

The appeal is easy: add sensors or other actuators anywhere on your robot with one simple 3 or 4 cable interface to power and talk to all of them. No mess of cable, no diversity of connector or protocol.

Here are my new attempts: an IMU board named DXLD IMU, and an interface board DXLD Interface.
dxld is the name of my dynamixel device lib that I released last year (and which nobody gave a **** about), and these will use the new version of that lib.

They are as small as technically possible while keeping 2 right angle Dxl connectors (for low profile) and M2 mounting holes. When the cables are connected the volume taken does not go up, meaning that the 26mm long PCB is the same length as two connected male+female connectors.
I could have gone with a side-by-side arrangement instead and landed a 22x21mm form factor for the IMU one, but not for the interface.

DXLD IMU is 26x14mm, with M2 holes 22mm apart.
It has a MPU-6050, and that’s about it. lots of 1.27mm debug pads on the bottom though.
I made it mostly for Thot, with the idea to test a lot of things on his robots.

DXLD Interface is 24x15mm with M2 holes 20mm apart.
It has a 2x5 2.54mm header that can be plugged into a breadboard, or used directly to connect stuff to.
The pins are 12V, 5V (500mA thanks to a DC/DC converter), 3.3V, GND and 6 GPIOs that also multiplex as PWM, 4 ADCs, I2C, SPI and a serial port (it’s possible to use SPI + serial or SPI + I2C or serial+ I2C).
The first thing this board will interface with is a very lightweight Lidar that I have been working on too, and that will be the object of another post.

Both boards share the same architecture, same MCU (STM32F301, Cortex-M4 @ 72MHz with FPU, 3.3V) and same Dynamixel level converter and protection. It can talk on the bus at up to 3Mbps (maybe more, I’ll have to verify).

For now, they are aimed at the TTL Dynamixel bus used by the AX series and some MX, but I might make other versions.

With the USB2AX Pro, it’s possible to imagine having many, many of these in a robot and still be able to have a full-robot loop (get info from everything, send info to everything) that takes only a few ms.

[sonel]

This is a great idea. A couple of days ago I sent a order to OSH Park for some small add-on boards to an Arduino (mini, pro) board to test this too.

How do you program the chip?

I would definitely be interested in getting my hand on a few INTERFACE ones.

[Xevel]

Ho, I forgot to talk about that. Having to attach cables to the board or to isolate it from the robot is a pain, so I have other plans.

So the first part is to reprogram the MCU on the board itself. For that, I already have developed a bootloader that talks on the Dynamixel bus.
It it not the same as the bootloader used by the Dynamixel servos, I redesigned it to have a robust error control.
This bootloader talks with Dynamixel packets, so it can operate on the bus even at the same baudrate as other servos without any problem.
Right now, it is made for a LPC mcu, like the dxld lib, but porting won’t be a problem.
It can program a device in a few seconds.

The second part of the plan is to have a secondary MCU running user code in an Arduino-compatible board attached to the DXLD Interface. When this happens, then what I want to do is have the Interface act as a programmer and be able to program that User MCU through either its own bootloader, or directly by emulating ISP or SWD.
Add then a plug-in to the arduino IDE to make it straightforward to upload code transparently, and that would be it.
That part of the plan would probably look like a real arduino, just with DXL ports instead of USB, and is a further development.

And concerning your boards: I, and a few other people, have already done arduino-based dxl devices, and if you want some of these are open source. However, if it’s AVR based, the problem is that when the bus becomes saturated, it risks not have much processing time left to do its job.
Here, even with a massively loaded 3Mbps bus, it should still have a reasonable amount of cycles left for its own tasks.
Some people have made devices based on Teensy, and it works pretty well however.

[Xevel]

Ok so here are the things needed to do on the firmware front to have something that starts to be interesting.

1. Port dxld for STM32F301. This should be pretty straightforward, replacing the LPCopen lib with the STM32Cube F3
2. Move to DMA + interrupt to have all communication taken care of without spending time on it. I already have an interrupt-based version that I forgot to push.
3. Update the Dynamixel part to work in both Dxl 1.0 and Dxl 2.0. Right now the lib is Dxl1.0 only, but I intend to have it do both, and maybe at the same time if there is no problem with the table.

There might be a hack to do to work without eeprom, by writing to FLASH instead. I’ll probably reserve 1024B of FLASH for two 512B copies of the table, I’ll have to see. Maybe add an EEPROM chip later otherwise.

I might have a better look at making it compatible with the koduino port of the Arduino libs too, not sure yet.

Concerning the bootloader, it will have to be partly re-written too.

The way the Dynamixel servos do updating or recovery is to have the servo reboot, then blast ‘#’ on the line at 57600bps (which is the baudrate used by the bootloader) until the device enters programming mode. The protocol is then very simple but not compatible with Dynamixel packets: nothing guaranties that there won’t be a string of characters that will look like a Dxl packet, it only hopes that having a (probably) different baudrate will be enough to isolate the bootloader communication from the other servos on the line.
If there are other servos talking at 57600bps too, and you are unlucky enough to have a string of characters that look like a Dxl command aimed at one of them, then the transfer might be corruptd by the error status packet of that servo, and aside from saying “it did not work” at the end, the botloader will not do much.

Mine is different: It talks with valid Dynamixel packets, and uses escape sequences to make sure that there are never two consecutive 0xFF in the transfered data. It also uses IDs for each each data packet, and acknowledges them, so that any case - save for an total loss of communication - results in a successful transmission of the firmware.

If anyone is keen to help I’ll hurry on publishing the code and more info - other wise I’ll just take my time, I have lots of things going on and no real priority.

[sonel]

I’m definitely interested. There are a bunch of things that I would prefer to have operating on the Dynamxel bus instead of being directly connected to the main controller (ex. Raspberry Pi). For instance these displays work on standard UART for sending commands and are a very appealing solution for a display in the head without the need to have the whole controller there - but lower in the chest (lowering the COM and reducing the torque requirements on the servos in the legs).

There is also this camera that is too expensive right now and only supports communication 1.0 meaning it is hard to integrate with XL-320 and the new XM/XH Servos.

Regarding the implementation of Communication 1.0 vs. 2.0 I’ve noticed the new servos from Robotis (XM, XH) have a registry (address 13) that can be used to switch between them. Maybe that’s an easier way to implement it.

[Xevel]

Hmmm yeah why not, though both camera and screen might need a big part f the bandwidth to operate. I guess we should just try.

For the Havimo, using Dxl1.0 alongside Dxl2.0 packets is not a problem, they each filters the other out. What is more of a problem for XM/XH is that it’s TTL only.
It’s a shame the HaViMo is not open source, because it could be upgraded to 3Mbps, RS485 and DXL2.0…

And concerning Dxl1.0 vs Dxl2.0, making the device talk both at the same time (so it would answer in the same protocol that it has recieved) should not be a problem, and maybe easier for users (one less thing to worry about), just plug it and talk to it.

---

Also, few days ago I found something annoying about the new XM/XH servos.

They use the MAX14783EESA (or at least the ones I have, which are the last beta before release).
From the datasheet of this component:

The IC has a 1-unit load receiver input impedance, allowing up to 32 transceivers on the bus.

For comparison, the driver used in RX-28 is the MAX3443EESA, for which the datasheet says:

The 1/4-unit-load receiver input impedance allows up to 128 transceivers on a single bus.

I do not have a MX-28R to verify ,but if anyone around here has one, I would really like to know if they kept the one from the RX, used the same one as the XM/XH, or used a different one altogether.

For my RS-485 devices, if I ever make some, I will go with a 1/8 unit load driver to avoid loading the bus needlessly. I found the LTC2859CDD which is reasonably priced, small, and has good specs (20Mbps, 3x3mm DFN, with switchable termination resistor, 1.65€/pc/100).

[Xevel]

Here is what they look like when assembled :

Lot more pictures, including the other projects I stuffed on the same PCB panel : https://goo.gl/photos/49VdDNXw41NjZAnB9

There are already some details I’m not a fan of before even powering them:

• big 10pins connector on DXLD Interface is too high for something with M2 fixation holes
• capacitor choice on power rails is not the best. At first I put ceramic ones, but between all the de-rating (voltage bias reduces their effective capacity by about 70 to 80% in this case) and the high price, I will need another solution. I temporarily put some tantalum in the meantime.

Next step, bringup (= powering up and writing the basic firmware to test everything)!