Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Refer to Logging Research for a starting point (and necessary data) courtesy of GordOn

Brainstorm

...

Information we need in every message

  • Timestamp

    • uint32 seconds + uint32 nanoseconds

      • range for seconds: 0 - infinity

      • range for nanoseconds: 0 - 10^9

  • Error codes (int32)

...

Odometry Msg

  • speed

  • coordinates in relation to the starting point? (starting point/home is (0,0) and everything is relative)

...

Telemetry Msg

  • sensor data (IMU, GPS, etc)

  • path manager waypoints

  • GPS coordinates

  • Target vs actual/current values of altimeter, RPM, Euler angles, etc.

State Report Msg

...

PID

...

flight mode (takeoff, landing, is landed, following waypoints, etc.)

...

battery charge

CV info wanted

Electrical info wanted

...

Firmware info wanted

...

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?