Transition to more double-precision maths

[magicrub]

In an effort to take advantage of future hardware that offer hardware assisted double-precision computation and the adoption of RTK, the codebase should be improved to use 64bit instead of 32bit precision where appropriate:

• gnc/EKF maths
• GPS RTK drivers
• GPS related maths (maybe already done?)
• mission waypoint support (new mavlink v2 packets?)
• position maths for various helper functions

There are a few options to consider, dependent on the build target:

• use "# if USING_DOUBLE_PRECISION" to declare double instead of float variables
• duplicate functions with float->double or int32_t->int64_t

Here are build targets to consider:

• Anything POSIX (x86/ARM: RasPi, QuRT, x86, ...)
• FMUv7

[dagar]

Has anyone benchmarked float vs double performance on a pixhawk or similar stm32f4? It would be interesting to know roughly where it matters performance wise and then be more deliberate in choosing float vs double.

There might be large portions of the code base that could be handled identically (preferring double) and only a few critical areas where single precision math on older hardware is necessary for performance. Hard to know without benchmarking.

[dagar]

Some data from switfnav - http://docs.swiftnav.com/wiki/STM32F4xx_porting_and_speed_notes

Not surprisingly double addition, subtraction, and division are an order of magnitude faster with hardware, but interesting that multiplication is about the same or even slower. Obviously this is a microbenchmark consisting of almost nothing but floating point operations, but it illustrates the best/worst case.

If we establish a set of crude benchmarks we can run on both new (FMUv7) and old (FMUv2, v3, v4) hardware we could start incrementally changing floats to doubles where we think increased precision is likely to matter. Then we'd still need to decide how best to handle float vs double based on hardware once we hit the first case that seriously degrades performance.

Side note from the swiftnav wiki

• we should try enabling -ftlo and -ftree-vectorize across PX4, but only after good benchmarks are in place and tracked

[davids5]

@dagar is the an FMUv7 or is that a FMUv5 on M7 Core?

[dagar]

Repeated that without thinking, but I meant FMUv5 with an STM32F7. I now see there are different versions of the STM32F7 with and without the double precision FPU. Can you provide some clarity @davids5?

[davids5]

Fun isn't it!

FMUV5 is based on CONFIG_ARCH_CHIP_STM32F765II=y

Based on marketing info.....

But it took me a while to believe there realy is a DPFPU

I do have it set in the conf CONFIG_ARCH_DPFPU=y

[PX4BuildBot]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)