How To Create an Object Following Robot – ROS 2 Navigation

In this tutorial, I will show you how to create an object-following robot using the ROS 2 Navigation Stack (also known as Nav2). The goal is to develop an application that will enable a robot to follow a moving object at a distance indefinitely. Here is the final output you will be able to achieve after going through this tutorial:

dynamic-object-following-ros2-nav2-robot

The official tutorial is on this page, but we will walk through the steps below.

Developing the code to detect the dynamic object is outside the scope of this tutorial (you can see this post though on how to integrate OpenCV and ROS 2). What we will focus on here is making sure we keep publishing an updated pose (of a dynamic object) to a topic. The Navigation Stack will then have logic to navigate the robot toward that pose.

Real-World Applications

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

  • Person-following robot
  • Luggage-carrying robot

We will focus on creating an application that will follow a moving point (that we set on the map) around a hospital.

Prerequisites

You can find the files for this post here on my Google Drive

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 hospital.world.

Create a Map

Open a terminal window, and move to your package.

cd ~/dev_ws/src/two_wheeled_robot/maps/hospital_world

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

My hospital map is made up of two files:

  • hospital_world.pgm
  • hospital_world.yaml

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/hospital_world

Add the nav2_object_following_params.yaml file from this folder

The definitions of the Behavior-Tree parameters are located on this page.

Create the Behavior Tree XML File

Let’s create the behavior tree.

Open a terminal window, and move to your package.

cd ~/dev_ws/src/two_wheeled_robot/params/hospital_world

Add the follow_point_bt.xml file from this folder. This file comes from here.

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/hospital_world

Add the nav2_config_object_following.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/hospital_world

Add the hospital_world_object_following.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 hospital_world_object_following.launch.py
follow-1-meter-behind-object-following-ros2-1

Command the robot to navigate to any position. Use the Nav2 Goal button at the top of RViz to simulate a new detection of the object of interest.

The robot will follow the point that you click. It will maintain a distance of 1.0 meter behind it.

You can also use this command in the terminal window to set a goal pose. The “object’s location” is published to the /goal_pose topic as a geometry_msgs/PoseStamped type message. All of this stuff below is a single command.

ros2 topic pub -1 /goal_pose  geometry_msgs/PoseStamped '{ header: {stamp: {sec: 0, nanosec: 0}, frame_id: "map"}, pose: {position: {x: 5.0, y: 0.0, z: 0.25}, orientation: {w: 1.0}}} '

You can also put the above command in code by creating a publisher node, populating a geometry_msgs/PoseStamped type message inside that node, and publishing that message to the /goal_pose topic.

That’s it! Keep building!

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