I had this idea about 5 years ago, from watching a kid assembling train tracks for a toy train.  I thought, what if the train could just “record” the tracks?  You put the train in record-mode, move it around a bit, then it plays that loop back over and over again.

Normally what you should do at this point is patent the idea then wait for someone else to come up with the idea and actually make it and then sue them for $millions.  This is the guiding principle of our entire patent system.  But I don’t have $10,000 lying around to get a patent, so I decided to just go ahead and try to make it myself.

How do you make a train that records it’s own tracks?  Basically, you need a motorized vehicle of some sort that knows where it is at any moment relative to where it started.  And that can record that position and play it back.  It also needs to be able to complete a loop – the person using the toy will probably never be able to create a perfect loop, so the toy needs to be able to correct the loop so that it can be played back over and over again.  None of that is very simple, but the part in italics is really the key.  How can a toy know where it is?  I came up with dozens of ideas, but eventually boiled it down to these:

• Use a mouse sensor (or something similar) to track distance and turning
• Count the rotations of each wheel on a car and use the differential to determine movement direction.

There are probably hundreds of other ways of recording position – from echo location to GPS to using a cheap video camera and complex digital analysis.  There are also a lot of ways of “cheating” – waypoints that the toy could move between, line-following robots, etc.  But I decided to stick to original idea and to approaches that I could actually prototype cheaply.

I’ve created two prototypes so far.  While neither of these look anything like a “train”, keep in mind it’s not that hard to put a train shell over a motorized toy. Each prototype represents hours of bread-boarding, soldering, coding, and testing.

Mouse-Bot

The basic ideas is this – when you move this monstrous franken-toy forward, the microcontroller receives y (as in vertical on an x-y axis) signals from the mouse.  When you turn the toy, it receives x signals.  Using a lot of trigonometry, it should always know where it is.  It actually works quite well. You can watch a video of it following a pre-programmed path here.

Here’s the problem, though.  If the mouse is not perfectly aligned and perfectly centered between the two wheels, crazy-complex calculations are required to compensate – and it’s nearly impossible to perfectly align and center the mouse. The calculations are too complex for the microcontroller to do on-the-fly, but without the calculations, the mouse-bot tends to always pull toward the left or the right (depending). Even the slightest misalignment leads to massive failure.

So I gave up on the mouse approach.

Zoomerang

Approach number two, keep track of the differential turning of two wheels.  With a great deal of tweaking, this approach mostly works.

As the video demonstrates, the main problem seems to be recording – it can fairly successfully play back the same loop every time.

I had a lot of trouble finding practical encoders to count the wheel turns, and there’s also a huge problem in that the motors are always “engaged”, so the wheels don’t want to turn during record mode. The system I use for counting wheel turns is ring magnets with alternating poles combined with Hall sensors.  I get 8 “pulses” per wheel turn which is not very precise.

There are a number of ways I could improve this design – much more precise encoders, adding a digital compass so that I know which way the toy is pointed (any extra data helps), some sort of method of disengaging the motors in record mode. But I’m starting to get the feeling that this dog won’t hunt.

Insert Coin To Continue

I’m going to shelve this project for a while.  If I pick it up again it will probably be to create a “waypoint” version.  It would work like this: put down two or more (solar-powered?) beacons and a toy will loop between them.  But for now I’m on to other projects…

Circuits and Such

Some notes on the circuit design(s) I used

• The microcontroller and sensors are powered by a 3.3V boost circuit – which doubles as a voltage regulator.  The motors are powered directly from the batteries.  Without the boost circuit, the sensors and even the microcontroller can get confused by voltage spikes and drops when the motors are turned on and off.
• I used a single MOSFET to drive each motor.  With this setup the vehicle can only drive forward.
• Also note that most MOSFETs have a rather high gate threshold, and some of them have a surprisingly high on-resistance.  When using MOSFETs to drive low voltage motors, look for low values for both of these attributes – i.e. gate threshold around 2V and on-resistance in the milliOhms or (even better) microOhms.
• For the mouse-bot version, I directly soldered connections to the mouse’s internal circuit board, rather than fool around with USB or PS/2 communication.