Fun with LEGO Mindstorms Programming

rhempel wrote to us about an interesting LEGO Mindstorms programming tool he's created called pbForth. Click below to learn more about it - but let's talk about Mindstorms programming in general. What else is everyone using? What's the coolest thing you've done with them?

I've developed pbForth, a port of a rather archaic programming language, for the LEGO Mindstorms brick. The cool thing about it is that with a dumb terminal emulator that does ASCII uploads and can handle XMODEM (checksum) transfers, you can compile applications right on the brick! Yes, on the brick! When you are done, you blast S records back to your PC using XMODEM and then you can reload the app anytime using one of the standard firmware uploaders.

Check out pbForth for LEGO Mindstorms

pbForth got a whole chapter in the O'Reilly book, and it is getting more and more momentum as replacement firmware that busts the 32 variable barrier, and allows total cross-platform development without screwing around with building ecgs.

OK, I'm biased - I wrote it - but I think it's cool. Maybe some of you LEGO gearheads out there would like to try programming in something other than the native tongue. Learning Forth can make you a better C programmer. No, I'm not a Forth evangelist - I write embedded systems in C all day long.

Comments

Just Forth?

[DrPsycho]

If Forth (or in this case pbForth) can be adapted to program the LEGO Mindstorm bricks, what about other programming languages?

I for one would love to see Perl for LEG0. Do any such extensions for Perl exist, or are they in the works? Could other languages be adapted for LEGO? Forth is admittedly rather archaic, and few people program in it any more. Might open the appeal of the Mindstorm to a greater community.

Oh. Who am I kidding. Every geek wants LEGO. :^)

No perl

[morven2]

Perl is NOT suited to embedded programming. Perl is huge. A Forth interpreter is tiny, and Forth bytecode is tiny. Forth was written for embedded systems.

Perl is best suited to larger systems, as a good method of tying together the extensive resources available on such a machine. It's just not suited to a tiny system.

WebCam mount, NQC, legOS

[Fastolfe]

Firstly, legOS is a really cool project. They've totally re-written the firmware for the RCX and built a fully pre-emptive multitasking environment running programs you can write in C or C++ and compile with a gcc cross-compiler. Very cool stuff, though the networking support (IR) doesn't seem very usable just yet.

NQC uses the standard firmware I believe, and is a bit more solidified. You write programs in a pseudo-C language and compile/upload it using the NQC utility. It also has some good IR message passing abilities.

Information about both of these can be found at LUGNET in the robotics section.

I experimented with LegOS a while back but ended up using NQC and a bunch of server-side Perl to build myself a telerobotic camera mount for my webcam.

There are definitely tools available out there for some extremely flexible Mindstorms programming.

Re:WebCam mount, NQC, legOS

[Hrunting]

I live in the same apartment as this webcam and actually built the camera-holding assembly. Being the humble dood that Fastolfe is, he fails to go on about some of the actual features in this webcam.

The assembly is built solely from the parts that I received in my Mindstorms kit a year ago (no add-ons, no extra sets). One motor runs the manages the rotation in the horizontal direction (spin) and the other manages rotation in the vertical direction (tilt). The whole thing sits about 8 inches high and the RCX unit does not form part of the base (we have it slightly separated since the IR signal comes from another computer across the room).

The program keeps track of spin and tilt so that users can't spin it all the way around (tangling up the cord in the process) nor can they tilt more than 90 degrees in any one direction. The program also allows a certain point to 'marked' as the initial starting point for the tracking, and there's a handy reset feature (not available outside the internal network). He also wrote the telecam daemon that resides on my Linux box that handles the actual control of the webcam (the web stuff is on a different server).

Streaming is handled by (*gasp*) a Windows program, Webcam32, that actually came with the Java code necessary to the streaming. It was a nice little package. Fastolfe is currently in the process of writing his own program for Linux that will use bttv or something similar to do the same thing, but for right now, it's working pretty dandy.

