AX-12 vs. RX-10 Protocol?

[tafoxx]

I'm writing a C++ library to control some RX-10 servos using the USB2Dynamixel adapter. I'm hoping to release it as open-source when it's mostly finished, because it's a crying shame that there's so much code for this servo available for Windows and hardly any for Linux. I noticed this forum is mainly focused on the Bioloid robot, which is built with AX- servos. Does anyone happen to know if the AX (or even DX) Dynamixel servos use the same protocol as the RX ones do?
Oh, and the same goes for the CM-5 controller. Does it work in a completely different way, or can it provide the same "virtual serial port" interface to the servos as the USB2Dynamixel does?

Thanks for the help. I'm hoping to get this code just about finished in the next week or so, and it would be really great if it could work "out of the box" with any Dynamixel.

[limor]

Hi, Thanks for posting.
We welcome any such initiative!

All the Robotis servos use the same Dynamixel protocol.
AX12 uses UART over 1-wire.
The rest use UART with 2 wires.
The advantage in theory is that 2 wires allows sending and receiving packets in parallel hence providing twice the speed and efficiency when doing closed-loop control. I'm not sure if this was tested and talked about here by community members.

CM5 and its ATmega128 are used as a brain with memory for the robot. You program the CM5 from the PC and then it acts autonomously (yes you can put there wireless interface and do all or some of the processing from a remote or local PC). If you use the USB2Dynamixel, the PC is the brain. CM5 doesnt have a USB interface.

[RandomMatt]

AX12 uses UART over 1-wire.
The rest use UART with 2 wires.
The advantage in theory is that 2 wires allows sending and receiving packets in parallel

I don't think this is quite right. I thought that:

* The AX12 uses TTL over 1-wire (1 is encoded as 5v, 0 as 0v).
* The rest use RS485 over 2-wires (1 is encoded as D+ with a bigger voltage than D-, 0 as D- with a bigger voltage than D+)

Therefore, the software is the same, and all dynamixel devices are half-duplex.

the advantage of RS485 / differential signalling is that you can use much longer cables without problems (and twisting the pair of data wires will help even more)

[i-Bot]

RandomMatt is correct the protocol for the RX/DX is the same as the AX. The difference is only in the electrical interface.

The AX uses a single signal wire at CMOS levels. The RX/DX uses a differential signal over two wires. Differential signal have the advantage that if the ground rail shifts ( due to heavy current and voltage drop on the ground wire) this does not damage the signal.

Signalling is still half duplex and data rates are the same for either type.

USB2Dynamixel supports both signal types on different interfaces.

CM5 supports only the AX servos, use CM2 for RX/DX

[limor]

thanks for clarifying the different RX and TX voltage levels' positive effect on communications when using longer cables.

It is true that Dynamixel is supposed to be half duplex. But when RX and TX are independent on the FTDI, PC, and servos *i think* you then have 2 independent transmission busses.
Meaning you can send a packet to servo-1 and without waiting for response, send another packet to servo-2. The servo-1 will respond after X milisecs according to the Delay-response register, followed by the servo-2 response packet (assuming they have the same Delay-response value). So effectively you can acheive full-duplex when talking to more than one servo.

[i-Bot]

The Dynamixel bus is truly half duplex, whether it uses one wire or two wire differential signalling. The same common wires/wires are used for both transmit and receive. The USB side of the USB2 Dynamixel is of higher speed and has buffers, so can make that side appear to be duplex, but again USB bus protocol is half duplex.

I am cautious on the return delay, it seems to be define the minimum delay, not the actual delay before response. This ensures the master has time to turn its buffers round.

The most interesting idea for speeding up the Dynamixel bus came from Stuart and Matt, who proposed a sync read command similar to the sync write. By snooping the bus for replies from other servos each servo knows when to send its reply. Needs special servo software though.

[tafoxx]

Wonderful news. So, if I understand it correctly, the communications hardware is different for each one, but the software protocol is the same... thus, when using the USB2Dynamixel, it should work the exact same way whether communicating over RS485, RS232, or TTL?
And the CM5 and CM2 have a "passthrough" mode to allow the same type of direct communication?

[limor]

