The GNAT GPL Ada development environment is a Free Software toolset targeting the FLOSS and Academic communities. The MINDSTORMS NXT port is maintained by AdaCore (www.adacore.com).

– Matteo Bordin bordin@adacore.com

Then send an application via email with a description of yourself, your involvement with LEGO MINDSTORMS, your special areas of interest, and a paragraph on why you are eligible to be an MCP member!

Send it to mindstormsnxt@lego.com with the header ‘MCP 4 application’.

Applications will be received from now and until 31 July 1200 GMT. All email applications received after this date will be rejected.

Applicants must be 18 years old to apply.

Lego Beyond Toys

Lego Beyond Toys 1

Lego Beyond Toys 2

Quite some time ago I wanted to give a brief tutorial about communication between an embedded program running on the NXT (for example written in NXC) and a computer. The reasons one would want to send data from an NXC program to a PC or vice versa can be divided into two main categories: Either the NXC program wants the computer to do things it can’t (complex calculations, look up information), or a computer program needs to tell an NXC program what to do (or which information to collect or log).

In the search for a good example I came across this idea: Wouldn’t it be great to show how the NXT could retrieve data from the internet (although the display is to small for a browser )? The first kind of data I could think of were weather forecasts (or current weather conditions). So here we are: This is how it looks if your NXT can show the current temperature and brief conditions of any place around the world (screenshot taken with J. Hansen’s tool NXTScreen).

Short description: The NXC program (client) can request weather conditions by storing a string in one of its mailboxes. The computer program (server, written in MATLAB) constantly looks for messages there via direct commands. If one is found the according weather conditions will be retrieved from the internet using the Yahoo! Weather RSS service. The most important data are extracted and sent back to the NXT (again by storing a string in a mailbox). The NXC program in term waits until a string can be read from the queue, parses it and finally displays city name, current temperature, and condition.

Left and right buttons cycle through multiple locations (i.e. cities); the orange center button toggles between Fahrenheit and Celsius mode! Interested? Read on!

The main requirements for bi-directional communication between an NXC program and a computer program are functions to send and receive strings. Once we have these, we can define our own protocol and send information back and forth. In NXC, we can use the function SendMessage() to store a string in a mailbox (let’s call this the NXC-Outbox for a moment, number 0 is fine). To retrieve strings from a mailbox (that have been put there by the computer), the function ReceiveRemoteString() works well. This time, we better use a different mailbox queue, e.g. number 1, and name it NXC-Inbox.

Half there! The NXC program can send and receive data, how about the PC side? We need some sort of program or library that supports direct commands (those are commands you can use to remote control your NXT; you can find more details in the Bluetooth Developer Kit). There are many implementations, good overviews are either this Wikipedia table or Steve’s comparison. Even more, we need to find a solution that already supports the direct commands MessageRead and MessageWrite (I’m saying this since some packages are still under development and don’t support the full set of commands). If not, those direct commands would have to be implemented (the Bluetooth Developer Kit has details about the format).

So let’s say we already have MessageRead and MessageWrite. These are the counter-parts of SendMessage() and ReceiveRemoteString() in NXC. We use MessageWrite to send a string to the mailqueue we called NXC-Inbox before (so the PC’s outbox is the NXT’s inbox). Just as well we use MessageRead to see if there’s something waiting for us in the NXC-Outbox (again, this would be the inbox from the PC’s point of view). If you get confused, don’t worry. Just remember that the computer has to receive what the NXT sends and the other way around.

Almost done. We have everything we need. We can send little “orders” (commands would be a better word) from the NXT to the PC, for example. Of course we have to define what those commands mean. The PC could see the incoming strings, react on them and send answers. This is what my weather demo does. I use Yahoo! Weather as actual source, so the program on the PC retrieves data from the internet (it’s actually data in the RSS newsreader format, the API details are described here).

As language I chose MATLAB (and the RWTH - Mindstorms NXT Toolbox, which I happen to be a developer of ). It provides the direct commands mentioned above, as well as a very easy-to-use built-in function to retrieve data from the internet. In theory the server could be implemented in any language. A detail I didn’t mention before is that we of course have to connect the computer to the NXT somehow. This can be a bit complicated if you want to use Bluetooth, it’s usually easier with USB, but always depends on your OS and hardware (as well as the programming package you use). With the MATLAB toolbox, you just have to plug in the USB cable or connect the Bluetooth dongle with the driver software, and you’re ready to go. Other packages are similar easy to use.

So finally, where is the sourcecode? Here’s the NXC client program, and here’s the MATLAB server program. If you don’t have MATLAB installed, this HTML version with syntax highlighting is easier to read. Both programs are heavily commented and can be used freely (GPL license).

If you just wanted to write a program that reacts on certain weather data (or whatever is available on a computer these days), you could have done this without an NXC program of course (just using remote control software like the MATLAB toolbox), resulting in a much simpler program. But then you’re in certain other ways limited (Bluetooth latency, or real time motor control for example). The way I documented it in this little tutorial, you could adapt the NXC program to work without a computer in range, and only use external data if they are available. The main point is that I wanted to illustrate some NXC-to-Computer communication.

So what do you think? What new kind of applications are possible? Any great ideas? If you did anything interesting, useful, or funny with this example, or have any other questions, please don’t hesitate to start a discussion in the forums!

Linus Atorf

