0
$\begingroup$

Rosanswers logo

Hi everyone:

I just managed to spawn my NXT robot in a Gazebo empty world, but when I hit play it starts to oscillate around its center of mass (I guess). I recorded a video to show this behavior.


I think this has something to do with collision and/or mass values of the urdf file, but I don't really know, and I thought it would be great to have an answer to this question around here.

Also, if I change the collision parameters of the wheels to match exactly the geometry of the visual ones my robot takes the role of a rocket and disappears in the sky... I think the robot starts to collide with itself (?)

Any ideas?

Thank you very much! :)

Update: here are the robot that oscillates and the robot that flies.

Update 2: the new robot that flies.

Update 3: I was going to post a new question, but I think it's still the same... After I corrected the scale of the tire meshes (actually changed them for cylinder shapes for simplicity) my robot spawns correctly and stays on the ground as someone would expect. But when I tried to move the robot I realized that its center of gravity is misplaced (I think that this was the reason of the oscillation in the first place) because the robot gets knocked over to the left very easily. I don't know why does this happen nor how to correct it, in part because I couldn't find any info on how this CoG is calculated.

Here's the current xacro file of the model. As you can see the robot is built around a link in the very center of the model (ref_0_link).

I took a couple of screenshots showing the physics of my model. Why is that link (?) over there (the one with all those green strings coming out of it) instead of in the center of the model?

image description image description

Thanks! :)

Update 4: Could anyone tell me how this center of gravity is calculated? Or if it's defined somewhere, or what... Maybe then I could fix it, I'm going nuts trying to find a solution. Thanks again!

Update 5: New photo: the blue arrow points to the root link (base_link, a small translucent box) and the grey arrow shows what I suppose is the COM of the robot, given the behavior of the simulation...

image description


Originally posted by Capelare on ROS Answers with karma: 202 on 2012-04-11

Post score: 1


Original comments

Comment by hsu on 2012-04-11:
can you share the model?

Comment by Capelare on 2012-04-11:
There you go, thanks. I suppose that the first one oscillates because it only has one link with collision parameters (base_link), although I don't know how to fix it without it becoming a rocket!

Comment by Capelare on 2012-04-11:
I just discovered the "Show physics" option in Gazebo, and I see that with the second model there's something that is being propelled to the upper right side of the robot. I don't know what it is, though. I'm trying to find out.

Comment by Capelare on 2012-04-11:
I updated the second model because I just realized that the caster_wheel_support_joint needed its own transmission tag, although the flying problem still appears and I haven't identified what causes it.

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

Update:

It appears you have found a bug! The model is is stable for me if I comment out the single line

  <canonicalBody>base_link</canonicalBody>

as you can see in this video, but the model does break if that line is left in the urdf.

While I find out why this is happening, you can comment out the <canonicalBody> tag and things should be a little bit better.

Thanks!


With regards the question on CG location, the tags define the mass properties of the robot. More details of the description can be found through urdf page.

Gazebo does automatic "mass-lumping" between links connected by fixed joints. Therefore, looking at the expanded link tree generated by running

rosrun urdf_parser  urdf_to_graphiz nxt.urdf

For efficiency sake, all of the child links rigidly connected to parent link via fixed joints are lumped into the top parent in the tree. You can also run

rosrun gazebo urdf2model -f nxt.urdf -o nxt.model

and see that the first <body:empty name="base_link"> in nxt.model contains a mass that was the aggregate of all its children as well as multiple <geom> and <visual> from it's fix attached children links.

Hope that makes sense.

That said, does your model still oscillate when you spawn it? I turned off the controllers and things appear stable.


Originally posted by hsu with karma: 5780 on 2012-04-16

This answer was ACCEPTED on the original site

Post score: 3


Original comments

Comment by Capelare on 2012-04-16:
Thanks for your reply! That's what I thought, but how is it that every link has the same inertial tags and the robot is virtually symmetrical, the COM is moved to one side? I don't understand :-\

Comment by Capelare on 2012-04-16:
The robot urdf file is generated by lxf2urdf and has almost a hundred links (for a pretty simple robot that just moves around)... Should I calculate the inertial properties for every link? Should I simplify the robot's definition? Could I just remove the inertial tags for the majority of the links?

Comment by hsu on 2012-04-16:
The visualization in Gazebo shows CG locations of each link separately, the off-sided COM I think you at referring to is not the COM of the whole robot, but just a visualization of the joint connections coming out of the root link.

Comment by hsu on 2012-04-16:
If you remove the inertial tag, the link will be ignored by the simulator. The simulator does lump links connected by fixed joints, so you could have small inertial values for all links connected by fixed joints,except for one link in each group. But ideally, accurate inertia values are preferred.

