Arducopter porting

Whether to port bits of Arducopter to Marcy 2 or port bits of Marcy 2 to Arducopter has been the mane question. Arducopter is a very large & growing nest of features, with a lot of hype around a few features that might be useful. Porting bits of Arducopter to Marcy 2 has been the only thing that fits into the 2-4 weeks between all up demos.

The additions or at least the hype is getting more frequent, as 3D Robotics has more money to invest in features, but the hardware has remaned the same. Recently, the big ones have been autotune, hybrid mode, inertial navigation, & Kalman filtering.

As with everything nowadays, the marketing for every new feature is in your face & viral, while reality sometimes differs. Actually having a stock arducopter to test with optimal parts is financially prohibitive. $800 + stock RC system + crash repairs is quite a lot by Chinese standards.

The inertial navigation still seems a bit like smoke & mirrors. There hasn't been a side by side test of inertial navigation vs. GPS only. The question is how much new information they can actually get from the same old garbage input.

The autotune feature is potentially useful, conceptually simple, but very time consuming to perfect. It's in 1 small file called auto_tune.pde. It commands a bunch of rolls & pitches to optimize an existing set of tuned attitude hold gains. It doesn't touch heading or position.

Once again, there's no obvious improvement that jumps out. Autotune will be expanded to heading & position. Then, there might be a lot more justification in porting it.

Sadly, porting the DCM to Marcy 2 did not offer any improvement. Straight integration of the roll & pitch rates was imperceptibly less effective. There was some improvement from adding weight to the IMU, but not from the DCM.

There was enough information in the original Rotomotion source code to come up with the idea of using a DCM in 2007, but the connection wasn't made & my formal education had only covered quaternions. Quaternions & the DCM probably give equivalent results, but the DCM has been standardized by Arducopter.

That leaves trying different amounts of ballast & different foam to reduce vibration without unbalancing it. Having the battery attached to the IMU did not reduce vibration as hoped.

There was an idea to add an outboard set of high quality gyros, but there aren't enough I/O pins to get the data in without building a completely new electronics package from scratch. Initial tests with some rough outboard gyros showed no improvement.

It's not like this is an original problem. The Turnigy microquad is a popular aircraft that everyone has to tune out, but Marcy 2 probably has less mass than the boards everyone else uses.





After decades of shunning floating point on microcontrollers, Marcy 2 was finally converted from fixed point to floating point in 1 huge rewrite.

Floating point still means investing a lot of time in the build system, linking obscure libraries only the author of the compiler knows about, obscure compiler flags, obscure versions of the compiler, obscure coding conventions, obscure initialization sequences.

Arduino was a rare case of floating point being automatically available. STM32 had a lot more pitfalls after the https://www.rcgroups.com/forums/show....php?t=2031526 discovery. Manely, several registers had to be set before running the program that included the math library. 1 register could only be accessed in assembly language.