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
'm no hardware or software architect, but the original ardupilot(328 based) kinda was like what turdsurfer wants. It could connect to an IMU through serial to get the attitude and position and then the ardupilot did the navigating and control of the servos. The Ardupilot needed the IMU to send in DIYd binary. I experimented with various ways to calculate the attitude before it was sent over serial. I tried quaternions, DCM, complimentary filter, DMP, and of course the stock IMU program. The smoothest and seemingly most efficient used the FreeIMU libraries to start with quaternions and then convert to euler.
The point is the little Ardupilot didn't care how the attitude was measured as long as it came through in the right format and speed. It worked and the simplicity and modularity still appeals to me. With the APM, you don't seem to have much modularity, but the sea of wires and potential bad connections is less.
Oh well, I guess there's always tradeoffs.
It was mentioned earlier that there is development risk. I've experienced that with the Ardupilot example I gave. I have a working board, but the manual was moved somewhere invisible. I considered taking it out again now that the weather is improving and I noticed that one of the jumper wires came unsoldered. I wanted to consult the online manual to see exactly where I need that jumper. It's gone. I still have the code, but all the little tweaks and fixes that the manual spells out are vaporized. My work on the IMU is meaningless if it can't connect to that old Ardupilot.
I can see that happening again and on a bigger scale for someone working on APM when it gets dumped completely to chase PrixHawk or some other monster.
Harry, the multiwii FCU followed a similar path, this board has been around for 3 years and it took a bit of the GPS processing off the hands of the FCU, at the same time converting the serial GPS connector into and i2c device. http://www.rctimer.com/product-762.html
This code is now integrated into the FCU.
I guess we need a standard interface between all the hardware on a drone, then its only 4 wires (power, ground and 2 signal wires) to each device/sensor.
Drones seem to prefer i2c and auto-mobiles prefer the CAN bus.
> 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.
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.
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.
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.
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.
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.
Hello Ben, yes, thats exactly what happens, one board (the FCU) permanently stabilises the drone, thats all it does - try and keep it level and straight and at the same height using its accel , gyros and baro. this is a standard FCU. A multirotor does this automatically as soon as you arm it.
The other board permanently measures where it is in space, how far away it is from obstacles and the ground and tells the FCU to go up down or left or right. It measures where it is and gives the drone instructions, it doesnt care if it is in an unstable or stable state. the more "stable " the FCU is the slower the whole thing responds.
So why not have a procesor for each one of the directions ?
Why not have a processor that decides to go up, and another to go down, one for forward, backwards, etc.
-
2
-
3
-
4
-
5
-
6
of 8 Next