Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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
      • Periodic functions
    • Rover apps
      • Consists of multiple modules
      • Responsible for calling module init and periodic functions
  • Example: science app
    • Modules
      • CAN driver
        • init
          • start postman thread
          • attach ISRs
        • periodic
          • 1ms
            • RX processor 
          • 10ms
            • TX processor
      • CAN app - science
        • init
          • set hw filters
        • periodic
          • 10ms
            • Update TX signals
      • Geneva actuator manager
        • init
          • init actuator manager and controllers
        • periodic
          • 1ms
            • Update actuator controls
      • Elevator actuator manager
    • main.cpp
      • main()
        • init
        • 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

Notes

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


  • No labels