INAV 1.6: Fixed Wing PIFF Controller

Another new feature of upcoming INAV 1.6 (BTW, INAV 1.6 ALPHA-1 has just been released) is brand new PID controller for fixed wings. I repeat: this new controller is used only on fixed wings, multirotors are not affected.

So, what is new about this new PID controller? First of all, it is no longer a PID (Proportional, Integral, Derivative). It is a PIFF (Proportional, Integral, Feed Forward) controller. What is the difference?

Traditional PID controller computes error between setpoint and measurement and feeds it to 3 modules: P, I and D.

PID controller

Continue reading “INAV 1.6: Fixed Wing PIFF Controller” »

Read More

JavaScript PID controller

I suppose this is the first time programing topic came up on this blog. Probably not the last time, since this is what I do most of the time.

While working on serial port usage balancing for INAV Configurator I’ve quite accidentally created a PID controller in JavaScript. Maybe it’s not the most advanced PID controller ever, but has all the things required:

  • computes P-term
  • computes I-term
  • computes D-term
  • has output limiting
  • has I-term accumulator limiting

Continue reading “JavaScript PID controller” »

Read More

PID looptime: why it is not only about frequency

Last 18 months was an extremely good period of time for all mini-quad enthusiasts. Progress, hardware and software both, was just incredible. Who could have guessed that in less than 2 years mini-quads will evolve into main group of drones with such excellent flight characteristics. Just take a look at looptime. When I entered the hobby, standard looptime was 3500us (285Hz). Then, someone noticed that mini-quads fly much better when looptime is lowered and it started. Right now, standard looptime is 2000us (500Hz), while Betaflight starts with 1000us (1kHz) or even 500us (2kHz) in case of faster flight controllers.

Just by looking at numbers one might come to a conclusion, that looptime should be kept as low as possible and higher control loop frequency is better. Hey, 2kHz should be twice as good as 1kHz, right? One might even thing that it’s really about frequency. Well, this is both false and true: sometimes it is not about frequency, sometimes it is about frequency after all.

Continue reading “PID looptime: why it is not only about frequency” »

Read More

JJPRO P175 PID tuning values

Like I stated before, default values for JJRC JJPRO P175 are flyable. But there is a huge difference between flyable and flying good.

I've spent few LiPos trying to make it fly just better than on stock values, and here is the most important fragment of CLI dump from my short tuning session.

Changes:

  • OneShot125 enabled
  • Gyro filtering improvements
  • Lower P gains
  • Lowered D gains
  • Raised I gains
  • Raised Rates
feature ONESHOT125

set i2c_highspeed = ON
set gyro_sync = ON
set gyro_sync_denom = 8
set gyro_lpf = OFF
set gyro_soft_lpf = 90

set p_pitch = 32
set i_pitch = 49
set d_pitch = 18
set p_roll = 32
set i_roll = 45
set d_roll = 18

set dterm_cut_hz = 80

set rc_rate = 90
set rc_expo = 65
set rc_yaw_expo = 0
set roll_rate = 70
set pitch_rate = 65
set yaw_rate = 55

Important: those settings apply only to 4S batteries. On 3S PIDs will be probably too low!

JJPRO P175 PID tuning values

Read More

Detecting Cleanflight PID tuning issues with Blackbox: gyro noise

After a short brake, let’s return to Blackbox series with new entry: “How much gyro noise is too much?”.

Almost all PID tuning tutorials states: reduce vibrations that affects gyroscope and accelerometer readouts. Yes, this true: any vibrations that appear during flight affects gyroscope and accelerometer readouts are bad and should be kept as low as possible. This can be done by balancing motors, propellers, using stiffer frame, adding dampeners, lowering LPF filters. But how much vibration induced gyro noise is too much? Let me answer with four Blackbox screenshots:

Super smooth gyro traces, no noise

smooth gyro traces

This is how it should looks like! Perfect trace. If it is archived without lowered LPF filters, then kudos for balancing everything!

