darwin motions

[limor]

thanks again!
the COG and Inertia tensor are needed for the physics simulator (ODE in the case of EZPhysics). How did you feed these parameters into the simulator you used?

[Fritzoid]

OpenHRP is designed as a plug-in to the Eclipse IDE which runs on Linux or Windows. One of the features of this plug-in is a custom "View" with editing capabilities. It also has model loading and saving menu options. Together these make it pretty easy to use (once you've collected the data of course).

Here's a link to a web page with some screen shots describing the process.

http://www.openrtp.jp/openhrp3/en/howtoeditmodel.html

A humanoid robot is more complex but the process remains the same. There's also nothing stopping you from using a text editor to modify the file. This is particularly useful when global changes are required.

[limor]

The COG and inertial tensor parameters were extracted from the set of high-resolution parts and assemblies that I created from the Robotis igs files. These parts and assemblies are in Alibre Design format and I can make them available too if you are interested.

yes please.

[i-Bot]

If you want to model the DARwin OP, there are now some CAD files and new dynamics information on sourceforge.

[Fritzoid]

I had to break the package into multiple pieces but the archives are now available in my files area.

bioloid_parts1.zip
bioloid_parts2.zip
bioloid_parts3.zip
bioloid_parts4.zip
bioloid_assemblies.zip

I was unable to upload the high-res. CM-510 part because it's just too big, nearly 8M compressed. Because it's so large it's impractical to use and I replaced it with a lower-res. version in the assemblies, so you shouldn't need it.

There is an extra text file in the assemblies archive named parts_specs.txt.
It collects the physical properties reports for the different assemblies in a single place. This is probably what you'll use most.

[billyzelsnack]

I'm surprised that they are continuing to post new stuff. I figured that they'd post just enough to satisfy their grant requirements and be done with it. I guess they truly are serious about the product and opensource. Good for them.

[exe_cutable]

Hi Fritzoid,

I thank you for uploading everything, but if you could I would like to know the position and rotation of the parts in relation to each other.

This would save me the trouble of installing Java + Eclipse + OpenHRP3 + etc...

Basically when you load the model in the OpenHRP3 plugin you set the translation and rotation so that it is correctly aligned with the torso, right? That is what I need also.

Joint positions in relation to the torso would also be great, but I guess those are similar

Thanks in advance,
Jorge Graça

[Fritzoid]

Hi exe_cutable,

The coordinates are based on a right-handed system with the x-axis pointing straight out from the chest, y-axis out the left arm and z-axis out of the top of the head. All the joints maintain this convention.

Each new joint is parented off the previous joint so it's translation is relative to the origin of the higher-level joint. The torso is at the highest-level and is positioned in the world coordinate system based on its center point. This is located mid-body at about the point of the chest plate.

[exe_cutable]

humm... ok, but what values? Or where can I find those values?

[Fritzoid]

That information is embedded in the file humanoid_A.wrl in the model directory of my BioSim.zip file. You can easily read this file with a text editor like gedit or wordpad. Each joint is defined using a DEF joint statement and the translation and joint orientation values follow this directly. Here's a few lines from the file...

Code: Select all

       
DEF right_shoulder Joint {
          jointType "rotate"
          jointId 1
          jointAxis 0.0 -1.0 0.0
          translation 0 -0.049 0.048


Here joint "right_shoulder" is located at an offset -0.049 meters in the y-direction and +0.048 meters in the z-direction. Both offsets are relative to the parent which is the torso in this case. The jointAxis line defines the rotation axis and direction, in this case about the negative y-axis.

[limor]

Hi Fritzoid

We have a problem with the model
Hopefully you can help by exporting things out of Alibre-design differently

the Physics parameters in the file are in SI coordinates (meters) while the mesh is in centimetres. Ideally you would be able to export the physics parameters in Centimetres as well

Thank you!

[Fritzoid]

Hi limor,

When you say the meshes are in centimeters are you talking about the VRML files or the parts and assemblies?

[exe_cutable]

Hi Fritzoid,

The VRML files.

Hopefully you could export the physics parameters (the humanoid_A.wrl) in cm also, instead of SI Units. Is that possible?

[Fritzoid]

The physics parameters in the humanoid_A.wrl are in SI units because that's the standard for OpenHRP. The simulator is generally used with much larger robots including life-sized where meters are a more reasonable scale. It seems to be the only option available too, so it doesn't make much sense to change the file.

What I can do is recalculate the physics parameters in the file Partnumbers.txt although this amounts to little more than shuffling the decimal points around. I'll have to post this later.

The VRML files themselves come from a different source than the physical parameters. They were produced from the low-resolution igs files found on the RoboPlus CD. After the individual parts were imported into Blender http://www.blender.org/ I cleaned them up and grouped into mesh assemblies. These files were then oriented, scaled and exported to create the files I uploaded in the model sub-directory.

Chances are that the final VRML files are of little use outside the OpenHRP environment. Consequently, I've made the blender files available for download in my files area. You can find them at the usual place with the file names Blender1.zip through Blender3.zip.

[limor]

Hi Fritzoid,
Have you posted the modified DARwIn / Bioloid gait generator code somewhere?
Have you tried it out on a real Bioloid?

I'm wondering just how much processing power is required to drive the inverse dynamics and ZMP.. would be great if it is able to run on low cost embedded linux