PDA

View Full Version : Dynamixel MX drops off the bus for 130 microseconds?



jwatte
12-29-2012, 02:29 PM
I'm talking to an MX-64T from an Atmega 32u4. I set the return delay time register to 5, which should mean 10 microseconds. I run with baud rate register set to 0, meaning 2 megabit speed.

However, for a long while, I was seeing all kinds of problems, because my talking loop would randomly/spuriously detect errors and wedge the communications.

After a long while of debugging my code, it seems that just increasing the timeout before deciding the other end is not responding "fixes" the problem. Here's a capture from one such instance, where there is a surprisingly long delay (about 130 microseconds) between the first and second "FF" byte in the preamble of the response from the servo:


4395

On the left, you can see my command (don't pay attention to the pin labels -- yellow channel 4 means "in transmitting mode" and black channel 0 is the actual TTL serial bus.)
Then you can see the first FF from the Dynamixel, followed by a LOONG pause, followed by the second FF and the rest of the packet.

Is this normal? Is there a defined/documented upper limit to how long I might need to stay in the busy-wait before I can say with certainty that the other end isn't going to answer?

Edit: It seems the forum resized my screen shot a bit. The original is here: http://watte.net/dynamixel-130-us-stall.png

tician
12-29-2012, 04:25 PM
I'm not sure how much of an effect the "return delay" values actually has on anything. It is still going to take some amount of time for the servo to retrieve whatever information you want and build the packet (and still perform motion control). All of the code robotis has ever provided builds the entire packet before it begins sending it, but the servos may send the first byte before they finish building the entire packet (although I'm not sure that would take 130us even on an ATmega88). The robotis provided dynamixel sdk and embedded-c examples all use a timeout for the entire packet instead of just a single byte. The delay I had to use for really reliable communication at 1Mbps on the CM-530 was ~30us * number of bytes in the packet (either length of data to be returned plus 6 or just 6 for a status packet) (pretty sure that was also with AX-12 and not an MX).

jwatte
12-29-2012, 11:04 PM
Thanks for the data. Given that I usually will be talking to servos I know to be there, I decided on an 800 microsecond overall timeout. This means that the worst case is pretty bad (my control needs to service interrupts every 1 ms, and reading the response is in a spin loop) but I haven't seen anything worse than the 130 us so far, so "it's probably mostly good."
Lucky I'm not building a space shuttle here :-)

Xevel
12-30-2012, 03:11 AM
The AX servos have a similar problem, where you can have a pause between any two bytes of the response (I can't remember how long it takes but it might be similar). While I never found out the _exact_ reason, I guess it has to do with the interrupt they use for the control loop.

You ask for an upper limit about the delay you have to wait to be sure it has timed out: in the documentation, the only information we have is that the servos use a timeout of 100ms between two byte. The thing is: this is how long the devices will wait, they never say how long the master should wait for an answer. I personally often use 1ms. If the servo has really dropped out, then you have a bigger problem than just communication anyways (need to troubleshoot why), and if the servo works OK, it will answer in far less time than that (at 1Mbps).

About the Return Delay, unless you have a very slow Dynamixel master, it seems to me that you can safely put it to 0. And anyways, this parameter changes how long the servo waits before it begins transmitting, nothing else that I know of.

jwatte
12-30-2012, 03:42 PM
this parameter changes how long the servo waits before it begins transmitting, nothing else that I know of

That seems fair. The default value is something ridiculously high (like half a millisecond.) I assume the reason it exists at all is to allow the master to turn around the bidirectional UART. I'm using an Atmega32u4, and there are a few register bits to poke at to make sure I flush out the "ghost receive" I get from the data I send myself, so a few microseconds of guaranteed silence is helpful. 10 us may be too much.
It's a "feature" of the Atmega UART that the transmitter cannot be used without enabling the receiver, so after transmitting, you have to poll the data register to make sure you receive the last byte you transmitted, if you tie the two to the same line.

Xevel
12-30-2012, 10:20 PM
It's a "feature" of the Atmega UART that the transmitter cannot be used without enabling the receiver, so after transmitting, you have to poll the data register to make sure you receive the last byte you transmitted, if you tie the two to the same line.

Never eared of that. I use the ATmega32u2 for the USB2AX, and there is no problem enabling the transmitter while the receiver is disabled. I use the Transmit Complete interrupt after the last byte to switch from transmitting to receiving, and it takes about the same time as sending one byte. At high baud rates, there is simply no way the servo would have finished interpreting the message and started answering in so little time.

tician
12-30-2012, 11:22 PM
Definitely not a feature of the ATmega88/168/328 and ATmega644p UARTs, since the ability of the arbotix to communicate with 'TTL' dynamixels is based solely on alternately switching between TX-only and RX-only modes (make both TXD and RXD inputs with pull-up enabled, then when active the TX functions override as an output driver for a little bit until disabled again). If it is new to the ATmega16/32U4, I would definitely consider that a microsoft scale 'feature', and I'm not really seeing any mention of it in the datasheet (7766 - 11/10).

jwatte
12-31-2012, 01:38 AM
Never eared of that

You are right! I could have sworn I read that in the data sheet, and that's why I wrote that code, and now I can't find it.
Maybe it was in the USART-as-SPI section or something... but the good news is, I can simplify my code -- thanks! :-)

tician
12-31-2012, 02:02 AM
You are right! I could have sworn I read that in the data sheet, and that's why I wrote that code, and now I can't find it.
Maybe it was in the USART-as-SPI section or something... but the good news is, I can simplify my code -- thanks! :-)
Having a part that requires the receiver to always be turned on does sound really familiar for some reason. I've scanned through way too many data sheets the last several years to be sure where (how I wish my brain had a useful garbage collector). It might have been something about using the USI on the ATtiny series.


edit: Hmm. USART in SPI mode is the opposite, with transmitter required and receiver optional.


Using the USART in MSPI mode requires the Transmitter to be enabled, i.e. the TXENn bit in
the UCSRnB register is set to one. When the Transmitter is enabled, the normal port operation
of the TxDn pin is overridden and given the function as the Transmitter's serial output. Enabling
the receiver is optional and is done by setting the RXENn bit in the UCSRnB register to one.
When the receiver is enabled, the normal pin operation of the RxDn pin is overridden and given
the function as the Receiver's serial input. The XCKn will in both cases be used as the transfer
clock.