{"id":12279,"date":"2019-03-12T17:20:29","date_gmt":"2019-03-12T15:20:29","guid":{"rendered":"https:\/\/blog.zhaw.ch\/icclab\/?p=12279"},"modified":"2021-03-04T18:45:29","modified_gmt":"2021-03-04T16:45:29","slug":"configuring-the-ros-navigation-stack-on-a-new-robot","status":"publish","type":"post","link":"https:\/\/blog.zhaw.ch\/icclab\/configuring-the-ros-navigation-stack-on-a-new-robot\/","title":{"rendered":"Configuring the ROS Navigation Stack on a new robot"},"content":{"rendered":"\n

Our lab has acquired a new robot as part of its ROS based robotic fleet. We opted with the SUMMIT-XL Steel<\/a> from Robotnik<\/a>; a behemoth compared to our much-loved TurtleBots.<\/p>\n\n\n\n

\"\"
The Summit-XL Steel is advertised to be a great platform for robotic application that require transporting heavy loads (up to 250 kg) such as warehouse automation (retrieved from https:\/\/www.robotnik.eu\/web\/wp-content\/uploads\/\/2018\/07\/Robotnik_SUMMIT-XL-STEEL-01.jpg<\/a>).
<\/figcaption><\/figure><\/div>\n\n\n\n\n\n\n\n

The first vital step for any mobile robot is to setup the ROS navigation stack: the piece of software that gives the robot the ability to autonomously navigate through an environment using data from different sensors. <\/p>\n\n\n\n

A major component of the stack is the ROS node move_base<\/a> which provides implementation for the costmaps and planners. A costmap<\/a> is a grid map where each cell is assigned a specific value or cost: higher costs indicate a smaller distance between the robot and an obstacle. Path-finding is done by a planner which uses a series of different algorithms to find the shortest path while avoiding obstacles. Optimization of autonomous driving at close proximity is done by the local costmap and local planner whereas the full path is optimized by the global costmap and global planner. Together these components find the most optimized path given a navigational goal in the real world. <\/p>\n\n\n\n

Most of the configuration process is spent tuning parameters in YAML files; however, this process is time consuming and possibly frustrating if a structured approach is not taken and time is not spent reading into details of how the stack works. Many helpful tuning guides are already available: Basic Navigation Tuning Guide<\/a> and ROS Navigation Tuning Guide<\/a> to name a few (we encourage anyone new to the stack to thoroughly read these). Hence, this post will aim to give solutions to some less-discussed-problems. <\/p>\n\n\n\n

Configuring a 2-LIDAR setup<\/strong><\/font><\/h2>\n\n\n\n

To give the robot a full 360 degree view of its surroundings we initially mounted two Scanse Sweep LIDARs<\/a> on 3D-printed mounts<\/a>. One of them recently broke and was replaced with a LDS-01<\/a> laser scanner from one of our TurtleBot3s. Each laser scanner provides 270 degrees of range data as shown in the diagram below. Apart from the LIDARs, the robot came equipped with a front depth camera.<\/p>\n\n\n\n

\"\"
The front and back laser scanner are located at opposite edges of the robot and each provide a field of view of 270 degrees (retrieved from https:\/\/www.roscomponents.com\/815-thickbox_default\/summit-xl-steel.jpg<\/a>).<\/figcaption><\/figure>\n\n\n\n
\"\"
Rear Sweep Scanse LIDAR on a 3D-printed mount (in blue).<\/figcaption><\/figure><\/div>\n\n\n\n

The biggest challenge in setting up our own LIDARs was aligning all three range sensors: front orbbec astra pro 3d camera<\/a>, front LIDAR, and rear LIDAR. The key here is to make precise coordinate measurements of the mounted laser scanner with respect to the origin of the robot i.e. the base_link<\/code> frame.<\/p>\n\n\n\n

\"\"
Screenshot of RViz showing alignment of all three range sensors on the robot: blue points = rear LIDAR, orange points = front LIDAR, and white points = front depth camera.<\/figcaption><\/figure>\n\n\n\n

Merging laser scans<\/strong><\/font><\/h2>\n\n\n\n

Both AMCL<\/a> and GMapping<\/a> require as input a single LaserScan<\/code> type message with a single frame which is problematic with a 2-LIDAR setup such as ours. <\/p>\n\n\n\n

To solve this issue we used the laserscan_multi_merger<\/code> node from ira_laser_tools<\/a> to merge the LaserScan<\/code> topics to scan_combined<\/code> and to the frame base_link<\/code>. The relay<\/a> ROS node would be insufficient for this issue since it just creates a topic that alternately publishes messages from both incoming LaserScan<\/code> messages.<\/p>\n\n\n\n

Note there is a known bug with the laserscan_multi_merger<\/code> node which sometimes prevents it from subscribing to the specified topics when the node is brought up at the same time as the LIDARs (i.e. same launch file). A simple fix we found is to use the ROS package timed_roslaunch<\/a> which can delay the bring-up of the laserscan_multi_merger<\/code> node by a configurable time interval.<\/p>\n\n\n\n

Clearing 2D obstacle layer (ObstacleLayer<\/code>) on costmap<\/strong><\/font><\/h2>\n\n\n\n

“Ghost obstacles” (as the online community likes to call them) are points on the costmap that indicate no-longer-existing obstacles. This issue was seen with the Scanse Sweep LIDARs and is prevalent among cheaper laser scanners. Many possible reasons exist as to why this occurs, although the most probable cause has to do with the costmap parameter raytrace_range<\/code> (definition provided below) and the max_range<\/code> of the LIDAR.<\/p>\n\n\n\n

raytrace_range –The maximum range in meters at which to raytrace out obstacles from the map using sensor data.<\/strong><\/p>source – http:\/\/wiki.ros.org\/costmap_2d\/hydro\/obstacles<\/a>

<\/cite><\/blockquote>\n\n\n\n

Here\u2019s a simple example to clarify the issue at hand. An obstacle appears in the line of sight of the laser scanner and is marked on the costmap at a distance of 2 meters. The obstacle then disappears and the laser scanner returns a distance of 6 meters at the original radial position of the obstacle. Ray tracing, which is set to a max distance of 3 meters, is unable to clear these points and thus the costmap now contains ghost obstacles. From this example it is clear the parameter raytrace_range<\/code> needs to be set to a slightly higher value than the maximum valid measurement returned by the laser scanner.<\/p>\n\n\n\n

If the issue persists, the following are a few other costmap parameters worth looking into:<\/p>\n\n\n\n