Hi there people!
I, along with @frizensami and @disgruntled-patzer, am from Yonah and we are in the midst of building a quad-plane based cargo drone infrastructure to help our hospital partner deliver vaccines. Its been a wild ride and many things have happened since we started the journey back in Jan 2017 - going from a tandem helicopter design to now a quadplane (since Sep 17); We have now gone through 3 iterations of quadplane and is now on our 3rd big boy quadplane.
Our journey led us to want to understand what’s going on under the hood in Arduplane. As we chugged along, because there was a lack in code documentation in a way that newbies can learn easily, my team (mostly @frizensami and @disgruntled-patzer) traced the code function by function and came up with a bunch of block diagrams to try and understand just how Arduplane-QP works and flows.
Having been blessed much by various open source projects in the past - Arduino, Reprap, ROS, OpenCV - I’ve always only been taking and its always been on my mind to give back when I can - projects sometimes move so fast that most times I don’t have time to. I hope that in sharing these diagrams, it’ll help someone out there learn Ardupilot, at the code level, better and faster. I also hope it’ll help to draw some help from the more experienced ones in this community if we have made any mistakes.
A few things to note regarding these diagrams:
- It is still ongoing; i don’t think we have captured all the mistakes.
- it is based on Arduplane 3.8.4
- Because there are so many routes and cases in the code that one could trace, we set for ourselves the context of a “typical AUTO quadplane flight” when we trace.
- We define governing functions to be the few key functions that has the most active influence on flight behavior (that closes the loop from mission file to servo) of a typical AUTO flight of a quadplane. Right now, we have identified and diagrammed out 4 functions in the scheduler list: navgiation.cpp, update_flight_mode.cpp, stabilize.cpp and set_servos.cpp
- We understood the scheduler with an analogy “video game player queue analogy”; If there’s demand from the community, we’ll be happy to expound. Understanding how the scheduler works is key to understanding how AP works.
- This is kinda another view of AP’s architecture. We needed an accurate imagery to relate to and hold everything together as we trace and understand how the cogs accurately move at the highest level.
- Data exchange done via global variables
- High level over view of the “governing” functions, especially how they all “connect” tgt via the data that they dump or use.
- Which waypoint to target next.
- When we finished tracing this, it became clear that a lot of the “copter” part of a quadplane angle and rate are calculated here, how differently yaw and throttle is treated and how update_flight_mode “connects” with navigation, L1 and the TECS
- This is where more yaw stuff and intermediate servo values are calculated.
- this is where physical motion is done. What surprised us is that the transition behavior actually happens here.