Having reported on the LEGO ROBOLAB Kit in April 2005, it seemed natural to write a sequel to that article based on the MINDSTORMS® NXT Robotics Toolset. The newer kit definitely has gone up-market in its programmability and sensor and motor capabilities. There is much less emphasis on low-level gearing and mechanical engineering in contrast to the earlier ROBOLAB that had basic motors.
In the MINDSTORMS kit, the motors include gear reduction as well as angular feedback sensors. Accordingly, you can program a motor to turn clockwise for 180 degrees at a certain speed. That would have been difficult if not impossible in the earlier product.
A tremendous amount of effort has gone into the step-by-step on-screen instructions for the various models. For example, there are 60 illustrated steps to build a robotic arm and an additional 16 steps for a hand. Given the complexity of some of the models, this effort is necessary to ensure a satisfying user experience, as they say. Nevertheless, some of the illustrations show only one piece being added. Perhaps an exploded view with explanatory text would be an alternative approach worth considering.
Programming also is very different from ROBOLAB, reflecting some of the changes introduced in recent versions of LabVIEW. Although wires can be used to interconnect ports on icons, you seldom need to. Instead, most of an icon's behavior is determined by parameter values entered on a form.
When programming, you start with the common palette, which is useful, but the options offered by the complete palette are more interesting. At least initially, I felt I had to work hard to overcome what seemed like excessive graphic gimmicks. There are self-locating blocks, lots of different colors and shapes, and very large symbols.
Icons are positioned on a sequence beam, which greatly limits the types of networks you can build, especially compared with ROBOLAB. A positive result of constraining the arrangement of icons is very predictable program execution. As I found, the real power of a program is in the configuration panels.
Without reading any instructions, you soon learn that clicking here and there opens up connector blocks on the icons. It's helpful that the wires are different colors for different kinds of data, and if you connect two things that shouldn't be connected, the wire goes dotty and grey. However, in my experience, it wasn't necessary to wire the icons together at all because the control-panel information was very comprehensive. Nevertheless, I'm sure that advanced MINDSTORMS builders find wiring useful.
Installing the software on my PC wasn't completely straightforward, and after installing it, you are exposed to LEGO and other advertising. You need to restart the computer for the short-cut icon to appear. After doing that, I could get the MINDSTORMS software to start up.
Example
A general comment on LEGO construction: It helps to have the parts spread out in a large flat box. There may be some kids that are so organized that they actually keep similar parts in separate containers; however, I suspect that most of the time all the parts end up mixed together. Finding a specific component among the 571 that make up the kit is helped by color and having only a layer or two to work through.
Initially, it's easy to find a part because there are several of each type. But as the project nears completion, you are trying to locate one particular part, and it can be difficult if you can't spread out all the remaining components.
Rather than dive into a pre-engineered example, I wanted to become familiar with the kit by building something original. My idea was to make a mechanism that had balls drop down slides and eventually get picked up and recirculated over and over.
Two motor drives were required: one to close a pair of jaws around the ball and the other to swing the ball and jaws up and over to a track and then release the ball and return to the original position. I didn't build the track but did complete the necessary programming for the LEGO mechanism. Figure 1 shows the operation of the model as a progression of separate positions.
Figure 1. Recirculating Ball Machine
Because I didn't know where the main arm would be positioned at the start of the program execution, I programmed the drive motor to traverse the arm relatively slowly to the right until a stationary photodetector triggered on a sufficiently high light level reflected from the white beam on the side of the arm. That action stopped the main motor and started a second motor that activated the jaws.
I used a worm gear as a rack driven by a pair of pinions geared together and turning in opposite directions on either side of the rack. This linear motion activated a symmetrical bell-crank arrangement that opened and closed the jaws, actually more like a pair of claws interleaved to grab and hold one of the 2″ balls.
After the photodetector triggered and the main motor stopped, the claw actuator motor was started and ran a short amount of time until the touch actuator was pressed. The mechanism was designed so that the jaw opening would be more than sufficient to drop the ball but not so wide that the bell cranks would jam. Also, the jaw opening could not be too narrow to restrict tolerance in the positioning of the next ball to pick up.
Having dropped the ball, the machine was in a known state set by two reliable sensors. A short 3-s wait icon held the machine in that state. Because the main motor drives a fixed gear ratio, it was simple to compute that the arm would reach the desired position at the other side of the machine after 1,120 degrees of rotation. As a result, a main motor icon was inserted and its panel programmed for 1,120 degrees with braking after the rotation.
Also, the claws then needed to be closed by running the second motor. Because of the design of the mechanism, a rubber-band drive was the easiest to implement and acted as an overriding clutch, providing holding power for the jaws after the motor had stopped. I deliberately programmed the motor to run a little longer than required so the rubber bands would be stretched.
By using a sensor to determine one end point in each of the mechanical loops, both the claws and the traversing mechanism could operate repeatedly without tolerance build-up.
Programming
I simply couldn't understand why I was having very basic programming problems. In desperation, I e-mailed MINDSTORMS but never received a reply or acknowledgement. Finally, I contacted an acquaintance at National Instruments, and soon the problem was solved. In effect, each icon in the program describes a state. For example, you may insert a motor icon and in its associated control panel set a number of conditions, such as run clockwise forever with servo feedback to hold a 50% speed.
I had assumed that if I put a similarly configured motor inside a while loop that when the loop terminated the motor would stop. No, the motor's local variables set on its control panel take precedence. When I tried to run that kind of program, the motor did indeed stop, but only because the program had stopped.
To gain control of the motor, you must insert another motor icon on the sequence beam but with different conditions programmed into the icon's setup panel. You could have a motor icon set to run forever, then a wait icon set to 10 s, and finally another motor icon set to stop. That kind of process underlies operation of any MINDSTORMS program.
However, because the programming panels work at a high level of abstraction, you can directly program a single motor icon to run for 10 s, avoiding the need for three separate steps. In addition, you can specify whether the motor should coast to a stop or brake. And, you can allow further program steps to execute while the motor runs or inhibit the program from moving on until the motor motion completes.
Obviously, there is a lot of powerful low-level software running in the background to support the actions programmed on each panel. All of this motion control required for the machine was possible using only six icons, giving some idea of the high-level nature of MINDSTORMS. Additional icons that I did not use have even more functionality. The move icon allows simultaneous control and synchronization of at least two motors necessary to simplify programming Rex the Robot to walk.
Also, the basic while loop could be linked to the state of a particular sensor. For example, if the loop were to run until the touch sensor was pressed, the loop icon would include the touch-sensor symbol, and the control panel would present appropriate choices such as actuate when pressed, when released, or when depressed 50%.
A lot of detail is handled on the individual panels associated with the elements, which makes the overall diagram higher level and cleaner. On the other hand, there's no way that a MINDSTORMS diagram is self-documenting to the degree a ROBOLAB diagram is. There is so much detail hidden in the panels that you have very little information on the diagram with which to work.
Construction
This kit uses the TECHNIC® beam-and-pin type of construction found in many LEGO mechanical kits. In common with ROBOLAB, the controller block can be built into the mechanism. Similarly, there are plenty of attachment points for the motors and sensors.
The split pins hold the beams securely, but I found that sometimes I needed to use a shaft as a tool to remove a tight-fitting pin, especially one of the three-high pins. In fact, one of the questions on the MINDSTORMS website was about building models that did not need the pins because they were hard to push in and out. I can imagine it might be difficult for a 10 year old.
This inconvenience aside, building the ball-recirculating machine followed the same approach you need to use for any LEGO mechanism. With a bit of forethought, there's not too much unbuilding and rebuilding required to get to a satisfactory result. Construction started with the claw assembly. When that was relatively complete, I built the traversing carriage that the claw assembly mounted to.
One problem that I hadn't foreseen was the position of the claw assembly motor connector. It was so low that I needed to raise the whole mechanism for the cable to clear the tabletop as the assembly traversed from one side to the other.
When first trying a control sequence, it's a good idea to restrict motor-drive performance. For example, either select a short amount of time or a small number of degrees or revolutions and opt for 50% power rather than 75% or 100%. Because the motors include gear reduction, there is a lot of torque available at the output even before adding more gearing.
If your program doesn't execute as you expect it to, it's very easy for the motors to tear apart the model they're attached to. Yes, this cautionary note is based on personal experience.
Building and Programming Alpha Rex
It was fun to dive in and create the ball-recirculating machine from scratch, but one of the objectives of the MINDSTORMS exercise was to review the construction plans. The kit comes with construction and programming instructions for 18 separate models. So, after documenting the ball machine's operation, the parts were reclaimed and construction started on Rex the Robot
(Figure 2).
I worked directly from the on-screen instructions, which are broken into several sections. The first—walking—has 48 drawings showing how to build the legs. I found that it helped to zoom the view. Otherwise, given the many small parts and the size of the overall mechanism, it sometimes was hard to tell if connecting pegs were two or three holes apart.
The drawings are very detailed and, one assumes, correct. I can imagine that each one was tried many times by several builders to ensure accuracy. Nevertheless, it's easy to make mistakes because you might not recognize that a part is asymmetrical. Oh, it looks like it's symmetrical, but you can build one step of the instructions and then not be able to complete a later step because of the incorrect symmetry.
An example is a part that has a smooth hole in one end but a cross-shaped hole in the other. The smooth hole will fit on a shaft, but a simple connector pin will not go into the cross-shaped hole. Assembled the other way around—with the cross-shaped hole on the shaft and the connector pin in the smooth hole—it works as intended.
I worked through the first 16 of 48 diagrams without much trouble. Figure 17 is a mirror image of what it should be, which obviously caused confusion. On previous diagrams, a small inset panel showed the type and number of parts required to complete that stage. Not so for figure 17. It simply showed a completed leg assembly, which clearly had more parts added after step 16. Although figure 17 created a problem, the robot has two legs, and they are symmetrical.
The sequence beginning with figure 18 starts on the other leg, and you can work out the differences after that leg is built. Still, figure 17 is confusing. For example, the entire figure 20 is dedicated to showing how one part fits, but figure 17 jumps to a completed mechanism without any details given. Panel 28 for the other leg has the missing detail so you can complete the first leg using it as a guide.
Most of the 48 building stages are very easy, but there are a few near the end that require more understanding of how the model actually moves. The mechanisms are cross-coupled and must be synchronized carefully. In other words, the right-side motor drives both legs as does the left-side motor. Part of the motion is a side-to-side rotation of the foot, and part is a lifting action.
Once you have completed the model to this stage, it's obvious just how complex it is mechanically. There is a lot going on, and without very clear and detailed drawings, it's doubtful that most people would be successful in building it.
I didn't try to program and run the legs at this stage but instead completed the body. It, too, is very complicated, requiring careful attention to the building instructions. After a couple of missteps, the body was completed and joined to the legs. The kit exposes the builder to many types of mechanical elements, even connecting rods with snap-together ball joints at each end that are used to help keep the body upright above the legs.
Programming was very simple, but it was only at this stage that I was able to synchronize the legs. Instead of walking, my headless robot shuffled in one spot. Synchronizing the right and left gear drives solved most of the problem as did correcting a small construction mistake. Nevertheless, walking forward depends entirely on the action of two pivoting rubber-tipped pawls.
The intention is that the pawl should freely pivot and drag when the foot moves forward, then digging in and holding one foot stationary when the other foot is moving forward. I found the idea almost worked on a smooth desktop but failed completely on carpet. I ended up modifying the pawls so that a rubber piece was attached to each side of the pivoting arm, which then worked as required.
Synchronization between the two motors driving the legs is very good, but if for any reason it is disturbed, you must manually readjust the relative rotational positions of the two gear trains. A coupling extending from each motor shaft makes a convenient place to rotate the gears into alignment. There is no actual feedback that ensures the mechanism is operating correctly, just separate signals that confirm each motor has performed as instructed.
As the robot neared completion, I tried the various programming suggestions for the walking, distance-sensing, touch, and light-sensing capabilities. Everything worked as intended, but I frequently got error messages that the NXT had run out of memory.
Cutting back from “Have a nice day” to “Hello” solved the problem, indicating that audio storage consumes a lot of memory. It also was necessary, as shown in the programming instructions, to delete one capability when adding another. So, for example, I couldn't simultaneously activate the ultrasonic distance sensor and the routine that controlled turning around.
This problem was solved by examining the programs stored in the NXT 118-kB memory, 56 kB of which is available for user programs. After I deleted the earlier ball-recirculating routine as well as a couple of initial experiments, I had plenty of room for a more complicated Rex the Robot control program.
Summary
Rex walks and talks, laughs when I clap my hands, and swivels his head from side to side while swinging his arms up and down after I press the touch sensor at the end of one arm. Very few icons are required to achieve all this activity, demonstrating conclusively the power of the high-level programming approach that has been adopted.
LEGO and National Instruments, the company's partner, have done a great job of integrating sophisticated control and actuation into a plastic construction kit. In fact, they have done such a good job that several industrial automation and test and measurement companies are considering using the NXT controller in totally unrelated professional applications.
Bringing Rex to Life
The program that makes Rex the Robot walk, talk, and react to stimuli is shown in Figure 3. Three while loops are set to run forever so they cause the actions within them to continue executing.
For example, to make Rex's head move from side to side and his arms pump up and down, you need to press the touch sensor connected to port 2. When it is pressed, the motor connected to port A runs, causing the head and arm movements. The motor is programmed to run for only five revolutions and then stop.
At this stage, the sound sensor is enabled. I set the threshold to 50% so that a loud handclap would be recognized but background noise would not. Clapping or another loud sound triggers the sensor and that, in turn, starts the stored sound file. In this case, Rex laughs. Because the touch and sound sensors are within a while loop, after Rex laughs, the touch sensor again is activated, waiting for the contact to be pressed.
While this is going on, a flower is continuously displayed on Rex's chest, also known as the NXT controller display screen. The model programming instructions displayed a heart-shaped icon for several seconds followed by a second icon. After it is visible for a while, control reverts back to the original one and so on to give the impression of a beating heart. I cut down that loop to show only the one flower icon.
Finally, the third while loop monitors the state of the ultrasonic sensor. I set the threshold to 15″ so the sensor is triggered when you move your hand to within 15″ of the sensor. That causes Rex to say “Have a nice day.” If you keep your hand at that distance, nothing else happens. Withdrawing your hand to farther than 15″ again triggers the sensor, this time starting the walking motion after Rex says “Fantastic!”