The most essential elements for a CotsBot are a Mica mote for the computation and communication,
a mobility platform to provide the motors and wheels/treads, and a motorboard to interface between the two.

The Mica Mote (current generation is Mica2) is available from Crossbow Technology Inc..
If you're feeling cheap, there are also complete schematics, layouts, and a bill of materials listed on the
TinyOS hardware site. It looks like these only exist for the
designs done at Berkeley though -- up to the Mica mote (not including Mica2).

The CotsBots are designed so that you can theoretically use any chassis you'd like underneath. The hardware is abstracted
through different software components, much like drivers abstract the hardware for operating systems. We have used two
primary platforms up to this point -- the Kyosho Mini-Z Racer and the Plantraco Desktop Rover. Only software for the Mini-Z is
available online currently, but the rover software should be available soon. The Mini-Z is available from most hobby shops, but
online they may be found at Tower Hobbies as well as many other places. We've used the
BMW Z8, Volkswagon Beetle, and Honda S-2000 and Tower Hobbies has discount pricing available for large education-based orders.
The Plantraco Desktop Rover is a neat tank-like vehicle available directly from Plantraco.

The Motorboard is slightly more complicated. Currently, this is not sold as a completed part although we are working on getting
somebody to do this. Instead, we offer the bill of materials (parts available from Digikey),
schematics, and layout files on the Hardware page. We have our boards manufactured in prototype quantities (up to 60)
from Advanced Circuits -- you just need to fill out a quote request and upload the ZIP file included on
the Hardware page. If you are too lazy to assemble the boards yourself (like me), I've used Valley Tech, formerly Phonic
Electronics, at 408-577-1218 for low quantity, reasonably priced assembly jobs. They'll send the boards back to you ready to go.

TinyOS is an "operating system" originally designed for large-scale sensor networks. We have co-opted it to use in robotics because of its event-driven
and hierarchical design. TinyOS is also completely open-source which makes things easy to play around with and a lot of code is already available to
do things like networking, data aggregation, security, etc. The programming language is a C variant which makes it easy to use. You can read a lot more about
it at http://www.tinyos.net or
download all of the code and start playing around directly from the TinyOS CVS on Sourceforge. However,
I recommend downloading the latest release which will include absolutely everything (code, tools, etc) that you need from the
TinyOS Download Page.

Make sure you have a programming board from Crossbow Technology Inc.. I recommend the Mica2 programming board because that
handles the most types of motes and is easiest to debug from. Once you have this, go through the TinyOS tutorial at
http://www.tinyos.net/tinyos-1.x/doc/tutorial/index.html. Lesson 1 goes through a very simple application that blinks one of the LEDs and shows how to program the Mica
mote. To program the motorboard, see the next question.

Plug the motorboard into the same programming board that you use for the Mica motes and make sure it has power.

Go to the contrib/cotsbots/apps/MotorboardTop directory -- this is the current top level application for the motorboard.

Type "make atmega8" at the prompt -- you are now compiling for the atmega8 platform (this is the processor on the motorboard).

Type "make atmega8 install" to install the code on the motorboard.

Once the motorboard is programmed in this fashion, there are a couple other things that you currently need to get the motorboard so that it communicates
with the mica mote. Currently, the two boards communicate using the UART, although I2C is also available. Unfortunately, both the current version of
the motorboard and the mica motes lack pull-up resistors (about 10k or so) required on the SDA and SCL lines for I2C to work. In addition, we are using the internal
RC oscillator on the atmega8 -- not a wise choice in hindsight. The internal oscillator requires a calibration constant to become accurate enough for
the UART to function properly -- this is done through loading a value in the on-chip EEPROM which is read on startup. At this time, you have to do this
by hand, but I'm working on an auto-calibration mechanism that can be loaded on the motorboard and do this for you. The calibration constant should be around
173, although this can change from chip to chip -- I haven't noticed changes more than +/- 2 on the atmega8's I've programmed.

First, make sure the fuse bits are programmed properly on the atmega8. This sets the clock speed and makes sure that the EEPROM is not erased when reprogramming
the mote (this is where we will store our calibration constants).

-dprog=dapa means tht you are programming over the parallel port and you should add a -dlpt=3 if using an IBM Thinkpad. The high
fuse byte command will assure that the EEPROM is preserved during reprogramming and the low byte sets the internal RC oscillator
to 2MHz. Reading the fuse bits afterwards allows you to check that things have changed.

Then to program the EEPROM directly in order to calibrate the clock,

uisp -dprog=dapa --terminal
ss eeprom
du 0
wr 0 0xad
du 0

This starts the uisp terminal program and switches to the EEPROM memory segment. The "wr 0 0xad" command is where you will set the calibration
constant because RealMain.nc reads the calibration constant from address 0. "du 0" at the end
allows you to view your changes.

You could also plug in the value you'd like into RealMain.nc directly, but as it changes from motorboard to motorboard, I though this was cleaner. Make
sure you take care in doing this otherwise, you could screw up your processor and you won't be able to talk to it.

This means that the code didn't verify for some reason. Ways to fix this include changing batteries on a mica mote, trying again, and making sure everything is
well pressed into the programmer and parallel cable.

So far, only the sensors available on the Mica SensorBoard have been used. This board includes an ADXL202e accelerometer which we've used for obstacle avoidance
and played around with for its use in an inertial navigation system. We've looked at the magnetometer for
use as a compass but haven't gotten this working yet. Light sensors have been used for simple light-following behaivors, and the buzzer-microphone pair for a robot diffusion scheme. An ultrasound
board is now available that we could use for localization and distance measurements, but it is not yet in the Mica form factor (only Dot form factor). I've used this on static
sensor nodes though and it gives about 10cm accuracy with the current TinyOS code available. If you'd like to build your own sensorboards, the more the merrier. Just let the
rest of us see them so that we can use them too!

So far we've only gotten as far as some simple Braitenberg-type behaviors and some robot diffusion experiments. We'd like to run the CotsBots through a sensor network (and get feedback
from the sensor network) all towards a final goal of mapping and exploration. The real thing we're lacking right now is localization.