2. 2
– We are helping to nurture future engineers and scientists
– The engineers and scientists of 2020 are second graders –
7- and 8-year-olds
Why National Instruments and LEGO®?
Welcome to the LabVIEW Object-Oriented Programming User Group Presentation.
October 22 – Jeff Buterbaugh
Aaron Campbell?
Kathryn’s area?
So everywhere I go, engineers get more excited about this product than any other offering from National Instruments. But why? What is it about the lego MINDSTORMS that is so appealing to engineers? Can we take any of the problems that are solved by Lego MINDSTORMS and apply them to REAL engineering?
So let’s look first at the hardware. What makes this brick so cool. Sure, it’s nice to be able to program a 32-bit processor with an LCD and a speaker, but really, it’s much more about the connectivity. <ANIMATE> In the engineering world, we would call these sensors and actuators. Using this tool, you can really develop something quickly that can gain a lot of information about the world around it. But that still isn’t the whole story.
What is it comes down to is that with the combination of the mechanical flexibility of the legos and the connectivity and ease of programming of the brick, you are no longer limited by execution and even those of us without masters in mechatronics can take our crazy ideas and make them into a reality. These applications we all downloaded from the MINDSTORMS website, and they represent just a small sampling of the crazy inventions that these lego users are devising when they are limited only by their imagination. On this slide you see everything form a camera controller (lower left) to vehicles to crawling creatures to a wax candle lathe (in the upper left) which takes a candle and reduces it’s diameter to mold it into a new shape. (http://MINDSTORMS.lego.com/NXTLOG/ProjectDisplay.aspx?id=c85e245e-d4b2-4453-a26f-36872ae69548)
The rest of this presentation really takes a look at the NXT hardware and software from an engineering point of view and looks at why these concepts are not too far from what real embedded design can be like.
Let’s start by taking a look at a generic architecture of a typical embedded system. Since most embedded systems are so specialized, these blocks are a little ambiguous. However, this is a very common architecture that is designed into systems from consumer electronics to industrial machines to medical devices.
<ANIMATE>
Starting with the interface to sensors and actuators, we see that a typical embedded design will incorporate some sort of I/O, either analog or digital. This can range from a simple push button/LED user interface to high precision A/D converters depending on the needs of the application.
<ANIMATE>
The next piece is digital logic to cleanly interface the I/O to the main processor. In the past, this has been discreet circuitry, but as these designs become more complex, most are moving to some co-processor to do inline analysis and processing of the data. This is usually a lower end microcontroller, an FPGA, a CPLD, or a custom ASIC.
<ANIMATE>
Third, we look at the main processor. This is really the brains of the operation, and this processor will house the main algorithms that define how the system behaves. This processor typically manages the collection and the analysis of data, and reactive control signals that need to be sent as well as managing the communication to the outside world.
<ANIMATE>
Which leads us to the final piece – connectivity. It has been said that in the near future, everything that runs on electricity will be on a network. Even regardless of this, most embedded systems offer some sort of connectivity for firmware upgrades, user configurations, etc.
Let’s take a look inside the MINDSTORMS NXT to see if this mirrors this architecture.
<ANIMATE>
This system diagram is from the MINDSTORMS hardware developer kit.
If well look closely at this system, we can see that it comprised of the four key components of most embedded systems.
<ANIMATE>
Here we see that there is some general analog and digital I/O to communicate to the sensors.
<ANIMATE>
We also see that lego has chosen an 8-bit microcontroller as the co-processor to manage the I/O. This is not programmable by the user, but rather, it is a fixed function device that offloads things like interrupt handling and protocol management so the main processor can have more bandwidth for the user application.
<ANIMATE>
We see also that LEGO has chosen an ARM7 32-bit processor for the main application development. This is the portion of the NXT that is user configurable.
<ANIMATE>
Finally, we see that the brick leverages several common communications protocols for both internal communications (SPI to the display) and to the outside world (Bluetooth via UART).
So now we come to the fundamental difference between the LEGO MINDSTORMS and actual product development. Here we see the phases of product design. Using the MINDSTORMS software, you can easily design an algorithm to control your device. And by taking advantage of the LEGO mechanical structures and the flexibility of the hardware brick, you can build a working prototype to bring your design to reality. However, you can’t really design a system with the MINDSTORMS because that would require that you build only one. If you actually wanted to produce the Wax Lathe machine, you would have to spend $250 on another Lego kit and put it together or embark on designing your own controller again from scratch.
<ANIMATE>
Rather, with the LabVIEW Graphical System Design Platform, you can use the same strength of extendable I/O and a common architecture as well as graphical development software to develop your prototype. However, in the end, you can deploy the same code to an embedded microcontroller using the LabVIEW Embedded modules.
With LabVIEW Embedded, you can take the algorithm that you developed for the CompactRIO controller and move to a smaller or more cost optimized solution while maintaining the software investment from the prototyping phase. This not only proves more efficient, but it also help eliminate the bugs that are introduced when an embedded developer converts prototyping code to actual embedded C code.
In conclusion,