The previous post outlined a relatively minimal path to getting a virtual robot up and running in the Gazebo simulation environment. The robot is a virtual copy of the physical TurtleBot 3 Burger, and they both run code built on ROS. This setup should be pretty close to a ROS “Hello World” for a beginner like myself to get started poking at and learning what’s going on.
The first thing to do is to run rostopic list. As per tutorial on ROS topics, this is a tool to see all the information topics being published by all components running under a ROS core.
/clicked_point
/clock
/cmd_vel
/gazebo/link_states
/gazebo/model_states
/gazebo/parameter_descriptions
/gazebo/parameter_updates
/gazebo/set_link_state
/gazebo/set_model_state
/gazebo_gui/parameter_descriptions
/gazebo_gui/parameter_updates
/imu
/initialpose
/joint_states
/move_base_simple/goal
/odom
/rosout
/rosout_agg
/scan
/statistics
/tf
/tf_static
That’s a pretty long list of topics, which might seem intimidating at first glance until we realize just because it’s available doesn’t mean it’s being used.
How do we look at what’s actually in use? Again from the ROS topics tutorial, we can use a ROS utility that graphs out all active nodes and the topics they are using to talk to each other. rosrun rqt_graph rqt_graph
Ah, good. Only a few things are active. And this was only when we have everything running as listed at the end of the previous post, which were:
- TurtleBot in Gazebo
- TurtleBot performing a random walk with collision avoidance
- Rviz to plot laser range-finder data.
If we stop Rvis, the /robot_state_publisher node disappears, so that was used exclusively for visualization. The two nodes prefixed with gazebo are pretty obviously interface points to the simulator, leaving /turtlebot3_drive as the node corresponding to the random walk algorithm.
The velocity command topic /cmd_vel looks just like the one in the basic turtlesim used in the ROS tutorial, and I infer it is a standardized way to command robot movement in ROS components. The /scan topic must then be the laser rangefinder data used for collision avoidance.
To find the source code behind item #2, the obvious starting point is the command line used to start it: roslaunch turtlebot3_gazebo turtlebot3_simulation.launch. This tells us the code lives in the turtlebot3_gazebo module and we can look at the launch instructions by giving the same parameters to the ROS edit command. rosed turtlebot3_gazebo turtlebot3_simulation.launch. This brings up a XML file that described components for the random walk. From here I can see the node comes from something called “turtlebot3_drive“.
I found a turtlebot3_drive.cpp in the source code tree by brute force. I’m sure there was a better way to trace it from the .launch file to the .cpp, I just don’t know it yet. Maybe I’ll figure that out later, but for now I have a chunk of ROS C++ that I can tinker with.
