Good bye ODE, hello GEAR!

I eventually grew tired of ODE's inability to handle cyclic graphs well, and looked for alternatives. Apparently cyclic dependencies in the constraints is a difficult problem to solve so very few solutions exist that will work. Luckily I found an alternative called GEAR (Geometric Engine for Articulated Rigid-body simulation) which was made with cyclic graphs in mind. GEAR is an implementation of a a novelty algorithm using some fancy new stuff called "lie group formulation for articulated rigid body dynamics". The code speaks for itself. Mr. Jinwook Kim who made the original, and Mr. Junggon Kim who adapted it to his use (and from what I can see, extended/simplified the code a bit) really know what they were up to. It seems to use more is nearer to use some basic C++ features and lacks the silly "C <--> C++ <--> C" wrapping of the ODE API. There seems to be no documentation what-so-ever, except for the extremely math-intensive and otherwise dense paper, and code comments are sparse. But the demos are stunning! Please check out the videos on this page.

"Sloop" demo of GEAR

I will make my best effort to use this code in my project, and if I am lucky, it will perform under my demands. One hurdle that I will have to get around is the lack of collision detection and handling, however there is some code for that on the video page that I might be able to adapt.

UPDATE: gear was moved to github.

ODE instability

Adding the actuators to my ODE model proved much harder than first anticipated. Even with all the stability-enhancing features of ODE cranked up to the max (really small step size, CFM and ERP set high, unit size bodies, masses etc.) my model completely explodes. I think the reason is that when I pose the model, it is not completely still, and the abrupt movement caused by the spike in error correction at simulation startup simply blows out of proportions.

Open Dynamics Engine (ODE) exploded simulation due to instability.

