AX-12 Baud Rate
AX-12 Baud Rate
by JavaRN
Thu Jul 09, 2009 10:28 pm
I have just ordered a Roboard from robosavvy to replace the cm-5 of my humanoid with something more sophisticated. However I noticed that to communicate wit ax-12 using roboard I have to lower the ax-12 baud rate to 115200. What effect will this have on the humanoid? Will it reduce performance, in the sense that playing motions will be drammatically effected? (hope not 
)
)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 Bullit
Thu Jul 09, 2009 11:35 pm
How many servos are you planning on having? How many are in motion at a time? Do you need to read data from the servos? If so how often and how many of them? How close in time do their responses need to be?
If you use the CM5 as a baseline for smooth motion then you'll have to update, at least servos in motion once every 8ms with a sync_write command. Looking at the ax-12 manual you can calculate how many bytes you need for each write and each read, multiply that number by 10 to include stop and start bit and compare that to your baud rate. Since reads aren't synchronized that may be an issue for your application with longer delays between reads due to baud rate.
hope this helps.
If you use the CM5 as a baseline for smooth motion then you'll have to update, at least servos in motion once every 8ms with a sync_write command. Looking at the ax-12 manual you can calculate how many bytes you need for each write and each read, multiply that number by 10 to include stop and start bit and compare that to your baud rate. Since reads aren't synchronized that may be an issue for your application with longer delays between reads due to baud rate.
hope this helps.
by JavaRN
Fri Jul 10, 2009 1:05 pm
How many servos are you planning on having?
20
How many are in motion at a time?
18
Do you need to read data from the servos?
Once before they start a page. i would like to keep the same format for motion pages as in the cm-5, so before I start a page I check their position to see how further each motor has to move, then sort the list of servo positions in descending order, so that the motor with the longest turn starts first, and then compute the speed for each motor, finally I send two writes for each servo - one for selecting the speed the other for selecting the goal position.
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 Bullit
Fri Jul 10, 2009 6:47 pm
Perhaps you don't know this but when you send a different speed to the Ax-12 you are also sending a different torque.
If you want to do things the way the CM-5 motion engine does them then you send a sync_write which goes to all servos and synchronizes motion. The CM-5 motion engine sets torque to maximum (which also means speed is set to maximum as they are directly related) then it sends CWSlope, CCWSlope and goal position to each servo as a single sync_write but this is updated many times between poses. The idea is that the servos all maintain a fixed torque throughout the motion, matching speed of the servos in done by taking many small steps between any two poses and therefore the speed is simply the derivitive of the posiiton. The time it takes to move from one pose to the next is controlled by the time it takes to get the servo that has the furthest to move to its destination at the speed requested. All other servos are scaled to complete their moves at the same time.
So if you are planning on updating 18 servos with a sync_write, lets say speed and goal then each servo cost 5 bytes with a packet overhead of 5 bytes, I think, so thats 5[bytes per servo]x18[servos]+5[bytes packet overhead]*10[bits per byte] = 950 bits per packet. At 115k baud you'll only be able to update them every 8.25ms which is close to the CM-5 speed but it doesn't allow for you to read back anything, you've already used up all your time in the serial transport at 115k baud.
If you want to do things the way the CM-5 motion engine does them then you send a sync_write which goes to all servos and synchronizes motion. The CM-5 motion engine sets torque to maximum (which also means speed is set to maximum as they are directly related) then it sends CWSlope, CCWSlope and goal position to each servo as a single sync_write but this is updated many times between poses. The idea is that the servos all maintain a fixed torque throughout the motion, matching speed of the servos in done by taking many small steps between any two poses and therefore the speed is simply the derivitive of the posiiton. The time it takes to move from one pose to the next is controlled by the time it takes to get the servo that has the furthest to move to its destination at the speed requested. All other servos are scaled to complete their moves at the same time.
So if you are planning on updating 18 servos with a sync_write, lets say speed and goal then each servo cost 5 bytes with a packet overhead of 5 bytes, I think, so thats 5[bytes per servo]x18[servos]+5[bytes packet overhead]*10[bits per byte] = 950 bits per packet. At 115k baud you'll only be able to update them every 8.25ms which is close to the CM-5 speed but it doesn't allow for you to read back anything, you've already used up all your time in the serial transport at 115k baud.
now I have many things to try when roboard arrives!
by PedroR
Mon Jul 13, 2009 12:45 pm
Hi JavaRN
I've noticed you mentioned lowering the speed of the servos to 115 kbps.
Is there any particular reason to do so?
The roboard maximum speed on the comm ports is ~460mbps (about half the speed of the bioloid bus) so theoretically you should be able to go up to that speed.
As a side note, the Robobuilder (which is similar to Bioloid in many aspects of the engineering) runs the servos at 115 kbps and it's able to perform nicelly.
In the future, if you run into any issue when putting the Roboard on the Bioloid I would recommend that you also post on our Roboard forum, as the engineers from DMP / Roboard keep monitoring that forum and I'm sure there you'll get info directly from the source
Regards
Pedro
I've noticed you mentioned lowering the speed of the servos to 115 kbps.
Is there any particular reason to do so?
The roboard maximum speed on the comm ports is ~460mbps (about half the speed of the bioloid bus) so theoretically you should be able to go up to that speed.
As a side note, the Robobuilder (which is similar to Bioloid in many aspects of the engineering) runs the servos at 115 kbps and it's able to perform nicelly.
In the future, if you run into any issue when putting the Roboard on the Bioloid I would recommend that you also post on our Roboard forum, as the engineers from DMP / Roboard keep monitoring that forum and I'm sure there you'll get info directly from the source
Regards
Pedro
by JavaRN
Mon Jul 13, 2009 5:16 pm
I got a little confused 
is the maximum speed for com 4 115k or 460k? when I contacted roboard technical support they told me it's 115k.
is the maximum speed for com 4 115k or 460k? when I contacted roboard technical support they told me it's 115k.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 PedroR
Mon Jul 13, 2009 5:22 pm
The info I have from their technical specs is 640K.
That's the speed we also advertise in our pages at Robosavvy.
However, they have supplied some samples for Bioloid which implement heuristics that solve the issue of having RX and TX shorted.
In practice they seem to implement some heuristics to control the timings between sending the packet and reading the servo response.
The heuristics in _those samples_ may be tunned up for 115kbps.
I haven't seen the answer you got from them so I can't really be sure.
If you can please post your question to them and their reply and we'll look through it.
As I said, the info I got from them in terms of specs is that the maximum theoretical limit is at 640Kbps.
That's the speed we also advertise in our pages at Robosavvy.
However, they have supplied some samples for Bioloid which implement heuristics that solve the issue of having RX and TX shorted.
In practice they seem to implement some heuristics to control the timings between sending the packet and reading the servo response.
The heuristics in _those samples_ may be tunned up for 115kbps.
I haven't seen the answer you got from them so I can't really be sure.
If you can please post your question to them and their reply and we'll look through it.
As I said, the info I got from them in terms of specs is that the maximum theoretical limit is at 640Kbps.