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
this just popped up on ars technica... takes your idea a bit further
http://arstechnica.com/information-technology/2015/03/for-a-brighte...
Good article. The use of Cloud tech has been explored heavily by the US Military. Another product that will go from tactical to practical.
Modluar designs have been around for some time, just not within the price range of the average mortal. The Military has been using modular designs for quite some time. Some upscale UAV companies have been using these products, but again, the average mortal does not have $50K for a UAV and its equipment. Eventually some of this stuff trickles down in to the consumer market. I guess the best thing to say is be patient.
41 years ago when I built my first R/C airplane it was balsa wood and paper. No one could afford plastic molded part planes. There were a few on the market, but for the most part every one built out of balsa wood and paper.
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! ;)
Dual redundancy can work, if each is limited to 50% authority. With two independent controls the output will be the average of the two. The 50% level is defined as that which results in neutral control conditions, i.e. a position hold in a multicopter. Dual redundancy can be achieved with, for example, a co-axial quad with each controller driving four motors. and each thrust limited so one controller-motor set can only maintain altitude at full power.
Triple Redundancy would result in a better outcome if one control channel is lost or goes to max, as the other two can easily overcome it, in this scenario each channel is limited two 33% authority. By limiting authority no voting is necessary between controllers and outputs are averaged only. In the case of multicopters, averaged thrust per motor set is the vote.
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 ?
It is nothing new. Mikrokopter was one of the first FC having some navigation. Navigation code is run on ARM while basic flight contronl is running on AVR. They comunicate via bus, so navigational board uses sensors from basic FC. It has it's own GPS and compass. Duplicating gyro and acc is nonsense.
In their case the duplication of gyro+acc is nonsense because they probably (from a commercial point of view) don't intend their autopilot to be interoperable with any other brand basic flight controller, or use the bus to also communicate extra non-critical info back to the autopilot for logging purposes or whatever.
But in any case, that is evidence that the concept exists and works, which is nice to know.
I dont see any problem with redundant acc and gyro.
duplication of gyro+acc is more common than you think, even the cheapest gybalslike this one have a duplicate gyro and acc, as well as a their own processor.
Drones are just platforms for lifting stuff. Drones are in charge of flight and stability and use whatever sensors they are equipped with. The stuff they are lifting must be able to command the drone using whatever sensors it is fitted with.
Currently, this is mostly done with human operator involvement (e.g. the gimbal assists the onboard camera to give stable images back to the pilot, who then moves the drone to frame the photograph correctly).
Companies that are purely focussed on building drones will eventually end up in a price war: basically dollars spent per lifting capability. Similar to the war Dell and HP won over the PC market, and iPhone and Samsung are currently fighting over the mobile market.
Its the companies that provide the stuff that goes on the drones that will provide the innovation and growth.
-
1
-
2
-
3
-
4
-
5
of 8 Next