# ROS1 Navigation Stack Integration¶

The current page presents a working example of integrating the SLAMcore SLAM algorithms into the ROS1 Navigation stack and using it as the core component to map the environment as well as provide accurate positioning of the robotic platform.

## Goal¶

The goal of this demonstration is to use the SLAMcore SDK as the main source of positioning during navigation and also use it for mapping the environment before the navigation. These two tasks have traditionally been handled by components such as AMCL and gmapping respectively, both of which, by default, use a 2D laser scan information for achieving their goal.

Instead, we’ll be using the 2D Occupancy Mapping capabilities of the SDK to generate the initial occupancy grid map and we’ll be using our SLAM positioning to localise in that map.

## Hardware Setup¶

We are using the Kobuki robotic platform, the D435i camera and the NVIDIA Jetson NX during this demonstration. We’re also using a custom mounting plate for placing the board and the camera on the robot.

Fig. 51 Main setup for navigation

## ROS1 Navigation Stack Setup¶

Traditionally the ROS1 navigation stack, move_base, requires the following components to be in place:

• An occupancy grid map of the environment, either generated ahead of time, or live.

• A global and local planner which guide your robot from the start to the end location. Common choices for these are navfn and DWA as the global and local planner of choice.

• A global and local costmap which assign computation costs to the aforementioned grid map so that the planner chooses to go through or to avoid certain routes in the map.

• A localisation module, such as AMCL or Cartographer

As discussed earlier, we’ll be using our software to generate a map of the environment before the navigation as well as localising the robot in the environment. On top of that, we’ll use the GlobalPlanner and the TebLocalPlanner instead of navfn and DWALocalPlanner respectively since this combination produced the best results during navigation. Lastly, we will be using the local point cloud published by our software for obstacle avoidance with costmap2D’s obstacle layer, as detailed in the Obstacle Avoidance section.

Fig. 52 Slamcore integration into ROS1 Navigation Stack

## Outline¶

Following is the list of steps for this demo. We’ll delve into each one of these steps in more detail in the next sections.

1. Set up Dependencies

2. [OPTIONAL] Run Visual-Inertial-Kinematic Calibration, to improve the overall performance.

3. Compute the slamcore/base_link ➞ base_footprint Transformation

4. Record Dataset to Map the Environment by teleoperating your robot.

5. Create Session and Map for Navigation , based on the map of the previous step

6. [OPTIONAL] Edit the Generated Session/Map, in case of small inaccuracies or artifacts.

7. Launch Live Navigation , based on the generated session file, using the kobuki_live_navigation.launch file.

8. [OPTIONAL] Interact with the Navigation Demo, using navigation_monitoring_slamcore.launch

Here’s also a graphical representation of the above:

Fig. 53 Outline of the demo

## Set up Dependencies¶

### Set up Binary Dependencies¶

See the Getting Started page to install the “SLAMcore Tools” and the “ROS1 Wrapper” Debian packages. We also have to set up the RealSense D435i as described in Setting up a Camera.

We also need to install a series of packages using apt.

### Set up ROS1 work workspace¶

You have to create a new ROS1 workspace by cloning the ros1-examples repository. This repository holds all the navigation-related nodes and configuration for enabling the demo. Before compiling the workspace, install vcstool which is used for fetching the additional ROS1 source packages.

In order to communicate with the Kobuki, you also need to set up the appropriate udev rules.

## Run Visual-Inertial-Kinematic Calibration¶

To increase the overall accuracy of the pose estimation we will fuse the wheel-odometry measurements of the robot encoders into our SLAM processing pipeline. This also makes our positioning robust to kidnapping issues (objects partially or totally blocking the camera field of view) since the algorithm can now depend on the odometry to maintain tracking.

To enable the wheel-odometry integration, follow the corresponding tutorial: Wheel Odometry Integration. After the aforementioned calibration step, we ended up with the following VIK configuration file:

## Record Dataset to Map the Environment¶

In order to autonomously navigate the environment, we first need to generate a map of it. To do that, we’ll be using the run_dataset_recorder.launch script to capture a dataset that contains visual-inertial, depth as well as kinematic information. We’ll also use the kobuki_live_teleop_joy.launch script to teleoperate the robot using a PS4 Joystick.

You now have to process this dataset and generate the .session file. In our case, we compressed and copied the dataset to an x86_64 machine in order to accelerate the overall procedure.

$tar cvfz 20210505-dataset.tgz 20210505-dataset/$ rsync --progress -avt 20210505-dataset.tgz <ip-addr-of-x86_64-machine>:


## Create Session and Map for Navigation¶

Once you have the (uncompressed) dataset at the machine that you want to do the processing at, use the slamcore_visualiser to process the whole dataset and at the end of it, save the resulting session.

$# Launch slamcore_visualizer, enable mapping features - -m$ slamcore_visualiser dataset \
>   -u 20210505-dataset/ \
>   -c /usr/share/slamcore/presets/mapping/default.json \
>   -m


