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.
Replies
good idea, we have done this and have been working on it for a few years. it uses its own laser, IR, and ultrasonic sensors and controls the FCU over a SumPPM or PWM connection, it uses the FCU's own baro /alt hold to assist. Tested on Naze 32, multiwii and APM.
It is controlled by a 3 position switch on your transmitter: manual mode, semi-automatic and automatic mode. It is designed for indoor use , specifically for www.dronescan.co
We have own own on-board board running our software, with telemetry back to our own ground station controller for processing the data collected.
We intend rolling out mavlink capbilities as well this will save on the SumPPM connection, mavlink has emerged as a clear standard in drone communications.
Eventually our autopilot will be fully automatic and not require the operator input and radio receiver at all.
Nice, although ideally, I think the baro sensor (and alt-hold functionality) belongs on the autopilot board.
Why ?
I have not tried it myself but if you are keen on hardware flexibility shouldn't be checking out paparazzi?
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.
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.
Interesting. There's still very little info to be found on Skyspecs, so we'll have to wait and see how that develops.
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 guess the entire system on a chip idea was stupid. Why put all the chips on one board when you can separate everything into dozens of boards and have wires going everywhere. Not only do they take up more space but they are "safer" and "give more options" just because i say so. Lets ignore the fact we cant actually give a real world example of how this would work.
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.
-
4
-
5
-
6
-
7
-
8
of 8 Next