Setting this thing up isn't very difficult. Of course, with the post to Slashdot, it's getting hit pretty hard, but the great thing is, that we've gotten more feedback about potential problems (as Fastolfe said, "Finally, someone who knows how to open their Java console") in the past five minutes than we've received since we put the thing up.

Re:Give your old bricks new life

[giberti]

As with any great toy, there are limitations, but here is the low down for thoes who dont know about this little toy yet...

Out of the box its a PLC type system with three in's and three out's... It comes with two motors, two on/off "touch" sensors and one ir sensor... It also has (but not talked about) its own built in IR sensor which it can use but requires using some slightly more advanced programming languages than the one included.

There are all types of Visual Basic programs available, but thats all I have seen so far. The lego site talks briefly about it I belive.

There are also add ons available for it... a heat sensor, a rotational sensor and of course more motors.

The toy is pretty nice, but really requires some patience engineering the remaining bricks to do what you want, and as always, if you dont have some legos already, you will want to go and get a few kits, because you will be limited despite the large quantity of bricks included.

Hope this helps clear some stuff up.

PRC

[miahrogers]

I was in the Penninsula Robotics Competition here in south eastern Virginia. We(my school's team) had to build a robot that would drive around a rectangular course and collect small white wiffle balls.

Programming for the Mindstorms robots isn't very hard. However there are many other problems with them.

For one you are only allowed to have three engines on a given mindstorms robot. I guess i should more accuratly say that you are only given 3 power terminals to plug your engines into, you may plug in more than three engines, but then two of them must go in the same direction.

Another problem with the mindstorms robots is that they don't allow much room for a "smart" robot, as you are only given 3 sensors (like the engines above you can plug in more than three sensors but then two of them must respond to the same stimulus).

Also the strength of legos in general is much worse when you try to put legos and a moving vehicle into one. Your building style will have to be entirely reformed if you plan on keeping your mindstorm alive for more than 10 minutes. The technic legos help with this a little, because they are longer and contain those neat axle shafts which we used liberally. But overall if you decide to change anything on the robot it will have to be entirely rebuilt for strengh/durability reasons.

The last major problem with mindstorms robots is that they cost way too much. For a kit including three engines, a bunch of legos, and one cpu unit(basically the bare minimum you can get by on if you want a robot that moves), it was > 500$.

Mindstorms™ is sort of limiting

[Ptolemy Too]

I have a bit of a bias, here: as a programmer and a homeschooling dad, I've long wanted to write a good Intro To Programming book. I thought Mindstorms(TM) might be a good medium for that. But it's not: Doing anything with Mindstorms(TM) is as much (or more!) mechanical engineering as programming.

At first I thought, oh, that's OK. That still involves problem solving and working with constraints, yes?

But what constraints! Forget any notion of building Rodney Brooks-like robots: You get three sensor inputs. Even if you were willing to spring for lots of extra-cost sensors, and used some clever multiplexing schemes, you'd be hard pressed to build an insect that could even know whether its legs were up or down, forward or back.

And seemingly simple robots have a way of using up the parts that come in the standard set. Once you've built a track following robot, what do you do with it? You've used up both motors. Similarly, once you've built an arm that can raise/lower open/close its claw, you've used both motors, both touch sensors, and most of the gears and structural pieces.

I'm afraid that I lost interest pretty quickly.

Re:Mindstorms™ is sort of limiting

[tlhIngan]

Here's a way to imitate more sensors/motors, assuming we can do it with a mindstorm (I don't have one, so this is just hypothetical).

For less verbosity, I'll call the motor controls A, B, and C, and sensors 1, 2, and 3.

Additionally, I'm assuming the motor outputs are tri-state (forward, off, reverse), but sensors are binary (shorted, open).

[Method 1]

Leave A for motor control, and multiplex it via a serial output from say, B. Leave sensors 1, 2 for direct use, and make 3 a multiplexed one. Contol the sensor multiplexor from C.

[Method 2]

