Complementary filter optimization: How to measure STM32F10x performance

Dear all,

I have been reviewing the attitude estimator implementation in the firmware code (estimator.cpp) and the docs @ .

I think that there is place for optimization in the implementations of the angular velocity integration, I would like to make a pull request but for measuring the improvement (and to be sure it is significant) I am interested into know how did you measured the time performances presented, i.e., the 90us in the Estimator::integrate_angular_rate function and the 12 us in the smoothed_gyro_measurement() function.

At the moment i did not have access to neither F1 or F4 controllers, so I am wondering also if in the SITL implementations the estimator code runs as it is (i read somewhere that the simulation was simplified, but i do not know up to which level)

Congrats for the project.

Welcome Jul!

Those numbers are from an F1, where computation costs are significantly higher (the F1 does not have a floating-point unit, so all floating point operations are emulated). On the F4, the cost is significantly lower since it has a single precision FPU. The whole autopilot on the F1 consumes about 70% available computation resources, whereas on the F4 we’re sitting at a leisurely 6% utilization.

I measured the time using a GPIOs and an oscilliscope (I.e. I set a pin high when we started the filter, and then set it low when it completed.) This was easy me, but I could imagine simulation methods working as well. However, it’s important to realize that we’re most concerned with performance as it is observed on the actual flight controller hardware. This can be pretty different than modern x86 hardware, where you have deep processor pipelines, vector floating point units, advanced operations, etc… that are all missing on these small cortex ARM chips. The problem with this is that gains observed on x86 hardware may not be the same for the F4/F1, the only way to be sure would be to run a test.

SITL runs the entire firmware stack unchanged. All the simplifications are with respect to aerodynamics (i.e, we have a simplified drag/thrust motor model). From the software side of things, there are absolutely no simplifications when running rosflight_sim.

Many thanks @superjax,

With the numbers of the F4, maybe no further changes are needed. Anyway I will share the commit as soon as I have it.

Thanks for the additional info,


Nice! I’d be really interested to see it!