Trouble with communicating with dynamixels continously

[rikkov]

Hi Guys,

I am using USB2Dynamixel to control a robot made using 8 RX series Dynamixel servos via computer. I am facing a problem of incorrect/corrupt read sometimes.

Its like sometimes when I read the data from the servos in my robot, the packet that the servos send me are corrupt with wrong header(0xFF 0xFF) and checkum.So the "read fails" in my program. Once a read fails all the read occuring after that keeps failing with the same error. But if unplug and replug the signal line to the robot, the read gets re-established and works fine till the error occurs next time.

I later found that flushing of USB2Dynamixel, when the read fails helps to re-establish the read. It would be really great if someone could advice me with a solution to this problem. I would like to know why this problem occurs in the first place.

I would also like to knwo if I am missing out on setting some prameters for USB2Dynamixel.

Thanks a lot,
Rikkov

[i-Bot]

In any configuration of long cables and high electrical noise( servos ), errors can occur. That is why there is a dynamixel packet protocol established and checksums added.

What program are you using the talk to the dynamixels ? A good program will incorporate error detection and recovery. Reception should always start with a proper sync search (0xff, 0xff) before interpreting packet content. Packets with checksum error should be rejected, and retried. Also when no valid response packet is received after 100 ms it should be retried

[billyzelsnack]

How often are you getting errors? I've been troubled by random errors with my custom interfaces too. I get an error every couple hundred reads.

I've dealt with the errors by making my code more robust and to just retry when any errors occur. I also always flush both read and write before a read. In the future I want to make my packet parsing a little smarter so it can detect errors earlier and not rely so much on a timeout.

btw. I believe my current timeout is set at 50ms which really is forever, but USB latency really sucks.

[Bullit]

Having worked with most of the different flavors of Robotis servos I can say there is is big difference in communication reliability from TTL to RS485. The TTL servos are prone to all sorts of communications issues. Given that we're talking a single ended, unloaded ttl signal that is 1 mhz on an unshielded network near a bunch of motors and in motion we should be surprised it works at all. The RS485 still has errors but they are considerably more rare.
Rule of thumb: errors happen, clean them up.
As mentioned earlier that's what protocols are for.

[rikkov]

Thanks a lot for the fast reply!!

I am using a program that we guys wrote,it just keeps writing and reading data to and from dynamixels at 6.9 Hz(for 8 servos).

So as you guys suggested I guess I will have to keep flushing things after each write-read cycle.

Thanks,
Rikkov

[MikeG]

rikkov the ideal solution is to fix your receive code so it can gracefully recover. I buffer the received status packets, parse and frame the status packet, discard any bad data, handle the bad data.

[Bullit]

A very important piece of the packet processing framework needs be to resynchronization. A state machine that while waiting for new packets eats bytes until it gets the 0xff 0xff indicating the start of a new packet can be a good solution.

[ryann2k1]

Hi All,
I am working now reading the data from dynamixel. with the same circuits, I managed to send data to the dynamixel, but when reading the data, I hardly can grab the data, only the two FF-FF, then the rest is gone.

Any suggestion will be appreciated.

Thank you.

Cheers,

Ryann2k1

[MikeG]

Sounds like you have a bug in your code, an error in your circuit, or possibly a bad... AX or RX-XX?

No way to tell from your vague post.

Circuit?
Source code?
Did it ever work?

[ryann2k1]

Hi Mike,

I am using the UART signal to Half duplex type selector circuit on AX-12 manual page 7.
the programming part :
void terima_serial()
{
while(!UCSRA.7); //Until RXC = 1
datarx [i] =UDR;
UCSRA.7 = 1; //Reset RXC with 1
}


//reset
void reset ()
{
DDRA = 0xFF;
PORTA = 0x00;
}

//direction port
void dp_terima()
{
DDRA = 0xFF;
PORTA = 0x80;
}

void dp_kirim()
{
DDRA = 0xFF;
PORTA= 0x40;
}

Function for reading status:

void baca_read_only1 ()
{
putchar(0xFF);
putchar(0xFF);
putchar(0x01);
putchar(0x04);
putchar(0x03);
putchar(0x10);
putchar(0x01);
putchar(0xE6);
}

The baudrate setting is 115.2 Kbps with clock from crystal 11,0592 MHz for the microcontroller 8535 and the baudrate of the motor is 115.2 Kbps. should it be set to 1 Mbps?
Any idea?

Cheers,


ryann2k1

[MikeG]

I can't make heads or tails of what you're trying to do. The instruction is writing a 1 to the status return register? Why?

AX-12 come from the manufacturer set to 1Mbps. Unless you changed it to 115.2, it's still set to 1M.

May I suggest that you try lighting the LED on ID 1? That's like the Hello World for AX-12s. If you get the LED to light then you know the connection is good and you can work on capturing the status packet.

[ryann2k1]

Hi Mike,

My program and circuit work fine when sending any command to dynamixel. I can move the motor to a certain position, I can access the led, etc. But the problems occurred when trying to read the data from dynamixel, I just can get the two FF-FF, while the rest is missing.

Any suggestion?

ryann2k1

[MikeG]

Sorry; don't know... probably your receive code is has a bug. Maybe someone with better AVR skills can help you debug your code.

[Fritzoid]

Hi Ryan,

Like Mike said, so far you've shown only shown us the code for a write command. Let's see your read command. Also you've shown us the subroutines, but not the calling sequence. What does main control loop look like?

Finally, the AX-12 manual schematic shows the port direction controlled by a single bit. Yet, your dp_termina() and dp_kirim() are toggling two different bits. Which port is actually connected to the 74HC04? Or is your circuit different, i.e. no inverter at all? We need to know a little more about your hardware setup to be certain the problem isn't in the circuit.

[Fritzoid]

I gave your code another look and this line bothers me...

UCSRA.7 = 1; //Reset RXC with 1

Try commenting-out this line. The RXC flag should be reset by the previous instruction which reads the data from the USART receive buffer (assuming it's now empty). Your code doesn't need to and shouldn't try to set or reset this flag. Could lead to lost data!