DARwin AX
DARwin AX
by i-Bot
Sat Mar 19, 2011 12:30 am
I have been running the DARwin code from Robotis with an AX based Bioloid comprehensive humanoid for the last couple of weeks.
While the DARwin OP is going to be a great robot, there are massive opportunities to leverage the code for significantly lower cost humanoids based on AX servos.
Have posted the first of a few articles on my findings and experiments here:
http://robosavvy.com/site/index.php?opt ... 5&Itemid=2
This hopefully shares some insight into wider significance of Darwin to the Bioloid.
The next article will describe how I got the DARwin software running with integration into Roboplus on my humanoid.
While the DARwin OP is going to be a great robot, there are massive opportunities to leverage the code for significantly lower cost humanoids based on AX servos.
Have posted the first of a few articles on my findings and experiments here:
http://robosavvy.com/site/index.php?opt ... 5&Itemid=2
This hopefully shares some insight into wider significance of Darwin to the Bioloid.
The next article will describe how I got the DARwin software running with integration into Roboplus on my humanoid.
Last edited by i-Bot on Mon Mar 21, 2011 4:41 pm, edited 1 time in total.
by siempre.aprendiendo
Sat Mar 19, 2011 1:18 am
Oops. It says that "You are not authorised to view this resource."
Oh, I find it here:
http://robosavvy.com/site/index.php?opt ... 5&Itemid=2
Oh, I find it here:
http://robosavvy.com/site/index.php?opt ... 5&Itemid=2
by SJ
Sun Mar 20, 2011 7:08 pm
This is my very first post here :]
The released code is designed to work with various types of humanoids robots, and in fact the prototype version of OP (Darwin-LC) had AX-18 servos. I think you can make a basically low-cost version of OP using bioloid GP, a fitPC board and controller board (either cm720 or usb2dynamixel will work I think)
The released code is designed to work with various types of humanoids robots, and in fact the prototype version of OP (Darwin-LC) had AX-18 servos. I think you can make a basically low-cost version of OP using bioloid GP, a fitPC board and controller board (either cm720 or usb2dynamixel will work I think)
by i-Bot
Sun Mar 20, 2011 9:22 pm
The code from UPenn supports a range of humanoids including DARwin OP, Darwin LC, and Nao. This seems to include functions, kinematics and dynamics.
The Robotis C++ code appears more specific to Darwin OP on kinematics and functions right now, but opens up the whole range of Robotis robots (Premium, GP) through integration with Roboplus.
I agree the GP looks ideal, and if the FitPC2i will "fit", this combination is very exciting. Affordable Robocup 2/3 size ?
The Robotis C++ code appears more specific to Darwin OP on kinematics and functions right now, but opens up the whole range of Robotis robots (Premium, GP) through integration with Roboplus.
I agree the GP looks ideal, and if the FitPC2i will "fit", this combination is very exciting. Affordable Robocup 2/3 size ?
by Fritzoid
Mon Mar 21, 2011 12:02 pm
I've been spending a lot of time with the darwin code myself and can see some daunting problems that need to be overcome before it can be used with a CM-5/510. Not the least of which are the transmission speed and command protocol.
So it is with great interest that I await your second article.
So it is with great interest that I await your second article.
by i-Bot
Mon Mar 21, 2011 4:48 pm
I put up a draft of the second part. I don't use the CM5 or CM510, just the USB2Dynamixel directly.
The second part might be updated as I, or others try the DARwin software with Roboplus. Still I hope there is enough to get others started experimenting.
http://robosavvy.com/site/index.php?opt ... 7&Itemid=2
The second part might be updated as I, or others try the DARwin software with Roboplus. Still I hope there is enough to get others started experimenting.
http://robosavvy.com/site/index.php?opt ... 7&Itemid=2
by Fritzoid
Mon Mar 21, 2011 6:36 pm
Excellent,
I'm looking for something just like this to leverage the darwin code into the OpenHRP simulator. It should be a fairly simple matter to feed the servo commands into the simulator as opposed to the USB2Dynamixel.
I'm also working on a java program to replace RoboPlus Motion. It will read, write, and edit motion files and will run under Linux. If I can connect this program to the darwin framework then maybe I can factor the Windows PC out of the configuration all together.
Keep up the good work!
I'm looking for something just like this to leverage the darwin code into the OpenHRP simulator. It should be a fairly simple matter to feed the servo commands into the simulator as opposed to the USB2Dynamixel.
I'm also working on a java program to replace RoboPlus Motion. It will read, write, and edit motion files and will run under Linux. If I can connect this program to the darwin framework then maybe I can factor the Windows PC out of the configuration all together.
Keep up the good work!
by PedroR
Tue Mar 22, 2011 4:57 pm
Hi i-Bot
I've been reading through your articles and (as usual) it's a very clever approach to adapting it.
I was actually quite interested and surprised to see you managed to track down the "bridge" in software/hardware to the emulation of the CM-730.
I was now wondering, once the CM-730 emulation is complete, how deep are the algorithms calibrated for the DarwinOP weight, center of mass, sensor positioning, etc.
From the DarwinOP main website it still seems to maintain this Motion/Action division where a Motion is triggered by an Action but I trust the approach is not as simplistic as this.
There's certainly a lot more going on with all that processing power under the hood.
Looking forward for further developments
Regards
I've been reading through your articles and (as usual) it's a very clever approach to adapting it.
I was actually quite interested and surprised to see you managed to track down the "bridge" in software/hardware to the emulation of the CM-730.
I was now wondering, once the CM-730 emulation is complete, how deep are the algorithms calibrated for the DarwinOP weight, center of mass, sensor positioning, etc.
From the DarwinOP main website it still seems to maintain this Motion/Action division where a Motion is triggered by an Action but I trust the approach is not as simplistic as this.
There's certainly a lot more going on with all that processing power under the hood.
Looking forward for further developments
Regards
by Bullit
Tue Mar 22, 2011 6:52 pm
There are actually two sources of code for the Darwin-OP:
The UPenn (mostly lua) source which was put up late last year and hasn't been updated since. It contains a full ZMP and IK walk generator along with ball following and game finite state machines. This code include mass, length, cm for all joints and robot. There is a bunch of clever stuff here but its not as clean as the Robotis implementation.
The Robotis source which is more current contains an IK walk generator which does not use mass, cm or ZMP. It does however use the geometric configuration of the robot. Line the UPenn code it supports Actions or pose playing which is joint angle based and does not use IK or balance. The Robotis code does have an interface to roboplus which is convenient to do pose based moves. This source does expose fully the Robotis pose motion engine and it interpolation methods. This should be a good source for anyone working with dynamixels for pose based motion.
I've been fortunate enough to have a Darwin-OP to play with for the last month or so. I've worked with both code bases. Both have their merits. I've managed to tune the Robotis gait generator quite nicely and its one of the most impressive walking gaits I've worked with. Like i-bot I am looking at porting some of this to my other platforms however I believe one of the reasons it works so well on the Darwin-OP is the rx-28m. The rx-28m's are clearly superior in their ability to hold a tight position without oscillation.
Both these sources have simple gyro balance with no kalman filtering or real PID (above the servos themselves) yet it seems to work quite well in the Darin-OP. I've tried similar implementations with other Robotis servos including the Bioloid only to find great sensitivity to oscillations hence previously I've resorted to kalman filtering and class C PID's.
The UPenn (mostly lua) source which was put up late last year and hasn't been updated since. It contains a full ZMP and IK walk generator along with ball following and game finite state machines. This code include mass, length, cm for all joints and robot. There is a bunch of clever stuff here but its not as clean as the Robotis implementation.
The Robotis source which is more current contains an IK walk generator which does not use mass, cm or ZMP. It does however use the geometric configuration of the robot. Line the UPenn code it supports Actions or pose playing which is joint angle based and does not use IK or balance. The Robotis code does have an interface to roboplus which is convenient to do pose based moves. This source does expose fully the Robotis pose motion engine and it interpolation methods. This should be a good source for anyone working with dynamixels for pose based motion.
I've been fortunate enough to have a Darwin-OP to play with for the last month or so. I've worked with both code bases. Both have their merits. I've managed to tune the Robotis gait generator quite nicely and its one of the most impressive walking gaits I've worked with. Like i-bot I am looking at porting some of this to my other platforms however I believe one of the reasons it works so well on the Darwin-OP is the rx-28m. The rx-28m's are clearly superior in their ability to hold a tight position without oscillation.
Both these sources have simple gyro balance with no kalman filtering or real PID (above the servos themselves) yet it seems to work quite well in the Darin-OP. I've tried similar implementations with other Robotis servos including the Bioloid only to find great sensitivity to oscillations hence previously I've resorted to kalman filtering and class C PID's.
by i-Bot
Wed Mar 23, 2011 12:08 pm
Thanks bullit for the clafication on the two versions.
I started with the UPenn code and agree it is more complete and the best start point if Robocup is the objective. The code hacks I put in the article are not valid for the UPenn code.
To run the UPenn code I had a different approach where I emulated the CM-730 on a Cortex M3 (actually an NXP not STM because I prefer the USB bootloader). This used the on chip USB interface to talk with the main controller unlike the CM730 which uses an FTDI chip. I had to write linux USB device drivers and rewrite the low level c and lua from UPenn. This got DARwin communication manager working. I was looking at adapting the kinematics on UPenn when the Robotis code appeared. The Robotis code seemed to offer a quick start opportunity to get more people involved, so I jumped over to that.
The UPenn code seems to have reference to a SYNC READ command, but that did not appear to make it to the Robotis docs or code. Do you use the same firmware in the CM-730 for both UPenn and Robotis main controller software ?
The superiority of the RX28M is interesting. Since you have experience of a wide range of Robotis servos including some with mag encoders, do you think the improvement is due to mechanics, encoders, or the servo firmware ?
In the UPenn code, I see in the DarwinOPCommManager.lua code, the comment " We can control hardness with RX28" and in the DarwinLCCommManager.lua code the comment " Dynamixel torque limit..... making it useless for hardness control". Can bullit, JS, or anyone explain this and what servos it applies to ?
I started with the UPenn code and agree it is more complete and the best start point if Robocup is the objective. The code hacks I put in the article are not valid for the UPenn code.
To run the UPenn code I had a different approach where I emulated the CM-730 on a Cortex M3 (actually an NXP not STM because I prefer the USB bootloader). This used the on chip USB interface to talk with the main controller unlike the CM730 which uses an FTDI chip. I had to write linux USB device drivers and rewrite the low level c and lua from UPenn. This got DARwin communication manager working. I was looking at adapting the kinematics on UPenn when the Robotis code appeared. The Robotis code seemed to offer a quick start opportunity to get more people involved, so I jumped over to that.
The UPenn code seems to have reference to a SYNC READ command, but that did not appear to make it to the Robotis docs or code. Do you use the same firmware in the CM-730 for both UPenn and Robotis main controller software ?
The superiority of the RX28M is interesting. Since you have experience of a wide range of Robotis servos including some with mag encoders, do you think the improvement is due to mechanics, encoders, or the servo firmware ?
In the UPenn code, I see in the DarwinOPCommManager.lua code, the comment " We can control hardness with RX28" and in the DarwinLCCommManager.lua code the comment " Dynamixel torque limit..... making it useless for hardness control". Can bullit, JS, or anyone explain this and what servos it applies to ?
by SJ
Wed Mar 23, 2011 4:09 pm
The main superiority of RX28M is that we do not have to worry about the potentiometer wear any more, which results in annoying servo whine and dreadful shaking after some while.
And we used to have some controller side code that keeps track of all joint angles of servo and returns them if requested (that's the sync read). The distributed code does not rely on controller side code and lacks that feature. However you can use any controller (cm720, usb2dynamixel, arduino..) instead I think.
Finally the hardness (or max torque) setting comments are about prototype OPs with AX-18 servos. For some reason we could not control the maximum torque of AX servos in the way we control RX and EX servos.
And we used to have some controller side code that keeps track of all joint angles of servo and returns them if requested (that's the sync read). The distributed code does not rely on controller side code and lacks that feature. However you can use any controller (cm720, usb2dynamixel, arduino..) instead I think.
Finally the hardness (or max torque) setting comments are about prototype OPs with AX-18 servos. For some reason we could not control the maximum torque of AX servos in the way we control RX and EX servos.