SYNCREAD
SYNCREAD
by billyzelsnack
Wed Jan 27, 2010 5:34 am
phpBB [media]
I implemented a SYNCREAD. The video shows two different ways of doing the same thing..
The regular way.
read 18 servo positions
syncwrite the position of servo 5 to all 18 servos ( except 5 )
21fps
The syncread way.
syncread 18 servo positions
syncwrite the position of servo 5 to all 18 servos ( except 5 )
65fps
My SYNCREAD protocol is pretty basic, but it's general..
255
255
id ( teensy dynamixel device )
length
80 ( syncwrite instruction, not hex )
address 0
count 0
id 0
address 1
count 1
id 1
...
checksum
The return packet I get is..
255
255
id ( teensy )
length
error
whatever the 0 read instruction returned with the first two bytes and last byte stripped
whatever the 1 read instruction returned with the first two bytes and last byte stripped
...
checksum
How fast are other people able to read and write all 18 servos? I'm not sure my interface and code is not adding extra latency for no reason. I'm going to put in some timestamps to see what is actually still slowing things down. I'd really like to hit 100fps.
by billyzelsnack
Thu Jan 28, 2010 5:12 am
I stuck some timing info inside my packets. Looks like it takes 42 ticks to read all 18 servos on the microcontroller side. The microcontroller is running 16MHz and the 8 bit timer is set to div 8. So.. 16000000/256/8 is 7813 ticks a second. 7813/42 ticks gives me 186fps on the microcontroller side for reads.
After seeing these numbers I probably am running at max speed there. I guess I need to look into USB latency a bit more.
After seeing these numbers I probably am running at max speed there. I guess I need to look into USB latency a bit more.
by Fritzoid
Thu Jan 28, 2010 2:13 pm
I'm having a little touble following your logic here. I clearly understand the desirability of having a syncread function and that faster is better for feedback control. What I don't get is the specifics. Correct me where I am wrong.
Your issuing a syncwrite with a non-broadcast ID (teensy?).
Your writing to a read-only address (0) for a length (L) of zero.
Your sending triplets (ID, address and count) where syncwrite wants ID and write data for length L.
And your getting responses from all the servos on the bus.
Questions:
What do you mean by a teensy dynamixel device?
Why are two bytes of data transmitted for each device when the original count is zero?
The documentation says syncwrite returns no status but you are claiming to be reading data?
What data is being returned and where is the requested address specified?
Obviously, I'm missing something
Your issuing a syncwrite with a non-broadcast ID (teensy?).
Your writing to a read-only address (0) for a length (L) of zero.
Your sending triplets (ID, address and count) where syncwrite wants ID and write data for length L.
And your getting responses from all the servos on the bus.
Questions:
What do you mean by a teensy dynamixel device?
Why are two bytes of data transmitted for each device when the original count is zero?
The documentation says syncwrite returns no status but you are claiming to be reading data?
What data is being returned and where is the requested address specified?
Obviously, I'm missing something
by billyzelsnack
Thu Jan 28, 2010 6:02 pm
I made another type of Dynamixel out of a microcontroller. Teensy is just an AVR microcontrller development board similar to Arduino.
http://www.pjrc.com/teensy/
My "teensy" is what bridges my PC via USB with the AX-12's. It also follows the Dynamixel protocol and has its own id and controltable. In addition to bridging between the PC and the AX-12's it can do other things. In particular it allows me to put two regular RC hobby servos on the same bus with the AX-12's. It also is what is doing all the SYNCREAD work.
I send a single packet from the PC to the teensy with a list of everything I want read from all 18 of my AX-12's. The teensy does all the reads itself and then creates a single packet that is returned to the PC. The usual way to do this would require 18 separate reads from the PC to the servos which is slower because of USB latency.
http://www.pjrc.com/teensy/
My "teensy" is what bridges my PC via USB with the AX-12's. It also follows the Dynamixel protocol and has its own id and controltable. In addition to bridging between the PC and the AX-12's it can do other things. In particular it allows me to put two regular RC hobby servos on the same bus with the AX-12's. It also is what is doing all the SYNCREAD work.
I send a single packet from the PC to the teensy with a list of everything I want read from all 18 of my AX-12's. The teensy does all the reads itself and then creates a single packet that is returned to the PC. The usual way to do this would require 18 separate reads from the PC to the servos which is slower because of USB latency.
by billyzelsnack
Thu Jan 28, 2010 7:50 pm
Dunno. The CM-* definitely can read all the servos very quickly. Maybe because the CM-* does other work too. My teensy Dynamixel doesn't do much at all each loop so it has processor time to do this extra work. The idea being that the other extra work is done on the PC instead.
I was considering switching away from a teensy and instead go the regular AVR + FTDI serial interface. The teensy USB can transmit much faster ( max 12Mb ) than the FTDI ( max ) 1Mb, but I think USB latency is the real bottleneck. The advantage of using FTDI is that the Robotis tools would still work with it.
If I end up switching I'll maybe give a go at porting it to the CM-5. Either way I'll be releasing the source to this soon and somebody else can mess around with it.
I was considering switching away from a teensy and instead go the regular AVR + FTDI serial interface. The teensy USB can transmit much faster ( max 12Mb ) than the FTDI ( max ) 1Mb, but I think USB latency is the real bottleneck. The advantage of using FTDI is that the Robotis tools would still work with it.
If I end up switching I'll maybe give a go at porting it to the CM-5. Either way I'll be releasing the source to this soon and somebody else can mess around with it.
poor bioloid
by UncleBob
Fri Jan 29, 2010 5:05 am
poor robot, it looks like it is chopped up ready to pour into a pot for dinner.
by i-Bot
Mon Jul 12, 2010 6:18 pm
Hi,
Did you get any further with this ?
I am looking at a similar attempt to get data from 20 servos in 10ms or less. from XP. I tried high speed FTDI, but it only works using special driver under linux, and XP cannot cope with the higher speed.
Plan is to emulate the FTDI device, because dynamixel manager seems to check for this even if it is only a virtual com port. A CDC device is a bit easier and faster, and would work with most other libraries.
Will use USBKEY initially, but target is AT90USB162
Did you get any further with this ?
I am looking at a similar attempt to get data from 20 servos in 10ms or less. from XP. I tried high speed FTDI, but it only works using special driver under linux, and XP cannot cope with the higher speed.
Plan is to emulate the FTDI device, because dynamixel manager seems to check for this even if it is only a virtual com port. A CDC device is a bit easier and faster, and would work with most other libraries.
Will use USBKEY initially, but target is AT90USB162
by billyzelsnack
Mon Jul 12, 2010 7:24 pm
I figured 83fps was fast enough for my uses and went on. For 18 servos I got 83fps which is 12ms. I'd guess 20 servos would probably be right around 12ms too. So that's pretty close to your 10ms number.
My next attempt will be to use LUFA with a bumble-b. I'll post the numbers I get from that, whenever that is.
Please post what numbers you end up achieving.
My next attempt will be to use LUFA with a bumble-b. I'll post the numbers I get from that, whenever that is.
Please post what numbers you end up achieving.
