Flight - New default PIDs for navigation

[digitalentity]

Need to get some sane defaults for NAV_ALTHOLD PIDs - PIDALT & PIDVEL

[digitalentity]

These values seem to work very well on a 450 sized 1kg quadcopter.
PIDALT: P=0.4
PIDVEL: P=3.8, I=0.006, D=4

[digitalentity]

This issue should address all navigation related PIDs: PIDALT, PIDVEL, PIDPOS, PIDPOSR, PIDNAVR.

[bk79]

@digitalentity tried yesterday a session with baro althold with default 0.4 but at least on my 500g racers looks like insufficient today I'll test again with 0.7 or maybe 1 on P and 0.002 on I. One of the thing noticed is that as long as I activate the althold I have a small bump in height, this is probably done due to the fact that we have no transaction between rc actual value and the pid output. I think this could be fixed with a transition ramp from during activation of the flight mode

[digitalentity]

@bk79
If possible please try the following PIDs:
ALT: P=1
VEL: P=1 I=0,015 D=4

Or in CLI:
p_alt = 10
i_alt = 0
d_alt = 0

p_vel = 10
i_vel = 15
d_vel = 4

These values come from computer simulation I did yesterday, but I haven't had a chance to flight test them - weather is unflyable, strong wind and rain.

[bk79]

What do you use to simulate it? I want to put in place a simulation
station to try an incremental version of the pid

Il giorno 09:50 gio 30/lug/2015 Konstantin Sharlaimov <
notifications@github.com> ha scritto:

@bk79 https://github.com/bk79
If possible please try the following PIDs:
ALT: P=1
VEL: P=1 I=0,015 D=4

Or in CLI:
p_alt = 10
i_alt = 0
d_alt = 0

p_vel = 10
i_vel = 15
d_vel = 4

These values come from computer simulation I did yesterday, but I haven't
had a chance to flight test them - weather is unflyable, strong wind and
rain.

—
Reply to this email directly or view it on GitHub
https://github.com/digitalentity/cleanflight/issues/4#issuecomment-126213838
.

[digitalentity]

I've wrote a quick and dirty model of a copter (only linear velocity/movement is calculated, banking angles are treated in an inprecise way, heading is assumed to be 0 deg). After that I integrated my PID code into this model, tried different PID values, and looked at P/I/D, velocity and altitude changes. No HIL simulation yet, sorry.

[bk79]

@digitalentity nope it goes down worse than before, still using the previoius commit, shall switch to the new one and test?

[digitalentity]

Thanks for testing this out. My simulation must be wrong somewhere. You can still test this with previous commit, there was no serious change since then. Would you happen to have a blackbox log of your test flight? It will help to track down the problem.

[digitalentity]

@bk79
It just occured to me that my NAV code is doing all wrong from the start. Current PID chain looks like this:
altitudeError -> PIDALT -> desiredVelocity -> PIDVEL -> throttle
This has one fundamental flaw - delocity is NOT proportonal to throttle. However acceleration is. There should be one more PID controller:
altitudeError -> PIDALT -> desiredVelocity -> PIDVEL -> desiredAcceleration -> PIDACC -> throttle

[bk79]

@digitalentity now it's clear the problem. On my thesys I didn't work on velocity ir acceleration to have altitute hold, you can't use a pid that way, or you have to integrate (once or even twice) with obvsious integration errors to obtain the same variable again. Let's keep it simple and use a very simple reading from baro and compare it with the setpoint. If you want to make it smoother also with speed and acceleration we can put three pids with max setpoint and a minimum selector on the output of all the PIDs so that it doesn't exceed some max value for those two other parameters. In the way you did you have CASCADE regualtors, which means (for stability) to have different loop times. or they won't work

[bk79]

One more thing, don't look for relationship between vel or acc to the throttle, the pid doesn't care about that, once PV and SP are of the same nature and you limit the output within the within the boundary limits (0-100 ie) pid will regulate itself with correct values

[digitalentity]

I figured that APM is doing a cascade in a similar way. It takes altitude error and feed it into position P-controller to get velocity target. After that it calculates velocity error and feed it into velocity P-controller to get acceleration target to reach this velocity. Then it calculates acceleration error and use it to calculate throttle value with PID-controller.
That makes sense to me. If we want to keep altitude constant, we need to keep velocity and acceleration to zero. Accelerometer has a very fast response time and less noise compared to barometer or acceleration integral. Directly controlling acceleration with a PID-regulator will give us a much faster response.
This is also very similar to copter leveling - we are not using accelerometer to directly control motors, we use angular rate - gyroscopes to compensate for rate of change before this change gets high enough to be noticed.

[digitalentity]

I think I'll give it a try. I've made a 3-PID cascade in 18f90963e10bf57caf90a79199d5b2652acc6c54. If it won't work I'll simply revert that commit.

[digitalentity]

