By Martin Cote

After working in the terminal, gazebo and RViz, it’s time for a change of pace. For this ROS101 tutorial we’ll be detailing the basics of creating your own rqt dashboard! A dashboard is a single rqt window with one or more plugins displayed in movable, re-sizable frames. Dashboards generally consist of a number of plugins that, in combination, provide a suite of UI capabilities for working with robots and robot data.

Dashboards can be populated and configured interactively in an rqt session. A preferred configuration can be saved as a “Perspective,” which saves the plugins loaded, their layout, where they are supported, their settings, and last-saved initial parameters (such as what topic we were last plotting). In this tutorial we’ll be working with the Husky simulation in ROS Indigo. To install ROS Indigo, please see these instructions, and visit our Husky simulation page to install the Husky simulation.

Getting Started

The first step is to install rqt! We’ll also be installing some common plugins to create our dashboard:

sudo apt-get install ros-indigo-rqt ros-indigo-rqt-common-plugins ros-indigo-rqt-robot-plugins

We can then launch RQT by simply using:

rqt

In the Plugins menu, select each plugin you want to load. You can change the layout by dragging and rescaling each plugin by its title bar or edges.

A practical example

We’ll now create a rqt dashboard with a few useful plugins and demonstrate a potential use case for this particular dashboard. For this tutorial we’ll be using our virtual Husky to simulate sensor data. Open Husky up in Gazebo using:

roslaunch husky_gazebo husky_playpen.launch

You can minimize Gazebo for now as we set up our rqt dashboard. Begin by opening the following plugin from the plugins drop down menu, and re size them as you like,

Rviz
Plot x2
Bag
Robot Steering

Each plugin has their own uses and settings, for more information about a particular plugin, visit the rqt plugins page of the ROS wiki

When you’re happy with a dashboard configuration, you can save the perspective by selecting Perspectives, Create Perspective, giving it a name, and asking it to clone the current perspective. These perspectives are saved locally and persist between sessions.

To export a perspective for closer management such as sharing or persisting to a repository, select Perspectives, Export and give it a name with the filename extension, .perspective

Loading a Perspective

A perspective can be loaded interactively in RQT by selecting Perspectives, import. However a more useful way is to launch them from the command-line, which allows us to wrap them in a script that can be rosrun or roslaunched:

rqt --perspective-file "$(rospack find my_ros_rqt_package)/config/my_dashboard.perspective"

Some plugins allow you to configure options that impact its installation and behavior. For example, the Python Console plugin allows you to choose which console implementation to use. You can access these options for any plugin by selecting the gear icon in its title bar. If no gear icon is present, the plugin has not been configured to provide an options menu.

Rviz: To load Husky into your Rviz plugin, select “open config” from the drop down menu, and navigate to /opt/ros/indigo/share/husky_viz/rviz/view_robot.rviz. You should now see a model of Husky loaded in Rviz! By default, this config file will include the simulated laser, and you can see the object in Husky’s path in the Gazebo environment.

Plot: The Plot tool is very useful to plot a particular topic in real time, for this example we will be plotting the commanded odometery topic versus the simulated odometrey. In the input window on the top right of the plot plugin, add the follow topic in each plot.

/odometry/filtered/twist/twist/angular/z

and

/husky_velocity_controller/odom/twist/twist/angular/z

Robot Steering: The robot steering plugin provides us with a simple way to manually drive Husky, all that is required is to specify  the  topic which accepts the velocity commands to move your Robot, for virtual Husky, that topic is /cmd_vel.

It’s time to put it together! Try commanding Husky to turn in place using the robot steering plugin, and watch your Husky is RViz turn in place while it’s updating the laser scan! You should also see the commanded odometry in one of your plots, while the actual odometry lags slightly behind as it catches up to the desired value.

Rqt bag: Rosbag is an extremely useful tool  for logging, and our support team may often ask for a bag file to take a closer look at your system. It’s possible to record a bag through the terminal, but using rqt is much simpler and more intuitive. Let’s record  a bag file of Husky driving around by clicking the record button, and selecting the topics you want to record. Once you’re happy with the data recorded, stop the recording.

Playing a bag file back is just as simple. Let’s go ahead and close rqt and Gazebo so ROS is no longer running, then start ROS again with just roscore:

roscore

And open rqt back up and load the ROS bag plugin again:

