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.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

        • 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.

        •  Sorry for jumping in your technical discussion, I'm a former airline pilot, now as a photographer I'm researching before buying my first drone.

          I think there is a lot to be made on the user interface side yet.

          Probably the most popular use for consumer grade drones now is photo/videography, and the average photographer like me is not so much interested in the aircraft itself as most r/c hobbyists.

          On the typical remote controller (3DR Iris, X8, DJI Phantom, Inspire) I miss some basic autopilot functions, like 'Altitude Hold', Heading Hold, Turn Rate Hold, Vertical Speed Hold, Horizontal Speed Hold. Those are probably the most used on a real plane, when one wants to fly it on a stable way (a mix of manual + auto piloting).

          Besides the little sticks on the controller, we should also have dials to adjust those parameters. Cinematography for example usually requires very smooth and stable movements.

          Also, there seems to be so much dependency on GPS.. years ago jets would cross oceans only on gyro / acc. It seems gimbals use very precise inertial units, would it be possible to use those units to navigate from starting point? Something like DJI Course Lock without the need for GPS.

          And more specific on your current discussion, I can say airplanes have lot's of redundancy, but can surely understand the limitations of the small drones.

          But if one day we will have tons of drones flying everywhere, over people and valuable goods, we will surely need more hardware redundancy / security (one item fails but doesn't affect another vital function).

          • I don't really understand your point.  You already have Altitude Hold, Vertical Speed Hold and Turn Rate Hold.  It's just that they are controlled with sticks, rather than knobs.  You could certainly slave these functions to knobs though, if you really wanted.

            It seems gimbals use very precise inertial units, would it be possible to use those units to navigate from starting point?

            Actually, gimbal IMU's underperform ours quite badly.  This is precisely because of the fact they don't employ GPS data fusion.  This is the cause of "horizon drift" that plagues virtually all of them.

            • Regarding my comment on dials to adjust speeds (V & H), altitude hold, etc, it comes from my experience as an aircraft pilot, it is completely different to fly holding the control yoke or using the autopilot dials. Using the autopilot the plane is much more stable, as direction and speed changes are somewhat limited.

              And regarding the inertial units, we used to fly planes just on the inertial system, there was no GPS at the time. Depending on the plane model there was crosscheck with ground radio stations, but many times those were out of range (sure not the same cheap inertial units, just explaining my prior comment).

              • How much did those gyro systems in the airliners weigh, and what did they cost?

                • For sure not suitable for a small drone, but since 50 years have passed from that model and now we have such small and cheap units (which I find incredible) I just asked if they would be capable of doing dead reckoning (500m long flights).

                  It would't surprise me if they could, as their very existence and price is fantastic.

                  • 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.

                  • Thank you for your answers, very clarifying.

                    And what about Doppler navigation, would it be possible on small drones? I have these questions about dead reckoning because it is not always that I can count on good GPS signal.

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

                    • Flight controller computations must be done with 64bits numbers to minimize "rounding" errors.
                    • Flight controllers must have a very precise high speed clock.

                    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.

This reply was deleted.

Activity