Add 3D Home Distance variable

[MrD-RC]

I would like to see a new 3D Home Distance variable in iNav. It could be used in the OSD and with Logic Conditions.

It would combine distance from home with absolute altitude (negative altitudes will give a positive addition to the home distance)

This could be used to give a true distance from home and trip distance in 3D space, rather than just along the ground. It could also be used in logical conditions to perform 3D distance based functions.

[issue-label-bot]

Issue-Label Bot is automatically applying the label Feature request to this issue, with a confidence of 0.96. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[MrD-RC]

It would actually be better if this used some basic trigonometry to calculate the line from the home position to the model, instead of just adding the distance from home to the altitude. This should be simple to do in the flight controller.

For example:
2000m away and 1000m up
In my example would be 3000m
But, the actual 3D home distance should be 2236m

Calculation:
2000 x 2000 = 4000000
1000 x 1000 = 1000000
4000000 + 1000000 = 5000000
sqrt (5000000) = 2236 (rounded to 0 decimal places)

This would work (I think) if the home distance and altitude use the same units. I am now thinking that altitude is in cm and home distance is in m (at least in logic conditions), if so the alt would need converting to metres too.

homeDist3D = round( sqrt( (home_dist * home_dist) + (alt * alt) ) );

[avsaase]

I think this is addressed by #6226.

[MrD-RC]

Perfect @avS2 thank you.

[MrD-RC]

The only thing in the original request that I can’t see (I’m looking on a mobile, so could be me) is the ability to add the 3D home distance to the OSD.

That may be addressed here #6197

[DzikuVx]

GVARs can be displayed on the OSD

[avsaase]

I personally would be hesitant to have the 3D distance on the osd instead of the ground distance. For me the use case of this lc is to let the vtx power depend on the 3D distance since that is the distance the signal has to travel. For navigation purposes 3D distance could be rather confusing in the case you are flying directly overhead but you read a large distance on the osd.

[mirov]

An interesting use case for this 3D distance feature is what happens if you have a model directly above the transmitter and the antenna nulls line up causing a RSSI drop and FailSafe. The alternate minimum distance procedure is meant to protect a plane/drone from spinning blades while sitting on/near the ground at the home point. But a FailSafe at 100m altitude above home shouldn't trigger the alternate procedure. I think that's what happened on a fixed-wing maiden today. And while I'm writing, what would happen if the FS happened at 100m above the active SafeHome ? And btw, what is the behavior for a fixed wing if the FS procedure (or alternate procedure) is "Drop" (as is the default) ?