• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Flight Controller Software - what to pick/start with?

JasonK

Well-known member
#1
I have a flight controller on my way and am trying to figure out what flight controller software options there are. My ultimate goal is to use this to run my VTOL design that I am working on. I am not afraid of getting my hands dirty and working on code myself, but would love to find something that has what I need already 'built in' (expectations are low from what I have found so far. Are their any flight controller software builds that I am missing in my research, I have found the following (along with any notes I have so far):
  • Betaflight: focused on quads/multi-rotors, specifically has a warning against fixed wings not being a good idea
  • ArduPilot: focused on autonomous flight, does say something about supporting VTOLs in the plane configuration, but the example is a mixed quad/fixed wing.
  • iNavFlight: another autopilot flight controller, haven't researched this one as much
  • Cleanflight: i haven't reviewed this one yet
  • baseflight: precursor to Cleanflight, appears to be abandoned at this time. (looks like there is more 'back' I can follow, but not worth following)
I noticed that many of these have a whole mess of features more then what I am looking for (at least initially), but don't see one that already has my use case working (but I could be wrong here also, some of them do have comments about VTOL flight).

I was trying to figure out
  • if one was better then another for my use case (there seems to be some code sharing between at least some of the above)
  • if there were any options that I was missing
  • if any of the above is likely to support my use case
  • any info about the various developer communities for the above and which one(s) would be best to work with (or if 'going from scratch' is my best option)
Any thoughts/input/etc will be appreciated.
 

ElectriSean

Eternal Student
Mentor
#2
Baseflight is done. Cleanflight was based on this, which then spawned Betaflight. Years later, Cleanflight was re-based on Betaflight and pretty much abandoned. iNav is also based on Cleanflight, with much better autonomous features. Ardupilot is it's own beast, and considered the most fully featured, at the expense of user friendliness (where have you heard that before ;))

As fas as VTOL goes, there is the OpenAeroVTOL project which I believe is based on Arupilot. That would probably be the best place to start, though I'm not sure if it will run on your FC out of the gate. There are versions of Arupilot now for the Matek wing boards, so I don't imagine porting it would be terribly difficult.

Hope this helps a bit.
 
#5
@JasonK It might be best to start from scratch. I'm looking at building a system as well that uses 3 motors with 2 rotating into full forward flight. High-speed hardware is pretty easy to come by, or I was thinking maybe writing custom software for one of the existing quad FCs. Somewhere I read an article of a guy who built his own FC (provides board layout, etc.) which might be a good place to start as well. Starting with obsolete hardware or firmware designed for that old hardware might just cause more pain than it's worth... Not sure as I'm just starting on this journey.
 

JasonK

Well-known member
#7
@CrazyGuy I have done enough software development that I know that avoiding 'reinventing the wheel' is often the better choice and yes, if I have to, I can do down the road of writing my own flight controller (there is enough reference material to work from for sure), but I was wanting to avoid this if I can.
 

JasonK

Well-known member
#9
no offense was taken. It looks like youtuber used the same MCU as is on the flight controller I just purchased, so if I don't see something good to start from, I can probably look at his code also. Functionally there are a few main parts to work out: initializing the MCU, talking to the various peripherals(IE the gyro/receiver), the PID loop, and the transition logic. The big parts I wanted to avoid is the initializing the MCU and reading the gyro and receiver's data.

I am shocked that 1MB flash is insufficient for some of the flight controller softwares (I see notes in arduflight for example that some boards don't have enough flash), at least for basic flight support. I can see how doing nav, GPS, etc,etc,etc (all the bells and whisles that I am not currently looking for) maybe being an issue.
 

JasonK

Well-known member
#10
I looked at that video further, and it looks like he just build his own FC board, but was still loading up betaflight on it (at least based on the link).
 

JasonK

Well-known member
#12
yah, any 'schematic' info needs could be pulled out of the build target file from ardupilot (since it can build to it, it should have a hardware description file somewhere in the source code). So I should be fine there.
 
#13
On the topic of writing your own software, have you guys seen this?

It's a great place to start and his work is all open source. Some of his code is confusing (because we was exploiting the ports on the cheaper/slower arduinos) but you can borrow the stuff that gets you IMU data and radio communication, and then run it on a much faster board like the teensy (also nice to have a super fast board because you can hard-code faster ESC protocols like oneshot125 on any digital pins). Once you have that data, writing the flight controller is fairly trivial as long as you know what steps are required.

A simple PID controller will get you flying in less than a days work. In general, your loop should look something like:
  1. get radio data--pwm, ppm, serial, whatever
  2. get IMU data--gyro and accelerometer
  3. filter IMU data (low pass out the noise, and filter fusion [madgwick] if you want attitude controller; rate controllers only use raw gyro data so no scary math required!)
  4. normalize radio data (from your pwm, ppm, or serial protocol) to -1 to 1
  5. convert radio data to desired setpoint (either rate or angle)
  6. PID where error is desired setpoint (from radio) - actual state (from IMU). Do this 3 times for roll, pitch, and yaw axis. Yaw is always rate setpoint. Now you have 'stablized' PID variables
  7. Control mixer: assign 'stablized' PID variables to each actuator output according to the vehicle dynamics (don't forget to add the normalized throttle)
  8. VTOL control mixer: assign different control mixes/actuator outputs if a radio switch is set high...bonus points if you fade them in
  9. un-normalize the actuator outputs to whatever protocol you are sending to servos/ESC. This can be between 1000-2000us for basic pwm libraries (good for servos, slow for motors) or 125-250us for oneshot125 protocol for motors
  10. Do whatever safety checks you want to do before sending any commands to the actuators. This can include a throttle cut switch which sets all the actuators output variables to minimum if a switch on the radio goes high, or something similar if there is bad radio data coming in (sort of like a radio failsafe)
  11. send the commands out to the actuator pins!
  12. regulate your loop rate (basically just a function that idles until a specified time since the start of the loop is reached)

I think that's about it. All of that is less than 500 lines in C if you go with the bare minimum, but you'll find yourself going down the rabbit hole of wanting to squeeze out more performance with different controllers (cascaded PID or LQR) so beware. This is what you can do with the described bare minimum running on an arduino nano; not perfect but gets the job done:

 
Last edited:

JasonK

Well-known member
#14
I haven't seen that, it looks like they are using an arduino board of some sort there... which amazes me, as the raw crunch power of the CPU on the flight controller board I picked out is way more then that of the arduino chip. I might take a look at that here in a bit, depending on the complexity of using the board that I have. (and yes, I am considering writing my own controller from scratch, but depending on the board in question, you have different setup code needs to get everything talking to each other).
 

JasonK

Well-known member
#15
my goal is to get my flight controller as _light_ as possible to target my final VTOL to be under the 250g limit (249g class) with as much of that weight being battery as possible. So, if something like that gets me all the processing I need (and it looks like the teensy would), then I would be happy to go down that path.
 

JasonK

Well-known member
#16
part of what we have here however, is what 'other' features might we want - IE many FC boards can hook up to FPV cameras to give a data overlay.
 
#17
part of what we have here however, is what 'other' features might we want - IE many FC boards can hook up to FPV cameras to give a data overlay.
Yup, that's the catch. Don't know if (or rather how easily) interfacing with video stream would be on one of these microcontrollers
 
#18
Yup, that's the catch. Don't know if (or rather how easily) interfacing with video stream would be on one of these microcontrollers
yes easy using a standalone OSD I have a couple diff brands I use Tarot and minim osd these have gps and are feature rich but I personally only use these on long range fpv where I truly need all the telemetry I can get

and the one I use the most is HK simple osd for just flight time and remaining battery voltage this one gives me the critical data and clean screen for proximity flying or crusing around my property I know already and dont need screen clutter

TL300L2-001.jpg
 
#19
On the topic of writing your own software, have you guys seen this?

It's a great place to start and his work is all open source. Some of his code is confusing (because we was exploiting the ports on the cheaper/slower arduinos) but you can borrow the stuff that gets you IMU data and radio communication, and then run it on a much faster board like the teensy (also nice to have a super fast board because you can hard-code faster ESC protocols like oneshot125 on any digital pins). Once you have that data, writing the flight controller is fairly trivial as long as you know what steps are required.

A simple PID controller will get you flying in less than a days work. In general, your loop should look something like:
  1. get radio data--pwm, ppm, serial, whatever
  2. get IMU data--gyro and accelerometer
  3. filter IMU data (low pass out the noise, and filter fusion [madgwick] if you want attitude controller; rate controllers only use raw gyro data so no scary math required!)
  4. normalize radio data (from your pwm, ppm, or serial protocol) to -1 to 1
  5. convert radio data to desired setpoint (either rate or angle)
  6. PID where error is desired setpoint (from radio) - actual state (from IMU). Do this 3 times for roll, pitch, and yaw axis. Yaw is always rate setpoint. Now you have 'stablized' PID variables
  7. Control mixer: assign 'stablized' PID variables to each actuator output according to the vehicle dynamics (don't forget to add the normalized throttle)
  8. VTOL control mixer: assign different control mixes/actuator outputs if a radio switch is set high...bonus points if you fade them in
  9. un-normalize the actuator outputs to whatever protocol you are sending to servos/ESC. This can be between 1000-2000us for basic pwm libraries (good for servos, slow for motors) or 125-250us for oneshot125 protocol for motors
  10. Do whatever safety checks you want to do before sending any commands to the actuators. This can include a throttle cut switch which sets all the actuators output variables to minimum if a switch on the radio goes high, or something similar if there is bad radio data coming in (sort of like a radio failsafe)
  11. send the commands out to the actuator pins!
  12. regulate your loop rate (basically just a function that idles until a specified time since the start of the loop is reached)

I think that's about it. All of that is less than 500 lines in C if you go with the bare minimum, but you'll find yourself going down the rabbit hole of wanting to squeeze out more performance with different controllers (cascaded PID or LQR) so beware. This is what you can do with the described bare minimum running on an arduino nano; not perfect but gets the job done:

Cool info thanks! I have the teensy and IMU on order and am putting together the code now for a first test. I'm also figuring out an airframe, probably start with a foamboard design similar to what you did to test the hardware and software.
 

tamuct01

Active member
#20
I started down a similar path with my V-22 Project and found that none of the off-the-shelf drone controllers would do VTOL or helicopter modes. I don't know the first thing about programming for F3/F4 flight controllers, but I'm pretty adept at Arduino, so I took Tom Stanton's idea and used an Arduino to provide servo mixing based upon the stabilized output from my Frsky S8R receiver.

There are several methods to use an Arduino to read RC PWM servo signals, but most are limited to a few inputs and they are quite slow. The best one I found is based on pin-change interrupts that can handle many channels at once and is very responsive.