rqt

This time we are going to open up the bag file we just recorded by clicking the 2nd button. You’ll now see all the topics that were recorded, and when messages were sent over that topic. You can take a closer look at a particular ticket by right clicking and selecting to view either the values or plot a particular topic.

For more information regarding rqt, please visit the ROS Wiki page, if you have any questions regarding this particular tutorial, please don’t hesitate to contact us!

Looking for other Clearpath tutorials? Here’s one you might like! See all the ROS101 tutorials here.

By Paul Bovbel

Udev is a device manager for Linux that dynamically creates and removes nodes for hardware devices. In short, it helps your computer find your robot easily. By default, hardware devices attached to your Linux (Ubuntu) PC will belong to the root user. This means that any programs (e.g. ROS nodes) running as an unpriveleged (i.e. not root) user will not be able to access them. On top of that, devices will receive names such as ttyACMx and ttyUSBx arbitrarily based on the order in which they were plugged in. Luckily, you can solve this, and more, with udev rules.

You probably already have at least one udev rule on your system that solves the naming problem for network devices, and you can take a peek at it in the /etc/udev/rules.d/ folder – it’s probably named 70-persistent-net.rules.

Some driver/software packages will already provide udev rules you can use. Check the /etc/udev/rules.d/ folder to see if there’s anything installed already. If the package is lazy and gives you a udev rule to install yourself, you can do this using:

sudo cp <rule file> /etc/udev/rules.d/

Writing a new udev rule:

If you still need to write your own rule to setup naming and permissions for your device, read on. Rules can get extremely complex, but the one below should cover 99% of use cases for ROS applications. If you’re looking for 99.9%, I suggest you start here. As an example, we will examine the udev rule provided by the urg_node driver in ROS:

SUBSYSTEMS==”usb”, KERNEL==”ttyACM[0-9]*”, ACTION==”add”, ATTRS{idVendor}==”15d1″, ATTRS{idProduct}==”0000″, MODE=”666″, PROGRAM=”/opt/ros/hydro/lib/urg_node/getID /dev/%k q”, SYMLINK+=”sensors/hokuyo_%c”, GROUP=”dialout”

A udev rule is made up of a bunch of comma separated tags, as above. The tags are divided into two parts: matching and configuration, however they can be written into the rule in any order (confusingly enough).

Matching:

The matching part lets the udev device manager match the rule to the device you want. The manager will try to match all new devices as they get plugged in, so it’s important that the rule be specific enough to capture only the device you’re looking for, otherwise you’ll end up with a /dev/hokuyo symlink to an IMU. There are many potential matching tags, and the best way to pick the useful ones is to get all the device attributes straight from udev.

Run the following command, inserting the <devpath> such as /dev/ttyACM0:

udevadm info -a -p $(udevadm info -q path -n <devpath>)

You will get a list of all device attributes visible to udev. looking at device ‘…/ttyACM0′:

KERNEL=="ttyACM0"
SUBSYSTEM=="tty"
DRIVER==""
looking at parent device '...':
KERNELS=="3-3:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="cdc_acm"
ATTRS{bInterfaceClass}=="02"
ATTRS{bInterfaceNumber}=="00"
looking at parent device '...':
...
ATTRS{idVendor}=="0483"
ATTRS{idProduct}=="5740"
...

Each of the device attributes is a potential tag. You can use any of the tags in the first section to filter, along with tags from a parent device. Use regex to make matching more flexible (e.g. [0-9] to match any number, * to match anything at all).

Example:

SUBSYSTEM=="tty", KERNEL=="ttyACM[0-9]*", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", ...

Due to the way udev is designed, you can only pull in the tags from one parent device. So in the above example you can always use the KERNEL and the SUBSYSTEM tag in your udev rule, but you cannot use both DRIVERS and ATTRS{idVendor} to do matching. Usually this is not a problem, since idVendor and idProduct are always present, and identify the majority of device types uniquely.

You should also add the ACTION tag, which is usually “add”, sometimes “remove” if you want to do something when the device is unplugged.

..., ACTION=="add", ...

Configuration:

Now that you have a rule that matches the device you want, you can add several configuration tags:

MODE="0666"

SYMLINK+=”hokuyo”

RUN+=”/bin/echo ‘hello world’”

