still up for debate, but potentially restructure the chassis control to have a chassis task that is always running, then use the motion handler to run movements. movements can be store as structs (already are for the most part with appa::Target) then just run them through robot.run(movement) or something similar. could create a movement queue to act as the bridge between the chassis task and other tasks. could even add movements that just block until notified. so you could technically queue up every single movement in an autonomous at once, then run things however you want and add blocking if you want to pause while driving. i dont see that being very practical since it would decouple the specific movements from the rest of to auto, but its cool that it could work.
benefits
- single chassis task that is always running. dont have to create and destroy them for every async movement
- a movement queue can chain together movements easily asynchronously
downsides
- synchronous movements will run in task then block main task vs running in main task
- queue system could add confusion and complexity, although I could make the existing API work identically to now or have the queue system private
still up for debate, but potentially restructure the chassis control to have a chassis task that is always running, then use the motion handler to run movements. movements can be store as structs (already are for the most part with appa::Target) then just run them through robot.run(movement) or something similar. could create a movement queue to act as the bridge between the chassis task and other tasks. could even add movements that just block until notified. so you could technically queue up every single movement in an autonomous at once, then run things however you want and add blocking if you want to pause while driving. i dont see that being very practical since it would decouple the specific movements from the rest of to auto, but its cool that it could work.
benefits
downsides