Somehow noisy gyro traces

somehow noisy gyro traces

Little noise appears, but amplitude is low, everything is under control.

Noisy gyro traces

reasonably noisy gyro traces

Gyro noise is visible. It is not a problem yet. If it was a result of raised LPF cutoff frequency, extra noise might be worth lowered signal delay. I would start to think how to reduce it on a hardware level. Perhaps bearings are dying, or propellers should be rebalanced?

Extremely noisy gyro traces

extremely noisy gyro traces

This is how unflyable gyro noise level looks like! If you see have problems with flight performance, you know what is causing it. This have to be fixed ASAP before everything else.

Read More

How to tune PID I-term on a quadcopter

With this entry I want to initiate short series of articles showing how to tune multirotor / quadcopter PID controller. Let’s call it a continuation of Blackbox series, but this time I will not relay only on Blackbox data. Yes, I will show few examples how given scenarios looks on Blackbox logs, but all steps will be doable without Blackbox.

Before we proceed, you much understand how PID controller works and what Kp aka. P-gain, Ki aka. I-gain and Kd aka. D-gain are responsible for. There are many sources: Wikipedia, my “What is PID controller article”, great video from Bruce and many many others.

How to tune I-term of PID controller

Most PID tuning tutorials suggests to start with P tuning and then move to I. Why? Probably because it’s simpler to get UAV in flyable state. Or because P is first letter on PID. Or I have no idea. Starting with I has some advantages:

  • tuned I-term will not affect much more important Pterm tuning
  • it is simpler to tune I than P if proper method is used
  • tuned I-term will probably not change during P and D tuning

Before we proceed, a reminder of what I-term is used for and short characteristic of it:

  • I-term is responsible for correcting long time error accumulated in the past: non-even thrust from motors, wind, etc.
  • I-term should not be affected by short events like few degrees attitude correction
  • I-term should should react fast in special conditions like upside-down phase of rolls and flips
  • bigger I-gain not only means that correction will be stronger. What is more important, it also determines how fast I-term would change!
  • too low I-term causes multirotor unable to keep desired attitude. UAV will bank on its own, be sensitive to wind
  • too much I-term will introduce overshot, visible low frequency oscillations, wobble on descend
  • gentle, smooth flying for aerial photography requires much lower I-gain than aggressive acrobatic flight
  • better UAV balance (center of thrust close to center of gravity) results in lower required I-gain
  • usually, due to weight distribution, pitch axis requires more I-gain than roll axis

There are two methods of manual I-gain tuning:

  • Tuning for smooth, aerial photography, flying with bigger drones
  • Tuning for acrobatic flying with smaller drones (250 size and smaller)

How to tune I-term for smooth flying, aerial photography style

General rule for I-gain tuning for smooth flying on bigger machines (8″ or bigger propellers, > 1kg) is to keep I as low as possible. Multirotors like these are not designed for acrobatics, or aggressive flying. Their main purpose to to be stable in hover or cruise and do not wobble on descend. Higher I-gain, due to bigger (sometimes huge) inertia of both body and propellers will result in overshooting, wobbles and oscillations.

  1. Start with weight balance. Center of gravity should be as close as possible to point of thrust. Simple procedure looks like this:
    1. For pitch and roll axis find a line that crosses the frame between two point lying in the middle between motors opposing this line
    2. Try to lift multirotor using two fingers catching centerplate where line crosses it
    3. If frame tilts forward, move some weight (usually battery) back, if frame tilts left, move some weight right, and so on
    4. This does not have to perfect, but the closer you will get, the better flight performance you will have
  2. Tune roll and pitch separately. Ignore yaw for now, this can be tuned much later and usually it is not required to tune yaw at all!
  3. Tuning has to be done in Acro/Rate mode, without self leveling!
  4. Start with default PID gains. In most cases they are good enough for hover. If drone is able to take off and does not wobble on its own, you are good to go. If it is sluggish, wobbles, tilts on its own, increase P gain in 20% steps until it is hovering without much trouble. Remember, we are not tuning P yet. We just want it to be flyable.
  5. Throttle up and do a fast ascend for few meters. Then cut throttle to about 25% and descend fast. Observe what is happening to a drone. Three things can happen:
    1. If drone is unable to keep attitude and tilts is any directions, I gain on this axis is too low. Increase I gain and repeat experiment
    2. If drone keeps attitude, but wobbles on descend, I gain is too high. Decrease I gain and repeat
    3. Try to keep I gain lower than higher. That means you should concentrate on finding a spot closer to a point where UAV is unable to keep attitude that to the point where wobble appears
    4. If drone keeps attitude and does not wobbles on descend, I gain is tuned
  6. Confirm I-gain tune by doing forward-backward and left-right fast flights. If multirotor is able to keep angles, does not slowly drift or slowly wobbles during braking, congratulations, you tuned I-gain for smooth flying!

