AX12 inconsistent return delay
AX12 inconsistent return delay
by RicardoMarinheiro
Thu Sep 30, 2010 1:44 pm
Set the return delay to 1. supposedly 2us.
then i send get position query packet continuously. sending, waiting for return packet, sending, waiting etc.
The following table shows a sample of return delays. The ones on the CM5 are associated with my firmware. My delays in the CM5 code are pretty consistent around 12us but AX12 return delay is not very consistent. in some cases the packet is not sent back in once continuous stream but is split up and the last byte or two sent after like 80us.
<table><tr><td>CM5 delay (us)</td><td>AX12 delay (us)</td></tr><tr><td>11.85</td><td>33</td></tr><tr><td>12</td><td>33</td></tr><tr><td>12.12</td><td>27.5</td></tr><tr><td>11.5</td><td>28.62</td></tr><tr><td>12</td><td>109.62</td></tr><tr><td>11.87</td><td>28.5</td></tr><tr><td>12</td><td>28.25</td></tr><tr><td>12.25</td><td>31.62</td></tr><tr><td>12</td><td>35.125+84(last byte delayed)</td></tr><tr><td>11.87</td><td>28.5</td></tr><tr><td>12.15</td><td></td></tr></table>
Here is a sample screenshot from the Saleae USB analyzer:
then i send get position query packet continuously. sending, waiting for return packet, sending, waiting etc.
The following table shows a sample of return delays. The ones on the CM5 are associated with my firmware. My delays in the CM5 code are pretty consistent around 12us but AX12 return delay is not very consistent. in some cases the packet is not sent back in once continuous stream but is split up and the last byte or two sent after like 80us.
<table><tr><td>CM5 delay (us)</td><td>AX12 delay (us)</td></tr><tr><td>11.85</td><td>33</td></tr><tr><td>12</td><td>33</td></tr><tr><td>12.12</td><td>27.5</td></tr><tr><td>11.5</td><td>28.62</td></tr><tr><td>12</td><td>109.62</td></tr><tr><td>11.87</td><td>28.5</td></tr><tr><td>12</td><td>28.25</td></tr><tr><td>12.25</td><td>31.62</td></tr><tr><td>12</td><td>35.125+84(last byte delayed)</td></tr><tr><td>11.87</td><td>28.5</td></tr><tr><td>12.15</td><td></td></tr></table>
Here is a sample screenshot from the Saleae USB analyzer:
by i-Bot
Thu Sep 30, 2010 2:18 pm
There is indeed a delay of around 50us (maybe 80, it is a long time since I measured it)added to the AX12 return delay, this occurs at random and appears to be based on some internal interrupt process in the AX12.
The return delay parameter is only the minimum delay, not the actual delay.
The return delay parameter is only the minimum delay, not the actual delay.
by Fritzoid
Thu Sep 30, 2010 2:26 pm
Ricardo,
What you are seeing is pretty much the best you can expect in these circumstances. There is a minimum response time of around 25-30 us. as you can see. This is the overhead to process the incoming packet and generate the outgoing response. As a result, a return delay setting below 30 us. is functionally ignored.
The servo firmware itself is interrupt driven and must priodically respond to requests from the USART, the AD converter, and various timers. After all, the firmware's main function is to run its PID control loop. The interrupt routines can preempt any code that might be creating outgoing packets and that will result in exactly the type of delays that you are seeing. And this is the "best case" scenario!
By the way, I like the way your protocol analyzer displays the hexadecimal translation along with the pulse data!
What you are seeing is pretty much the best you can expect in these circumstances. There is a minimum response time of around 25-30 us. as you can see. This is the overhead to process the incoming packet and generate the outgoing response. As a result, a return delay setting below 30 us. is functionally ignored.
The servo firmware itself is interrupt driven and must priodically respond to requests from the USART, the AD converter, and various timers. After all, the firmware's main function is to run its PID control loop. The interrupt routines can preempt any code that might be creating outgoing packets and that will result in exactly the type of delays that you are seeing. And this is the "best case" scenario!
By the way, I like the way your protocol analyzer displays the hexadecimal translation along with the pulse data!
by RicardoMarinheiro
Thu Sep 30, 2010 3:19 pm
i-Bot wrote:I see your trace says roboard. Which Roboard ports are you using ?
Using USB2Dynamixel. the reason i'm not connecting directly to RS232 on RoBoard is that I hoped to be able to talk to CM5 at 1mpbs but turns out that CM5's RS232 chip is limited to 122kbps. planning to replace that chip at some stage.
by limor
Mon Oct 04, 2010 10:10 pm
Seems like there somewhat more consistent servo behavior when upgrading the AX12 firmware to version 24 (latest) using the RoboPlus Dynamixel Wizard software.
We have here in the lab a mix of the old (2006) AX12 servos and the current AX12+. Even after upgrading to the latest firmware, it seems that doing this fast "SYNC_READ" sequence is not liked by the old AX12 servos. One effect is getting errors in the response packets. In the example below you can see 2 sequences of position-request packet followed by a reply packet (servos 02 is AX12+ and servo 0B = 11 is AX12). servo 11 replies with and Voltage Error. We tested the current load and voltage fluctuations dont seem to be beyond any reasonable range. we are using the Bioloid power adapter. Current load with 5 servos is in the range of 400ma and voltage pretty stable around 12v.
We have here in the lab a mix of the old (2006) AX12 servos and the current AX12+. Even after upgrading to the latest firmware, it seems that doing this fast "SYNC_READ" sequence is not liked by the old AX12 servos. One effect is getting errors in the response packets. In the example below you can see 2 sequences of position-request packet followed by a reply packet (servos 02 is AX12+ and servo 0B = 11 is AX12). servo 11 replies with and Voltage Error. We tested the current load and voltage fluctuations dont seem to be beyond any reasonable range. we are using the Bioloid power adapter. Current load with 5 servos is in the range of 400ma and voltage pretty stable around 12v.
by Fritzoid
Wed Oct 06, 2010 2:27 pm
The voltage error flag is set under the following conditions:
1. The Present Voltage (control table address 42) is greater than the Highest Limit Voltage (control table address 13).
-or-
2. The Present Voltage (control table address 42) is less than the Lowest Limit Voltage (control table entry 12).
If neither condition is true then the flag is reset.
Can I assume that the voltage limits are set to reasonable values on device 0x0B?
Also, you might want to read the present voltage instead of the present position to see what the servo thinks the voltage is when the error occurs.
Just for testing purposes of course.
1. The Present Voltage (control table address 42) is greater than the Highest Limit Voltage (control table address 13).
-or-
2. The Present Voltage (control table address 42) is less than the Lowest Limit Voltage (control table entry 12).
If neither condition is true then the flag is reset.
Can I assume that the voltage limits are set to reasonable values on device 0x0B?
Also, you might want to read the present voltage instead of the present position to see what the servo thinks the voltage is when the error occurs.
Just for testing purposes of course.