Refer to Logging Research for a starting point (and necessary data) courtesy of Gordan
Brainstorm
...
Information we always need
Timestamp
uint32 seconds + uint32 nanoseconds
range for seconds: 0 - infinity
range for nanoseconds: 0 - 10^9
state of the telemetry, path manager waypoints, and attitude manager state
CV Info wanted
Electrical info wanted
Firmware info wanted
...
GordOn
Information to be Logged
Attitude Manager
OutputMixing
PID output for the actuators. Include the channel and PID value
Log once:
PID values used
Log if we enter failureState
Path Manager
Mode and stage of flight we are in
Cruising state
Cruising state instructions for modifying the flight path
Coordinated turns and elevation outputs:
Desired heading, altitude, and airspeed (Data sent from modes)
Desired roll, rudder, pitch, throttle (basically data sent to Attitude Manager)
Log once:
PID values used
Log if we enter failureState
Telemetry Manager
Confirming receipt/sending of data from groundstation
“Data sent to ground”
“Data received from ground”
If successful transfer, output a 1 as well, else 0
Log if we enter failureState
Sensor Fusion
Current state of the plane
Basically the SFOutput_t struct
roll, pitch, yaw, rollRate, etc.
Raw sensor data
Ex. accX, accY, accZ from IMU, airspeed from airspeed sensor
Sensors
When sensor constructor is called/Sensor module is initialized (happens once in our program, so knowing if/when it happens is nice)
When we call GetResult(), log the status of the sensor (Kaveet needs to come up with tracking sensor status)
Nice to Haves
Battery percentage log
File System Organization
Least organization
All logs go into one master file
Most organization (Preferred)
Each numerical value gets its own text file (similar to Simulation)
Data that must be grouped (ex. channel PID values) should be in the same file
Brainstorm
Information we need in every message
Timestamp (HHMMSS)
sensor highest frequency, path manager lowest frequency. at which rate do we publish
path manager - midpoint update?
separate files?