Ros. Navigation stack

This article will look at the approaches and libraries provided by ROS for solving problems of autonomous and not very navigation.

There will also be considered several packages specific for anthropomorphic robots. Any robot (surely even a machine with a mid-powerful on-board PC running Linux and a couple of webcams) will surely find something for themselves here.

If the hardware is too weak for such calculations, you can use the distribution of ROS, which allows the nodes on different machines to interact with each other. A similar option is described here .

Tesarus

Obstacle map (Occupancy Map, Grid)

A two-dimensional discrete map, in which each cell can be in one of three states:

Point Cloud (PointCloud)

In ROS, point clouds exist mainly in the form of sensor_msgs / PointCloud2 .

Dense point cloud

Analogue to Occupancy Grid, but in 3D.

In this article, the default will be the implementation from the Octomap library.
A good analysis of the library in this presentation .

Concept nodes / topics / subscribers

In short, you can run your program in the context of ROS, where it will be a node (Node).
There are also Topics. These are sort of named boxes into which nodes can add and retrieve messages of various types (for example, objects of types geometry_msgs :: Pose, sensor_msgs :: PointCloud2, nav_msgs :: Path, and many others).

Any of the nodes can publish to any topics, as well as read messages from any topics.
Nodes work asynchronously from each other.

If not quite briefly, then

• tutorials
• roscpp

Ros

Robot operating system is a very convenient platform for the implementation of robotic projects.

• Successful package concept (you can use the library functionality, simply by running the appropriate node)
• Provides many needed packages for robotics
  In particular, the stacks are well developed:
  
  • Navigation
  • Localization
  • Mapping (SLAM algorithms)
• Provides visualizers, a convenient concept for messages and subscribers, and much more.

Details

SLAM (with English. Simultaneous localization and cartography)

For autonomous navigation, and indeed anything that requires complete information about the environment, you need a map of the environment itself.

For these tasks, a map in the form of a cloud of points is well suited, from which you can later obtain other map options (dense point cloud, OccupancyGrid).

Vision-based SLAM algorithms allow you to build an environment map and approximately estimate your location in it.

At the entrance

Data from sensors to help assess the location.

For example:

• Ins
• Motor data
• etc.

Data from Vision Sensors

RGB-D Camera

• Representatives: Kinect, Real Sence, Asus Xtion
• Provides RGB snapshot and depth map
• Well supported by small libraries.
• Gives acceptable accuracy (depending on the distance. From 1 mm to 5 cm)
• Range 4 meters
• Blind zone 0.5 meter
• sensor_msgs / PointCloud2

Stereo camera

• High range
• Virtually no blind spot
• Accuracy is lower than RGB-D cameras
• A couple of webcams are not a good stereo camera ( but what the hell is not joking )

Lidar

• Very high range
• No less high cost
• sensor_msgs / LaserScan

At the exit

• Environment Map
• Location approximation

SLAM packages in ROS

Note : in ROS you can receive point clouds from stereo cameras or RGB-D cameras. In turn, point clouds can be converted to LaserScan, which is the running format of ROS messages for lidars and is received by some of the packages described below.

This means that having a stereo camera on hand, you will most likely be able to use SLAM algorithms that receive data from Lidars or RGB-D cameras. Similarly for RGB-D cameras, you can use them as Lidars.

rtabmap_ros

ROS package providing wrapper over rtabmap library . Probably the most popular, easy to use and versatile package.

• Quality documentation
• Supports many sensors as data sources (RGB-D range of cameras, stereo cameras, lidars)
• Moderately demanding of resources, even when creating large maps (enough laptop with an Intel Core i3 + 4 GB RAM)
• It has many interesting settings that affect the speed of work / quality
• Provides many advanced features.
  For example:
  
  • builds an obstacle map by projecting groups of points, starting at a certain height
  • has integration with move_base (see below)
  • has a segmentation node of a point cloud into 2 other clouds (obstacles and earth)
• Integration with the Octomap library (special structures for creating, storing and processing dense point clouds)

hector_slam

