Linux Bluetooth Starter

Jürgen Stuber has a cool little tutorial showing how to receive a bluetooth transmission of data from the NXT brick to a Linux box.

Making your own digital sensors

Michael Gasperi made a homebrew digital (I2C slave) sensor. Creating digital sensors typically requires either some hardware which supports I2C communication, such as PCF8574 digital port expander, or a microcontroller like the Microchip PIC. The later alternative is the most versetile, allowing using all the microcontroller features to interface with the NXT. These include digital input/output, analog input/output, UART (i.e. RS232, needed for instance for most GPS/GSM modules) etc. The pitfall, however, is that one need to program the PIC to behave as a proper “I2C Slave”. In this dedicated page Michael explains how to do this efficiently.

NOTE: Sivan Toledo did a similar job with the TI MSP430 family chips. Take a look here.

More on HiTechnic IRLink and PF

As I posted a few days ago, the new HiTechnic IRLink (which should be available from HiTechnic in about a week) opens up new opportunities for controlling extra motors with the NXT. The IRLink sensor (i.e. it connects in a sensor port) allows the NXT to control the new RC LEGO trains, control the RCX (like the RCX IR Tower did) and control the new Power Function motors. The new PF motors, which are available in 2007 kits like the LEGO Creator Dinosaur (1 medium and 1 large motor) and the 8275 Technic Bulldozer (2 medium motors, 2 large motors) have their own battery box (a conversion cable for directly connecting to the NXT is supposed to be released soon) and can connect either directly to the battery box or via a special IR receiver. The IR receiver allow controlling the PF motors via a special remote control, also available from LEGO in the above mentioned kits.
So, back to the IRLink from HiTechnic. Since each IR receiver control 2 motors (let’s call them motor 1 and motor 2) and can have 1 of 4 ‘channels’, you can operate up to 8 PF motors using one IRLink. Notice, however, that the current needed will probably require more then 1 battery box for 8 motors running in parallel…. HiTechnic will release 3 special NXT-G blocks for the IRLink - one for RC Train system, one for RCX communication and one for controlling PF motors. In the rest of this post I am going to discuss the later block.
Before we go off - a short reminder. When you wire one of the regular NXT servo motors, the simplest program I can think of is ‘run motor until I press orange button’. Below is an NXT-G program that does just that:

Quite simple, isn’t it? So, when I first got my IRLink connected to my NXT (after importing the NXT-G block from HiTechnic) I dropped the block on my diagram and made this program:

the control panel for the PF block is shown below

As you can see, I asked Motor 1 to move ‘Forward’ and then had a ‘Wait for Button Press’. Eagerly I ran the program and to my great disappointment the motor rotated for a short moment and then stopped. The program, however, was still running until I pressed the orange button.

What happened? Well, here’s the catch. The IRLink acts just as the Remote Control does. When you want a PF motor to move forward you move one of the RC joysticks up and hold it until you want it to stop. If you press forward for a short period and then release the knob, the motor would rotate for a short period - just like what happened in my first program.

What should be done? If you want a persistent motion, you should put the PF block in a loop. You must also make sure that executing the rest of the loop does not take too much time, else the motion will be jerky. My second program is shown below:

now the motor rotated continuously as I expected. As this block’s behavior is quite different then the concept of ‘Move Unlimited’ block, this may be a cause for some confusion at first.

Remember - when in doubt about how to use IRLink for controlling PF motors, think in terms of how you would have done the same with the manual PF Remote Control. I am having great fun with these motors….

Guy Ziv

NXC Tutorial

Daniele Benedettelli published a nice tutorial on NXC. You can download it from NBC/NXC website or directly here.

NXT Constructopedia - Beta 2

A useful resource for individuals and educators alike. It explains and give building instructions for various NXT/motors attachments, swirling/sliding fronts, few simple projects and a nice quick start car.

Download it here.

NXT Memory and File System Organization

Here’s a little bit more technical information on the LEGO Mindstorms NXT file system and memory.

The main processor on the NXT is an ARM7 RISC CPU equipped with 256K bytes of flash memory and 64K bytes of RAM memory

Sector size on the flash memory is 256 bytes. There are hardware commands to erase either a single sector or all sectors at once. The “erase” and “write” command operates on a complete sector in flash.