It is good practice to make sure symlinks are unique for each device, so the above is actually poor practice! If you have multiple devices of the same type (e.g. 2 Hokuyos), or if you have multiple devices using a generic USB-to-Serial converter (e.g. FTDI), a basic idVendor and idProduct rule will not properly discriminate between these devices, since udev will map all matching devices to the same symlink. There are several approaches:

Directly through device attributes:

If your device has a unique identifier, such as a serial number, encoded in its attributes, you can painlessly create a unique symlink:

…, SYMLINK+=”device_$attr{serial}”, …

This will usually not be the case. If a parent device has a serial number, you can use the following trick using environment variables. Create a udev rule for the parent device to store an environment variable:

…, <match parent device>…, ENV{SERIAL_NUMBER}=”$attr{serial_number}”

And a rule for the child device that uses the variable in the symlink:

..., <match child device>..., SYMLINK+="device_$env{SERIAL_NUMBER}"

External Program:

If the manufacturer does not expose a unique identifier through the device attributes, you can execute an external command using the PROGRAM tag:

PROGRAM="/bin/device_namer %k", SYMLINK+="%c"

Unlike the RUN tag which spins off, this command will be executed before the rule is fully processed, so it must return quickly. The urg_node driver above uses this tag to execute a ROS binary:

PROGRAM="/opt/ros/hydro/lib/urg_node/getID /dev/%k q", SYMLINK+="sensors/hokuyo_%c"

Substitution argument %k refers to the device path relative to /dev/, and %c refers to the output of the PROGRAM tag.

Running a new udev rule:

Once you have sudo cp’ed your rule into the /etc/udev/rules.d/ folder, you can test it with your device. To get udev to recognize your rule, run the following command:

sudo udevadm control --reload-rules && sudo service udev restart && sudo udevadm trigger

You should be able to find a symlink in /dev/ that links to the full device path (e.g. /dev/ttyACM0), and the permissions on the device path should be read/write for all users.

If your permissions aren’t being set, and you symlink is not being created in /dev/ as expected, you can try simulating udev’s processing of the rule by running the following with the appropriate device path:

udevadm test $(udevadm info -q path -n /dev/ttyACM0)

Things to keep in mind

Check that your rule follows the naming convention – <priority>-<device name>.rules. Technically you can have multiple rules for the same device, and the number determines what order they’d get executed in. Since we’re writing addon rules, a priority of 99 is safest.

You can have multiple rules in a file separated by newlines. Make sure that each individual rule is on one line.

Check that all tags (matching and configuration) are comma separated.

Check that your rule file has a trailing newline.

Check that your rule is owned by the root user – ll /etc/udev/rules.d/ should say ‘root root’ for the rule file.

The post Do More with Udev appeared first on Clearpath Robotics Inc..

By Martin Cote

We previously learned how to write a publisher node to move Husky randomly. BUT: what good is publishing all these messages if no one is there to read it? In this tutorial we’ll write a subscriber that reads Husky’s position from the odom topic, and graph its movements. Instead of just copy-pasting code into a text file, we’ll pull the required packages from GitHub, a very common practice among developers.

Before we begin, install Git to pull packages from GitHub, and pygame, to provide us with the tools to map out Husky’s movements:

sudo apt-get install git
sudo apt-get install python-pygame

Pulling from GitHub

GitHub is a popular tool among developers due to its use of version control – most ROS software has an associated GitHub repository. Users are able to “pull” files from the GitHub servers, make changes, then “push” these changes back to the server. In this tutorial we will be using GitHub to pull the ROS packages that we’ll be using. The first step is to make a new directory to pull the packages:

mkdir ~/catkin_ws/src/ros101
cd ~/catkin_ws/src/ros101
git init

Since we now know the URL that hosts the repositories, we’ll easily be able to pull the packages from GitHub. Access the repositories using the following command:

git pull https://github.com/mcoteCPR/ROS101.git

That’s it! You should see an src and launch folder, as well as a CMakelist.txt and package.xml in your ros101 folder. You now have the package “ros101″, which includes the nodes “random_driver.cpp” and “odom_graph.py”.

Writing the subscriber

We’ve already gone through the random_driver C++ code in the last tutorial, so this time we’ll go over the python code for odom_graph.py. This node uses the Pygame library to track Husky’s movement. Pygame is a set of modules intended to create video games in python; however, we’ll focus on the ROS portion of this code. More information on Pygame can be found on their website. The code for the odom_graph node can be found at:

