Technical information regarding the Handyboard and the communications protocol used by this software

Packet format:

[Preamble | Source ID | Destination ID | Packet ID | Opcode | Length | Data | CRC]

1. Preamble

This is used to signify the beginning of a packet, rather than noise.

2. Source ID

The ID of the source of the packet.

3. Destination ID

The ID of the receiving end of the packet.

4. Packet ID

The ID of the packet. Multiple packets that are part of large data will have incremental packet IDs.

5. Opcode

An operation/instruction to be carried out. The opcodes are listed in opcodes.txt

6. Length

If Opcode is Header packet:

Length = The number of packets to follow for the following data

otherwise:

Length = The length of the packet Data section (does not include the CRC)

7. Data

The data for the packet.

8. CRC

The CRC error correction value. This is a CRC check for all the data in the packet including the header information.

General communications protocol:

Handshake:

The server will perform a handshake with each robot in broadcast range. During this step, any important information about each robot will be obtained, including the robot's buffer size, and sensor arrangement.

Packet Transmission:

Server to robot:

The server will not send a packet of any size larger than the robot's buffer size. The server will wait for an acknowledgement of each packet before sending the next. This will ensure that the robot has plenty of time to clear its buffer. The server has to follow this stop-and-wait protocol because all the robots are on the same frequency. If one robot receives a packet, they all do, but only the robot that has the same ID as the Destination ID will parse the packet. Typically, the server will not send large data packets to the robot; rather it will send short commands and data.

Robot to server:

The robot will not have any real restrictions on the size of a packet. Since the server is typically much faster than the robot, it is able to parse each packet as fast as it is sent. Even though each robot in broadcast range will pick up the transmission from another robot, the packets will be ignored if the Destination ID does not match, even if the buffers overflow.

Robot to Robot:

A robot will not be able to send a packet any larger than the buffer size of the receiving robot. This information can be requested from the server. This mode of communication is best done through the server, since direct robot-to-robot communication would interfere with the communication of the server and other robots. Direct robot-to-robot transmissions are still possible, simply by specifying the receiving robot's ID as the Destination ID. In this case, the server should be notified.

Update:

The server will periodically send out requests for new robots in the range of transmission. Each robot will respond with a random delay, and the first robot to respond will be added next. If the server does not receive any responses from a given robot after a certain amount of time, the server will drop that robot from the list. That robot would then have to be added back when the server requests new robots again.

Data compression:

Since the Handyboard has limited processing power and memory, all data has been limited to one-byte units. The resulting decrease in data resolution is not very significant in terms of the needs of the Handyboard.

Representing a floating point measurement with one byte:

A byte can represent 255 values, so measurements that are of floating data can be truncated to a certain precision given a limited range.

For this example, a resolution of an 8th of an inch will be used.

Let resolution = 8 (number of divisions per inch)

Let max range = 255/resolution = 255/8 = 31.875 inches

Let m = measurement clamped between 0 and 31.875 inches

Let byte_value = (int)(m*8)

Any byte_value of 255 can be interpreted as being out of range. Therefore, the actual range of valid readings is between 0 and 31.75 inches (byte_value 0 to 254). This distance of 31.75 inches is plenty for most short range uses of the Handyboard sonar. If the resolution were decreased to a quarter of an inch, max range would be 63.75 inches.

Opcodes:

The following is a list of opcodes that are currently defined (but not necessarily implemented)

Opcodes: Description:

0 = No Op No instruction in this packet - just data

* 1 = Header packet Contains the number of following packets

2 = Data packet Contains general data

* 3 = Set error correction mode Sets error checking/correction mode

6 = Acknowledgement An acknowledgement for a packet

7 = Negative Acknowledgement An error has occurred.

8 = Request New Robot IDs Get IDs from new robots

9 = Request Info Get general info (buffer size, name, etc.)

10 = Request Sensor Layout Get info about sensors and their arrangement

11 = Request Sensor Data Get the data from the sensors in order (not sonar)

12 = Request Sonar Data Get the sonar data

* 13 = Set Error Correction Set error correction mode

14 = Set Sense Set sensing mode

* 15 = Set Scan Range Set the scan range (of sonar)

16 = Set Auto Scan Set automatic scanning mode of sonar

17 = Scan Scan sonar once

18 = Move Move robot by given direction and distance

19 = Stop Stop robot

.

. Not set yet...

.

*255 = Blank This means the same as 0**

* Opcode is not currently implemented

** See problems section below, a trailing 0 character is not always detected.

Problems with Serial Communications of the Handyboard:

The Handyboard may have trouble detecting a '\0' (null) character as a terminating character if such a method is used.

If data is sent to the Handyboard too quickly, the buffer will fill up quicker than it can be emptied. This can be fixed by making the other end slow down its transfer rate. Alternately, the data can be sent in packets no larger than the buffer size and a stop and wait protocol can be used to acknowledge each packet.