The NXT firmware is loaded into flash memory starting from the front. The “leftover” flash (about ~128K) at the rear is used for the NXT’s file system

The last sector in the flash contains the file system “table of contents” (TOC). It is a 64 element array of pointers. Each pointer is either NULL or the starting address of the first flash sector of a file. Since the TOC is only one sector long, the NXT file system is limited to 63 files total. One of the “pointers” is used to contain some flags.

Flash memory is specified to support 10K write cycles. It might be worrisome that the TOC is written so often that this will be exhausted in a year or two of heavy use (two rewrites per file download!). Fortunately, (1) the spec appears to be extremely conservative and (2) the most common failure mode is the flash will simply not retain its contents for the full 10 years in its design spec.

The first few bytes of a file contain system information about the file – like its name – and access to these bytes is normally hidden from user programming.

(more…)

NXT Sensors Primer

Short tutorials on the NXT sensors from the LEGO Education site

NXT-G Tutorial

NXT Online Tutorial by the Oregon Robotics Tournament and Outreach Program

RobotC and Debugging

Here’s something I got from Dick Swan, the developer of RobotC:

Debugging your programs is always a challenge on the NXT. ROBOTC is one of the few programming solutions for the NXT that offer a traditional run-time “debugger” capability. It’s usually a lot easier to correct programs with a debugger rather than manually inserting “print” or “display” statements in your program to try to figure out what’s wrong.

The capabilities of a run-time debugger can be shown using the ROBOTC solution. The PC screen shot above illustrates several of debugger features

With the ROBOTC debugger you can:

• Start and stop your program execution from the PC
• “Single step” through your program executing one line of code at a time and examining the results (i.e. the values of variables) the flow of execution.
• Define “breakpoints” in your code that will cause program execution to be suspended when they are reached during program execution
• Read and write the values of all the variables defined in your program
• Read the write the “values” of motors and sensors as your program is executing.
• Remote the NXT LCD and buttons to your PC desktop.

For more details on the features of the ROBOTC debugger, open this file.

PERSONAL NOTE: The free NXC/NBC also has a real-time debugger. But they have different feature sets and capabilities. Maybe John Hansen can shed more light on this issue?

Taking pictures of your NXT creations

Dave Parker made this wonderful page with instructions on taking quality pictures of LEGO NXT creations. There’s a quick and simple page for kids, and mor elaborate page for those with more patience.. Thanks Dave!

Technic Pins

Jim German posted this article describing the different pins in the NXT set, and what they are (usually) good for.

Ultra Sound Sensor goes PING, PING…

One of simplest, yet quite cool, stuff you can do with the I2C Write block is work with your US sensors in “ping” mode, i.e. measure distance by command instead of continous operation. Let’s look at the following sample NXT-G program (click to expand):

The first US Block initializes the US sensor (i.e. set’s the sensor to LOWSPEED_9V and RAWMODE), and performs a read call. Since this is the first read call in the program, it also sets the sensor to work in continous mode. Any other US sensor blocks afterwards DON’T do either of these operations, only read from the US sensor ‘measurement 0′ byte (i.e. distance of closest object). The first time the I2C Write in the loop is called it turns the sensor to work in ping mode, ping once and store the measurements (the US sensor measures the 8 closest distances each time, see below). Next times, it just tells the sensor to ping. You can use the “regular” US Sensor block to read the last distance stored. Try changing the time delay on the Wait block and see how this works. The last I2C block returns the sensor to the “regular” mode, just to be extra safe…

Now for something more exciting - as I said the US sensor measures 8 distances. The US Sensor block gives access only to the first (closest) object. Extending the previous program we now use the I2C Read to read and display the remaining 7 distances:

Last, but not least, we can now work with two US on the same NXT with alternating pinging. First we should set both sensors:

and then we loop, pinging both sensors (a delay between sensors may be needed to allow echos die out before second sensor fires, in my tests it didn’t show any effect) and showing measurements:

Ultrasonic Acoustic Sensing

A nice explanation on ultrasound sensing, with details on implementation and limitations in the RCX version.

Using Visual Basic to control NXT

Michael Gasperi has a good step-by-step tutorial on controling the NXT from Visual Basic here.