How to Set Speed Limit Zones – ROS 2 Navigation

In this tutorial, I will show you how to navigate using speed limit zones using the ROS 2 Navigation Stack (also known as Nav2). A speed limit zone is an area which limits the maximum speed of a robot. Here is the final output you will be able to achieve after going through this tutorial:

speed-limit-demo

Notice how the robot moves slower through the gray/black areas than the white areas of the map.

Real-World Applications

The application that we will develop in this tutorial can be used in a number of real-world robotic applications: 

  • Hospitals and Medical Centers
  • Hotels (e.g. Room Service)
  • House
  • Offices
  • Restaurants
  • Warehouses
  • And more…

We will focus on creating an application that will limit the speed of a robot in certain areas of a warehouse or factory floor.

Prerequisites

You can find the files for this post here on my Google Drive. Credit to this GitHub repository for the map files. And credit to this tutorial that shows the steps for implementing a speed limit filter.

Create a World

Open a terminal window, and move to your package.

cd ~/dev_ws/src/two_wheeled_robot/worlds

Make sure this world is inside this folder. The name of the file is warehouse_speed_limit_zones.world.

Create a Map

Open a terminal window, and move to your package.

cd ~/dev_ws/src/two_wheeled_robot/maps/warehouse_world

Make sure the pgm and yaml map files are inside this folder.

My world map is made up of two files:

  • warehouse_world_speed_limit_zones.pgm
  • warehouse_world_speed_limit_zones.yaml

Create a Speed Limit Filter

Now we need to create a mask that identifies the speed limit zones. 

This tutorial has instructions on how to use a graphics editor like GIMP (you can install using the sudo apt-get install gimp command) to prepare the filter mask. 

You will start with a copy of the world file you want to use. In this tutorial, I am going to use my warehouse_world_speed_limit_zones.pgm file. You need to edit this file so that speed limit zones are different shades of gray….the darker the gray, the lower the speed limit.

My filter mask is made up of two files:

  • speed_mask.pgm
  • speed_mask.yaml

Both of these files are located in my ~/dev_ws/src/two_wheeled_robot/maps/warehouse_world/ folder.

Create the Parameters File

Let’s create the parameters file.

Open a terminal window, and move to your package.

cd ~/dev_ws/src/two_wheeled_robot/params/warehouse_world

Add the speed_limit_zones_params.yaml file from this folder

Create the RViz Configuration File

Let’s create the RViz configuration file.

Open a terminal window, and move to your package.

cd ~/dev_ws/src/two_wheeled_robot/rviz/warehouse_world

Add the nav2_config_speed_limit_zones.rviz file from this folder

Create the Launch File

Let’s create the launch file.

Open a terminal window, and move to your package.

cd ~/dev_ws/src/two_wheeled_robot/launch/warehouse_world

Add the warehouse_world_speed_limit_zones.launch.py file from this folder

Launch the Launch File

We will now build our package.

cd ~/dev_ws/
colcon build

Open a new terminal and launch the robot in a Gazebo world. 

ros2 launch two_wheeled_robot warehouse_world_speed_limit_zones.launch.py

Wait for the robot to snap to the estimated initial location within RViz. This process should take a minute or two.

1-speed-limit-zones-1

You might notice that the robot’s pose in RViz is not aligned with the pose in Gazebo. Localization using the AMCL (Adaptive Monte Carlo Localization) package is really sensitive to the initial pose estimate. The trick is to make sure the initial location of the robot is in a location with a lot of distinctively shaped obstacles (i.e. the shelves and boxes) for the LIDAR to read. 

Even though the initial pose was set when we launched the robot, it is likely that the estimate in RViz is pretty bad. Let’s set the initial pose again by clicking the 2D Pose Estimate button at the top of RViz and then clicking on the map.

You can also set the initial pose by opening a new terminal window and typing the following command.

ros2 topic pub -1 /initialpose geometry_msgs/PoseWithCovarianceStamped '{ header: {stamp: {sec: 0, nanosec: 0}, frame_id: "map"}, pose: { pose: {position: {x: -3.7, y: 9.0, z: 0.0}, orientation: {w: 1.0}}, } }'

When the robot snaps to the location, the map and odom axes should be pretty close to each other right at the origin of the map (x=0, y=0).

Now send the robot to a goal that is on the other side of the speed limit zones by clicking the “Nav2 Goal” button at the top of RViz and clicking on a goal location.

The robot will move to the goal, slowing down in the speed limit zones.

A success message will print once the robot has reached the goal location.

That’s it! Keep building!

Autonomous Agricultural Robot Systems Design & Architecture

In this tutorial, I will present a template for the system design and architecture for an autonomous agricultural robot. This template could be modified for designing any autonomous mobile robot. These requirements are not an exhaustive list.

System Requirements

Mandatory Functional Requirements 

Functional requirements define what a system must do. These requirements are typically specified by the user.

M.F.1. The system must accept a map of the farm.

M.F.2. The system must harvest wheat.

M.F.3. The system must detect static objects.

M.F.4. The system must detect dynamic objects.

M.F.5. The system must return to the home location after harvesting.

M.F.6. The system must indicate when fuel is low.

M.F.7. The system must generate an estimate of crop production, including acreage, area harvested, and yield.

Mandatory Non-Functional Requirements

Non-functional requirements define the constraints that impact how the system should fulfill the functional requirements. These requirements are typically specified by the engineer.

M.N.1. The system shall harvest 95% of crops on flat, unobstructed terrain.

M.N.2. The system shall send a notification when the fuel level gets to 5% of a full tank.

M.N.3. The system must cover 0.25 acres on flat, unobstructed terrain in 20 minutes.

M.N.4. The system shall navigate on a 15-degree sloped hill.

M.N.5. The system shall detect >99% of static objects greater than 0.3 meters in height and 0.2 meters in width.

M.N.6. The system shall detect >99% of dynamic objects greater than 0.3 meters in height and 0.2 meters in width.

Desired Functional Requirements

D.F.1. The system must generate a report of crop health.

Desired Non-Functional Requirements

D.N.1. The system shall navigate on a 25-degree sloped hill.

D.N.2. The system shall harvest 99% of crops on flat, unobstructed terrain.

Functional Architecture

functional-architecture-ros2

EKF = Extended Kalman Filter

Cyber-physical Architecture

The cyber-physical architecture maps the functional architecture to the hardware and software components of the robotic system. 

User Interface

Hardware

Software

Navigation

Hardware

  • On-board computer
  • Vehicle (Including Motors)

Software

Sensing

Hardware

Software

Manipulation

Hardware

  • Microcontroller
  • On-board computer
  • Vehicle

ROS 2 Architecture Overview

ROS 2 Architecture Overview

Below is a high-level diagram of the ROS 2 architecture.

ros-architecture

Data Distribution Service (DDS) Architecture Overview

ROS 2 uses DDS as its middleware. DDS reduces coupling, increases scalability, and improves performance, reliability, security, and flexibility. It is for this reason why it is common to see the DDS communication protocol used in the defense industry

Below is a high-level diagram of the DDS publish-subscribe communication protocol using an example robotics application.

dds-overview