-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flight - New default PIDs for navigation #4
Comments
These values seem to work very well on a 450 sized 1kg quadcopter. |
This issue should address all navigation related PIDs: PIDALT, PIDVEL, PIDPOS, PIDPOSR, PIDNAVR. |
@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 |
@bk79 Or in CLI: p_vel = 10 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. |
What do you use to simulate it? I want to put in place a simulation Il giorno 09:50 gio 30/lug/2015 Konstantin Sharlaimov <
|
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. |
@digitalentity nope it goes down worse than before, still using the previoius commit, shall switch to the new one and test? |
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. |
@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 |
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 |
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. |
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. |
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. |
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 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 |
if you want to smooth the reading of baro have a try with this code |
@digitalentity did you try anything? |
@bk79 |
Nice, I knew that the arducopter guys knew what they are doing :) |
Yeah, it seems that I've just re-invented the wheel here. He-he! |
@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. |
I'm glad to hear that you've found the source of the problem! I'm even more happy that's not software related 😄 |
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 |
@bk79 noted, thanks! |
A new set of default settings: |
Looks like gps_posr_d is too big. Reduced to 1 and PH was working well at last. |
A flight-tested set of defaults: |
…aflight bring betaflight up to par with serial1wire-blheli-multiesc
A new set of defaults seem to be suitable for most if not all. |
...Nevermind... (wrong post) |
Current default PIDs work for most. I'm closing this. |
MSP command for radar POIs
Need to get some sane defaults for NAV_ALTHOLD PIDs - PIDALT & PIDVEL
The text was updated successfully, but these errors were encountered: