forward declaration to avoid ARM-specific __fp16 in transitive dependency of stabilizer_types.h

[jpreiss]

stabilizer_types.h now depends on lighthouse_calibration.h, which depends on ootx_decoder.h, which defines a struct containing the __fp16 type. This type does not exist on x86, so it breaks the Crazyswarm Python bindings for stabilizer_types.h.

Since lighthouse_calibration.h only declares functions that accept a pointer to the struct containing __fp16, we can use a forward declaration instead.

(In contrast, making stabilizer_types.h not depend on lighthouse_calibration.h at all would require forward-declaring some nontrivial function pointer typedef.)

[jpreiss]

Sorry, I forgot to build/run the tests. Will fix this.

[jpreiss]

It seems that the test problem is nontrivial because CMock only generates mocks based on the header file, so it can't mock the functions that accept that struct. I'm not familiar enough with CMock to fix this problem at the CMock configuration level.

We could also use conditional compilation to switch between forward declaration and including, either with a flag for test builds, or a flag for x86 builds.

Maybe the easiest solution is to just #define __fp16 uint16_t in our bindings, since we don't need that struct anyway...

[jpreiss]

adopting the "easiest solution" above for now and closing. please comment if there's a less hacky way to get around this that I'm missing.

[krichardsson]

Hi @jpreiss !

Yeah, the dependency tree is a not stellar and some clean up would be nice at some point...

The reason there is a dependency to lighthouse is that it is needed for the sweepAngleMeasurement_t that is used when pushing data into the estimators.

I have only had a 5 min look at this, but what would happen if we moved the estimator related types to estimator.h instead?

[jpreiss]

@krichardsson Hi! thanks for taking a look.

Moving structs to estimator.h might fix the problem for now, but it would return if we want bindings to the estimator modules in the future. I could see that happening for SITL testing.

The uint16_t workaround feels OK to me. In general, we expect C primitive types to exist on both platforms. __fp16 is a weird edge case. ootx_decoder.h does not depend on any ARM headers, so it is already "clean" in the sense we normally mean w.r.t. firmware bindings.