RCwiproc

From RoboJackets Wiki
Revision as of 01:32, 24 September 2006 by AndyB (talk | contribs) (→‎Comments)
Jump to navigation Jump to search

Wireless Protocol

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.

Comments

  • I came across an interesting paper doing some work for my ECE4605 class; it details RTP which is a transport protocol for real-time applications. I haven't had a chance to read it, but we may be able to gleam some good information from it. RTP - RFC3550 I'll also try and take a look at that book on protocols you mentioned. I should give you a heads up, however, that I'm not sure how much time I'll get to goto the meetings this week as I have 4 tests (one on 4 different days...) and a 30-minute presentation to give (on the day I don't have a test). I should be able to make it for maybe an hour on Monday and a little while on Thursday, but I probably wont be able to stay as long as I'd like. That said, if you could let me know of any pertanent information I miss from the meetings, I'll try and keep doing some research/work on the protocol and programming for the ARM. Which reminds me, we're just programming in C/C++ then compiling it for ARM, right? Or are we going to do really low-level assembly programming for the ARM? If we run out of topics to talk about sometime during the meetings, perhaps we can determine exactly what we want the robots to be able to do... then think about what programs/functions we'll have to program in. ScottT 21:53, 23 September 2006 (EDT) We have GCC I'm gonna strongly reccomend we use it. --Andy 01:32, 24 September 2006 (EDT)
  • Also remember two other things. Our module is going to filter out all parts of the spectrun except for the area around the carrier frequency. Unless another team is being an ass we should be the only team on that frequency. Also monitoring the channel means that either our RX module and TX always be on the same frequency so that RX module can look for the channel to be clear or we have to switch frequencies on the RX module which takes a fair amount of time in fact more than we can handle and still be broadcasting at 55Hz. But we'll have to do some investigating at the meeting on Monday. In the mean time be sure to take a look at that book on protocol design thats at the bottom of this page, it actually has a caculation in chp7 I believe for determining the optimal configuration for a protocol based on reliability. MarksP 19:16, 21 September 2006 (EDT)
  • I think we should definatly go with monitoring the channel for when the channel is clear... or, perhaps, dividing the sending time between each of the systems... each block of time is divided between the host sending a message, then each robot in turn sending a message... I actually hadn't thought about that mostly because my classes haven't dealt with wireless protocols so much yet. ;) Something to consider when watching the channel, however, is whether or not interference from other teams will be picked up as activity on the channel. ScottT 18:59, 20 September 2006 (EDT)
  • As far as ACKs are concerned remember that for wireless arbitration between msgs gets a bit hairy. Say two robots try to respond back to the host at the same time. The wireless signal that the host will recieve will be the analog sum the signals from those two robots. It is impossible for the host to tell which is which. Two ways around this: We could have each robot time out a set time t before it responds with an ACK. If we add a delay to t for each robot, then they will respond in an orderly fashion one after the other. Another solution is to have each robot look for traffic on the wireless channel and transmit only when the channel is clear. This is the best solution and is similar to the scheme used in CAN. Also remember this protocol needs to be as low level as possible. As for checking for wheel jams thats an issue for the motor controller. In the event of a jam its probably best to end gameplay for that robot since this isn't a safetly critical application. Phillip
  • What about the rate of dropped packets... how many do we actually expect to have? Since the system will be as close to real-time as possible, we'll have to deal with these dropped packets as well as any out-of-order packets that may arise because of the drop. Unless there's a good reason not to, we might want to have ACKs for every packet sent... both to and from the robots. We obviously have a unique situation in that we have a designated server and clients all the time... in other words, we only have to imeplement a client and a server protocol that correctly interact rather than a universal protocol where you could be either client or server (TCP, etc.). I think one of the first things we should do is figure out how we want to handle errors (if at all). Also, should the server be constantly broadcasting to each robot? Maybe a constant packet size, always transmitting at set times with corresponding ACKs from each robot after every packet? Just shooting some ideas out there. I'll try and look into this more before Thursday so we can speak on it some. ScottT 00:48, 20 September 2006 (EDT)
  • Do the robots implement any kind of checking on whether or not their wheels are jammed? Or other mechanical/electrical errors? ScottT 22:23, 19 September 2006 (EDT)
  • Parts of this protocol seem like there's too much or too little emphasis on some areas. Also, we may be able to work on the size of each packet a bit by playing around with what information we put in the header. The checksum is definatly good, but we need to consider the impact this could have on the "real-time" nature of the protocol. We may not be using UDP, but perhaps we can draw some from it. This is a great start, and I'll put some more comments/thoughts later, but I managed to burn the fingertips of 3 of my fingers, so typing takes some time right now, heh. ScottT 22:20, 19 September 2006 (EDT)

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 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 Bytes 3 up to 17 Last Byte
Header (1 byte) ID (3 bits) Length (5 bits) 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)



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

Links

Wireless Hompage

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