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
Canberra UAV implemented dead reckoning in 2012 in the Ardupilot code, on GPS loss. I have not used it personally, ie switched off GPS, but it is in the code we used for the OBC.
In the OBC it was required to circle for 30 seconds and then fly some 8km to home for a manual landing. The alternative was flight termination on GPS loss.
I have tried implementing dead reckoning. The micro sensors used in today's drones are roughly 1000x too noisy and imprecise for significant dead reckoning use. The accumulation of error due to the double integration of the accelerometer data happens very quickly even under ideal circumstances.
An accelerometer designed for dead reckoning would also need to output 24 or 32bit numbers (currently 16bit) and have a sample rate of ~10kHz or greater. These are huge changes from today's sensors.
Beyond the sensors improvements, the following are also required:
These last two items are no real problem today, but many flight controllers do not currently support them.
It's not possible at this time. Even if the chips were accurate enough, these quadcopters vibrate way too much. The signal-to-noise-ratio is very low.
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!
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.
'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.
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.
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.
Nice, although ideally, I think the baro sensor (and alt-hold functionality) belongs on the autopilot board.
I have not tried it myself but if you are keen on hardware flexibility shouldn't be checking out paparazzi?
-
1
-
2
-
3
-
4
of 4 Next