I would be interested in learning more about that FC. Pixhawk and PX4 are great but as you mentioned so broad in scope they make the programming process more difficult than it needs to be. Vector is much simpler but also more limited.
Hi Pat, my work with this system began before DIY drones and the APM1 going back to the mid-2000's. I've been at this a long time so I could pile on information and thoughts and motivations and stories for hours. That's hard to do well in a forum, so I'll say a few things and feel free to ask more specific questions.
I've always liked linux because of it's capabilities and tools and fairly low level connection to the system resources. Raspberry pi and beaglebones run linux. Way back when I started we were working with early gumstix boards which also ran linux.
I like simplicity. I think it is analogous to weight when designing an airplane. You can't always make things as light as you wish, but it's a battle that needs to be fought every day and any gains are immediately felt in increased performance or capabilities. I don't think it's too much different when coding.
I like python. When I port my C++ code to python, I get the same result at often 1/3rd the lines of code. Fewer lines of code is usually directly proportional to simplicity (assuming no one is going out of their way to write obfuscated code.)
I like figuring things out for myself. The reality is that the system is going to go fly a grid pattern or a circle for an hour+. If I slap someone else's controller and code in an off the shelf airplane, it's boring. The excitement comes from watching your own code do all the magic just the way you intended it. It doesn't always work out as intended and that makes the successes even more satisfying.
I like robustness. I have run my flight controller for more than 9 days straight flying a realistic flight simulation producing realistic sensor data (flightgear). I watch things like my flight controller memory footprint to make sure it never changes during this time. I make sure there aren't any glitches or bombs. If something does bomb or hang, it really stresses me out until I get to the bottom of it.
I like simplicity of design. I'll talk your ear off for another hour about threaded vs. not-threaded architectures. For a flight controller there is a clear information flow: read sensors, compute attitude estimation (ekf) and other sensor processing, compute navigation and control, send out actuator commands. I don't want these things happening out of order or on some non-deterministic time schedule. I've thought a lot about timing and end-to-end throughput. PX4 has a very elegant threading and messaging system (uORB) which is very beatiful from a computer science stand point. But from an engineering standpoint of producing time deterministic operations, it falls pretty short. I've heard they've made a lot of improvements here, so I'm not trying to be negative on them at all, just pointing out my own observations from a year or two ago when we dug deep into the PX4 architecture.
We use a big processor/little processor design. We have a little processor (teensy-3.6) that does all the sensor I/O and servo PWM generation. But this pretty much all it does. The big processor runs linux and our flight control app is a hybrid of C++ and python. The big processor does all the heavy lifting work ... computing the EKF, doing WGS-84 great circle navigation, mission, logging, communication, guidance, control. The result is two simpler systems working together (versus something like PX4 which is a big complex monolithic app.) Our little processor which handles sensor I/O also takes care of all our hard real time work. The big processor waits for sensor data from the little processor, crunches through the main loop, and sends servo commands back to the little processor.
We aren't trying to rule the world with this system; we simply have been developing it to support our various projects over the years. I have a lot of time and thought personally invested in it, so I am completely biased. Our lab also runs a few things with pixhawk and for student projects, pixhawk has worked pretty well. It's relatively easy to get something installed and flying and there is a lot of documentation. However, we are primarily a research lab, so having an in-house developed system that we understand from top to bottom and can modify for our needs ... that has really proved beneficial. PX4 is open-source, but the sheer complexity is a steep hill to overcome. We also have an extremely complex project with 12 independent flight control surfaces, 2 EDF motors, and retractable landing gear. In addition we have several IMU's and analog sensors spread across a 14' wing span. This just ends up being beyond the capability of a standard pixhawk. Our system is expandable so we actually have 3 additional teensy processor boards that run in lockstep with our little processor. The little processor aggregates all the sensor information and hands it to the big processor all at once. This is way more complex than our typical projects, but we had to design something ourselves to support the large number of sensors and servos and simultaneously meet strict deterministic timing requirements.
All that said, in it's typically configuration our flight controller is a beaglebone black with a simple cape that has a teensy3.6 onboard. The cape mostly just routes connections between everything ... it's not a complex board. One of our guys spun off a company to do flight controller hardware (and other stuff.) All our code and research is licensed with the MIT open-source license, but hardware is hard ... and it just costs money for someone to source the parts and build them up. You can google bolderflight to see what the hardware looks like.
One of the students in our lab integrated our flight controller into an x-uav talon for an entomology (insects) project and made a little video. If you have a couple minutes, it is a good little overview of the sorts of things we have been doing. (apologies if I've shared the link here before ... I'm getting old and starting to repeat my stories.)
That's probably way too big of an information dump for a forum post, but there is a lot of details and aspects and thought and experiences that have gone into all of our work. It's hard to know what specific questions people have or what angle they might be interested in. Everyone is interested in slightly different use cases, so I think it would be really empowering to have a community somewhere that is capable of building up flight controller hardware and software from scratch. DIY drones used to be the goto community for this, but now ...??? If I haven't just completely scared everyone off, please feel free to ask more specific questions. I don't know all the answers, but happy to share what [I think] I know.