Drivers are lazy and can cause accidents.

Adaptive cruise-control vehicles that follow a lead vehicle on the highway. The lead vehicle is driven by a professional and the rest of the cars follow the leader while their drivers "take their hands off the wheel, read a book or watch TV."

There are a few problems with this. Overlooking the fact that trains have existed for decades, so this isn't truly a new concept, there are serious control issues that need to be addressed.

How do you decide which vehicle is the lead? "Okay, so Bob is in front, and he's a truck, so I'll follow him. WOW! Bob is a terrible driver!" But I don't notice, because I'm sitting back, reading the morning newspaper.

Sure, you could have some smart software that decides Bob isn't going to get you to your destination safely, but if you're already going to have all that processing, why not just have full autonomy?

"Where am I?" Turns out Bob decided to take Exit 5, a few miles ahead of my actual destination. Since I wasn't really in control of my car, I lost time and fuel.

Perhaps there is some solution like pre-programming your route into GPS and letting the software take care of following its own path. But still, there's no guarantee that the driver hasn't fallen asleep when you need him to take back manual control.

The article cites a 20-40% efficiency gains from vehicles following closely, much like geese flying in a vee. What it fails to acknowlege is the fact that every member of this "platoon" has its own locomotion system. That efficiency calculation will probably tank when compared to a conventional train. There's also problems with wear and tear on each engine versus only needing to service a one or two engines, as in a train.

There are definitely some interesting challenges to solve here, so I agree the study is worthwhile. It just seems like the focus is wrong -- a solution searching for a problem. And a problem that already has a better solution.

Mass transit isn't everywhere, and trains only work well on special tracks. The ability to travel in a train configuration while still retaining independent destination control is appealing. Our road systems and vehicle technology, however, do not have the necessary infrastructure to safely allow drivers to tune out while rolling down the highway at 60mph.

We've seen some great results from the recent DARPA Urban Challenge that alludes to the possible future of fully autonomous vehicles. I don't see a hybrid solution (people + robot) working out any time soon.

UPDATE: The NavLab at Carnegie Mellon did demonstrations of this technology back in the 80's.

The Scout is a capable platform on its own, able to traverse rough terrain and avoid obstacles at high speeds. Even so, one of the main strengths of the Scout is its (rear) accessory interface.

Many research platforms were designed around a single purpose or only provide the ability for "expansion" cards in the form of networked printed circuit boards. Researchers working on the Scout platform won't be restricted to the current sensor/manipulation package, nor will they be constrained to fixed size add-on modules. The Scout provides power, data, and hardware attachment points to allow a variety of mechanical or sensor add ons. You can see the six threaded hard points in the rear of the vehicle, as well as a thrust bearing for pivoting accessories.

The accessory interface attempts to be as non-restrictive as possible while providing both basic and advanced functionality to the designer. To that end we've denoted two classes of accessories, those with "smarts" (onboard processor) and those without. Both classes of accessories must identify their type/function as matched against an accessory database stored on each robot. This allows the OS to configure communications between the ARM and AVR at the bandwidth necessary for desirable performance.

Dumb accessories are simple devices that only require power and access to an analog (input) or (2) digital I/O. This might be as simple as a wagon with a potentiometer for tracking position and a switch to indicate whether a load is present. Basic I/O pins are provided by the AVR.

A smart accessory has its own on-board microcontroller that handles all the low-level control. An I2C connection straight to the ARM9 processor is provided. Smart accessories can still access the AVR pins, although it should rarely be necessary. The forklift shown below is a "smart accessory" since it requires active control of the lift position and active monitoring of the RFID reader and loading.

My favorite accessory to date, the forklift gives the Scout 0" to 6"+ lift capacity. Pulling tasks off the server, robots will autonomously move packages around, pausing to recharge when necessary. Mobile robots are already in use in semi-automated distribution centers, such as Staples.

The mechanism uses a three stage lift actuated by a cable pulley system. The RFID reader sits behind the carriage. When closed, the forklift does not extend into the sonar's sensing cone, enabling use of rear ranging data. The charging contacts also had to remain exposed so the robots can dock for battery refueling.

Design to test cooperation between two or more robots, the dig and haul attachments provide an entertaining and challenging application of swarm robotics.

The designs both employ micro servos for actuation. Hauler also uses a load cell (force sensing resistor) to determine when the bucket is full and instruct the digger to halt loading.

Hauler could easily be implemented as a "dumb" accessory, but Digger requires it's own micro due the increased complexity of the control and positioning system.

Plans are in place to design a simple webcam interface, surveillance package, and a pan/tilt semi-automatic cannon. Have an idea of a sweet accessory? Add your concept to the comments below! I love hearing new ideas, no matter how radical.

Between classes, eating, and sometimes sleeping I've been hard at work refining the Colony Scout robot. The core feature set has remained the same -- four wheel drive, rocker pivot platform powered by a lithium ion pack. The sensor package includes a front bumper, dual sonar rangefinders, battery level monitoring, localization beacons, xbee communications, wheel encoders, yaw gyroscope, and three axis accelerometer.

Shown here in green (one of many colors), the Scout now sports a vented enclosure for the electronics. RGB (multicolor) LED "headlights" shine out the front hood, which is magnetically clasped for easy access to the processing board.

The team has been hard at work designing the Scout board, which runs an ARM9 core mated to an ATmega 128A as a coprocessor. The ARM9 does the heavy lifting but leaves the very important role of gathering sensor data and driving the motors to the lower powered AVR chip.

Board design is custom and includes components specific to the platform. We are looking into POE (power over ethernet), USB, and external charging to power the system.

Scout will run a Linux RTOS -- as yet to be decided. Linux brings a lot of functionality to the table but also has its own quirks that will be interesting during development and testing. We hope to have a first run dev board in testing by December.

Testing and validating the robot design only goes as far as production. The diagnostic station aids the maintenance process over the lifetime of the robot(s).

I went for a pipelined design whereby tests are separated spatially to allow faster throughput with multiple robots. This results in an elongated testing platform, but it still measures in under a yard...so far :-)

Assuming the robot can navigate to the station, it will ascend the ramp and proceed through the three stages. All tests and robot maneuvers are controlled by the Colony server, which handles scheduling and task assignments for all the robots.

The motors and encoders are tested across the speed range of the robot. A sequence of tests is also performed with loading on the dyno rollers. This simulates the robot driving across different terrains.

Between the two larger stations, the bridge tests the three cliff sensors through several cycles (see ladder-like design). This comes after the encoders/motors are calibrated for straight line driving. We don't want robots to go splat during a maintenance run!

The final and most complex station latches onto the robot and spins it for gyro testing. Accelerometer tests are also performed by spinning and tilting the robot. I'm still designing the internal mechanisms -- should be interesting.

Dyno Station Mock up (who doesn't love Legos(R)?)

I've also been working on the design and function of the charging station. So far it's pretty sweet with a low profile, modular design. I'll try to post some renders and details up soon!