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.