Also, considering basic physics we can theoretically calculate acceleration-to-throttle PID parameters. Acceleration is directly proportional to thrust, which in turn can be assumed to be directly proportional to throttle. If we need to reach a given acceleration we should have a certain amount of extra thrust. Relation is linear and is essentially a P-term of a PID-controller translating acceleration to throttle.

[bk79]

the problem is that once you reach acc=0 and you're in constant velocity you're moving anyway without setting anything, it's ok to use limit to acceleration and have a pid to target 0 point but if you're reaching a condition of constant velocity from acceleration would prevent it to reach altitude setpoint. and now that I'm thinking about that the copter was going down at constant velocity...slow velocity, and it going up without stopping at the point where I've activated alt hold thanks to the I part I've added very slowly
I still have the to send you the log if you're still interested in that

[bk79]

I would do this...let's divide two pid control for alt hold one to keep setpoint (altitude set -altitude read) velocity comes already from the D term of this pid, the second one for keeping acceleration within a small value -deadband - (9.81 - tilt corrected acceleration reading), the minimum of the two reading will be the output to the throttle

[bk79]

if you want to smooth the reading of baro have a try with this code
if (prevbaroread != 0)
{
float highlim = prevbaroread* 1.05;
float lowlim = prevbaroread * 0.95;
float smoothread=fmax(lowlim,actualbaroread);
smoothread=fmin(smoothread,highlim);
}

[bk79]

@digitalentity did you try anything?

[digitalentity]

@bk79
Did try 3-pid cascade (P-controllers for altitude and velocity, PID-controller for acceleration). Default PIDs were very low, especially kI for acceleration PID (caused initial drop of altitude when enabling althold), but after some time the copter was very good at keeping altitude. As a matter of fact I never seen it hold altitude that good. Forgot to enable blackbox logging so not much to analyze here. I'll give it another try tomorrow if weather is good enough, play with PID values a bit. If it will indeed fly that good, I'll keep this code.

[marksev1]

Nice, I knew that the arducopter guys knew what they are doing :)

[digitalentity]

Yeah, it seems that I've just re-invented the wheel here. He-he!

[bk79]

@digitalentity I've had a try to the latest build with cc3d looks like working even if I cannot fly for now, I'm waiting for a 4 new escs since the old cheap one were faulty. As far as the i2c driver looks like the problem was a faulty dupont cable of the with sda line of the nav-board + the use of internal pull up resistor was really giving a lot of noise to the lines. Since I'm already using gy-68 which includes aready 4.7kohm reistors between lines it was more than ok to use those and disable the internal resistors of the atmega328p sda-scl. So far I had two hours running without any issues. I'll leave the board on connected the whole night and see if it is stable over 12 hours which I think is a reasonable time to be sure it works properly.

[digitalentity]

I'm glad to hear that you've found the source of the problem! I'm even more happy that's not software related 😄

[bk79]

yep..anyway as suggestion if you use the same board and some other mag or baro that already has sda-scl resistors mod the twi code to comment out the pull up resistors of the atmega. it will reduce noise of 70% at least.

those are the two lines to be commented out
// digitalWrite(SDA, 1);
//digitalWrite(SCL, 1);

[digitalentity]

@bk79 noted, thanks!

[digitalentity]

A new set of default settings:
set gps_pos_p = 33
set gps_pos_i = 0
set gps_pos_d = 0
set gps_posr_p = 70
set gps_posr_i = 15
set gps_posr_d = 50
set nav_gps_cf = 0.200
set baro_tab_size = 7
set baro_noise_lpf = 0.350
set baro_cf_vel = 0.965
set p_alt = 30
set i_alt = 150
set d_alt = 0
set p_vel = 100
set i_vel = 50
set d_vel = 50

[digitalentity]

Looks like gps_posr_d is too big. Reduced to 1 and PH was working well at last.

[digitalentity]

A flight-tested set of defaults:
set gps_pos_p = 15
set gps_pos_i = 0
set gps_pos_d = 0
set gps_posr_p = 90
set gps_posr_i = 15
set gps_posr_d = 1
set nav_gps_cf = 0.200
set baro_tab_size = 7
set baro_noise_lpf = 0.350
set baro_cf_vel = 0.965
set p_alt = 30
set i_alt = 150
set d_alt = 0
set p_vel = 80
set i_vel = 50
set d_vel = 50

[digitalentity]

A new set of defaults seem to be suitable for most if not all.
nav_alt_p = 50
nav_alt_i = 0
nav_alt_d = 0
nav_vel_p = 100
nav_vel_i = 5
nav_vel_d = 100
nav_pos_p = 15
nav_pos_i = 0
nav_pos_d = 0
nav_posr_p = 90
nav_posr_i = 15
nav_posr_d = 1

[marksev1]

...Nevermind... (wrong post)

[digitalentity]

Current default PIDs work for most. I'm closing this.