On a Blackbox log, wobble during fast descend might look like this: too much I gain during descend

Both axises: roll and pitch were affected in this case, but bigger wobble appeared on pitch axis, up to 45degrees per second! If you take a look at pitch PID graphs, you would see that I-term moved from more positive, to negative and then to positive again. P term tried to compensate, but it had to fight not only with changing conditions, but also with changing I term after original movement has been canceled out. This might not a be a perfect example, but shows general principle.

This example show what is happening in similar situation when I gain is much lower. I term stays more less flat, most of the work is done by P term.

not too much I gain during descend

How to tune I-term for acrobatic flying

If you would tune I gain using procedure from previous paragraph and went doing some rolls and flips, you would notice something bad: when copter crosses 90 degrees and begins upside-down phase, single wobble, a strong jerk, appears. Like I mentioned before, I gain does not only determines correction force. It also determines allowed speed of change when conditions changes. Imagine a copter that is slightly tail heavy. That means motors in the back have to spin slightly faster than those in the front to compensate for weight imbalance. I term does that very moment you take off and it works as long as you do not try to bring everything upside down very fast. If rear motors would still bring more trust that forward motors when drone is inverted, it would not compensate for weight imbalance. It would make thing worse than better. Our imaginary tail heavy multirotor needs less thrust in the back when flying inverted.

Flips, rolls and all other rapid maneuvers requires higher I gain to allow for faster I term change. If I term is unable to follow strong changes, single wobble or multiple wobbles would appear when passing magical 90 degrees inclination.

Another problem with method from previous paragraph is that small machines are much more wobble on descent resistant than big ones. Smaller, faster rotating propellers, less inertia, more agile. One would really have to push I gain very high to see strong wobble during descend. And it still not would do good for acrobatics. This is why, on those machines, try the following

  1. Balance multirotor like above
  2. Start with default PIDs
  3. Use only Acro/Rate mode
  4. Tune each axis separately
  5. Take off and check UAV stability during fast ascends and descends
    1. If it keep attitude but wobbles, lower I gain
    2. If it does not wobbles, but does not keep inclination, rise I gain
    3. If it does not wobbles and keeps attitude, we can move forward
    4. This step does not have to be very precise. As long and it keep inclination, you are good to go
  6. Go high. If you have FPV, this helps a lot. If not, just pay attention to drones behavior
  7. Do a fast single roll. If during transition to inverted flight (around 90 degrees) multirotor jerked, I gain is too low and I term is unable to follow the change. Raise I gain on axis and try again. The hardest thing here is to decide which axis is responsible for jerk. Sometimes it is single axis, sometimes both roll and pitch together: FPV helps a lot with this. If you really do not know, rise both. Repeat this step until roll is smooth, without visible wobble
  8. Do the same during flips. If you did everything right in previous step, this is only to confirm everything works like expected
  9. Confirm there are no wobbles during fast descends. If they appear try lowering I gains a little

Small note: I gain that allows for smooth transition to inverted flight flight depends on rotation speed and imbalance. The bigger imbalance and faster the rotation, the higher I gain would be required. So if you change rates, you might want to repeat I term tuning.

