Difference between revisions of "RCwiproc"

From RoboJackets Wiki
Jump to navigation Jump to search
(→‎Our Protocol)
(→‎Our Protocol)
Line 1: Line 1:
−
==Wireless Protocol==
+
between a wired video game controller and a console. <br>
−
 
 
−
The host will send each robot velocity, direction, and shoot directives, at a rate of about 40-50 Hz. '''(This data rate still needs to be confirmed with testing)''' In such a way the enitre system (host, camera, and robot) will behave as a real-time system. The robot will send its current error status, battery voltage, wheel velocity, unique ID, and whether or not it has the ball to the host but at the much slower rate of 10Hz.
 
−
 
 
−
==To Do==
 
−
* Research protocols
 
−
** <strike>UDP (User Datagram Protocol)</strike> - Dropping UDP as a choice in protocol. Would need a module that implements it already
 
−
** <strike>Protocol Book</strike>
 
−
* Determine the rate at which to update robots - Will need to find theoretical base for this and confirm with test.
 
−
* <strike>Specify a custom protocol</strike> - Remeber to do Visio graph of packet structure
 
−
* <strike>Evaluate and compare UDP to a custom protocol</strike>
 
−
 
 
−
==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?<br>
 
−
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. <br>
 
 
<br>
 
<br>
 
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 not directly communicating to them.<br>
 
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 not directly communicating to them.<br>
 
<br>
 
<br>
 
===Our Protocol===
 
===Our Protocol===
−
A vital part of our robocup team is its communication system. Therefore an effective means of sending information across this system will need to be realized with a protocol of some sort. In general our protocol needs to allow the host to command movements and actions to the robots, while allowing the robots to provide status information back to the host. The medium will be RF signals in the 900mHz range. This means that we can assume an appreciable dropped packet rate, and interfereance from other teams, and devices. Binary data clocked at 57Kbps will be our vocabulary, and the msg format will be in packets of varying length. Specifically each packet will be divided in bytes, with the first byte consisting of a know header. This will be followed by bytes containg the msg ID, its length, who its intended for, the data being sent, and a checksum. The checksum will be a sum of all the ones in the msg represented as an unsigned 8-bit number. Below in the figure is a a detail of what each packet will look like.  
+
====Packet Structure====
 +
A vital part of our robocup team is its communication system. Therefore an effective means of sending information across this system will need to be realized with a protocol of some sort. In general our protocol needs to allow the host to command movements and actions to the robots, while allowing the robots to provide status information back to the host. The medium will be RF signals in the 900mHz range. This means that we can assume an appreciable dropped packet rate, and interfereance from other teams, and devices. Binary data clocked at 57Kbps will be our vocabulary, and the msg format will be in packets of varying length. Specifically each packet will be divided in bytes, with the first byte consisting of a know header, followed by bytes containg the msg ID, its length, who its intended for, the data being sent, and a checksum. Below in the figure is a a detail of what each packet will look like.
 
<br>
 
<br>
 
{|  cellspacing="1"
 
{|  cellspacing="1"
Line 33: Line 14:
 
! width="75" bgcolor="#909090"|ID (3 bits)
 
! width="75" bgcolor="#909090"|ID (3 bits)
 
! width="125" bgcolor="#909090"|DLC (5 bits)
 
! width="125" bgcolor="#909090"|DLC (5 bits)
−
! width ="200" bgcolor="#909090"|Robot ID (1 byte)
+
! width ="200" bgcolor="#909090"|Recipient ID (1 byte)
 
! width="280" bgcolor="#d0d0d0"|Data (0 - 15 bytes)
 
! width="280" bgcolor="#d0d0d0"|Data (0 - 15 bytes)
 
! width ="200" bgcolor="#909090"|Checksum (1 byte)
 
! width ="200" bgcolor="#909090"|Checksum (1 byte)
−
 
 
|}
 
|}
 
<br>
 
<br>
−
Explain what each part of packet means
+
The header consists of two transitions 0 to 1 and 1 to 0 spread over the time of one byte. The ID of the msg is a unique 3-bit value the identifies the type of msg being sent. In the table below is a listing of the different msgs and thier ID's. Each msg's length is described by a 5-bit value called the DLC or data length code. Who the msg is intended for is determined by which bit is set in the Recipient ID. Bits 1-5 correspond to robots 1-5, 6 corresponds to the host and 7 means the msg is meant for all robots. The format of the data section of the packet is based on the msg being sent. In most cases it is blank but for data msgs it has the following format:
 +
