The way the “imufupdate” command works is by sending a signal to the IMU-F processor. The bootloader then pulls the new code from the binary we distribute, decrypts it, and then self-updates. The only communication between IMU-F code and Butterflight is over an SPI boundary. IMU-F talks to the flight code just like it were any other Gyro.
No. We are not in violation of the GPL by distributing as an aggregate binary as some have claimed
See: Mere aggregation
A hex is just like any binary file, *.dmg, *.iso or *.zip. It’s simply a different encoding. Neither Butterflight, nor the IMU-F code in the aggregate know anything about, or reference each other, in any way.
The aggregate is allowed by the GPL because we do not execute the code in the same memory space nor are the binaries themselves modified post-compilation. They are concatenated with a clear separation of “blank” data and conventional start and end segments.
There also also plenty of other examples of closed-source code running alongside open source code even on our own flight controllers. DFU, for example, is closed-source by ST-Microelectronics. It even runs on the same chip and is what you use to flash code onto any STM processor.
It’s also our mission to help the open source community by helping to improve the firmware for other flight controllers and not just ours.
IMU-F is our motion-coprocessor.
It interacts with the gyro on board and processes all of the filtering using a very special filtering algorithm we developed based on the work of Rudolph Kalman.
This allows us to operate filtering outside of the flight-controller loop and maximize efficiency why also reducing latency. It may sound counter-intuitive, but while we did add about 6us of latency to the actual connections, our filters execute 2x faster than Betaflight/Butterflight’s filters. This allows us to output clean quaternions at 32khz.
The code in Butterflight has been modified in our target to remove all of the filtering code and operate on the data given to Butterflight directly. This also enables a 32khz pid loop. Running a 32khz pid loop widens the acceptable PID range to make tuning easier and in most cases, almost unnecessary. You can also run at 16khz which has a similar effect (though not as drastic) and enable a ton of other features without taxing the CPU. Now you don’t have to choose between smooth performance and better features!