I will work on it some more before giving up on it. One idea is to engage the actuator bodies after the rest of the model has settled. Maybe assembling the model in zero gravity will help as well. But so far it is not looking good for this project. :-( I was hoping that ODE would play nice. I have used it a lot before, but then I mostly played with the collision detection and building large structures out of blocks to see how they would collapse, which ODE handled splendidly.

In my frustration I went looking for alternatives and found this excellent collection of hexapod code by 12Cent Dwarf

First ODE based IK screenshot

I finally managed to coax ODE into accepting my IK rig. It was not easy, I can tel you that. The ODE documentation is a nightmare. I still haven't figured out why some of my code does not work. But I decided to leave it be and focus on what's more important. I have built the rig without actuators. It runs in a simulator that draws out a simple representation of the world in OpenGL. I also have a Qt5 form where I can add some widgets to control the simulation as I go along. In the screen-shot, the robot is actually in free fall, because it becomes really unpleasant to look at after it lands.

Devol Robot Simulator first screenshot

And here is the code that actually assembles the robot:

void LimbRigController::buildRig(){
    Vector center(-2,0,5);
    int NUM_LEGS=6;
    Vector axisBase(1,0,0);
    float thighToShinRatio=0.75;
    float legLength=1.0;
    float innerRad=0.5;
    float kneeRad=innerRad+(legLength*thighToShinRatio)/(legLength*thighToShinRatio+legLength/thighToShinRatio);
    float toeRad=kneeRad+(legLength/thighToShinRatio)/(legLength*thighToShinRatio+legLength/thighToShinRatio);
    float kneeHeight=0.0;
    float stepAng=(360)/NUM_LEGS;
    float ang=0;
    float legRadius=0.1;
    float baseRadius=2;
    DynamicObject *base=new DynamicObject(world,space,center,center +Vector(0,0.01,innerRad/baseRadius),Vector(0,0,1),baseRadius,0x008888ff,DynamicObject::CYL);
    //base->join(0,center,Vector(0,0,1));
    dobs.push_back(base);
    for(int i=0;i pelvis(0,innerRad,0);
        pelvis.rotate(ang,0,0,1);
        pelvis+=center;
        Vector knee(0,kneeRad,kneeHeight);
        knee.rotate(ang,0,0,1);
        knee+=center;
        Vector toe(0,toeRad,0);
        toe.rotate(ang,0,0,1);
        toe+=center;
        Vectoraxis=axisBase;
        axis.rotate(ang,0,0,1);
        DynamicObject *thig=new DynamicObject(world,space,pelvis,knee,axis,legRadius,0x00ff8888,DynamicObject::CYL);
        DynamicObject *shin=new DynamicObject(world,space,knee,toe,axis,legRadius,0x0088ff88,DynamicObject::CYL);
        base->join(thig,pelvis,axis,-M_PI*0.5,M_PI*0.5);
        shin->join(thig,knee,axis,-M_PI*0.5,0);
        dobs.push_back(thig);
        dobs.push_back(shin);
        ang+=stepAng;
    }
}

Anatomy of a robot limb

For simplicity I have decided to keep all 6 limbs of Devol identical. Each limb will be interchangeable with any other. This I hope will make building and maintaining the limbs much quicker and cheaper due to reuse, but the design process might take longer because now I have to ensure that the one design i decide upon actually will work for all 6 legs.

I have been thinking a lot, and created a 3d model for simulating the possible limb configurations. I have also managed to install OpenRave, and I have started learning to use it by adapting one of the example robot definition XML files while reading some of its tutorials on-line.

I have also looked at realistic actuators that might fit into the designs on global sourcing sites such as alibaba. For example I have received a quotation at 22USD per piece for 20pieces of this nice little actuator. Since I will need 18 of them, this is good news.

FY011C Linear actuator 12VDC at FOB 22USD/20pcs

The idea is that instead of having geared motors at the joins, I will have linear electro-mechanical actuators in a configuration that is typical for hydraulic and pneumatic systems. The benefits are many:

• The design is simple
• The resulting robot will be more solid due to the separation of hinges and force in joints.
• Reaching higher precision in the actuators is easier than with geared motors due to the available flexibility of mounting positions.
• The actuators will actually be cheaper due to their outspread use in furniture.
• The actuators will remain static under load with 0 power drain.
• The actuators are available with built in position sensors and end switches
• The actuators are available with IP ratings for dust and water resistance. The one I found was rated IP66
• The choice of available actuators is huge with all sorts of quality, precision, speed and load requirements.

 But how can I calculate the required dynamic and static forces? I found this great site that appears to be centered around building another hexapod. They have a head start, I better shape up!

Anyhow they made a series of tutorials, one which was very useful for my project, namely the PDF about simple hydraulics joints. I can warmly recommend it due to its simplicity and completeness.

My take-away was this figure with the matching formula:

Shamelessly stolen without permission from http://projecthexapod.com

Linear Piston Force * Moment Arm = Torque @ Joint 


Now I'll just have to find out the value for all my variables...

3D rig

I have used  Light Wave since version 5.0, and it is a great 3D modeling and animation program with really long traditions. It has support for inverse kinematics, so it is perfect for experimenting with different models of the robot.  I have made a 3D model and animated it.

The purpose is to find optimum leg configurations, sizes and placements. I can also use the model to predict what kind of forces and precision I will need in my actuators. This was the greatest take-away from my first limb prototype, the fact that I need to have actuators with more torque and a design with much more sturdy joints. This is my first result. Its a single walk cylcle:

IKFast

Right now I am working on the software part of the robot. The area I have worked most on is related to vision, audio and other rather complex areas. I have hit a wall because the single most important algorithm for the vision subsytem, namely the SURF has an implementation in OpenCL that refuses to run on my nVidia hardware. Apparently nVidia has inferior OpenCL support to the likes of AMD. I have struggled with a hodgepodge of drivers, libraries and versions before essentially giving up til I get my hands on some better hardware.

In the meantime I have shifted focus to another important part of the software, namely motion. How will the position of the legs be calculated? I have worked with 3D graphics for a while earlier in my carrier, and I instantly googled "IK" for "Inverse Kinematics", which is the art and science of calculating where a bunch of stuff under constraints will move when receiving input.

It turns out that to make IK work I will have to create an accurate 3D model of the robot body first. How else would the IK solver know what and how to operate?

After looking around for a bit for C++ libraries for solving IK problems, I came across IKFast which is a plugin to the extensive OpenRAVE project that takes the whole making a model and simulating it very seriously. Actually IKFast is a compiler that will generate C++ code that can be incorporated into my project directly. It needs a robot description as input, and it will output code that is fast, accurate and robust and that fits my robot perfectly.

This is exactly the kind of tool I love. Performance in the front seat. The downside (or upside if you will) is that I need to know exaclty how my robot should look like, and although I have all these dreams resembling scenes from the sci-fi movies, I havent put much effort into finding a resonable working design.

I guess it is time that I start designing the body of my robot. Maybe I can use the robot model to simulate my way to a better design?