gedit -p ~/catkin_ws/src/ros101/src/odom_graph.py

Let’s take a look at this code line by line:

import rospy
from nav_msgs.msg import Odometry

Much like the C++ publisher code, this includes the rospy library and imports the Odometry message type from nav_msgs.msg. To learn more about a specific message type, you can visit http://docs.ros.org to see it’s definition, for example, we are using http://docs.ros.org/api/nav_msgs/html/msg/Odometry.html . The next block of code imports the pygame libraries and sets up the initial conditions for our display.

def odomCB(msg)

This is the odometry call back function, which is called every time our subscriber receives a message. The content of this function simply draws a line on our display between the last coordinates read from the odometry position message. This function will continually be called in our main loop.

def listener():

The following line starts the ROS node, anonymous=True means multiples of the same node can run at the same time:

rospy.init_node('odom_graph', anonymous=True)

Subscriber sets up the node to read messages from the “odom” topic, which are of the type Odometry, and calls the odomCB functions when it receives a message:

rospy.Subscriber("odom", Odometry, odomCB)

The last line of this function keeps the node active until it’s shut down:

rospy.spin()

Putting it all together

Now it’s time to test it out! Go ahead and close the odom_graph.py file and build your workspace using the catkin_make function in your workspace directory.

cd ~/catkin_ws
catkin_make

The next step is to launch our Husky simulation to start up ROS and all the Husky related nodes

roslaunch husky_gazebo husky_emepty_world.launch

In this tutorial we have provided a launch file that will start the random_driver and odom_graph node. The launch file is located in ~/ros101/src/launch and is called odom_graph_test.launch. If you want to learn more about launch files, check out our launch file article on our support knowledge base. We will now source our workspace and launch both nodes with the launch file in a new terminal window.

source ~/catkin_ws/devel/setup.bash
roslaunch ros101 odom_graph_test.launch

There you have it! Our subscriber is now listening to messages on the odom topic, and graphing out Husky’s path.

See all the ROS101 tutorials here. 

By Martin Cote

In our previous post, we graduated from driving a Husky to taking on a Grizzly! Now it’s time to get down and dirty with what ROS is really made of: nodes! We will first be creating a workspace to work from, then we will write a simple publisher that will make our virtual Husky drive around randomly. If this is your first time visiting a Clearpath Robotics ROS 101 blog, get started here.

Creating a workspace and package

Before we begin writing a node, we need to create a workspace and a package. Workspaces are simply directories to store all of your packages. First we will need to create a new directory.

mkdir ~/ros101

This created a directory in your home folder, which we will use as a workspace directory. We now need to create a subdirectory in your workspace directory to store all your source code for your packages.

mkdir ~/ros101/src

The last step to creating the workspace will be to initialize the workspace with catkin_init_workspace.

cd ~/ros101/src
catkin_init_workspace

Now that our workspace has been created, we will create a package in the src directory we just created. This can be done by navigating to the ~/ros101/src directory, which you should have already done in the last step, and using the catkin_create_pkg command  followed by what we want the package to be named, and then followed by what other packages our package will be dependent on; this command creates another directory for your new package, and two new configuration files inside that directory with some default settings.

catkin_create_pkg random_husky_driver roscpp std_msgs

You can see that this created CMakeLists.txt and package.xml inside the random_husky_driver directory; this is also where you will store all your source code for your packages. The roscpp and std_msgs  dependencies were added into the CMakeLIst.txt and package.xml.

Writing the publisher

As mentioned in our previous post, a publisher publishes messages to a particular topic. For this tutorial, we will be publishing random commands to the /husky/cmd_vel topic to make your Husky visualization drive itself. Start by creating a file in your ~/ros101/src/random_husky_driver directory called random_driver.cpp, and copy the following code.

#include <ros/ros.h>
#include <geometry_msgs/Twist.h> 
#include <stdlib.h> 

