Thank you for your comments. It seems you’ve got a little version mix-up.

The toolbox 2.03 (and 2.04) uses MotorControl.rxe. The version displayed on your NXT screen should be MotorControl 1.1 (or 1.2). With this toolbox, you need to have the LEGO MINDSTORMS NXT Firmware version 1.05 installed.
So far so good. The motor class in this version is called NXTmotor (note the lowercase m). Motor precision and performance is alright, but not great.

The warning you describe (no reply time out in .WaitFor) has only been introduced in toolbox version 4.00. This version offers far better motor control. For this version, MotorControl20.rxe is required. It’s called this way intentionally by COM_OpenNXTEx to distinguish from previous versions (so renaming files doesn’t help). In order to compile MotorControl20.nxc, you need nbc.exe from the very latest version from BricxCC, included in the file test_release.zip, found here: http://bricxcc.sourceforge.net/
You can also find the MotorControl20.rxe binary here: http://www.mindstorms.rwth-aachen.de/trac/browser/trunk/tools/MotorControl/MotorControl20.rxe

Please note that MotorControl 2.* needs the newest LEGO MINDSTORMS NXT Firmware. Either 1.26 (comes with NXT-G Education 2.0), 1.27 or 1.28 by John Hansen (included in the mentioned test_release.zip from BricxCC) or 1.28 (comes with the new NXT 2.0 retail building kit).

So please don’t mix up different versions of the toolbox with different versions of MotorControl. Always take the MotorControl version which comes with the according toolbox zipfile. You can find out the toolbox you’re using (set in the MATLAB path) by typing:

info = ver('RWTHMindstormsNXT')

With toolbox 4.00, the motor class is called NXTMotor (uppercase M) by the way.

So I hope I’ve clarfied eveything. The high pitched beeping noise you describe is intended. It’s the NXT’s synchronization. It should be mentioned somewhere inside the chapter “Troubleshooting” of the toolbox documentation I believe. I’ve also added a description of this “feature” in the new documentation for future version 4.01. It keeps the motors in sync, useful for straight driving. It can be disabled using .Stop or .StopMotor.

The next toolbox release 4.01 is scheduled for next week. With this release we’ll also officially support Mac OS. The motor control in 4.00 (beta) works ok, we fixed some minor issues for 4.01, but overall 4.00 is pretty stable and should be well usable.

Don’t hesitate to ask further questions. Keep watching http://www.mindstorms.rwth-aachen.de for future versions, and feel free to open a ticket with feature requests or bug reports if needed.

Regards, Linus

I am using version 2.03 of the RWTH - Mindstorms NXT Toolbox on a MacBook and Matlab 7.6. I am able to communicate via bluetooth. I can play a note and read from the sensors. I am having trouble with the motors. I have uploaded the MotorControl.rxe file to the NXT.

If I run

handle = COM_OpenNXT('bluetooth.ini');

the MotorControl.rxe program on the NXT is executed.

If I then run

COM_SetDefaultNXT(handle);
m = NXTMotor('A', 'Power', 50, 'TachoLimit', 1000);
m.SendToNXT(handle);
timedOut = WaitFor(m, 5);

I get the following warning:

Warning: There has been no reply (time out) for at least 5 seconds from the
embedded NXC program MotorControl, which should be running on the NXT
brick. Please make sure the program is running and does not get terminated
accidentally. Exiting WaitFor() and continuing...
> In NXTMotor.WaitFor at 168

Coincidentally, the file COM_NXTOpenNXTEx.m was using MotorControl20.rxe instead of MotorControl.rxe. I changed this in the m-file back to MotorControl.rxe. No luck. Next, I left the MotorControl20.rxe in the m-file and changed the name of the file on the NXT. That didn’t work either. I tried this because I wasn’t sure which m-files actually use the filename on the NXT.

I have used the DirectMotorCommand to get the motors to turn. The motors don’t rotate to the programmed value. Also, the NXT makes high-pitched noises afterwards until I turn the NXT off.

I’d like to use the NXTMotor functions rather than the DirectMotorCommand function.

Any advice for me?

Thanks,
Michele

I’d like to respond to some issues brought up in the comments here:

