Another light seeker, but it has telemetry!

The light seeker concept is for robotics much like blinking an LED with a microcontroller, or printing Hello, world! in programming.
Not one to go the easy way, I decided to use a single light sensor and have the vehicle remember how much light there was so it would know if it was managing to make improvements.

It works decently now, and I discovered that moderndevice has $10 3axis accelerometers and $7 radios, naturally I had to have them! I bought a RBBB to go along with the BBB I already have, as well.

I put the accelerometer and a radio on the vehicle with the RBBB, set up the other radio on my BBB to act as a receiver/base station and report back to the computer what the vehicle was up to. The radios want <3.8v (though people have run them on 5v), so I build the RBBB with a 3.3v reg, and swapped a 3.3v reg into the BBB as well. Both are running at 16mhz without issues.

Next up came learning how to make things in Processing, I eventually managed to take a simple sketch I found online to make a input graph that used a bazillion vertical lines and made it into a more classically lined graph for all four sensor inputs (light, x, y, z).

First up, pictures!

The truck, it’s a $10 thing that has two H bridges, one for the motor on the rear wheels, and another for a motor that slams the front wheels around (no progressive steering here, it’s all or nothing). I soldered old IDE/PATA ribbon cable to the four H bridge inputs and plugged 'em in to the arduino. So far I’m just doing forward/reverse, no steering. The truck tends to spin it’s wheels and rotate a bit in reverse, so it’s not a one dimensional kind of thing. Hitting stuff changes it’s direction too ;D

The base station. Pretty simple, it’s a BBB with a radio receiver and a USB-BUB. The USB-BUB has a second connector wired to the 3.3v output of the FTDI chip, it also lacks the DTR as I was getting tired of having the arduino reset every time I opened a serial monitor (the diagnostics from the radio on the reset confused the hell out of the Processing sketch, too)
Ignore the five extra jumpers, they are from testing the accelerometer on that board. I forgot to remove them.

Last, a picture of the Processing sketch output, white is light, green is X (front/back), red is Y (side/side), purple is Z (up/down, as you may have guessed)

Lastly, the code:

The vehicle itself. (This code is all mine, as it states you’re welcome to use it)

The receiver (note, this is my brutalization of the demo/configuration sketch from Jeelabs)

The processing sketch (note, this is my brutalization of someone else’s code as well, his message at the start of the code is intact)

The receiver code desperately needs to be trimmed down, I haven’t gotten around to it yet.

The Processing sketch does some smoothing on the x/y/z now that it didn’t do when I took the screenshot, it’s much nicer now.

Looks good!

So what's next, digital compass? Then if you can stop hitting things or spinning wheels, you could get a 2D plot of where it's been.

I was wondering about that, I'd love to do such a thing but I'm going to need to learn a bunch more of the programming aspect first, and filter the accelerometers some more

When you come to filtering the accelerometer values, you could do this on the Arduino or the server, you just need a low pass filter. That looks a bit like this:

// Adjust alpha for the level of smoothing.

#define alpha 0.8

void loop()
static double lastX = 0;
double newX = readAccelerometerX();
double smoothX = alpha * lastX + (1 - alpha) * newX;
lastX = newX;
// ditto for the other 2 axes

I would tell you that the algorithm is called lossy integration, but I've been told that's pretentious ;)

Anyway, its nice and easy to code.

Wonderful, thank you! I'll implement that today.

Did you make your own arduino ?

Soldered 'em together, but they come as a kit from ModernDevice. The one on the car is a Really Bare Bones Board (RBBB), the one in the receiver is a Bare Bones Board (BBB).