Showing posts with label nxt. Show all posts
Showing posts with label nxt. Show all posts
Monday, August 30, 2010
Tutorial on Building a Thermostatic Sensor for your NXT
In this video, I take you step-by-step through the process of creating a thermostatic sensor for your NXT. Enjoy!
Saturday, August 14, 2010
Customizing the GUI
I have been asked how to change the GUI’s connect panel to change the name and Bluetooth address of the NXT or NXTs you want to connect to.
In the ConnectPanel.java file, you need to change these two lines of code:
In my particular case, my NXTs are called MONTE and Wayfinder; their Bluetooth addresses are 00:16:53:00:57:37 and 00:16:53:08:82:3a respectively.
For example, if your NXT is called Delta with a Bluetooth address of 00:16:53:00:00:00, then the two lines of java code should read:
Thank you for your feedback.
In my next posts, I’ll show you how to change the NXT’s map, and how to build the robot in Lego.
In the ConnectPanel.java file, you need to change these two lines of code:
private static final String[] _robotNames = {"MONTE", "Wayfinder"};
private static final String[] _robotAddresses = {"00:16:53:00:57:37","00:16:53:08:82:3a"};
For example, if your NXT is called Delta with a Bluetooth address of 00:16:53:00:00:00, then the two lines of java code should read:
private static final String[] _robotNames = {"Delta"};
private static final String[] _robotAddresses = {"00:16:53:00:00:00"};
Thank you for your feedback.
In my next posts, I’ll show you how to change the NXT’s map, and how to build the robot in Lego.
Saturday, February 7, 2009
The Reason for not Blogging Lately
I have been unable to blog lately because I have been away. However, I will soon be back to my normal routine. Once I'm back, I'll be blogging once again on LEJOS: Programming the NXT in Java.
Monday, January 12, 2009
Localization Video
Here is a video from an unrelated MCL project. I am posting it so that you can see the basic idea.
Saturday, January 10, 2009
Test my New Program
Over the next few days, I'm going to be testing my new Monte Carlo Localization (MCL) application on different kinds of enclosures I want to see if the algorithm can handle different situations, localizing the robot correctly within the enclosure. Once I have some results, I will share them with you.
Sunday, January 4, 2009
The Communication Protocol
In communicating with the NXT robot, we want to keep our communication protocol as simple as possible. Through simplicity, the PC can direct more of its attention to the problem of Monte Carlo Localization (MCL), and less of its time on Bluetooth connection. The PC sends its command in the form of three integers. The first integer is the command itself, an integer from 0 to 4. The two integers that follow the command are optional parameters.
The robot’s reply is always eight integers. We need eight integers to accommodate the eight echoes that we obtain from the ultrasonic sensor.
There are five cases to consider:
The responsibility for sending the command to the robot and receiving a reply from it is shared between the Event Handler and BTCommPC classes. Upon detecting that an action event has been fired on the GUI, it is the Event Handler’s responsibility to gather the necessary information, compose the three-integer command and pass a reference to the integer array to the BTCommPC class. BTCommPC is responsible for sending the command one integer at a time to the robot and await a reply. Once a reply starts being sent, BTCommPC reads each integer, one at a time, placing them in an eight-integer array. BTCommPC then passes a reference to the array to the Event Handler.
Once the Event Handler receives a reference to the reply array, it is handler’s responsibility to disseminate it. Usually, this involves passing values back to the GUI panels and passing the ultrasonic sensor readings to the MCL class so that the MCL class can update its statistics. This command/reply process continues until the user requests that the Bluetooth connection be terminated either explicitly by pressing the disconnect button, or implicitly by terminating the program.
The robot’s program is complementary to BTCommPC’s algorithm. At first, the robot waits for a Bluetooth connection. Once a connection is made, it waits to receive its three-integer command. Once the command is received, the robot moves or turns, if necessary, and then sends back its eight-integer reply one integer at a time. The robot then waits for its next command. If the robot is commanded to terminate its Bluetooth connection, the robot sends back its acknowledgement, disconnects, and its program terminates on the brick.
More implementation to come.
The robot’s reply is always eight integers. We need eight integers to accommodate the eight echoes that we obtain from the ultrasonic sensor.
There are five cases to consider:
Description: The user requests the battery voltage
Command 0, 0, 0
Reply millivoltage, 0, 0, 0, 0, 0, 0, 0
Description: The user asks for the ultrasonic sensor to ping and report back
Command 1,0,0
Reply A series of 8 integers being the echo values
Description: The user requests that the robot move forward/backward
Command 2,distance,speed
Reply A series of 8 integers being the echo values
Description The user requests that the robot turn left/right
Command 3,angle,speed
Reply A series of 8 integers being the echo values
Description The user requests that the Bluetooth connection be terminated
Command 4,0,0
Reply 255,255,255,255,255,255,255,255
The responsibility for sending the command to the robot and receiving a reply from it is shared between the Event Handler and BTCommPC classes. Upon detecting that an action event has been fired on the GUI, it is the Event Handler’s responsibility to gather the necessary information, compose the three-integer command and pass a reference to the integer array to the BTCommPC class. BTCommPC is responsible for sending the command one integer at a time to the robot and await a reply. Once a reply starts being sent, BTCommPC reads each integer, one at a time, placing them in an eight-integer array. BTCommPC then passes a reference to the array to the Event Handler.
Once the Event Handler receives a reference to the reply array, it is handler’s responsibility to disseminate it. Usually, this involves passing values back to the GUI panels and passing the ultrasonic sensor readings to the MCL class so that the MCL class can update its statistics. This command/reply process continues until the user requests that the Bluetooth connection be terminated either explicitly by pressing the disconnect button, or implicitly by terminating the program.
The robot’s program is complementary to BTCommPC’s algorithm. At first, the robot waits for a Bluetooth connection. Once a connection is made, it waits to receive its three-integer command. Once the command is received, the robot moves or turns, if necessary, and then sends back its eight-integer reply one integer at a time. The robot then waits for its next command. If the robot is commanded to terminate its Bluetooth connection, the robot sends back its acknowledgement, disconnects, and its program terminates on the brick.
More implementation to come.
Friday, January 2, 2009
Efficient Programs and Button Listeners
In my blog on January 1st, I explained how the RConsole class can be used to easily send output from the NXT brick over a Bluetooth connection to your PC. However, the program has a deficiency. The escape button must be pressed and held for the program to stop.
True, the while loop is terminated whenever the brick’s escape button is pressed. But, after reading the raw and processed values of the Electro Optical Proximity Detector (EOPD) and printlning those results to the RConsole, the loop pauses for five seconds. This pausing means that the escape button’s state is checked approximately once every five seconds at the top of the while loop.
So, to stop the program, the user has to press and hold down the escape button until the while loop has an opportunity to read the button’s state. Pressing and releasing the escape button is insufficient. If the escape button is in the released position when the while loop checks the button’s state, the while loop will execute again even though the button might have been pressed and released when the loop was paused.
This problem is best solved by using the ButtonListener interface. The interface has two methods: buttonPressed(Button b) and buttonReleased(Button b). Once a button has been registered with a listener, these methods fire whenever the button is pressed or released, as the case may be. Furthermore, these methods fire regardless of what other things the program might be currently doing.
In the new version of the program, given at the end of this blog entry, the while loop is now controlled by a boolean variable, keepItRunning. The variable is initialized to true. The program implements the buttonPressed method such that it changes the keepItRunning variable to false. Although we are not explicitly using the buttonReleased method, we are obliged to implement it because it is part of the ButtonListener interface. So, we give the buttonReleased method an empty implementation.
The program line Button.ESCAPE.addButtonListener(this); registers the escape button with a listener. The this keyword indicates that the buttonPressed and buttonReleased methods are implemented in this class. (It is possible for the methods to be in another class; so, the addButtonListener method must know where these methods can be found.)
To try this new idea out, upload this program, as given below, to your NXT and start it running. Now, get your nxjconsole running from a command prompt. The program works in exactly the same way as described in my January 1st post. However, if the escape button is pressed and released, the program will end after its five-second pause. The program ends because the pressing of the escape button fires an event, which in turn calls the buttonPressed method. That method changes the keepItRunning boolean variable from true to false. The while loop ends because the while loop will only run as long as keepItRunning is true.
What follows next is the code for EOPDSensor2:
True, the while loop is terminated whenever the brick’s escape button is pressed. But, after reading the raw and processed values of the Electro Optical Proximity Detector (EOPD) and printlning those results to the RConsole, the loop pauses for five seconds. This pausing means that the escape button’s state is checked approximately once every five seconds at the top of the while loop.
So, to stop the program, the user has to press and hold down the escape button until the while loop has an opportunity to read the button’s state. Pressing and releasing the escape button is insufficient. If the escape button is in the released position when the while loop checks the button’s state, the while loop will execute again even though the button might have been pressed and released when the loop was paused.
This problem is best solved by using the ButtonListener interface. The interface has two methods: buttonPressed(Button b) and buttonReleased(Button b). Once a button has been registered with a listener, these methods fire whenever the button is pressed or released, as the case may be. Furthermore, these methods fire regardless of what other things the program might be currently doing.
In the new version of the program, given at the end of this blog entry, the while loop is now controlled by a boolean variable, keepItRunning. The variable is initialized to true. The program implements the buttonPressed method such that it changes the keepItRunning variable to false. Although we are not explicitly using the buttonReleased method, we are obliged to implement it because it is part of the ButtonListener interface. So, we give the buttonReleased method an empty implementation.
The program line Button.ESCAPE.addButtonListener(this); registers the escape button with a listener. The this keyword indicates that the buttonPressed and buttonReleased methods are implemented in this class. (It is possible for the methods to be in another class; so, the addButtonListener method must know where these methods can be found.)
To try this new idea out, upload this program, as given below, to your NXT and start it running. Now, get your nxjconsole running from a command prompt. The program works in exactly the same way as described in my January 1st post. However, if the escape button is pressed and released, the program will end after its five-second pause. The program ends because the pressing of the escape button fires an event, which in turn calls the buttonPressed method. That method changes the keepItRunning boolean variable from true to false. The while loop ends because the while loop will only run as long as keepItRunning is true.
What follows next is the code for EOPDSensor2:
import lejos.nxt.Button;
import lejos.nxt.LCD;
import lejos.nxt.SensorPort;
import lejos.nxt.comm.*;
import lejos.nxt.addon.*;
import lejos.nxt.*;
public class EOPDSensor2 implements ButtonListener{
private boolean keepItRunning = true;
public void buttonPressed(Button b){
keepItRunning = false;
}
public void buttonReleased(Button b){}
public void runProgram(){
Button.ESCAPE.addButtonListener(this);
RConsole.openBluetooth(40000);
LCD.drawString("Connected", 0, 2);
EOPD electroSensor = new EOPD(SensorPort.S1);
while(keepItRunning){
electroSensor.setModeLong();
RConsole.println(Integer.toString(
electroSensor.readRawValue()));
RConsole.println(Integer.toString(
electroSensor.processedValue()));
try{
Thread.sleep(5000);
}catch(InterruptedException e){
System.exit(0);
}
}
RConsole.println("Closing...");
RConsole.close();
}
public static void main(String[] args){
EOPDSensor2 programInstance = new EOPDSensor2();
programInstance.runProgram();
}
}
Wednesday, December 31, 2008
Important Links

Here are some very useful links to get information about programming the NXT in the Java Language:
- SourceForge From here, you can download the jar files as well as the brick's firmware to get you started programming in Lejos -- Java for the Mindstorms NXT brick
- Setup Tutorial From this website, you can learn how to properly set up your brick with the firmware, and correctly get Eclipse (a Java development environment) working properly
- Forum In this forum, you can communicate with other developers who use Lejos to program the NXT brick
Subscribe to:
Posts (Atom)