...

• main.cpp, Starting LOS and SM.

  • Gordon will do.

  • https://github.com/UWARG/ZeroPilot-SW-3/blob/testing/LOS_Link/main.cpp

• PRs, dependencies, Try to get in ASAP.

  • LOS_Link

    • Sketchy, waiting on testing

  • LOS_Actuators

    • Gotten correct outputs on G4, waiting on testing

  • AM

    • Near or ready for Merge. Jack Greenwood

    • Switch to using Los_Actuators::getInstance().set(uint8_t channel, uint8_t percent);

  • SM dependencies using above

• LOS use the Los_Link::getInstance().getRx(); for RC data for now and Los_Actuators::getInstance().set(uint8_t channel, uint8_t percent); for actuators.

  • No issue of different managers calling at the same time for this architecture.

  • Gordon, update how SM does this stuff. Check channels here: https://github.com/UWARG/LaminarOS/blob/LOS_Actuators/LOS_Interface/Inc/config.hpp

• Gordon do a submodule update to get new LOS code once merged

MVP Stuff:

• Deadline: End of term.

• Clarification on what MVP looks like

  • All managers running, Data flowing as discussed.

  • System-by-system Breakdown:

    • ZP (Shared?)

      • Starts SM

      • Asks LOS to start SF

    • LOS

      • Los Actuators

        • Motor control

      • Los Link

        • PPM

      • Los Position

        • Either VectorNav or SF GPS/IMU

      • Los Telemetry

        • RFD900s To/From Ground

      • Los Comms

        • Aim to have code ready for communication to/from CV

        • Does not block MVP if CV (Jetson) not yet ready

    • SF

      • See Los Position

    • SM

      • Starts AM, PM, TM, inter-thread communication system

      • Determines drone state (Boot, Disarm, Ground Ops, Flight, Fatal Fail)

      • Read from Telemetry and write to telemetry

      • Pass messages to PM/AM to fly the drone

      • Handle, parse, and pass along RC controls

      • Shuts off actuators when disarmed/fatal failure

      • ArduPilot Passthrough to Los Actuators

    • AM

      • Controls actuators during (happy) flight

      • Operational PID loop (not yet fully tuned)

      • Correct parsing of input messages

      • Response output to be sent to SM → TM → ground

    • PM

      • Generates waypoints based on Telemetry/CV input

      • Manages Takeoff/Landing waypoints/velocity profile

    • TM

      • Interacting with Los Telem

      • Code ready for CV communication

        • Do not block MVP if CV is not yet ready for this

      • Interfacing with SM

        • To/from ground

• concerns about combining all the structs into a single message

  • Larger messages with different sources of data going between threads

  • Initially thought TM would run as fast as possible

  • Pros:

    • Easier to parse

    • Can work if same TM and SM frequency

  • Cons:

    • Implement Batching to handle multiple messages

    • Could fill queues

  • Outcome: Followup Discussion, requires more information

• Who starts TM?

  • SM

• LOS Overview:

  • Want one big LOS instance that holds LOS_Core, LOS_Link, LOS_Actuators, etc.

  • Critical segment protection built in so no interfering calls from different managers

• Should we really be passing stuff thru through PM

  • Pros: prevents multiple sources of input into AM and allows PM to clear current trajectories and immediately swap to pilot control

  • Cons: What if PM fails, this seems out of PM scope, idk man this seems sus is there a better way

• concerns about combining all the structs into a single message

Post MVP Stuff:

• • Cons: notes from Sahil: PM shouldn't be talking to AM, instead SM should just have an if statement where depending on whether the drone is in autonomous mode or RC, it takes the instruction strict from either PM or LOS RC and passes it to AM. That way AM is only communicated to by SM and is only getting data from one source

    • Good only if you can figure out a way not to introduce latency.

  • Outcome: Aadi’s Flag Model

    • Have a readPmTargets global flag that SM writes to and AM and PM read from.

      • PM clears output queue when reading readPmTargets== false

      • AM ignores PM commands when it is false

      • SM sets this based on if RC data is received

      • Read/write mutexes used to prevent corruption (many can read, only 1 can write)

    • SM keeps stream of messages to/from SM open for (non-PM) teleop (SM → AM) and set that flag false before writing

Post MVP Stuff:

• Deadline: Mid January

• Everything that does not directly block the MVP goal of all managers running and drone operating.

• Replace message queues with LCM channels (seems like a better way to publish data like sensor data where only the last piece of data should be read, rather than all the data).

  • Also its pretty easy to implement. Only issue would be lack of support for uint16_t and uint32_t, but if this is post MVP, I have a solution, it will just take time to implement.

  • https://lcm-proj.github.io/tut_cpp.html

  • Current system is designed so that LCM should be easy to swap in (MailQs not actually used as queues)

  • Publisher/subscriber model, subscribe only to topics you care about.

• Preflight and Postflight States

  • Spin up/down motors briefly to reduce current spikes

Action Items

• Christopher Chung is going to reach out to CV about timelines on Los Comms and TM communication.

  • Also going to make a table for MVP task status

• PRs and dependencies, get them in ASAP

  • If you have methods that aren’t in main yet, get something in before 11am tomorrow.

  • Making it function can happen slightly later if needed.

Thread System

Nov 27th

...

MVP

...

...

View file
name WARG_MVP_Threads_Mermaid_Code.txt

Communication System

Nov 27th

...

MVP

...

...

View file
name WARG_MVP_Comms_Mermaid_Code.txt

Message Definitions:

https://uwarg-docs.atlassian.net/wiki/spaces/ZP/pages/2137653308/ZP+SW3+Common+datatypes

...