Chris Connors was kind enough to include my work from 2010 in his post about the Faire.
Pololu makes a controller (called the “Baby Orangutan”) very similar to the one I am building. It has an Arduino-compatable microcontroller, 1A motor driver, and user IO lines. It is also cheap. However, there are a few things my design has that theirs does not.
The ToyBrain motor driver is replaceable. If you accidentally short the output pins and destroy the chip with overcurrent, you can remove it from the socket and replace it. The motor driver of the Baby Orangutan is a fairly fine-pitch SMD package, and so is difficult for the average user to desolder and replace.
Connections to the ToyBrain are also a bit more convenient than those on the Baby Orangutan. The ToyBrain has headers designed for servos, and headers for sensors that carry power for those sensors. The Baby Orangutan breaks all the pins out as single pins, leaving the user to deal with power wiring.
The ToyBrain uses the serial port for programming with a $5 FTDI cable available from multiple vendors. This means that it integrates very easily with the Arduino development environment, and it can send serial data back to an attached computer. The Baby Orangutan uses a USB to ICSP adapter to program the chip. It has the ability to send data back to a computer via serial, but it would require a second cable.
This post isn’t intended to slam Pololu. They make useful products with incredibly high quality. I know this because I buy their stuff. The point isn’t that my device is better, it’s that it’s different, in ways that make it better for me.
The ToyBrain project has been on hold for a variety of reasons, mostly time and money. I finally have enough money to order the motor driver chips I wanted from Digikey. They are on back order, but should arrive near the end of the month. Once I have those, I’m going to put together a little video of the first boards doing a variety of motor driving tasks. That video will go into a Kickstarter funding round to get the second edition of the boards produced and populated.
At least one of the ToyBrain boards is going to end up hooked to a computer via the serial port at one end, and a vibrating motor at the other end. I’m reviving an old project to add a teledildonics plugin to Pidgin. It will allow a remote user to use commands like /harder and /faster (and of course /softer and /slower) to control the speed of the vibrator. That one may not make it into the Kickstarter video.
I found an interesting post about laser power ratings recently. It covers the relationship between PWM and laser output power, which is going to be useful for the power supply that I’m building for my laser. Once I build that power supply, I’ll be in the rather interesting position of having designed a cutting laser power supply that can be built from easy-to-obtain materials. Hopefully, that will knock the price down enough that more people can do DIY CNC laser builds. I may also make that PCB available as a kit, so people can build their own.
I also looked up TEA Laser plans again, and started wondering about making a dye laser. The TEA laser emits in the UV range. so it could be used to pump a UV-reactive dye. Vitamin b12 (in energy shot drinks) and tonic water both are UV reactive, so it may be possible to make a yellow or blue laser using a dye that is drinkable. Normally, laser dye is a toxic dye in a toxic solvent, so this would be pretty neat for the home experimenter.
Version one of the ToyBrain boards had a bunch of problems:
- TX and RX were swapped on the serial line header
- The ICSP header was backwards
- There was no debug LED
- The SMD resistor pads for the reset pull-up resistor were too small
- The connection for the reset switch was a 0.1″ header rather than a proper footprint
- There was a lot of wasted space
Despite all of that, I managed to eventually get them working, with a slowed-down version of the Arduino bootloader, adapters for the ICSP and serial headers, and much messing about.
The new board is smaller, measuring about 1.5″ by 1.28″, and adds a proper reset switch, a SMD LED for debugging, corrected resistor footprints, and a (in my opinion) slicker layout. I still didn’t add voltage regulation or mounting holes, but I may be able to get a little space for the holes by moving a few traces in the corners of the board.
My ToyBrain boards are programmable over ICSP, but when I connect them to an FTDI USB-to-serial cable, I can’t load a program into them from the Arduino development environment. The error I get back is that the programmer is not responding, which could be caused by several things, listed here by increasing order of how tedious they are to check:
- I might have some misconfiguration on the USB ports or Arduino IDE. I can eliminate this possibility by using the same FTDI cable to program a known-working Arduino BBB. If that works, I know that my problem is off the end of the FTDI cable, in my own hardware.
- I tried this, and got a working blinking light program on my BBB. This means my cable and computer are fine.
- I might have messed up the bootloader configuration for my board. I think this is somewhat likely, as I’m using the Arduino bootloader on a board that is running at 8MHz. If the Arduino bootloader or IDE requires the Arduino 16MHz crystal for proper timing, it is now running at half the normal clock speed, resulting in the serial timings being double what they should be. I can test this by telling the IDE to attempt to talk to the board at half of whatever the normal speed is, using the platform support in recent Arduino IDE releases. If it’s a timing issue, that should fix it.
- This was the problem. I reflashed with the 8Mhz bootloader from here, and now I can load programs and have them run.
- I might have screwed something up in the reset or power circuitry of the Arduino (I already know I got TX and RX backwards). I can check out the connections with a voltmeter pretty easily. I can also burn an LED blink program to the board with ICSP and see if it runs.
- The power and reset circuitry is fine. I burned a LED blinking test program to the board using the command avrdude -c usbtiny -p m8 -U flash:w:test.hex and got a square wave on port B, so the chip is running code and the fuses make at least enough sense that the onboard oscillator starts.
- I may have used bad fuse settings, and put it in some mode that doesn’t result in the bootloader starting. I can test this by burning my own LED blink program to the bootloader section and seeing if it blinks an LED. This won’t make it load code, but it will at least confirm that the bootloader is getting started.
- This is covered by the previous section. The chip isn’t bricked, and it runs code.
There have been two things that I have done several times over the last couple of years. The first one is having a bit of code control an inductive load of about an amp, be it a DC motor, stepper motor, or solenoid. My ToyBrain boards are a general solution to that problem, so I can just drop one in and write the code, instead of reinventing the wheel (or at least the controller for the wheel).
The other problem that I end up solving a lot is having a microcontroller drive an RGB led to make color fades and washes. This shows up in different forms in a bunch of my projects, and is not hard to do. However, I keep doing it, so I might as well have a PCB to make it easy. My goal is to have something that can drive up to about 30A, for three channels, with PWM. I usually use an ATTiny85 for this, along with current-regulated MOSFET drivers operating as current sinks. That actually leaves me with two pins left over for other purposes, so I’ll have some GPIO lines on the board as well.
The point of having general solutions like this is that it saves me from doing the boring parts of a job and lets me get directly to the interesting parts. These sort of programmable widgets are becoming so cheap and simple that they are effectively the dust that real things are made of. There is actually a term for this process: Ephemeralization. AM and FM radios are effectively ephemeral at this point. You can buy a single IC that does everything needed to receive AM/FM audio signals, or get the radios pre-made in units of a great gross from somewhere in China for pennies each. The case it is in no longer needs to look “like a radio” (whatever that means) because the parts are so small and flexible that you can put any sort of case around them and have a radio. Cameras (of a certain quality level, at least) have pretty much gone that way, cell phones and computers are going next.
What kind of world do you get when everything has a computer in it because it was cheaper and easier to build the thing around a general-purpose computing device instead of designing a single-use custom solution?
The ToyBrain boards arrived. I have populated four of them with programming headers and microcontrollers. Two have ATMega8 chips, the other two have ATMega48 chips that I salvaged from some thermostats that I found.
I haven’t bothered fully populating the boards because I want to check that the ICSP headers are working by burning the Arduino bootloader to the chips, and that the serial headers are working by loading a program from the Arduino IDE.
Assuming that I haven’t miss-designed the circuit boards or baked the chips while soldering them, this will provide a smoke-test for the computer side of the boards. I still need to get a bunch of SN754410NE quad half-H-Bridge motor driver chips to handle the output side.
So far, I’ve come up with quite a few applications for the little boards:
- Re-animating gutted toys with new programming
- Controlling a single stepper motor with step/direction signals and limit switches
- Driving up to 4 channels of medium-current LED lights (RGB plus white?)
- Making loud noises by using the quad half H-bridges as push-pull speaker drivers
- Solenoid drivers and control hardware for chimes
I’m very eager to get a few of the boards out to beta testers and see what other people come up with.
I have a bunch of old toy skeletons sitting around. They are not toy versions of the bones of animals, but the frameworks and some of the motors from things like a toy tracked robot, an RC truck, a few toy robot insects, some tiny RC cars, a robot base with continuous-rotation servos, and so forth. All of these things have motors or servos in them. All of them need some form of controller to make them into autonomous robots to do my bidding (or wander around banging into things).
To that end, I’ve developed a little embeddable controller around the ATMega8, ATMega48/88/168, and other pin-compatible microcontrollers. That is the same chip used in the Arduino, so my board will be software-compatible with the Arduino as well.
My controller, which I’m calling ToyBrain, has a pair of 1A (stackable for more current) H-Bridge motor drivers, so it can control up to four motors in one direction, two motors bidirectionally, or one stepper motor. It also provides two headers for servo motors. For inputs, it has four analog or digital inputs and two digital inputs that are connected to interrupt lines, so it can do things like handle bumper switches in an interrupt service routine.
I’ve ordered 10 boards. When they arrive, I’m going to populate them with whatever chips I have around and try to get a few of my old toys running. Assuming everything goes well and I get a polished device together over the winter, this may end up being something I sell at the MIT flea regularly. I’ll hook up a bunch of toys with the same controller, to show off its versatility, and offer the controller as a kit people can buy.