Bot Build night Aug 9

We’ve been getting together every other Monday night at the silo to work on group projects, but really what we want to see is more robots being built, be it by individuals or groups.  So even if you’re not interested in the current swarm robot project, feel free to bring your own robot-to-be on down to share in the excitement of mashing together mechanical bits, hard bits, and soft bits to do cool stuff.

And if you DO have brushbots, bring them down and let’s get them talking!

7pm, bRainSilo:

Hope to see you there!


Project meeting July 12

Last time Scott and I got four or five BrushBots running around in an arena with comm boards attached — one configured as a transmitter and the others as receivers. We only had simple RX and TX code running, but the receivers were picking up messages quite frequently; much better than we were expecting, actually.
But just five bots isn’t too exciting. It’s time to get a bigger swarm together and develop better message passing code! Bring your brushbots, bring your comm boards and let’s swarm!

While Scott and I hearded bots around, Tim got his steering control of the brushbots (a homemade toothbrush-head based bot in his case) working. The really cool thing is that he’s only using a single vibrating motor, yet still getting steerability! Come on Tim… Hurry up and upload the details on how you’re doing this!

Hope to see you all tonight,

7pm, bRainSilo:


Project Meeting June 14

The next group project meeting is Monday evening — same time, same place:
6/14, 7pm bRrainSilo

How many people want to build up some BrushBotComm boards using the Tiny84 at the meeting?  (Tiny44’s are still out of stock)
If there’s enough interest, we’ll do it — please reply on the mailing list, or below, with the number of Tiny84 based boards you want to build.

For those with a board already, let’s start working on the Rx/Tx protocol now that we have the IR working, and figure out the best way to strap these boards onto the BrushBots!

See you all Monday!


No project meeting Monday 5/31

No project meeting this Monday 5/31 as it’s a holiday.  But don’t let that stop you from dedicating your three day weekend to concocting the best IR communication protocol the Portland area has ever seen!  Or just kick back and enjoy some nice BBQ weather.  Whichever.

It would be cool to hear about any progress with the latest (ver0.3) IR Tx/Rx code that was released a couple weeks ago though.  Anybody try it yet?

Next project meeting: June 14.


PARTS Indoor Challenge and mouse sensors

After this morning’s PARTS meeting and Indoor Challenge, a few of us were talking about using optical mouse sensors for tracking robot position rather than wheel-based encoders.  Optical mouse sensors use optical-flow techniques to determine X & Y motion based on differences between successive snapshots of the underlying surface texture.  These sensors contain very-low resolution (18×18) cameras and all the necessary DSP to distill the information down to a delta-X and a delta-Y value.  It’s possible to read the raw image data out as well.

I’ve been wanting to play around with optical mouse sensors for a while, and the PARTS Indoor Challenge seemed like a good target application, so I threw some Avago ADNS-2620 sensors into the last DorkBot group order.  Unfortunately I didn’t have time this last week to do anything with them.  I figured I would need two sensors to track X, Y, and rotation since the mouse sensor doesn’t do rotation.  This certainly isn’t a new idea — mouse sensors have been used for robotics for quite a while, but I hadn’t done much research on it until now.  Here are some good links:

Precise Dead-Reckoning for Mobile Robots Using Multiple Optical Mouse Sensors (PDF)
Evaluates accuracy of two vs four mouse sensors compared to encoder-based dead reckoning.
Two sensors are significantly better than encoder-based DR if the robot speed is less than the max rate of the mouse sensors; four sensors are even bettter.
Four sensors are still significantly better than encoder-based DR even when the robot speed is greater than the max rate of the mouse sensors.
Testing was done on a felt surface, however, so the variability of the floor we’ve been running the PARTS Indoor Challenge on may require more than two sensors for robust positioning, even at slower speeds.

Cody’s Robot Optical Motion Sensor #1 (CROMS-1)
Nice writeup on hacking an optical mouse sensor, including creating a custom lens assembly for increased range.

Implementation Of An On-Chip Insect-Inspired Optic Flow Based  Navigation Sensor
NASA Tech Brief referenced by Cody’s above writeup.  Using optical mouse sensors with custom lens assemblies for flying robots (at low altitudes).  Overviews the optical design methodology and presents data from actual flight testing.  Concludes that optical mouse sensors are usable for terrain-following behavior on a robotic-flier.  Free registration is required to access the report.

Required components for optical mouse sensor (if you want to start from scratch rather than hack a mouse):
(These aren’t necessarily the best mouse sensor for robot navigation, but they are readily available.)

