ME218C 2019 Communications Protocol

Version 1.1, 5/20/2019

Communications Committee Members:

Ashar Alam
Lawrence Domingo
Elliot Helms
Brian Jun
Thomas Labingi
Ben Kumar
Pablo Martinez Alanis
Rob Miller
 Revision Log

Date Section/ Authors

Description

23MAY2019 Ed Carryer Command Pippin, Gimli, Merry

Protocol/
Changed Rx data packet to
0xED.
Updated 1 second of
waiting after the tower
singing transmission. Total
time changed to 10
seconds.

23MAY2019 Pairing Diagram/ Pippin, Gimli, Merry

Updated Whale and
Goggle State Diagram

23MAY2019 Introduction Page/ Pippin, Gimli, Merry

Deleted image of
Smeagle/Gollum and car

23MAY2019 End Page/ Pippin, Gimli, Merry

Removed images of hover
boat
Introduction
This protocol is intended for use in 2019’s iteration of ME218C: Smart Product Design
Applications as robots play a game of “Ed? Carryer!”. The game will be played by a Wireless
Human Analog: Land-based Emulator (WHA:LE) and a companion Good [Or Great]
Geo-Location Enabler (G[OG]GLE).

Overview of XBee Communication

The G[OG]GLEs and WHA:LEs will primarily communicate with each other using the XBee
protocol specified by the IEEE 802.15.4 standard. Each G[OG]GLE and WHA:LE will have one
XBee radio to achieve this. Communications with the XBee radios can be performed using a
standard UART and are structured in the following manner for transmission and receipt:

Our protocol has been designed to allow all 8 G[OG]GLEs and WHA:LEs to communicate with
each other. Any G[OG]GLE and WHA:LE pair will be capable of pairing with each other. The
16-bit addresses for all 16 devices are shown in the following table.
 Team G[OG]GLE XBee address WHA:LE XBee address
1 2081 2181
2 2082 2182
3 2083 2183
4 2084 2184
5 2085 2185
6 2086 2186
7 2087 2187
8 2088 2188

Summary of Commands
The protocol will be able to handle the following core communications:
● Pairing:​ T ​ his is a bidirectional communication sequence that will be initiated by a
G[OG]GLE, and must be confirmed by the WHA:LE with an acknowledgment.
● Control: T ​ his is a unidirectional communication that contains command information for
the WHA:LE. This data packet will be transmitted from the G[OG]GLE to the WHA:LE at
a frequency of 5Hz, once a successful pairing has occurred.
● Status: T ​ his is a unidirectional communication that contains status information related to
the WHA:LE. This data packet will be transmitted from the WHA:LE to the G[OG]GLE at
a frequency of 5Hz, once a successful pairing has occurred.
● Bumper Contact:​ This is a broadcast that will be transmitted whenever the WHA:LE
that is “it” registers bumper contact. A method is described in which each WHA:LE that
received bumper contact within 200ms of this broadcast will respond to the “it” WHA:LE,
who will determine if “it” status is passed to another WHA:LE.
● Bumper Contact Response:​ ​This is a unidirectional communication that contains the
team number of the non-”it” WHA:LE that received a contact within 200ms of a reported
“it” WHA:LE bumper contact.
● “it” Transfer:​ This is a unidirectional communication that passes the “it” status from one
WHA:LE to another, following a valid bumper contact and response routine.
● Ed Carryer Commands: ​This is a broadcast that will be transmitted whenever the
WHA:LE that is “it” sings “Ed”, which will trigger all other WHA:LEs to respond by singing
“Carryer”. A method is described in which each WHA:LE will sing “Carryer” without
interference.
List of Headers for Commands

Command Header
0x01 Directed Message Header
(used for Control and Status)

0x02 Broadcast Header for checking “it” transfer

(used for Bumper Contact)

0x03 Bumper Contact Response Header

(used for Bumper Contact Response)

0x04 “it” Transfer Header

(used for “it” Transfer)

0x33 G[OG]GLE to WHA:LE Pairing REQ

(used for Pairing)

0x42 Manual Unpair Command (triggered by

G[OG]GLE)

0xED Broadcast Header for "Ed"

(used for Ed Carryer Commands)

0xFF WHA:LE to G[OG]GLE Pairing ACK

(used for Pairing)

Overview of FM Communication
In addition to the XBee communication approach, each WHA:LE will transmit audio data over a
specific FM frequency to a corresponding receiver in its paired G[OG]GLE. FM frequency
channels are specified for each team in the table below, to avoid interference between the
devices.

