FW App Structure Redesign
- Currently, all our rover apps have this general structure:
- Start CAN RX/TX threads
- while(true) loop
- Update actuator controls
- Update CAN TX signals
- This gets really messy and repetitive
- We want to create a more modularized app structure
- Drivers (everything in our libs folder)
- Modules (logic for a particular part of an app)
- Init function (constructor)
- Periodic functions
- Rover apps
- Consists of multiple modules
- Responsible for calling module constructor and periodic functions
- We also want to fix timing requirements, right now there is no guarantee to the period at which the while(true) loop in main() runs
- Example: science app
- Modules
- CAN driver
- constructor
- start postman thread
- attach ISRs
- periodic
- 1ms
- RX processor
- 10ms
- TX processor
- 1ms
- constructor
- CAN app - science
- constructor
- set hw filters
- periodic
- 10ms
- Update TX signals
- 10ms
- constructor
- Geneva actuator manager
- constructor
- init actuator manager and controllers
- periodic
- 1ms
- Update actuator controls
- 1ms
- constructor
- Elevator actuator manager
- CAN driver
- main.cpp
- main()
- instantiate all modules
- start periodic_1ms thread
- start periodic_10ms thread
- periodic_1ms
- call 1ms functions from each modules
- delay until next 10ms mark
- periodic_10ms
- call 10ms functions from each module
- delay under next 10ms mark
- main()
- Modules
Notes
- Do we want to decouple encoder / current sensor reads from actuator update loops?
Tasks