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.

The RobOrchestra Snarebot is finding its legs..err arms this year. The project is a few years old and has experienced incremental improvements over its lifetime. This time around we are looking to make a dramatic improvement based on the existing design and input from drumming consultants. We want to make it as realistic at drumming as possible with good dynamics and a pleasing sound.

The old design used two large solenoids pulling on cables to actuate the drum sticks. The wires were connected to specialized rubber holders that had built in compliance to allow the sticks to rebound quickly off the drum surface. These work really well and were one of the biggest components in the success of snarebot 1. What the 'bot lacked was good control over speed and dynamics - since solenoids are either "on" or "off", that's all you could coax out of it. Since there was a single pivot point, it was also impossible to induce different velocities out of the drum strike.

This is the design I envisioned last year - a small, portable device that could fit on any standard size drum. It was actually really neat, and I built a small prototype for the shell and legs. When you rotated the center handle the legs would extend or contract depending on the direction you turned. Since there wouldn't be much force opposing the legs (all downward) they would remain extended and the 'bot would perch happily on the edge of the drum.

This worked pretty well, but only left about an 8 diameter area in which to fit the drum stick mechanism. We found out that short sticks sound really flat since you couldn't get the pleasing resonance you normally hear from a snare drum. The device made had about 4" arm and could hit every 25ms, so speed wasn't an issue.

My sketch for this years' redesign is above. Its larger offset design allows for greater movement and the use of standard drum sticks, so we avoid the resonance issues of the past design. It will incorporate cable drives, solenoids, and servo motors to provide a wide range of speed and dynamics control lacking in Snarebot 1. The drawing isn't exactly to scale as the drum sticks actually stretch across the diameter of the drum, but after taking some measurements I verified the design is doable. Now it's just a matter of finding time to sit down and CAD model it in SolidWorks.

Some people have expressed concerns about latching onto the tuning bolts, but others say we should be fine. I've designed the 'bot this way so that we can eliminate the large clunky stand. It worked out pretty well for Snarebot 1, since you could easily reposition it, but we have something up our sleeves for this design that can accomplish the same thing.

You can't see it from this drawing, but the base will incorporate motorized translation and rotation so the snarebot can target different areas of the drum. Now, we're starting to talk about a lot of motors here, but each RobOrchestra controller board has ~16 outputs, so we should be fine. Hmmm....how about some neon underlighting?