Comment by Capelare on 2012-04-16:
The root link has only one joint coming out of it, so either I don't understand what you're saying or that doesn't make any sense... And besides that, if I change the root link joint, this red box with axes (idk how to call it) changes it position just a little bit, not fully reflecting the change

Comment by Capelare on 2012-04-16:
@hsu I added a new photo and edited the other two, pointing out with a grey arrow what I think to be the COM of the robot. I just noticed that this thing has green lines for every link unless there's (at least) a continuous joint between them. [...]

Comment by Capelare on 2012-04-16:
@hsu [...] So this is the COM of the main body of the robot, isn't it? So, knowing that this is not the ideal solution, I could just estimate an inertial tag for this big bunch of links... am I wrong? I think that correcting all of the inertial tags for the 60+ links is not an option :-\

Comment by hsu on 2012-04-17:
I replied in the answer. hope that makes sense.

Comment by Capelare on 2012-04-17:
Thanks, it makes perfect sense :) My robot appears stable iif I spawn it with a small -z parameter (e.g. -z 0.02), but it reveals its instability soon after moving it (with nxt_teleop and the controller, for example) or if you spawn it at -z 0.1 or higher...

Comment by Capelare on 2012-04-17:
Could you please test this? I'll be completely shocked if my robot is stable in your simulation and unstable in mine... O.o

Comment by hsu on 2012-04-17:
your controller may be unstable? what controller and controller configurations (e.g. pid gains) are you using?

Comment by Capelare on 2012-04-17:
I don't think so, if I comment out both controller tags of the urdf it shows the same behaviour. Do you get the base_link axes centered if you turn on the Show physics option on Gazebo? Thanks again for your help.

Comment by Capelare on 2012-04-18:
Are you sure about the bug? if you look carefully when you pull the robot upwards and then release it, it bounces a little to the left, so maybe you just got lucky and it's not stable. Try throwing it a little higher and see what happens. Anyway, good luck finding the bug!

Comment by Capelare on 2012-04-18:
Or f you want you can check out the controller plugin I'm writing so you can try things out with the nxt_teleop package instead of having to drop the robot. When you turn right or left you can perfectly see the unstability problem: This is the git repository

Comment by hsu on 2012-04-18:
Sorry, after looking at it in more detail, the controllers are fine, it's the tag the causes the model to roll-over uncontrollably. Also the CG for the base_link is still off-sided; do you expect the base_link CG to be centered on the robot?

Comment by Capelare on 2012-04-18:
Well, it's not that I expected it to be centered, because the inertial tags for all the links are identical (lxf2urdf doesn't bother doing it otherwise because there's no nxt simulator... yet :P). But yes, I'd like it to be centered, after all the robot is symmetrical, as you can see.

Comment by Capelare on 2012-04-18:
BTW what is the purpose of the canonicalBody tag, anyway? I just put it there because it was there in the erratic robot description, but I couldn't find any info about it anywhere. Once again, thanks for your time and dedication!

Comment by Capelare on 2012-04-20:
@hsu (or anyone): where's the origin of coordinates of a link? is it at one corner or in the middle of the link? Maybe there is my error...

Comment by hsu on 2012-04-20:
coordinate systems are explained here: http://ros.org/wiki/urdf.

$\endgroup$
0
$\begingroup$

Rosanswers logo

Also, if I change the collision parameters of the wheels to match exactly the geometry of the visual ones my robot takes the role of a rocket and disappears in the sky... I think the robot starts to collide with itself

This might be because something is in collision, try starting simulation paused (pass in the -u parameter on startup), or spawn your robot at some distance from the ground.


Update: After reviewing the urdf, it looks like you forgot to scale the tire meshes, so they are very large and collides with the ground plane. this urdf should spawn correctly.


Originally posted by hsu with karma: 5780 on 2012-04-11

This answer was NOT ACCEPTED on the original site

Post score: 5


Original comments

Comment by Capelare on 2012-04-11:
Oh, I see that the video only shows up in the preview, and not the final post... let me fix it so you can watch it ;-)

Comment by Capelare on 2012-04-11:
I do both things, btw. It seems that the robot collides with itself, but I can't figure why...

Comment by Capelare on 2012-04-11:
I only had collision meshes on the tires and on the caster wheel because I thought that performance would be seriously affected if all the links had collision meshes... Isn't that right?

Comment by Capelare on 2012-04-11:
Anyway, two of the three collision meshes that I have are misplaced, and the other one is indeed REALLY BIG. I will correct this errors and try your urdf file. Thanks a lot! :)

Comment by tfoote on 2012-04-16:
@Capelare please accept this answer if it solves your problem.

Comment by Capelare on 2012-04-16:
@tfoote I accepted the answer but I cancelled that, because even though this solves a problem I had, it does not solve the question I was really asking. That's the reason I updated the question several times after this answer was given ;-)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.