Costmap configuration

I created a new file in the itesm_demo package in order to include all of the configuration files related to the configuration of move_base.

$roscd itesm_demo
$mkdir config
$cd config

I created four files in this folder. The description of each of them follows:

1. costmap_common_params.yaml: Parameters that are common both for local and global costmaps:


obstacle range: determines the maximum range sensor reading that will result in an obstacle being put into the costmap.
raytrace range: determines the range to which we will raytrace freespace given a sensor reading.

footprint: in the case of specifying the footprint, the center of the robot is assumed to be at (0.0, 0.0) and both clockwise and counterclockwise specifications are supported.

Inflation radius: The inflation radius should be set to the maximum distance from obstacles at which a cost should be incurred.

2. global_costmap_params.yaml: long term plans over the entire environment


global frame: defines what coordinate frame the costmap should run in
robot base frame: defines the coordinate frame the costmap should reference for the base of the robot.
static map: determines whether or not the costmap should initialize itself based on a map served by the map_server.

3. local_costmap_params.yaml: local planning and obstacle avoidance

Rolling window: parameter to true means that the costmap will remain centered around the robot as the robot moves through the world.

4. base_local_planner_configuration.-yaml: The base_local_planner is responsible for computing velocity commands to send to the mobile base of the robot given a high-level plan

Successful map

The map created today seems to be fairly coherent. In order to create it I drove the robot around the hallway. Here it is:

Mapping

Today I could make a more or less coherent map of lab conditions. The problem is that my lab's conditions aren't ideal at all ... However, the overlapping of the map, which was the main issue to be solved, seems to have disappeared.

What I did this time was to use the original RosAria node since the one modified by the sscrovers team seems to throw odometry errors due to the introduction of an additional function (update). I will post later my comments concerning this code.

What I did afterwards, was to verify that the cmd_vel message published by the teleoperation node coincided with the one to which RosAria node subscribes to. In this case the specific name of the topic is /RosAria/cmd_vel and its type is geometry::msg.

Tomorrow I will physically construct a map with ideal conditions in order to verify that the odometry issue isn't present at the original RosAria node.