conduct least 3 trials at 3 different start locations in 3 different environments. measure total time, number of collisions. all of your trials must use the same controller '''without modification'''.

+

You are expected to conduct least 3 trials at 3 different start locations in 3 different enclosure environments. Measure and report total time for escape and number of collisions during each trial. All of your trials must use the same controller '''without modification'''.

-

Document your controller and experimental results in a written report. You are welcome to experiment with various enclosure escape algorithms and evaluate the relative performance of each. The details of how this report is graded are discussed in the following section. Example reports are provided in the ``Documents" section of the \href{http://www.cs.brown.edu/courses/cs148/}{course website}. When finished, your report should be committed to the <tt>enclosure_escape/docs</tt> directory of the repository that you checked out.

+

Document your controller and experimental results in a written report based on the structure described in the [http://brown-robotics.org/index.php?title=CS148_Missive#Project_Report_Format course missive]. You are welcome to experiment with additional enclosure escape algorithms and evaluate the relative performance of each. When completed, your report should be committed to the <tt>enclosure_escape/docs/username</tt> directory of the repository that you have created out.

Introduction

This project is structured to acquaint you with the basics of writing robot controllers using ROS (the Robot Operating System) in the context of building an "enclosure escape" robot controller. 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.

Important Dates

Project Assigned: Sept 3, 2010

Project Due: Sept 17, 2010, 11:59pm

ROS Framework and brown-ros-pkg

ROS for Robot Control

A primary motivation of ROS is to facilitate modular design and reuse of software components, portability across robot hardware, and programming language independence. 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 may be a node that handles the basic movement of the robot, and there may be another node that simply publishes information from a camera. From these simple nodes, nodes performing more complex behavior can be created. For example, a node can be created to recognize objects from information provided by the camera driver node. Further, another node take in information about recognized objects and output commands that move the robot to follow selected objects.

Nodes exchange information over an IP network as messages that are topics (handled in a publish-subscribe manner) or services (handled in a request-response manner). 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. Once nodes are matched, the publishing node will talk directly to its subscriber(s). An illustrations of how ROS performs matchmaking is shown (with an additional example, File:Rosmaster.pdf). ROS also uses a parameter server to pass arguments to nodes from the command line using rosparam.

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.

ROS for the iRobot Create

The brown-ros-pkg is a collection of nodes that includes basic sensing and movement functionality for the iRobot Create. For this assignment, you will be using the irobot_create_2_1 package. irobot_create_2_1 publishes messages of the robot's current sensing (e.g., whether the robot's left or right bumper is pressed) and has services for controlling the robot (e.g., the robot's driving speed and rotation).

ROS as a Build Environment

In addition to providing a software interface for robots, ROS also provides a build environment for software development 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.

As you may have noticed, 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.

ROS support packages

ROS installation instructions (optional)

Although cs148 robots have ROS and support packages preinstalled, you can look under the "Getting Started" section of brown-ros-pkg to install these packages on your own computer. The current version of ROS is C-Turtle. For Ubuntu Linux, C-Turtle installation is essentially an apt-get of the ROS binary package and running an automated script (getros.py) from brown-ros-pkg. Installation for other operating systems is similar, but can involve some customization of the installation process.

ROS package for keyboard teleoperation of a mobile robot base. Adapted from the playerjoy utility for Player.

Assignment Instructions

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, you will implement a random traversal controller run experiments to evaluate how well your system can escape from an enclosed area.

Note: lets revisit these instructions based on infrastructure updates

Your tasks for this assignment are as follows.

Setup remote access to the robot's netbook

Run ROS and teleoperate the robot

Write your own random traversal controller

Commit to your group's repository

Conduct experiments and Reporting

Setup remote access to the robot's netbook

Ask one of the TAs for access to the Roomba Lab (CIT 404), an iRobot Create, and an IP address. Choose an appropriate name for your group, which the TA will use to create a repository that will be used later in this assignment.

Turn on the iRobot Create and the mounted netbook computer. Make sure that the netbook is connected to the AIBO wireless network (no password is necessary).

Each netbook has an IP address in the form 10.100.0.x, where x is posted next to each robot name on the whiteboard in the Roobma Lab. Determine the IP address for the robot you are currently working with by looking at the whiteboard or by running the command /sbin/ifconfig on the computer.

From a stationary Roomba Lab computer (or your personal laptop) connected to the AIBO network, open a terminal enter the command:

> ssh obot@IPADDRESS

where IPADDRESS is the IP address of your robot. This will allow you to remotely connect to the robot's netbook, such that you do not have to do your coding on a small laptop. (Note: should we discuss ssh forwarding?)

If successful, you should have a remote terminal shell on the netbook and be able to navigate its filesystem with standard unix commands.

Run ROS and teleoperate the robot

In the background on your ssh connection or in a separate terminal on the netbook, start the ROS master with the roscore command:

> roscore

The ROS Master must be running for other ROS nodes locate each other and communicate. Most ROS nodes will fail if a roscore is not running.

Start, in the background or in a separate terminal on the netbook, the iRobot Create driver with the rosrun command:

Create a temporary projects directory for your group with the command and change directory into it:

> mkdir /home/obot/ros/<GROUPNAME>
> cd /home/obot/ros/<GROUPNAME>

where <GROUPNAME> is the name of your group

NOTE: If there are other groups' folders on this laptop, remove them. The ros package path is set to /home/obot/ros, and so if there is another folder in /home/obot/ros that contains a package of the same name as the one you are creating, ros will complain. It is class policy delete your code from a laptop after you commit it, for this reason, and to also adhere to the academic code.

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

> roscreate-pkg enclosure_escape rospy std_msgs irobot_create_2_1

This automatically creates a directory called enclosure_escape with direct dependencies on two other packages rospy (ROS Python client library) and iRobot Create driver. 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, and paste the following inside it:

run the enclosure_escape node, assume roscore and irobot_create_2_1 are still running

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

Modify enclosure_escape.py to perform random traversal

Committing your package to your repository

The enclosure escape package should be committed to your group's repository. The package we have just created is in a temporary working space on the laptop that could be deleted at any time. Checking your package into a repository on the CS filesystem ensures your code is accessible by everyone in your group and the course staff, protected, backed up, and version controlled to prevent conflicts during collaborative coding. Please read this git tutorial thoroughly at least through the end of chapter four; for now the important parts are below, but you should know everything in this tutorial. Before starting here, be sure you've told the TAs your group name so that you have a repository in the course directory.

We expect your repository to have one folder 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.

Because your repositories will be saved on the department file system, but the code needs to be on the netbooks, we will be using a git daemon to send the git actions.

First, on a department machine, run the git daemon using this command:

> git daemon --verbose --export-all --enable=receive-pack

Now, in your ssh connection (or on the netbook), get a copy of your empty repository, use this command:

> git clone git://<IP ADDRESS>/course/cs148/repo/<GROUPNAME>.git

where <IP ADDRESS> is the ip address of the computer you ran the daemon on (either foxwood or sandworm).

Put the code you've been working on in <GROUPNAME>/escape and then, from that directory, run:

> git add .
> git commit -a -m "My first commit!"
> git push

The last line puts your code into the repository in the course directory.

In order to synchronize your code with the repository, use this command:

> git pull

Experiments and Reporting

You are expected to conduct least 3 trials at 3 different start locations in 3 different enclosure environments. Measure and report total time for escape and number of collisions during each trial. All of your trials must use the same controller without modification.

Document your controller and experimental results in a written report based on the structure described in the course missive. You are welcome to experiment with additional enclosure escape algorithms and evaluate the relative performance of each. When completed, your report should be committed to the enclosure_escape/docs/username directory of the repository that you have created out.

Grading

Your grade for this assignment will be determined by equal weighting of your group's implementation (50\%) and your individual written report (50\%). The weighted breakdown of grading factors for this assignment are as follows: