Stripped down navigation

[peabody124]

So I know Kenn won't love this, which is why it isn't up for a pull request yet :).  I've done some work on the path planner that I think is positive and makes the code a lot simpler to work with which I'd like to advocate for now.

Changes:

1. Curved paths are defined by a start and end position, a left or right curve, and a radius.  The end is the true end instead of a circle.  Here is an example of flying a box path with clockwise and counterclockwise segments.  Obviously this is a shitty path for a plane :)

2. To make sure that following these curves never has singularities in the mapping from position to desired velocity it is constrained to curves of less than 180 degrees.  There is a separate mode for flying a circle continuously.

3. Removed the PathAction object and updated the GCS to  work with this.  The obvious consequence of this is we no longer have jumps, error paths, etc.  As I've said previously for now at least I'd _really_ rather work with a simple planner while making the follower work really well.

4. The path planner is now super super simple.  It just looks at the path status for completed and when that happens advances to the next waypoint.  When a waypoint is active PathDesired simply gets the values from that waypoint with the additional logic that the start position is the previous waypoint (or in the case of the first waypoint the current position) and the starting velocity is the previous waypoint velocity.

5. paths.c takes in the PathDesired object to specify the desired path.  This is the first step of moving any logic for the path desired from the follower if we want to move towards using Feret-Serret representations.

6. I documented the shit out of the GCS path planning code to try and tempt Kenn :)

7. Moved the calculation of the LLA positions of waypoints in the uavomodelproxy instead of the map gadget so that the pathplanner gadget can work standalone.

If there is support for this I want to move the widget for editing waypoints into a standalone plugin and gadget, and then it can also pop up when requested from the map.  That way you can also do what the old waypoint editor does and highlight the currently active waypoint while flying.

[peabody124]

The dialog is now ported and the selection is common across the plugin so it syncs between all the maps.

I'd like to discuss the UI a bit.  Right now it feels a bit overwhelming.

1. Is there ever a situation where some of the waypoints are relative and others are absolute? If not we can move the relative column into an option for the whole plugin.
   
2. It would be nice to be able to toggle displaying the waypoints with relative (NED) and absolute locations as well.
   
3. Do we want altitude and altitude above home?
4. I like using the selector to indicate the active waypoint but worry that might get confusing with the normal selection mode.  Should we have a toggle or what?

[peabody124]

Ok and it was ridiculously easy to restore the popout functionality using the plugin and all of the dialogs/gadgets/maps stay in sync with the selected waypoint.

P.s. PT - you might disagree with this, but I'd suggest the graphical items on the map should not have a concept of relative coordinates.  They should only have a real lat/lon value that is set from the model and which they update on the model.  This will get rid of the loops where they keep calculating bearing and LLA.

Currently we have

LLA

NED

bearing/distance

The FlightDataModel object needs to track these to be able to display them simply in a table (or it can compute some of them on the fly and fail when they are set).

Anyway do we want the ability to set all of those types?

[peabody124]

Ok.  These changes are up for review https://github.com/PhoenixPilot/PhoenixPilot/pull/40

It's a pretty comprehensive set of changes but I feel like it's an improvement and will be clean enough to allow extensions in the future as needed.

[PT_Dreamer]

Sure, if the relative logic was moved outside the map lib the wps only need to know their absolute position.

[peabody124]

I forgot to add that to the change list in the review.  I connected the update from map to model (modelmapproxy) to occur on waypoint changed manual since that is when it is dragged.  That removes the circular loops.  The bearing is displayed by the waypoint as you move since it still calculates the waypoint representation of bearing based on WPChanges.

[Kenn Sebesta]

1) Yes, I think there will be many good reasons why a waypoint might be relative. I don't see an immediate problem turning it into an absolute representation in internal memory, though, so long as the user can still choose to update a waypoint using a relative approach.

2) Yes.

3) Probably MSL and AGL would be better.

4) Tough to say until we get some more experience with using the waypoint manager.

[mnuapel]

When speaking about relative waypoints do you always mean relative to home? I think it would be useful to have a kind of waypoints that are relaitve to the previous waypoint.

For example:

Waypoint 1: Go to X,Y (absolute)

Waypoint 2: From waypoint 1 go 200 metres to the west and climb 10m

What do you think?

Also I think relative waypoints should not be converted to absolute representation in internal memory. For example I can imagine to have pre-programmed a mission that will always make 10m radius circles in 10m over the takoff point. If the internal representation of waypoints will be always absolute, this "mission program" cannot be activated in different location, without recalculating the waypoints in GCS and reloading back.

What do you think?

[peabody124]

Weird I swear I replied to this earlier.

Right now the whole path will be relative to HomeLocation.  If the HomeLocation is saved in the UAV then it will essentially be in absolute coordinates.  If the HomeLocation is not saved then it will be relative to the first fix.  I'm not going to argue this mechanism should be made more explicit.

As to making waypoint 3 relative to waypoint 2, that I would be a lot more hesitant about.  It means you only know where a waypoint is based on how you got that which would likely lead to some very dangerous logic.

[Kenn Sebesta]

Just a quick note, I prefer to fail to arm if we haven't set home. It would be better to have a TX API for configuring home. I've seen GPSes be off by as much as 500m in first fix, and they got stuck there for several minutes, with 5 (or more?) satellites.

[peabody124]

I'll agree to that once we have a convenient mechanism to reset it or a bit more data on that (we can change the requirements for when it self-sets home) but I use this mechanism all the time when I change flying sites and don't bring laptop.  That being said I've done that mostly with PH so we should keep this in mind for now IMO.

BTW mnaupel isn't the first person I've heard who wants a path to just be relative to where you start.  Gary Mortimer always said that was the nice thing about Attopilot.  You might have a survey path loaded up.  Go to a new location, get a fix, throw it.  Boom.

[peabody124]

Ok.  Fixed wing works again and follows curved path segments too