Read More

Which sensors drones use to fly?

Modern drones utilize many different sensors to archive flight. Some of them are required to fly, some are only optional and they can only improve flight performance. This entry will be a summary of those sensors, with short description and information how UAV utilizes data from them.

Gyroscope

Gyroscope, or shorter gyro, is the only sensor that drone really needs for stable flight. It feeds flight controller with extremely important information: how fast aircraft is rotating around its own axises: roll, pitch and yaw. Inner loop of PID controller utilizes his information to stabilize the craft.

When pilot is not applying any deflection to roll, pitch and yaw control sticks (they are in neutral positions), drone should not rotate. It should keep current attitude, do not wobble, do not have rotation drift. If it starts to rotate, this information is taken from gyros and counteraction is applied to stop unintended rotation and event to rotate back to desired attitude.

Continue reading “Which sensors drones use to fly?” »

Read More

Cleanflight low pass filters part 2

Quite a lot things changed in the world of low pass filtering since my previous port on this topic was published. So, here is the updated guide to Cleanflight LPF filters:

gyro_lpf

gyro_lpf is the most important low pass filter for gyroscope readouts. First of all, it is not part of Cleanflight, but is done by gyroscope itself. Cleanflight only initializes gyro with desired cutoff frequency. Allowed values are:

  • OFF
  • 188HZ
  • 98HZ
  • 42HZ
  • 20HZ
  • 10HZ

When OFF is selected, gyro offers fastest possible sampling rate (8kHz, new data every 125us) and smaller possible delay. But, it is extremely prone to any vibrations. Any noise from motor or propeller will be visible in gyro output. All other values of this filter allows gyro to provide new data every 1000us (1kHz).

42Hz is lowest 'flyable' cutoff frequency. It does not makes sense to go lower, since signal delay will be too big and filter will attenuate frequencies that are important from 'flight' point of view. So, 188Hz, 98Hz and 42Hz are the ones that are interesting for us. Exact value depends on propellers, motors, balancing, bearings state, frame rigidness and few other aspects. Let's say, that 250mm or smaller frames can use 188Hz, 450mm and bigger frames should use 98Hz or 42Hz.

gyro_soft_lpf

gyro_soft_lpf is a second state of gyro readout filtering before they are introduced to PID controller. One might ask: why two filters? After all, gyro_lpf does the same thing. Yes, it does the same thing. But using 2 LPFs in this case has some advantages. gyro_lpf can not be tuned. It's either: off, 188Hz, 98Hz, 42Hz. But what if, for example, main source of gyro noise is at about 90Hz? Cutoff at 98Hz would be pretty useless. One would have to use 42Hz, loosing a lot of usable frequencies and having to suffer from noticeable (from PID controller point of view) delay. This is why fully configurable second stage of LPF was added.

gyro_soft_lpf should be kept below gyro_lpf, and below frequency of main noise source. Usually between 50 and 100Hz. Frequencies below 50Hz are too important for stable flight to attenuate them. On the other hand, everything above 100Hz is useless and can be cut off.

pterm_cut_hz

This software LPF filter was removed and is no longer available.

dterm_cut_hz

Here, let me just quote my previous post:

(..) D term of PID controller, since it is trying to look into a future, can be a source of huge noise and vibrations. After all, looking into a future is always a tricky business. This is why D term can change with totally different frequency than gyro input and there is a very good reason to limit D term change. Too see how excess D noise can affect gyro traces take a look at my Blackbox tutorial.
(…) Rule of thumb is: smaller and more rigid frames allows for higher D term cutoff frequency and 42Hz is a good place to start. Bigger frames might require lower cutoff frequency and 10Hz is lower boundary.

If only frame and noise level allows, D term cutoff frequency should be kept as high as possible. This allows D term to reacts faster to changing flight conditions and can greatly improve UAV behavior in prop wash and rapid maneuvers.

Read More

Setting up iNav on 250 class racer