At the start of each game, the G[OG]GLE operator must tune their receiver to the appropriate
FM Frequency for the WHA:LE that they intend to control.

Team Assigned FM Frequency (MHz)

1 107.9

2 106.3
 3 105.1

4 104.1

5 103.1

6 102.3

7 101.1

8 100.1

Pairing Protocol
A pair between a G[OG]GLE and WHA:LE is accomplished by the following sequence, at
minimum:

As stated previously, once this pairing is complete, the G[OG]GLE will send a Control packet
and the WHA:LE will send a Status packet, each at a frequency of 5Hz.

After a successful pair, if a Control packet is not received by the WHA:LE and/or a Status
packet is not received by the G[OG]GLE within 1 second, both G[OG]GLE and WHA:LE will
revert to an unpaired state.

If the team selector input on the G[OG]GLE changes from the paired WHA:LE to a new WHA:LE
at any time after a successful pair, a manual unpair will take place and both G[OG]GLE and
WHA:LE will revert to an unpaired state.
The following figures represent common state diagrams to be implemented for pairing between
each G[OG]GLE / WHA:LE.

WHA:LE Pairing State Diagram

G[OG]GLE Pairing State Diagram

Pairing Frame Data
The following tables represent the structure of bytes to be sent at the request and acknowledge
steps of the pairing process.

G[OG]GLE to WHA:LE Pairing Request Frame Data

Frame ID Destination Address Options RF Data Packet

0x33 MSB and LSB of 0x00 (to not disable See details below:
target WHA:LE ACK)
selected

Data Packet Contents:

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4

Pairing Header MSB Xbee LSB Xbee MSB Xbee LSB Xbee
0x33 Address Address Address Address
G[OO]GLE G[OO]GLE WHA:LE WHA:LE

WHA:LE to G[OG]GLE Pairing Response Frame Data

Frame ID Destination Address Options RF Data Packet

0xFF MSB and LSB of 0x00 (to not disable See details below:
G[OG]GLE that sent ACK)
request

Data Packet Contents:

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4

Ack Header MSB Xbee LSB Xbee MSB Xbee LSB Xbee
0xFF Address Address Address Address
G[OO]GLE G[OO]GLE WHA:LE WHA:LE

If both source and destination headers don’t match, disregard pairing request and start again
pairing request.
Unpairing Frame Data
The following tables represent the structure of bytes to be sent at the request and acknowledge
steps of the unpairing process.

G[OG]GLE to WHA:LE Unpairing Request Frame Data

Frame ID Destination Address Options RF Data Packet

0x42 MSB and LSB of 0x00 (to not disable See details below:
target WHA:LE ACK)
selected

Data Packet Contents:

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4

Unpairing MSB Unpairing Unpairing Unpairing LSB Unpairing

Header Payload Payload Payload Payload
0x42 0xDE 0xAD 0xBE 0xEF

Control Protocol
This section describes the protocol for sending a Control packet from a G[OG]GLE to the
WHA:LE that it is paired with. In addition to the Frame ID, this packet will have three bytes. The
first byte will contain the driving information for the WHA:LE. The second byte will give the
direction information to the whale. The last bit will contain, 7 bits for special instructions (0-6)
and one bit that will be flagged in the event that the WHA:LE is “it” and commanded by the user
to sing “Ed”.

Control Frame Data

G[OG]GLE to WHA:LE Control Frame Data
Frame ID Destination Address Options RF Data Packet

0x01 MSB and LSB of 0x00 (to not disable See details below:
target WHA:LE ACK)
selected
Data Packet Contents:
Byte 0 Byte 1 Byte 2 Byte 3

Directed Driving Direction Special

Message (Forward / (Left / Right) Command
Header 0x01 Backward)

Total Length for G[OG]GLE to WHA:LE Command: 8 bytes

Additional details on the format of the Driving, Direction and Special Command bytes are
included below.

Driving Byte:
This byte will be a number between 0 and 255. At 127 the WHA:LE should not move. The closer
to 0, the nearer the WHA:LE should exert relative to its maximum backward control effort. The
closer to 255, the nearer the WHA:LE should exert relative to its maximum forward control effort.

Direction Byte:
This bit will be a number between 0 and 255. At 127 the WHALE should be moving straight. The
closer you get to 0 the closer your the WHALE should turn relative to its maximum left turn
control effort. The closer to 255, the nearer the WHALE should turn relative to its maximum right
turn control effort.

Special Command:
Bits 0 through 6 are left for each team to use as special commands. The 7th bit will be used to
command the WHA:LE to sing “Ed” if it is currently “it”. The process of commanding the
WHA:LE to sing “Ed” is detailed further in the following section.

7 6 5 4 3 2 1 0

Sing ‘Ed’ UNUSED

Bit 7:
● 0: The WHA:LE does not sing
● 1: The WHA:LE sings “Ed” and proceeds with the Ed Carryer Command Protocol
Bit 6-0:
● UNUSED

**NOTE: WHA:LE to G[OG]GLE do not exchange capabilities because no team wants to add
additional functionality. We just want to check off :D

Sing “Ed” Request

When Bit 7 of the Special Command byte is set and the receiving WHA:LE is “it”, it is required to
audibly sing “Ed” and to broadcast a message to all other WHA:LEs to start the “Carryer”
response process as explained in the Ed Carryer Command Protocol section. Sending this
instruction to any WHA:LE that is not “it” should result in that WHA:LE silently ignoring this
request and handling the rest of the packet normally. If the WHA:LE is in the 8s refresh period
after singing Ed, it should not sing, but handle the rest of the packet normally.

If the addressed WHA:LE is “it” and it is currently able to sing, it should do the following as
quickly as possible upon receiving this request:
1. Begin to play the “Ed” audio over its speaker
2. Broadcast the Ed Carryer Command to all other WHA:LEs
3. Set an 8 second timer, during which the “it” WHA:LE is unable to sing “Ed”

The “Ed” audio should last no longer than 1 second.

Status Protocol
This section describes the protocol for sending a Status packet from a WHA:LE to the
G[OG]GLE that it is paired with. In addition to the Frame ID, this message will have three bytes.
The first two of these bytes will contain sensing information from the WHALE. The last byte will
be left blank for use by each team as desired.

Status Frame Dat1

WHA:LE to G[OG]GLE Status Frame Data
Frame ID Destination Address Options RF Data Packet

0x01 MSB and LSB of 0x00 (to not disable See details below:
target G[OG]GLE ACK)
selected
Data Packet Contents:
Byte 0 Byte 1 Byte 2 Byte 3

Directed Front/Back Left/Right Additional

Message Proximity Proximity and Sensor Data
Header 0x01 Bumper

Total Length for WHA:LE to G[OG]GLE Command: 8 bytes

Additional details on the format of the Proximity and Bumper bytes are included below.

Front/Back Proximity:
The four MSBs will contain information about sensing in the front of the WHALE. The four LSBs
will contain information about sensing in the back of the WHALE. In each case, the closer the
object to the WHA:LE, the higher the value of this nybble.

Each team is strongly encouraged to implement some form of proximity sensing such that
inter-operability between teams’ WHA:LEs and G[OG]GLES is improved.

7 6 5 4 3 2 1 0

Front Proximity Sensor (optional) Back Proximity Sensor (optional)

Bit 7-4 (optional):The higher the value, the closer the obstacle in front of the WHA:LE

Bit 3-0 (optional):

- The higher the value, the closer the obstacle behind the WHA:LE

Left/Right Proximity and Bumper:

This byte contains information for proximity both on the left side (bit 7 and 6) the right side (bit 5
and 4). The higher the value of these bit pairs, the closer the object. This byte also contains the
status information for the bumpers. If the bumpers are activated the bit is set and if the bumper
is not activated the bit is cleared (bit 3 for front, bit 2 for back, bit 1 for left and bit 0 for right).

Similarly to the above, each team is strongly encouraged to implement some form of left/right
proximity sensing. Bumper detection is similarly encouraged but not required.

7 6 5 4 3 2 1 0

Left Proximity Sensor Right Proximity Front Back Left Right

(optional) Sensor (optional) Bumper Bumper Bumper Bumper
Bit 7-6 (optional)
- The higher the value, the closer the obstacle to the left side of the WHA:LE

Bit 5-4 (optional):

- The higher the value, the closer the obstacle to the right side of the WHA:LE

Bit 3:
- 0 if front bumper not active
- 1 if front bumper active

Bit 2:
- 0 if back bumper not active
- 1 if back bumper active

Bit 2:
- 0 if left bumper not active
- 1 if left bumper active

Bit 1:
- 0 if right bumper not active
- 1 if right bumper active

Additional Sensor Data:

7 6 5 4 3 2 1 0

"IT" UNUSED

Bit 7:
● 0 if receiving WHA:LE is not "it"
● 1 if receiving WHA:LE is "it"
Bit 6-0:
● UNUSED

Bumper Contact Protocol

This section describes the protocol for determining the transfer of “it” status. The
purpose of this communication is for the WHA:LE that is “it” to tell other WHA:LEs that it has
detected a collision and to request information about collisions within the past 200ms. The
following diagram indicates the flow of transferring “it” status after a valid bumper contact.
Upon registering bumper contact, the WHA:LE that is “it” sends out a broadcast message to
determine if other WHA:LEs had a bumper contact within 200ms of the contact.

Each WHA:LE satisfying this criterion sends a directed message to the WHA:LE that is “it”
informing it of the bumper contact. Among all WHA:LEs that respond in this manner, the one
with the strongest RSSI is designated to be next “it”, which is communicated by a directed
message from the formerly “it” to the newly “it” WHA:LE. At this point, the newly appointed “it”
WHA:LE must wait 8 seconds before it can begin moving (Control and Status packets must be
sent, but movement cannot be acted upon until 8 seconds have elapsed).

If no other WHA:LE responds to “it”, gameplay proceeds with the same WHA:LE denoted as “it”.

Bumper Contact Frame Data

“it” to WHA:LEs Bumper Contact Frame Data
Frame ID Destination Address Options RF Data Packet

0x02 0xFFFF (Broadcast) 0x00 (to not disable See details below:
ACK)

Data Packet Contents:

 Byte 0 Byte 1

“it” Bumper 0xFF

Contact
Header 0x02

Total Length for “it” to WHA:LEs Broadcast: 6 bytes

WHA:LEs to “it” Bumper Contact Response Frame Data

Frame ID Destination Address Options RF Data Packet

0x03 MSB and LSB of It to 0x00 (to not disable See details below:
receive detection ACK)

Data Packet Contents:

Byte 0 Byte 1

Bumper Bumper
Contact Response
Response 0x01 - 0x80
Header 0x03 (see below)

Total Length for WHA:LE’s to “It” Directed Message: 6 bytes

​ umper Response:
B
The Bumper Response byte indicates whether or not the particular WHA:LE encountered a
collision when “it” detected a collision.

● 0x01 – Team #1 bumper detected [00000001]

● 0x02 – Team #2 bumper detected [00000010]
● 0x04 – Team #3 bumper detected [00000100]
● 0x08 – Team #4 bumper detected [00001000]
● 0x10 – Team #5 bumper detected [00010000]
● 0x20 – Team #6 bumper detected [00100000]
● 0x40 – Team #7 bumper detected [01000000]
● 0x80 – Team #8 bumper detected [10000000]

it” to WHA:LE - “it” Transfer Frame Data

Frame ID Destination Address Options RF Data Packet
 0x04 MSB and LSB of the 0x00 (to not disable See details below:
next “it” ACK)

Data Packet Contents:

Byte 0 Byte 1

“it” Transfer 0xFF

Header 0x04

Total Length for “It” to WHA:LE Directed message: 6 bytes

As stated above, the newly appointed “it” WHA:LE must implement measures to wait 8 seconds
before acting upon Control movements after newly receiving “it” status.

**Note: The lame-duck "IT" WHA:LE shall be considered "IT" until the entire "IT" transfer
message is completed.

Ed Carryer Command Protocol

This section describes the protocol for directing non-”it” WHA:LEs to begin their timers to
sing “Carryer”, following an executed sing “Ed” request by the “it” WHA:LE.

Ed Carryer Command Frame Data

“it” to WHA:LEs Ed Carryer Command Frame Data
Frame ID Destination Address Options RF Data Packet

0xED 0xFFFF (Broadcast) 0x00 (to not disable 0xED

ACK)

Following receipt of this command, all WHA:LEs that are not “it” should begin a timer as soon as
possible, with a delay of X seconds, where X is their team number (1-8). This structured delay
is intended to enable targeted detection of certain teams’ WHA:LEs. At the end of 8 seconds, an
additional second (ninth second) is allocated for the beacon. Then wait another second before
“it” can start singing ED again. This makes a total of 10 sec.
Upon timeout, each WHA:LE should audibly sing “Carryer”. This sound clip should last no more
than 1 second to allow the next WHA:LE the chance to sing without interference. If fewer than
all 8 teams are playing in a game, there will be delays in this “Carryer” sing response.

All G[OG]GLEs receiving this message should silently ignore this broadcast.

The below diagram indicates the full flow of an “Ed” / “Carryer” sing, including the initial “Ed”
sing request as detailed in the Control Protocol and the “Carryer” sing response as described in
this section.

Acknowledgements
The ME218C 2019 communications committee would like to acknowledge the valuable support
of Professor Ed Carryer and Karl Gumerlock in the creation of this standard document.