RCwiproc

Wireless Protocol

The wireless protocol for the 2007 RoboCup will define the means by which the host computer and on-field robots will communicate. The wireless channel itself will be half-duplex with a single frequency being shared by the Rx and Tx modules. The host will send each robot velocity, direction, and shoot directives, at a rate of about 40-50 Hz. In such a way the enitre system (host, camera, and robot) will behave as a real-time system. Each robot will respond to these data messages with its current error status, battery voltage, wheel velocity, unique ID, and whether or not it has the ball.

Comments

MOVED TO DISCUSSION PAGE (discussion tab up top, or just click that link) ScottT

To Do

• Research protocols
  • UDP (User Datagram Protocol) - Dropping UDP as a choice in protocol. Would need a module that implements it already
  • Protocol Book
• Determine the rate at which to update robots - Will need to find theoretical base for this and confirm with test.
• Specify a custom protocol - Remeber to do Visio graph of packet structure
• Evaluate and compare UDP to a custom protocol

Protocol Structure

What is a Protocol?

A protocol is a set of rules to define how two or more entities comunicate. It contains 5 basic elements:

• A service definition - What information will the protocol provide the entities that utilize it?
• A set of assumptions - What is assumed to in the protocol? What isn't?
• A vocabulary - What will be the forms of data that I will use to communicate with this protocol
• A format/encoding - How will my vocabulary coherantly fit together to form larger msgs, and cmds
• A set of procedural rules - How will I intiate communication? How are the entities using this protocol indentied? What are thier roles?
  

Other considerations such as the medium are not specifically stated in the protocol but influence how the protocol is formed. Consider the difference between Wi-Fi where one router can talk to multiple devices versus communication between a wired video game controller and a console.

As an example of a protocol consider the english language in its vocal form. The service it provides is a means of conveying thoughts thruogh the use of sound. It assumes that all the parties involved can speak and understand english, that the medium is such that the transmission of sound waves is possible, and that meaning of the vocabulary used is the same among all parties involved. Its vocabulary is made up of 26 letters that by themselves or in groups represent a set of vocal patterns generated and recieved by all the parties involved. In this abstract defintion of vocabulary, it is not words but rather letters and the sounds they make that form the protocol. The basic format of the english language is such that the vocabulary of letters is formed into words, which each carry the meaning of the thought being conveyed.

The procedural rules change based on the situation. Sometimes one person is communicating with a group of passive listeners, at other times several people are communicating with one person at once. There are even times (eavesdropping) where one or more parties are listening to a speaker but not directly communicating with them. For each of these types of communication schemes we have developed means by which to avoid confusion and express our intent. For example in the case were multiple people are talk to the same person, the listener, who is not able to communicate with several people at once will ask each speaker to talk one at a time in some arbitray order. This method of determining who gets to speak when multiple parties wish to communicate with each other is called arbitration. Techniques for arbitration vary based on the medium and topology of a communication scheme.

Another set of procedural rules apply for situations were the information sent by the speaker is not discernable to the listener. In such cases the listener will ask the speaker to repeat what they just said or to provide clarification. Generally these methods work, but often times communication can break down if the listener continually can't discern what is being said. In extreme cases the listener might try to incorrectly discern incorrect information that he/she thought the speaker said. For these case nothing can be explicitly done in order to prevent the listener from responding to errant information, but if the information from the speaker is relatively important, the speaker can query the listener to enure that the correct information was recieved. In general this entire method is called Ack (acknowledgement) and retransmit.

Our Protocol

The wireless protocol for our 2007 RoboCup team will allow the host computer to communicate with the individual robots. Messages will be transmitted, serially using a 900MHz radio transmitter/receiver pair at 57kbps. Special considerations must be made for protocol design when wireless is used as a medium. For example, wireless data, transmitted by a device at a specific frequency, can be received by any device within range, receiving at that frequency. Therefore there must be a means in the protocol of establishing which device is to be addressed in a message. For some messages though addressing is not used as the intent it to talk to all devices at once. A verbal analog to this sort of multi-cast communication is a drill sergeant commanding a platoon of solders. Another consideration must be made relating to the corruption of data. Signal noise from other devices and from broadband devices can degrade a wireless signal, creating errant data in the packet. Methods such as checksums and Cyclical Redundancy Checks (CRC) can be used to check for corrupted packets.

For our protocol a combination of multi-cast and addressed messages are used, with the multi-cast messages being used to communicate most of the data to the robots. The protocol is half duplex with Rx and Tx sharing the same frequency. Multi-cast data messages are sent at a set interval from the host computer, with the space between them being devoted to status/ack messages from the robots. No flow control will be implemented nor will there be any re-transmission of errant messages, in order to maintain the real-time requirements of the system.

Errant messages will be identified using a CRC at the end of each message. An CRC algorithm on the each Rx controller will determine if the data recieved is corrupted and will "toss out" incorrect data. The CRC will be 8 bits for the majority of messages except the data messages which will have a 16-bit CRC due to thier length.

Packet Structure

Header Format:

Start/Flag (1 byte)	RobotID (5 bits) / Type (3 bits)	Data (0 - 137 bits)	Checksum/CRC (1 - 2 byte)

The header consists of a start or flag byte to indicate the start of a packet, 5 bits to identify the robot(s) being sent to (00000 for robot->host communication), and 3 bits to indicate the type of message. The types of messages can be:

• Init Message
• Data Message

For Init messages, the robot sends the init message out to each robot (1-5) in turn and waits for an ACK message. For data messages, they can either be Control messages or Data/Movement messages as specified by the first bit of the data field. Init/Data Control messages are followed by a 8 or 16 bit CRC/Checksum while the Data Movement/Data messages are followed by a 16 or 32 bit CRC/Checksum.
Control Message:

Flag/0 (1 bit)	Message Type (3 bits)	Errors (4 bits)	Checksum/CRC (8 or 16 bits)

Data Message:

Flag/1 (1 bit)	Robot 1 Data (3 bytes/24 bits)	Robot 2 Data (3 bytes/24 bits)	Robot 3 Data (3 bytes/24 bits)	Robot 4 Data (3 bytes/24 bits)	Robot 5 Data (3 bytes/24 bits)	Checksum/CRC (16 or 32 bits)

OUTDATED

---

Host to Robot Messages

MsgID	ID	ACK?	To	DLC	Data Format	Description
Wakeup	0x01	Yes	Individual robots	1	Byte 1 Robot ID	Host polls for each robot individually. When this msg is recieved by a robot it responds with a status msg indicating that it is ready for action.
Go/Start	0x02	Yes	Individual robots	0	None	Intiates main process on robots.
Data	0x03	No	All robots	15	See below	Streaming data sent to all robots in one msg.
Game Reset	0x04	No	All robots	0	None	Ends the main process on all robots. Reverts them back to wakeup state.
Shoot Ball	0x05	Yes	Individual robots	1	Robot ID (1 byte) Robot Angle (1 byte)	Commands the robot with ID given to take the shot.
Robot Stop	0x06	Yes	Individual robots	0	Robot ID	Commands an indivdual robot to stop. May not be used.

With the format for the Data messages being defined as:

Byte 1	Byte 2	Byte 3
Vx (1 byte)	Vy (3 bits)	Theta (5 bits)

Robot to Host Messages

MsgID	ID	ACK?	To	DLC	Data Format	Description
Status	0xA	No	Host	3	None	Given in response to Wakeup message. Data section not fully specified, contains battery info serial number error state

Protocol Procedural Rules

When messages are being sent between the host and the team robots care must be taken to cause data collisions, message oscillations, and other errors. To prevent such events a set of procedural rules are implemented dictating when each msg is sent and what happens both before and after the messages transmission. Below is a detailed explanation of the procedural rules for each message and finally somMay be folded into msg 0x04e flow charts for events such as initial startup and stopping.

Wakeup

As the title says this msg brings the robots out of a known "sleep" state and registers them the host controller. The motivaton for the message and the procedure it details is so that message transfer starts from a known safe state, this state being the "sleep" the state. The "sleep" state is entered once the robot is turned on and is written in firmware. In "sleep" state the robots will not talk to the host nor respond to any messages except wakeup. The procedure for waking up a team is as follows:

• First the human operator feeds in the unique ID of each robot on the field. These ID numbers range from 1-10 and in fact are the IDs included in each message.
• When the command is given the host sends out the wakeup msg to the robot whose ID is first in the list of IDs fed in the the operator.
• If the robot with that ID is on the field it will immediately respond back to the host with a status message giving information on its health, and its unique serial number.
• When the host recieved this status message it will move on the next ID in its list and transmit a wakeup message with that ID.
• If the host does not recieve a status message back or the health of the robot is such that its not ready it will alert the operator and will not continue the wakeup sequence.
• Once all the robots have been verified to be on the field and ready the wakeup sequence shall be considered complete and host is now ready to start a game.
  

You may wonder why the wakeup msg is sent to each robot one at a time. Even though our protocol is full-duplex it doesn't define an arbitration scheme. As work-around messages from the robots to the host are only sent when asked for by the host. In such a manner we can ensure that only one robot can talk to the host at a time, avoiding data collisions. Future implementations we see the addition of arbitration.

GO/Start

Once the robots on the field are found and in good order we can start a game. The GO/Start message signals the robots to begin thier main process and prepare to recieve data. The robots do not acknowledge this message since it is a broadcast message. Broadcast messages are messages sent to all robots at once, and makeup the majority of msgs sent on the wirless channel. The motivation for these message types is simplicity. Instead of sending most messages to each robot individually and flooding the wireless channel thereby increasing chances for a dropped packets we package the information in one big message. As a consequence there can be no acknowledgments to these messages due to the lack of an arbitration scheme.

Data

This message will be the bulk of the messages sent from on the wireless channel. It is a broadcast message for the above reasons and hence no acknowledgment is required. Each robots data values are picked off from the data section. This message can only be recieved by a robot when it is out of sleep mode.

Game Stop

Another broadcast message. Singals the end or stoppage of game play. When the robots are stopped they are not in sleep mode and can still communicate with the host. But since they are stopped thier internal process is no longer active and they act as "dumb" terminals.

Shoot Ball

As the title says this messages signals the robot whose ID it is sent to to shoot the ball, once it has rotated a given number of degrees. Since this is an individual robot message an acknowledgment is allowed and is required.

Robot Stop

The same as Game Stop only sent to individual robots. Since this is an individual robot message an acknowledgment is allowed and is required.

Status

The only message sent from the robot to the host, the status message serves as both an actual status message and as an ACK. In any case status messages are only sent was ack to messages that allow acknowledgments.

Articles

• Linx article on protocol design
• TI Example wireless system design protocol and all
• Paper on the Cylical Redundancy Check error checking algorithm (CRC)
• Enitre book on protocol design, a bit dated though like 1990 dated
• Berkeley article on wireless protocol design. Gives a real world example of how to design a wireless protocol.
• Ohio University article. Details an intresting communications method
• Paper from Maxim on Manchester Encoding
• Berkeley PPT on errors and wireless
• Circuit Cellar discussion on Manchester Encoder/Decoder
• Cornell electrical design document
• Page on coding communications protocols in C++

Links

Wireless Hompage