Although iNav (iNavFlight) with advanced GPS and navigation support is best suited for larger, GPS equipped drones, there is absolutely no reason not to use it on something smaller like 250 racer. Why? Well, why not? Basic flight mechanics is the same like in Cleanflight or Betaflight. FP-PID is brand new PID controller, not very popular and not very well documented, but in many ways superior to LuxFloat. The way it handles D term is just outstanding. It can be pushed very, very high without introducing noise.

OK, it has a drawback. High computational requirements and floating point logic causes users of STM32F1 based flight controllers like Naze32 or CC3D can forget about looptime 1000us. 1400us is all those boards can do. On the other hand, looptime 1000us (or even 500) is quite new thing introduced and made popular only about half year ago. And people were racing before that somehow… So, 2000 is not that bad after all. Good thing SMT32F3 board are strong enough not to have to worry about this issue. So, let’s go! Continue reading “Setting up iNav on 250 class racer” »

Read More

New PID controller for iNav

If anybody keeps track of my posts about iNav flight controller software, he or she should notice that I like it very much. Guy nicknamed DigitalEntity did excellent job improving Cleanflight’s navigation modes. Maybe it is still not the same level as Pixhawk or Naza, but with this improvement speed those two are within reach for sure. When few days ago I noticed that he started to work on new PID controller called FP-PID, I’ve decided to take a look at.

Question. What is the worse flaw of all MultiWii inherited PID controllers? No, not the fact that they are using integer math. It might not make much sense on FPU equippent CPU like STM32F3, but it is fine. The biggest problem with them is that they are not based on proven scientific methods. If you read the code, it will look like this: divide this by Y, multiply X, make a strange assumption, instead of running other control loop make another strange assumption. At the end, they work. But hmm… in a magical way… The only PID controller that was written according to “rules” is LuxFloat.

And since I’m not an expert on control theory, I’ve decided to ask DigitalEntity why FP-PID is developed and what new will it bring. Here are the most important fragments of his reply.

I believe that the only real reason to have lots of PID controllers if that some/most/all of them are flawed in some way (from calculus point of view). So instead of having 2-3-4-5 controllers based on coding voodoo I would prefer to have one controller that is based on solid math and well-known numeric methods. The only PID controller in Cleanflight with clear and simple design […] is LuxFloat. That’s the reason to take it as a base for future improvement.

Comparing to LuxFloat, it is designed to improve the following:

  • Better integral anti-windup prevention. Instead of hard-limiting integral part […] the FP-PID implements so-called ‘backtracking’ algorithm to keep the PID controller output within limits. Next step […] PID will be aware when the motors are at their limit
  • Improved D-term calculation. All fuss around D-term is about noise. D-term tends to amplify high-frequency noise (usually vibration from props/motors) making the quad jitter. Current designs calculate D-term from current and previous readings and implement low-pass filtering and averaging to prevent D from amplifying noise, while allowing it to do it’s job. They all fight the consequence, not the cause – they try to fight already amplified defivative of the noise instead of filtering the noise itself. My D-term code is based on Pavel Holoborodko’s method of noise-robust derivative calculation […]. I also kept BiQuad filter from Betaflight to filter out the remainder of the noise.
  • Modifier self-leveling logic. Current approach with self-leveling is to take angle error and feed it to gyro-based controller as if it was pilot’s input in acro mode. However, roll/pitch angles are calculated from the same gyro data, leading to the phenomenon similar to D-term noise amplification – the faster the quad is rotating the bigger is PID response in self-leveling compared to rate mode. What I did is made the self-leveling code behave like human pilot. Human pilot does not correct for each and every slight attitude change, instead he corrects for bigger and slower changes. This is by definition the low-pass filter which is what I did in the code. This change makes self-leveling less jittery which is very evident when doing FPV flights in ANGLE or HORIZON modes.

The way I see it, it sounds super intresting. If time and weather will allow, I will give it a try next weekend on my 250 build. Just for fun.

Read More