Matt, To me there are two primary areas where we do not yet really seem to understand the problem, and deliver a good solution. 1). Creating an accurate probabilistic view of reality from multiple sensors. We do not yet have a good architecture for that in MatrixPilot. It will become more important over time. In detail today, we want altitude delivered from GPS, Barometer and Sonar. How best to form a picture of reality from those ? At the other end of difficulty: we do not yet integrate vision into the IMU's view of orientation, and we do not integrate vision into location. I look forward to one day having the time tofinish this course by Sebastian Thrun on the driver less car.<https://www.udacity.com/course/cs373> 2) I would like to see a unified model for navigation and flight using an understanding of the forces that can be manipulated on an aircraft. Such a model will fly a Quadrocopter or an aeroplane just as well, because it is based on Force = Mass * Acceleration (and the equivalent for rotation), and understands the flight dynamics of the aircraft. I am excited by your work on your branch of MatrixPilot because you have started down that route for sailplanes. (You now incorporate Coefficient of Lift, and Coefficient of Drag into your navigation and flight algorithms). In truth, the one model, could potentially work for many types of aircraft. Our autopilot could then fly an aircraft that was both a plane and a quad in one structure, with relative ease. The core problem in this second model is the mathematical representation. At any one time, the navigation of the plane needs to describe all the sets of solutions (potentially infinite sets) initially, and then apply constraints (e.g. fly upside down, do not exceed max velocity, do not exceed minimum velocity, arrive at waypoint at time T, do not roll more than 30 degrees), to reduce the infinite set of solutions to a smaller set. And then finally incorporate a cost model (e.g. fly with the least energy loss), to come up with the optimum navigation solution. So for me, I'm interested in the mathematical model of how all of that can be represented. Crack the maths, and software will fly the plane without lots of special caveats and a spaghetti of different code paths, which is how we do it today.
API for UDB Edit
Would it be beneficial to have a high level, logical API for the UDB? The idea would be to expose the internal IMU data, representing the state of the flight vehicle, while hiding the implementation details. This would allow for future UDB implementation changes without impacting integration with external systems. Perhaps a first implementation could be a read only API, allowing external systems to use the data but not change it? So we'd have logical functions like 'getAltitude()', 'getRateOfClimb()', etc. This would also make it easier for new developers to use/integrate the UDB without having to understand the internal details. Sorry if this is a crazy idea, but coming from a high level s/w background, this seem kind of natural to support integration.
Ardu udb comparison Edit
FWIW, I am planning on getting back to VTOL work in a month, so that probably slots in at number 5 on the second list. And an anecdote... I just hosted Moses for a month (the young man from Kenya that started the java GUI for UDB config) and we both still agree that we prefer UDB over ardupilot. But he went back with ArduPilot gear with two Nurfs so he could do a demo for a wildlife conservation project. I am looking at the list and trying to see if there is anything that stands out as to why we went with ardupilot for the demo.... Really about reducing our risk as we needed something fairly plug and play with decent GCS integration. The Mission Planner with config via USB and zig bee, plus support for an Android GCS were probably the biggest factors. It takes some time when you start trying to integrate a payload and actually architect a system that can be used in the field by non experts. We have no doubt the fantastic work that Bill and all devs are doing flies the plane better, it just seems harder to get there from here at this point. I had hoped that we could find the time while Moses was here to start working on the operational end of the UDB but we did not. All I can do at this point is provide feedback and hope its considered in your roadmap.
Range, q16/long Edit
Another example: While coding up the fbw branch, I was continuously struggling against data range problems. Scaling variable up and down was a huge effort sponge and a potential source of failure. The solution was a combination of Q16/long and 16bit floats. This made the code development much faster. There are significant down sides which means that this is not the best solution. I suspect I know the right solution but maybe I am trying to solve the wrong problem. Regards Matt