RoboJackets Wiki - User contributions [en]

User:ScottT

2007-03-07T00:53:36Z

ScottT:

'''Scott Travis'''
RoboCup Electronics Team
Wireless/ARM
'''email''': scorpio@gatech.edu
'''phone''': 770-314-5743
'''AIM''': darkpathfinder 
Feel free to AIM me sometime if you have a question.

RCsensors

2006-12-04T16:01:06Z

ScottT: /* Gyro */

==What We Need Now==
* Gyro (for angle)
** Analog Devices [http://www.analog.com/en/prod/0,2877,ADXRS300,00.html ADXRS300EB]
* [[RCbatterymon|Battery monitor]]
* <strike>Current Sensing (to motors)</strike>(Will be packaged in motor drivers)--[[User:Marksp|Phillip]]

==What We Need Eventually==
* Collision Detection
** Bumpers
** Sonar
* Ball Sensor
** IR Beam
* <strike>Temperature Sensor</strike>(Will also be packaged in motor drivers)--[[User:Marksp|Phillp]]
* <strike>Accelerometer</strike>/encoder - I would just go with encoders, according to CMU, we move to fast for an accelerometer/gyro --[[User:AndyB|Andy]] 21:34, 24 May 2006 (EDT)
** <strike>Encoder that goes with our motors: [http://maxonmotorusa.com/files/catalog/2005/pdf/05_235_e.pdf Encoder MR] [[User:ScottT|ScottT]] 19:23, 17 October 2006 (EDT)</strike> Not getting because of lead time issue

==Schematics==
Schematics
==Devices==
===Gyro===
Analog Devices [http://www.analog.com/en/prod/0,2877,ADXRS300,00.html ADXRS300EB]

EagleCAD files for Gyro: [http://www.prism.gatech.edu/~gtg763x/ROBOCUP.zip ROBOCUP.zip]

===IR Beam===
====IR LED====
*[http://robotag.carleton.ca/resources/technical/datasheets/liteon_ir_emitter_10-21.pdf Chosen 11/09/06 1.6V 50mA]
*[http://downloads.solarbotics.com/PDF/IR_LED_Xmit-QED233.pdf Fairchild 1.8V 180mW 940nm]
====IR Photo-Transistors====
*[http://downloads.solarbotics.com/PDF/PNA4602_datasheet.pdf Panasonic 5V bias]

===Encoders===
Scott place your info here
Typical Circuit
*[http://focus.ti.com/lit/ds/symlink/cd54hct14.pdf Schimitt Tigger]

===Collision Bumpers===

==Articles==

==Links==

[[RobocupElectrical|Electrical Homepage]]

RCsensors

2006-10-17T23:23:32Z

ScottT: /* What We Need Eventually */ - Added link for encoders that go with the motor we're currently looking at

RCCamera

2006-10-09T23:16:19Z

ScottT: /* Camera */

==Camera==
So, after speaking with the folks at the US Open, I have some information to report about the cameras used. The CMU team used two of the smallest Sony prosumer three chip cameras with wide angle lenses. They did not stream from firewire, but rather used S-Video and a capture card per camera. They used the deinterlaced frames to get a apparent speed of 60 FPS. Consequently, they need the enhanced color reproduction of the three chip cameras because they are using the deinterlaced frames which implies they have about half the resoloution (320 x 240) of interlaced frames (640 x 480). That is, the ball makes up only about 12 pixels with the deinterlaced frames, and accurate color reproduction is a necessity to be able to pick the ball out of the background noise.

So, with a quick enough camera, the color reproduction should not matter as much.

For professional machine vision cameras, the following look pretty good.
===Pro Cameras===
* [http://www.baslerweb.com/index.html Basler]
**[http://www.baslerweb.com/downloads/11684/A600_9.pdf A601fc (60 FPS) or the A602fc (100 FPS)]. They are VGA (640 x 480) color firewire cameras which are linux compatible.
* [http://www.ptgrey.com/index.asp Point Gray] has some promising cameras (and generally better pricing).
** [http://www.ptgrey.com/products/flea/index.asp Flea] 60 FPS at VGA 12 bit color
** [http://www.ptgrey.com/products/flea2/index.asp Flea 2] 60 FPS at VGA 12 bit color
** [http://www.ptgrey.com/products/dragonfly2/index.asp Dragonfly 2] 60 FPS at VGA 12 bit color onboard RGB, YUV etc conversion.
** [http://www.ptgrey.com/products/scorpion/index.asp Scorpion] 60 FPS at VGA 12 bit color

===Camera We Have===
* Videre
** Model DCAM-L
** 4 mm CS mount lens

===Camera Resources===
* [http://damien.douxchamps.net/ieee1394/cameras/index.php Linux Driver Page] Really good!!
* [http://www.cs.cmu.edu/~iwan/1394/ CMU 1394 page]
* [http://sourceforge.net/projects/linux1394 Sourceforge 1394]
* [http://sourceforge.net/projects/unicap Sourceforge Unicap]
* [http://sourceforge.net/projects/iidcapi Sourceforge IEEE1394 Digital Camera API]

==Lens==
* 68 degree FOV (with one camera - not really practical)
* 35 degree FOV (with two cameras)

RCwicoprocessor

2006-10-09T23:02:23Z

ScottT: /* Parts */

The wireless co-processor will act as a the link between the packet modem and the micro. Its main function is to handle the wireless communications protocol and serve as a simple buffer (do we need this?). Serial data from the wireless module will be feed into the co-processor's UART. The co-processor will then retransmit only the velocity and theta to the micro on the SPI or some other protocol, when the micro has its ready to recieve line pulled low.
==The Wall==
==To Do==
==Specifications==
==Schematics==
==Parts==
Atmel ATiny 2313
*[http://www.atmel.com/dyn/resources/prod_documents/2543S.pdf Data Short]
*[http://www.atmel.com/dyn/resources/prod_documents/doc2543.pdf Data Sheet]
 
Atmega-16 40-pin dip JTAG
*[http://www.atmel.com/dyn/resources/prod_documents/2466S.pdf Data Short]

==Articles==
==Links==
* [[RCwiproc|Wireless Protocol]]

 
[[RobocupElectrical|Electrical Homepage]]

RCmicro

2006-10-09T22:16:04Z

ScottT: WinARM link

The microprocessor is the heart of the 2007 robojackets robocup competition robot and acts as the interface between the wireless communication system and the robot proper. A simple firmware program monitoring the internal sensors of the robot and controling the motor and ball roller/shoot will run on the micro. Currently as part of our phase one objectives we are looking closly at processors from Atmel, SI Labs, Motorola, and PICs. Below are some specs.
==The Wall==
9/14/06 - We chose a dev kit see the sparkfun link below. It'll cost $64.95 a pop and we are getting 3.

==To Do==
*Finalize number of I/O and type (SPI, PWM, ADC, etc)
*Design Schematic tying in all devices
*Breadboard to test write simple code
*Get board made
*Write Code

==Specifications==
{| style="text-align:center;" cellspacing="0" cellpadding="5"
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Device
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 32-bit microprocessor
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Power
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3.3V Low pwt
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Archetecture
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | ARM
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Clock
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | >50 MHz
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Memory
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Flash 128Kb
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | IO pins
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 32-64 pins Software Configurable
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Interfaces
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | SPI, UART
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | DA/AD
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | (3)10-bit DAC (2)10/16-bit ADC
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Timers
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 8-bit (3)
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | PWM
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 4 channels
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Programming
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | JTAG or Bootloader
|-
! style="border:.5px solid black; background:#909090" |
| style="border:.5px solid black; background:#d0d0d0" |
|}

==Schematics==
Schematics
==Articles==
*[http://direct.xilinx.com/bvdocs/whitepapers/wp123.pdf Article on Interfacing ARM processors and FPGAs]
*[http://tech.groups.yahoo.com/group/lpc2000/ Yahoo group about just the LPC ARM from Phillips]

==Possible Micros==
Phillips LPC
*[http://www.sparkfun.com/commerce/product_info.php?products_id=266 Sparkfun dev kit]
*[http://www.standardics.nxp.com/literature/leaflets/microcontrollers/pdf/lpc213x.pdf Phillips LPC213x series ARMs. Less memory than the LPC221x series but lower-power consumption and smaller footprint. Its still every bit as capable]
*[http://www.nxp.com/acrobat_download/literature/9397/75014627.pdf Phillips LPC221x series ARMs. More memory vs LPC2213x. COntains everything we need.]
*[http://www.lpctools.com/index.asp?PageAction=VIEWPROD&ProdID=54 Dev kit for LPC213x series $149.00. 2 issues: Do we have a JTAG programmer and if so will it fit the pin-out of this device?]
AVR32
*[http://www.atmel.com/products/AVR32/ ATMEL's answer to the ARM. Has everything '''including''' the kitchen sink.]

==Links==
*[http://www.skyeye.org/index.shtml ARM processor simulator for Linux] - might be able to use this to test things, but I'm not sure it would be better than just taking home a dev board. :P [[User:ScottT|ScottT]]
*[http://www.open-research.org.uk/ARMuC/ ARM Wiki] - Good page with a lot of ARM resources/links. [[User:ScottT|ScottT]]
*[http://www.heyrick.co.uk/assembler/qfinder.html Page of ARM processor instructions] - ASSEMBLY instructions, if we need them. [[User:ScottT|ScottT]]
*[http://www.arm.com/support/training/type4680.html Apparently free ARM course] - Not sure how useful this could be. [[User:ScottT|ScottT]]
*[[RCfirmware|Firmware]]
*[http://bray.velenje.cx/avr/terminal/ Bray++ Terminal (just download/run, no install!)]
*[http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/#winarm WinARM ARM development programs for Windows]
 
[[RobocupElectrical|Electrical Homepage]]

RCmicro

2006-10-09T22:09:31Z

ScottT: Bray++ Terminal Link

RCwiproc

2006-10-09T21:13:31Z

ScottT: Added link about programming communication protocols

==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==
'''MOVED TO [[Talk:RCwiproc|DISCUSSION PAGE]] (discussion tab up top, or just click that link)''' [[User:ScottT|ScottT]]

==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? 
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====
Header Format:
 
{| cellspacing="1"
|-
! width="200" bgcolor="#909090"|Start/Flag (1 byte)
! width="240" bgcolor="#909090"|RobotID (5 bits) / Type (3 bits)
! width="280" bgcolor="#d0d0d0"|Data (0 - 137 bits)
! width ="200" bgcolor="#909090"|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:
{| cellspacing="1"
|-
! bgcolor="#909090"|Flag/0 (1 bit)
! width="93" bgcolor="#909090"|Message Type (3 bits)
! width="124" bgcolor="#909090"|Errors (4 bits)
! width="250" bgcolor="#909090"|Checksum/CRC (8 or 16 bits)
|}
 
Data Message:
{| cellspacing="1"
|-
! bgcolor="#909090"|Flag/1 (1 bit)
! width="250" bgcolor="#909090"|Robot 1 Data (3 bytes/24 bits)
! width="250" bgcolor="#909090"|Robot 2 Data (3 bytes/24 bits)
! width="250" bgcolor="#909090"|Robot 3 Data (3 bytes/24 bits)
! width="250" bgcolor="#909090"|Robot 4 Data (3 bytes/24 bits)
! width="250" bgcolor="#909090"|Robot 5 Data (3 bytes/24 bits)
! width="250" bgcolor="#909090"|Checksum/CRC (16 or 32 bits)
|}
 

'''OUTDATED'''
----
{| style="text-align:left; width:100%; height:300px" cellspacing="0" cellpadding="5"
|+ '''Host to Robot Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Wakeup
| 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" | Individual robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Byte 1 Robot ID
| 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:#909090" | Go/Start
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x02
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Intiates main process on robots.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Data
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x03
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 15
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | See below
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Streaming data sent to all robots in one msg.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Game Reset
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x04
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| 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;" | Ends the main process on all robots. Reverts them back to wakeup state.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Shoot Ball
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x05
| 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;" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID (1 byte) Robot Angle (1 byte)
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands the robot with ID given to take the shot.
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Robot Stop
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x06
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands an indivdual robot to stop. May not be used.
|}
With the format for the Data messages being defined as:
 
{| 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)
|}
 
 
{| style="text-align:left; width:100%; height:100px" cellspacing="0" cellpadding="5"
|+ '''Robot to Host Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Status
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0xA
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Host
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 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==
*[http://www.linxtechnologies.com/documents/AN-00160.pdf Linx article on protocol design]
*[http://focus-webapps.ti.com/general/docs/sitesearch/searchsite.tsp?searchTerm=serial%20RS232%20drivers&selectedTopic=1077383935&numRecords=25 TI Example wireless system design protocol and all]
*[http://www.mathpages.com/home/kmath458.htm Paper on the Cylical Redundancy Check error checking algorithm (CRC)]
*[http://spinroot.com/spin/Doc/Book91.html Enitre book on protocol design, a bit dated though like 1990 dated]
*[http://bwrc.eecs.berkeley.edu/People/Faculty/jan/publications/p124.pdf Berkeley article on wireless protocol design. Gives a real world example of how to design a wireless protocol.]
*[http://www.ohiolink.edu/etd/send-pdf.cgi?ohiou1121356426 Ohio University article. Details an intresting communications method]
*[http://www.eetasia.com/ARTICLES/2005JUN/A/2005JUN06_RFD_AN01.PDF Paper from Maxim on Manchester Encoding]
*[http://webs.cs.berkeley.edu/retreat-6-03/slides/ChipconECC.ppt Berkeley PPT on errors and wireless]
*[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]
*[http://www.ddj.com/dept/cpp/193004231 Page on coding communications protocols in C++]

==Links==
[[RCcoms|Wireless Hompage]]

User:ScottT

2006-10-06T01:51:00Z

ScottT:

'''Scott Travis'''
RoboCup Electronics Team
Wireless/ARM
'''email''': scorpio@gatech.edu
'''AIM''': darkpathfinder 
Feel free to AIM me sometime if you have a question.

User:ScottT

2006-10-06T01:48:17Z

ScottT:

RoboCup Electronics Team
Wireless/ARM
AIM: darkpathfinder
 
Feel free to AIM me sometime if you have a question.

Talk:RCwiproc

2006-10-05T05:03:29Z

ScottT: reponse to problem

* Why is this a problem? The robot would be constantly receiving on it's Rx channel and transmitting when it needs to on the Tx channel. The Rx channel on the robot will always be fed with information from the host. The Tx channel should be able to be read with whichever wireless module is on the Tx channel, right? I mean, just because it's a dedicated transmitting channel doesn't mean the robot can't read it just to determine if there's traffic on the channel, right? I'm not sure if I understand the problem. [[User:ScottT|ScottT]] 01:03, 5 October 2006 (EDT)

* Realized a problem with the design from Tuesday, mainly how does the robot check if the RX is clear if the TX module is on another frequency and talking with the host. This is the problem I mentioned earlier. We might need to go back to the previous version unless we don't want collision detection on the RX channel. [[User:Marksp|Marksp]] 13:32, 4 October 2006 (EDT)
* I've been looking into the issue of how/when the robots/host should be sending data over the wireless. I suggest that we go about it one of two ways... the first/easiest being keeping every transmitter/station in sync and devoting specific times during a cycle for each of the robots and the host to use the channel. Essentially, divide a ~14-20ms space of time between the 5 robots and the host depending how much they need to transmit (host packets may be larger than robot packets...). While this would work, it's inefficient in using the channel if not every robot needs to trasmit during a cycle. The second way would be something close to [[http://en.wikipedia.org/wiki/CSMA-CD CSMA/CD]] (Carrier Sense Multiple Access with Collision Detection). This works by checking the channel to see if it's free and also checking to see if, while transmitting, a collision occurs and to handle such an event accordingly. This would be a more efficient use of the available time on the channel however, it would be more complicated. We could work it to give the host precidence over the robots to transmit, possibly. There is, of course, the option of using two wireless modules on every station to allow different Tx/Rx channels. The host could be constantly transmitting over it's Tx channel while listening for any robots on the Rx channel. Meanwhile, the robots would be constantly listening on their Rx channels (same freq as host Tx) and transmit when necessary over their Tx channels (same freq as host Rx). I believe this would provide the most efficient use of the channels and would free us from worrying about the host transmissions getting in collisions with robot transmissions. We could also implement the CSMA/CD scheme on the robot Tx/host Rx channel so that the robots can make efficient use of their available bandwidth in communicating with the host. Any or all of these schemes should work and, time permitting, I think we should try and test them all to see which we like better. The scheme with a single-channel and time divided transmissions between host and robots would likely be the simplest to implement... the main problem there may be keeping the timing constant. What do you guys think? [[User:ScottT|ScottT]] 17:05, 2 October 2006 (EDT)

* I'll be at the meeting today until 7 at the latest. That said, I'll see if I can get this page a bit cleaner and divided better based on topics. Do we have the wireless modules/ARM dev kits so that we can start testing? It'd be great to have a testbed for the wireless itself so we can try out different protocol ideas. Here's a question I'll pose to you guys though: how reliable do we want the protocol to be? If it's very reliable, we'd have things like retransmission of packets and such that'd make sure each command got to the robots, but we might lose some of that "real-time" aspect in the process. If it's unreliable, we can be as real-time as we want but we'd have to make sure the robots could deal with some dropped/lost packets. [[User:ScottT|ScottT]] 16:22, 25 September 2006 (EDT)

* 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 completely agree. Just making sure that I wasn't assuming we'd have higher-level languages when all we could actually use was assembly. :P [[User:ScottT|ScottT]] 16:22, 25 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)

* 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. [[User:ScottT|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. [[User:Marksp|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. [[User:ScottT|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? [[User:ScottT|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. [[User:ScottT|ScottT]] 22:20, 19 September 2006 (EDT)

RCwiproc

2006-10-02T23:25:12Z

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

Talk:RCwiproc

2006-10-02T21:05:40Z

ScottT: Thoughts on wireless transmission schemes

* I've been looking into the issue of how/when the robots/host should be sending data over the wireless. I suggest that we go about it one of two ways... the first/easiest being keeping every transmitter/station in sync and devoting specific times during a cycle for each of the robots and the host to use the channel. Essentially, divide a ~14-20ms space of time between the 5 robots and the host depending how much they need to transmit (host packets may be larger than robot packets...). While this would work, it's inefficient in using the channel if not every robot needs to trasmit during a cycle. The second way would be something close to [[http://en.wikipedia.org/wiki/CSMA-CD CSMA/CD]] (Carrier Sense Multiple Access with Collision Detection). This works by checking the channel to see if it's free and also checking to see if, while transmitting, a collision occurs and to handle such an event accordingly. This would be a more efficient use of the available time on the channel however, it would be more complicated. We could work it to give the host precidence over the robots to transmit, possibly. There is, of course, the option of using two wireless modules on every station to allow different Tx/Rx channels. The host could be constantly transmitting over it's Tx channel while listening for any robots on the Rx channel. Meanwhile, the robots would be constantly listening on their Rx channels (same freq as host Tx) and transmit when necessary over their Tx channels (same freq as host Rx). I believe this would provide the most efficient use of the channels and would free us from worrying about the host transmissions getting in collisions with robot transmissions. We could also implement the CSMA/CD scheme on the robot Tx/host Rx channel so that the robots can make efficient use of their available bandwidth in communicating with the host. Any or all of these schemes should work and, time permitting, I think we should try and test them all to see which we like better. The scheme with a single-channel and time divided transmissions between host and robots would likely be the simplest to implement... the main problem there may be keeping the timing constant. What do you guys think? [[User:ScottT|ScottT]] 17:05, 2 October 2006 (EDT)

* I'll be at the meeting today until 7 at the latest. That said, I'll see if I can get this page a bit cleaner and divided better based on topics. Do we have the wireless modules/ARM dev kits so that we can start testing? It'd be great to have a testbed for the wireless itself so we can try out different protocol ideas. Here's a question I'll pose to you guys though: how reliable do we want the protocol to be? If it's very reliable, we'd have things like retransmission of packets and such that'd make sure each command got to the robots, but we might lose some of that "real-time" aspect in the process. If it's unreliable, we can be as real-time as we want but we'd have to make sure the robots could deal with some dropped/lost packets. [[User:ScottT|ScottT]] 16:22, 25 September 2006 (EDT)

* 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 completely agree. Just making sure that I wasn't assuming we'd have higher-level languages when all we could actually use was assembly. :P [[User:ScottT|ScottT]] 16:22, 25 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)

* 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. [[User:ScottT|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. [[User:Marksp|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. [[User:ScottT|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? [[User:ScottT|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. [[User:ScottT|ScottT]] 22:20, 19 September 2006 (EDT)

Talk:RCwiproc

2006-09-25T20:22:23Z

ScottT: Added some comments

* I'll be at the meeting today until 7 at the latest. That said, I'll see if I can get this page a bit cleaner and divided better based on topics. Do we have the wireless modules/ARM dev kits so that we can start testing? It'd be great to have a testbed for the wireless itself so we can try out different protocol ideas. Here's a question I'll pose to you guys though: how reliable do we want the protocol to be? If it's very reliable, we'd have things like retransmission of packets and such that'd make sure each command got to the robots, but we might lose some of that "real-time" aspect in the process. If it's unreliable, we can be as real-time as we want but we'd have to make sure the robots could deal with some dropped/lost packets. [[User:ScottT|ScottT]] 16:22, 25 September 2006 (EDT)

* 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 completely agree. Just making sure that I wasn't assuming we'd have higher-level languages when all we could actually use was assembly. :P [[User:ScottT|ScottT]] 16:22, 25 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)

* 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. [[User:ScottT|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. [[User:Marksp|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. [[User:ScottT|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? [[User:ScottT|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. [[User:ScottT|ScottT]] 22:20, 19 September 2006 (EDT)

RCwiproc

2006-09-25T20:13:07Z

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

==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==
'''MOVED TO [[Talk:RCwiproc|DISCUSSION PAGE]] (discussion tab up top, or just click that link)''' [[User:ScottT|ScottT]]

==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? 
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.
 
{| cellspacing="1"
|-
|Byte 1|| Byte 2||Bytes 3 up to 17||Last Byte
|-
! width="200" bgcolor="#909090"|Header (1 byte)
! width="240" bgcolor="#909090"|ID (3 bits) Length (5 bits)
! width="280" bgcolor="#d0d0d0"|Data (0 - 15 bytes)
! width ="200" bgcolor="#909090"|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:
 
{| 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)
|}
 

{| style="text-align:left; width:100%; height:300px" cellspacing="0" cellpadding="5"
|+ '''Host to Robot Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Wakeup
| 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" | Individual robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Byte 1 Robot ID
| 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:#909090" | Go/Start
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x02
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Intiates main process on robots.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Data
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x03
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 15
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | See below
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Streaming data sent to all robots in one msg.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Game Reset
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x04
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| 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;" | Ends the main process on all robots. Reverts them back to wakeup state.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Shoot Ball
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x05
| 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;" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID (1 byte) Robot Angle (1 byte)
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands the robot with ID given to take the shot.
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Robot Stop
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x06
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands an indivdual robot to stop. May not be used.
|}
With the format for the Data messages being defined as:
 
{| 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)
|}
 
 
{| style="text-align:left; width:100%; height:100px" cellspacing="0" cellpadding="5"
|+ '''Robot to Host Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Status
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0xA
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Host
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 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==
*[http://www.linxtechnologies.com/documents/AN-00160.pdf Linx article on protocol design]
*[http://focus-webapps.ti.com/general/docs/sitesearch/searchsite.tsp?searchTerm=serial%20RS232%20drivers&selectedTopic=1077383935&numRecords=25 TI Example wireless system design protocol and all]
*[http://www.mathpages.com/home/kmath458.htm Paper on the Cylical Redundancy Check error checking algorithm (CRC)]
*[http://spinroot.com/spin/Doc/Book91.html Enitre book on protocol design, a bit dated though like 1990 dated]
*[http://bwrc.eecs.berkeley.edu/People/Faculty/jan/publications/p124.pdf Berkeley article on wireless protocol design. Gives a real world example of how to design a wireless protocol.]
*[http://www.ohiolink.edu/etd/send-pdf.cgi?ohiou1121356426 Ohio University article. Details an intresting communications method]
*[http://www.eetasia.com/ARTICLES/2005JUN/A/2005JUN06_RFD_AN01.PDF Paper from Maxim on Manchester Encoding]
*[http://webs.cs.berkeley.edu/retreat-6-03/slides/ChipconECC.ppt Berkeley PPT on errors and wireless]
*[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]]

Talk:RCwiproc

2006-09-25T20:12:09Z

ScottT: Page created, moved over everything from the comments section

* 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)

* 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)

* 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. [[User:ScottT|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. [[User:Marksp|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. [[User:ScottT|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? [[User:ScottT|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. [[User:ScottT|ScottT]] 22:20, 19 September 2006 (EDT)

RCwiproc

2006-09-24T01:53:42Z

ScottT: /* Comments */

==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. [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)

* 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)

* 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. [[User:ScottT|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. [[User:Marksp|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. [[User:ScottT|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? [[User:ScottT|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. [[User:ScottT|ScottT]] 22:20, 19 September 2006 (EDT)

==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? 
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.
 
{| cellspacing="1"
|-
|Byte 1|| Byte 2||Bytes 3 up to 17||Last Byte
|-
! width="200" bgcolor="#909090"|Header (1 byte)
! width="240" bgcolor="#909090"|ID (3 bits) Length (5 bits)
! width="280" bgcolor="#d0d0d0"|Data (0 - 15 bytes)
! width ="200" bgcolor="#909090"|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:
 
{| 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)
|}
 

{| style="text-align:left; width:100%; height:300px" cellspacing="0" cellpadding="5"
|+ '''Host to Robot Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Wakeup
| 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" | Individual robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Byte 1 Robot ID
| 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:#909090" | Go/Start
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x02
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Intiates main process on robots.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Data
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x03
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 15
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | See below
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Streaming data sent to all robots in one msg.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Game Reset
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x04
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| 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;" | Ends the main process on all robots. Reverts them back to wakeup state.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Shoot Ball
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x05
| 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;" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID (1 byte) Robot Angle (1 byte)
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands the robot with ID given to take the shot.
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Robot Stop
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x06
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands an indivdual robot to stop. May not be used.
|}
With the format for the Data messages being defined as:
 
{| 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)
|}
 
 
{| style="text-align:left; width:100%; height:100px" cellspacing="0" cellpadding="5"
|+ '''Robot to Host Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Status
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0xA
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Host
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 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==
*[http://www.linxtechnologies.com/documents/AN-00160.pdf Linx article on protocol design]
*[http://focus-webapps.ti.com/general/docs/sitesearch/searchsite.tsp?searchTerm=serial%20RS232%20drivers&selectedTopic=1077383935&numRecords=25 TI Example wireless system design protocol and all]
*[http://www.mathpages.com/home/kmath458.htm Paper on the Cylical Redundancy Check error checking algorithm (CRC)]
*[http://spinroot.com/spin/Doc/Book91.html Enitre book on protocol design, a bit dated though like 1990 dated]
*[http://bwrc.eecs.berkeley.edu/People/Faculty/jan/publications/p124.pdf Berkeley article on wireless protocol design. Gives a real world example of how to design a wireless protocol.]
*[http://www.ohiolink.edu/etd/send-pdf.cgi?ohiou1121356426 Ohio University article. Details an intresting communications method]
*[http://www.eetasia.com/ARTICLES/2005JUN/A/2005JUN06_RFD_AN01.PDF Paper from Maxim on Manchester Encoding]
*[http://webs.cs.berkeley.edu/retreat-6-03/slides/ChipconECC.ppt Berkeley PPT on errors and wireless]
*[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]]

RCwiproc

2006-09-20T22:59:18Z

ScottT: /* Comments */

==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 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. [[User:ScottT|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 sametime. The wireless signal that the host will recieve will be the ananlog 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. [[User:Marksp|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. [[User:ScottT|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? [[User:ScottT|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. [[User:ScottT|ScottT]] 22:20, 19 September 2006 (EDT)

==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? 
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.
 
{| cellspacing="1"
|-
|Byte 1|| Byte 2||Bytes 3 up to 17||Last Byte
|-
! width="200" bgcolor="#909090"|Header (1 byte)
! width="240" bgcolor="#909090"|ID (3 bits) Length (5 bits)
! width="280" bgcolor="#d0d0d0"|Data (0 - 15 bytes)
! width ="200" bgcolor="#909090"|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:
 
{| 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)
|}
 

{| style="text-align:left; width:100%; height:300px" cellspacing="0" cellpadding="5"
|+ '''Host to Robot Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Wakeup
| 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" | Individual robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Byte 1 Robot ID
| 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:#909090" | Go/Start
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x02
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Intiates main process on robots.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Data
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x03
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 15
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | See below
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Streaming data sent to all robots in one msg.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Game Reset
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x04
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| 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;" | Ends the main process on all robots. Reverts them back to wakeup state.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Shoot Ball
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x05
| 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;" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID (1 byte) Robot Angle (1 byte)
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands the robot with ID given to take the shot.
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Robot Stop
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x06
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands an indivdual robot to stop. May not be used.
|}
With the format for the Data messages being defined as:
 
{| 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)
|}
 
 
{| style="text-align:left; width:100%; height:100px" cellspacing="0" cellpadding="5"
|+ '''Robot to Host Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Status
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0xA
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Host
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 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==
*[http://www.linxtechnologies.com/documents/AN-00160.pdf Linx article on protocol design]
*[http://focus-webapps.ti.com/general/docs/sitesearch/searchsite.tsp?searchTerm=serial%20RS232%20drivers&selectedTopic=1077383935&numRecords=25 TI Example wireless system design protocol and all]
*[http://www.mathpages.com/home/kmath458.htm Paper on the Cylical Redundancy Check error checking algorithm (CRC)]
*[http://spinroot.com/spin/Doc/Book91.html Enitre book on protocol design, a bit dated though like 1990 dated]
*[http://bwrc.eecs.berkeley.edu/People/Faculty/jan/publications/p124.pdf Berkeley article on wireless protocol design. Gives a real world example of how to design a wireless protocol.]
*[http://www.ohiolink.edu/etd/send-pdf.cgi?ohiou1121356426 Ohio University article. Details an intresting communications method]
*[http://www.eetasia.com/ARTICLES/2005JUN/A/2005JUN06_RFD_AN01.PDF Paper from Maxim on Manchester Encoding]
*[http://webs.cs.berkeley.edu/retreat-6-03/slides/ChipconECC.ppt Berkeley PPT on errors and wireless]
*[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]]

RCwiproc

2006-09-20T04:48:19Z

ScottT: /* Comments */ New thoughts

==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==
* 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. [[User:ScottT|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? [[User:ScottT|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. [[User:ScottT|ScottT]] 22:20, 19 September 2006 (EDT)

==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? 
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.
 
{| cellspacing="1"
|-
|Byte 1|| Byte 2||Bytes 3 up to 17||Last Byte
|-
! width="200" bgcolor="#909090"|Header (1 byte)
! width="240" bgcolor="#909090"|ID (3 bits) Length (5 bits)
! width="280" bgcolor="#d0d0d0"|Data (0 - 15 bytes)
! width ="200" bgcolor="#909090"|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:
 
{| 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)
|}
 

{| style="text-align:left; width:100%; height:300px" cellspacing="0" cellpadding="5"
|+ '''Host to Robot Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Wakeup
| 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" | Individual robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Byte 1 Robot ID
| 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:#909090" | Go/Start
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x02
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Intiates main process on robots.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Data
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x03
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 15
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | See below
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Streaming data sent to all robots in one msg.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Game Reset
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x04
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| 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;" | Ends the main process on all robots. Reverts them back to wakeup state.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Shoot Ball
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x05
| 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;" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID (1 byte) Robot Angle (1 byte)
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands the robot with ID given to take the shot.
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Robot Stop
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x06
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands an indivdual robot to stop. May not be used.
|}
With the format for the Data messages being defined as:
 
{| 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)
|}
 
 
{| style="text-align:left; width:100%; height:100px" cellspacing="0" cellpadding="5"
|+ '''Robot to Host Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Status
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0xA
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Host
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 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==
*[http://www.linxtechnologies.com/documents/AN-00160.pdf Linx article on protocol design]
*[http://focus-webapps.ti.com/general/docs/sitesearch/searchsite.tsp?searchTerm=serial%20RS232%20drivers&selectedTopic=1077383935&numRecords=25 TI Example wireless system design protocol and all]
*[http://www.mathpages.com/home/kmath458.htm Paper on the Cylical Redundancy Check error checking algorithm (CRC)]
*[http://spinroot.com/spin/Doc/Book91.html Enitre book on protocol design, a bit dated though like 1990 dated]
*[http://bwrc.eecs.berkeley.edu/People/Faculty/jan/publications/p124.pdf Berkeley article on wireless protocol design. Gives a real world example of how to design a wireless protocol.]
*[http://www.ohiolink.edu/etd/send-pdf.cgi?ohiou1121356426 Ohio University article. Details an intresting communications method]
*[http://www.eetasia.com/ARTICLES/2005JUN/A/2005JUN06_RFD_AN01.PDF Paper from Maxim on Manchester Encoding]
*[http://webs.cs.berkeley.edu/retreat-6-03/slides/ChipconECC.ppt Berkeley PPT on errors and wireless]
*[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]]

RCwiproc

2006-09-20T02:23:00Z

ScottT: /* Comments */ - posing a question

==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==
* Do the robots implement any kind of checking on whether or not their wheels are jammed? Or other mechanical/electrical errors? [[User:ScottT|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. [[User:ScottT|ScottT]] 22:20, 19 September 2006 (EDT)

==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? 
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.
 
{| cellspacing="1"
|-
|Byte 1|| Byte 2||Bytes 3 up to 17||Last Byte
|-
! width="200" bgcolor="#909090"|Header (1 byte)
! width="240" bgcolor="#909090"|ID (3 bits) Length (5 bits)
! width="280" bgcolor="#d0d0d0"|Data (0 - 15 bytes)
! width ="200" bgcolor="#909090"|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:
 
{| 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)
|}
 

{| style="text-align:left; width:100%; height:300px" cellspacing="0" cellpadding="5"
|+ '''Host to Robot Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Wakeup
| 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" | Individual robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Byte 1 Robot ID
| 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:#909090" | Go/Start
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x02
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Intiates main process on robots.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Data
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x03
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 15
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | See below
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Streaming data sent to all robots in one msg.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Game Reset
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x04
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| 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;" | Ends the main process on all robots. Reverts them back to wakeup state.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Shoot Ball
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x05
| 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;" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID (1 byte) Robot Angle (1 byte)
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands the robot with ID given to take the shot.
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Robot Stop
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x06
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands an indivdual robot to stop. May not be used.
|}
With the format for the Data messages being defined as:
 
{| 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)
|}
 
 
{| style="text-align:left; width:100%; height:100px" cellspacing="0" cellpadding="5"
|+ '''Robot to Host Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Status
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0xA
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Host
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 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==
*[http://www.linxtechnologies.com/documents/AN-00160.pdf Linx article on protocol design]
*[http://focus-webapps.ti.com/general/docs/sitesearch/searchsite.tsp?searchTerm=serial%20RS232%20drivers&selectedTopic=1077383935&numRecords=25 TI Example wireless system design protocol and all]
*[http://www.mathpages.com/home/kmath458.htm Paper on the Cylical Redundancy Check error checking algorithm (CRC)]
*[http://spinroot.com/spin/Doc/Book91.html Enitre book on protocol design, a bit dated though like 1990 dated]
*[http://bwrc.eecs.berkeley.edu/People/Faculty/jan/publications/p124.pdf Berkeley article on wireless protocol design. Gives a real world example of how to design a wireless protocol.]
*[http://www.ohiolink.edu/etd/send-pdf.cgi?ohiou1121356426 Ohio University article. Details an intresting communications method]
*[http://www.eetasia.com/ARTICLES/2005JUN/A/2005JUN06_RFD_AN01.PDF Paper from Maxim on Manchester Encoding]
*[http://webs.cs.berkeley.edu/retreat-6-03/slides/ChipconECC.ppt Berkeley PPT on errors and wireless]
*[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]]

RCwiproc

2006-09-20T02:20:29Z

ScottT: Added comments section and a comment. We could use the discussion page for this... but I dunno how many people would check there.

==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==
* 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. [[User:ScottT|ScottT]] 22:20, 19 September 2006 (EDT)

==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? 
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.
 
{| cellspacing="1"
|-
|Byte 1|| Byte 2||Bytes 3 up to 17||Last Byte
|-
! width="200" bgcolor="#909090"|Header (1 byte)
! width="240" bgcolor="#909090"|ID (3 bits) Length (5 bits)
! width="280" bgcolor="#d0d0d0"|Data (0 - 15 bytes)
! width ="200" bgcolor="#909090"|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:
 
{| 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)
|}
 

{| style="text-align:left; width:100%; height:300px" cellspacing="0" cellpadding="5"
|+ '''Host to Robot Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Wakeup
| 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" | Individual robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Byte 1 Robot ID
| 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:#909090" | Go/Start
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x02
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Intiates main process on robots.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Data
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x03
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 15
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | See below
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Streaming data sent to all robots in one msg.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Game Reset
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x04
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | All robots
| 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;" | Ends the main process on all robots. Reverts them back to wakeup state.
|-

! style="border:.5px solid black; border-bottom:0px; background:#909090" | Shoot Ball
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x05
| 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;" | 1
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID (1 byte) Robot Angle (1 byte)
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands the robot with ID given to take the shot.
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Robot Stop
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0x06
| 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;" | 0
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Robot ID
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Commands an indivdual robot to stop. May not be used.
|}
With the format for the Data messages being defined as:
 
{| 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)
|}
 
 
{| style="text-align:left; width:100%; height:100px" cellspacing="0" cellpadding="5"
|+ '''Robot to Host Messages'''
|-style="border:1px solid black; border-bottom:0px; background:#909090"
! style="border:1px solid black;border-bottom:1px"|MsgID !! style="border:1px solid black;border-bottom:0px"|ID !! style="border:1px solid black;border-bottom:0px"|ACK? !! style="border:1px solid black;border-bottom:0px"|To
!! style="border:1px solid black;border-bottom:0px"|DLC !! style="border:1px solid black;border-bottom:0px"|Data Format !! style="border:1px solid black;border-bottom:0px"|Description
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Status
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 0xA
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | No
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Host
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | None
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 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==
*[http://www.linxtechnologies.com/documents/AN-00160.pdf Linx article on protocol design]
*[http://focus-webapps.ti.com/general/docs/sitesearch/searchsite.tsp?searchTerm=serial%20RS232%20drivers&selectedTopic=1077383935&numRecords=25 TI Example wireless system design protocol and all]
*[http://www.mathpages.com/home/kmath458.htm Paper on the Cylical Redundancy Check error checking algorithm (CRC)]
*[http://spinroot.com/spin/Doc/Book91.html Enitre book on protocol design, a bit dated though like 1990 dated]
*[http://bwrc.eecs.berkeley.edu/People/Faculty/jan/publications/p124.pdf Berkeley article on wireless protocol design. Gives a real world example of how to design a wireless protocol.]
*[http://www.ohiolink.edu/etd/send-pdf.cgi?ohiou1121356426 Ohio University article. Details an intresting communications method]
*[http://www.eetasia.com/ARTICLES/2005JUN/A/2005JUN06_RFD_AN01.PDF Paper from Maxim on Manchester Encoding]
*[http://webs.cs.berkeley.edu/retreat-6-03/slides/ChipconECC.ppt Berkeley PPT on errors and wireless]
*[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]]

RCmicro

2006-09-20T01:52:13Z

ScottT: /* Links */

RCmicro

2006-09-20T01:51:33Z

ScottT: /* Links */ - need to use the preview button more...

The microprocessor is the heart of the 2007 robojackets robocup competition robot and acts as the interface between the wireless communication system and the robot proper. A simple firmware program monitoring the internal sensors of the robot and controling the motor and ball roller/shoot will run on the micro. Currently as part of our phase one objectives we are looking closly at processors from Atmel, SI Labs, Motorola, and PICs. Below are some specs.
==The Wall==
9/14/06 - We chose a dev kit see the sparkfun link below. It'll cost $64.95 a pop and we are getting 3.

==To Do==
*Finalize number of I/O and type (SPI, PWM, ADC, etc)
*Design Schematic tying in all devices
*Breadboard to test write simple code
*Get board made
*Write Code

==Specifications==
{| style="text-align:center;" cellspacing="0" cellpadding="5"
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Device
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 32-bit microprocessor
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Power
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3.3V Low pwt
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Archetecture
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | ARM
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Clock
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | >50 MHz
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Memory
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Flash 128Kb
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | IO pins
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 32-64 pins Software Configurable
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Interfaces
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | SPI, UART
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | DA/AD
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | (3)10-bit DAC (2)10/16-bit ADC
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Timers
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 8-bit (3)
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | PWM
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 4 channels
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Programming
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | JTAG or Bootloader
|-
! style="border:.5px solid black; background:#909090" |
| style="border:.5px solid black; background:#d0d0d0" |
|}

==Schematics==
Schematics
==Articles==
*[http://direct.xilinx.com/bvdocs/whitepapers/wp123.pdf Article on Interfacing ARM processors and FPGAs]
*[http://tech.groups.yahoo.com/group/lpc2000/ Yahoo group about just the LPC ARM from Phillips]

==Possible Micros==
Phillips LPC
*[http://www.sparkfun.com/commerce/product_info.php?products_id=266 Sparkfun dev kit]
*[http://www.standardics.nxp.com/literature/leaflets/microcontrollers/pdf/lpc213x.pdf Phillips LPC213x series ARMs. Less memory than the LPC221x series but lower-power consumption and smaller footprint. Its still every bit as capable]
*[http://www.nxp.com/acrobat_download/literature/9397/75014627.pdf Phillips LPC221x series ARMs. More memory vs LPC2213x. COntains everything we need.]
*[http://www.lpctools.com/index.asp?PageAction=VIEWPROD&ProdID=54 Dev kit for LPC213x series $149.00. 2 issues: Do we have a JTAG programmer and if so will it fit the pin-out of this device?]
AVR32
*[http://www.atmel.com/products/AVR32/ ATMEL's answer to the ARM. Has everything '''including''' the kitchen sink.]

==Links==
*[http://www.skyeye.org/index.shtml ARM processor simulator for Linux] - might be able to use this to test things, but I'm not sure it would be better than just taking home a dev board. :P [[User:ScottT|ScottT]]
*[http://www.open-research.org.uk/ARMuC/ ARM Wiki] - Good page with a lot of ARM resources/links. [[User:ScottT|ScottT]]
*[http://www.heyrick.co.uk/assembler/qfinder.html Page of ARM processor instructions]
*[http://www.arm.com/support/training/type4680.html Apparently free ARM course] - Not sure how useful this could be. [[User:ScottT|ScottT]]
*[[RCfirmware|Firmware]]
 
[[RobocupElectrical|Electrical Homepage]]

RCmicro

2006-09-20T01:50:09Z

ScottT: /* Links */ - ARM processor simulator

The microprocessor is the heart of the 2007 robojackets robocup competition robot and acts as the interface between the wireless communication system and the robot proper. A simple firmware program monitoring the internal sensors of the robot and controling the motor and ball roller/shoot will run on the micro. Currently as part of our phase one objectives we are looking closly at processors from Atmel, SI Labs, Motorola, and PICs. Below are some specs.
==The Wall==
9/14/06 - We chose a dev kit see the sparkfun link below. It'll cost $64.95 a pop and we are getting 3.

==To Do==
*Finalize number of I/O and type (SPI, PWM, ADC, etc)
*Design Schematic tying in all devices
*Breadboard to test write simple code
*Get board made
*Write Code

==Specifications==
{| style="text-align:center;" cellspacing="0" cellpadding="5"
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Device
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 32-bit microprocessor
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Power
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3.3V Low pwt
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Archetecture
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | ARM
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Clock
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | >50 MHz
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Memory
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Flash 128Kb
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | IO pins
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 32-64 pins Software Configurable
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Interfaces
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | SPI, UART
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | DA/AD
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | (3)10-bit DAC (2)10/16-bit ADC
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Timers
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 8-bit (3)
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | PWM
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 4 channels
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Programming
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | JTAG or Bootloader
|-
! style="border:.5px solid black; background:#909090" |
| style="border:.5px solid black; background:#d0d0d0" |
|}

==Schematics==
Schematics
==Articles==
*[http://direct.xilinx.com/bvdocs/whitepapers/wp123.pdf Article on Interfacing ARM processors and FPGAs]
*[http://tech.groups.yahoo.com/group/lpc2000/ Yahoo group about just the LPC ARM from Phillips]

==Possible Micros==
Phillips LPC
*[http://www.sparkfun.com/commerce/product_info.php?products_id=266 Sparkfun dev kit]
*[http://www.standardics.nxp.com/literature/leaflets/microcontrollers/pdf/lpc213x.pdf Phillips LPC213x series ARMs. Less memory than the LPC221x series but lower-power consumption and smaller footprint. Its still every bit as capable]
*[http://www.nxp.com/acrobat_download/literature/9397/75014627.pdf Phillips LPC221x series ARMs. More memory vs LPC2213x. COntains everything we need.]
*[http://www.lpctools.com/index.asp?PageAction=VIEWPROD&ProdID=54 Dev kit for LPC213x series $149.00. 2 issues: Do we have a JTAG programmer and if so will it fit the pin-out of this device?]
AVR32
*[http://www.atmel.com/products/AVR32/ ATMEL's answer to the ARM. Has everything '''including''' the kitchen sink.]

==Links==
* [http://www.skyeye.org/index.shtml] ARM processor simulator for Linux - might be able to use this to test things, but I'm not sure it would be better than just taking home a dev board. :P [[User:ScottT|ScottT]]
*[http://www.open-research.org.uk/ARMuC/ ARM Wiki] - Good page with a lot of ARM resources/links. [[User:ScottT|ScottT]]
*[http://www.heyrick.co.uk/assembler/qfinder.html Page of ARM processor instructions]
*[http://www.arm.com/support/training/type4680.html Apparently free ARM course] - Not sure how useful this could be. [[User:ScottT|ScottT]]
*[[RCfirmware|Firmware]]
 
[[RobocupElectrical|Electrical Homepage]]

RoboCup

2006-09-19T04:40:00Z

ScottT: /* Announcements */ - New links

[[Image:Robocup.jpg|thumb|350px|right|Apologies Somethingawful.com]]

Welcome to the '''[http://www.gatech.edu/ Georgia Tech]''' '''[http://www.robojackets.org/ Robojackets]''' '''[http://www.robocup.org/ RoboCup]''' wiki!
We meet weekly on Monday and Thursday at 6PM in the [http://gtalumni.org/campusmap/ Tin Building] (building #48 on the map - Mechanical Engineering Research Building) though the meeting time may change this summer.

==Announcements==
* 09/19/06 Added some ARM programming/reference links to the [[RCmicro|Microcontroller]] page. [[User:ScottT|ScottT]] 00:40, 19 September 2006 (EDT)
* 09/04/06 Finished protocol design still needs some tweak, input is welcome. Moving on to motion system. Oh yeah we need a name for our team or should RoboJackets suffice?--[[USER:Marksp|Phillip]]
* 08/08/06 Finally put down on paper and wiki the protocol design. Will add some more pics and give more detail as time goes on. Next up wireless hardware. --[[USER:Marksp|Phillip]]
* 05/31/06 Would someone (I think Phil or Ryan) please email or post the general roadmap so the other teams can add it to their page?
* 05/06/06 Found a mailing list for small size hosted by the CoC [https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small here]

* 04/18/06 The RoboCup US Open will be held this weekend at Georgia Tech see this website for details: http://www.robocup-us.org/

==Important Items==
*'''[http://www.cs.cmu.edu/~brettb/robocup/rules/f180rules2006.html Official Rules]
* '''[[General Project Roadmap]]'''
* [[USOpen notes]]
* [http://www.cs.uml.edu/~holly/91.549/readings/tla.pdf On Three Layer Architecture (the article Andy sent out)]

== Systems ==
* [[RobocupElectrical|Electrical System Information]]
** [[RCMotion|Motion Control]]
** [[RCcoms|Communication (Wireless/Wired)]]
***[[RCwiproc|Wireless Protocol]]
***[[RCwicoprocessor|Wireless Co-processor]]
** [[RCsensors|Sensors]]
** [[RCmicro|Microprocessor]]
** [[RCpower|Power]]
** [[RCmotor|Motor System]]
** [[RCroller_shooter|Roller/Shooter]]
* [[RobocupVision|Vision System Information]]
** [[RCCamera|Robocup Image Acquisition]]
** [[RCVisSoftware|Robocup Image Processing]]
* [[RobocupSoftware|Software System Information]]
* [[RobocupMechanical|Mechanical System Information]]

==Links==
* [http://www.cs.cmu.edu/~brettb/robocup/#movies Small size resource page] - link dump, very good!!!
* [http://robocup.mae.cornell.edu/ Cornell Big Red] very good technical documentation!! Check out the ME writeups!
* [http://www.cs.cmu.edu/~robosoccer/small CMU webpage - great resource]

RCmicro

2006-09-19T04:20:31Z

ScottT: /* Links */ - ARM Wiki link. Reorganized links.

The microprocessor is the heart of the 2007 robojackets robocup competition robot and acts as the interface between the wireless communication system and the robot proper. A simple firmware program monitoring the internal sensors of the robot and controling the motor and ball roller/shoot will run on the micro. Currently as part of our phase one objectives we are looking closly at processors from Atmel, SI Labs, Motorola, and PICs. Below are some specs.
==The Wall==
9/14/06 - We chose a dev kit see the sparkfun link below. It'll cost $64.95 a pop and we are getting 3.

==To Do==
*Finalize number of I/O and type (SPI, PWM, ADC, etc)
*Design Schematic tying in all devices
*Breadboard to test write simple code
*Get board made
*Write Code

==Specifications==
{| style="text-align:center;" cellspacing="0" cellpadding="5"
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Device
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 32-bit microprocessor
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Power
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3.3V Low pwt
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Archetecture
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | ARM
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Clock
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | >50 MHz
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Memory
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Flash 128Kb
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | IO pins
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 32-64 pins Software Configurable
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Interfaces
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | SPI, UART
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | DA/AD
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | (3)10-bit DAC (2)10/16-bit ADC
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Timers
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 8-bit (3)
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | PWM
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 4 channels
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Programming
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | JTAG or Bootloader
|-
! style="border:.5px solid black; background:#909090" |
| style="border:.5px solid black; background:#d0d0d0" |
|}

==Schematics==
Schematics
==Articles==
*[http://direct.xilinx.com/bvdocs/whitepapers/wp123.pdf Article on Interfacing ARM processors and FPGAs]
*[http://tech.groups.yahoo.com/group/lpc2000/ Yahoo group about just the LPC ARM from Phillips]

==Possible Micros==
Phillips LPC
*[http://www.sparkfun.com/commerce/product_info.php?products_id=266 Sparkfun dev kit]
*[http://www.standardics.nxp.com/literature/leaflets/microcontrollers/pdf/lpc213x.pdf Phillips LPC213x series ARMs. Less memory than the LPC221x series but lower-power consumption and smaller footprint. Its still every bit as capable]
*[http://www.nxp.com/acrobat_download/literature/9397/75014627.pdf Phillips LPC221x series ARMs. More memory vs LPC2213x. COntains everything we need.]
*[http://www.lpctools.com/index.asp?PageAction=VIEWPROD&ProdID=54 Dev kit for LPC213x series $149.00. 2 issues: Do we have a JTAG programmer and if so will it fit the pin-out of this device?]
AVR32
*[http://www.atmel.com/products/AVR32/ ATMEL's answer to the ARM. Has everything '''including''' the kitchen sink.]

==Links==
*[http://www.open-research.org.uk/ARMuC/ ARM Wiki] - Good page with a lot of ARM resources/links. [[User:ScottT|ScottT]]
*[http://www.heyrick.co.uk/assembler/qfinder.html Page of ARM processor instructions]
*[http://www.arm.com/support/training/type4680.html Apparently free ARM course] - Not sure how useful this could be. [[User:ScottT|ScottT]]
*[[RCfirmware|Firmware]]
 
[[RobocupElectrical|Electrical Homepage]]

RCmicro

2006-09-19T04:09:08Z

ScottT: /* Links */ Added link to online ARM course

The microprocessor is the heart of the 2007 robojackets robocup competition robot and acts as the interface between the wireless communication system and the robot proper. A simple firmware program monitoring the internal sensors of the robot and controling the motor and ball roller/shoot will run on the micro. Currently as part of our phase one objectives we are looking closly at processors from Atmel, SI Labs, Motorola, and PICs. Below are some specs.
==The Wall==
9/14/06 - We chose a dev kit see the sparkfun link below. It'll cost $64.95 a pop and we are getting 3.

==To Do==
*Finalize number of I/O and type (SPI, PWM, ADC, etc)
*Design Schematic tying in all devices
*Breadboard to test write simple code
*Get board made
*Write Code

==Specifications==
{| style="text-align:center;" cellspacing="0" cellpadding="5"
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Device
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 32-bit microprocessor
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Power
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3.3V Low pwt
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Archetecture
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | ARM
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Clock
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | >50 MHz
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Memory
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Flash 128Kb
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | IO pins
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 32-64 pins Software Configurable
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Interfaces
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | SPI, UART
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | DA/AD
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | (3)10-bit DAC (2)10/16-bit ADC
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Timers
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 8-bit (3)
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | PWM
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 4 channels
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Programming
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | JTAG or Bootloader
|-
! style="border:.5px solid black; background:#909090" |
| style="border:.5px solid black; background:#d0d0d0" |
|}

==Schematics==
Schematics
==Articles==
*[http://direct.xilinx.com/bvdocs/whitepapers/wp123.pdf Article on Interfacing ARM processors and FPGAs]
*[http://tech.groups.yahoo.com/group/lpc2000/ Yahoo group about just the LPC ARM from Phillips]

==Possible Micros==
Phillips LPC
*[http://www.sparkfun.com/commerce/product_info.php?products_id=266 Sparkfun dev kit]
*[http://www.standardics.nxp.com/literature/leaflets/microcontrollers/pdf/lpc213x.pdf Phillips LPC213x series ARMs. Less memory than the LPC221x series but lower-power consumption and smaller footprint. Its still every bit as capable]
*[http://www.nxp.com/acrobat_download/literature/9397/75014627.pdf Phillips LPC221x series ARMs. More memory vs LPC2213x. COntains everything we need.]
*[http://www.lpctools.com/index.asp?PageAction=VIEWPROD&ProdID=54 Dev kit for LPC213x series $149.00. 2 issues: Do we have a JTAG programmer and if so will it fit the pin-out of this device?]
AVR32
*[http://www.atmel.com/products/AVR32/ ATMEL's answer to the ARM. Has everything '''including''' the kitchen sink.]

==Links==
*[[RCfirmware|Firmware]]
*[http://www.heyrick.co.uk/assembler/qfinder.html Page of ARM processor instructions]
*[http://www.arm.com/support/training/type4680.html Apparently free ARM course] - Not sure how useful this could be. [[User:ScottT|Scott]]
 
[[RobocupElectrical|Electrical Homepage]]

RCmicro

2006-09-19T04:03:16Z

ScottT: /* Links */ - Fixing link... learning WikiCode...

The microprocessor is the heart of the 2007 robojackets robocup competition robot and acts as the interface between the wireless communication system and the robot proper. A simple firmware program monitoring the internal sensors of the robot and controling the motor and ball roller/shoot will run on the micro. Currently as part of our phase one objectives we are looking closly at processors from Atmel, SI Labs, Motorola, and PICs. Below are some specs.
==The Wall==
9/14/06 - We chose a dev kit see the sparkfun link below. It'll cost $64.95 a pop and we are getting 3.

==To Do==
*Finalize number of I/O and type (SPI, PWM, ADC, etc)
*Design Schematic tying in all devices
*Breadboard to test write simple code
*Get board made
*Write Code

==Specifications==
{| style="text-align:center;" cellspacing="0" cellpadding="5"
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Device
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 32-bit microprocessor
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Power
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3.3V Low pwt
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Archetecture
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | ARM
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Clock
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | >50 MHz
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Memory
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Flash 128Kb
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | IO pins
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 32-64 pins Software Configurable
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Interfaces
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | SPI, UART
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | DA/AD
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | (3)10-bit DAC (2)10/16-bit ADC
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Timers
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 8-bit (3)
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | PWM
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 4 channels
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Programming
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | JTAG or Bootloader
|-
! style="border:.5px solid black; background:#909090" |
| style="border:.5px solid black; background:#d0d0d0" |
|}

==Schematics==
Schematics
==Articles==
*[http://direct.xilinx.com/bvdocs/whitepapers/wp123.pdf Article on Interfacing ARM processors and FPGAs]
*[http://tech.groups.yahoo.com/group/lpc2000/ Yahoo group about just the LPC ARM from Phillips]

==Possible Micros==
Phillips LPC
*[http://www.sparkfun.com/commerce/product_info.php?products_id=266 Sparkfun dev kit]
*[http://www.standardics.nxp.com/literature/leaflets/microcontrollers/pdf/lpc213x.pdf Phillips LPC213x series ARMs. Less memory than the LPC221x series but lower-power consumption and smaller footprint. Its still every bit as capable]
*[http://www.nxp.com/acrobat_download/literature/9397/75014627.pdf Phillips LPC221x series ARMs. More memory vs LPC2213x. COntains everything we need.]
*[http://www.lpctools.com/index.asp?PageAction=VIEWPROD&ProdID=54 Dev kit for LPC213x series $149.00. 2 issues: Do we have a JTAG programmer and if so will it fit the pin-out of this device?]
AVR32
*[http://www.atmel.com/products/AVR32/ ATMEL's answer to the ARM. Has everything '''including''' the kitchen sink.]

==Links==
*[[RCfirmware|Firmware]]
*[http://www.heyrick.co.uk/assembler/qfinder.html Page of ARM processor instructions]
 
[[RobocupElectrical|Electrical Homepage]]

RCmicro

2006-09-19T04:02:07Z

ScottT: /* Links */ - Added ARM processor instruction page

The microprocessor is the heart of the 2007 robojackets robocup competition robot and acts as the interface between the wireless communication system and the robot proper. A simple firmware program monitoring the internal sensors of the robot and controling the motor and ball roller/shoot will run on the micro. Currently as part of our phase one objectives we are looking closly at processors from Atmel, SI Labs, Motorola, and PICs. Below are some specs.
==The Wall==
9/14/06 - We chose a dev kit see the sparkfun link below. It'll cost $64.95 a pop and we are getting 3.

==To Do==
*Finalize number of I/O and type (SPI, PWM, ADC, etc)
*Design Schematic tying in all devices
*Breadboard to test write simple code
*Get board made
*Write Code

==Specifications==
{| style="text-align:center;" cellspacing="0" cellpadding="5"
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Device
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | 32-bit microprocessor
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Power
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3.3V Low pwt
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Archetecture
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | ARM
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Clock
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | >50 MHz
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Memory
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Flash 128Kb
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | IO pins
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 32-64 pins Software Configurable
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Interfaces
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | SPI, UART
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | DA/AD
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | (3)10-bit DAC (2)10/16-bit ADC
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Timers
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 8-bit (3)
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | PWM
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 4 channels
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Programming
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | JTAG or Bootloader
|-
! style="border:.5px solid black; background:#909090" |
| style="border:.5px solid black; background:#d0d0d0" |
|}

==Schematics==
Schematics
==Articles==
*[http://direct.xilinx.com/bvdocs/whitepapers/wp123.pdf Article on Interfacing ARM processors and FPGAs]
*[http://tech.groups.yahoo.com/group/lpc2000/ Yahoo group about just the LPC ARM from Phillips]

==Possible Micros==
Phillips LPC
*[http://www.sparkfun.com/commerce/product_info.php?products_id=266 Sparkfun dev kit]
*[http://www.standardics.nxp.com/literature/leaflets/microcontrollers/pdf/lpc213x.pdf Phillips LPC213x series ARMs. Less memory than the LPC221x series but lower-power consumption and smaller footprint. Its still every bit as capable]
*[http://www.nxp.com/acrobat_download/literature/9397/75014627.pdf Phillips LPC221x series ARMs. More memory vs LPC2213x. COntains everything we need.]
*[http://www.lpctools.com/index.asp?PageAction=VIEWPROD&ProdID=54 Dev kit for LPC213x series $149.00. 2 issues: Do we have a JTAG programmer and if so will it fit the pin-out of this device?]
AVR32
*[http://www.atmel.com/products/AVR32/ ATMEL's answer to the ARM. Has everything '''including''' the kitchen sink.]

==Links==
*[[RCfirmware|Firmware]]
*[[http://www.heyrick.co.uk/assembler/qfinder.html|Page of ARM processor instructions]]
 
[[RobocupElectrical|Electrical Homepage]]

RCroller shooter

2006-07-02T15:21:49Z

ScottT: /* The Wall */

In order to dribble and shoot the ball each robot needs a roller and shooter device. There are several methods to accomplish this as of yet none have been chosen.
==The Wall==
07/02/06 - Just shooting off some ideas here. I read that the CMU team uses three(!) charged capacitors at 200V to drive a custom solonoid and that their shooting can hit the ball at around 35mph... that's ~ 51.3ft/s, 15.65m/s, or 1565cm/s. Do we even have a camera in mind that can capture anything near that fast? More importantly, do they, really? It says they have the smallest 3CCD "prosumer" comcorder from sony... I really don't think that's a crazy-fast FPS camera, so perhaps that's something to consider (that is, worrying more about where the ball is '''likely to go''' rather than where exactly it is while the other team has it). As for the shooter itself, I don't know much about solonoids, but I'll be looking those up soon. I did, however, have a quick idea about what we might could do... I don't know how feasible it would be, but maybe a small device that acts somewhat like a rail gun could be used. We'd take a small metal rod, hook it up so that it can't shoot out the front of the robot, then put it in a tunnel of small coils connected to some capacitors. When the capacitors drain, the coils would propel the rod like 1-1.5 inches out of the robot to hit the ball. It's probably not practical by any means... so I'm looking into other possible solutions as well. ;) -- [[User:ScottT|ScottT]] 11:21, 2 July 2006 (EDT)

==To Do==
*Determine how roller and shooter will work

==Specs-Shooter==
{| style="text-align:center;" cellspacing="0" cellpadding="5"
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Device
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Driver for shooter
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Drive Power
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | ?
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Logic Voltage
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3.3V
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Configuration
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Low-Side
|-
! style="border:.5px solid black; background:#909090" | Package
| style="border:.5px solid black; background:#d0d0d0" | SOIC or PO-SOIC
|}
==Schematics==
Schematics
==Shooter Drivers==
*[http://focus.ti.com/lit/ds/symlink/drv103.pdf TI Solenoid driver, Overcurrent protection, 3A]
*[http://focus.ti.com/lit/ds/symlink/drv102.pdf TI Solenoid driver, Overcurrent protection 2.7A]
*[http://www.st.com/stonline/books/pdf/docs/1332.pdf ST Micro Dual Switch mode Solenoid Driver, 2.5A@40V]

==Articles==
==Links==
[[RobocupElectrical|Electrical Homepage]]

RCroller shooter

2006-07-02T15:19:21Z

ScottT: /* The Wall */ - ideas/comments

In order to dribble and shoot the ball each robot needs a roller and shooter device. There are several methods to accomplish this as of yet none have been chosen.
==The Wall==
07/02/06 - Just shooting off some ideas here. I read that the CMU team uses three(!) charged capacitors at 200V to drive a custom solonoid and that their shooting can hit the ball at around 35mph... that's ~ 51.3ft/s, 15.65m/s, or 1565cm/s. Do we even have a camera in mind that can capture anything near that fast? More importantly, do they, really? It says they have the smallest 3CCD "prosumer" comcorder from sony... I really don't think that's a crazy-fast FPS camera, so perhaps that's something to consider (that is, worrying more about where the ball is '''likely to go''' rather than where exactly it is while the other team has it). As for the shooter itself, I don't know much about solonoids, but I'll be looking those up soon. I did, however, have a quick idea about what we might could do... I don't know how feasible it would be, but maybe a small device that acts somewhat like a rail gun could be used. We'd take a small metal rod, hook it up so that it can't shoot out the front of the robot, then put it in a tunnel of small coils connected to some capacitors. When the capacitors drain, the coils would propel the rod like 1-1.5 inches out of the robot to hit the ball. It's probably not practical by any means... so I'm looking into other possible solutions as well. ;) -Scott

==To Do==
*Determine how roller and shooter will work

==Specs-Shooter==
{| style="text-align:center;" cellspacing="0" cellpadding="5"
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090;" | Device
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0;" | Driver for shooter
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Drive Power
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | ?
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Logic Voltage
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | 3.3V
|-
! style="border:.5px solid black; border-bottom:0px; background:#909090" | Configuration
| style="border:.5px solid black; border-bottom:0px; background:#d0d0d0" | Low-Side
|-
! style="border:.5px solid black; background:#909090" | Package
| style="border:.5px solid black; background:#d0d0d0" | SOIC or PO-SOIC
|}
==Schematics==
Schematics
==Shooter Drivers==
*[http://focus.ti.com/lit/ds/symlink/drv103.pdf TI Solenoid driver, Overcurrent protection, 3A]
*[http://focus.ti.com/lit/ds/symlink/drv102.pdf TI Solenoid driver, Overcurrent protection 2.7A]
*[http://www.st.com/stonline/books/pdf/docs/1332.pdf ST Micro Dual Switch mode Solenoid Driver, 2.5A@40V]

==Articles==
==Links==
[[RobocupElectrical|Electrical Homepage]]

RoboCupElectrical

2006-04-17T03:01:59Z

ScottT: Just... Don't ask...

==The Electrical System==
The electrical system includes all the hardware based on the robot, the host computer, the wireless system, and robot firmware. The objective for the 2007 competition is to create a strong base on which to build future teams. In order to guide us towards that goal we have broken the project up into 5 distinct phases.
* Phase One
** Function description of hardware (Completed)
** Evaluate and specify parts
** Circuit design
** Build schematic for electrical system
* Phase Two
** Begin firmware design
** Purchase prototype parts and board
** Build two prototype boards
** Evaluate performance of prototype
* Phase Three
** Secure founding for full production run.
* Phase Four
** Up schematic and board to rev 2 based on phase two results
** Purchase parts for full run of robots
** Build 10 boards
** Test and debug
*Phase Five
**more revisons if neccesary
** Debug
Currently we are in phase one. We have just completed a functional description of the electrical system and are now evaluating parts for use in the robot.
* [[RCcoms|Communication (Wireless/Wired)]]
* [[RCsensors|Sensors]]
** [[RCtemp|Temperature]]
* [[RCmicro|Microprocessor]]
* [[RCpower|Power]]
** [[RCbattery|Battery]]
* [[RCmotor|Motor System]]

RoboCupElectrical

2006-04-17T02:58:22Z

ScottT:

==The Electrical System==
The electrical system includes all the hardware based on the robot, the host computer, the wireless system, and robot firmware. The objective for the 2007 competition is to create a strong base on which to build future teams. In order to guide us towards that goal we have broken the project up into 5 distinct phases.
* Phase One
** Function description of hardware (Completed)
** Evaluate and specify parts
** Circuit design
** Build schematic for electrical system
* Phase Two
** Begin firmware design
** Purchase prototype parts and board
** Build two prototype boards
** Evaluate performance of prototype
* Phase Three
** Secure founding for full production run.
* Phase Four
** Up schematic and board to rev 2 based on phase two results
** Purchase parts for full run of robots
** Build 10 boards
** Test and debug
*Phase Five
**more revisons if neccesary
** Debug
Currently we are in phase one. We have just completed a functional description of the electrical system and are now evaluating parts for use in the robot.
* [[Communication (Wireless/Wired) RCcoms]]
* [[Sensors RCsensors]]
** [[Temperature RCtemp]]
* [[Microprocessor RCmicro]]
* [[Power RCpower]]
** [[Battery RCbattery]]
* [[Motor System RCmotor]]

RoboCupElectrical

2006-04-17T02:57:58Z

ScottT:

==The Electrical System==
The electrical system includes all the hardware based on the robot, the host computer, the wireless system, and robot firmware. The objective for the 2007 competition is to create a strong base on which to build future teams. In order to guide us towards that goal we have broken the project up into 5 distinct phases.
* Phase One
** Function description of hardware (Completed)
** Evaluate and specify parts
** Circuit design
** Build schematic for electrical system
* Phase Two
** Begin firmware design
** Purchase prototype parts and board
** Build two prototype boards
** Evaluate performance of prototype
* Phase Three
** Secure founding for full production run.
* Phase Four
** Up schematic and board to rev 2 based on phase two results
** Purchase parts for full run of robots
** Build 10 boards
** Test and debug
*Phase Five
**more revisons if neccesary
** Debug
Currently we are in phase one. We have just completed a functional description of the electrical system and are now evaluating parts for use in the robot.
* [Communication (Wireless/Wired) RCcoms]
* [Sensors RCsensors]
** [Temperature RCtemp]
* [Microprocessor RCmicro]
* [Power RCpower]
** [Battery RCbattery]
* [Motor System RCmotor]

RoboCupElectrical

2006-04-17T02:55:40Z

ScottT:

==The Electrical System==
The electrical system includes all the hardware based on the robot, the host computer, the wireless system, and robot firmware. The objective for the 2007 competition is to create a strong base on which to build future teams. In order to guide us towards that goal we have broken the project up into 5 distinct phases.
* Phase One
** Function description of hardware (Completed)
** Evaluate and specify parts
** Circuit design
** Build schematic for electrical system
* Phase Two
** Begin firmware design
** Purchase prototype parts and board
** Build two prototype boards
** Evaluate performance of prototype
* Phase Three
** Secure founding for full production run.
* Phase Four
** Up schematic and board to rev 2 based on phase two results
** Purchase parts for full run of robots
** Build 10 boards
** Test and debug
*Phase Five
**more revisons if neccesary
** Debug
Currently we are in phase one. We have just completed a functional description of the electrical system and are now evaluating parts for use in the robot.
* [[RCcoms Communication (Wireless/Wired)]]
* [[RCsensors Sensors]]
** [[RCtemp Temperature]]
* [[RCmicro Microprocessor]]
* [[RCpower Power]]
** [[RCbattery Battery]]
* [[RCmotor Motor System]]

User:ScottT

2006-04-10T15:44:55Z

ScottT:

Not much to say here...