int main(int argc, char **argv) {
     //Initializes ROS, and sets up a node
     ros::init(argc, argv, "random_husky_commands");
     ros::NodeHandle nh;

     //Ceates the publisher, and tells it to publish
     //to the husky/cmd_vel topic, with a queue size of 100
     ros::Publisher pub=nh.advertise<geometry_msgs::Twist>("husky/cmd_vel", 100);

     //Sets up the random number generator
     srand(time(0));

     //Sets the loop to publish at a rate of 10Hz
     ros::Rate rate(10);

       while(ros::ok()) {
            //Declares the message to be sent
            geometry_msgs::Twist msg;
           //Random x value between -2 and 2
           msg.linear.x=4*double(rand())/double(RAND_MAX)-2;
           //Random y value between -3 and 3
           msg.angular.z=6*double(rand())/double(RAND_MAX)-3;
           //Publish the message
           pub.publish(msg);

          //Delays untill it is time to send another message
          rate.sleep();
         }
}

Let’s break down this code line by line:

#include <ros/ros.h>
#include <geometry_msgs/Twist.h> 

These lines includes the headers that we are going to need. The <ros/ros.h> header is required for ROS functionality and the <geometry_msgs/Twist.h> is added so that we can create a message of that type.

ros::init(argc, argv, "random_husky_commands");
ros::NodeHandle nh;

The first line, ros::init,  is used to initialize the ROS node, and name it “random_husky_commands”, while ros:NodeHandle starts the node.

ros::Publisher pub=nh.advertise<geometry_msgs::Twist>("husky/cmd_vel", 100);

Publishing a message is done using ros:Publisher pub=nh.advertise, followed by the message type that we are going to be sending, in this case it is a geometry_msga::Twist, and the topic that we are going to be sending it too, which for us is husky/cmd_vel.

The 100 is the message queue size; that is, if you are publishing message faster than what roscpp can send, 100 messages will be saved in the queue to be sent. The larger the queue, the more delay in robot movement in case of buffering.

Therefore in a real life example, you will want to have a smaller queue in the case of robot movement, where delay in movement commands are undesirable and even dangerous, but dropped messages are acceptable. In the case of sensors, it is recommended to use a larger queue, since delay is acceptable to ensure no data is lost.

ros::Rate rate(10)
...
rate.sleep()

ROS is able to control the loop frequency  using ros:Rate to dictate how rapidly the loop will run in Hz. rate.sleep will delay a variable amount of time such that your loop cycles at the desired frequency. This accounts for time consumed by other parts of the loop. All Clearpath robots require a minimum loop rate of 10Hz.

while(ros::ok())

The ros::ok function will return true unless it receives a command to shut down, either by using the rosnode kill command, or by the user pusing Ctrl-C in a terminal.

geometry_msgs::Twist msg;

This creates the message we are going to send, msg, of the type geometry_msgs:Twist
msg.linear.x=4*double(rand())/double(RAND_MAX)-2;
msg.angular.z=6*double(rand())/double(RAND_MAX)-3;

These lines calculate the random linear x and angular z values that will be sent to Husky.

pub.publish(msg)

We are finally ready to publish the message! The pub.publish adds msg to the publisher queue to be sent.

Compiling the random Husky driver

Compilation in ROS in handled by the catkin build system. The first step would usually be to set up our package dependencies in the CMakeLists.txt and package.xml. However this has already been done for us when we created the package and specified our dependencies. The next step is then to declare our new node as a executable, this is done by adding the following two lines to the CMakeLists.txt files in ~/ros101/src/random_husky_driver

add_executable(random_driver random_driver.cpp)
target_link_libraries(random_driver ${catkin_LIBRARIES})

The first line creates the executable called random_driver, and directs ROS to its source files. The second lines specifies what libraries will be used. Now we need to build our workspace using the catkin_make command in the workspace directory

cd ~/ros101
catkin_make

Let’s bring up the husky visualization as we did in a previous blog post.

roslaunch husky_gazebo husky_empty_world.launch

The final step is to source your setup.bash file in the workspace you have created. This script allows ROS to find the packages that are contained in your workspace. Don’t forget this process will have to be done on every new terminal instance!

source ~/ros101/devel/setup.bash

It’s now time to test it out! Make sure you have a instance of roscore running in a separate terminal, then start the node.

rosrun random_husky_driver random_driver

You should now see Husky drive around! In a new terminal window, we can make sure that our node is publishing to the /husky/cmd_vel topic by echoing all messages on this topic.

rostopic echo /husky/cmd_vel

You should now see a stream of random linear x and angular z values.

See all the ROS101 tutorials here. 