Bluetooth
Not all Bluetooth adapters you can buy work equally well with the NXT or with MATLAB. We tested some, and here’s the (incomplete) list as a guide:
http://www.mindstorms.rwth-aachen.de/trac/wiki/BluetoothAdapter

Motor precision
Since version 2.03 of the RWTH - Mindstorms NXT Toolbox, a way for better precision is provided. While the official NXT firmware (and previous toolbox versions) don’t provide a way to rotate a motor to a precise angle with a single command (like e.g. 90 degrees and then stop), we added this feature by a program running on the NXT simultaneously. So give version 2.03 a try and use the NXTmotor class.

Even better motor control is added with the latest version 4.00 (beta), only 10 days old :-). While it might be unstable, first results show a really great way to control motors accurately (the class is now called NXTMotor). Try out the latest version and see if it works for you:
http://www.mindstorms.rwth-aachen.de/trac/wiki/Download

Gyro Sensor
Make sure to use either version 2.04 (of the RWTH - Mindstorms NXT toolbox) or the beta 4.00, as version 2.03 has limited support for the Gyro sensor (no good calibration, only 1 sensor allowed) which is fixed in later versions.

I assume you are referring to Bluetooth interface.

You can get both the gyroscope and accelerometer data using the RWTH Aachen Mindstorms NXT Toolbox (see the GetAccelerator and GetGyro functions).

Getting the time information is tricky. With the Bluetooth interface, it is difficult to get the time at which the gyro or acceleration value was sensed. The simplest solution is probably something like the following:

  % This example uses the RWTH Aachen Mindstorms NXT Toolbox
  tic; % start of measurement
  OpenGyro(SENSOR_1);
  for i=1:100
    sensorValue(i) = GetGyro(SENSOR_1);
    timeStamp(i) = toc;
    pause(0.1);
  end
  CloseSensor(SENSOR_1);

Gautam

If you want to control the LEGO NXT from MATLAB using Bluetooth, there is NO need to change the standard firmware.

If you want to generate an executable that will run autonomously on the LEGO NXT (using the Simulink-based library) then you will need to change the firmware (the library comes with instructions for how to do this). Updating the firmware — and switching back to the standard firmware — is usually pretty safe, and is common in many LEGO NXT programming environments.

Gautam

Regards,
Dhruba

Gautam

You can use the RWTH functionality from Simulink. I will go through the example with the MATLAB toolbox from my post, but you can use the same approach for the RWTH toolbox functions.

Step 1: in MATLAB set up the connection to the LEGO NXT and configure the sensors:

 lego = legoNXT('COM40');
 mySensor = lego.Port1;
 set(mySensor, 'Type','Touch');
 leftMotor = lego.PortA;

Step 2: To read the sensor in Simulink, add a “MATLAB Fcn” block to your model. For the MATLAB expression, enter “getdata(mySensor)”. Wire the input port of the MATLAB Fcn block to Ground. You can group the Fcn and Ground blocks as a subsystem that pumps out sensor values.

Step 3: To control the motor in Simulink, add another “MATLAB Fcn” block. For the MATLAB expression, enter ” setMotorPower(legoMotor,u)”, where setMotorPower is the following MATLAB function:

function out = setMotorPower(motorObj, powerValue)
  set(motorObj, 'power', powerValue);
  out = 0;

(You need a separate function because the MATLAB Fcn block requires an output, but the SET command doesn’t return one). Finally, wire the output port of the MATLAB Fcn block to a terminator. You can group the Fcn and terminator blocks as a subsystem that accepts a motor power setting. You can create another such subsystem for starting/stopping the motor.

Step 4: Configure your model (using the “Configuration Parameters …” dialog box) to use a Fixed-step discrete solver. Now, you need to run your model in real time rather than simulated time (for example, you want to poll the sensor every 200 msec or so). To achieve this, you need a block which forces the simulation to match elapsed time. If you have the Aerospace Blockset, you can use the “Simulation Pace” block. Otherwise, try the following submissions in the MATLAB Central FileExchange:
Pseudo Real Time in Simulink
Real-Time Blockset 7.1 for Simulink

You can improve this lots of ways, of course. For example, you can mask your “read sensor” and “set motor power” subsystems and allow the user to specify different sensor/motor ports. Or, you can include the the initialization code as part of another MATLAB Fcn block. But the above steps should be sufficient to get you started.

Gautam