Improve high_latency_tgt_dist()

[hunt0r]

Summary

Some spots were incorrectly using decimeters (dm) rather than decameters (dam). Also improved some values and typecasting.

Classification & Testing (check all that apply and add your own)

• Checked by a human programmer
• Non-functional change
• No-binary change
• Infrastructure change (e.g. unit tests, helper scripts)
• Automated test(s) verify changes (e.g. unit test, autotest)
• Tested manually, description below (e.g. SITL)
• Tested on hardware
• Logs attached
• Logs available on request

Description

This resolves #32838 .

• Some unit-scaling was done outside a MAX(..., uint16_max), which means the likely-intended max-value was not possible.
• Unit suffix is added to the function, per our preference for that in our dev wiki.
• Some divisions are converted to multiplications, per our preference for that in our dev wiki.
• Some implicit casts are made explicit.
• One change from 0.001 to 1e-3 was made, because I find that easier to read for exponents >= 3.

[peterbarker]

I wonder if we should spell out "decameters".... I didn't recognize dam

[hunt0r]

I wonder if we should spell out "decameters".... I didn't recognize dam

Just ICYDK, it's the preferred abbrev from our wiki.
(I too don't like it, FWIW.)

[tpwrules]

If you want my two cents on the units, maybe it should not be in the function name. There are all sorts of weird units in these high latency functions like duodegrees and quintimeters per second. But they are listed in the comments in GCS_Common.cpp.

Not every bug needs the entire thing rearchitected to fix :)

As mentioned I do like the improvement in very high distance scenarios.

[timtuxworth]

If you want my two cents on the units, maybe it should not be in the function name. There are all sorts of weird units in these high latency functions like duodegrees and quintimeters per second. But they are listed in the comments in GCS_Common.cpp.

Not every bug needs the entire thing rearchitected to fix :)

As mentioned I do like the improvement in very high distance scenarios.

We have a fairly well discussed list of standard units here https://ardupilot.org/dev/docs/style-guide.html#preferred-abbreviations-for-units and "dam" isn't on the list. I think adding units to the method fits the pattern we are going for, but if so probably add it to the list maybe with a comment "only used for high latency mavlink messages" (or somethink like that.

[timtuxworth]

I wonder if we should spell out "decameters".... I didn't recognize dam

lets just add it to the list: https://ardupilot.org/dev/docs/style-guide.html#preferred-abbreviations-for-units

[tpwrules]

I wonder if we should spell out "decameters".... I didn't recognize dam

Just ICYDK, it's the preferred abbrev from our wiki. (I too don't like it, FWIW.)

Is it? I do not see it, and it's not on the page Tim linked. Can you provide a link? How did you decide that it is?

[hunt0r]

How did you decide that it is?

Wiki says "Functions that return a single physical value or variables that represent a physical value should be suffixed by the physical unit." From NIST, the abbreviation for this unit is 'dam', and nothing in the table overrides that.