So you have had a taste of driving a virtual Husky in our previous tutorial, but now want to try something a little bigger? How about 2000 lbs bigger?

Read on to learn how to drive a (virtual) Grizzly, Clearpath Robotic’s largest and meanest platform. If you are totally new to ROS, be sure to check out our tutorial series starting here and the ROS Cheat Sheet. Here is your next ROS 101 dose.

An updated version of the Learn_ROS disk is available here:

https://s3.amazonaws.com/CPR_PUBLIC/LEARN_ROS/Learn_ROS-disk1.vmdk
https://s3.amazonaws.com/CPR_PUBLIC/LEARN_ROS/Learn_ROS.ovf

Login (username): user
Password: learn

Updating the Virtual Machine

Open a terminal window (Ctrl + Alt + T), and enter the following:

sudo apt-get update
sudo apt-get install ros-hydro-grizzly-simulator 
sudo apt-get install ros-hydro-grizzly-desktop 
sudo apt-get install ros-hydro-grizzly-navigation

Running a virtual Grizzly

Open a terminal window, and enter:

roslaunch grizzly_gazebo grizzly_empty_world.launch

Open another terminal window, and enter:

roslaunch grizzly_viz view_robot.launch

You should be given two windows, both showing a yellow, rugged robot (the Grizzly!). The left one shown is Gazebo. This is where we get a realistic simulation of our robot, including wheel slippage, skidding, and inertia. We can add objects to this simulation, or even entire maps of real places.

The right window is RViz. This tool allows us to see sensor data from a robot, and give it commands (in a future post). RViz is a more simplified simulation in the interest of speed.

We can now command the robot to go forwards. Open a terminal window, and enter:

rostopic pub /cmd_vel geometry_msgs/Twist -r 100 '[0.5,0,0]' '[0,0,0]'

In the above command, we publish to the cmd_vel topic, of topic type geometry_msgs/Twist, at a rate of 100Hz. The data we publish tells the simulated Grizzly to go forwards at 0.5m/s, without any rotation. You should see your Grizzly move forwards. In the gazebo window, you might also notice simulated wheel slip, and skidding. Enjoy and stay tuned for more soon!

See all the ROS101 tutorials here. If you liked this article, you may also be interested in:

• Up and flying with the AR.Drone and ROS: Getting started
• Taking your first steps in robotics with the Thymio II
• Discovering social robotics with the Aisoy1
• Parrot AR.Drone app harnesses crowd power to fast-track vision learning in robotic spacecraft

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

In the previous ROS 101 post, we showed how easy it is to get ROS going inside a virtual machine, publish topics and subscribe to them. If you haven’t had a chance to check the out all the previous ROS 101 tutorials, you may want to do so before we go on. In this post, we’re going to drive a Husky in a virtual environment, and examine how ROS passes topics around.

An updated version of the Learn_ROS disk is available here:

https://s3.amazonaws.com/CPR_PUBLIC/LEARN_ROS/Learn_ROS-disk1.vmdk
https://s3.amazonaws.com/CPR_PUBLIC/LEARN_ROS/Learn_ROS.ovf

Login (username): user
Password: learn

If you just downloaded the updated version above, please skip the next section. If you have already downloaded it, or are starting from a base install of ROS, please follow the next section.

Updating the Virtual Machine

Open a terminal window (Ctrl + Alt + T), and enter the following:

sudo apt-get update
sudo apt-get install ros-hydro-husky-desktop

Running a virtual Husky

Open a terminal window, and enter:

roslaunch husky_gazebo husky_empty_world.launch

Open another terminal window, and enter:

roslaunch husky_viz view_robot.launch

You should be given two windows, both showing a yellow, rugged robot (the Husky!)

The first window shown is Gazebo. This is where we get a realistic simulation of our robot, including wheel slippage, skidding, and inertia. We can add objects to this simulation, such as the cube above, or even entire maps of real places.

The second window is RViz. This tool allows us to see sensor data from a robot, and give it commands (We’ll talk about how to do this in a future post). RViz is a more simplified simulation in the interest of speed.

We can now command the robot to go forwards. Open a terminal window, and enter:

rostopic pub /husky/cmd_vel geometry_msgs/Twist -r 100 '[0.5,0,0]' '[0,0,0]'

