This project is currently on hold as we work on some other new research robots.

A very brief overview

Each robot will have:

• Ampro Encore PP1 (Motorola PPC 300mhz)
• Linux 2.4.x with preemption patches
• Via EPIA ME6000
• Linux 2.6.x
• Lots of RAM/storage
• Wireless ethernet (802.11b)
• Firewire
• Onboard status LCD/LEDs
• SONAR sensors (a bunch)
• Infrared sensors (a bunch)
• Bump sensors (a bunch)
• Camera (perhaps omnidirectional)
• Custom chassis (perhaps molded plastic)
• Outdoor-capable (anywhere a wheelchair can go)
• Battery life ~3 hours when moving 50% of the time
• Differential drive
• Up to about 1 m/s
• Remote control via PDA or any other computer
• Hybrid reactive/deliberative software architecture
• Lots of other stuff that I have forgotten...

Update 10/03: as of now, we have given up on the Ampro board in favor of the Via EPIA ME6000. Ampro did not provide us with satisfactory support, considering their board couldn't even handle booting from a hard drive (using their instructions to do so). In fact, their support staff seemed to have less of a clue about their own board than we did. Personally, I'm quite pleased with the Via board so far. All of our software was "ported" by changing one line:

#define ROBOT_BYTE_ORDER __LITTLE_ENDIAN

With this change, and the near-completion of our chassis and selection of a camera, we are nearly ready to start putting the final robot together.

Prototype integration test "1" (07/09/2003)

Here are some pictures from our first real "integration" test (integration between the microcontrollers in charge of the lowest-level stuff, like driving the motors, and the main computer/software). The chassis being used is completely temporary (as you can see, none of the hardware is even really fixed to it). The main computer (pictures 4 and 5) is still sitting on my desk, and is talking to the hardware via that serial tether. Pictures 2 and 3 show the PDA controlling the motors.

Movie:Driving around controlled by the PDA (mpeg4 divx, 2.7mb)

Software Feature-complete! (08/01/03)

We are done adding new features to our robot software (for now). Some of the things our software does:

• Controls the hardware on the robot by talking to low-level microcontrollers via a serial interface
• Performs motor control on the CPU using shared motor control libraries ("plug-ins") for easy swapping of motor controllers with no recompilation
• Provides a handy /dev/robot/... interface for higher-level access to the hardware (e.g. /dev/robot/sonar, /dev/robot/odom, etc.), implemented as a Linux kernel driver; also includes resource locking functionality for high-priority programs that require exclusive access to a hardware device (e.g. an "emergency-stop" program)
• Provides the "librobot" library for high-level control of the robot hardware and access to sensory information; this library is network transparent (so the same programs can be run on the robot itself or remotely via a network connection)
• Provides "netrobotd" for handling over-the-network librobot requests
• Implements a real-time simulator with the same network protocol as "netrobotd" so that librobot programs can run in simulation with no changes from the real-world version (not even recompilation!); simulates a 2d environment with reasonably accurate physics
• Provides configurable data logging of every type of sensor and control data available (including encoder/pwm counts, velocity requests, changes in odometry, etc.), and tools for viewing logged data; in addition, the simulator has the ability to "play back" log files
• Implements a "reactive" ("behavioral") layer; "behaviors" are implemented according to a predefined (but flexible) interface and can
  • be inhibited (paused) and uninhibited
  • receive input data from other behaviors or deliberative programs
  • send output data to any number of other behaviors
  • interact with hardware via librobot
  • load sub-behaviors, connect their inputs and outputs, etc. in order to create a subsumption-like interconnection of behaviors
  Behaviors in our system are simply processes that interact via standard IPC mechanisms
• Allows an operator to control the robot remotely using a PDA interface (on a Sharp Zaurus) and wireless ethernet

Of course, our software does lots more, but these are the most important functionalities it provides. You may be interested in the doxygen documentation generated from the source.

Some interesting code statistics (generated using David A. Wheeler's SLOCCount):

SLOC    Directory       SLOC-by-Language (Sorted)
3726    misc            cpp=3726
1931    pda             perl=1104,cpp=827
1560    librobot        ansic=1560
1026    arch            cpp=628,ansic=398
710     interp          ansic=710
621     include         ansic=621
347     scripts         sh=347
316     driver          ansic=316
169     mc              ansic=169
0       doc             (none)
0       top_dir         (none)

Totals grouped by language (dominant language first):
cpp:           5181 (49.79%)
ansic:         3774 (36.27%)
perl:          1104 (10.61%)
sh:             347 (3.33%)

Total Physical Source Lines of Code (SLOC)                = 10,406
Development Effort Estimate, Person-Years (Person-Months) = 2.34 (28.08)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.74 (8.88)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 3.16
Total Estimated Cost to Develop                           = $ 316,075
 (average salary = $56,286/year, overhead = 2.40).

We seem to have squeezed 28.08 person-months of development into just two! Hopefully there aren't 14 times more bugs!