PTB v0.44 Release! 

be great to have something implemented in BF to do that in the data collection phase

good question. I think antigrav wont matter too much during "basement tuning" because it only kicks in with fast throttle moves. as for iterm_relax, hmmm, I think I'd leave it on. The thing with iterm is the tuning window there will be very very wide for a 5 inch. so like as long as P is sufficiently high to close the error gap, then you could effectively have iterm anywhere from say ~50-150 without issue. racers like it on the high side for helping in sharp turns as it gives a constant push that really helps cornering. the only time I term becomes and issue if on less powerful builds when asking too much of the quad wrt rotation rate. so like jamming 1000+deg/s. So ya, there are these non-linearities but I think most of the range where we fly usually is within the bounds of where things are fairly linear. I think that's why the PID controller works at all on our miniquads, and why step resp method seems to work pretty well. Not sure I understand the 2nd part of your question. I have thought about how to sort of model the parts that are not tested. so in a sense if it's linear then it should be easy to interpolate across the points not measured. I sort of do that when making a decision on what PIDs I should use. So I might often pick PIDs that are between two curves. I like the idea of modelling the missing data though

@@PIDtoolbox Thanks for your answer : - ). At least at my build I see a difference from the step response estimate generated from experiments having i term relax off or on. I actually found the information helpfull for tuning the highpass for i-term relax. what i actually ment with the second part was assuming we're having i term relax off and we're exciting the quad in RPY direction around hovering the controller operates linear around an operation point. As far as I understood PIDtoolbox is estimating the stepresponse from setpoint (w) -> gyro (y) via powerspectrum estimation (T = Pyw / Pww, T: w->y) and then integration of the impulseresponse (just ifft). In the same way you could actually estimate from setpoint (w) -> pid output (u) (SCw = Puw / Pww, SCw: w->u). Dividing those in the frequency domain delivers the frequency response estimate of the open loop plant (P = T/SC, P: u->y). The idea then would go as follows: 1.) take an experiment with any stabilizing PID parametrization with sufficent excitation and not too much gain in the higher frequency region, 2.) estimate T, SCw and the plant P, 3.) since T is just a function of P and C (PID cntrl) the stepresponse of T could then be calculated (simulated) with any given PID values (try and erro in PIDtoolbox). Like this it should be possible to reduce the amount of experiments and tune at least the linear part of the controller offline with real data : - ) It should actually even be possible to tune the lowpassfilter for the D-term along the process. (phu...)

N refers to the number of observations that go into an average. Here it’s referring to the number of extracted step response curves that go into that averaged step response curve. The algorithm uses a sliding window that moves across the data from start to end of logfile and at each point in time is computes the relationship between set point and gyro to get the step response trace for that date. Then it steps and repeats until it reaches the end. All the while it collects these step response curves that are then averaged in these plots. Hope that makes some sense

@@PIDtoolbox aaaaahhhh :D This was shown as much higher number in the past, right ? Anyway much thanks for the fast and exactly answer! Now i can sleep again at nights :) Regards ❤️

@@outlawdareal it depends on many factors. There used to be subsampling and min deg/s options both of which affected N, but the absolute N here is not as important as the quality of the observations. For example if you set min deg/s in the old version to something really low, it just start trying to compute step responses on little blips in the data around the noise floor. sure you'll get higher N, but not a better or more meaningful result. the current settings will only give you a good result when you have a clean gyro, and you give it a decent amount of stick input. this way, people dont interpret junk.

as a rule of thumb for gyro, -30 to < -20 is acceptable. > -20 is questionable, > -10dB not good, > 0dB you're on fire. This is of course ignoring every below 20Hz which is essentially stick input. Between about 20Hz and 100Hz is a tricky region because it's not usually filterable so you get what you get there, but the best flying rigs will have this region below -30dB as well, and that's irrespective of propwash or oscillation

@@PIDtoolbox Thanks 🙏🏻

you never need to re-run the installer. just grab the new PTB executable (in the 'main' folder). Drop the 'main' folder on your desktop and run the program that's inside there. I recently re-uploaded the win version which had a bug in the spec analyzer, so try re-downloading

@@PIDtoolbox ty sir 🙏🏼

can you be more specific? are you referring to during the runtime install or just downloading the program zip file from github?

😄

I cant recall if KISS logfile outputs setpoint. From what I saw it looks like it's RC command but not set point. Maybe Im wrong. Send a recent logfile and I'll take a closer look

@@PIDtoolbox You are right, KISS seems do not output "setpoint" to logfile. I would love to send you some log file but I don't know how to do that in RU-vid

@@xuanyuliu6715 drop it in the PTB github site under 'Issues'. Add an issue for "KISS functionality" or something. If you dont have a github account, then the blackbox log facebook group. My name is Brian White and I respond and post there quite a bit. It's Mark Spatz site

@@PIDtoolbox Will do. Thank you