This lab is intended to encourage investigation into different types of robot locomotion and control. We will do this within the theme of urban search and rescue.

Powerpoint presentation here

To get a better picture of this lab, please watch the following footage from a real urban search and rescue robot.

MPEG movie

Size:

Due to the nature of this project, CURF requires your robot to meet certain constraints.

Since the robot is intended to assist in search and rescue missions, the size of the robot is a very important design factor. Hence. the following dimensions must not be exceeded:

(NOTE: These dimensions are for your entire robot and DO include the vision system. Make sure you design your robot appropriately.)

Tele-Operation

All robots should be tele-operable from a remote command center consisting of a computer terminal and a video monitor. Using the Interactive C text interface, you can control your robot (which will be connected to the robot by a tether control line) by calling software functions stored on your robot. This control paradigm is often referred to as semi-autonomous, where the operator provides some high level control directing the robot in its autonomous actions. We have provided instructions and sample code with which you can control your robot using your keypad. We highly encourage you to use the code provided or any other method that you are familiar with how to tele-operate your robot.

Instructions
Sample Code

Vision System:

We will be providing you with a camera and two flashlights with a LEGO base that you will need to mount onto your robot. For more information follow the link below to the vision system page.

Vision System
Vision Contract

Cable

All teams must use the pre-approved cable harness (ie. the telephone cable that interfaces with the handyboard)

Power

All power must be on board the robot

Extra Parts

Each group will be supplied one extra LEGO motor to help in the manipulation. (This motor will not count towards your $50 extra parts budget.)

You are encouraged to pursue additional resources for LEGO parts, within a $50 spending limit (of your own money). See the class bboard or email the USAR team for approved "rare" parts and ordering info. Any common household stuff (like tape) and common hardware store items can be used as well. Basically this means anything that can be bought at a grocery store or hardware store, etc. For a list of acceptable parts follow the link below. Please note the list is not complete, if you are considering a part not on the list ask a member of the CURF staff.

Preapproved Extra Parts List

Design Proposal:

CURF requires your team to submit a design proposal outlining your plans for your USAR robot. This write-up should include a basic schematic, descriptions of how your robot works, especially any "special" features it will have.

Proposal Guideline
Proposal Grading
Sample Proposal (note that the sample proposal is not the official guideline; it lacks evaluation of the metrics in alternative designs which is required)

Prototype Evaluation:

Your robot must pass several tests demonstrating basic mobility on Monday, March 26 and Tuesday, March 27 ). These tests include climbing a slope or moving over uneven terrain. Refer to the checkpointwebpage for more detials.

The TA who evaluated your proposal must be present for the check point evaluations.

Checkpoint Webpage

USAR Demonstration

On April 3rd your team will demonstrate their robot. Teams will be given 10 minutes to navigate a disaster scene. Points will be awarded for locating victims, identifying victims, and clearing rooms. For scoring details, refer to the grading sheet at the top of this page. The top teams will be invited to demonstrate their robot on April 4th

Poster and Self Evaluation

All teams must submit a poster of their USAR robot and team. The poster must measure 8.5" x 11" and contain a description of the robot, a picture of the robot, and a picture of all team members. Refer to link below for poster template.

For extra credit (upto 10 points) the CURF review board has decided to award additional points to teams who are willing to provide a description of their USAR experience: what they learned, what went well, and what did not go so well. Follow the second link below for the full announcement.

Peter Friedman's code

There are two versions of the code - the one provided with the example and the one that was modified by students previously to work with newer versions of IC and include provisions for serial timeouts. However, the newer version stores recieved chars to a char*, thus you need to pass a pointer around. Peter modified the newer code so that the integer returned by the serial_getchar() function actually returns the int of the char received instead.

The original code was:
int serial_getchar(int timeout, *char)

the new one is:
int serial_getchar(int timeout) which returns the int representation of the char recieved.

This has been tested with the version of IC on the laptops in the REL and both HyperTerminal as well as TerraTerm pro.

last updated: March 22, 2007 by Dewey Yang
(c) 1999-2007: Howie Choset, Carnegie Mellon