Avago ADNS-2620 optical mouse sensor
Data Sheet
Purchase:  Mouser 630-ADNS-2620 ($1.58, qty 1)

Avago HDNS-2100-001 lens
Data Sheet
Purchase: Mouser 630-HDNS-2100-001 ($0.18, qty 1)

Avago HDNS-2200 LED alignment clip
Data Sheet
Purchase: Mouser 630-HDNS-2200 (Non-stocked/Not available in small quantities! Grrr.  I think I can do without it.)

Avago HLMP-ED80-K0T0 LED
Data Sheet
Purchase: Mouser 630-HLMP-ED80-K0T00 ($0.39, qty 10)

More to come!


BrushBotComm board build follow-up Monday

Yes, there is another PARTS Project meeting tonight!

Time: Monday 4/5, 7:00pm
Location: bRainSilo:

We will be continuing with the BrushBotComm boards — soldering on the final components, including the missing IR LED resistors and the IR
LED’s themselves; making programming cables; and learning how to load code onto them.

As I mentioned in this blog entry the ArdunioISP should work well for a programmer, and hopefully as a serial link for debugging.  So, if you have a spare Arduino that you can use for a programmer, bring it.  Or, I have a handful of cosmetically defective (but fully functional) Teensy2.0’s available for really cheap.

*BrushBotComm boards and extra parts you’ve received.
*Soldering iron — if you have a decent one with a fine tip.  This is especially important this meeting as we have a fair amount of hand soldering to do.
*Desk lamp if you can — we didn’t really have enough light last time
*Vision enhancement devices — I’ll bring my stereo-microscope and what magnifiers I have, but I think we could have used more last time
*Money for Arduinos if you need one for programming.
*Laptop if you have one to use for programming.



New to the Portland area, therefore, new to the Parts group.

I’m currently working on a rather large robot that will use several microprocessors. I have just added AVR processors to the list of processors that I work with. Now to get them to all talk together. More later as I am sitting in the April meeting now…..

BrushBot Comm board IR communications

I’ve been doing some experiments with the IR transmitters and receivers used on the comm board.  One outstanding question is what the value of the series resistors (R1 and R2) for the transmitter should be.  We want the message passing distance to be fairly short in order to keep the communications mainly between pairs of bots.  But the IR power should still be sufficient to give reliable communications. Another question is whether or not the voltage from the batteries we are using will be sufficient for the IR receiver.

I made up the following test setup:  For the receiver side, I took one of the IR receivers that we are using on the comma boards and mounted it in a solderless breadboard to make it easy to try resistor values.  I also hooked up a variable power supply and used an ATMega328 LillyPad Arduino to drive the IR LED.  The LillyPad was the only thing I had handy which would run at 8MHz and low voltage.  The power supply was set to 2.75VDC which is pretty much as low as you can go with a 328 running at 8MHz and is around the voltage that the batteries can put out.  I used a test program from the IRremote library ( to repeatedly send out 0XD10 which is the Sony code for the ENTER key.

On the receiver side, I used a comm board hooked up to a variable power supply to test how the receiver coped with different voltages.   Monty had written a test program for the receiver side which recognizes Sony ENTER and blinks the LEDs in a particular pattern (although the key codes in irrx.h need to all be decremented by one to be correct).  With this program it is possible to move the comm board around and watch the LEDs to see where successful IR transmission occurs.

As a baseline test, I put in a 100 ohm resister into the IR transmitter circuit which gives about 20ma drive to the IR LED.  Using 5VDC for the receiver, the IR transmission works successfully at quite a long distance (probably across a room).

However, lowering the receiver voltage to 2.85VDC or below results in a failure of the IR receiver to work.  It still registers that an IR transmission is occurring but is unable to recognize the code.  Since the batteries put out more like 2.72VDC, this is a big problem.  After discussing it with Monty, we decided to short out R5, the resistor on the Vcc line into the IR receiver to try to get as much voltage into the receiver as possible.  Fortunately, this seems to work and allows the receiver to work down to 2.53VDC.  So I then hooked up the battery board to the comm board and (with R5 shorted) the receiver works.  The rest of the result below are all done with battery power for the receiver.

I then examined how changing the transmittter series resistor affected the range:

1K ohm            18 inches
4.7K ohm        5 inches
10K ohm         2.5 inches

These distances are for on-axis communications.  I’ll do some more experiments to see how the off-axis accuracy breaks down and update the table.