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: 4937

Reply to This

Replies to This Discussion

Of course!  That's given.

You may be underestimating the power of this tech. though...  One uC for each led just doesn't maximize the system.

You really need 1 uC for the LED, another uC to check if the led is on using it's sensors, which each of course have their own uC.

If the LED is not actually on, or if the LED-check uC decides it should be when it's not then it can communicate back to the "Pons uC" to tell the LED-switch uC to turn the LED on.

If they can't agree on the proper LED state then another "arbiter-uC" will interrogate each of them in turn and make a decision.

HI Eduardo, great perspective you are bringing here as a former airline pilot. Agree with you on some basic autopilot functions missing, like  horizontal speed hold and turn rate hold.

They are actually available on auto missions, you can set them prior to a mission, but it's true you can't  all adjust them in flight. I think the main difficulty is the number of channels and knobs available,  you'd need many more on  a typical controller. (As an example, I am already maxed out at  16 channels and use all the knobs on my radio for things like adjustable yaw rate, pitch and roll expo/rates, gimbal pitch rate, etc ...).

But there is certainly no theoretical limitation if a tablet or computer interface is used, with unlimited knobs, and given many controls could be multiplexed on a single channel.

With respect to GPS dependency, I think the problem is technological. The  mems gyros used  drift considerably, so dead reckoning is not an option. That's the difference between mems gyros on a small drone  and heavy mechanical gyros in the $100,000's on airline jets.The complementary filter in DCM    fuses accelerometer data with gyors and helps adjust for their drift some, (and the newer EKF does this too) but still  in a very short time a GPS update is needed to "reset" them. Short of a breakthrough in mems gyros or alternatives to GPS like optical flow, I don't know how this problem can be overcome ...

lot's of redundancy is easier said than done, it is not just a case of adding extra components. The devil is in the detail.

Imagine having 2 cars in case of breakdown.  If you had a narrow drive and the car in front won't start, you couldn't get the back one out.  If you break down on a long journey, the fully working car at home is no use to you at all. On a cold damp day, the battery might have gone on both cars at the same time.

So with sensors you must be able to recognise when one has a fault and if so which one is faulty.  Also most faults have a cause, they don't just spontaniously occur, you need to be sure that the same fault be triggered in both sensors. In a plane the pilot receives a lot of information to decide which of these to trust, in the autopilot this underlying data is hidden from us, so we are not empowered to make that same decision where the autopilot can't itself.

So these things are not trivial to deal with.

Hi John, thank you for your reply.

I guess the main thing I wanted to bring is this concept of flying 'manually' trough the autopilot (as I know it), which would be the guy who keeps the flight very stable.

It's a very common thing in airplanes, something between fully manual and full auto flight plan mode.

I think if one company really wants to hit mass market, that's very useful, as the lay person / photographer doesn't want to become an ace pilot, he just wants to move the camera without crashing and without shaky footage (and not having to plan missions with waypoints, etc).

I agree with you about too much dials on the remote control, that reinforces the point that there is so much to do yet on the user interface front.

Current controls are still inherited from r/c hobbyism, maybe the same sticks could behave differently if autopilot is engaged, for example.

What I would like to have is something like a Wii game controler, with a button where I could engage autopilot (or many different modes like 'Sport', 'Video', etc).

I guess user experience experts will find much better solutions in the future.

I don't trust so much on my Android phone to fly things, as it messes even with my email and many times lags with the touch on the screen (not to mention hackers / viruses). I'm probably old school and like to have a dedicated, solid control in my hands.

It's a pitty the inertial units can't deal with dead reckoning, I guess I was expecting too much from them, but some years ago I was really shocked to learn about the very existence of such small and cheap inertial units.

And what about Doppler? I think that's what DJI is using on the Inspire but only for low altitude. I can tell you that we could fly for hours on it and it was very precise, not very recomended over water.

Probably you would need more powerful sonars, not suitable for small drones..

Sure Ben, you are completely right.

Even on modern, big jets, serious issues can happen when onboard computers get conflicting data. And the conflicting data can lead even the pilots in the wrong direction.

For example, in recent years some Airbus models had similar incidents / accidents where there was conflicting airspeed data.

