Home

Dynamic mapping

Action planning of robots and autonomous vehicles is based on maps of their environment. These maps often only contain information about the static environment and ignore dynamic entities. Information about dynamic entities, often moving objects, in the environment can help to improve action planning in robotics.

An approach to gather probabilistic information as well as change rates about the dynamic environment was developed. All entities within a map are probabilistic, containing a value about the probability of their existence. In addition a change rate of these objects is also saved. Dynamic behaviour at certain locations causes dynamic areas to be created. In addition this new information need to be saved somehow into the map. A technique to save thisinformation, as well as to reuse existing maps and extend them was implemented. This project is all about gathering informations, evaluating these informations regarding their dynamic aspect, generating dynamic areas and store probabilistic dynamic informations and change rates in maps.

A software module called ''dynamic mapping'', which is designed to gather and process probabilistic information and change rates about the dynamic environment was developed. This module in cooperation with other modules (all available at the git repository on this site) and a robotic software framework called ROS is able to perform dynamic mapping while autonomously driving to a certain destination. A small robot, equipped with a laser scanner which provides informations about the environment, was used to experimentally examine the behaviour of the dynamic mapping software module.

Compiling and running dynamic mapping

Catkin vs Rosmake

In the ROS version I used a build system named ''catkin'' is used. With catkin, all catkin-modules are compiled by calling ''catkin_make''. In each module a ''CMakeLists.txt'' and a ''package.xml'' file must exist. How ''catkin'' works in detail is described in catkin.

In earlier versions of ROS, the build system ''rosmake'' was used. I also use some legacy modules in this project, which still use ''rosmake''. Each module has to be compiled on its own with command ''rosmake''. How ''rosmake'' works in detail is described in rosmake.

The following packages respectively modules use ''catkin'':

• dynamic_mapping
• p3at
• p2os-master
• rviz
• RosAria

The following packages respectively modules use ''rosmake'':

• gmapping
• LMS1xx
• navigation stack

To build the catkin modules navigate into the src folder, the root folder of the repo and then one level up (cd ..). Then call ''catkin_make''.

To Build the rosmake modules navigate into each one and call ''rosmake''. In the example of the LMS1xx package call: ''rosmake LMS1xx LMs1xx''

Running dynamic mapping

I strongly recommend to run the different ROS modules on two different hosts. The robot on its own will get performance problems otherwise and a second computer is needed anyway if rviz is used. Because a screen is needed to visualize the rviz interface. As a requirement the two computers need to be connected over a WLAN connection. The following steps are needed to run the dynamic mapping including all necessary modules (the two hosts are named ''robot'' and ''pc''):

1. Run ''dynamic_mapping_robot.sh'' on robot
2. Run ''dynamic_mapping_pc.sh [-n] [-f filename]'' on pc

Important is that we need to wait until ''dynamic_mapping_robot.sh'' has loaded all modules, thus the last module p2os_urdf was started before we run ''dynamic_mapping_pc.sh'' on pc.

The script ''dynamic_mapping_robot.sh'' loads the following modules in the given order:

1. roscore (ROS core module)
2. RosAria (ROS robot drivers)
3. LMS1xx (Laser Scanner driver)
4. gmapping (SLAM module)
5. tf (static transform base_link to laser)
6. transform_broadcaster (transform between maps and update_area)
7. safety_navigation (safety module)
8. p2os_urdf (robot model)

Most of the modules have configuration parameters which can be used to change their behaviour. If this is required they can be added respectively changed directly in the script. This may be particularly interesting in case of the gmapping module, because there are various parameters which can be changed.

The script ''dynamic_mapping_robot.sh'' loads the following modules in the given order:

1. rviz (roboter visualisation)
2. dynamic_mapping (import, export, processing dynamic maps)
3. keyboard_control (control the robot by keyboard) keyboard control is started if no argument was set
4. navigation stack (autonomous control) (navigation stack is started by argument ''-n'')

The user has the choice if he wants to use the keyboard control module or the navigation stack. Only use one of them can be used simultaneously. The script ''dynamic_mapping_robot.sh'' is called without any parameters to start the keyboard control module or with parameter ''dynamic_mapping_robot.sh -n'' to start the navigation stack.

If a map was once exported and should be imported later again for further mapping, this import can be done by using the option ''-f'' and setting the desired file name of the map file. After this the robot location has to be set either by rviz ''Set initial pose'' feature or from an external module by publishing the robots location within the map on the ''initialpose'' topic. After the initial position of the robot was set, the map merging starts and dynamic areas are displayed respectively changed and generated.

If the dynamic mapping was finished the map can be exported by calling:

rosrun dynamic_mapping map_export [-f filename] [-g]

The file name can be chosen by using the option ''-f'' and the desired file name. The option ''-g'' exports the map without dynamic areas as grey valued map.