There are already many good basic multicopter controller boards on the market. Think of Naze32, KK2, etc. Then there's also great firmware, some of which that support multiple boards and PID controllers (e.g. Cleanflight). Most of these boards and firmware fly great, but lack or have poor navigation support (alt/GPS hold, RTH, etc).
On the other hand we have Arducopter which is a multicopter controller that also has very feature rich and stable autopilot capabilities.
Wouldn't it be great if users could pick the basic flight controller of their choice and combine it with the autopilot of their choice? I'd like to do that, and I'm convinced that once these modular designs start appearing, that it'll boost both the development of both basic controllers and as well as autopilots.
What I'm thinking of is an autopilot board that acts as a PPM-sum filter between the RC receiver and the basic flight controller (e.g. barebones Naze32 or KK2), and has it's own gyro+accelerometer and I/O connectors for PPM-in, PPM-out, GPS+nav, and that's it. The autopilot need not even know how many motors the flight controller controls. It only has to be told via some configuration tool, what the functions of the various channels are and have configurable navigation PIDs.
If the autopilot/navigation board is designed small enough, then it can be simply stacked above the flight controller board and added at a later stage after the frame has been tuned.
Sounds like extra parts, extra wires, extra complexity, extra points of failure, and extra cost, and limited compatibility. With absolutely zero benefit.
I think the Arducopter developers would rather spend their time making the Arducopter Acro mode better, rather than working towards handing that control over to these other boards.
It's not necessarily about handing over anything. It would be perfectly fine to continue Arducopter based development on both an autopilot as well as a lean & mean controller board at the same time.
Yes there are extra parts and complexity in the form of 1 PPM-sum cable, 1 board and it's associated firmware and configuration tool, and 4 nylon standoffs and nuts. If thought out well, a party that develops both types of boards and firmware (the ardu* project), can design the boards so that they can also be permanently mated (similar to PX4) if end users so choose.
The added benefit IMHO for end users is more choice about which components to use in the mix, and the possibility of buying+adding an autopilot at a later stage, or experimenting with various combinations.
Anyway, I'm just throwing the idea out there. If there's no interest, then so be it.
For general users and sport flier, I doubt this has value.
For people that want to develop advance capabilities (computer vision, artificial intelligence, advanced sensors, etc..), being able to use a stand-alone flight controller tied to their preferred development computer of choice seems like a good idea. With a simple communication interface (to get flight information and send navigation commands) it should be easy for anyone who want to use a BBB, RPi2, Odroid, GumStix or x86 to provide advanced functionality. This allows the flight controller to hand items that require hard real-time attention, while freeing the companion computer to do whatever is needed without the developer needing to deal with unrelated items.
I'm not sure if we're describing the same thing here as the basic flight controller (or whatever I should call it) has nothing to share with the autopilot. You could think of sharing the gyro and acc info over a serial connection but since these chips are dirt cheap and tiny, they may has well be duplicated. Other than that, there is nothing else that needs to be shared. The autopilot is effectively a just filter in the PPM-sum stream that emulates a real pilot in what it 'sees' and by virtually piloting using PPM channels.
But I agree, that this will simplify and stimulate development of more autopilots (not necessarily just advanced, but also the most simple that beginning developers can pick up). At the same time it'll allow the minimal flight controller to be lean and mean and just do what it does best and nothing else: accurately translating stick inputs into attitudes and maintaining them.
B.t.w., I say PPM-sum, but it could just as well be SBUS.
Ah I think the problem here is that there is a major discrepancy between what you seem to think an autopilot does and what one actually does. These functions are not so neatly seperated.
So far you have not actually articulated WHY anyone would ever want to do this. Why a developer would ever want to do this? Why a user would ever want to do this? You keep saying it is for flexibility and choice. You're creating a solution for a problem that doesn't exist. When was the last time you heard someone say "gosh I wish I could have a cheap Hobby King flight controller, then attach a fancy Ardupilot autopilot to it??"
These are completely pointless layers of complexity and detached automation.
I think that the collision avoidance system Skyspecs was showing off worked like this. Essentially, their controller on top of any other flight controller or autopilot to allow you to use any of the common hobby grade systems.
I understand they want to make their system work on any existing platform, but it seemed like over complexity and potentially 2 redundant control loops.
I have not tried it myself but if you are keen on hardware flexibility shouldn't be checking out paparazzi?
Interesting. There's still very little info to be found on Skyspecs, so we'll have to wait and see how that develops.
Thanks. I'll check it out, but from the little I've read about it so far, I don't think Paparazzi is the same sort of layered system as Jonathan and I described.