Why no physically separate multicopter controllers and autopilots yet?

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.

Views: 4941

Reply to This

Replies to This Discussion

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.

Why ?

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.

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.

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!

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

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.

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.

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.

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

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service