PhoenixPilot/PhoenixPilot — pull request #40 by peabody124 (2012-12-03 16:23:55+00:00)
Title: Simplify navigation

So this is a pretty big merge request. There is a lot more that I'd like to do but I'm also incline to limit the scope a bit.
1) Remove path actions objects so the waypoint contains all the information about that waypoint
2) Introduce a FlyCurve PathDesired where start and end mean exactly that. The mode parameters field sets the radius. http://imgur.com/xQW23
3) Paths are defined to start from where you are and fly a vector to the first waypoint. From there each waypoint defines the mode from the previous waypoint to that waypoint.
4) Moved the path planner into a standalone plugin so it can be instantiated in the desktop. The method to make it pop out or edit waypoints works in the new plugin http://imgur.com/QDb1V but this removes any dependency on OPMap for making paths.
5) When the last waypoint is hit enter position hold mode at the current location
6) Changes to telemetry required for a robust uploading of waypoints
7) A layer of code in the ModelUAVOProxy to perform robust uploading

Limitations (and I'm ok with them being blockers):
1) Not tested on fixed wing yet. I'm not sure the state of the followers yet.
2) One can implement undefined paths (they also show up as disconnected on the GCS). For example if you have two waypoints at 50m and the radius is 40 there is no path to connect that. I'd like a more general way for the FlightDataModel to refuse to upload that and the GCS to show red links for broken.
3) No way to remove nodes from a path. In my previous implementation one of the modes for a waypoint would be "stop" which meant to not fly to it. I'd prefer to do this more explicitly by setting the mode to the last (desired) waypoint to HoldPosition for any valid path. However this then lacks the mode to get there. This can also be done with two waypoints - one at the location with a mode to get there, and another at the same location that says stay. The GCS can then not show any subsequent waypoints (that might be set in the FC memory). Basically the representation can handle it - we just need to clearly define the requirements for a valid flight plan.
4) No indication if the upload of a flight plan fails (hasn't happened in my testing yet but it can)
5) More specifically if we want the ability to modify paths in flight we might want to extend to only pushing the dirty waypoints? However that enforces a closer coupling between the waypoints UI representation and the waypoint UAVO concept than I'd like (we might eventually have 3 waypoints for a corner of a box if we want to automatically filet it, for example).