In the above command, we publish to the /husky/cmd_vel topic, of topic type geometry_msgs/Twist, at a rate of 100Hz. The data we publish tells the simulated Husky to go forwards at 0.5m/s, without any rotation. You should see your Husky move forwards. In the gazebo window, you might notice simulated wheel slip, and skidding.

Using rqt_graph

We can also see the structure of how topics are passed around the system. Leave the publishing window running, and open a terminal window. Type in:

rosrun rqt_graph rqt_graph

This command generates a representation of how the nodes and topics running on the current ROS Master are related. You should get something similar to the following:

The highlighted node and arrow show the topic that you are publishing to the simulated Husky. This Husky then goes on to update the gazebo virtual environment, which takes care of movement of the joints (wheels) and the physics of the robot. The rqt_graph command is very handy to use, when you are unsure who is publishing to what in ROS. Once you figure out what topic you are interested in, you can see the content of the topic using rostopic echo.

Using tf

In Ros, tf is a special topic that keeps track of coordinate frames, and how they relate to each other. So, our simulated Husky starts at (0,0,0) in the world coordinate frame. When the Husky moves, it’s own coordinate frame changes. Each wheel has a coordinate frame that tracks how it is rotating, and where it is. Generally, anything on the robot that is not fixed in space, will have a tf describing it. In the rqt_graph section, you can see that the /tf topic is published to and subscribed from by many different nodes.

One intuitive way to see how the tf topic is structured for a robot is to use the view_frames tool provided by ROS. Open a terminal window. Type in:

rosrun tf2_tools view_frames.py

Wait for this to complete, and then type in:

evince frames.pdf

This will bring up the following image.

Here we can see that all four wheel are referenced to the base_link, which is referenced from the base_frootprint. (Toe bone connected to the foot bone, the foot bone….). We also see that the odom topic is driving the reference of the whole robot. This means that if you write to the odom topic (IE, when you publish to the /cmd_vel topic) then the whole robot will move.

In the previous ROS 101 post, we provided a quick introduction to ROS to answer questions like What is ROS? and How do I get started? Now that you understand the basics, here’s how they can apply to a practical example. Follow along to see how we actually ‘do’ all of these things …

First, you will need to run Ubuntu, and have ROS installed on it. For your convenience, you can download our easy-to-use image here:

https://s3.amazonaws.com/CPR_PUBLIC/LEARN_ROS/Learn_ROS-disk1.vmdk
https://s3.amazonaws.com/CPR_PUBLIC/LEARN_ROS/Learn_ROS.ovf

Login (username): user
Password: learn

Get VMWare Player, and use the virtual disk above. If you don’t want to use the provided image, follow the tutorial here (after installing Ubuntu 12.04):

http://wiki.ros.org/hydro/Installation/Ubuntu

Throughout the rest of the tutorials, we will be referencing the ROS cheatsheet available here.

Open a new Terminal Window (Ctrl + Alt + T).
In the new terminal, type roscore (And press enter).
This should produce something similar to the below.

What you have just done is started the ROS Master as we described above. We can now experiment with some ROS commands.
Open a new Terminal, and type in rostopic. This will give you a list of all the options that the rostopic command can do. For now, we are interested in rostopic list
Type in rostopic list. (And press enter). This should give you a window like the following:

The two entries listed above are ROS’s built in way of reporting and aggregating debug messages in the system. What we want to do is publish and subscribe to a message.
You can open a new Terminal again, or open a new tab on the same terminal window (Ctrl + Shift + T).
In the new Terminal, type in: rostopic pub /hello std_msgs/String “Hello Robot”

Let’s break down the parts of that command.
rostopic pub – This commands ROS to publish a new topic.
/hello – This is the name of the new topic. (Can be whatever you want)
std_msgs/String – This is the topic type. We want to publish a string topic. In our overview examples above, it was an image data type.
“Hello Robot” – This is the actual data contained by the topic. I.E. the message itself.
Going back to the previous Terminal, we can execute rostopic list again.
We now have a new topic listed! We can also echo the topic to see the message. rostopic echo /hello

We have now successfully published a topic with a message, and received that message.
Type Ctrl + C to stop echoing the /hello topic.
We can also look into the node that is publishing the message. Type in rosnode list. You will get a list similar to the one below. (The exact numbers beside the rostopic node may be different)

