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

                • Great idea!  Processors are cheap, so why not have one for every single function you could possibly imagine?

                  The best setup would be: sensor -> uC -> multiple Pons uCs -> combo uC -> FC uC.

                  Since STM32's cost only about $1-2 each, the whole system could be done for cheap!

                  • Of course!  That's given.

                    You may be underestimating the power of this tech. though...  One uC for each led just doesn't maximize the system.

                    You really need 1 uC for the LED, another uC to check if the led is on using it's sensors, which each of course have their own uC.

                    If the LED is not actually on, or if the LED-check uC decides it should be when it's not then it can communicate back to the "Pons uC" to tell the LED-switch uC to turn the LED on.

                    If they can't agree on the proper LED state then another "arbiter-uC" will interrogate each of them in turn and make a decision.

                  • You forgot to also add there should be one uC for each rx output and lets throw in a few uC for other functions like one for each led you might want to stick around your copter.

                • Good idea maybe I'll try it. For now a single processor can easily keep up with basic calculations, most distance sensors only update approx every 50ms anyway, so half the time the processor is idling waiting for a sensor to give a new reading. There's no point re calculating if no sensor has given fresh data. Unlike an Fcu which continually reads 6 gyro and accelerometers at a much higher rate and does double integration and kalman filters which requires a bit more grunt.
            • 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.

              • A manual pilot doesn't just blindly give input, they see what the drone is doing using external sensors (their eyes) and creates their own feedback loop. You don't have that.

          • Your most basic multirotor is a distributed processor system with wires going every where. Each esc has a processor with firmware and 6 wires, the GPS has a processor with firmware the rc receiver and Tx have a processor each, laser rangefinders and ultrasonics have processors, even smart batteries are coming out with their own processor and firmware. All we did was add one more processor and firmware.
      • 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.

          • Just call the thing a sensor hub then.  At least then it will sound useful to people.

            Right now it just sounds like a poorly thought out middle man that does nothing but add cost and create more points of failure.

This reply was deleted.

Activity

DIY Robocars via Twitter
How to use the new @donkey_car graphical UI to edit driving data for better training https://www.youtube.com/watch?v=J5-zHNeNebQ
5 hours ago
DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
Saturday
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
Thursday
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Wednesday
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord: https://discord.gg/EPsZHkg9Nx) https://t.co/PNDewvJdrb
Wednesday
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
Wednesday
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar https://www.youtube.com/watch?v=9yy7ASttw04
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge https://t.co/nZQTff5…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉 https://t.co/NtKnO…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch http://indyautonomouschallenge.com/stream
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: Another incident: https://t.co/G1pTxQug6B
Oct 23
More…