Since we last reported about The Great Internet Migratory Box of Electronic Junk, several of these boxes have begun circulating in different areas of the world. Team Hack-a-Day launched three themselves. Robots.net decided that there was a need for a specialized box just for those who hack robots, and have launched their own.

The box contains lots of things that will appeal to roboticists, such as servos, various sized motors, RC car parts, and even a small microcontroller board. Plus hackable items like old CD drives, a trackball, and miscellaneous electronic and hardware parts. Everything fits in a standard sized shipping box, but it is full. A complete list can be found on the robots.net site, and they also have pictures of the contents.

Those who wish to track the box can follow it under the name robots.net-box1 on the TGIMBOEJ wiki. There is also a place to get your name added to the list of potential recipients. The wiki contains information about the whole process, including how to start a new box.

The Dallas Personal Robotics Group held their semi-annual Roborama contest on Saturday November 22nd in Garland, TX. The DPRG had a table at the recent Austin Makers Faire. Each spring and fall, they hold the Roborama contests for autonomous robots. The spring event has contests for outdoor self-navigating robots. The 2008b contests were designed to test the abilities of indoor robots. Normally held at the Science Place, this year they elected to have the contests at the DPRG warehouse in Garland.

There were a wide variety of robots represented: lots of built-from-scratch projects, some lego-bots, and a few off-the-shelf models. Computing power ranged from nothing up to an on-board PC with WiFi. The Polulu 3pi‘s were heavily represented. The builders themselves were anything from high school students to veteran club members.

Winners had their choice of prizes in order of placement in each contest (first place got to pick first, etc). Prizes included a STM32circle, a pair of servos, or gift certificates to a local electronics store. Other entrants got a mini-cylon LED display to make their robot a little more menacing. You can view full results here.

The simplest event was the Quick-trip contest. This competition had the robots move from the starting area straight to a second area, and back again. The area is enclosed by walls and marked off with black tape, and the robot must completely cross the tape to be considered in an area. While it sounds very simple, not all robots were able to complete the course. The winners were determined by who successfully finished the course in the least time. This years winner of the Quick-trip contest was a lego-bot named Gort built by student Nathan Harlan.

The second event is a little more complex, called T-Time. This one has three areas, and tests the accuracy of turning. There are 3 areas, the robot starts in one, must visit the other two and return to the start area.  The course is a ‘T’ shape, so the robot must make a couple of turns. It was won by David Martineau with BoxyRoxy Mk IV.

The third event was a line-following competition. Robots must follow a white stripe on black background, with lots of sharp curves.  The course itself was only about a yard square, so smaller bots fit more easily. This year the line following was all about the Polulu 3pi’s. At least 4 entered, and all of them used the unmodified hardware: the only difference was the programming. One contestant used a genetic algorithm to evolve a neural-net. Another contestant programmed his on the day of the contest. The winner was PI R Squared, owned by Steve Rainwater.

The next Roborama will be sometime in the spring of 2009. DPRG holds montly club meetings. They also have the Robot Builders Night Out, which is a chance for roboticists to meet at the Garland warehouse and work on thier robots. It is open to anyone, not just club members.

Here’s the plot of one orb exploring a soccer field. Burning Man attendees will most likely see the whole SWARM in full autonomous operation.

If you haven’t heard about Arduino, you must be trying really hard to avoid it. Arduino is a package of hardware and software that allows easy programming and fast prototyping, lowering barrier to entry for microcontroller development both in terms of cost and learning curve.

There are two types of Arduino compatible boards. The “software” compatible boards do not have the exact same physical layout, but they can run the programs generated by the Arduino IDE. They also have a compatible bootloader on the AVR chip. Examples of this type of board are the Boarduino and the Arduino Mini.

The 100% compatible boards have the header pins in exactly the same position and order as the Arduino reference design. The reason that this is important is that there are Arduino “shields” which plug on top of an Arduino. Popular ones are the ProtoShield and the XBee shield. The Freeduino SB is the latter type, a 100% hardware and software compatible board.

So if it’s 100% compatible, why is it a Freeduino and not an Arduino? It’s a matter of licensing. While the Arduino software and designs are free (as in beer), the actual Arduino name is trademarked and requires permission to use. For some people that wasn’t free enough, so they created Freeduino under the Creative Commons license, which has zero intellectual property encumbrances – no copyright, trademarks, or restrictive licenses. That allowed Solarbotics to build a Freeduino and be sure that they weren’t infringing on anything.