To begin you are going to need a development board for an FPGA or microcontroller. I chose the Digilent (http://www.digilentinc.com) Nexys 2 board. It uses a Xilinx Spartan 3E FPGA. You will also want a bread board to develop the communications circuit. Digilent also sells I/O devices called PMODs. I got their servo motor interface PMOD. As a side note, all these components will work with a project for the RCX or NXT.  Finally you will need some resistors to build into the input circuit to keep from frying the FPGA.

Remember how I said digital systems work in pulses? Well these pulses are read every so often as defined by the system clock. For the RCX servo motor controller we have to have two clocks. Using verilog (a programming language for hardware) we can divide the clock into the two clocks we need.  Clock speeds can vary from servo to servo, but expect to program for 10 pulses per millisecond. The other clock will need to run at 10 pulses per second for the RCX. To write code in verilog, you will need a program from Xilinx that will allow you to create the file you download to the FPGA. For help regarding verilog, send me a PM. Wikipedia has good documentation, but once you begin to understand it, it is really easy.

Once you have your two clocks made, let’s work on the important part: the servo PWM. This is the real hard part. For this you are going to need to use one of your clocks (the faster one). You need to be able to control the 0’s and 1’s going to the motor. This can be done with a simple if statements. Again, exact times depend on the motor you choose!

Now you need to read the signal coming from the RCX. I uses eight clock counts (one byte) but you can work with different counts. You want to count up all the 1’s in your chosen cycle. Your code then needs to pass this to the PWM controller and have it decide on the time. That is it. Pretty simple right? Well, try and see. If you can master this fairly simple project (yet one that no one has tackled) then you are ready to work on the NXT!

This is how I approached the problem, and it sets you up for a good basic understanding of digital systems. Wikipedia and google are your friends. Once this all makes sense then you can begin to work on the NXT. I will say the I2C stuff for my next blog, but I think this will take you enough time!

–Andy Milluzzi

So how does this one work?  When the program starts, the robot checks its current heading and makes this its Set Point.  Any change in the position of the spinning platform will cause the robot to rotate as well, thus changing its heading.  The difference between the new heading and the Set Point is the error.  Using the PID control a response is calculated and actuated by the motors.  If the platform is rotated slowly, the robot will in turn only pivot slowly about its axis.  However, if you give the platform a nice spin, the robot will speed up its motors and try to keep up.

You can download the RobotC source code from here: [LINK].  Make sure you calibrate the compass and mount it as far from the motor and brick as possible (at least 15 cms) due to magnetic interference.

While all the theory is one thing, I wanted to see how the sound sensor reacts on tones of different frequencies in reality. And what would be easier than to use the NXT’s built-in speaker? You can use it to produce a tone of a given frequency (for example with the direct command PlayTone), and then record the sound pressue with the sound sensor. That is exactly what I have done (the MATLAB script can be found here), and here are the results:

Now this looks interesting! It shows how the sound sensor determined different volume levels for different frequencies, whereas the actual volume of the speaker was not changed. Since two unknown devices where used in this test (the NXT’s sound sensor as well as its speaker), we cannot know where exactly this behavior comes from. And as I mentioned above, measuring sound pressure levels is a complicated thing, which is why it is hard to say (for me, at least) how the curve should look in an ideal world. But we can analyze the data a bit further without having to worry too much about exact acoustics.

With dBA units one tries to account for the fact that different frequencies are perceived as having a different volume by the human ear. There are different weightings, the following picture shows the case for dBA (taken from this site):

As you can see, the human ear perceives tones between 1kHz and 10kHz as the loudest ones. To see what the sound sensor does when returning the data in either dB or dBA, I simply divided dBA by dB values to see their relative amplification:

The shape of this curve is not quite similar to the one we expect (note the different axes in the two plots). There is no real conclusion that can be drawn here, at least not with more tests…

So what is the use of these new insights (if any)? First of all, we have a picture of the difference between dB and dBA modes. Apart from some aspects of the NXT speaker one could discuss (but I will not do this right now), we know that the sound sensor picks up different tones with different readings. Unfortunately, the sound sensor reading is also influenced by its distance from the speaker. What we could use however are relative volumes of different tones.

Maybe this way multiple NXTs could communicate with each other via beeps, independent from their distance (i.e. from the absolute volume of the beeps). I imagine a certain beep-code being sent, something like a sequence of tones with different frequencies. The sound sensor could record the according sound levels of the tones, and calculate the ratio between them. If everything goes well, this ratio should stay fairly constant and enable transmission of information.

I am going to investigate this idea further some time in the future. Another thing on the to-do-list would be to repeat the described experiment, but this time with different (better) speakers…

– Andrew Milluzzi

Hi everybody! I’m Linus Atorf, a 25-year-old physics student from Aachen, Germany. I’ve been working with LEGO Mindstorms for 2 years now, since I joined the Insitute for Imaging and Computer Vision at RWTH Aachen University. There I’ve helped developing the RWTH - Mindstorms NXT Toolbox for MATLAB from scratch. Since 2007, every year almost 400 students (field of study Electrical Engineering, Information Technology, and Computer Engineering) work with 200 NXT sets during a full-time laboratory course lasting 8 days [1]. The lab is used to teach the first-year students (about 20 years old) programming in MATLAB, mathematical methods and of course teamwork skills, while hopefully having some fun with LEGO robots. Most of the time I’m working with MATLAB, but recently I also began to enjoy NXC. During my work I occasionally stumble upon interesting NXT-related things I’d like to share - or I could show you some of the impressive robots our students build (like this tic tac toe playing bot [2])…

[1] http://mindstorms.lfb.rwth-aachen.de/index.php/en
[2] http://thenxtstep.blogspot.com/2008/12/tic-tac-toe-playing-nxt.html

Nils Voelker sent me an email on this NXT creation he made. It was a part of an art and design exhibit in Netherlands. The exhibit had images of objects such as an apple or a chicken, an eye-tracker followed the observer and recorded the points on the object he looked at, and this ceiling-mounted NXT made spots on a piece of paper recording these points. See more pictures and videos on Nils site here.