In my opinion (having some computer programming experience), we are facing new challenges. Engineers have decades of experience with aeronautical materials, learning from many accidents in the past.

But when it comes to an accident where some software bug played some part, that's something relatively new. It's very hard to anticipate every combination of problems and make the software to deal with it in advance.

Just in case someone is curious about how Boeing deals with redundancy:


Hi Eduardo

On the subject of horizontal speed or turn rate hold I'm not sure that they would be very useful on a RC aircraft. Unless the aircraft is doing long range FPV it's unlikely that in the short distance that one can see an RC aircraft flying at a field that those sorts of mixed mode auto/manual parameters would be used. Some aircraft I fly are "invisible" in 20 seconds across the field. In the case of UAV operations these controls mostly already exist or are of no consequence when flying full auto for still imaging.

Video for quads etc is of course different, but there I think the key to user ergonomics is to control them relevant to earth frame rather than aircraft orientation. That way the sticks always make sense...at least for me! Obviously the camera gimble would respond to orientation instead (aka heading) that way, which together with tracking should make it fairly simple for a single operator to get good footage. Most commercial operators will only ever be doing so with a dedicated pilot and camera operator however, as it's nearly impossible to be able to frame the camera footage and be situationally aware of the aircraft and position it correctly at the same time. It's a bit like texting on your mobile whilst eating a Big Mac and driving a car...not advisable at all, but some can pull it off!

We've used Android devices for competitions and flights quite often without any significant faults or failures, beyond those we programmed in ourselves....ahem. ;-) For the reliability and size of the device I'd prefer using and Andorid device over a windows PC any day. Android sandboxing is pretty stable and secure to boot against malicious attacks too. You of course need half decent hardware though, that's where Apple has the edge a bit because they're all the same...if not quite as good! 

Thank you for commenting JB,

I'm probably thinking about the autopilot 'hold' modes because to me it seems much easier to fly these things from the inside rather from outside ;-)

The hold modes would be there mostly as 'dampers' against oscilations, not necessarily because one wants to keep the heading for long periods of time, for example.

Maybe some control sensitivity change would have the same effect, but it should be able to be disengaged, reverted to normal on a click.

Regarding video/photo, I would like a drone as a giant crane or camera dolly, which can perform very smooth movements.

I agree that redundancy is not a trivial development. But I'd insist on getting at least a third independent opinion as to the state of the aircraft aka have three cars not two. The difficulty with two is that it's always a 50:50 vote which one is right so your (or code) odds of making the right decision isn't much, if at all better. A third input and by dismissing the odd one out, gives at least 66% chance of acting appropriately.

In saying that decoupling redundancies that have the same output is difficult as well. There's a point of diminishing returns by adding system complexity for redundancy, provided of course they can still provide the level of functionality required. Using a control system to overcome aerodynamic good design practice to make something that normally doesn't fly fly, like a quadcopter, obviously increases the sensitivity to external control loss. Essentially the responsibilities of attitude control are simply being progressively handed further up the control pyramid instead of being dealt with locally or even mechanically.

I think blindly separating control from autopilot isn't the way to go as it introduces more points of failure, added cost, user error and higher development overhead that stifles innovation and reliablity...especially without standards for comms etc. that also include feedback between the devices so that each component is aware of another's state.

BTW from memory the PXH has a separate onboard FMU plus redundant sensors that are all being compared to GPS data in flight via "sensor fusion" for accuracy as well. RC controls can already override the PXH autopilot so why remove the FMU from the board and add a cable and another board? If you want another controller to be in charge just plug it in to the PXH PPM input. You can then switch between the two with the RC as desired. Done! ;)

We have redundant sensors and give them a ranking over time. 3 strikes and you're out. If a sensor starts giving strange data we ignore it and use another one till it comes right. This works in our scenario which is fairly predictable. Other guys use a kalman filter.

But what happens when they diverge and start giving slightly different values, perhaps one barometer gives a reading a few lower than the other. How does one tell ?

I do not think that gimbal has redundant IMU's.  It has complementary IMU's.  One is measuring the attitude of the camera, the other is measuring the attitude of the mounting base.

This is a completely separate issue from having redundant sensors.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service