Nov 25 Architecture Meeting
Discussions:
November 27th Stuff:
main.cpp, Starting LOS and SM.
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 andLos_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 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
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
== falseAM 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.
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
Communication System
Nov 27th
MVP
Message Definitions: