In attendance: ?JameySharp, ?KeithPackard, ?PeterWelte, Tim, AndrewGreenberg
Reviewing java UI code
Rocket Status Display
- Random bits hard to interpret
- Want red/green lights about rocket element status
- Use array of status displays
nodes.c
nodes.c:run
Purpose:
- Tracks node state by polling some nodes
- Can't track success of "enable" messages
Problems:
- Could watch for data messages and track.
- Remember timestamps from last message from each node
- Easy for most things as messages are broadcast
- Requires changes to IMU thread to post timestamps. Post to blackboard and have nodes thread monitor.
- Rocket Ready is magic. We don't want to re-set it if it goes down, we want to abort launch.
- We thought we want the nodes thread to do the set, but it's not necessary.
- Recovery node is somewhat magic.
- Request 'abort' state and recovery transitions to 'safe'
- Request 'safe' state and recovery may be in either 'safe' or 2m enabled.
Fixes:
- Timestamp messages from monitored nodes
- Check timestamps to monitor success of enable commands
- Split out Rocket Ready code to ensure the message is sent only once (done)
- Add list of 3-tuples for 'acceptable' states: (node, requested mode, acceptable alternate mode). Include (recovery node, abort, safe) and (recovery node, safe, 2m armed). (done)
- Sequencer must initialize nodes.c state before nodes is started
nodes.c:message
Purpose:
- Receives node state notification messages
- Tracks actual node state
Problems:
- Wakes up node thread if state is "wrong", so:
- If node can't get into the right state, we'll spin
Fixes:
- Don't wake getter thread from message handler. Let it poll. (done)
nodes.c:node_reset
Purpose:
- Uses enumeration to reset specific nodes
- Assumes reset data is 0x2e, which is currently true for all nodes.
- We wondered if APS uses a different reset data, but it doesn't.
Problems:
- If the APS is reset, the flight computer gets powered off.
Fixes:
- Refuse to reset APS node (done)
rec.c
rec.c:message
Purpose:
- Tracks pyro firing state
- But, pyro sends 1 when firing, 0 when done
- Must track ever fired
Fixes:
- Ignore pyro off messages (done)
- Range check pyro number (done)
- Timestamp pyro on messages, record to blackboard
rec.c:rec_set_timer
Purpose:
- Sets a single pyro timer.
Fixes:
- Sequencer should set all four timers
can_rw.c
Problems:
- Calls directly to write messages to net and flash
- Must not write to flash or net from can_rdr
Fixes:
- Need separate giant fifo for messages
- Separate threads for writing to flash and to network
- Verify whether udp writes ever block
imu.c
Purpose:
- Monitors all IMU messages
- Can use /dev/can1 when available (better be always)
- Sends raw and cooked data for each message
Problems:
- Don't care about fast cooked data
- Must try to save all raw data everywhere
- process_imu_accel holds the blackboard lock for a "long" time
Fixes:
- Need new blackboard thread to send blackboard data periodically
- Again, use giant queue to hold IMU messages and separate async threads to dump queue to disk and network
- Comment lock stuff in process_imu_accel to note why lock is held for so long
gps.c
Purpose:
- Reads serial GPS protocol
- Parses out lat/lon/alt
- Converts to UTM
- Parses out ECEF
- Need either ECEF or UTM for 'near tower' compuation
Problems:
- Don't care about UTM
- ECEF data must be ignored everywhere when GPS is not locked
- GPS is the last component that uses the single-element queue and fifo_read, which are a fairly significant performance bottleneck.
Fixes:
- Remove all extra computation from rocket.
- Make sure ECEF data is ignored everywhere when GPS is not locked
- Would be nice to have a separate CAN device for GPS messages.
- We can't drop any of these messages, so a separate hardware message buffer is bad.
- Think about eventually eliminating the fifo and using a character ring buffer. (Not this week?)
NOTES
- Make sure something (lots of things) log all of the network traffic they receive. Perhaps a daemon on the server machine constantly monitoring the network would be good. Something we can't turn off would be best.
Some messages have timestamps, some do not. Make sure all timestamp consumers check for valid timestamps in all messages. Invalid timestamps have '0' time (yes, some valid ones will too).
set_ms should ignore zero times
At this point Keith left, taking our notes with him. But we got them back.
pressure.c
- Tim will double check pressure.c algorithms (set_pressure_base and process_pressure) by comparing LV1B GPS data to LV1B pressure data.
report_state.c
- Jamey is making it report_blackboard.c
run_threads.c
- check whether fifo_write calls need to be locked
- sanity check that fifo_opens only happen for things that can accept messages.
atv.c
- Andrew will change the atv overlay output.
sequencer.c
- repeat note: start() needs to initialize structures in nodes.c (Andrew: get Jamey init values)
- evaluate_powerup needs to be minimally implemented so that a FC boot doesn't take "safe" the nodes. (Andrew: get Jamey state transitions)
- in arming_test(), move the inversion into the comment.
- rocket_ready: set all four pyro timers
- rocket_ready: redo pressure and imu boot detects
- launch_abort: REMOVE REC_MODE_ABORT!!
- boost: redo boost detect? or ok?