The Freeduino comes as a “mini-kit”, which means that all the surface mount components are done, leaving just over a dozen through-hole parts to solder on. The instructions are humorous and well written, just right for someone who knows how to solder. The Freeduino was at least as easy to assemble as a Boarduino, and took less time. It’s possible to assemble the board in under an hour, even for someone out of practice with soldering skills. While the instructions and ads say that you can use either a regular USB jack or a mini-jack, the kit does not come with both. Instead there are two versions of the kit, so you have to decide before you buy which USB connector you want. Our kit came with a USB mini connector.

Here’s the assembled Freeduino (in red on the right) next to a (slightly damaged) Arduino NG. The PCBs are the same size and shape. Note the difference that the USB connector makes.

It turns out that the choice of USB connector can effect the compatibility of the Freeduino board. Because they shifted things around, the regular sized USB socket casing bumps into some Arduino shields, so they might not fit. As the manual says, “Our design pushes the USB-B connector up to make room for the switch, and it will interfere with some Shield boards.” The USB mini connector doesn’t have this issue, so if the right cable is handy, it’s a no-brainer which one to get. Many common cellphones and digital cameras to use this kind of connector.

Here are three USB cables: regular, mini, and micro. The middle one fits the USB mini connector on the Freeduino.

A nice feature of the Freeduino is that the ATmega chip comes pre-loaded with the “blinky” program (this is the “hello world” of the Arduino universe). Once assembled, powering up the board immediately runs the blinky program, showing right away that the board is operational.

While all Free/Arduino boards are compatible, it is possible to add features, as Solarbotics proves with this board. Generally, the Freeduino they put together is an improvement over the current generation Arduino Diecimila. Most users won’t really notice the better use of capacitors for circuit protection. They will notice the better placement of the indicator LEDs, which are closer to the edge of the board. The power switch is slightly misleading. It seems to sit between the voltage regulator and the ATmega chip. Even with the switch in the “off” position, a little power is still being used.

Those who use the Freeduino for real-time applications will appreciate the much more accurate 16 MHz crystal, which has about 1000x less error than some other designs. The PCB also has some room for customization, which will be useful for those trying to build compact projects. There is room to add a potentiometer (trim pot) that can set the analog reference voltage for the AD converter. Note that the kit does not come with this part. When working with non-TTL sensors the trimpot could save a few external parts. Solarbotics also left room to add a second, heftier voltage regulator, if needed. However, it’s not clear what the limits of the one on the board are.
The feature that they seem proudest of is the blue LED on pin 13.

Since the Freeduino has a more accurate crystal, we decided to see how it would perform as a clock. A binary clock is the easiest to implement because the display is just a row of identical LEDs. Each LED is wired to a pin through a resistor and hooked to common ground. The digital output of the controller can then turn the LED on and off. This calculator helps choose just the right resistor value, but there’s enough leeway for a resistor that’s pretty close. Note that the polarity of the LED is important.

A clock isn’t much use if you can’t set it, so this clock includes two switches. One switch selects which number to set, and the other switch is used to set the value. The switches are wired using a pull-down resistor. [Ladyada] has a long but thorough tutorial on using switches. The switches need to be debounced, but we took care of that in software. That’s about all there is to the hardware setup. Note that we used some of the analog pins as digital I/O. The chip supports this and the latest version of Arduino software does too. Be sure to use at least version 11 of the Arduino package or the buttons will not work.

The Arduino software environment runs as one big loop. Each time through the loop, our program does the following:

• See how many milliseconds have passed since the last time, and adjust the internal time accordingly.
• If a set of LEDs needs to be blinked, toggle their state.
• Check the state of the buttons; adjust time accordingly.
• Display the time in binary.

The count of milliseconds is kept for us by the Arduino library using a timer interrupt. It’s not quite as simple as it seems at first, because the Arduino milliseconds counter can roll over. So there’s extra code to detect and handle that condition. Then all we have to do is break it down into hours, minutes and seconds.

Handling the buttons turns out to be the trickiest part. First of all, we only want to act when the button is just released; not when it is up, held down, or just pressed. Second, the buttons have to be debounced. Debouncing is a whole separate subject which deserves an article of it’s own. We used a software debouncing trick that waits for an input to stabilize. For those who want to learn more, the definitive paper on the subject is here(PDF).

Displaying the time is actually the easiest part, since all we have to do is set the various pins according to the bits in the time variables. The entire program is available here(PDE). The Arduino IDE compiles and downloads it to the board with just a couple of clicks.

