VRC heightmap problems

[osrf-migration]

Original report (archived issue) by Thomas Koletschka (Bitbucket: thomasko).

---

Given that the other heightmap related ticket was "resolved" and the pull-request merged I'll open a ticket to re-iterate the current heightmap problems:

Texture distortion (or some underlying problem that causes this):

The texture moves with the camera which makes it look like it's ~20cm farther away than it actually is. A video demonstrating the effect of texture moving around, notice how it moves across the edges of triangles (this is using the heightmap with just one texture and no normal map): http://www.youtube.com/watch?v=eC_1MiATQBE

A picture of the stereo point cloud of the ground in front of the robot at the same height of the robot which appears ~20cm below the actual height (red grid is at -0.2m, gray grid at 0m): http://i.imgur.com/d5IxVbb.png

Extremely poor LIDAR performance:

When turning on the LIDAR in vrc world 2 (walking), the real-time factor drops down from ~0.99 to 0.02 (no hands, no rubble). In vrc world 1 it is not as bad, there it only drops about 0.1 (e.g. from 0.5 to 0.4) and in the old world that used drc_terrain I never noticed a difference when enabling the LIDAR as far as I can remember.

The difference between those worlds is that both vrc1 and vrc2 use a heightmap with 513*513 resolution but vrc1 has a map size of 500x500x118 while vrc2 only has a map size of 200x200x46.9. So vrc1 is more than twice as large as vrc2 and has a better performance for LIDAR. Assuming that Gazebo/OGRE creates one vertex per pixel, this means that vrc2 has a higher triangle density than vrc1 which explains why it's slower than vrc1. drc_terrain has a heightmap resolution of 257px and a map size of 2000x2000x500 which is ten times larger than vrc2 and hence explains why those issues didn't arrise with drc_terrain.

I converted the vrc2 heightmap into a triangle mesh, one with 132098 triangles and the other with 526338 to test speed with pure triangle meshes - I'm not sure what triangle count vrc2 has but it should be close to one of them. With the lower resolution triangle mesh my real-time factor only dropped by 0.05 and with the higher resolution mesh it only dropped by 0.1. But again I'm not sure whether either of them is close to the resolution that the heightmap rendered by Gazebo/Ogre has.

Maybe this performance drop might decrease or even disappear when switching to the GPU based LIDAR given that enabling the cameras does not affect performance that much either?

Errors/differences/bugs/.. in collision geometry:

Visual geometry and collision geometry are different at some parts of the terrain, or maybe the collision geometry is buggy. See http://youtu.be/r6aH04E_F_8 and http://youtu.be/TXkw3nV1OR0 for some examples. This makes walking on the heightmap even more difficult and unpredictable than it already is with all the other heightmap related bugs and problems listed above.

Atlas gliding, slipping, falling through heightmap:

Another day, another bug (or at least partially a variant of the one above):
Atlas slips, glides, and/or falls through the heightmap when it gets close to an edge. Example of extreme slipping (or maybe small penetrations that make it slip forward): http://youtu.be/ojSBBKH9Ne8 and an example of atlas falling through the heightmap for several centimeters: http://youtu.be/5fKJtuXpIks

[osrf-migration]

Original comment by Thomas Koletschka (Bitbucket: thomasko).

---

• Edited issue description

[osrf-migration]

Original comment by Thomas Koletschka (Bitbucket: thomasko).

---

@nkoenig @hsu

In an attempt of getting a usable terrain for testing perception and avoiding the lidar performance issue I wanted to test the performance of a triangle mesh as a replacement for heightmap. In order to test an extreme case I used a trimesh [1] with a size of 13*13 meters and a resolution of 250.000 triangles and put 6 of them into the scene in front of Atlas [2] - so that's 1.5 million triangles in front of atlas placed up to a distance of approximately 30 meters, so pretty much all the triangles are within the reach of LIDAR and cameras.

Even though the triangle mesh has a much higher resolution than the heightmap used in vrc world 2, the triangle mesh performs much better than heightmap, especially when using the LIDAR.

Here are some results, both worlds using the same physics settings (the vrc world2 defaults with unbounded update rate):

heightmap (vrc world2 heightmap + atlas, no other objects): 
        atlas standing: 1.45 - 1.5
        both cameras: 1.3   
        lidar: 0.03, 0.02, or maybe lower just not displayed  | lidar hz stays at 40
        atlas levitating: 1.8
        atlas levitating+cameras: 1.6
        atlas levitating+lidar: 0.18
        atlas levitating+lidar+cameras: 0.18 | camera at ~28, lidar at ~36

6*250k trimesh:
        atlas levitating: 1.5
        atlas levitating+cameras: 1.40 | cameras at 14Hz (50% of desired)
        atlas levitating+lidar: 1.2 | lidar at 38Hz
        atlas levitating+lidar+cameras: 1.15-1.20 | cameras at 17Hz, lidar 38Hz
        atlas "standing" (feet are in contact with ground but robot held upright using 'pinned_with_gravity'): 1.15
        atlas "standing" + all sensors: 0.85-0.9 | lidar 35Hz, cameras 21Hz

As you can clearly see, even with unnecessarily high resolution the triangle mesh clearly outperforms the (fairly low resolution) heightmap used in vrc world 2. Besides performance the triangle mesh also has the advantage of not suffering under the distance/texture distortion problem that Gazebo heightmaps have (actually I've also noticed the same texture distortion problem at some parts of terrain while testing cryengine 3 - so this might partially be a problem of the underlying technology used).

The only case where heightmap performs "better" than the trimesh in the above "benchmark" is the cameras' update rate, but this is due to the extremely high triangle count which was chosen as stresstest for LIDAR. Using a more sane, but still high resolution, triangle count of 50k per mesh bumps the camera rate back up to the desired 30Hz.

I haven't had time to test other performance criteria but e.g. dropping atlas onto the 250k triangle mesh still keeps the RTF above 0.9 upon impact.

[1] http://i.imgur.com/JzxjxAE.jpg (exported from an Unreal Development Kit example scene, triangle count reduced to 250k using Meshlab)

[2] http://i.imgur.com/phi42KS.jpg

[osrf-migration]

Original comment by Thomas Koletschka (Bitbucket: thomasko).

---

• Edited issue description

[osrf-migration]

Original comment by Thomas Koletschka (Bitbucket: thomasko).

---

• Edited issue description

[osrf-migration]

Original comment by Thomas Koletschka (Bitbucket: thomasko).

---

• Edited issue description

[osrf-migration]

Original comment by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).

---

• changed state from "new" to "invalid"

Thanks very much for the detailed feedback.

But to help us address the problems you're reporting here, please break this issue up into pieces, one for each distinct problem. We want to each issue to be as small as possible, such that it can be closed by a single fix. As it stands, the variety of problems you're describing will almost certainly require many different things to be done.

[osrf-migration]

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

---

• set version to "all"