WorldMap interface

If you read this, please notice I write it as I'm thinking about how the world can be defined. (so we forget about working only on tracks)

The two options bellow try to take into account the "car park" problem, since car parks can't really be defined as a network of roads.

Option 1

2.5 dimensions, vectorial definition of road areas and other areas.

• The ground is an height-map.
• By default, everything is covered with a given default material (for example "grass").
• Then we define layers of other materials' areas:
  • an area is a 2D polygon projected onto the ground from above.
  • it has properties:
    • Is it drivable?
    • Physical properties
    • Graphical look
• Then we add 3D models of buildings, parked vehicles, [...] on top of the height-map .

Option 1b: we can discretize the areas of materials by making a "material map".

note for readers:

• an height-map gives the height of the ground for every x,y.
• a material-map gives the material of the ground for every x,y.

Option 2

• The world is a big 3D mesh (including ground, buildings, everything).
• Roads are triangles of this mesh which are applied a material with flag "is_drivable"

But the world is no more two-dimensional, is it manageable by the driving robot? Yes he can just ignore the "z" of the polygons. Later, if the robot handles the 3D, it become possible to make bridges, etc.

(WDB:) Note: There are TORCS tracks having bridges and tracks beeing non planar (i.e. wheel-2). This is handled by the physics simulation, not by the robot itself.

Option 3

(WDB:) Combine Option 1 and 2: Use Option 2 as base for viewers and for "offroad" driving, but use the vector based description of roads for the simplifying of the physics simulation of road based driving. Why? Option 2 should be the natural way for the graphics part. Here we can use the collada format and all the code existing for it. For offroad driving we can use a physics simulation based on the ODE engine. The vector based driving is for many (real world) situations a good description, easy to connect with the algorithms of navigation systems, urban driving, traffic rules etc. We can use a physics simulation based on the TORCS engine. We can use a program like trackgen to get the 3D-mesh of the vector based track description. Option 2 doesn't mean one 3D-mesh, it is possible to have a set of 3D-meshes, easily to switch on/off parts of the world being relevant for vision systems but not for the collision calculation of the physics system. With this approach we can combine the best of both worlds. We can make robots switch between roadbased and offroad driving. In fact we could scale down the vector based description to be defined one to one on the triangles of the 3D mesh, if needed to make complex transitions between road based and offroad regions/driving.

I also like the combination. I think representing urban driving maps and obstacles and road protocols is quite natural in 2-D. If we want to overlay that 2-D info with 3-D info, and represent it all in the physics engine, that is fine! I don't think we need to switch modes in the robot or simulator between offroad and onroad scenarios. Just because our maps are 2-d doesn't mean the robot ignores that it is in a 3-d space: it should try to keep the car upright, etc. We will have a good physics engine, so we may as well use it as much as possible. It is easy to add data to a system. We could even have some code take our 2-D roads and put hills and potholes and other obstacles. Motion planning is a series of layers, so just because most of it happens in 2-D doesn't mean that there won't be some 3-D elements. Keithcu 04:47, 16 July 2008 (EDT)