Gazebo: robot oscillates after spawn

asked 2012-04-11 07:20:08 -0600

202 ●14 ●17 ●28

updated 2012-04-16 08:04:26 -0600

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

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

edit retag flag offensive close merge delete

Comments

can you share the model?

hsu ( 2012-04-11 07:22:27 -0600 )edit

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!

Capelare ( 2012-04-11 07:39:59 -0600 )edit

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.

Capelare ( 2012-04-11 07:47:11 -0600 )edit

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.

Capelare ( 2012-04-11 08:49:15 -0600 )edit

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2012-04-16 06:45:05 -0600

hsu
5735 ●31 ●62 ●89

updated 2012-04-18 08:19:10 -0600

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 <inertial> 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.

edit flag offensive delete link

Comments

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 :-\

Capelare ( 2012-04-16 06:58:25 -0600 )edit

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?

Capelare ( 2012-04-16 07:06:29 -0600 )edit

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.

hsu ( 2012-04-16 07:24:10 -0600 )edit

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.

hsu ( 2012-04-16 07:42:58 -0600 )edit

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

Capelare ( 2012-04-16 07:56:57 -0600 )edit

@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. [...]

Capelare ( 2012-04-16 08:19:23 -0600 )edit

@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 :-\

Capelare ( 2012-04-16 08:23:30 -0600 )edit

I replied in the answer. hope that makes sense.

hsu ( 2012-04-17 08:01:52 -0600 )edit

see more comments

answered 2012-04-11 07:23:57 -0600

hsu
5735 ●31 ●62 ●89

updated 2012-04-11 09:35:18 -0600

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.

edit flag offensive delete link

Comments

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 ;-)

Capelare ( 2012-04-11 07:26:36 -0600 )edit

I do both things, btw. It seems that the robot collides with itself, but I can't figure why...

Capelare ( 2012-04-11 08:55:57 -0600 )edit

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?

Capelare ( 2012-04-11 12:29:39 -0600 )edit

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! :)

Capelare ( 2012-04-11 12:30:49 -0600 )edit

@Capelare please accept this answer if it solves your problem.

tfoote ( 2012-04-16 06:26:38 -0600 )edit

@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 ;-)

Capelare ( 2012-04-16 07:39:34 -0600 )edit

add a comment

answered 2016-12-21 05:08:52 -0600

PrasadNR
37 ●5 ●7 ●11

I am not sure if this is the proper answer; But, I am unsure if it is because of the sequence of connection; Spawning model and then connecting or opening the socket and then spawning. For me, this is happening when I spawn the second robot.

https://vimeo.com/194174316 https://vimeo.com/192273295

The same model when spawned for the first time works properly; I believe that the issue is because of connection. I hope this helps someone (including me) greatly if this answer is suitably edited and posted.

edit flag offensive delete link

add a comment

Gazebo: robot oscillates after spawn

Comments

3 Answers

Comments

Comments

Question Tools

Stats

Related questions

Gazebo: robot oscillates after spawn edit

Comments

3 Answers

Comments

Comments

Question Tools

Stats

Related questions

Gazebo: robot oscillates after spawn