ROS Navigation

In this ROS sample, we are demonstrating Omniverse Isaac Sim integrated with the ROS Navigation stack.

To learn more about ROS Navigation refer to the ROS website: http://wiki.ros.org/navigation

For this sample, we use the carter_2dnav package which contains the required launch file and navigation parameters.

The carter_description package is also used for displaying the NVIDIA Carter robot model in RViz.

Both packages are located under the directory ros_samples/navigation/. If not already done, include both packages into your ROS workspace. Build and source your workspace before proceeding.

Ensure Roscore is running before running Omniverse Isaac Sim.

First go to Isaac Examples -> Communicating -> ROS -> Navigation to load the warehouse scenario.

Press Play to begin simulation.

The ROS Navigation Setup

This block diagram shows the ROS messages required for the ROS Navigation stack.

ROS Navigation Overview Block Diagram

As described above, the following topics and message types being published to the ROS Navigation stack in this scenario are:

ROS Topic

ROS Message Type

/tf

tf2_msgs/TFMessage

/odom

nav_msgs/Odometry

/map

nav_msgs/OccupancyGrid

/scan

sensor_msgs/LaserScan

Omniverse Isaac Sim TF broadcasting in more detail:

ROS_DifferentialBase subscribes to the /cmd_vel topic and is responsible for controlling the movement of the robot. It also publishes the transform between the odom frame and base_link frame.

ROS_Carter_Broadcaster is responsible for publishing the static transform between the base_link frame and chassis_link frame. Keep in mind that since the target prim is set as Carter_ROS, the entire transform tree of the Carter robot (with chassis_link as root) will be published alongside the base_link frame.

ROS_Carter_Lidar_Broadcaster is responsible for publishing the static transform between the chassis_link frame and carter_lidar frame.

Finally, to ensure all ROS nodes reference simulation time, a ROS_Clock prim has been added which publishes the simulation time to the /clock ROS topic.

Occupancy Map

In this scenario we will use an occupancy map. To generate a map there are 2 options:

  1. Using the Occupancy Map Generator extension within Omniverse Isaac Sim (Recommended)

  2. Using the slam_gmapping ROS package

Using the slam_gmapping ROS package:

Follow the tutorial: http://wiki.ros.org/slam_gmapping/Tutorials/MappingFromLoggedData

Note

Since a rosbag is not available, substitute the rosbag command in the tutorial with the following command: rosrun teleop_twist_keyboard teleop_twist_keyboard.py. This will start the teleop_twist_keyboard ROS node and enable you to use your keyboard to manually drive the robot around the warehouse to simultaneously generate a map.

Press Stop to terminate the simulation.

Running ROS Navigation

Click on Play to begin simulation.

In a new terminal, run the ROS launch file to begin ROS Navigation.

roslaunch carter_2dnav move_base.launch

Rviz will open and begin loading the urdf model of the robot, the global costmap (occupancy map), as well as the local costmap which will be overlaid on top.

To verify that all of the transforms are broadcasting, run the following command in a new terminal to visualize the ROS TF frame tree:

rosrun rqt_tf_tree rqt_tf_tree

The generated graph should look similar to the one shown below.

ROS TF frame tree

It is mostly likely after launching move_base.launch, that the local costmap will not match the global costmap. This means the robot is not correctly localized. To mitigate this, click on the 2D Pose Estimate button near the top of the Rviz window and set the initial estimated pose by clicking and dragging at a point on the map where you think the robot is located.

To get a better idea of where the robot is located, you may wish to change camera views by clicking at the top left of the viewport in the Omniverse Isaac Sim window.

Demo of the 2D Pose Estimate

In Rviz, the robot model will immediately jump to the indicated pose. The local costmap should now be similarly aligned to the global costmap.

Note

The local and global maps don’t have to perfectly align yet. However if their alignment is quite different, you may repeat the previous step until you get a closer alignment.

To make both the local and global maps properly align, manually drive around the robot (rotating in place works the fastest in most cases). For manually controlling the robot, run the teleop_twist_keyboard ROS node using the following command in a new terminal.

rosrun teleop_twist_keyboard teleop_twist_keyboard.py

Use the keyboard to move the robot until the local costmap has properly aligned with the global costmap.

Demo of localization while controlling robot via keyboard

Now the robot has been properly localized! You may now stop the teleop_twist_keyboard node as it is not required anymore.

Click on the 2D Nav Goal button and then click and drag at the desired location point in the map. The ROS Navigation stack will now generate a trajectory and the robot will start moving towards its destination!

Demo of 2D Nav Goal