<br>
 +
{|  cellspacing="1"
 +
|-
 +
! width="250" bgcolor="#909090"|Robot 1 Data (3 bytes)
 +
! width="250" bgcolor="#909090"|Robot 2 Data (3 bytes)
 +
! width="250" bgcolor="#909090"|Robot 3 Data (3 bytes)
 +
! width="250" bgcolor="#909090"|Robot 4 Data (3 bytes)
 +
! width="250" bgcolor="#909090"|Robot 5 Data (3 bytes)
 +
|}
 
<br>
 
<br>
−
The information that will be sent along the wireless link will be determined by the ID of the msg encapsulating it.  Other factors such as the msg destination and its DLC or data length code will further refine the msg. In the table below are the defintions for each msg. Some msg will require an acknowledgment or ACK from the recipient. An ACK will be realized as a msg of a different ID, and that msg is specified in the msg description in the table.
+
With the format for the data for each robot being defined as:
 +
<br>
 +
{|  cellspacing="1"
 +
|-
 +
|Byte 1||Byte 2||Byte 3
 +
|-
 +
! width="200" bgcolor="#909090"|Vx (1 byte)
 +
! width="200" bgcolor="#909090"|Vy (3 bits)
 +
! width="200" bgcolor="#909090"|Theta (5 bits)
 +
|}
 
<br>
 
<br>
−
<br>
+
 
 
{| style="text-align:left; width:100%; height:300px" cellspacing="0" cellpadding="5"
 
{| style="text-align:left; width:100%; height:300px" cellspacing="0" cellpadding="5"
 
|+ Host to Robot Messages
 
|+ Host to Robot Messages
Line 53: Line 51:
 
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x01
 
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x01
 
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Yes
 
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Yes
−
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Individual robots
+
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Individual robots
−
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 0
+
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0
−
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | None
+
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | None
−
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 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.
+
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 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.
 
|-
 
|-
  
Line 101: Line 99:
 
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | None
 
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | None
 
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands an indivdual robot to stop.
 
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands an indivdual robot to stop.
−
|-
+
|}
 
<br>
 
<br>
 +
====Protocol Procedural Rules====
 +
 
<br>
 
<br>
−
(Flow charts on how msgs are sent)
 
  
 
==Articles==
 
==Articles==

Revision as of 09:54, 11 August 2006

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 not directly communicating to them.

Our Protocol

Packet Structure

A vital part of our robocup team is its communication system. Therefore an effective means of sending information across this system will need to be realized with a protocol of some sort. In general our protocol needs to allow the host to command movements and actions to the robots, while allowing the robots to provide status information back to the host. The medium will be RF signals in the 900mHz range. This means that we can assume an appreciable dropped packet rate, and interfereance from other teams, and devices. Binary data clocked at 57Kbps will be our vocabulary, and the msg format will be in packets of varying length. Specifically each packet will be divided in bytes, with the first byte consisting of a know header, followed by bytes containg the msg ID, its length, who its intended for, the data being sent, and a checksum. Below in the figure is a a detail of what each packet will look like.

Byte 1 Byte 2 Byte 3 Byte 4 Bytes 5-19 Last Byte
Header (1 byte) ID (3 bits) DLC (5 bits) Recipient ID (1 byte) Data (0 - 15 bytes) Checksum (1 byte)


The header consists of two transitions 0 to 1 and 1 to 0 spread over the time of one byte. The ID of the msg is a unique 3-bit value the identifies the type of msg being sent. In the table below is a listing of the different msgs and thier ID's. Each msg's length is described by a 5-bit value called the DLC or data length code. Who the msg is intended for is determined by which bit is set in the Recipient ID. Bits 1-5 correspond to robots 1-5, 6 corresponds to the host and 7 means the msg is meant for all robots. The format of the data section of the packet is based on the msg being sent. In most cases it is blank but for data msgs it has the following format:

Robot 1 Data (3 bytes) Robot 2 Data (3 bytes) Robot 3 Data (3 bytes) Robot 4 Data (3 bytes) Robot 5 Data (3 bytes)


With the format for the data for each robot being defined as:

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


Host to Robot Messages
MsgID ID ACK? To DLC Data Format Description
Wakeup 0x01 Yes Individual robots 0 None 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.
Vx Vy and Theta 0x03 No All robots 15 See below Streaming data sent to all robots in one msg.
Stop 0x04 No All robots 0 None Stops all robot motion.
Shoot Ball 0x05 Yes Individual robots 1 Robot Angle Commands robot to take the shot. May be folded into msg 0x04
Robot Stop 0x06 Yes Individual robots 0 None Commands an indivdual robot to stop.


Protocol Procedural Rules


Articles

Links

Wireless Hompage

Retrieved from "https://wiki.robojackets.org/index.php?title=RCwiproc&oldid=3011"