After downloading program, or resetting the board, the clock starts up right away and begins counting seconds. The display is three sets of LEDs showing binary numbers. The leftmost 5 show the hours in 24-hour (military) format. The middle six display the minutes, and the last set is for seconds. The clock can be set with the two buttons. Button 1 selects which part of the time to set: hours, minutes, or seconds. Pressing button 1 rotates through each part. The set of LEDs that are being set will flash briefly. Button 2 is used to actually change the value. For hours and minutes, button 2 will increment the value each time it is pressed. That does mean that it may have to be pushed up to 59 times to set the minutes. When setting the seconds, button 2 just resets them to 0. We thought this was easier to synchronize than trying to catch a moving number.

In order to prevent accidentally changing the time, the software implements a “safety.” If no button is pressed for about 3 seconds, then button 2 is disabled until button 1 is pressed again. Pressing button 1 when the safety is on will flash the set of LEDs currently selected and turn button 2 on again.

Just to see if the more accurate crystal makes a difference, we ran the exact same program on the Freeduino SB and then a Boarduino. The boards were set and compared using a radio controlled “atomic” clock as the reference time. Here’s a picture of the Boarduino running the binary clock:

The Boarduino did surprisingly poor job at keeping time. Without correction it gained over a minute per hour. The Boarduino uses a resonator that can have up to 0.5% drift. We had to apply a “fudge” factor of 0.85% to keep it from drifting noticably. Even then it tends to gain a few seconds over the course of a few hours. The Freeduino did much better; drifting only a couple of seconds during a five hour run. So the more accurate crystal does make a difference.

There’s lots of room for enhancements to this project. We used a prototyping breadboard with lots of jumper wires, but there are plenty of better ways to wire it up. It could even be implemented as a shield.

We hope that this how-to was useful as both a review of the Freeduino SB board and as an example of simple micro-controller input and output. Happy hacking.

Old computer mice are being abandoned in droves. They’re tossed out because of dirt, obsolescence, or for being entirely too beige. Anyone who has a computer usually has more than one mouse and you can get them for pennies, if not free just for asking. Fortunately for the discriminating (read: cheap) hacker, these little widgets are chock-full of project parts. Today’s How-To will dissect a computer mouse, extract the useful parts, and give some ideas about how to use them.

Here we have a standard PS2 mouse; a USB mouse will look pretty much the same. We’ll talk about optical mice later on.

Lets open it up. First, take out the mouse ball. Then there will be one or more screws on the bottom side that need to come out. Screws are sometimes hidden under the rubber pads.

The first thing to notice is the cable connector. Most mice have a very convenient plug for the cable, instead of soldering it onto the board. That’s the first usable part: a 4 (or 6) conductor cable with a nice plug on one end. The socket can be removed from the PCB and used in other projects.

With the cord out of the way, we can start pulling out parts. First thing that pops off is the mouse wheel. Yes, it’s just a big rubber wheel. If you’re annoyed by the mouse wheel’s clicking noise, you can silence it. There are at least two micro-switches and usually a third one under the mouse wheel which can be used for bump sensors or buttons.

Next thing to take out are the two plastic slotted discs. They’re the encoder wheels. They turn whenever the mouse moves and interrupt an IR beam, producing pulses. It used to be that precision encoder wheels were pretty expensive, but not anymore. Every single (non-optical) mouse comes with a pair built in.

On either side of the encoder wheel are some little boxes. One side is an IR emitter, and the other side is a pair of IR detectors. Sometimes the emitters and detectors will be one complete unit. A pair of detectors is used because with 2 detectors slightly offset, it generates quadrature encoding, so that mouse knows the direction of rotation.

These IR emitters and detectors are fairly modular pieces when it comes to hacking and can be removed with some careful desoldering. It is a good idea to use a multimeter to see what kind of voltage is going to them before removing them. They are probably TTL parts, because mice are powered by 5v, but sometimes they are an even lower voltage. The emitter/detector pair by itself can be interfaced directly. Those parts alone can be used for a proximity sensor or for a line following robot.

Add an encoder wheel and this sensor setup has lots of uses. From a tachometer, to a wind speed indicator, to sensing a robot’s speed, this will do it. The quadrature output (with some decoding) can be used to measure distance, direction, and speed.

