2020-05-31 Meeting notes

Owned by Anthony Berbari (Deactivated)
Last updated: 2020-06-14 by Lucy Gong (Deactivated)
2 min read

Date

May 31, 2020

Participants

  • @Anthony Berbari (Deactivated)

  • @Lucy Gong (Deactivated)

  • @Annie LePage

  • Craig Crundwell

Goals

  • Talking to David update (though I don’t think anything new has come up)

  • Sensor interface update

  • Architecture update

  • CV update (don’t get too hyped, been disappointed )

  • Moving forward: How to break up the first state machine into manageable subtasks.

  • Assigning those subtasks, (possibly bringing in new recruits, though doesn't seem super likely)

Discussion topics

Item

Notes

Item

Notes

David Update

  • No further updates - poke him Wednesday?

  • Fall term - Teerstra will probs try to keep bay open

Sensor Interface Update

  • IMU, Airspeed and GPS interfaces are up woot!

  • We can start building up state machines

Architecture Update

  • Diagrams are now clean - thanks Anthony!!

  • Docs are now live - anyone can go in and edit the diagrams

CV Update

  • CV bois didn’t deliver :(

  • 1 has dipped on WARG, 1 guy saying he’ll get it done by today

  • Leave on back burner for now till someone completes the bootcamp

Attitude Manager Task Splitting

  • Pour over from PICPilot as much as possible.

  • Get Sensor Measurements/Sensor Fusion - Lucy

    • i: sensor data, o: formatted results in structs/error msg

    • Get Sensor Measurements = Sensor.GetResult() from sensor threads

  • PID - Annie

  • Send instr to motor/control - Anthony

    • This section will involve mocking hardware for testing purposes

  • 1 person assigned to each module. Talk to make sure the interfaces for each module mesh w/ each other, since these modules will be interacting w/ each other

    • ex: Does Sensor Fusion or PID module responsible for dealing w/ garbage data? Or Control Motor module?

    • Could use Errors_t struct that gets passed along each module

  • When defining the fn, start writing unit tests

    • How does your module respond to old data, new data, erroneous data, etc.?

  • Should the modules be classes vs a bunch of fns:

    • w/ classes they’ll be instantiated only once…ask Serge :)

Action items

Attitude Manager: Complete Module Interfaces for next week
Attitude Manager: Start writing the function - does not have to be completed by next week
Ask Serge: Should the attitude manager modules be classes or a bunch of fns? Where should the battery status checks be, in the Telemetry thread?
Have long term goals set by the end of week (Have Autopilot FW ready)

Decisions