Flight - New default PIDs for navigation about inav HOT 44 CLOSED

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

from inav.

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

from inav.

@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

from inav.

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

from inav.

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 <
[email protected]> 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
.

from inav.

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.

from inav.

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

from inav.

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.

from inav.

@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

from inav.

@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

from inav.

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

from inav.

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.

from inav.

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.

from inav.

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.

from inav.

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

from inav.

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

from inav.

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);
}

from inav.

@digitalentity did you try anything?

from inav.

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

from inav.

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

from inav.

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

from inav.

@digitalentity which values are you using for PIDs? I'm giving a try to the navigation-rewrite branch and I have little with to give a full erase if not needed

from inav.

@bk79
Sorry for being silent for some time. I'm on a field trip and finding a good internet connection here is tricky. I'm using the following parameters and PIDs:
set gps_pos_p = 20
set gps_pos_i = 0
set gps_pos_d = 0
set gps_posr_p = 15
set gps_posr_i = 3
set gps_posr_d = 10
set gps_nav_p = 0
set gps_nav_i = 0
set gps_nav_d = 0
set baro_tab_size = 7
set baro_noise_lpf = 0.350
set baro_cf_vel = 0.965
set p_alt = 100
set i_alt = 80
set d_alt = 0
set p_vel = 130
set i_vel = 70
set d_vel = 50

I'm using CLI because multipliers for PIDs are now different between configurator and firmware. ALTHOLD and PH seem to work for me, need to test if these PIDs would work for different weather conditions though.

from inav.

Forgot to mention another significant setting:
set acc_deadband = 0

from inav.

Thanks but a bit too late for test now I had a try two days ago while i was
on vacation and issued a freeze of the cc3d board with a crash, I'm still
figuring out what the problem is, since I've connected both i2c Nav board,
mag and baro on the i2c bus, and using also soft serial I'm wondering which
one gave me trouble or probably cc3d itself. Did you have any freezing of
the board during your flights?

Il giorno 03:27 mer 12/ago/2015 Konstantin Sharlaimov <
[email protected]> ha scritto:

Forgot to mention another significant setting:
set acc_deadband = 0

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

from inav.

I'm using a Naze Acro, I2C-NAV board, mag and baro on the same I2C bus + OSD on softserial. No freezing so far. What commit were you using for your build? Lots of changes were made in last few days, probably I've broken (or fixed) something. Or it could be bad soldering, failed electrical contact, emf interference, whatever. Unless you'd be able to reproduce the freeze, I guess we'll never know for sure.

from inav.

Any build will give freeze but I had a try with only i2c Navy board
connected and power coming from ftdi so no interferences due to emf I need
to check grounding and soldering on the i2c bus /navboard though it will be
something I can do tomorrow when i'm back home with all the equipment right
now I'm still at seaside with just phone laptop and the quadcopter

Il giorno 06:20 mer 12/ago/2015 Konstantin Sharlaimov <
[email protected]> ha scritto:

I'm using a Naze Acro, I2C-NAV board, mag and baro on the same I2C bus +
OSD on softserial. No freezing so far. What commit were you using for your
build? Lots of changes were made in last few days, probably I've broken (or
fixed) something. Or it could be bad soldering, failed electrical contact,
emf interference, whatever. Unless you'd be able to reproduce the freeze, I
guess we'll never know for sure.

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

from inav.

from inav.

No I think it's something with my config I have no wish to have you loosing
time on this if I'm unsure it's something I did wrong, I honestly admit
that to have everything ready for an fpv session near the sea I did quick
dirty soldering to a sort of bus done with pin headers to have 5v and
ground also available for the 808 camera and for osd. Probably I have to
power directly from one of the escs bypassing the board to keep everything
isolated

Il giorno 15:00 mer 12/ago/2015 Konstantin Sharlaimov <
[email protected]> ha scritto:

That's strange. Probably i2c-nav driver is buggy. I'll dig deeper into this
when I get home next week.

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

from inav.

from inav.

No problem, just one question of you know it, is there a way to evaluate
free ram? I want to exclude that it's low ram stability issue

Il giorno 15:21 mer 12/ago/2015 Konstantin Sharlaimov <
[email protected]> ha scritto:

Please keep me up to date with your findings and don't hesitate to report a
bug if you'll find this to be a software issue.

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

from inav.

from inav.

A new hex file is available - cleanflight_NAZE.navigation-rewrite.Aug13.hex
Now new PID and config defaults. Did several flights with this hex and new PIDs - all seem to work fine on my setup.
@bk79 you can grab a fresh copy of navigation-rewrite branch.

from inav.

I'm at the airport by this evening I'll get a try and compile it for cc3d

Il giorno 07:38 gio 13/ago/2015 Konstantin Sharlaimov <
[email protected]> ha scritto:

A new hex file is available -
cleanflight_NAZE.navigation-rewrite.Aug13.hex
Now new PID and config defaults. Did several flights with this hex and new
PIDs - all seem to work fine on my setup.
@bk79 https://github.com/bk79 you can grab a fresh copy of
navigation-rewrite branch.

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

from inav.

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

from inav.

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

from inav.

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

from inav.

@bk79 noted, thanks!

from inav.

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

from inav.

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

from inav.

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

from inav.

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

from inav.

...Nevermind... (wrong post)

from inav.

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

from inav.