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

Reply to This

Replies to This Discussion

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.

This is a pointless idea.  It would just duplicate hardware and create uncountable problems.

Either make the autopilot suitable to your stabilization requirements, or add autopilot functions to a stabilizer like the naze32.  Either way would work just fine and save you countless hours of dev. time.

Nice, although ideally, I think the baro sensor (and alt-hold functionality) belongs on the autopilot board.

It hasnt duplicated hardware, it has created a redundant system with a safety factor. If our board locks up due to a faulty sensor , the drone can still fly.

most FCU code is bloated and difficult to integrate to, it usually conforms to its own coding standards,  does not make use of object orientated programming , it spends a lot of effort in supporting legacy hardware, and, because it is open source it can change randomly at any time, this is a threat to us, a feature that we built our business model on could not be supported in future versions. In addition if we had to have spent 2 years writing custom code to integrate to APM and  now suddenly it is discontinued and PixHawk is the new FCU, all of that time would be lost.  it is safer to do what we do best on our own hardware and software and leave the drone controlling to the FCU's.They have VERY good altitude hold functions, very complex processing and sensor fusion, no need to duplicate this on our board. 

Soon the FCU's will support sense and avoid and then we will just connect those sensors to the FCU's and comment out those portions in our code, we already have compiler directives in our code in expectation of that day.

You will see more and more BYOD developments like ours - instead of developing a monolithic system, just develop the attachements and anyone can Bring your own drone and plug it on.

There's nothing redundant about it.  Now there are 2 sensors and the drone will crash if either fails!

Good point Ben, we could have a watchdog timer which would pass the RC signals through to the FCU in case our board blacks-out, In early versions we  probably needed this but lately our system is more reliable. If our board totally fails, it will send "0" to the FCU on all RC channels in which case the FCU failsafe kicks in and it lands slowly.

its rarely a black-and-white situation of complete failure or lock-up. 

Its more about computational power and "multi-threading". The FCU's alt hold functions need a lot of computational power and no interruptions, our sensors work on a slower cycle but are quite intense when data is received, this suits us but would reduce the performance of the FCU. 

Pixhawk  have tried to get around this by throwing hardware at the problem but this has come at the cost of a huge software burden , over 700 000 lines of code.

You didnt actually give any tangible benefits. If i smash my f/c with a hammer, i know have another choice that doesnt mean it actually improves the flight experience.

Just stating someone is wrong doesnt really make them wrong. It would be better if you actually shared some info and gave an example of why it is better.

The real problem with bad sensors is not that they die but that they give incorrect values. When there are just two sensors giving the same value how does your f/c know which is correct ?

The answer is it doesnt, its just impossible to know from just 2, that means your idea has just added complexity and solved absolutely nothing. THis complexity has just made things worse.

What a wonderfully illogical assumption.

Because you say so ?

This is a fantastic idea for a number of reasons, especially as vtol systems become more popular.

THis doesnt back your assumption in anyway, anyone can write a few interesting unrelated facts, that doesnt make their POV correct.

One master autopilot with two simple stabilize controller slaves simplifies that immensely.

Actually this is completely wrong, it makes things many times worse. WIth 2 separate sensors returning the same values (eg 2 barometers measuring height), how does your F/c know which to trust ?

If you wear 2 watches with different times, which is correct ? In reality its made the problem worse and just added complexity.

It also creates a ton of expandability and support for unconventional frame types.

How ? If anything this combo actually supports less, because you have more boards and wires which means one needs more space which might not be possible on a small multi like a 250.

Does it make sense in all situations? No not really, especially for simple multirotors. But for vtol applications and unconventional frame types it makes a ton of sense.

You havent actually given a true benefit, your just arguing that because its your opinion it must be right.

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.

I see you're referring to multiple (baro) sensors that a F/C has to decide between, but that is not the case in this idea. There is no duplication of sensors, except for at very most an acc+gyro, and that won't be shared by the same board and processor anyway.

The future will reveal if modularisation turns out to be a good or bad idea in this situation, and how prescient your facts/opinions really are. I believe Jasper Pons is on the right track though.

For those who hate the notion of an extra PPM-sum (or other data link) cable and/or stackable boards, perhaps monolithic design proves to be more popular (but I really hope not), with everything including receiver and brushless gimbal controller integrated into 1 board and all processing done on 1 chip to make the loop time as long and as varying as possible, with firmware releases dependent on changes in even more code, and end users having less choice, but hey, they save a cable or 2.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service