Heightmap visual is offset from collision object

[osrf-migration]

Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).

---

I've been building a modified DRC robot with 4 wheels and the upper torso. It works just fine on the generic plane, however using terrain maps cause bad behaviour.

I've seen two types of incorrect behaviours which happen when I approach a slope in the drc_terrain:

1. gazebo segfaults on approach about 80% of the time (see the stills attached)
2. the wheeled robot drives up the slope but its body doesnt tilt and is embedded within the visual terrain. It occasionally hops up and down and the arms flay around.
   Here's some stills showing the behaviour:
   http://people.csail.mit.edu/mfallon/share/2012nov/terrainmap_issue/
   Also attached is everything needed to run the system including the modified robot model.

This is the simplest invocation:
roscore
gazebo mit_driving_task_wheeled_robot_terrain.world
rosrun keyboard_teleop keyboard_teleop

Could you give me some feed back on this or do you have a well tested terrain map and robot model combo that I could build off of instead?

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

Most likely the heightmap collision object is offset in one direction.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed priority from "major" to "critical"

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed state from "new" to "resolved"

Fixed in pull request #156

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• set version to "all"

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed state from "resolved" to "closed"

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

• changed state from "closed" to "open"

ran into this issue again with other heightmap files

I believe it's related to the problem described in this ogre thread

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

• changed priority from "critical" to "major"

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

I believe it's the "Terrain Tessellation" problem that was first mentioned in this post

[osrf-migration]

Original comment by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

---

Issue #638 was marked as a duplicate of this issue.

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

Issue #2388 was marked as a duplicate of this issue.

[osrf-migration]

Original comment by ttdm (Bitbucket: TTDM).

---

I believe the offset only exist when using the visual->geometry->heightmep->pos SDF element which seems to be the only way to move (the visual only) of the heightmap (it should be confirmed by the previous reporter if they still remember if it was the case for them).
On the other hand, it's not possible to use either the model->Pose, the link->Pose, collision->Pose or even the collision->geometry->heightmep->pos (which is the counterpart for the collision of what it is possible to use to move the visual) sdf elements with a height-map.
It's also not possible to use the gazeboAPI model::SetPose and related model functions, I did not extend my study to the collisions and link Pose related functions but it's probably going to be the same. All those functions and SDF definitions have been tested using a world plugin and swapping between a box ( for which it worked) and a heightmap.
Edit : gazebo version : 7-0-0 but considering the time stamps on this thread, it should be the same on a more recent version of gazebo.