yes. same communication protocol.
passthrough - don't recall that there is an example firmware that provides "passthrough" but it is very simple to write this code and flash the board with it.

[RandomMatt]

yes. same communication protocol.
passthrough - don't recall that there is an example firmware that provides "passthrough" but it is very simple to write this code and flash the board with it.

libbioloid's supervisor can do it - it is called bridge mode.

Out of the box it isn't a fantastic solution as the PC UART is driven at 57600baud (while the Dynamixel UART is run at 1Mbit) - but that it trivial to change. left as exercise to reader - cm5_init()

[Mandor]

I'm writing a C++ library to control some RX-10 servos using the USB2Dynamixel adapter. I'm hoping to release it as open-source when it's mostly finished, because it's a crying shame that there's so much code for this servo available for Windows and hardly any for Linux. I noticed this forum is mainly focused on the Bioloid robot, which is built with AX- servos. Does anyone happen to know if the AX (or even DX) Dynamixel servos use the same protocol as the RX ones do?
Oh, and the same goes for the CM-5 controller. Does it work in a completely different way, or can it provide the same "virtual serial port" interface to the servos as the USB2Dynamixel does?

Thanks for the help. I'm hoping to get this code just about finished in the next week or so, and it would be really great if it could work "out of the box" with any Dynamixel.

Hi. I've also a c++ lib for Linux to use the usb2dynamixel. I will release it someday but if you need some help, I can send you the code.

[tafoxx]

I'm mostly finished, actually, but I am curious... how did you end up designing it? I decided early on that it would be impractical for multiple objects to share the same serial port, and just wrote a single class to control all the servos connected on one line. It worked out pretty well, but it's a little awkward having to pass the servo ID to just about every single function. I'm also not sure how much information to keep about the servo state--it would be a bit redundant to store all the servo registers for every servo in the controlling class, but then I have to worry about whether to expect status return packets, or whether the servo is in "endless turn" mode or not.
How did you end up addressing those issues?

(Oh, and just the other day I found a few mistakes in the manual. That was fun.)

[RandomMatt]

(Oh, and just the other day I found a few mistakes in the manual. That was fun.)

Okay, my turn to be curious - what were the mistakes in the manual? I'm now in panic - i hope i haven't produced a rubbish libbioloid - mode!

(As an aside it sounds like you've written an imperative program in an object - rather than an object oriented program. For libbioloid I used C, so I didn't even bother with the object!)

Matt

[tafoxx]

Two things, both pretty small, and one of them was an error of omission. But there could be more that I haven't found... I haven't tested everything.
*The overload error only seems to be triggered if the servo's maximum capacity is overloaded, not the Max Torque value. It seems to me like that would make it much less useful...
*The value of the "Present Speed" registers also returns the direction of movement in the tenth bit, like Present Load.

And yeah, my code isn't terribly "object-oriented"... but I couldn't figure out a better way to do it, if all the servos were to be controlled over the same serial port. Plus I figured they would all share the same interface anyway, and there really isn't much of a need to store data about individual servos.

[RandomMatt]

Two things, both pretty small, and one of them was an error of omission. But there could be more that I haven't found... I haven't tested everything.
*The overload error only seems to be triggered if the servo's maximum capacity is overloaded, not the Max Torque value. It seems to me like that would make it much less useful...
*The value of the "Present Speed" registers also returns the direction of movement in the tenth bit, like Present Load.

The first is news to me... but then I have never seen an overload error - so I'm obviously doing it wrong (Now I use my own servo firmware, so i'm never going to notice what the AX12s do)
The second, now you say it, I remember finding out for myself!
There is a third... the load reading (on a stock AX12) is next to useless.

[tafoxx]

I was only able to trigger an overload error once. Every other time the servo overpowered me, and sometimes it pinched my finger just for good measure.
I wouldn't recommend trying to overpower the AX-12s, though. I think those have plastic gears.

It seems that the present load value gives nonsense unless torque is enabled. Once it's enabled, it gives okay results, although not terribly precise, and occasionally it gets stuck returning the value of 64 after the load is removed. Interestingly enough it only seems to get stuck at a clockwise 64, never counterclockwise...