Lab 7: USAR
Lead TAs: Akshay Jayaram, Rexy Tseng, Max Harper, Jong Eun Kim and Alex May

Note: Only group members present for ALL stages of evaluation will receive a grade.

Proposal Presentation

Final Demo Presentation

Grading Sheet Proposal

USAR Package (bring to event)


Special Thanks to NIST

Important Dates

Introduction
Challenge
Design Criteria
Evaluation
Additional Links



Important Dates:


Note: all team members must be present during demos to receive grades for project proposal evaluation, checkpoints, and the USAR demonstration (HW 8, 9, 10).
Proposal Submission: March 17th, 2009
Prototype Evaluation: March 23th or March 24th, 2009 (20:00h latest)
Prototype Selection: March 25th, 2009
USAR Demonstration: March 31st, 2009
USAR Final (TBA): April 1st, 2009
Post USAR discussion:
(Poster & Self Evaluation due) 		April 6th, 2009



Introduction:

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.

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

MPEG movie




Challenge:


Special Thanks to Center for Robotic Assited Search and Rescue
In light of recent events of the World Trade Center disaster and previous disasters such as the Oklahoma City bombing, the need for improved rescue efforts are growing. Hence, the Carnegie Urban Rescue Force (CURF) has funded Carnegie Mellon University's Introduction to Robotics class of Spring 2009 to develop a fleet of highly mobile, all-terrain and easy to use mobile robots to assit in Urban Search and Rescue efforts.
All contractor teams from Introduction to Robotics class of Spring 2009 are urged to submit their design proposal no later than March 17th, 2009 to be eligible for a full award for future work.
Upon approval of the proposals, each contractor will have one week to demonstrate a working prototype of their concept. A Prototype Review Board will then evaluate all working designs and select the ones that satisfy the evaluation requirements.
The selected prototypes will then move onto the final phase of the project.



Design Criteria:

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:


Width: 7.0"
Depth: 8.5"
Height: 6.0"

(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 Handyboard group will be allowed 4 LEGO motors, and each NXT group will be allowed 3 motors. (These motors will not count towards your $20 extra parts budget.)

You are encouraged to pursue additional resources for LEGO parts, within a $20 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




Evaluation:

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.

You must explain how you plan for your robot to handle different obstacles like stairs, doors, broken furniture, rocks, cars, etc. The exact contents of this report and grading sheet are listed below. This proposal must be handed in by Tuesday, March 17th Note that at this point you do not have to demonstrate a working prototype.

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

Note: if an evaluator approves a feature in your proposal that violates one of the rules, unless you have written permission from head TA, your team still cannot use the feature.


Prototype Evaluation:

Your robot must pass several tests demonstrating basic mobility on Monday, March 23 and Tuesday, March 24 ). 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

Presentation

On March 31st your team will demonstrate their robot. Teams will be given 15 minutes to navigate a disaster scene (and 5 minutes setup). 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 1st

Rule Clarifications:

-The elevator will drop to the first floor as soon as the manual override ceases to be pressed.
-Each robot is allowed 3 resets per run. A reset does not reset the time. A reset will NOT zero that teams points.
-A team may call a reset at anytime.
-If a robot falls from the second or third floor onto the classroom floor (does not land on a lower floor) that team will be forced to use a reset.
-If a robot was on the first floor and comes into contact with the classroom floor it will be immediately picked up and placed in the orientation and position it was last in on the first floor.
-After calling a reset, the team may inspect and repair their robot, but the clock will not be stopped. When ready the robot will be placed at its original entry point to the floor it was on.
-If a team requires a reset or is forced to use one, but has no remaining resets, their run is over.
-All reset rules apply to individual robots and not to their allied robots.

Finalist times
USAR Package (bring to event)

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.

Poster Template
Self Evaluation





Additional Links

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: 3/19/2009 by Somchaya Liemhetcharat
(c) 1999-2009: Howie Choset, Carnegie Mellon