Minutes20101117

Below is the structure of the comms flowing from AVR to ARM and from ARM to AVR. Most of the things are well defined, the exception being wireless since we don't know when those comms will occur, what the size of the packets will be, or how many packets there will be. Other remaining questions are the actual structure of the UART packets ->

{header{}, {packet_1_typeID, packet_1_data}, {packet_2_typeID, packet_2_data} } //the typeID encodes the length of that sub-packet
Pros:
  • Can start processing the data while it comes in since each serialized packet is encapsulated.
Cons:
  • list here
{data{packet1_data, packet2_data, packet3_data}, header{table of contents}} //like the ZIP file format
Pros:
  • Calculate the size of the overall packet during message compilation (only touch it once)
  • Packet position (table of contents) is stored in a central location'
Cons:
  • In some cases, having the packet type separated from the data itself could be a detriment. Concerns about robustness of this approach to dropped bits? Probably all the same issues as encapsulated since they are treated as a single serialized stream too.

AVR to ARM (this direction only)


Sonar

Frequency: every 50 ms, readings from both sonars (at "exactly" the same time, they are triggered together)
  • Note: THIS NEEDS TESTED (hook up sonar to serial & pwm interfaces, and verify that measuring time between our trigger signal and the PWM pin going low == distance reading)
Data Size (bytes) Notes
Range_0 (0-255) 1 front sonar
Range_1 (0-255) 1 rear sonar
Time 4 4 maximum, could be anything over a few seconds if clocks are synced (e.g. 2 bytes)
Stepper Angle 1 7.5deg/step, 48 positions

Cliff Sensors

Freqency: every 10/30ms?

Data Size (bytes) Notes
3 Pins (0-1) 1
Time 4 not necc needed, but might be nice for mapping

Expansion DIO (assuming all are inputs)

Frequency: Default is 0, otherwise dictated by the ARM, which is dictated by type of accessory. Note that the priority is also configurable.

Data Size (bytes) Notes
4 Pins + Detect 1 4 pins in lower 4 bits, detect in 5th bit

BOM

Frequency: assuming you get a valid signal every time you do a read, (how fast are we reading?) no faster than every 33ms per channel

BOM is decoded on the AVR, so at maximum we are transmitting a robotID & sensorPosition (reading robot and sending robot) for each of the 4 channels.
robotID 6 bits
sensorPostion, 2 bits (x2)

Data Size (bytes) Notes
robotID + senderPosition + receiverPosition 2 See above explanation

Wireless (AVR to ARM structure)

Assuming AVR disassembles wireless packets, transmits "important" things to the ARM (sender, actual data)
  • Need to look into this more, all the info in a packet might be relevant to the ARM
Notes:
  • Lower priority than our sensors
    • Option 1 ("throw it away" if other things are going on)
      • Force the transmitter to re-send data if it didn't get an ack
    • Option 2 (store it, but don't deal with it now)
      • Don't know if sender is transmitting large packets or streaming data

Frequency: Unknown, limited by wireless hardware, theoretical limit is 2mb/s (perfect scenario) but that is an atypical usage scenario


.
.
.
.
.

ARM to AVR (this direction only)


Orbs

Data Size (bytes) Notes
Orb0 3 R+G+B, left
Orb1 3 R+G+B, right

Expansion

Note: All four states always transmitted, just read out bits corresponding to output pins

Data Size (bytes) Notes
Direction + OutputState 1 lower 4 bits-> state, upper 4 bits -> direction (on AVR, XOR with current direction states)

Wireless

Send it to the AVR, the AVR will chunk it if necessary
RobotID to hardware receiver ID mapping will be stored/handled by ARM

Destination [PAN_ID (2 bytes) + MAC (2 bytes)]
MessageLength (1 byte)
Message (length <=127 bytes - sizeof(metadata))

FRAME [ PAN + MAC + MessageLength + Message + CRC ] <= 128 bytes

Configuration

No sonar on/off, because the stepper can't be turned off
Wireless "always" receiving (can't be turned off in hardware, ignored in software by the ARM)

Data Size (bytes) Notes
BOM_Transmit: on/off 1 byte
BOM_Read: on/off 1 byte
Cliff Sensors: read on/off 1 byte
Sonar_Speed: @Speed (LOW, MED, HIGH) 1 byte # of positions decreases with increasing speed
Sonar_Manual: Positions24 3 bytes front and rear control mask OR'd by ARM before transmit, but you'll always get front&rear for the same angle
Reset: to defaults 1 byte basically everything is "off" & no sensors are read, GPIO are inputs
Expansion: Frequency, Priority 1 byte directionality set during every output state command, set freq to 0 to stop readings