Fundamentals of ROS

Organization of ROS code

The top level organization of ROS code is a package. A package is simply a folder with a collection of ROS code. This git repository is the uvic-rover package. Within it is both library code and executable. Packages often contain one or more nodes. Nodes are simply executable processes that connect to the ROS network. For example, one node that we have is the 'drive' node, it takes in joystick command as input and outputs PWM signals for the motors to move. Nodes talk to each other via topics. A topic is simply a channel where nodes can publish or subscribe to data messages. The topic will have a particular message format. An example of a topic is /camera/rgb. This topic has a message type of Image. A camera driver node might publish image messages to this topic and perception code might subscribe to the topic to process the images. See here for rules on topic names.

Another thing to be aware of is launch files. roslaunch is a tool for easily launching multiple ROS nodes locally and remotely via SSH. It includes options to automatically respawn processes that have already died. roslaunch takes in one or more XML configuration files (with the .launch extension) that specify the parameters to set and nodes to launch, as well as the machines that they should be run on.

Useful ROS commands

roscore starts a ROS master service

rosnode list shows you all the running nodes on the network

rostopic list shows you all the topics. You can get further info about topics like the message type with other rostopic commands.

rosrun <package-name> <node> will run a particular node from the specified package

roslaunch <package-name> <launchfile> will run a particular launch file in the specified package

roscd <package> will navigate to where a package actually lives on your system

apt install ros-<version>-<package> will let you install existing ROS packages that are in the package repositories. For example, apt install ros-noetic-moveit installs the moveit package for ROS1 on Ubuntu 20.04. Note that some packages are not in the repositories and will have to be built from sources. More on this later.

rosrun rqt_tf_tree rqt_tf_tree shows the hierarchy of defined transformations

Catkin workspaces

For ROS packages that are not packaged with apt we can instead build them from source. This is also the workflow for our uvic_rover package since we are always actively developing and are not creating releases. ROS packages must be built in a catkin workspace, which is a special directory structure that the catkin build system uses. A brand new catkin workspace can be created by the following:

mkdir -p path_to_my_workspace/workspace_name/src
cd path_to_my_workspace/workspace_name/src
catkin_init_workspace
cd path_to_my_workspace/workspace_name/
catkin_make

To start developing a package, simply clone the package directory into src and run catkin build. Note that catkin build invokes the compiler and some other catkin initialization for your package. For python packages you do not have to catkin build for each change to .py files since python is interpreted.

In order to actually execute code in your workspace you must run source devel/setup.bash. This sets environment variables like PYTHON_PATH to point toward the devel directory so that your code can correctly resolve dependencies. It is important to do this each time you want to run code in the workspace. Note that once you've sourced the setup.bash you can do things like rosrun uvic_rover navigation.py and ROS is aware of the uvic_rover package.

One useful thing about catkin workspaces is that they provide isolation. Because we have to source the setup.bash for each indiviudal workspace, I could have different versions of the same package in different catkin workspaces for different projects without them interfering with each other.

Publisher/Subscriber Model

One common paradigm in interprocess communication libraries is the publish-subscribe pattern. Processes are able to publish messages to certain topics, and subscribes can subscribe to those topics to receive messages. The publisher has no knowledge of who its subscribers are, and there can be many subscribers to one publisher. This is used frequently in ROS. Consider a node that acts as a driver for a camera. When it reads an image, it broadcasts it on a topic named image and any other processes that needs visual data can receive the image by subscribing to the topic.

I highly recommend going through the ros wiki and doing the tutorials on there. At minimum, you should look at the node tutorial. This is the 'hello world' of the ROS world.

URDFs and Xacros

It is useful to have a model of the robot for things like simulation, visualization, and inverse kinematics. In ROS it is typical to specify this in a URDF or Xacro file. These are essentially XML files that specify a robot as a collection of joints and links. Joints are used to connect and move links. Links have an associated physical and visual geometry.