Bulk Read for USB2AX
Bulk Read for USB2AX
by i-Bot
Tue Nov 06, 2012 4:16 pm
In the early days of the DARwin framework when I wrote this:
http://robosavvy.com/site/index.php?opt ... 7&Itemid=2
, it was pretty easy to modify the DARwin frame work to work on AX servo based robots.
More recent developments in the the DARwin software and the MX28 servos made this more difficult without large C++ code changes.
The move from 1024 resolution to 4096, and PID, can be managed through the #defines, though you need an early 1024 friendly version of Roboplus too.
The most significant change was the introduction of the Bulk Read command to the Dynamixel protocol. The Bulk Read is implemented by the MX28, CM730, and the FSR feet to greatly optimise the return of data from these devices through the USB and Linux kernel to the application. The DARwin code runs on an 8ms cycle, so this is important. The DARwin code can be changed to make individual reads, but each of these goes through the USB and kernel as seperate transaction, this is slow especially if an FTDI USB2serial is used with a 1ms latency.
To resolve this problem I have made a new code version for the USB2AX from Xevel. This code converts the Bulk Read to individual reads within the USB2AX and sends the responses back. The only change to the DARwin code is to now use ttyACM0 instead of ttyUSB0, and the AX servos look like 1024 MX servos. The Sync write of servo position and the Bulk Read fit well within the 8ms window.
The Bulk Read is not well documented by Robotis, but is basically a broadcast message received by all the MX28, CM730 and FSR. They all reaspond individually in the same way as a normal read, except they sequence their responses in the order they were listed in the broadcast packet. They simply watch the bus for the previous ID packet to end before sending.
I will send the code to Xevel, so he can add it to the USB2AX repository.
This code could easily be ported onto the CM900 too !
http://robosavvy.com/site/index.php?opt ... 7&Itemid=2
, it was pretty easy to modify the DARwin frame work to work on AX servo based robots.
More recent developments in the the DARwin software and the MX28 servos made this more difficult without large C++ code changes.
The move from 1024 resolution to 4096, and PID, can be managed through the #defines, though you need an early 1024 friendly version of Roboplus too.
The most significant change was the introduction of the Bulk Read command to the Dynamixel protocol. The Bulk Read is implemented by the MX28, CM730, and the FSR feet to greatly optimise the return of data from these devices through the USB and Linux kernel to the application. The DARwin code runs on an 8ms cycle, so this is important. The DARwin code can be changed to make individual reads, but each of these goes through the USB and kernel as seperate transaction, this is slow especially if an FTDI USB2serial is used with a 1ms latency.
To resolve this problem I have made a new code version for the USB2AX from Xevel. This code converts the Bulk Read to individual reads within the USB2AX and sends the responses back. The only change to the DARwin code is to now use ttyACM0 instead of ttyUSB0, and the AX servos look like 1024 MX servos. The Sync write of servo position and the Bulk Read fit well within the 8ms window.
The Bulk Read is not well documented by Robotis, but is basically a broadcast message received by all the MX28, CM730 and FSR. They all reaspond individually in the same way as a normal read, except they sequence their responses in the order they were listed in the broadcast packet. They simply watch the bus for the previous ID packet to end before sending.
I will send the code to Xevel, so he can add it to the USB2AX repository.
This code could easily be ported onto the CM900 too !
by i-Bot
Wed Nov 07, 2012 11:06 am
Sure, I didn't want to mess with the main repo code as you start a production run.
Maybe we should put it as a development branch.
It is still work in progress, and though it works, I should do some more rigorous testing. I am also adding an option to emulate the CM730. Not fully !, just enough to keep the DARwin software happy.(ping, DXL Power)
Maybe we should put it as a development branch.
It is still work in progress, and though it works, I should do some more rigorous testing. I am also adding an option to emulate the CM730. Not fully !, just enough to keep the DARwin software happy.(ping, DXL Power)
by limor
Thu Nov 08, 2012 8:38 pm
Hi i-Bot
Have you tried using the gait generator with bioloid?
An IMU can be plugged to the dynamixel bus and respond to dynamixel packets using an arduino pro mini as glue.
IMHO the linux based closed loop gait generator is key to Darwin's appeal. The open-loop motion editor and behavior editor provided by the CM5/CM510/CM730, can be replaced by simple program on linux that execute open-loop motions directly via the USB bus.
If I recall few years ago we tried to get gumstix and friends to talk to dynamixels at high frame rate and results were not impressive due to the high latency of the USB bus controller and FTDI. In our project actuatedcharacter.com we rewrote the AX12 firmware to accommodate high loop frame rates rather than trying to fight dynamixel's limitations.
So if managed now with RPi and this firmware to get lower latency and create closed loop (ie: read all AX12 sensors into linux then write target speed, CW, CCW back to servos) at 8ms frame rate, then bioloid is about to get a serious facelift.
Have you tried using the gait generator with bioloid?
An IMU can be plugged to the dynamixel bus and respond to dynamixel packets using an arduino pro mini as glue.
IMHO the linux based closed loop gait generator is key to Darwin's appeal. The open-loop motion editor and behavior editor provided by the CM5/CM510/CM730, can be replaced by simple program on linux that execute open-loop motions directly via the USB bus.
If I recall few years ago we tried to get gumstix and friends to talk to dynamixels at high frame rate and results were not impressive due to the high latency of the USB bus controller and FTDI. In our project actuatedcharacter.com we rewrote the AX12 firmware to accommodate high loop frame rates rather than trying to fight dynamixel's limitations.
So if managed now with RPi and this firmware to get lower latency and create closed loop (ie: read all AX12 sensors into linux then write target speed, CW, CCW back to servos) at 8ms frame rate, then bioloid is about to get a serious facelift.
by i-Bot
Fri Nov 09, 2012 12:00 pm
Hi Limor,
I did not work on the walk module for this DARwin yet. On my DARwin-pi I used the DARwin walk module, but the joints were changed from a standard premium. The USB2AX is not used on the Rpi due to USB limitations, so the DARwin-pi code version is very highly modified.
My own current status using the Bulk Read on the USB2AX is a sort of DARwin Premium. This runs the DARwin motion manager and the Action plug in module. The Action module runs within the motion manager framework at 8ms rate, so we might assume the walk module would also run OK if modified to the Premium joints. No modification is made to the Premium joints and a small number of DARwin code changes ( < 10 so far) are made. Keeping close to the standard DARwin code should help as new versions are released, or to add features from other projects(NimbRo).
This is not yet embedded, but runs on an old pentium laptop running Ubuntu 12.04. I sent you an email asking about the A10 stick and how it performs on USB. This may be an an option to try with USB2AX. The only working autonomous embedded DARwin using AX servos that I have right now is the DARwin-pi, but that involves a much bigger step from the standard Premium in hardware and software.
The walk module is the most complex to modify because it has quite a lot of DARwin op specific bits.
I ran the DARwin roboplus server on the Premium and connected from Roboplus(old 1024 version) over TCP/IP socket. This allowed me to download the HumanoidA motions to a DARwin .bin file. These can now be edited with the DARwin Action Editor and run using DARwin script files. I have yet to make a full DARwin program using action to emulate the complete HumanoidA task file.
I did not work on the walk module for this DARwin yet. On my DARwin-pi I used the DARwin walk module, but the joints were changed from a standard premium. The USB2AX is not used on the Rpi due to USB limitations, so the DARwin-pi code version is very highly modified.
My own current status using the Bulk Read on the USB2AX is a sort of DARwin Premium. This runs the DARwin motion manager and the Action plug in module. The Action module runs within the motion manager framework at 8ms rate, so we might assume the walk module would also run OK if modified to the Premium joints. No modification is made to the Premium joints and a small number of DARwin code changes ( < 10 so far) are made. Keeping close to the standard DARwin code should help as new versions are released, or to add features from other projects(NimbRo).
This is not yet embedded, but runs on an old pentium laptop running Ubuntu 12.04. I sent you an email asking about the A10 stick and how it performs on USB. This may be an an option to try with USB2AX. The only working autonomous embedded DARwin using AX servos that I have right now is the DARwin-pi, but that involves a much bigger step from the standard Premium in hardware and software.
The walk module is the most complex to modify because it has quite a lot of DARwin op specific bits.
I ran the DARwin roboplus server on the Premium and connected from Roboplus(old 1024 version) over TCP/IP socket. This allowed me to download the HumanoidA motions to a DARwin .bin file. These can now be edited with the DARwin Action Editor and run using DARwin script files. I have yet to make a full DARwin program using action to emulate the complete HumanoidA task file.
by limor
Fri Nov 09, 2012 5:00 pm
IMHO a linuxified Bioloid needs to have the closed-loop gait generator of the Darwin to make for an ultimate wow factor. 
we have two of these Chinese Android sticks. (that cost like RPi but have better CPU and are much smaller form etc.)
Telechips A5 - branded CX01
Alwinner A10 - branded MK802
the CX01 works (after powering it with enough Amps), gets very hot and the Wifi doesn't really work. Without wifi and with that much heat, it is challenging to work with. (i found some references online that there are tricks to get the wifi to work better by separating the attached wifi board from the cpu board but haven't tried it yet)
The MK802 seems overall better designed than the CX01. but ours just died so we will order another one and test the USB performance as you have asked.
we have two of these Chinese Android sticks. (that cost like RPi but have better CPU and are much smaller form etc.)
Telechips A5 - branded CX01
Alwinner A10 - branded MK802
the CX01 works (after powering it with enough Amps), gets very hot and the Wifi doesn't really work. Without wifi and with that much heat, it is challenging to work with. (i found some references online that there are tricks to get the wifi to work better by separating the attached wifi board from the cpu board but haven't tried it yet)
The MK802 seems overall better designed than the CX01. but ours just died so we will order another one and test the USB performance as you have asked.