improve and document mission interface

[flixr]

We have a basic mission interface with the mission modules:
mission_fw.xml
mission_rotorcraft.xml
https://wiki.paparazziuav.org/wiki/Mission

While it now has support for global LLA coordinates, lat/lon are sent as float which should never be done because it has really bad precision/resolution.
Also how about using a variable length array for PATH instead of fixed 5 waypoints?

Todo:

• don't send lat/lon as floats as that has bad precision (use int32 with 1e7deg instead)
• don't convert LLA to float again in the fixedwing version (we seem to miss functions to convert LLA to UTM in int or double...)
• add one fixedwing and one rotorcraft example airframe to conf_tests.xml
• improve documentation (also description in module.xml)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[gautierhattenberger]

Concerning the 5 WP in Path, I did it like that because:

• I'm not sure sending a variable length array uplink really work (possible data alignment issue ?)
• it prevents people from sending too many WP
• since the mission element is a union, I didn't want the path element to be to big
• it was a fair trade-off I think (if you need 2 segments, send 2 segment elements, if you need 3 or 4 segments, send a path element)

[flixr]

Hm... I can understand the point about the union and ease of implementation.

Still think that it would be nicer to use variable length array in the end, that would also save bytes in the messages if your path is shorter.
It would also make the MISSION_SEGMENT superfluous, as it is simply a PATH with two entries...

On the other hand, do we really want to have the same alt for the whole path (instead of a separate alt for each point in the path)?

[agressiva]

about mission module, i think it a good idea to make a polysurvey (osam like).
I think about that some time ago but i am not a master in c programming.

what you suggest on how pass waypoints to MISSION_SURVEY ?
it need to be dinamic because some poligon use 10 point and others may use 20 ... 25 ...

its very usefull for pro grade photogrammetry jobs.

[benlaurie]

Did I get my sums wrong? 1e7deg is up to 1.5 meters of error, isn't it?

On Tue Nov 25 2014 at 7:58:57 PM Eduardo Reginato lavratti <
notifications@github.com> wrote:

about mission module, i think it a good idea to make a polysurvey (osam
like).
I think about that some time ago but i am not a master in c programming.

what you suggest on how pass waypoints to MISSION_SURVEY ?
it need to be dinamic because some poligon use 10 point and others may use
20 ... 25 ...

its very usefull for pro grade photogrammetry jobs.

—
Reply to this email directly or view it on GitHub
#984 (comment).

[gautierhattenberger]

if you consider the earth radius at around 6371km, it gives a resolution of 6371000_1e^-7_pi/180 = 0.011 m. So 1cm resolution for 1e7deg with integer. Not sure what you can expect from float.

[flixr]

A 32bit float has 23bits for the mantissa, which is a bit more than 7 digits. Since you already use 3 digits to represent the part to the left of the decimal point, that leaves about 4 digits for the rest..
So in the worst case of 180deg you have a precision of only ~3m!
http://en.wikipedia.org/wiki/Decimal_degrees