Actuatedcharacter
Actuatedcharacter
by limor
Thu Jul 15, 2010 1:56 am
As you may know, I managed to get funding from the European Community (FP7 / Eureka / Eurostars) to develop a running-jumping humanoid robot.
It took a couple of years and finally the money showed up few month ago in the bank and recently 2.5 engineers were finally hired and are working full time (in addition to myself and a couple of Profs. in control and mechanical engineering) to get the objectives accomplished in the limited time.
You can follow our progress on this thread and on http://actuated.wordpress.com
There are some by-products that may be of interest to the Bioloid community.
0) Because I'm managing the project and this is not an academic project and not a top-secret endeavor, most things will be documented and open-source.
1) there is going to be a documented way(s) of doing a precise real-time physics simulation of the Bioliod. Which means you can test your motions on the simulated robot before you massacre your expensive bot. (we just found out that Robocup NAO simulation league uses an ODE based environment which is opensource and may save us some time
)
2) there is going to be a completely new software for controlling the Bioloid. Instead of Motion Builder and interaction scripting, we plan to create a 100Hz closed loop control system with a PC/RoBoard/gumstix.. is the brain that continuously takes input from servo positions and from IMUs (such as CH-Robotics) and continuously tells the servos what to do. From self stabilizing standing (on balls! big feet are gone!) to walking and running and jumping.
3) Matlab will provide the first version of said brain. so there will be a documented way of using simulink/simechanics/matlab to control the robot and its real-time 3D/Physics simulator in real-time. And.. to produce an output C file from matlab that can be compiled on Linux so that the "brain" can run detatched from matlab Gui.
4) Anyone who wishes to participate in this or run parallel experiments or is generally interested in this area of humanoid robotics, is welcome to either taken on some tasks/objectives or get get any help and ideas.
This is the guy (a.k.a. Jacobian1) who will one day run and jump.
The spooky video below shows the simulated robot testing convex mesh collision with physx.
It took a couple of years and finally the money showed up few month ago in the bank and recently 2.5 engineers were finally hired and are working full time (in addition to myself and a couple of Profs. in control and mechanical engineering) to get the objectives accomplished in the limited time.
You can follow our progress on this thread and on http://actuated.wordpress.com
There are some by-products that may be of interest to the Bioloid community.
0) Because I'm managing the project and this is not an academic project and not a top-secret endeavor, most things will be documented and open-source.
1) there is going to be a documented way(s) of doing a precise real-time physics simulation of the Bioliod. Which means you can test your motions on the simulated robot before you massacre your expensive bot. (we just found out that Robocup NAO simulation league uses an ODE based environment which is opensource and may save us some time
)
2) there is going to be a completely new software for controlling the Bioloid. Instead of Motion Builder and interaction scripting, we plan to create a 100Hz closed loop control system with a PC/RoBoard/gumstix.. is the brain that continuously takes input from servo positions and from IMUs (such as CH-Robotics) and continuously tells the servos what to do. From self stabilizing standing (on balls! big feet are gone!) to walking and running and jumping.
3) Matlab will provide the first version of said brain. so there will be a documented way of using simulink/simechanics/matlab to control the robot and its real-time 3D/Physics simulator in real-time. And.. to produce an output C file from matlab that can be compiled on Linux so that the "brain" can run detatched from matlab Gui.
4) Anyone who wishes to participate in this or run parallel experiments or is generally interested in this area of humanoid robotics, is welcome to either taken on some tasks/objectives or get get any help and ideas.
This is the guy (a.k.a. Jacobian1) who will one day run and jump.
The spooky video below shows the simulated robot testing convex mesh collision with physx.
phpBB [media]
by Kuba
Thu Jul 15, 2010 6:49 am
morning message:
i am really interested in participation for the full time. i see already, that this robot will run faster backwards than forwards and i think i could prove it easily. i'll try to make some graphics about it this evening.
evening message:
ok, even my googled free software confirms that your robot will move better backwards. i can prove it.
anyone who needs a programmer - please, consider me as a team member. i want to help, i like programming, i really need a new job.
i am really interested in participation for the full time. i see already, that this robot will run faster backwards than forwards and i think i could prove it easily. i'll try to make some graphics about it this evening.
evening message:
ok, even my googled free software confirms that your robot will move better backwards. i can prove it.
anyone who needs a programmer - please, consider me as a team member. i want to help, i like programming, i really need a new job.
by limor
Thu Jul 15, 2010 10:45 pm
Fritzoid wrote:Looks real nice guys, but Matlab and SolidWorks are way out of my price range. Especially as a hobbyist.
There are some free alternatives to Matlab but not sure the compatibility level of stuff written in Simulink and Simechanics.
However, please note that this new "Jacobian" API that will link the robot to the PC/gumstix, will be open-source therefore you can put whatever real-time brain that you want running on the PC/gumstix.
Matlab/Simulink/Simechanics is a sketching environment for lazy control engineers. Serious programmers (who dont use Pascal) may just write optimized code in other languages.
A comparison can be drawn between the DLL provided by Robotis in conjunction with USB2Dynamixel. Any programming language can use the DLL and the API given by Robotis is the Dynamixel API. The downside of using the FTDI/Dynamixel combo is that by definition, the USB bus controller uses 1ms frames. Each packet going back and forth between the PC and the servos through the half-duplex dynamixel bus will use up a 1ms timeslot. So if you want to read servo positions and then tell the servo to move clockwise or counter-clockwise and at what torque, you use up at least 4 slots. 1000/4=250. if you have 12 servos/sensors on the bus then 250/12 ~ 21 . This means that the maximum control loop rate you can do with 12 entities on the bus is around 20Hz.
Using the new "Jacobian" API, with the CM5 or CM510 as a bridge between the PC and the bus, for 12 entities on the bus, we expect over 120Hz control loop.
There were discussion threads here in the forum couple of years ago about how to get high Hz closed loop control cycles between the CM5 and the servos (there should be links in the wiki). The novelty is that the CM5-PC serial/USB link will be compressed and full-duplex. Hence not Dynamixel. By doing so and developing a protocol specifically for the purpose of closed-loop-control, we are not limited by the USB bus controller 1ms timeslot limitation.
by l3v3rz
Fri Jul 16, 2010 7:19 pm
It would be great if you build something that can act as a general simulator that can be re-configured for robobuilder as well. I've been trying to build something similar using Physx and C# (3D models in Blender) for a while. BTW The nice thing about Physx is if you have a Nvidia graphics card it can use the GPU to hardware accelerate the Physx and you get 10-100 fold speed improvement.
Heres some video of my stuff (all done in evening etc ... )
Note in the first one its a 16 servo robot, but by the newer version I'm trying to support 18 servos as I bought the hip kit.
The problem I've hit is trying to get the model to be realistic in terms of its weight / density / physical dimensions etc etc. So if you create an open source library with say a "servo class" and some different bracket types that can then be "assembled", purely data driven that would be really cool.
Heres some video of my stuff (all done in evening etc ... )
phpBB [media]
Note in the first one its a 16 servo robot, but by the newer version I'm trying to support 18 servos as I bought the hip kit.
The problem I've hit is trying to get the model to be realistic in terms of its weight / density / physical dimensions etc etc. So if you create an open source library with say a "servo class" and some different bracket types that can then be "assembled", purely data driven that would be really cool.
by l3v3rz
Sun Jul 18, 2010 4:45 pm
Downloaded your code and got it running - looks really nice. Almost spooky as it lies there twitching!
Incidentally have you seen this site? : http://bioloidcontrol.sourceforge.net/
Incidentally have you seen this site? : http://bioloidcontrol.sourceforge.net/
by limor
Mon Jul 19, 2010 11:54 pm
bioloidcontrol looked like a very nice project but seems to have not evolved in 2 years.
Our intention now with actuatedcharacter is to bring the physx simulator to certain level of working condition but then leave it in favor of ODE. it seems like the physx has some limitations in its ability to recreate complicated servo behavior whereas ODE is opensource and may provide an easier path to better simulation.
measuring all the physical parameters of the robots and putting them in place into the simulation is a pain. we've done it for Bioloid and there's no reason why you can't do the same for Robobuilder.
Our intention now with actuatedcharacter is to bring the physx simulator to certain level of working condition but then leave it in favor of ODE. it seems like the physx has some limitations in its ability to recreate complicated servo behavior whereas ODE is opensource and may provide an easier path to better simulation.
measuring all the physical parameters of the robots and putting them in place into the simulation is a pain. we've done it for Bioloid and there's no reason why you can't do the same for Robobuilder.
by limor
Tue Jul 20, 2010 12:01 am
Another thread started by billyzelsnack here on the forum has preceeded this in discussing the idea of using a bridge board between the PC/USB/FTDI and the dynamixel bus in order to circumvent the limitations of USB's 1ms frame rate.
http://robosavvy.com/forum/viewtopic.php?t=5808
http://robosavvy.com/forum/viewtopic.php?t=5808
3impact
by birbilis
Sat Jul 24, 2010 12:45 pm
You might want to try the free 3impact engine (http://www.3impact.com), nice wrapper arround ODE (mesh-ball and ball-ball collisions, also implementing ragdolls) and Direct3D (including skinmesh) and nice Sound engine with Doppler effect. Had port its C API to Pascal and created OOP API layer over it in the past (for Delphi) and others followed up (see the forums there) with OOP layers for .NET etc.
by limor
Sat Jul 24, 2010 8:20 pm
3impact definitely looks nice, small and clean code. with impressive demos. I'm familiar with Ogre3d.org which is the heavy-weight of opensource 3D engines. but good to know about this engine.
the challenge really is (a) getting all the inertial parameters into the 3D/ODE model and (b) then to somehow model the AX12 servos control.
Since the self-balancing robot is in perpetual motion, the PWM position-holding control offered by AX12 (and any other RC servo) is useless (*).
The only useful things contrallable with AX12 is power (torque) and direction of rotation (there is no speed control). There is a very high amount of power needed to start the AX12 rotating but once it gets going, it is possible to reduce the torque.
What I suspect we will have to do is initially model the AX12 as a motor with high internal friction (starting friction and then motion friction). Eventually, we will have to sample AX12 servos and just use the sampled data in place of the motor control mathematical model.
Therefore, 3dimpact may be able to give some shortcuts in getting quick visual mapping between ODE and graphics. For now we have started with something i have written many years ago called ezphysics.org. we have updated it to the latest version of Ogre3D and ODE and it seems to be running ok.
(*) PWM holding position feature of the servos may be useful not at the actual target position but at the peripheries. since if you use a 0 punch and big CW value (tolerance around the target position), it is simulating a sort of spring effect. they may turn out to be useful.
the challenge really is (a) getting all the inertial parameters into the 3D/ODE model and (b) then to somehow model the AX12 servos control.
Since the self-balancing robot is in perpetual motion, the PWM position-holding control offered by AX12 (and any other RC servo) is useless (*).
The only useful things contrallable with AX12 is power (torque) and direction of rotation (there is no speed control). There is a very high amount of power needed to start the AX12 rotating but once it gets going, it is possible to reduce the torque.
What I suspect we will have to do is initially model the AX12 as a motor with high internal friction (starting friction and then motion friction). Eventually, we will have to sample AX12 servos and just use the sampled data in place of the motor control mathematical model.
Therefore, 3dimpact may be able to give some shortcuts in getting quick visual mapping between ODE and graphics. For now we have started with something i have written many years ago called ezphysics.org. we have updated it to the latest version of Ogre3D and ODE and it seems to be running ok.
(*) PWM holding position feature of the servos may be useful not at the actual target position but at the peripheries. since if you use a 0 punch and big CW value (tolerance around the target position), it is simulating a sort of spring effect. they may turn out to be useful.
by limor
Sun Jul 25, 2010 12:39 pm
billyzelsnack wrote:So why ODE instead of Bullet?
not being familiar with Bullet, we relied on some googling and found some posts saying that for robot simulation Bullet is not as "good" as ODE. For example this thread. Can't quantify this assessment. I know what to do if I need to write my own servo simulator using sampled data with ODE. Dont know anything about Bullet.
What's your experience?
by billyzelsnack
Sun Jul 25, 2010 3:36 pm
I was more asking for my sake. I have a lot of experience with physics engines, but that experience is several years old now.
My plan was to go with Bullet over ODE because Erwin is still active in it where Russell has not been active in the development of ODE for years. Worst case I'll contribute to Bullet or just write my own simulator again. My project does not have a timeline, so I have the luxury of such things.
In that thread it looks like the main complaint was mass ratios. For what you're doing that should not really be a problem, but who knows. Back a few years the most precise simulator was Newton, but its development looks pretty dead now.
If ODE is currently working for you, I'd say stick with it.
My plan was to go with Bullet over ODE because Erwin is still active in it where Russell has not been active in the development of ODE for years. Worst case I'll contribute to Bullet or just write my own simulator again. My project does not have a timeline, so I have the luxury of such things.
In that thread it looks like the main complaint was mass ratios. For what you're doing that should not really be a problem, but who knows. Back a few years the most precise simulator was Newton, but its development looks pretty dead now.
If ODE is currently working for you, I'd say stick with it.