Why no physically separate multicopter controllers and autopilots yet?

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.

Views: 4947

Reply to This

Replies to This Discussion

His understanding is completely fundamentally wrong.  An autopilot does not emulate a real pilot's inputs, it is completely integrated and not a seperate function to any type of stabalisation.

If they were seperable (which they are not) sensors like gps, barometer, compass, gyro and accelerometers would all need to be duplicated which does not give you redundancy but multiplies the chance of failure with the added complication of deciding which conflicting input to believe. In a weight sensitive application like there is no such thing as an insignificant weight addition.

So in summary: It's not readily possible, it has no proposed benefit and would add unnecessary weight and cost while descreasing reliability!

While you're describing what autopilots are now, that isn't necessarily the same thing as what they should or could be. This is technology that should be open to questioning and change, and not a new religion that is defined once, immutable, and defended by dogma.
But thanks anyway for your facts or opinions (whichever best describes them).

Your most basic multirotor is a distributed processor system with wires going every where. Each esc has a processor with firmware and 6 wires, the GPS has a processor with firmware the rc receiver and Tx have a processor each, laser rangefinders and ultrasonics have processors, even smart batteries are coming out with their own processor and firmware. All we did was add one more processor and firmware.

It has nothing to do with dogma or preconceptions, it has to do with your idea having no basis in reality.  You may as well be suggesting that a magic potato controls our drones.

You seem to think that you can just be permanantly stablising on one board and moving around with the other board.  The point is, movement requires the drone to be in an unstable state!  These are *not* independent functions.

By that reasoning, an RC pilot won't be able to fly a multicopter in manual (or stabilize mode) because what a separate autopilot will be doing, is emulating the RC pilot. Instead of visually assessing the aircraft's position and orientation, it measures it. Instead of moving physical sticks and switches, it sends PPM channel values.

Added to that, Jasper Pons seems to have successfully put this concept into practice.

I still disagree, even though you may be throwing pontifications quicker than Chuck throws roundhouse kicks.

I also agree that this is the future. Control on an MCU board with autopilot navigation and additional processing on a separate more powerful system running a full OS.  

Think micro-controller based control board handling stabilization and other low level control + Intel NUC running the autopilot navigation, localization, path planning and sensor processing

You get the reliability of embedded hardware plus the computational ability, expandability and sensor compatibility of a full X86 / computer system. Even Raspberry Pi would be a good start. I also think this will come very soon.

This is obviously overkill for hobby world at the moment. It doesn't take much power to carry out low level control and navigate towards GPS waypoints but wait until laser scanners and vision processing get involved in industry and begin to trickle down into high end hobby applications such as 'professional' drone aerial photography. Look at what Perceptive Labs is doing with using image processing to track targets with a gimbal for aerial photography. I believe I've seen an image of their system which uses additional computing hardware strapped on top of a 3DR system to have the gimbal visually lock on to targets selected by the user'

Want to use another camera system? Buy a new USB camera and plug it in and get the deb package for its drivers / interface. Don't worry about specific wiring and flashing the MCU again. 

For smaller hobby aerial systems, it may be a stretch to power and fly even an RPi in something like a Bixler. Some of the processing intensive work may be able to get pushed to the ground station. 

Micro-controller + computer with OS seems to be the way things are heading in ground robotics with ROS (Robot Operating System is a meta-operating system for linux). This architecture and ROS may yet push their way onto aerial systems (see Ascending Technologies flying Intel I7s with Linux / ROS on Pelican quadrotors) as sensing and computational requirements escalate.

Disclaimer: I work at the first church of ROS. 

  Dan Neault has already done exactly what Robbie describes, although I'm not sure if he used ROS.


Scroll down a bit there's even a photo. He's upgraded since that photo to a full windows board and lidar instead of ultrasound.

Robbie, I think our  DroneScan project could do with  ROS, we have come to the limits of what embedded can do with our skills.  Do you do consulting? We cant manage another steep learning curve, would prefer to hook up with someone with those skills. P.M. if interested.

A manual pilot doesn't just blindly give input, they see what the drone is doing using external sensors (their eyes) and creates their own feedback loop. You don't have that.

disagreeing with the facts does not change them.

Just call the thing a sensor hub then.  At least then it will sound useful to people.

Right now it just sounds like a poorly thought out middle man that does nothing but add cost and create more points of failure.

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service