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:

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.

No comments: