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-packetPros:
- Can start processing the data while it comes in since each serialized packet is encapsulated.
- list here
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'
- 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
- 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
- Option 1 ("throw it away" if other things are going on)
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 | |
Wireless: unknown, possibilities include (channel, PAN) |
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 |