the skid landing from osam is really strange, not completely sure what was the idea behind.
Especially one of the steps looks dangerous with altitude mode enabled together with a killed throttle (Approach step).
Since it is not documented, I suggest to drop it

anything missing to merge this ?

• OSAM routines should still be split
• probably drop skid landing as you proposed?
• maybe one catapult/bungee routine is enough?

Naming of init/run functions still has to be harmonized...

Not discussing new code filenames names as good as I can ;) but other issues.

• Catapult should remain preferred, using that code. Did not try OSAM bungee. Quickly walked through code, co-existence otherwise get rid of bungee.
• Yes, split OSAM code, get rid of OSAM n naming, make honorable remark sourcecode
• bomb should be renamed to something like nav_store.c and internal to nav_store_release nav_store_
  (store: http://www.thefreedictionary.com/aircraft+store) Bomb has a negative association. An autopilot called Paparazzi is already an issue, we do not need more controversy)
• see no use for flightzone.c/h, there is already function IsInside.
• Spiral.c possibly could be done with default flightplan, not played enough with that on to see it's benefit, but has DIGITAL_CAM in i, maybe handy but IMHO should not be in there.
• SNAV is nice and should surly stay, but nav_smoothing a better name

How about simiply drop instead of bomb? Would also make more sense wrt. to things like outback challenge.

it is both about the object, the course and the release, maybe unshackle ;) but anyhow drop is already much better a term, thx. I'm looking in direction of payload, release, drop, I think the shoot in the code is release, the bombi called store. in the code the word bomb is intermixed and means different things e.g. bomb_trigger_delay is release_trigger_delay and bomb_x is object_x or store_x

Catapult should remain preferred, using that code. Did not try OSAM bungee. Quickly walked through code, co-existence otherwise get rid of bungee.

Catapult and bungee are definitely to different way to takeoff and they need different procedures

split OSAM code

already done

bomb should be renamed

done

see no use for flightzone.c/h

already removed

Spiral.c

mostly harmless

SNAV

the actual benefit is not the smoothing but the time sync at arrival point, which is way from being perfect and handy to use. Should be kept anyway I think.

SNAV
the actual benefit is not the smoothing but the time sync at arrival point, which is way from being perfect and handy to use. Should be kept anyway I think.

also still needs proper naming of the functions, and maybe should be renamed from nav_smooth to nav_synced_arc or something like that?

Some ramblings:

Reason: function names show up in flightplans, and flightplans are likely to be created by people with not so much inner autopilot working or programming experience. The flight plan terms and functions should be very descriptive and well named to easy flightplan writing (It kind of having a Flightplan "language")

Maybe already done but source code changes are at lightning speed nowadys ;) and some text where still in my scratchnotes

• Since border_line is something different thant line_border
  border_line.c -> nav_border_line.c
• Still add flightplan since "nav_common" could aslo entail some other routines flight_plan
  *Simply:

nav_gls.c
nav_cube.c
nav_line.c
nav_survey_rectangle.c
nav_common_flight_plan.c
nav_traffic_info.c

*Rename poly_survey_adv
nav_survey_polygon.c

Since poly is not to obvious (well yes to us geeks..) and adv is surely not clear, I know it should mean adv(anced) but why would we add that all things as advanced in PPRZ ;)

for nav_smoothing.c
indeed better have: nav_synced_arc

Discsurvey is gone.. nav_survey_disc otherwise. Shame that it is gone it was another nice example of how to extend nav routines. (yes, I know one could dig in code history but that is no to likely for most to do) Anyhow it is maybe just me being sentimental over code gone over time... ;)

BTW thx to all for giving good naming a good deal of thinking and discussion, in the end it will make pprz usage more joyful for people starting in PPRZ

Since border_line is something different thant line_border border_line.c -> nav_border_line.c

Not quite following, it was renamed to nav_line_border for now (which seems fine to me).

Still add flightplan since "nav_common" could aslo entail some other routines flight_plan

You mean we should add the old "extra" navigation routines by default, rather than having the user load the respective module? Or what do you mean?

Rename poly_survey_adv

Already renamed to nav_survey_poly_adv. We could rename to nav_survey_polygon_advanced, but then names are starting to get really long...
Also it would be nice to clean up the two polygon surveys and keep only one (I haven't really used either so someone else has to do that...)

for nav_smoothing.c
indeed better have: nav_synced_arc

Yep, still has to be renamed..

Discsurvey is gone.. nav_survey_disc otherwise.

nav_survey_disc is there... but it needs docs, so if you have used that, could you plz write a short doc section for it?

Concerning the function name, I would vote for "start" finally. The reasons are that nobody could come with a "good" solution and there are as many pros/cons for all candidates. But also because the modules are already using start/stop functions for stuff called before periodic calls and outside of the general init phase, so there is at least some consistency here.

But also because the modules are already using start/stop functions for stuff called before periodic calls and outside of the general init phase, so there is at least some consistency here.

These would actually be more aptly named "pre_start" and "post_stop", where the start and stop refers to the starting/stopping of the periodic function of that module.
IMHO that would actually be a reason NOT to call it start, since it clearly does not "start" the navigation routine neither is it a function to run before the "start" like it's currently used in modules(rather a "pre_run" function).

Personally I would vote for "prep" (or if that is not clear the long version "prepare") or setup.

nice find, this pre_ and post_ namings are not all that bad.

So what do we do about naming now?

Also are there any volunteers to check differences between the two polygon survey and line functions?

I still suggest to keep the current names (mostly because it doesn't make such a big difference in the end, and we have other stuff to do...).

For the differences:

• between lines, the standard one is continuously flying between two waypoints, while the osam line seems to be more like a path function (several lines between a sequence of waypoints) but with the guarantee that the complete segments are flown by make circles at the begging of each leg for correct alignment.
• between surveys, it doesn't seems to be much different (same type of input parameters), polygon is using DC_SHOT functions as an option, while osam uses generic LINE_START and STOP macros at beginning and end of lines.

The lines modules can probably be kept, with some doc on osam. For the surveys, it is up to photogrammetry users to tell which coverage function is the best, and they can probably be merged in the end (in an other pull request).

Smooth nav needs a better interface but it can be done later, so this pull can be merged.

It cannot be merged yet, some names are still not correct and some flight_plans need to be updated for the new names.
Also the airframe files that are in the example conf and test conf need to be updated to include the nav modules they use so everything builds.