Poly survey via Guidance Vector Field addition

[noether]

Some updates regarding the Guidance Vector Field (I will update the wiki accordingly).

• The gains 'ke' and 'kd' are not "global" anymore and each trajectory has its own set of gains. If the user runs a mission with different trajectories, then there is not need to change the gains on the fly anymore, e.g. poly survey (see later). The user can also tune the gains separately and save them in its airframe.

• More primitives regarding ellipses, sin and lines have been added. In particular, now there is 'gvf_segment' where the aircraft tracks a segment defined by two points.

• The set NAV now has 'nav_survey_polygon_gvf_run()', which does exactly the same as 'nav_survey_polygon_run()', but employing the GVF instead of the Carrot. One of the advantages is that during the segments, the aircraft really tracks the line and it is not going to a waypoint (Carrot).

[noether]

mmm I do not understand/find which tests my code failed, any help? :P

edit: it is most probably because of the new field in the GVF msg (pprz link)

[flixr]

The problem is that you added gvf functions (specifically gvf_set_direction) to nav_survey_polygon and now that depends on the gvf module... and since the gvf module is of course not added (and shouldn't be) to each airframe using survey_polygon, it fails for those...

[noether]

ahh I see the problem then. Thanks Felix.

Then it is not only gvf_set_direction, but gvf_ellipse and gvf_segment, i.e., all the functions that substitute the carrot guidance by the gvf_guidance.

Mmm, what would you suggest? For example, to move this navigation function to the gvf module? or to
put the new two functions in the nav_survey_poly between #IFDEF GVF? (maybe this is dirty?) another ideas?

[OpenUAS]

Not really the fault of @noether , well maybe add, #ifdef USE_AD0 around the static const uint32_t ADC_AD0CR_SEL_HW_SCAN = 0 and rest etc. etc. maybe. A warning about an unused var breaks the build, very strict policy indeed ;-)

[flixr]

@OpenUAS the build doesn't break because there are unused vars...
Is because of the additions to the nav_survey_polygon module that now effectively requires the gvf module to be loaded as we...
@noether if you can, it would be nicer to put those functions in the gvf module... as far as I can see there is no reason to have them in the nav_survey_polygon module....

[noether]

yes, I think it will be the best solution, I will put these navigation functions in the gvf module.

Thanks for the input guys :P

[noether]

do not accept this pull yet. I had to synchronize my repo in order to have it ready in another computer on Monday :P. I will test this change in a flight during next week.

[noether]

Hello,

if you do not have any further comments or requests, the pull request is ready to be merged.

[noether]

It seems that the conflict with pprzlink has been solved by rebasing the latest paparazzi/master with this branch.

[noether]

I do not understand why I still have 'conflicts' with pprzlink mmmm. I have synchronized this branch with the latest pprz/master and made a 'make clean all' (so I know it is pointing to the correct commit of pprzlink).

Last time I have solved it with a 'big rebase', which was an ugly solution.... any ideas?

edit

I have pulled from pprz/master again (pprlink was updated again in master xD), it seems now there is not conflict

[podhrmic]

@noether sorry I had to make some small changes in pprzlink

[noether]

@podhrmic haha, no worries man :P. Next time I know how to fix such an issue without too much mess .

[podhrmic]

@noether apparently there are still some requested changes from @flixr regarding the docs and the code indentation. Could you please address those so I can merge this?

[noether]

@podhrmic

I think I have already addressed the points of @flixr. Please, let me know whether this is not the case and I will add the requested docs.

By the way, last week a friend at ENAC has found a small bug in this pull request. It is not important but it can be annoying when one uses the poly_survey with the GVF. I will fix it this week and then update this pull request.

If you are ok with this upcoming update, then we can merge it :P.

[noether]

Oki, I think this is the last time I add new features in this pull request.

I have added new primitives for following straight lines (endless lines, segments and 'segment loops'). The GVF wiki has been updated accordingly with the new available functions for the user.

Let me know whether the style or other things are ok for you, or whether something needs to be better documented in the code.