Final description of our project

As the result of the course we developed a remote control system of the Lego MINDSTORM NXT robots from a mobile phone. We used Spike standard model of NXT as a robot to be controlled and Nokia 6233 as a remote controlling device, but we tried to write universal application which can be used with minor changes to control any NXT robot using any mobile devices with MIDP2.0 and JSR82 (Bluetooth API) support. We used LeJOS as an operating system for our NXT device which allowed writing both parts of the system using Java language.
The main features of our system are:
An ability to control any robot motors.
An ability to subscribe a phone to receive data from any robot’s sensors in real-time mode.
One can make robot to play some sound while executing any command.
Simple Bluetooth protocol. Almost all commands are described by one or two bytes.
Easy expandable for any other NXT robots.
The portability was our main goal. As I already told in my blog, we have very simple set of commands. For instance, all movements of the robot are performed by the following command pair “rotate/stop motor”, “motor index”. All command constants are stored in NXTCommand class both at mobile phone and in the robot. By using this pair one can increase forward motor speed (motor will start rotating forward if it is stopped or will slow down if rotates backward); do vice versa (increase rotating backward); stop rotation of a motor; rotate any motor to any desired angle forward or backward. Mobile phone application has a set of such small commands mapped to each number key. So, for instance when controlling Spike robot, if you press key 2 (it means forward) phone will send two commands: increase forward speed of motor B and increase forward speed of motor C. If you press pound button (it is a tail kick) phone will send 3 commands: rotate motor A to a certain angle forward, wait a little bit and rotate motor A to a certain angle backward.
Thus, if you want the application to control other type of NXT robot all that you need to change mappings of commands to the buttons in mobile phone application. Also adding a new type of command is not very challenging. You just need to keep in mind those limitations of LeJOS which I described earlier.

The second big feature except control of motors is an ability to receive data from sensors to a mobile phone. This is done in three steps (see our final presentation at Evgenia's diary). First of all when a user enters Sensors menu, phone sends request to a robot asking what sensor types it has. Robot sends back 4 sensor types in the order in which those sensors are connected to the sensor ports (Sensor from port 1 goes first, then goes sensor from port 2 and so on). Mobile application shows a menu to a user where he can choose which sensors he wants to receive data from. After user presses OK button, phone sends a request to subscribe for a certain sensor’s data. Robot handles this request by starting a new thread which monitors sensor values and sends them periodically to the phone.

Unfortunately our robot can not detect by itself which sensors it has (it is probably possible but we had no enough time to implement it), so sensor types should be manually changed in robot’s application code when porting it to another robot type. Also we have implemented listeners only for 3 types of sensors: ultrasonic, touch and sound sensors, because it is all that Spike has. But new listeners can be easily implemented by analogue with other ones just in few minutes.

About disadvantages of the system: Bluetooth channel is very unstable and sometimes some data is lost during transmission. This problem begins very relevant, when robot is moving and spends a lot of power for the motor rotation. So when you want to subscribe to some sensor, stop the robot and do not keep you mobile device far from your robot. Sometimes even some critical exception can be thrown because of broken connection or lost data. There is no graceful handling of broken Bluetooth connection neither in robot application nor in mobile phone. Also, robots application has no exit point. It is done so, because LeJOS doesn’t support correct exit from any program and it is just restarts in order to finish a running application.

The thing that could be added to this system is a separate thread for some own robot’s logic execution. For instance, this thread could contain code which would prevent robot run into an obstacle even if a user intentionally gives to robot such commands. Or robot could make some action by itself if user doesn’t send any commands for a certain period of time (for instance play some yawn sound).

Source code and binaries you can take from here.