/
2020-05-31 Meeting notes

2020-05-31 Meeting notes

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

Related content