SLAM algorithm that builds a 2D obstacle map.
By default, it uses data from lidar, but
with the same success, it can input data from a stereo camera, an RGB-D camera to the input (see the note at the beginning of the chapter).

Close relatives: slam_gmapping .
Surely these are the most lightweight implementations of SLAM algorithms.

Elasticfusion

• build meshes
• high resource requirements (GPU)
• Does not have a package in ROS

This library is well reviewed in this article .

Approaches to solving the problem of autonomous (and not so) navigation

In this section, we will analyze the main approaches to solving the above problem, which ROS provides. The official tutorial presents only a small part of them. For a number of robots there are ready-made solutions (sections 6.2 - 6.6 by the link above). I also advise you to watch this link . Perhaps it makes sense to rewrite their code a bit, if your robot looks like one of the list presented there.

There are also a number of packages not mentioned in the sources above. Especially solutions for copters.

Obstacle Map Planning (OccupancyMap)

This approach allows us to solve the problem of navigation on the plane, which is quite simple in an algorithmic sense.

The obstacle map (see in the article's thesis) can be obtained from a point cloud in several ways:

• Based on a slice at a certain height from a point cloud
• How is the projection of all points on the plane z = 0 starting from any given height z =? ..
  This option is provided by rtabmap.
  It has many parameters, like this:
  
  • allowable tilt angle "plane"
  • the number of points near that should be considered an obstacle
  • much more
• Some implementations of SLAM algorithms initially build only an obstacle map (see above).

ROS concept move_base

Good for wheeled robots. This is the ROS concept, which consists of 2 gliders.

Global planner

Looks for a global route on the Obstacle Map as a line.

Local planner

The calculation of speeds and angles falls on a local glider, so as to avoid collisions.

Next, the speed and angles are fed to the node that controls the robot. Well suited for wheeled platforms.

footstep_planners

This approach is designed mainly for anthropomorphic robots. One of the scenarios for using an obstacle map in the context of navigation and movement of an anthropomorphic robot is to build a safe trajectory of steps for the robot, which it can subsequently follow.
Then the trajectory in the form of a set of feet goes on execution of the robot.

The use of this option is possible if the robot controller can "perform" tasks of the form "to occur at a point with given coordinates."

In my opinion, when planning, the equilibrium conditions of the robot should be taken into account, although planning is carried out from a set of "safe steps". Or, when implementing a step, the controller of the robot must evaluate the ability to realize it without falling.

footstep_planner & humanoid_navigation

footstep_planner is part of the solution for humanoid_navigation for navigating an anthropomorphic robot in a known environment.

footstep_planner provides the ability to plan a route in the form of a set of foot positions leading from the starting position to the final position.
Planning is done on a 2D obstacle map.

It should be noted that this package provides many necessary settings, which allows it to be used on almost any anthropomorphic robots.
Starting with the physical parameters of the feet and their positions relative to each other at a step,
ending with the choice of search algorithm used when planning.

Navigation in dense (and not so) point clouds

Vigir_footstep_planner

This is the ideological successor footstep_planner'a in 3D space. With it, you can lay a route directly in dense clouds of points. Included - a plugin for Rviz, allowing you to edit the resulting route.

Details in the publication

3D navigation

The extension of the move_base described above is 3D with collision checking. A model robot and a dense 3D environment map are used.

Interesting publication on this package

Move it

Package planning of complex movements for robots of any design. The robot is represented as a model, taking into account all moving parts and restrictions on their movement. Further, it is possible to calculate the trajectory of all the limbs of the robot during its transition from one state to another. It is possible to take into account collisions with the environment in the form of dense clouds of points (by Octomap).

In the documentation for MoveIt, you can find a number of models that can be exported and played with them. Among tutorialov this one is good, showing the work with the library from C ++ code.

Interesting links

Qualitative analysis of SLAM algorithms (English)

• Book Probabilistic Robotics
• Course on SLAM algorithms and navigation
  Throughout the course mate thoroughly versed. base SLAM algorithms.
  As practical tasks - implementation from 0 on Python with visualization.

Mentioned in the article

• 3D mapping with Octomap
• MoveIt tutorials
• Ros robots
• ROS navigation wiki