Missing bytes in AX12 response-packages
Missing bytes in AX12 response-packages
by sirhoop
Wed May 14, 2008 4:25 pm
Hi.
I am currently building a communication library for the bioloid, that lets me control it in toss-mode. In toss-mode the cm5 becomes transparent, so I can send real dynamixel-packages to the serial port. It's just like communicating directly to the ax12s.
I run the communication at 57600 bps and it's pretty fast. For example when the time from sending a command to completely receiving the response is something like 2.7 ms. I measured these times with an oscilloscope.
But building up a complex architecture that could manage response messages for every command I experienced strange errors. Sometimes I'm getting wrong responsepackages even if I wait between commands 1 second. Once again we used the oscillioscope to check for the response messages and we found out that indeed sometimes there are bytes missing in a response message.
So let's have a closer look on how such a response should look like.
For example if I sent a move command to AX12 with id 0 I should get the following package:
FF FF 00 02 00 FD
00 - id
02 - length
00 - error (everything's ok)
FD - checksum
but sometimes I only get
FF 00 02 00 FD or 00 02 00 FD or even FF 02 00 FD
I could not find no determinism in when a package is broken. It just happens from time to time. Somebody has described the problem before, but I thought I let you know that we proved it now by measuring the serialport. Does anybody know why that happens or how I can prevent it.
We think it's a problem of the CM5. Perhaps it has problems synchronizing the different communication speeds (cm5-pc: 57600 bps, cm5-ax12: 1Mbps).
So especially I would like to know if the same problems occur if you are using the USB2Dynamixel?
best regards,
Alex
I am currently building a communication library for the bioloid, that lets me control it in toss-mode. In toss-mode the cm5 becomes transparent, so I can send real dynamixel-packages to the serial port. It's just like communicating directly to the ax12s.
I run the communication at 57600 bps and it's pretty fast. For example when the time from sending a command to completely receiving the response is something like 2.7 ms. I measured these times with an oscilloscope.
But building up a complex architecture that could manage response messages for every command I experienced strange errors. Sometimes I'm getting wrong responsepackages even if I wait between commands 1 second. Once again we used the oscillioscope to check for the response messages and we found out that indeed sometimes there are bytes missing in a response message.
So let's have a closer look on how such a response should look like.
For example if I sent a move command to AX12 with id 0 I should get the following package:
FF FF 00 02 00 FD
00 - id
02 - length
00 - error (everything's ok)
FD - checksum
but sometimes I only get
FF 00 02 00 FD or 00 02 00 FD or even FF 02 00 FD
I could not find no determinism in when a package is broken. It just happens from time to time. Somebody has described the problem before, but I thought I let you know that we proved it now by measuring the serialport. Does anybody know why that happens or how I can prevent it.
We think it's a problem of the CM5. Perhaps it has problems synchronizing the different communication speeds (cm5-pc: 57600 bps, cm5-ax12: 1Mbps).
So especially I would like to know if the same problems occur if you are using the USB2Dynamixel?
best regards,
Alex
Communication
by JavaRN
Wed May 14, 2008 4:55 pm
It is the same problem I experienced with the zigbee wireless module I'm still trying to find what is wrong.
F'dan il-passatemp ghandek bzonn zewg affarijiet - FLUS u HIN. Zewg affarijiet li huma skarsi hafna u li jien minnhom ghandi vera ftit!
by siempre.aprendiendo
Wed May 14, 2008 7:02 pm
It's strange... I have never met this problem...
I have been doing several test programs to communicate Pocket PC, Windows and Ubuntu with the CM-5, in C/C++, C# and a few tests with Lego NXT and Java. I have used the serial port and the USB2Dynamixel, sometimes "stressing" the communications using "synchronous with different delay times, burst and polling methods...
I have been doing several test programs to communicate Pocket PC, Windows and Ubuntu with the CM-5, in C/C++, C# and a few tests with Lego NXT and Java. I have used the serial port and the USB2Dynamixel, sometimes "stressing" the communications using "synchronous with different delay times, burst and polling methods...
by sirhoop
Thu May 15, 2008 1:09 pm
@ le fatumbi:
No it's not the same problem. The problem described in your link concerns missing parameters, and those parameters are missing all the time. It is obviously a bug. But my problem is different. Most of the time it works fine, but sometimes one or two bytes (mostly the first ones) are missing.
@StuartL:
Yes I also thought of a bufferoverflow, but we waited 1 second between move-commands. So that would be an argument against this thesis.
How can I use the USB2Dynamixel to control the whole humanoid, for it has only one ax12-bus-connector. Or is there another possibilty to send command directly from the serialport to the ax12s.
No it's not the same problem. The problem described in your link concerns missing parameters, and those parameters are missing all the time. It is obviously a bug. But my problem is different. Most of the time it works fine, but sometimes one or two bytes (mostly the first ones) are missing.
@StuartL:
Yes I also thought of a bufferoverflow, but we waited 1 second between move-commands. So that would be an argument against this thesis.
How can I use the USB2Dynamixel to control the whole humanoid, for it has only one ax12-bus-connector. Or is there another possibilty to send command directly from the serialport to the ax12s.
by StuartL
Thu May 15, 2008 3:25 pm
Waiting one second between commands doesn't help the buffer overflow problem, it's the rate at which the CM5 is receiving the data that's the problem.
If there's a buffer bug (we had one in our library for a long time without noticing) it could be unpredictable and weird in its symptoms. If they're using a ring buffer, for example, the problem could occur as an off-by-one error on the wrap-around of the ring buffer. Our problem wasn't dissimilar to this, it was a race condition during interrupt handling causing the library to lose track of the byte it was sending for a few machine cycles and ended up retransmitting the whole packet halfway through the original retransmission.
With regard to the USB2Dynamixel, just cascade the Dynamixels like you would normally. The 'bus' is just that, a bus. Therefore if you can provide the current into the connector that your Dynamixels need to operate just daisy chain them as necessary. The 6-way star connector is very useful in this regard.
If there's a buffer bug (we had one in our library for a long time without noticing) it could be unpredictable and weird in its symptoms. If they're using a ring buffer, for example, the problem could occur as an off-by-one error on the wrap-around of the ring buffer. Our problem wasn't dissimilar to this, it was a race condition during interrupt handling causing the library to lose track of the byte it was sending for a few machine cycles and ended up retransmitting the whole packet halfway through the original retransmission.
With regard to the USB2Dynamixel, just cascade the Dynamixels like you would normally. The 'bus' is just that, a bus. Therefore if you can provide the current into the connector that your Dynamixels need to operate just daisy chain them as necessary. The 6-way star connector is very useful in this regard.
some tests
by sirhoop
Thu May 22, 2008 1:13 pm
I did some tests to estimate the error rate. What I did was sending 100 commands for every servo. So in the end 1800 command and for every command I wait for the response packages before sending the next one.
That test took about 14 seconds, so that the command rate was 128 Hz for the robot and 7 Hz per servo. Pretty bad, I know. But what makes it worse is about 5-6 % of the responsepackages were incomplete.
Now I am handling bad response packages by sending the command again, until the responsepackage is ok. It works quite well.
Since I don't need response messages for movement, I now use sync write. I allways send a move command to every servo. With sync write I can control the servos with about 53 Hz. The 1800 instruction took only 1.86 seconds.
I asked Robotis about the problem of the missing bytes, but did not get an answer yet.
That test took about 14 seconds, so that the command rate was 128 Hz for the robot and 7 Hz per servo. Pretty bad, I know. But what makes it worse is about 5-6 % of the responsepackages were incomplete.
Now I am handling bad response packages by sending the command again, until the responsepackage is ok. It works quite well.
Since I don't need response messages for movement, I now use sync write. I allways send a move command to every servo. With sync write I can control the servos with about 53 Hz. The 1800 instruction took only 1.86 seconds.
I asked Robotis about the problem of the missing bytes, but did not get an answer yet.
by limor
Tue May 27, 2008 4:41 pm
siempre.aprendiendo wrote:It's strange... I have never met this problem...
I have been doing several test programs to communicate Pocket PC, Windows and Ubuntu with the CM-5, in C/C++, C# and a few tests with Lego NXT and Java. I have used the serial port and the USB2Dynamixel, sometimes "stressing" the communications using "synchronous with different delay times, burst and polling methods...
Hi, please share some of your code
by siempre.aprendiendo
Tue May 27, 2008 7:37 pm
limor wrote:siempre.aprendiendo wrote:It's strange... I have never met this problem...
I have been doing several test programs to communicate Pocket PC, Windows and Ubuntu with the CM-5, in C/C++, C# and a few tests with Lego NXT and Java. I have used the serial port and the USB2Dynamixel, sometimes "stressing" the communications using "synchronous with different delay times, burst and polling methods...
Hi, please share some of your code
Yes, I will share it, but before I want to do some "cleaning"