One tricky thing about using the encoder with the IR sensor is getting the emitter to line up with the detector(s). No problem: instead of desoldering the parts from the PCB, use a rotary tool to cut off the little piece of PCB that has the sensors on it (already lined up). Wires can then be soldered to the pins/traces on the other side. If holding the encoder wheel in place is a problem, a hunk of the mouse casing can be used with it. Be sure to leave enough PCB to keep it stable on the mouse casing.

This is a picture of an encoder wheel with quadrature from a PS2 mouse on a small robot. Rather than make custom parts, the mouse is carved up and the whole assembly is fitted to the motor axis.

What’s left to salvage on the mouse? The sensors for the mouse wheel. Depending on the model, the mouse wheel movement may be sensed with switches or a low resolution encoder, suitable for measuring slow rotation.

The final bit is the mouse controller chip. At first thought it seems pretty useless: it’s a single purpose part made specifically to run a computer mouse and nothing else. However, if your controller chip isn’t an anonymous blob, the datasheet could be very enlightening. Octopart can help find datasheets based on the chip’s part number. This (PDF) is a typical datasheet for a mouse controller.

This specific part does a number of useful things:

• decodes the quadrature input from the encoders
• keeps a running count of the number of encoder pulses in a set of registers
• filters out jitter
• debounces the micro-switches and keeps track of their state
• packetizes the information and sends it up the cord.

For a PS2 mouse, getting at these features is not too difficult. The PS2 protocol is pretty friendly, even for microcontrollers. Here’s an example of interfacing a microcontroller with a mouse. For USB mice, check the controller’s datasheet to see if it can do both PS2 and USB; with older mice there’s a decent chance it does. While pure USB is not very easy to talk to with a microcontroller, it’s really easy to hook to a PC (with the right software).

We promised a look at optical mice. Optical mice do not have any rotary encoders. There are still some switches and a low-res encoder for the mouse wheel. What an optical mouse has in it is a mini-camera, lights, and lenses. The light is probably a fairly standard LED, although they tend to be bright, and the lenses are purpose built. However, it is possible to interface directly to the mini-camera or use it as a really poor scanner.

We hope this How-To has sparked some ideas and that your obsolete mouse won’t seem as useless anymore.

[McLurkin] was an entertaining speaker and had an interesting view of robotics. He is optimistic that robot parts will become more modular, so it will be easier to build them, and more importantly, faster to design them.

Some quotes:

• “There’s more sensors in a cockroach’s butt than any robot”
• “12 engineer years to design, 45 minutes to build”
• “If it can break your ankle, it’s a real [rc] car.”

His swarm (pictured above) is made up of over a hundred small identical bots, but he only brought about a dozen with him. The demo was still quite impressive. He had the robots spread out, clump together, play follow the leader and circle the wagons. Each behavior had a very simple rule behind it. To spread out, for example, each robot tries to move away from it’s nearest neighbor. The really fun part was when he had the robots perform a physical bubble sort. The rule for this was that each bot tried to put a higher-id bot on one side and a lower-id bot on the other. After a minute or so of bumping around the bots all lined up in id order.

I was interested in the details of the robot itself. Here’s a picture with the parts labeled.

Each robot has a unique ID number. They communicate with each other via IR and have sensors so that they can tell which direction and how far away the other bots are. The lights on top are just indicators so you can tell what the bots are doing. A mesh network is rebuilt several times a second, creating a directed graph from the ‘leader’ (which can be any arbitrary bot) that connects to each bot in the swarm. Any bot can act as a repeater, relaying instructions to bots that can’t talk to the leader directly.

Robot swarms are not a new idea: they’ve been floating around as concepts for many years. However, [McLurkin] was one of the first to actually build and program a large swarm (at one time he held the record for the largest robot swarm in the world). The idea caught on with researchers and today there’s even an open source robot swarm project. If you’re not up to building a whole bunch of robots, there are also simulators.

After the demo, we asked [McLurkin] about the cost of the robots. He said he didn’t know for sure, but estimated at least $2000 per bot. When we commented that “that’s a lot of money for 100 bots”, he pointed out that compared to the $20K+ that research robots can go for, it’s a bargain. He also said “This whole new world of hobby robotics just didn’t exist in the 90′s”. For robots to be deployed in swarms of hundreds or even thousands, in situations where they can get damaged or lost (search and rescue, military exercises) the cost will need to drop dramatically.

Here he is packing up his robot swarm. After the demo, we half expected them to pack themselves – no, they don’t.

For more info on robot swarms, their inspiration and possible uses take a look at [McLurkin]‘s web site.