Museum Exhibits Preparation

I'm preparing a robotics exhibit for a local museum that is opening up soon. To that end, I learned how to weld just now (I'm not very good yet. Also now I'll smell like welding all day).

The exhibit is simple--drive a small remote controlled car around a map of the city, from a monitor that tracks the car and displays a birds-eye view camera image, auto-rotated to the car.

The biggest hurdles:

• Light weight and high capacity battery (but low max discharge rate--which is fine, I don't need a high discharge rate)
• Sleep mode for the wireless radio and microcontroller to conserve battery when nobody is using the exhibit (chose the Wixel here, for reasons I'll cover in another post)
• Safety against, stall, over-current, under-voltage, and other battery damaging conditions
• Making sure the parts the user touches (console, perimeter wall) stand up to the forces users will likely put on these

To adjust thresholds for my wake-up circuit, I finally installed drivers for the portable oscilloscope I have: http://www.gabotronics.com/development-boards/xmega-xprotolab.htm

First impressions: Quick-start was very easy. Installed drivers and software on Windows to get this screenshot, but you don't need to, as the scope has a tiny display.

In the image above I am bringing a flashlight closer and farther from the sensor. The green shows the phototransistor circuit output directly. The red is the output of the comparator circuit (LM358N, CNY70 if you want the parts. Just what I keep in stock, not chosen for any other reason. Don't turn on the CNY70 LED for this application, durr).

I was able to get it to robustly sense when I walked under the fluorescent light fixtures in this building, holding it at chest height.

More on this later.

EDIT: One more fun image.

My fluorescent bulb desk lamp apparently pulses on/off with a cycle taking 7ms or so. The other pattern (where the waveform is getting "pinched" and then expanded) is aliasing from the slow sampling frequency of the oscilloscope (or at least the points drawn in the software) at this large time scale and the 7ms lamp pulse.

MOARbots update

MOARbots is now on github: https://github.com/MOARbots/

Here's a video of one of the waypoint navigation routines that have come out of the UW independent study.

What's next? Yet another revision to the parts list. The new MOARbots will be based around the Teensy and the ESP8266. Using the ESP8266 by itself (with something like this board) is still on the table but will have to wait a bit. Using the Teensy has the advantage of being able to make them into Teensyduinos. The Arduino programming language/environment is easy to use compared to writing in C. And, if I'm willing to wait a bit, the hobbyist community will develop the tools I need for the ESP8266. Take a look at this project, for example: https://github.com/nodemcu/nodemcu-firmware/

One of the most important things that has happened to MOARbots recently is the expansion of the team of volunteers working on it. Thanks to the Sector 67 community and the University of Wisconsin community, MOARbots is now more than just my own personal project.

Lastly, here's a teaser of one more cool direction MOARbots might take:

This $50 quadcopter...
http://www.amazon.com/Hero-RC-Matrix-Quadcopter-Battery/dp/9269802574

...plus this $40 3-axis gyroscope, 3-axis accelerometer, and on-board processor...
https://www.sparkfun.com/products/11028

...plus this github project to help free that device from the small-mindedness of the company that made it and then decided to make their code closed-source...
https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050

...plus April Tags and MOARbots.

A swarm of Wi-Fi connected autonomous self-stabilizing quadcopter at under $150 per quadcopter? I'm hoping it's possible, anyway!

Robot Cart Progress -- It Drives!

First assembled prototype. Preliminary tests show that (a) it is capable of driving smoothly and (b) it doesn't draw too much current for the L298 motor driver. Spent yesterday evening hunting down flyback diodes at Sector and I even found two additional L298s, as well as a handful of extra large breadboard-compatible tactile switches (pictured left, in the background).

The Wixel code for the transmitter is done. Next up is integrating the PWM code to the receiver modules, and creating easy to use skeleton code for competition participants to come in and edit.

I still need to get additional batteries, a suitable USB camera with a good wide angle of view and OpenCV compatible drivers, and a few other parts. So far so good though.

Edit: Minor Setbacks
I bought these batteries from Adafruit and these batteries from Sparkfun. The Sparkfun batteries provide enough current to get the cart moving, but if it hits any obstacle and stalls, this triggers the overcurrent protection. Toggling the power on and off resets this protection. The Adafruit batteries can't even run the motors unloaded (wheels not in contact with the ground). They twitch, then die out (presumably, overcurrent protection). This is a shame, because I purchased them on the assumption that they would provide a maximum continuous 2C discharge rate, which they aren't, as far as I can tell. The datasheet seems to say that (bad formatting on it makes it hard to read).

In any case, Sparkfun's comment system and tendency to better document products on the page makes me feel a lot better about purchasing from them when they have the stock I want. Unfortunately neither battery will quite do for my needs, so I need to go back and rethink this.

Also, I wasn't able for whatever reason to get the wixel-pwm library by dpark83 working for me. It isn't particularly well commented which makes it difficult to use. I did find this simpler code, which works well enough for me to use instead.

Since the price for these robots is already quite high, I'm going to try and re-use some parts around Sector. Namely, a bin of old cheap lithium ion batteries without any protection circuits, and a bunch of scrapped prototypes for a battery board that has no documentation, but a ton of features (presumably). Or, in the interest of time, skip the reverse-engineering on the battery boards, and just triple check to make my circuits don't look too explode-y, and go protection-less. So far I haven't made any really serious mistakes with my wiring prototypes...