Note

Refer to Step 2 - Prepare the mapping configuration file in case you want to tune the mapping configuration file in use or include the VIK configuration parameters.

### Edit the Generated Session/Map¶

You can optionally use slamcore_session_explorer and the editing tool of your choice, e.g. Gimp to create the final session and corresponding embedded map. See SLAMcore Session Explorer for more. When done, copy the session file over to the machine that will be running SLAM, if not already there.

## Specify the Session and the Configuration File Paths¶

The final step is to indicate the paths to the session file and to the configuration file. Additionally, if integrating wheel odometry, you can define the wheel odometry topic. The launchfile for navigation, kobuki_live_navigation.launch, reads these parameters from the environment variables SESSION_FILE, CONFIG_FILE and ODOM_READING_TOPIC respectively.

• The session file was generated and copied to the Jetson NX in the previous step.

• For the configuration file, you can use one of the presets, found at /usr/share/slamcore/presets/ or, if you are also integrating wheel-odometry information as shown in section Run Visual-Inertial-Kinematic Calibration, we will send you a new JSON configuration file with wheel-odometry in mind.

$# Edit the nav-config.sh file created earlier$ # see "Compute the slamcore/base_link ➞ base_footprint Transformation"
$export SESSION_FILE="/path/to/session-file"$ export CONFIG_FILE="/path/to/config-file"
$export ODOM_READING_TOPIC="/odom"$ # source nav-config.sh again for the changes to take effect
$source nav-config.sh  ## Launch Live Navigation¶ With the previous pieces in place, we are now ready to start the autonomous live navigation. 1. Launch kobuki_live_navigation.launch 2. Launch a teleoperation node, in case you have to manually drive the robot around for a short while until it relocalises in the session of the previous run. 3. Launch navigation_monitoring_slamcore.launch to visualise the process. Note If you have an external monitor connected to your Jetson NX, you can also run the “Visualisation Machine” commands along with the rest of the instructions on the Jetson NX itself. This demo assumes that the visualisation, and the processing (SLAM and navigation) happen on separate machines (a SLAM Machine and a Visualisation Machine). Thus, refer to Remote Visualisation of the Navigation Demo on how to set up remote visualisation using rviz and view the navigation on your x86_64 machine. $ roslaunch ros1_examples kobuki_live_navigation.launch
... logging to /home/slamcore/.ros/log/187b968c-b1be-11eb-a1ef-d8c0a6261b17/roslaunch-nikos-nx2-28609.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://nikos-nx2:46867/

...


And on a separate terminal,

$roslaunch ros1_examples kobuki_live_teleop_key.launch kinematics:=false SUMMARY ======== PARAMETERS * /keyop/angular_vel_max: 6.6 * /keyop/angular_vel_step: 0.33 * /keyop/linear_vel_max: 1.5 * /keyop/linear_vel_step: 0.05 * /keyop/wait_for_connection_: True * /rosdistro: melodic * /rosversion: 1.14.10 NODES / keyop (kobuki_keyop/keyop) ROS_MASTER_URI=http://localhost:11311 ^[[Bprocess[keyop-1]: started with pid [25805] [ INFO] [1620666607.587512385]: KeyOpCore : using linear vel step [0.05]. [ INFO] [1620666607.591905406]: KeyOpCore : using linear vel max [1.5]. [ INFO] [1620666607.592041775]: KeyOpCore : using angular vel step [0.33]. [ INFO] [1620666607.592124614]: KeyOpCore : using angular vel max [6.6]. [ WARN] [1620666607.603671407]: KeyOp: could not connect, trying again after 500ms... [ INFO] [1620666608.104021379]: KeyOp: connected. Reading from keyboard --------------------------- Forward/back arrows : linear velocity incr/decr. Right/left arrows : angular velocity incr/decr. Spacebar : reset linear/angular velocities. d : disable motors. e : enable motors. q : quit  $ roslaunch ros1_examples navigation_monitoring_slamcore.launch

SUMMARY
========

PARAMETERS
* /rosdistro: melodic
* /rosversion: 1.14.10

NODES
/
rqt (rqt_gui/rqt_gui)
slam_visualiser (rviz/rviz)

ROS_MASTER_URI=http://nikos-nx2:11311

process[slam_visualiser-1]: started with pid [287]
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-berger'
INFO | ${node} | /tmp/binarydeb/ros-melodic-rviz-1.13.17/src/rviz/visualizer_app.cpp:114 | 1620671623.758027686 | rviz version 1.13.17 ...  ### Interact with the Navigation Demo¶ At first, we may need to teleoperate the robot manually, until the SLAM algorithm relocalises. We can see that the relocalisation took place by looking at the rviz view where the local and global costmaps start getting rendered, or by subscribing to the /slamcore/pose where we start seeing incoming Pose messages. This is how the rviz view will look like after the robot has relocalised. Fig. 54 rviz view during navigation ### Waypoint Navigation¶ Aside from individual navigation goals which can be set using the 2D Nav Goal button of rviz or by publishing to the /move_base/goal topic, you can also issue a series of goals and have the navigation stack follow them one, after another automatically. To do that, issue each one of your intended goals by publishing a Pose message to the /initialpose topic either via the command line or via the 2D Pose Estimate button of rviz, . Fig. 55 Providing waypoints to follow When you have added all the waypoints that you want, call the /path_ready service so that the robot starts to follow them. $ rosservice call /path_ready "{}"


