Home | Support | Hardware | Software | Download | Media and Pubs | Related Work

FAQ

This is the beginning of a list of questions I've gotten in the past -- hopefully it will continue growing and becoming more detailed as new questions come in.

Where do I buy the pieces (Mica mote, motorboard, mobility platform, etc)?

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.

Do you sell complete kits or motorboards?

The short answer is no and see the above question to find out where to buy the pieces. However, if somebody is interested in making these for us, we'd be more than happy to help you out.

What is TinyOS?

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.

How do I program everything?

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.

How do I program the motorboard?

The simple answer is as follows --
  • 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).

		uisp -dprog=dapa --rd_fuses
		uisp -dprog=dapa --wr_fuse_h=0xd1
		uisp -dprog=dapa --wr_fuse_l=0xe2
		uisp -dprog=dapa --rd_fuses
-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.

What does a flash error mean?

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.

What sensors have been used on the CotsBots?

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!

What kind of things have you done with the CotsBots?

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.

Is there any kind of literature I can read?

I'm slowly finishing up my Masters thesis, but a paper published at IROS 2003 is in the Media section.