1 National Institute of Standards and Technology

100 Bureau Drive, Mailstop 8230\
Gaithersburg, MD USA 20899

adam.jacoff@nist.gov[\
](http://www.springer.de/comp/lncs/index.html)<http://robotarenas.nist.gov/competitions.htm>

2 International Rescue System Institute

Kobe KIMEC Center Bldg. 2F\
1-5-2 Minatojima-Minami-Machi, Chuo-ku, Kobe 650-0047 Japan

tadokoro@rescuesystem.org

**Abstract.** This Team Description Paper template is based on the
Springer publication format, so please adhere to all formatting as
shown. The abstract should summarize the contents of this Team
Description Paper (so write it last!) and should contain at least 70 and
at most 150 words. Please edit the items in the title section above as
necessary to include your TeamName, Country, Authors, Addresses, Email,
and Websites. Please use the numbering scheme shown for authors from
multiple organizations.

Introduction

Please use this **Team Description Paper (TDP)** template to answer the
following questions about your team's approach to designing,
fabricating, controlling, and operating your urban search and rescue
robot team. We will likely have many more teams interested in
participating than we can accommodate, so we will use this paper to
initially qualify your team for final registration. We are looking for
teams showing solid progress toward a functioning system, particularly
innovative approaches, and well formulated (and well described) team
strategies. Timely submittal of this and other documents is also
appreciated.

It is very important that you follow this particular template regarding
formatting (paragraph types, figures, footnotes, everything!). This
template is the exact format used to publish these **Team Description
Papers** in the **RoboCup Book** following each competition (published
by Springer as part of their series called Lecture Notes on Artificial
Intelligence). Consider this the beginning of the process of documenting
your team's approach for eventual publication. We ask that you follow
the headings below as an outline to describe your team personnel,
robots, interfaces, and team strategies.

We understand that at this early date your system is likely not fully
realized, so we expect this document to be incomplete in parts. ***We do
not expect a polished paper at this time, but rather a comprehensive
discussion of your team's approach**.* However, we expect you to
articulate at least some ideas in each area outlined below. The more
comprehensive your approach appears, the more favorably it will be
reviewed. If you have hardware implemented, please add lots of pictures
as you describe your system, and give details regarding the parts
themselves (sensors, motors, joysticks, etc). If you have drawings of
your system, please include them. If you have particular team
strategies, please describe them. Otherwise, please attempt to describe
at least the direction you are going in any given section and what we
can expect to see at the competition. Please also describe how your
operator(s) plan to interact with your system.

As mentioned earlier, this is only a preliminary draft of your **Team
Description Paper**. It is meant to prompt you into considering all
aspects of the task, so that you are not surprised, or thwarted, by any
particular area. After the competition, you will have another
opportunity to add, modify, and enhance your team description prior to
publication in the RoboCup book. After a week of intensive collaboration
with other teams at the competition, and the inevitable last minute
development that occurs, your system will likely change for the better.
We'll want to capture that development and publish your successful
implementations so that others may benefit from your experience. That is
the ultimate goal of this paper.

So remember, add many pictures and drawings below to help explain your
approach. See the Appendix at the end of this document for guidelines to
insert figures, tables, computer code, and references in the document
text according to the Springer format. Pay attention to these details
the first time and you won't have to do it over prior to publication.

Also, **Travel Support** requests should be made using a separate form
available on the website. If you need travel support for your team,
please complete this form and we will forward your request to the
General Chair for the event.

Finally, good luck with your preparations! We're very much looking
forward to seeing what you've developed!

1.  Team Members and Their Contributions

Please use this section to recognize all team members and their
technical contributions. Also note your advisors and sponsors, if you
choose.

-   Adam Jacoff Controller development

-   Satoshi Tadokoro Mechanical design

-   Brian Weiss Operator

-   Elena Messina Advisor

-   Al Wavering Sponsor

2.  Operator Station Set-up and Break-Down (10 minutes)

Please use this section to describe your plan for set-up and break-down
of your operator station. Note that this task must be accomplished in
**less than** **10** **minutes**. The rules from last year may be
modified to apply penalties for taking longer. As with previous years,
there will be a table and chairs available for your use. It is extremely
critical that your operator station be set up with a minimum number of
operators -- preferably the same operators that run the robots. Eventual
deployment at a real disaster site will likely require your system to be
backpack-able, along with your robots. So consider climbing a ladder
with your robot and operator controls as the ultimate goal. For the
purposes of this competition, you may be larger and heavier (this year).
But we encourage you to at least start considering a system that is
integrated into a movable chassis with wheels, handles, operator seat,
whatever. Large roller tool boxes or storage containers may be useful.
Your efforts in this regard will not go overlooked!

3.  Communications

Please use this section to describe your plan for communicating with
your robots (passive tether, active tether, radio, etc.) Keep in mind
that radio transmissions are inherently problematic in complex
environments, due ton conflicting radio traffic, obstacles in the
environment, and range issues. So don't expect perfect radio signals
ever, and plan for radio drop-out because it will happen! Even the
relatively saturated radio frequencies at the RoboCup, as problematic as
they are, don't compare to the radio transmission problems experienced
at an actual disaster response. So plan to make your system functional
in adverse environments!

If you are using radio communications, we specifically caution
that**...**

CERTAIN RADIO FREQUENCIES WILL BE RESTRICTED FOR USE AT THE COMPETITION
\-- CHECK THE WEBSITE FOR THE LATEST AVAILABLE INFORMATION REGARDING
DISALLOWED FREQUENCIES, ASSIGNED CHANNELS FOR EACH LEAGUE, AND USE OF
YOUR OWN ACCESS POINTS

http://robotarenas.nist.gov/competitions.htm

We have had problems in the past conflicting with other leagues using
the same frequencies, so we must negotiate usage agreements among the
leagues at these large venues. We simply cannot interfere with other
leagues, which rely on radio to administer their games too \--
especially with streaming video!

EFFECTIVE USAGE OF RADIO FREQUENCY CANNOT BE GUARANTEED!

TRANSMITTING ON ANOTHER LEAGUE'S ASSIGNED FREQUENCY, OR ON ANOTHER
TEAM'S ASIGNED FREQUENCY, (EVEN INADVERTENTLY) IS GROUNDS FOR
**DISQUALIFICATION**

We have to be very strict on this, as these are huge events and
difficult to manage - we're trying to be considerate of other teams and
leagues. Each league will have certain channels assigned to it in the
popular wireless LAN frequencies. For example, our Rescue Robot League
may have only one 802.11B/G channel to use of the three non-overlapping
channels (CH1, CH6, or CH11), and maybe two or three of the eight
non-overlapping 802.11A channels. So we **STRONGLY RECOMMEND** using
**802.11A (5GHz)** radio communications for your wireless LANs since the
league will have more 802.11A channels to use, and we've seen far better
performance on A channels over B/G channels.

You will be expected to set up your own team access points (APs), but
must strictly adhere to the single channel we assign you. **APs THAT
USE** **FREQUENCY HOPPING** **TO FIND THE BEST CHANNEL ARE NOT
ALLOWED**, as they may end up on another league's channel and be cause
for disqualification. (NetGear APs can be set to a stay on a specific
channel, and others manufacturers should allow this as well.) **See the
website for final details on all radio channels \-- all competition
venues handle their radio frequency restrictions differently!**

Initially, teams using LINUX had problems finding drivers, but that
should be remedied by now (try the mailing list noted on the website, or
the FAQs, if you're still having trouble). Once onsite at the
competition, we will reserve and schedule channels for practice sessions
and competitive missions.

If you do plan to use radio transmissions of any type, please modify the
table below to **specify which frequencies your team expects to use**.
Fill in the rows that apply, add other specific frequencies and power
levels if necessary, and delete the rows that don't apply to your team.
If there is overlap across teams, we'll need to coordinate schedules for
those other frequencies as well.

  --------------------------------- ------------------- ------------------
  **Rescue Robot League**                               

  TEAMNAME (COUNTRY)                                    

  MODIFY TABLE TO NOTE                                  
  [ALL]{.underline} FREQENCIES THAT                     
  APPLY TO YOUR TEAM                                    

  **Frequency**                     **Channel/Band**    **Power (mW)**

  5.0 GHz - 802.11a                                     

  2.4 GHz - 802.11b/g                                   

  2.4 GHz - Bluetooth               spread-spectrum     

  2.4 GHz - Other                                       

  1.2 GHz                                               

  900 MHz                                               

  40 MHz                                                

  27 MHz                                                

  \<FILL IN OTHER\>                                     

  \<FILL IN OTHER\>                                     
  --------------------------------- ------------------- ------------------

4.  Control Method and Human-Robot Interface

Please use this section to describe your plan for controlling your robot
\[remote teleoperation, partial autonomy, full autonomy\], and your
human-robot interface for robot control and victim recognition.. Also
explain what your operator will be doing during missions and which tasks
are autonomous.

5.  Map generation/printing

Please use this section to describe your plan for generating the map
that you will submit immediately after each mission. The rules and the
performance metric clearly highlight the need for easy to understand,
accurate maps. You'll see that automatically generated, sensor-based
maps are clearly encouraged. Operators may annotate items of interest
(like victims) or correct data. The intent is to improve accuracy and
relieve the operator of the intensive, ongoing workload associated with
remote situational awareness. We want to see improvements over having
your operator watch a video stream and draw a map. So please describe
how you intend to track arena features, mark victims, and generally
produce maps of the environments.

6.  Sensors for Navigation and Localization

Please use this section to describe the sensors you use for navigation
\[tactile, acoustic, ultrasonic, infrared, visual, laser, chemical,
encoder, other\], and explain how you use them.

7.  Sensors for Victim Identification

Please use this section to describe the sensors you use for victim
navigation \[tactile, acoustic, ultrasonic, infrared, visual, laser,
chemical, encoder, other\], and explain how you use them.

8.  Robot Locomotion

Please use this section to describe your system of locomotion \[wheeled,
tracked, legged, air propulsion, other\], and explain how you use them.

9.  Other Mechanisms

Please use this section to describe other innovative mechanisms in your
system not described in a previous section.

10. Team Training for Operation (Human Factors)

Please use this section to describe what kind of training is required to
use your system, and what kind of skills are beneficial for operators of
your system. Also, how you went about training your team members for the
competition.

11. Possibility for Practical Application to Real Disaster Site

Please use this section to describe how close your system is to
practical application at a real disaster site. What part of your system
do you think is robust enough to handle field testing right now, and
what would you want to improve upon before attempting such field trials.
Of course, you will have a much better idea of this after the
competition. But hopefully you have seen some inspiring successes in
your practice sessions.

12. System Cost

Please use this section to total the costs of key system components and
the overall expense of your system. In this section, we're looking for
particular information that other teams could use to replicate your
successful approaches. So part numbers, prices and websites are much
appreciated. This information will only be available to the other teams
(and the public) when it is published in the Springer Book long after
the competition is complete.

13. Lessons Learned

After the competition is over, please use this section to add your
thoughts on the lessons your learned from deploying your robot and
watching others. Your system will change leading up to the event and
during the event as you react to changes in your assumptions. This
section should capture those changes (although you may also modify all
the previous sections as well), and articulate the lessons you took from
the experience which will refine your system design.

References

(See Appendix for proper citation formatting)

APPENDIX: General Formatting Hints (you may delete this section to the
end of the document prior to submitting!)

Please use the general formats below in your document where appropriate.
The easiest way is to simply copy and paste the following item and edit
the content as appropriate to insert your information.

**Table 1.** Font sizes of headings. Table captions should always be
positioned *above* the tables. The final sentence of a table caption
should end without a period

  -------------------- ----------------------------- --------------------
  Heading level        Example                       Font size and style

  Title (centered)     **Lecture Notes ...**         14 point, bold

  1^st^-level heading  **1 Introduction**            12 point, bold

  2^nd^-level heading  **2.1 Printing Area**         10 point, bold

  3^rd^-level heading  **Headings.** Text follows    10 point, bold
                       ...                           

  4^th^-level heading  *Remark.* Text follows ...    10 point, italic
  -------------------- ----------------------------- --------------------

2.3 Figures and Photographs

![](media/image1.png){width="2.53125in" height="2.3493055555555555in"}

**Fig. 1.** One kernel at *xs* (*dotted kernel*) or two kernels at *xi*
and *xj* (*left and right*) lead to the same summed estimate at *xs*.

2.4 Formulas

Displayed equations or formulas are centered and set on a separate line
(with an extra line or halfline space above and below). Displayed
expressions should be numbered for reference. The numbers should be
consecutive within each section or within the contribution, with numbers
enclosed in parentheses and set on the right margin. For example,

  ---------------------------------------------------------------- ------
  x + y = z .                                                      ()

  ---------------------------------------------------------------- ------

Please punctuate a displayed equation in the same way as ordinary text
but with a small space before the end punctuation. LaTeX users can find
more examples of how to typeset equations in the file llncs.dem (see
Sect. 3).

2.5 Program Code

Program listings or program commands in the text are normally set in
typewriter font, e.g., CMTT10 or Courier.

Example of a Computer Program from Jensen K., Wirth N. (1991) Pascal
user manual and report. Springer, New York

program Inflation (Output)\
{Assuming annual inflation rates of 7%, 8%, and\
10%,\... years};\
const MaxYears = 10;\
var Year: 0..MaxYears;\
Factor1, Factor2, Factor3: Real;\
begin\
Year := 0;\
Factor1 := 1.0; Factor2 := 1.0; Factor3 := 1.0;\
WriteLn(\'Year 7% 8% 10%\'); WriteLn;\
repeat\
Year := Year + 1;\
Factor1 := Factor1 \* 1.07;\
Factor2 := Factor2 \* 1.08;\
Factor3 := Factor3 \* 1.10;\
WriteLn(Year:5,Factor1:7:3,Factor2:7:3,\
Factor3:7:3)\
until Year = MaxYears\
end.

2.6 Footnotes

The superscript numeral used to refer to a footnote appears in the text
either directly after the word to be discussed or -- in relation to a
phrase or a sentence -- following the punctuation sign (comma,
semicolon, or period). Footnotes should appear at the bottom of the
normal text area, with a line of about 2cm in TeX and about 5cm in Word
set immediately above them.[^1]

2.7 Citations

The list of references is headed "References" and is not assigned a
number in the decimal system of headings. The list should be set in
small print and placed at the end of your contribution, in front of the
appendix, if one exists. Please do not insert a pagebreak before the
list of references if the page is not completely filled. An example is
given at the end of this information sheet. For citations in the text
please use square brackets and consecutive numbers: \[1\], \[2\],
\[3\], ...

2.8 Page Numbering

Your paper should show no printed page numbers; these are allocated by
the volume editor.

References

1\. Baldonado, M., Chang, C.-C.K., Gravano, L., Paepcke, A.: The
Stanford Digital Library Metadata Architecture. Int. J. Digit. Libr. 1
(1997) 108--121

2\. Bruce, K.B., Cardelli, L., Pierce, B.C.: Comparing Object Encodings.
In: Abadi, M., Ito, T. (eds.): Theoretical Aspects of Computer Software.
Lecture Notes in Computer Science, Vol. 1281. Springer-Verlag, Berlin
Heidelberg New York (1997) 415--438

3\. van Leeuwen, J. (ed.): Computer Science Today. Recent Trends and
Developments. Lecture Notes in Computer Science, Vol. 1000.
Springer-Verlag, Berlin Heidelberg New York (1995)

4\. Michalewicz, Z.: Genetic Algorithms + Data Structures = Evolution
Programs. 3rd edn. Springer-Verlag, Berlin Heidelberg New York (1996)

[^1]: The footnote numeral is set flush left and the text follows with
    the usual word spacing. Second and subsequent lines are indented.
    Footnotes should end with a period.