I'm considering paparazzi for control, although it wouldn't be the most natural choice when it comes to how easy it is to flash, calibrate and getting it ready for flight. Those are issues we attempt to address during this project. I did consider APM, but one of the factors is that we want to design, with a partner, our own boards and hardware, which is how we intend to make this commercially feasible.
My doubts about the use of paparazzi are the following:
- The calibration settings aren't saved on the boards, they are specified as #defines in the airframe. Has anyone ever started work on storing settings in flash? Are there considerations why you wouldn't want to do this? ( I know overrides are available from the GCS, but I also want this board to be usable by people without having to build/use the GCS ).
- We're also thinking about simple acrobatics for multirotors like flips and rolls. The openpilot project implements some of that in attitude and "rattitude" mode and it would be interesting to see if those concepts can be taken across and implemented on the paparazzi. Is there a reference code in the repo that demonstrates how people approach the issue of acrobatics, considering the architecture of paparazzi? ( I remember some example of an airplane that was perching).
- The navigation on paparazzi is very statically implemented. The flight plan is compiled inside the control code. We intend to loosen this up by defining some standard navigation blocks (elements, whatever you call them) and then switch between these elements through 3rd party instructions. probably a 3rd party board with lots more headroom and capabilities to dynamically elaborate a flight plan.
Looking forward to your replies, especially issue #1.
Rgds,
Gerard