If at any point you want to reset the list of given waypoints, call the /path_reset service.

$rosservice call /path_reset "{}"  Finally if you want to disable following the given waypoints perpetually, disable the patrol_mode parameter. $ rosrun dynamic_reconfigure dynparam set /follow_waypoints patrol_mode False


Note

You can also call these services or the dynamic reconfiguration from the RQT GUI launched as part of navigation_monitoring_slamcore.launch.

## Appendix¶

### Remote Visualisation of the Navigation Demo¶

You can visualise the navigation process using ros1-examples/navigation_monitoring_slamcore.launch

Since the live navigation is running on the Jetson NX platform, we want to remotely visualise it on our x86_64 machine. To do this, we can make use of the remote capabilities of ROS.

Instructions for such a network configuration are provided in the NetworkPage of ROS1 and are summed up in the current section for completeness

Make sure that your x86_64 machine and Jetson NX are on the same network and you can ping by name one from the other machine.

# On the Jetson NX - hostname: nikos-nx2
# edit your /etc/hosts file and add an entry for your x86_64 machine

# Add an entry like the following:
192.168.50.130  draken

# make sure that pinging draken works
berger@nikos-nx2:~/ros_ws$ping draken PING draken (192.168.50.130) 56(84) bytes of data. 64 bytes from draken (192.168.50.130): icmp_seq=1 ttl=64 time=2.69 ms 64 bytes from draken (192.168.50.130): icmp_seq=2 ttl=64 time=41.2 ms  # On your x86_64 machine - hostname: draken # edit your /etc/hosts file and add an entry for Jetson NX # Add an entry like the following: 192.168.50.210 nikos-nx2 # make sure that pinging the Jetson NX works berger@draken:~/ros_ws$ ping nikos-nx2
PING nikos-nx2 (192.168.50.210) 56(84) bytes of data.
64 bytes from nikos-nx2 (192.168.50.210): icmp_seq=1 ttl=64 time=3.58 ms
64 bytes from nikos-nx2 (192.168.50.210): icmp_seq=2 ttl=64 time=3.58 ms


Now in order to share a common ROS1 Master across these 2 computers, set the ROS_MASTER_URI environment variable on your x86_64 machine and run the ROS1 core either directly or via a launchfile on the Jetson NX.

$# just launch roscore as usual.$ roscore
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://nikos-nx2:37757/
ros_comm version 1.14.10

SUMMARY
========

PARAMETERS
* /rosdistro: melodic
* /rosversion: 1.14.10

NODES

auto-starting new master
process[master]: started with pid [23855]
ROS_MASTER_URI=http://nikos-nx2:11311/

setting /run_id to d9bc19b6-50fc-11eb-bda8-d8c0a6261b17
process[rosout-1]: started with pid [23866]
started core service [/rosout]

$rostopic list /rosout /rosout_agg  $ # *without* running roscore on this machine, verify that we're connecting
$# to the roscore on the Jetson NX$ rostopic list
ERROR: Unable to communicate with master!

$export ROS_MASTER_URI=http://nikos-nx2:11311$ # now, after running roscore on the Jetson NX:
\$ rostopic list
/rosout
/rosout_agg


At this point you should be able to launch the autonomous navigation stack on the Jetson NX and visualise the results using navigation_monitoring_slamcore.launch on your x86_64 machine.

### Obstacle Avoidance¶

We use the /slamcore/local_point_cloud topic published by our software as an input to the costmap2D obstacle_layer, to mark and clear obstacles in the local and global costmaps during navigation. You can find more details of the implementation in our obstacle_avoidance_pointcloud.yaml file, found here. You can modify the local point cloud for obstacle avoidance by defining the boundaries of the point cloud in your configuration file, as explained in Point Cloud Trimming. This can be useful to exclude ground points and prevent them being marked as obstacles.

Note

ALTERNATIVE - Tweaking the local point cloud via the ROS costmap2d obstacle_layer min_obstacle_height parameter.

Instead of using our JSON LocalPointCloud parameters as explained in Point Cloud Trimming, you may want to use the ROS min_obstacle_height parameter as one of the observation source parameters in the obstacle_avoidance_pointcloud.yaml file. This parameter allows you to set a height (measured from the map frame) from which points are considered valid. In this case, the points are not removed from the cloud but simply ignored, allowing you, for example, to ignore ground points and prevent them being marked as obstacles. Setting min_obstacle_height to 0.02 would only consider points 2cm above the map Z coordinate when marking obstacles.