Content Comparison

...

The autopilot will consist of 3 threads that each manage a state machine and many other threads that manage sensor data acquisition. The 3 state machines are the attitude manager; responsible for putting and keeping the aircraft in some desired attitude, the path manager; responsible for instructing the attitude manager to achieve some attitude in order to navigate the aircraft to some particular location, and the telemetry manager, responsible for all communications with the ground station. At the same time, there will be a thread for each sensor, ensuring data is collected at well timed intervals.

Path Manager

Image RemovedImage Added

• The sensors relevant to the path manager are the GPS, altitude sensors, and anything responsible for communicating to/from the ground.
• As with the lower level, this architecture is also interrupt based.
• Not sure how we should manage loop period. Should this be run more or less often then the lower level loop ? And how to keep loop periods constant when we have 2 separate loops running.
• Gps stuff comes around fairly slowly and can be fairly inaccurate. As mentioned in Asana, seems like a good idea to fuse measurements made by the lower level with it to figure out what is going on. I don’t think this was implemented in PicPilot.
• The PicPilot does a ton of really cool waypoint tracking stuff. I think most of it is fine to port over.
• A couple things not included in these documents: Battery level checkers, led managers... Not sure where these things should go.
• Autonomous takeoff/landing is still a whiles away, but not sure how it would fit into such an architecture. Probably want another state machine that takes control from this one when we deal with take offs/landings.
• Not sure how often data needs to be sent to/received from the ground. We should make sure that uncertainty is accounted for when figuring out how often to run this loop. Surely FreeRtos gives us methods for doing things like this.
• Actually, I’m having second thoughts about having ground communications be part of this module. What does path managing have to do with ground communication anyway ? Maybe a third module should exist, feeding this one with relevant ground data and figuring out what to give the ground.

...