Strict Standards: Declaration of action_plugin_safefnrecode::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /home/brownrob/public_html/cs148/lib/plugins/safefnrecode/action.php on line 14

Strict Standards: Declaration of action_plugin_popularity::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /home/brownrob/public_html/cs148/lib/plugins/popularity/action.php on line 57

Warning: Cannot modify header information - headers already sent by (output started at /home/brownrob/public_html/cs148/lib/plugins/safefnrecode/action.php:14) in /home/brownrob/public_html/cs148/inc/auth.php on line 352

Strict Standards: Declaration of Doku_Renderer_metadata::table_open() should be compatible with Doku_Renderer::table_open($maxcols = NULL, $numrows = NULL, $pos = NULL) in /home/brownrob/public_html/cs148/inc/parser/metadata.php on line 24

Strict Standards: Declaration of Doku_Renderer_metadata::table_close() should be compatible with Doku_Renderer::table_close($pos = NULL) in /home/brownrob/public_html/cs148/inc/parser/metadata.php on line 24

Warning: Cannot modify header information - headers already sent by (output started at /home/brownrob/public_html/cs148/lib/plugins/safefnrecode/action.php:14) in /home/brownrob/public_html/cs148/inc/actions.php on line 180
enclosure_escape – Introduction to Autonomous Robotics

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.

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

XML-RPC (over HTTP) to negotiate connections with other nodes and the ROS master (described below)

TCPROS (over TCP) (or UDPROS over UDP) for transport of data as topic and service messages

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.

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.

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:

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.

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.

Find a partner and choose one of the names on the whiteboard in 404 as the team name. The TA will use this to create a repository that will be used later in this assignment.

Now, you should be ready to use the robot. The robot base and computer should already be plugged in to power:

Unplug the power cords from the Turtlebot base and computer.

Ensure that the robot base is turned on (a green light should glow next to the power button). Connect the two USB cables to the laptop.

Unplug the two USB cables connecting the Turtlebot computer to the rest of the robot.

Turn on the computer (if necessary) and log in: userid and password are both your team name initially. Feel free to change your password. (Note: that you will have to do this for each robot.)

From a terminal window, use roslaunch to launch the Turtlebot driver on the Turtlebot computer. roslaunch is a means to start the execution of a collection of ROS nodes automatically. Each Turtlebot has a launchfile in the /home/turtlebot directory that sets some calibration parameters and then brings up some subset of the Turtlebot's functionality. For this assignment, the “minimal.launch” file provides functionality that we need for now:

[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.]

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.

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:

Create a directory somewhere where an appropriate version of ROS is installed (either on your machine or your account on the robot). This directory will become the root of a git source repository, as noted below:

mkdir <groupname>
cd <groupname>

ROS needs to be told to look in this directory in order to find robot programs. You can run this command inside every terminal shell you start, or you can add it to a .bashrc file for convenience:

Create a ROS package for your enclosure escape code using the roscreate-pkg command:

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.

Change directory into the enclosure_escape package:

roscd enclosure_escape

Create the nodes directory within the enclosure_escape package:

mkdir nodes

Create a file called nodes/enclosure_escape.py (file), and paste the following inside it:

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:

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.