This project is structured to acquaint you with the basics of writing robot controllers using ROS (the Robot Operating System). This introductory project is in the context of building an random traversal robot controller to “escape” an arbitrary planar environment. ROS runs onboard a robot (or any computing device) and provides a software interface to the robot hardware, such as sensors and actuators, over an IP network. Similar to a hardware abstraction layers for modern operating systems, ROS is considered robot middleware to facilitate portability across robot hardware and reusability of robot software components.
A video of Lisa Miller's implementation of this assignment from Spring Semester 2009:
Project Assigned: Sept 12, 2011
Project Due: Sept 19, 2011, 12:30pm (just before class)
ROS is many things wrapped into one. It is an interface layer for software to work with robots. It is a network protocol. It is a message structure of data types for robots. It is package distribution system. It is a form of inter-process communication. This will get confusing.
Thus, the following is a short high-level description of ROS to help prime your understanding.
A primary motivation of ROS is to facilitate modular design and reuse of software components, portability across robot hardware, and programming language independence. As such, the ROS run-time environment is essentially a means of inter-process communication over internet sockets, but with a large and growing body of support for devices and software libraries used in robotics.
Central to ROS is the concept of a ROS node, ROS's basic building block. Each node is a modular process with some specialized purpose. For example, there are nodes that interface with devices, such as nodes that control the basic movement of a robot or simply publish information from a sensor. Other nodes can provide interfaces to existing software libraries, such as for path planning or visual object recognition. By establishing communication between nodes, more complex behavior can be created. For example, a robot can recognize objects by connecting its node for publishing images to a node for visual object recognition. Further, another node can be created to follow recognized objects by receiving information from the visual object recognition node and sending motor commands to a node that interfaces with the robot's motors. !! example
To moderate communication in ROS, there a special node called the master node. Conceptually, this node is a matchmaker that is responsible connecting publishers to subscribers (or requesters to services) for data messages of a particular ROS topic, using XML-RPC. Once nodes are matched, the publishing node will talk directly to its subscriber(s), using TPCROS or UDPROS. An illustrations of how ROS performs matchmaking is shown. ROS also uses a parameter server to pass arguments to nodes from the command line using rosparam.
At runtime, the publish-subscribe connections between nodes forms a graph representing the flow of information. Information about this graph can be accessed in various ways provided by ROS. For example, the rxgraph utility will show a visual display of all nodes and their topic connections currently executing. The rostopic command-line utility allows for querying and analysis of topics currently active in ROS.
A more complete conceptual and technical overview of ROS is described on the main ROS web site.
As surveyed by Huang et al., it should be noted that ROS is only one of many viable robot middleware frameworks. Also, the core functionality of ROS is to perform socket-based inter-process communication, or “communications and marshalling” as described for the LCM library. The “robot” aspects of ROS are due to its support for robot-related devices and software, which are a complementary but orthogonal features to inter-process communication.
In addition to providing a software interface for robots, ROS also provides a development environment that resembles a package management system. The package is the primary element in the ROS build environment “that logically constitutes a useful module.” A package is typically a directory containing a collection of ROS nodes with related files, such as service and message definitions, makefiles, and external libraries. Packages can be compiled using the rosmake or rosdep commands, handling the process of building executable nodes and “some special ROS magic.” The ROS build system uses CMake at its core. Packages can be created using the roscreate-pkg command, providing a skeleton of a valid package as a starting point. Dependencies for a package can be found using the rospack command.
ROS stacks are used to organize collections of packages for code sharing. Stacks are the software units ROS uses for testing, release, and distribution of software modules. The resulting modules are binary Debian packages that are available via apt-get as part of a ROS distribution.
Due to its distribution-centered design, ROS tends to rosinvent existing unix tools for easier navigation of ROS packages. For example, rosbash includes several ros-ified commands such as roscd, rosls, etc.
Although ROS nodes can be developed in any programming language that can support ROS messages, the only languages with first-class support as ROS client libraries are currently for Python and C++. Java support for ROS was announced recently, but is unsupported by cs148. Support deemed unworthy of first-class support by the powers governing ROS will also not be supported in cs148.
CS148 robots have ROS and support packages preinstalled. So, there is no need for you to create your own ROS installation.
However, if you want to have your own ROS install (which is very helpful), directions are on the ROS installation page. ROS is currently transitioning versions, between the older “Diamondback” and the new “Electric” versions. For this class, at least initially, we will be using the older, more stable Diamondback release.
Linux support ROS's package management system is primarily designed for the Ubuntu Linux operating system, but should work with most common Linux distributions. You can install ROS and the Turtlebot-specific stacks on your Ubuntu system easily, using apt-get:
sudo apt-get install ros-diamondback-desktop-full sudo apt-get install ros-diamondback-turtlebot-desktop sudo apt-get install ros-diamondback-brown_remotelab
OS X support It can be made to work with Mac OS X, but not without a fair amount of work – if you wish to try, details are also found at the ROS installation page.
Windows and other OS support Direct use of ROS in Windows and non-Linux operating systems is not yet supported. However, we will spend time later in the class with rosbridge, a ROS proxy that enables non-ROS applications to use ROS from any platform or development environment using JSON messaging.
ROS by virtual machine We very much recommend that you use Ubuntu Linux; if you are running OS X or Windows it is probably best to install a virtual machine running Ubuntu via VmWare or Virtualbox. brown-ros-pkg has a ROS quick start guide installing ROS and provides a VMWare image with ROS pre-installed.
For this assignment, you will be expected to work with an existing installation of ROS to write a simple random traversal controller to escape a static environment.
Before writing your own controller, you must first setup the robot and verify that it is running properly. Once your controller is completed, your robot will be able to escape from an enclosed area by bumping into walls and reacting appropriately.
Your tasks for this assignment are as follows.
For the most part, the sections below will follow the Turtlebot bring up and teleop tutorials from ros.org:
First, you will need access to CIT 404 where the robots reside:
Next, you need to find a group to work with for the semester:
Now, you should be ready to use the robot. The robot base and computer should already be plugged in to power:
> roslaunch ~/turtlebot.launch
> rosrun turtlebot_dashboard turtlebot_dashboard
Turtlebot bring up tutorial and video from ros.org:
[Note: This video contains instructions for running the turtlebot dashboard from another computer. Your 148 TA staff is working on solving networking issues so that we can do this. Ignore these instructions for now; we'll have the network ready within a couple of weeks and will provide instructions when ready and necessary.]
When the robot is started, it will be in passive mode. When you are ready to make the robot move, enable “Full mode” on the Turtlebot dashboard, by clicking on the cog-wheel icon.
This tells the robot to begin accepting motor commands. Then run the teleoperation interface from the brown_remotelab package.
rosrun teleop_twist_keyboard teleop_twist_keyboard.py /cmd_vel:=/turtlebot_node/cmd_vel
This command tells the robot to run the teleop_twist_keyboard.py program, found in the teleop_twist_keyboard stack, and remaps the /cmd_vel topic (which is where the teleop program publishes its motor commands) to the /turtlebot_node/cmd_vel topic (which is where the Turtlebot driver is listening for motor commands). If successful, you should see the following interface appear in the teleoperation terminal and control the robot (driving and turning speed) from your keyboard.
Reading from the keyboard and Publishing to Twist! --------------------------- Moving around: u i o j k l m , . q/z : increase/decrease max speeds by 10% w/x : increase/decrease only linear speed by 10% e/c : increase/decrease only angular speed by 10% anything else : stop CTRL-C to quit
Have fun driving the robot around. If it works, then everything is configured properly. If not, time to track the problem down.
Please see and follow the instructions in Turtlebot Hardware Setup.
We highly recommend that you go through the ROS tutorials on ros.org. These instructions roughly follow the ROS tutorial on creating a simple publisher and subscriber. We skip over several helpful details and features in the interest of being concise.
In this section, you will create a ROS package that will allow you to implement enclosure escape. You will modify the source in these instructions for implementing the random walk robot behavior for enclosure escape. The following steps describe how to create, build, and execute ROS packages for a sample robot controller:
mkdir <groupname> cd <groupname>
source /opt/ros/diamondback/setup.bash export ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:/path/to/<groupname>
roscreate-pkg enclosure_escape rospy std_msgs turtlebot_node
This automatically creates a directory called enclosure_escape with direct dependencies on two other packages rospy (ROS Python client library) and Turtlebot node. These packages depend on several other packages, which can be found using the rospack command. roscreate generates a number of files for building the new package, as described in the roscreate tutorial.
#!/usr/bin/env python import roslib; roslib.load_manifest('enclosure_escape') import rospy from geometry_msgs.msg import Twist from turtlebot_node.msg import TurtlebotSensorState # global variables bump = False # listen (adapted from line_follower def processSensing(TurtlebotSensorState): global bump bump = TurtlebotSensorState.bumps_wheeldrops > 0 #newInfo = True def hello_create(): pub = rospy.Publisher('/turtlebot_node/cmd_vel', Twist) rospy.Subscriber('/turtlebot_node/sensor_state', TurtlebotSensorState, processSensing) rospy.init_node('hello_create') #listen global bump twist = Twist() while not rospy.is_shutdown(): if bump: str = "hello create, you have bumped into something %s"%rospy.get_time() rospy.loginfo(str) twist.linear.x = 0; twist.linear.y = 0; twist.linear.z = 0 twist.angular.x = 0; twist.angular.y = 0; twist.angular.z = 0 bump = False else: str = "hello create, you can spin now %s"%rospy.get_time() rospy.loginfo(str) twist.linear.x = 0.1; twist.linear.y = 0; twist.linear.z = 0 twist.angular.x = 0; twist.angular.y = 0; twist.angular.z = 0.1 pub.publish(twist) rospy.sleep(0.25) if __name__ == '__main__': try: hello_create() except rospy.ROSInterruptException: pass
chmod +x nodes/enclosure_escape.py
rosrun enclosure_escape enclosure_escape.py
If successful, you should see the robot move forward at an angle, and stop when it bumps into something.
For setting up your git repository, see repository_setup.
We expect your repository to have one branch for each project. While you will be able to view or tamper with the repositories of other groups, doing so is a violation of the honor code and we'll notice.
We will be using a script to checkout your code to test it. This will be completed and posted shortly.
Hint: For your first commit, cd into the root directory of your git repository, and:
> git add . > git commit -a -m "My first commit!" > git push
The last line puts your code into the repository online.
In order to synchronize your code with the repository, use this command:
> git pull
When you have finished with your Turtlebot for the time being, stop all of the ROS nodes running on your own computer except for the Turtlebot dashboard. Commit and delete all of your code on the robot, if you were working with your own code. Put the machine back into Passive mode again by clicking on the cog-wheel icon on your dashboard. This is important. The robot will not charge unless it is in Passive mode. Plug power cables into both the computer and the robot base, and verify on your dashboard that the battery icons now indicate charging. At this point, you can stop the dashboard on your own machine and leave.
To submit this project, create a branch of your repository named “submit_enclosure_escape”. This code will be checkout and run by the course staff, without modification. This code will be tested against two environments with five trials for each enclosure. Sample enclosures are outlined below:
A script will be provided soon to test automated checkout and execution of your code on a Turtlebot.