Use A, B for motor control. Use C to control multiplexors for both motors and sensors. Again, sensor input 3 is multiplexed.

[Method 2.1]

Control motors by using a positive-going multiplexing scheme, and sensors by a negative going (reverse) scheme.

[Method 3]

Again, A is for multiplexed motor control.
Again, 3 is for multiplexed sensor control, 1, 2 are regular sensor inputs.
Use B as a clock, and C as data to control a shift-register, whose outputs connect A or 3 (as appropriate) to inputs.

I'm not saying that the constraints aren't limiting, just be imaginative and try to think of something. I don't know if these ideas work or not, but they're ideas for people to try, perhaps mess around with, which can lead to more ideas. Perhaps try various constrained microcontrollers (very little RAM (from bytes to countable kbytes), low clock, constrained instruction set, low program memory count [there are processors that separate program instructions from RAM]), like Basic STAMPs, PICs, to more "expansive" processors like a HC11.

The challenge is to make things work given a constraint (usually cost) >G. Perhaps you'll make an "MindStorm Expansion Brick" that hooks up to the RCX unit and offers a lot of sensors/motor control, at the expense of software complexity.

Legos. Yum

[Magus311X]

I personally use NQC becuase personally its much easier for me to deal with than the drag-and-drop interface provided with the application on the kit's CD-ROM, and IMHO I find it more flexible.

Mark Miller has made modifications to allow each sensor input on the RCX to handle four different sensors per input (for a total of twelve sensors per RCX unit). He has also provided example code in NQC to show how to handle the situation. Here's the link: http://www.eagle-software.com/MindFest.h tm. This is a great solution for those of you who would like to use more than 3 input devices on a single brick.

What am I doing with mine? Currently I'm trying (honest!) to create an ATV that can map out its immediate surroundings (using proximity detection [http://www.mop.no/~simen/legoproxi.htm], and input from touch sensors) so that if it gets stuck it can quickly figure out how to leave the area. I just purchased my second set and a myriad of sensors too. Joy! =)
--

Re:Mindstorms

[Our Man In Redmond]

You're not paying $100 (or $200 or whatever) for the Legos. You're paying for a really cool, really small computer that happens to come with a bunch of Lego bricks and other accessories (sensors, motors, and the like).

I don't know just how cool it is yet, though. I got a set for my son for Christmas and he hasn't yet let me near it.
--

I really hope someone will moderate this up.

[GoRK]

Here's a related topic to this whole Mindstorm business. I have a system that LEGO designed way way before the Mindstorms and even MIT's LEGO brick (which became the basis of the Mindstorms) called LEGO Technic TC. It consisted of a very simple 8-bit ISA card that connected to a black box with a ribbon cable. Basically it was a relay control card. The thing had 6 "output ports" that could either drive a motor forward and backward or operate a light. It also had two input ports for 1-bit touch sensors or optical sensors (or any other 1-bit sensor you could build for that matter).

The whole system was programmed in a LOGO (Remember that one, geeks?) environment called LEGO TC LOGO. It ran under DOS. I have been unable to find any control programs for this thing except for the stupid worthless DOS based LOGO.

Is anyone else still using this system? Is there anything for it under Linux?

~GoRK

Joystick sensor for Mindstorms

[Xidus]

A few days after getting my LEGO Mindstorms set, I hit upon the idea of using a joystick as an input sensor. I had an Atari 2600 in the closet with a few good controllers left, so I hacked together a method to use it with the RCX.

Briefly, with any switch-based joystick, you can use different resistors between each direction wire and ground so that unique sensor values result which can be read by the RCX.

When it's done, you have a 10-position switch that's very useful -- discrete values for joystick in the center, all 8 positions, and fire button pressed. (trigger RCX-mounted weaponry? Mmmm...)

Complete info is available at http://xidus.xidus.net/joystick.html

Have fun, and let me know if you do anything interesting with this sensor, or even if you manage to build one correctly.
-
$ more ~/.sig
******** .sig: Not a text file ********