Lego Mindstorms and Processing
The Lego Mindstorms platform is a great way to learn some basics of computer programming, robotics, and mechanical engineering principles. Frankly, it is also a great opportunity to re-discover the love of building with plastic bricks – as I did with the Color Sorter I wrote about several months ago. There are a wide variety of models available to build, particularly if you poke around the Mindstorms website or pick up a book like The Unofficial Lego Mindstorms Inventor’s Guide (by David J. Perdue and Laurens Valk).
The biggest drawback I have found is that the programming environment – which is based on LabView. The on-board memory for the NXT brick is relatively limited, and the process of programming by dragging blocks around the screen is less intuitive (for me, anyway) than more text-based languages. This is especially true for branching and subroutines.
In saying this I should explain that I’ve programmed in a number of different languages over the years, from Pascal and Logo to VBscript, ColdFusion, and PHP. Almost every one of them has been text-based. While I have come across some parametric 3d modeling applications (Grasshopper, Generative Components and Houdini) that are more visual in nature, the bulk of what I know (and the most powerful by many standards) are based in text. I don’t mean to say that no one can program using a visual metaphor, but it is not where most of my experience lies.
Thankfully, many people have found a way to bridge these worlds, and I have managed to trace their steps. Processing is an open source programming language with a number of contributed libraries – one of which, written by Jorge Cardoso, allows for communication with NXT bricks via Bluetooth.
After kicking around with some example sketches (particularly one from Diego Baca), I was able to piece together a remote control program for the Jeep model described in chapter 14 of Perdue and Valk’s book. This exercise was really helpful, giving me an opportunity to program in a more familiar mode while still getting more experience with Mindstorms. The increased experience with Processing is an added benefit.
Details of the Mindstorms Remote Control
The sketch works fairly simply, by reading the mouse position over the control diagram. The mouse’s horizontal position determines the degree to which the Jeep steers left or right, while its vertical position controls the speed of travel. The drive motors only engage when the mouse button is clicked, so the jeep brakes as soon as you lift your finger.
The design provided by Perdue and Valk includes an ultrasonic sensor already, so it was relatively simple to add a safety function to stop forward motion when the jeep detects an object within a specified range. To complement that, I added a rear fender that hangs in front of two touch sensors in order to prevent collisions from the rear.
One final modification was necessary, to the steering mechanism. In testing I realized that the provided design had two factors that made building my own control program more difficult:
1) I don’t have the degree of control necessary over the motor’s starts and stops to prevent the jeep from over-correcting as it steers.
2) The jeep’s steering mechanism only allows for about 120 degrees of motion; beyond that you risk damage to the motor some other component.
Combine those two problems, and it quickly becomes clear that something needs to change – so I added a larger gear to step down the steering process. This both provides greater precision in steering and gives a larger range of available motion – with the added benefit of increasing the torque of the steering assembly (a good thing when you’re driving on carpet).
You can see the whole thing in action (with a slightly earlier version of the control program, before I cleaned up the interface) below:
I have since disassembled the modified jeep in favor of the next model in the book, the walking lizard. This I’ve programmed as directed, using the diagrams supplied by Perdue and Valk. It was a good learning exercise, particularly the process of creating a “My Block” – which seems to be a good stand-in for subroutines. Like any project, the lizard also offers opportunities for modification. I will have to cover these in a separate post, once I’ve had more opportunity to experiment a bit.
Another direction I need to take is to understand better the way that the NXTcomm library works (or doesn’t). It appears that the NXT programming environment can achieve a greater level of control than I’ve been able to achieve via Processing – particularly when it comes to distance of travel. This isn’t so important on a remote control car, but some of my ideas for future projects will require positional accuracy far beyond what I’ve been able to achieve thus far.