- Shopping Bag ( 0 items )
Lego robots! Mindstorms are sweeping the world and fans need to learn how to programme them
Lego Mindstorms are a new generation of Lego Robots that can be manipulated using microcomputers, light and touch sensors, an infrared transmitter and CD-ROMs. Since Lego launched Lego Mindstorms in late 1998 sales have skyrocketed - with no sign of slowing down. Mindstorms have captured the imagination of adults and children alike, creating a subculture of Mindstorm enthusiasts around the world. The kits are now a staple part of engineering and computer science classes at many high profile Universities.
Building Robots with Lego Mindstorms provides readers with a fundamental understanding of the geometry, electronics, engineering, and programming required to build your own robots. Mario and Giulio Ferrari are world-renowned experts in the field of Lego Mindstorms robotics, and in this book they share their unrivaled knowledge and expertise of robotics as well as provide a series of chapters detailing how to design and build the most exotic robots. Mario and Giulio also give detailed explanations of how to integrate Lego Mindstorms kits with other Lego programmable bricks such asScout and Cybermaster, as well as with non-robotic Lego Technics models.
Having discussed motors and sensors, and geometry and gearings, it's now time to put all these elements together and start building something more complex. We stress the fact that robotics should involve your own creativity, so we won't give you any general rule or style guide, simply because there aren't any. What you'll find in this short chapter are some tips meant to make your life easier if you want to design robust and modular robots.
Recall the standard grid we discussed in Chapter 1. We showed how it leads to easy interlocking between horizontal and vertical beams. The sequence was: 1 beam, 2 plates, 1 beam, 2 plates… You can take advantage of the plate layer between the beams to connect two groups of stacked beams, thus getting a very simple chassis like the one in Figure 5.1. If you actually build it, you can see how, despite its simplicity, it results in a very solid assembly. This also proves what we asserted in Chapter 1 regarding the importance of locking layers of horizontal beams with vertical beams. For instance, if you remove the four 1 x 6 vertical beams, the structure becomes very easy to take apart. Figure 5.1 A Simple Chassis
Remember to use the black pegs (or pins) when connecting beams. They fit in the holes with much more friction than the gray ones, because they are meant to block beams. The gray pegs, on the other hand, were designed for building movable connections, like levers and arms. You're not compelled to place all the beams in one direction and the plates in another. Actually, you are likely to need beams in both directions, and Figure 5.2 shows a very robust way to mount them, locked in the intermediate layer of our example structure. Figure 5.2 Alternating Plates and Beams
Sometimes you want to block your layers with something that stays inside the height of the horizontal beams, maybe because you have other plates or beams above or below them. The full beams we’ve used up to this point extend slightly above and below the structure. The liftarms help you in such cases, as shown in the three examples of Figure 5.3:
Liftarm a Two coupled 1 x 5 liftarms with standard black pegs
Liftarm b A single 1 x 5 liftarm and .75 dark gray pegs
Liftarm c Two 1 x 3 liftarms with axle-pegs
Figure 5.3 Using Liftarms to Lock Beams
Naming all the individual LEGO parts is not an easy task. Some people call a half-beam what we refer to as a liftarm, because it has half the thickness of a beam. Due to this, we chose to use the terminology defined in a widely accepted source: the LUGNET LEGO Parts Reference (see Appendix A for the URL to the site). Despite our insistence on the importance of locking beams, there's no need to go beyond the minimum required to keep your assembly together. When the horizontal beams are short, a single vertical beam is usually enough. The example “a” in Figure 5.4 is better than its “b” counterpart, because it reaches the same result with fewer parts and less weight. Weight is, actually, a very important factor to keep under control, especially when dealing with mobile robots. The greater the weight, the lower the performance, due to the inertia caused by the mass and because of the resulting friction the main wheel axles must endure. Figure 5.4 One Vertical Beam is Sometimes Enough
We suggest you also support the load-bearing axles with more than a single beam whenever possible. The three examples shown in Figure 5.6 are better than those in Figure 5.5, with 5.6c being the best among all the solutions shown so far. The use of two supports, one on either side of the wheel, like on a bicycle, avoids any lever-effect created by the axle on the support, thus reducing the friction to a minimum. Figure 5.6 Two Supporting Beams Are Better than One
The position of the RCX has a strong influence on the behavior of mobile robots. It's actually the shape and weight of the whole robot that determines how it reacts to motion, but the RCX (with batteries) is by far the heaviest element and thus the most relevant to balancing load. To explain why balancing load is important, we must recall the concept of inertia. We explained earlier in the chapter that any mass tends to resist a change in motion. In some cases, to resist acceleration. The greater the mass, the greater the force needed to achieve a given variation in speed. The “Acrobot” model shown in the MINDSTORMS Constructopedia works under this same principle. If you have already built and tried it, did you wonder why it turns upside down instead of moving forward? This happens because the inertia of the robot keeps it in its present condition—which is stationary. Once power is supplied to the motor, the wheels try to convert that power into motion, accelerating the robot. But the inertia is so great that the force resorts to the path with least resistance, turning the body of the robot instead of the wheels. After having turned upside down, the robot has the undriven wheels in front of it, preventing it from turning again, and now can't do anything other than accelerate. You probably don't want your robots to behave like Acrobot. More likely, you ’re looking for stable robots that don't lose contact with the ground. You can use gravity to counteract this unwanted effect, putting most of the weight further from the driving axles. There's no need for complex calculations, simply experiment with your robot, running a simple program that starts, stops, reverses, and turns the robot to see what happens. Place the RCX in various positions until you're satisfied with the result.
Putting It All Together: Chassis, Modularity, and Load The following example summarizes all the concepts discussed so far in this chapter. Using only parts from the MINDSTORMS kit, we built the chassis shown in Figure 5.7. Its apparent simplicity actually conceals some trickiness. Let's explore this together. Figure 5.7 A Complete Platform
It's built like a sandwich, with two layers of beams that contain a level of plates. It's robust, because vertical beams lock the layers together. Notice that for the inner part of the robot, we used 1 x 3 liftarms instead of 1 x 4 beams. This way the top results in a smooth surface where one can easily place the RCX or other components. The load-bearing axles are two #8 axles that support both the outer and inner beams (#8 means that the axle is 8 studs long), while the wheels are as close as possible to their supports. Figure 5.8 Bottom View
The motors have been mounted with the 1 x 2 plates with rail, as explained in Chapter 3 (look back to Figure 3.4). They are kept in place by two 2 x 4 plates on their bottom (Figure 5.8), but by removing those plates you can quickly and easily take out the motors without altering the structure (Figure 5.9). Figure 5.9 Easily Removing the Motors
You can also remove the pivoting wheel and the two main wheels in a matter of seconds to reuse them for another project (Figure 5.10). We should mention here that the pivoting wheel is quite special, since it's what makes a two-wheeled robot stable and capable of smooth turns. The technique of making a good pivoting wheel has its own design challenges, of course, which we'll explore in Chapter 8. Figure 5.10 …and the Wheels
The truth is that if you own only the Robotic Invention System, you probably won't have enough parts to build another robot unless you dismantle the whole structure. If you have more LEGO TECHNIC parts, however, you can leave your platform intact and reuse wheels and motors in a new project. Now we can experiment with load and inertia. If you have the LEGO remote control, you don't need to write any code. If not, we suggest you write a very short program that moves and turns the robot. You don't need anything more complex than the following pseudo-code example, which will drive your robot briefly forward then backward, and make it turn in place: start left & right motors forward
wait 2 seconds
stop left & right motors
wait 2 seconds
start left & right motors reverse
wait 2 seconds
stop left & right motors
wait 2 seconds
start left motors forward
start right motors reverse
wait 2 seconds
stop left & right motors
Place your RCX in different locations and test what happens. When it is just over the main wheel axles (Figure 5.11), the robots tend to behave like the Acrobot and overturn easily. Figure 5.11 Poor Positioning of the Load (RCX) Makes This Robot Very Unstable
As you move the RCX toward the pivoting wheel, the robot becomes more stable (Figure 5.12). It still jumps a bit on sudden starts and stops, but it doesn't flip over anymore. Figure 5.12 Better Positioning Improves Stability
The content of this chapter may be summarized in three words: layering, modularity, and balancing. These are the ingredients for optimal structural results. Thinking of your robot in terms of layers will help you in building solid, well-organized structures. Recall the lessons you learned in Chapter 1 about layering beams and plates and bracing them with vertical beams to get a solid but lightweight structure. A robust chassis comes more from a good design than from using a large number of parts. Modularity can save you time, allowing you to reuse components for other projects. This is especially important when it comes to the “noble” parts of your MINDSTORMS system—the sensors, motors and, obviously, the RCX—because they are more difficult and expensive to replicate. You should put this concept into operation not only for single parts, but for whole subsystems (for example, a pivoting wheel), which you can transfer from one robot to another.
Balancing is the key to stable vehicles. Keep the overall mass of your mobile robots as low as possible to reduce inertia and its poor effects on stability. Experiment with different placements of the load, mainly in regards to the RCX, to optimize your robot’s response to both acceleration and deceleration. We will look more deeply into this matter in Chapter 15, when we learn how to build walking robots (where management of balance is a strict necessity). Unfortunately, these goals are not always reachable; sometimes other factors force you to compromise. Compactness, for example, doesn’t mesh well with modularity. Certain imposed shapes, like those used in the movie-inspired droids of Chapter 18, can force you to bypass some of the rules stated here. We aren’t saying they can’t be violated. Use them as a guide, but feel free to abandon the main road whenever your imagination tells you to do so.
|Chapter 1||Understanding LEGO Geometry||3|
|Chapter 2||Playing with Gears||17|
|Chapter 3||Controlling Motors||41|
|Chapter 4||Reading Sensors||57|
|Chapter 5||Building Strategies||83|
|Chapter 6||Programming the RCX||97|
|Chapter 7||Playing Sounds and Music||117|
|Chapter 8||Becoming Mobile||127|
|Chapter 9||Expanding Your Options with Kits and Creative Solutions||153|
|Chapter 10||Getting Pumped: Pneumatics||179|
|Chapter 11||Finding and Grabbing Objects||199|
|Chapter 12||Doing the Math||213|
|Chapter 13||Knowing Where You Are||233|
|Chapter 14||Classic Projects||249|
|Chapter 15||Building Robots That Walk||279|
|Chapter 16||Unconventional Vehicles||311|
|Chapter 17||Robotic Animals||333|
|Chapter 18||Replicating Renowned Droids||349|
|Chapter 19||Solving a Maze||371|
|Chapter 20||Board Games||391|
|Chapter 21||Playing Musical Instruments||411|
|Chapter 22||Electronic Games||425|
|Chapter 23||Drawing and Writing||441|
|Chapter 24||Simulating Flight||467|
|Chapter 25||Constructing Useful Stuff||493|
|Chapter 26||Racing Against Time||513|
|Chapter 27||Hand-to-Hand Combat||525|
|Chapter 28||Searching for Precision||537|
|Appendix B||Matching Distances||569|
|Appendix C||Note Frequencies||575|
|Appendix D||Math Cheat Sheet||577|
|Gears, Wheels, and Navigation||579|
LEGO Mindstorms offer us the opportunity to look at the world with different eyes, letting us create anything we wish, but within the limitations of mechanics -- this forces the builder to rediscover the mechanics that rule even our most basic daily actions, like simply walking or picking up objects. We all tend to forget that these basic abilities required a long learning process that happened, mostly unconsciously, during our childhood. In designing robots that must successfully mimic those behaviors, we are forced to break down each seemingly simple action into its many components, and in the process we cannot help but rediscover how complex our interaction with the environment is! For example, the experience of building a robot that walks teaches us many important principles about how static and dynamic balance work. Similarly, the making of a grabbing arm requires that we learn how to adapt the shape of a mechanical hand to that of the objects to be grabbed, which in turn requires that we understand the concepts of degrees of freedom, force, and elasticity. In a certain sense, we become children again, but with the knowledge and the experience to bring a higher level of awareness to our discoveries.
People who approach robotics for the first time may not have anticipated the extent of the challenge. Tasks of apparent triviality hide a surprising complexity, and entail the mastery of many different techniques. For example, a classic robotics competition requires robots to search out soda cans in a room, collect them, and bring them back to the starting point. It seems quite a simple task -- after all, any toddler could perform such a task. However, the list of the involved abilities is impressive: the robot has to find the cans, distinguishing them from the wall or floor; it has to grab them, store them somewhere within its structure, and then finally, it must find its way back to the starting point, which by itself is quite a difficult operation.
For this reason I always invite beginners to start with very simple goals! Each small challenge they meet will provide the necessary experience to embark on more demanding projects. I also tell them to compare their own solutions to those devised by other people. Fortunately there are plenty of resources about Mindstorms robotics -- good books and good Web sites -- and everybody can take advantage of these documented experiences to speed up the learning process.
The best way to gather new knowledge is to attend contests. When preparing a robot for a contest, you are forced into a mental condition in which you try to imagine what solutions your opponents could use, and try to evaluate the pros and cons of all of them. Succeeding in a contest requires that your robot not only work, but also be optimized for the given task, and to achieve this you must pick the best possible strategy and implement it flawlessly. The big moment arrives when your robot has a confrontation with its opponents, which is your real opportunity to learn from others' solutions and from your own mistakes.
If you are part of a team that is preparing a robot for a competition, your experience will be even more positive, because you will benefit from a multitude of ideas during the design phase as well as during the event. The story I'm going to tell you is a good example of how working in a team can lead to results which are better than those of the individual contributions of the team members.
One of the first LEGO Robotics contests organized by the Italian LEGO Users Group was about line following. In this kind of competition, a sort of classic among the contests for small robots, the robotic vehicles are required to follow a strip of tape on the floor, from beginning to end, running as fast as possible. The robot that covers it in the shortest time wins. It was only the second competition of our club, and most of us had owned the Mindstorms Robotics Invention System kit for just a few months, so the group had little (if any) experience with this particular task. We all knew that line following was possible using a light sensor that would look down to distinguish the line from the floor, but that was all.
The robot I prepared was a differential drive, that is, a robot controlled by two independent drive wheels, one on the right and the other on the left, whose combination of motion allow the robot to go straight or turn in any direction. I had mistakenly believed that an optimal approach to line following required two line sensors, one on the left and the other on the right of the line, but the rules of the contest stated that only a single light sensor was allowed, so I equipped my robot with one light sensor placed directly in the middle of the front edge. I programmed the robot to go straight while reading the black line, and to stop and search the line again, turning right and left, after having lost the line (which happened quite often).
The contest was held in Modena, at my brother Giulio's home, and I had invited Antonio Ianiero and Domenico Franco, a couple of friends from Rome, to spend the night at my house the night before, so they could avoid the travel time in the early morning. Of course, when they arrived, we couldn't resist showing each other our robots, discussing the strategies and the mechanical details. Antonio's robot was a very simple differential drive. It was definitely slower than mine, but instead of stopping from time to time to perform a big correction, it used smaller continuous adjustments. More important, Antonio had discovered the key strategy to line following: to stay along the edge of the strip instead of in its center. (Light sensors read a small area, not a single point, so when on the edge of a line they detect both part of the line and part of the floor, returning an intermediate value.) This way the robot knows which direction to turn to return on the path: If it reads too strong a "line" value, it turns toward the "floor" values, and vice-versa. Domenico's robot was a steering drive, the architecture commonly adopted in cars. It actually had not been completed, and had some serious software problems that made it very unreliable. Nevertheless, I felt there was something good about it, something that both Antonio and I had missed.
We discussed new ideas and possible tricks to improve our robots long into the night, and when I finally went to sleep I felt I had learned a lot, but still couldn't come up with the optimal solution. At 6:30am I suddenly woke up with The Idea -- something that had points in common with all of the three robots, but was essentially new: A tricycle, with the light sensor attached to an arm protruding from the front wheel steering assembly. This configuration seemed immediately very good to all of us, and we frantically started to build this new robot. Antonio wrote the code, while Domenico and I assembled the structure. We had no more than a couple of hours to finish and test it.
Everything went well, and we had the robot running fast and smoothly along the test line in time to attend the contest. The steering configuration proved a very efficient solution: The steering mechanism adjusted the position of the sensor to keep it as close as possible to the edge of the line, and the driving wheel was consequently pointed in the right direction. The drive wheels had nothing to do but push the robot, since they no longer needed to stop and adjust direction. We were very excited.
Well, if you're waiting for a happy ending, I'm sorry to disappoint you! Our collectively conceived robot didn't win the race, though it did rank second with a good lead over the third-place winner. However we were pleased to see that our solution was that successful. In fact, Paolo Masetti's robot, who won the race, had been built using the same configuration, with the difference that Paolo had had the idea weeks earlier and had had the time to optimize the details! His robot, Indy, which covered the seven meters of the run in less than ten seconds, has become a legend in our club. We still have had the satisfaction of having found something very close to the optimal solution, of having had a grand time discussing, designing, and building the robot together, and of having seen in action the result of the power of our ideas. And that is the reward of building with LEGO Mindstorms, whether you compete or not! (Mario Ferrari)