Provide a complete occupancy grid/octomap of the simulated environment

[severin-lemaignan]

Scripts that control aspects of the simulation would benefit of accessing a good model of the environment, like 2D occupancy grid or, even better, an octomap.

One typical application could be crowd/swarm/flock simulation: if you want to simulated a crowd of humans moving in your simulation, the crowd simulator (typically, an external application that interface with MORSE through the socket API) need a dynamic model of the simulated environment (where are the walls, the objects like furnitures, the robots, etc.).

This could alos be useful to introspect/monitor the simulation, or extract metrics on the robot behaviours.

Means to implement such a feature are not clear. The "naive" approach (using a laser scanner/kinect/velodyne sensor, taking samples at various random locations in the scene, and interpolating them into a dense map) seem inefficient, but may still be useful to prototype.

A better implementation is likely to require some dedicated OpenGL shaders. It could also be interesting to investigate projects like "Blender for Architecture" which may have tools to take slices of a scene.

This feature request is part of the MORSE for HRI 2014 WS outcomes

[marc-hanheide]

a probably sufficient solution for 2D maps would be to:

• create an orthographic camera that captures the whole scene from top view (above the scene, or close to the ceiling of a closed room)
• use the z-Clipping of that camera to ignore the floor

In high-enough resolution that gives a decent rendering of a gridmap with walls. This is quite efficient I believe (we could even set the camera to only render wireframes, as only the boundaries are relevant), and very easy to implement, right? Some post-processing would allow to convert it into a e.g. a ROS costmap for navigation. Some convenience API that sets rendering parameters to create such a map with the right scale etc. could prove useful.

Here's an example rendered by BGE:

[adegroote]

Using "sensor" to generate map of the environment for this purpose looks strange for me.

We have the whole model of the world, being in blender format, collada or whatever you want. One tool can read this description and do the needed transformation, which will be relatively specific to each model.

Another option is to extract it at runtime, we have all the bounding box, and we can simply "synchronise" non-static object (in the same way we are doing for multi-robots simulation, or even now in case of multi-scene for multi camera resolution) (we can assume that bouding box won't change as far as we are not using soft bodies).

If more information are need (more semantic one), we can add some properties and sync them also.

[marc-hanheide]

I'm not quite sure I understood all of @adegroote suggestion correctly, but here's my view:

• We are actually generating many of our worlds programmatically in builder scripts (including walls, etc), because we are interested in experiments in dynamic worlds (or at least random worlds, that are generated automatically). Hence, just generating a map from a static blender file is not an option and also inconvenient for other users, who would just want to "plug in" a crowd simulation.
• The bounding boxes could probably be used to create a (3D) map, but then it would still require an implementation of some (simplified) rendering (or rasterisation at least), or did I miss a point? Wouldn't it then be easier to use out-of-the box methods for that? Also, the bounding box can be quite a bad approximation in various cases, isn't it?
• Having a "2D map sensor" would also prove useful for many SLAM/navigation tests, where people can use the MORSE 2D map sensor as a ground truth representation of a dynamic/random world.

Just my two cents.