RCwiproc - Revision history

Cwehmeyer3 at 02:07, 14 June 2018

2018-06-14T02:07:23Z

Rosawa3: recategorizing

2013-11-09T12:38:39Z

recategorizing

Rosawa3 at 13:46, 18 July 2013

2013-07-18T13:46:24Z

Marksp: updating with new protocol information

2006-10-16T14:22:22Z

updating with new protocol information

Marksp: /* To Do */

2006-10-11T16:42:24Z

‎To Do

ScottT: Added link about programming communication protocols

2006-10-09T21:13:31Z

Added link about programming communication protocols

ScottT: Began rewriting protocol page based on discussion during the 10/2/2006 meeting

2006-10-02T23:25:12Z

Began rewriting protocol page based on discussion during the 10/2/2006 meeting

ScottT: /* Comments */ -Moved the comments to the discussion page!

2006-09-25T20:13:07Z

‎Comments: -Moved the comments to the discussion page!

Marksp: /* Comments */

2006-09-25T00:24:08Z

‎Comments

AndyB: /* Comments */

2006-09-24T05:32:27Z

‎Comments

← Older revision		Revision as of 02:07, 14 June 2018
Line 209:		Line 209:
	[[RCcoms\|Wireless Hompage]]		[[RCcoms\|Wireless Hompage]]
	[[Category: RoboCup]]		[[Category: RoboCup]]
−	~~[[Category: Electrical]]~~

@@ Line 209: / Line 209: @@
 [[RCcoms|Wireless Hompage]]
 [[Category: RoboCup]]
-[[Category: RoboCup Electrical]]
+[[Category: Electrical]]

← Older revision		Revision as of 13:46, 18 July 2013
Line 208:		Line 208:
	==Links==		==Links==
	[[RCcoms\|Wireless Hompage]]		[[RCcoms\|Wireless Hompage]]
		+	[[Category: RoboCup]]
		+	[[Category: RoboCup Electrical]]

@@ Line 1: / Line 1: @@
 ==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==
@@ Line 24: / Line 23: @@
 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>
-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.
 <br>
 ===Our Protocol===
 ====Packet Structure====
 Header Format:

@@ Line 10: / Line 10: @@
 ** <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>Determine the rate at which to update robots - Will need to find theoretical base for this and confirm with test.<strike>
 * <strike>Specify a custom protocol</strike> - Remeber to do Visio graph of packet structure
 * <strike>Evaluate and compare UDP to a custom protocol</strike>

@@ Line 194: / Line 194: @@
 *[http://bbs.circuitcellar.com/phpBB2/viewtopic.php?t=2233& Circuit Cellar discussion on Manchester Encoder/Decoder]
 *[http://robocup.mae.cornell.edu/documentation/robocup/2002/2002EE.pdf Cornell electrical design document]
 ==Links==
 [[RCcoms|Wireless Hompage]]

@@ Line 28: / Line 28: @@
 ===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.
+Header Format:
 <br>
 {|  cellspacing="1"
 |-
-|Byte 1|| Byte 2||Bytes 3 up to 17||Last Byte
+! width="200" bgcolor="#909090"|Start/Flag (1 byte)
 |-
-! width="200" bgcolor="#909090"|Header (1 byte)
+! bgcolor="#909090"|Flag/0 (1 bit)
-! width="240" bgcolor="#909090"|ID (3 bits) Length (5 bits)
+! width="93" bgcolor="#909090"|Message Type (3 bits)
-! width="280" bgcolor="#d0d0d0"|Data (0 - 15 bytes)
+! width="124" bgcolor="#909090"|Errors (4 bits)
-! width ="200" bgcolor="#909090"|Checksum (1 byte)
+! width="250" bgcolor="#909090"|Checksum/CRC (8 or 16 bits)
 |}
 <br>
-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:
+Data Message:
 {|  cellspacing="1"
 |-
-! width="250" bgcolor="#909090"|Robot 1 Data (3 bytes)
+! bgcolor="#909090"|Flag/1 (1 bit)
-! width="250" bgcolor="#909090"|Robot 2 Data (3 bytes)
+! width="250" bgcolor="#909090"|Robot 1 Data (3 bytes/24 bits)
-! width="250" bgcolor="#909090"|Robot 3 Data (3 bytes)
+! width="250" bgcolor="#909090"|Robot 2 Data (3 bytes/24 bits)
-! width="250" bgcolor="#909090"|Robot 4 Data (3 bytes)
+! width="250" bgcolor="#909090"|Robot 3 Data (3 bytes/24 bits)
-! width="250" bgcolor="#909090"|Robot 5 Data (3 bytes)
+! width="250" bgcolor="#909090"|Robot 4 Data (3 bytes/24 bits)
 |}
 <br>
 {| style="text-align:left; width:100%; height:300px" cellspacing="0" cellpadding="5"
 |+ '''Host to Robot Messages'''

@@ Line 4: / Line 4: @@
 ==Comments==
-* Man, we are filling this comments section up. Yeah, work first. Don't worry about showing up if you really want to we can just conference you on aim, but I don't want you to have to be worrying about 4 test and go to a meeting. As for the article it looks promising, we might slash certian parts in the packets since the size of our network is know. As for assembly programming, only if its punch-cards and bare teeth. Oh yeah some Grand Challenge guys were in the COC lab and were talkin mess about how they would rather have a Porsches than little robots.  --[[User:Marksp|Phillip]] 20:32, 24 September 2006 (EDT)
+'''MOVED TO [[Talk:RCwiproc|DISCUSSION PAGE]] (discussion tab up top, or just click that link)''' [[User:ScottT|ScottT]]
 ==To Do==

← Older revision		Revision as of 00:24, 25 September 2006
Line 4:		Line 4:

	==Comments==		==Comments==
		+	* Man, we are filling this comments section up. Yeah, work first. Don't worry about showing up if you really want to we can just conference you on aim, but I don't want you to have to be worrying about 4 test and go to a meeting. As for the article it looks promising, we might slash certian parts in the packets since the size of our network is know. As for assembly programming, only if its punch-cards and bare teeth. Oh yeah some Grand Challenge guys were in the COC lab and were talkin mess about how they would rather have a Porsches than little robots. --[[User:Marksp\|Phillip]] 20:32, 24 September 2006 (EDT)
		+
	* 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. [http://www.ietf.org/rfc/rfc3550.txt 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. [[User:ScottT\|ScottT]] 21:53, 23 September 2006 (EDT) We have GCC I'm gonna strongly reccomend we use it. --[[User:AndyB\|Andy]] 01:32, 24 September 2006 (EDT)		* 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. [http://www.ietf.org/rfc/rfc3550.txt 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. [[User:ScottT\|ScottT]] 21:53, 23 September 2006 (EDT) We have GCC I'm gonna strongly reccomend we use it. --[[User:AndyB\|Andy]] 01:32, 24 September 2006 (EDT)

@@ Line 4: / Line 4: @@
 ==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. [http://www.ietf.org/rfc/rfc3550.txt 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. [[User:ScottT|ScottT]] 21:53, 23 September 2006 (EDT)
+* 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. [http://www.ietf.org/rfc/rfc3550.txt 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. [[User:ScottT|ScottT]] 21:53, 23 September 2006 (EDT) We have GCC I'm gonna strongly reccomend we use it. --[[User:AndyB|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. [[User:MarksP|MarksP]] 19:16, 21 September 2006 (EDT)