Because we asked rostopic to publish the /hello topic for us, ROS went ahead and created a node to do so. We can look into details of by typing rosnode info /rostopic_…..(whatever numbers)
TIP: In ROS, and in Linux in general, whenever you start typing something, you can press the Tab key to auto-complete it. If there is more than one entry, double tap Tab to get the list. In the above example, all I typed was rosnode info /rost(TAB)

We can get info on our topic the same way, by typing rostopic info /hello.

You will notice that the node listed under “Publishers:” is the same node we requested info about.

Up till now, we have covered the fundamentals of ROS, how to use rostopic, rosnode.

Next time, we will compile a short example program, and try it out.

See all the ROS101 tutorials here. If you liked this article, you may also be interested in:

• Up and flying with the AR.Drone and ROS: Getting started
• Taking your first steps in robotics with the Thymio II
• Discovering social robotics with the Aisoy1
• Parrot AR.Drone app harnesses crowd power to fast-track vision learning in robotic spacecraft

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

Clearpath Robotics brings us a new tutorial series on ROS!

Since we practically live in the Robot Operating System (ROS), we thought it was time to share some tips on how to get started with ROS. We’ll answer questions like where do I begin? How do I get started? What terminology should I brush up on? Keep an eye out for this ongoing ROS 101 blog series that will provide you with a top to bottom view of ROS that will focus on introducing basic concepts simply, cleanly and at a reasonable pace. This guide is meant as a groundwork for new users, which can then be used to jump into in-depth data at wiki.ros.org. If you are totally unfamiliar with ROS, Linux, or both, this is the place for you!

The ROS Cheat Sheet

This ROS Cheat Sheet is filled with tips and tricks to help you get started and to continue using once you’re a true ROS user. This version is written for ROS Hydro Medusa. Download the ROS Cheat Sheet here.

What is ROS?

ROS (Robot Operating System) is a BSD-licensed system for controlling robotic components from a PC. A ROS system is comprised of a number of independent nodes, each of which communicates with the other nodes using a publish/subscribe messaging model. For example, a particular sensor’s driver might be implemented as a node, which publishes sensor data in a stream of messages. These messages could be consumed by any number of other nodes, including filters, loggers, and also higher-level systems such as guidance, pathfinding, etc.

Why ROS?

Note that nodes in ROS do not have to be on the same system (multiple computers) or even of the same architecture! You could have a Arduino publishing messages, a laptop subscribing to them, and an Android phone driving motors. This makes ROS really flexible and adaptable to the needs of the user. ROS is also open source, maintained by many people.

General Concepts

Let’s look at the ROS system from a very high level view. No need to worry how any of the following works, we will cover that later.

ROS starts with the ROS Master. The Master allows all other ROS pieces of software (Nodes) to find and talk to each other. That way, we do not have to ever specifically state “Send this sensor data to that computer at 127.0.0.1. We can simply tell Node 1 to send messages to Node 2.

How do Nodes do this? By publishing and subscribing to Topics.

Let’s say we have a camera on our Robot. We want to be able to see the images from the camera, both on the Robot itself, and on another laptop.

In our example, we have a Camera Node that takes care of communication with the camera, a Image Processing Node on the robot that process image data, and a Image Display Node that displays images on a screen. To start with, all Nodes have registered with the Master. Think of the Master as a lookup table where all the nodes go to find where exactly to send messages.

In registering with the ROS Master, the Camera Node states that it will Publish a Topic called /image_data (for example). Both of the other Nodes register that they are Subscribed to the Topic /image_data.

Thus, once the Camera Node receives some data from the Camera, it sends the /image_data message directly to the other two nodes. (Through what is essentially TCP/IP)

Now you may be thinking, what if I want the Image Processing Node to request data from the Camera Node at a specific time? To do this, ROS implements Services.

A Node can register a specific service with the ROS Master, just as it registers its messages. In the below example, the Image Processing Node first requests /image_data, the Camera Node gathers data from the Camera, and then sends the reply.

We will have another tutorial “ROS 101 – Practical Example” next week.

See all the ROS101 tutorials here. If you liked this article, you may also be interested in:

• Up and flying with the AR.Drone and ROS: Getting started
• Taking your first steps in robotics with the Thymio II
• Discovering social robotics with the Aisoy1
• Parrot AR.Drone app harnesses crowd power to fast-track vision learning in robotic spacecraft

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.