RoboCup Radio 2009

Bandwidth

• 90Hz cycles => 11ms period.
• 250kbaud maximum. The radio can do 500kbaud with some modulation types, but we can not assume that this will be the final choice.
  • Raw: 347 bytes per period, less 23 bytes for VCO calibration time. 324 bytes usable.
• 12 bytes overhead per packet
  • 4 bytes preamble (recommended by datasheet, 2 bytes minimum)
  • 4 bytes sync (recommended by datasheet, 2 bytes minimum)
  • 1 or 2 bytes padding for error correction (payload must be an odd number of bytes before padding)
  • 2 bytes CRC
  • Separate overhead for forward and reverse packets
• Maximum packet size is 255 bytes, excluding FEC padding and CRC.

Configuration

Need to consider a reliable communication protocol for performing robot configuration

• Radio configuration
• PID loops
• etc...

This is not done often, but a host-side application for this would be nice.

Channels

• A small number of channel configurations (8-16?) should be stored on the robot for scanning. Would prefer EEPROM on MCU for this. Should not require JTAG flash to change these.
  • Channel config includes bit rate, modulation, power, etc. Everything can be configured per channel.
  • These *will* change during competition. Expect frequent changes during setup as other teams go online and crowd us out.
  • Too many possible channels to scan in an acceptable amount of time.
• Each robot will scan for the host among the channels it knows on power-on and when it has received no radio data in some period of time (5s?).
  • Expect to wait at least 3 radio cycles (33ms) on each channel. If we miss three forward packets in a row, either the host is on another channel or the channel is unusable.
• Not sure how to select a channel for standalone mode.
  • Use last channel assigned by host, stored on the base
  • Select with joystick
  • Clear Channel Assessment (find lowest noise among configured channels)

Scanning

Looking for robots that are turned on.

• This should be done per request of the host. Most likely during a stop/halt in gameplay because we do not reverse channel data then.
• Should be able to change a robot on the field without touching the computer.

Protocols

Reverse

Under normal operating conditions the reverse channel has several different modes of operation.

1. Gameplay Mode
   • Slow Update: All robots are reporting back every nth robot fast loop interval.
   • Fast Update: Only one robot is reporting back, but is reporting every fast loop.
2. Fast Engineering data
3. Slow Engineering data

Information Types

There are three types of information that need to come back over the reverse channel. They are in order of priority.

Gameplay

Gameplay information needs to be updated frequently and is critical to good gameplay.

• Ball Presence
• Capacitor Voltage

Fast Engineering

These are things that we want to know periodically, but are not updated very quickly or are not critical to gameplay.

• Battery Health/Voltage
• RSSI

Slow Engineeting

Items that do not change at all or change very slowly during a match.

• Board serial number