Page Comparison

...

• 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 init 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
      • initconstructor
        
        • start postman thread
        • attach ISRs
      • periodic
        • 1ms
          • RX processor 
        • 10ms
          • TX processor
    • CAN app - science
      • initconstructor
        
        • set hw filters
      • periodic
        • 10ms
          • Update TX signals
    • Geneva actuator manager
      • initconstructor
        
        • init actuator manager and controllers
      • periodic
        • 1ms
          • Update actuator controls
    • Elevator actuator manager
  • main.cpp
    • main()
      • initinstantiate 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

...

• Do we want to decouple encoder / current sensor reads from actuator update loops?

Tasks