Data fusion

=== Description ===
https://groups.google.com/group/uavdevboard-dev/browse_frm/thread/b324c76e1bb9e1e0/e543242112a5580b#e543242112a5580b
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 ===
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 ===
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 ===
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
Category:Gentlenav