Loiter mode and PSC tunning

Moved the RPM command from potentiometer (that i thought was unstable) to the normal 3 position switch, surprisingly, yet, the RPM setting is not stable, have to check the inconsistency of the Align ESC governer mode, i suspect it malfunctions.
You can see here that although i fliped to Idleup1 and back the RPM did not change

Will check the dynamic Notch following, thought that assigning 2 for HNTCH_MODE is enough.

will do.

Yesterday’s flight, D gain was almost half, 0.001 and the heli was flying great, i will return to it

Alas the telemetry I use (YAPPU) has no RPM readout. even though i have rigged a sensor. need to find a solution. i suspect that making the pixhawk governing the RPM is worse.

Copy that (thought it might give more clues on the stability).

Will try to do it, i’m restricted by the size of my backyard.

Thank you very much for your help, I’ve started this venture thinking it is impossible to have the AP steer safely the heli, luckily, i was wrong :slight_smile:

Did more tuning today to address the whole ‘command model’ versus ‘feeling’ the helicopter. So, I’ve been ‘tuning to the graphs’, ignoring my gut, and this is where I am at the moment.

• Everything is working fine
• It feels ‘crisp’ but ‘dampened’ in Stabilize. I can certainly feel the feed forward.
• It holds position in PosHold just like it did before I started tuning attitude and rate more precisely.
• I’m curious how these changes will help in AUTO mode as compared to what we are used to.
• I think I should revisit yaw

I will apply some feedback here though. From a conceptual standpoint, the attitude controller certainly needs to be figured out before the position stuff is attempted. That said, I don’t think I can see any significant improvement - or hinderance. The data is there to show properly tuning both really matters, but there is an argument that some realities may be different than the math drives us to. My point to that comment is really how would I have known the attitude tuning was ‘improper’ aside from @bnsgeyer looking at my logs? And, where is the point of diminishing return?

Here is my latest log:
https://drive.google.com/file/d/1H1Q5rj9BEJ4yiUnYXK0LiBts02QzQT-e/view?usp=sharing

I’m sure there is more tuning to do, namely paying a bit more attention to the notch filter settings, and differentially tuning roll and pitch PID. I’m not sure, but I think I can see some differences in roll versus pitch performance in the graphs. And, I think the yaw needs attention, although completely asymptomatic.

My plan this week is to correlate all my notes, tuning logs, etc. and see where @bnsgeyer’s input made the largest differences to my personal strategies or what I was misunderstanding.

I wonder how well some of that process would translate into the autotune methodologies? @bnsgeyer are you planning on doing autotune in small steps, or all at once per concept? i.e. rate pitch P, stop, rate pitch I, stop - or try to find the whole PID, FF, MAX, LIM on one hop? If that answer is in your autotune thread, I’ll self educate first…

Thoughts?

And one more flight. This one exposes another issue I’ve had in PosHold, where if you have a high rate off a position it takes a while to brake and hold the new position. Not sure if this is the PHLD_BRAKE_RATE & PHLD_BRAKE_ANGLE parameters, or more on the P gain for the position, but I will play with it and try to figure it out tomorrow.

https://drive.google.com/file/d/16wSoKJI1IMYeWFedBbeWVaTkkFf02gnu/view?usp=sharing

Later!

Great questions. When a user posts something about behaviors in auto mode or a position hold mode being poor or unstable then the first thing I ask is whether the attitude controller was tuned properly. So it isn’t until they experience a crash or unusual behavior. I don’t know if you feel the same way, but I thought the tuning wiki is pretty explicit and sure it doesn’t contain the knowledge that I’ve recently been pushing but I think it will get a user to the 80-90 % solution. I would be interested in your comments on the tuning wiki. By the looks of your initial set of parameters, I’m guessing that you never bothered to follow it because you felt the aircraft performed adequately with the default parameters.

I plan the autotune to perform a full tune on one axis in about a 5-7 min flight. The user would have to set the command model parameters and the autotune would tune the FF, ANG_P and Rate PIDs. I am currently not planning to get into filter changes. However the way I am tuning the aircraft relies on the user to handle vibrations and provide the autotune with relatively clean feedback signals.

@LoopZilla So what is the fascination with POSHOLD. Why not use Loiter? To be honest, I have not spent much time really digging into these modes and tuning them. I have spent some time with Loiter but I have no experience with POSHOLD. I have found in loiter that it is important to provide the max angle (keeps the controller from getting crazy) and adding PSC_VELXY_D term are important but most of my other values are default.

By the way, you tune looks really good except for some rotor vibes coming through. I didn’t give you an accurate frequency. Based on this latest log, 27 hz is closer. If you want you can widen the notch some to maybe 10 hz since you don’t have RPM feeding the filter dynamically.

I don’t disagree the Wiki got us very close, remarkably close considering the complexity of what we are achieving. But what may be shocking is that the honest answer is we spent an inordinate amount of time studying and applying the tuning concepts from the Wiki in our initial setup. By the book so to say. It is a lot to digest, very subjective, with few examples to hone in on the goals. The forum certainly augments, but there you must filter lots of opinion with limited practical example. Such is the way with open source.

Our tuning processes are extremely regimented. I will not allow tuning a parameter on any of our vehicles without a tuning log. You don’t move a parameter unless you have a justifiable reason, and you must record the change, prediction, and observation. You write a test card to set up the change, and prescribe the way you will validate the change. This helps us create a knowledge base, and helps us to filter out all the ‘good idea fairies’ and knee jerk reactions. The wiki just doesn’t give us all the data to make a prescribed and intentional move, with some associated concept what the detriment could be.

Example from the wiki:
“The final setting for ATC_ACCEL_x_MAX parameters will depend on the size of the helicopter. Large 800-900 class machines will typically be in the 36000-52000 range; smaller 450-500 class machines will typically be in the 90000-110000 range.”

Why? How does that number change the math, and what math anyway? If I change just that number, what should I look for in a response? Where should I look. How might it affect the next steps?

So, something is/was missing from the wiki. Missing enough such that you felt we completely ignored the most important part of your tuning approach.

This controller is quite different from the COTS autopilots, with a ton of variables and options, and it changes too rapidly - which we are all thankful for but it makes staying on top of a perfect tune a significant commitment of time and energy (I know you and many others have invested a lot to even have this discussion). With the heli at 80% optimized, I can go collect data and afford to continue doing business. I have to pay to tinker, and that last 20% is the hardest to achieve.

Our combined goal is to change that point of diminishing return from 20% to like 5%. I think a few minor additions to the Wiki would help with that, or at least bridge the gap between “you didn’t even try” to more like “I see why you stopped”.

I also think that some of my values being fairly close to the defaults also implied that we didn’t make effort to verify them. Not the case, but that was where ‘diminishing return’ may have creeped in on my P gain for the attitude. Example - look at my D gain; default is 0.100 and mine lands at 0.130 (which is even a little aggressive on the high side so we could prove we did something). Our experience following the wiki was: I set the parameters to Tx remote tune the D, we hovered, and with one click on the dial the platform oscillated 20 degrees. Mad. Scary. I wasn’t about to try that on the P - in hindsight ESPECIALLY when the tuning guide recommends a 0.300 max high side and mine lands at 0.058 (2x default). From a subjective standpoint, we didn’t really see any need to risk the bird for what seemed like minimal benefit, especially since there were no symptoms driving us to find a better number.

Maybe I was missing the LOOK AT THE LOGS to unveil the symptom(s) which would drive us to make changes. Tune to the graphs. If anything, that is my largest takeaway from this thread topic!

Simply put, PosHold relates to most all of the other COTS autopilots we have experience with. And, it was where we witnessed a problem - so we set off to fix it. I honestly don’t think this heli has ever been put in LOITER mode, unless that is what happens at the end of a mission.

I’ll try it tomorrow after I research what the definition of LOITER mode is and what makes it different than PosHold (which works fine for our procedures, and what I thought I needed for a better auto LAND mode).

Not to mention the definition of LOITER has changed a lot since it was first implemented (I think I remember it more like the plane definition).

Regarding the notch, yes, I just used the 30Hz (even tried 15Hz), but I must be a little off the perfect 1800. I’ll need to capture another optical RPM to get it dialed in, but I’m tracking.

Loiter is a better mode to use as a precursor to any of the autonomous modes. Poshold is just stabilize mode with a position hold when you center the stick. Loiter uses the position controller for holding position as well as maneuvering. It is a translational rate command with position hold. So when you hold the stick away from center, you are commanding a speed over the ground that the controller is closing the loop on.

Thanks for the feedback. It’s late so I will digest it a little more tomorrow.

So the initial command model parameters will help you establish the baseline guesstimates for a given platform’s size, weight, agility, etc.?

I ask because I will have 3 or 4 more helicopters ready to tune this week, all different sizes. I planned to follow the methodologies we learned here, develop an augmented wiki, and let our interns loose on them (throw some of that subjectivity back in the mix).

I’m really curious if we couldn’t hone in on a generic process, manual as it is for now, but that which would help set a baseline for your autotune concepts and the parameters required to be successful.

Just a thought…if nothing else, getting to a ‘four flights and done’ tuning regimen certainly helps us out.

This is a good example of the way to check the heli behavior, knowing on how to look at the logs and find the parameters that gives you the correctness of the tuning, is essential.
I learned a lot from the data reviled here … thanks a lot :slight_smile:

It would be helpful if you were able to come up with a more detailed manual tuning wiki. Over the past year, I think I have learned enough about helicopter dynamics and the unique challenges posed by RC helicopters. I have it in my head but haven’t put the time into a guide. So having some help along with the experience of applying it to various size heli’s would be great.
Sad to say that I cannot react as quickly as I’d like with feedback. I donate my time to the community. I would like to be more involved in your initial steps so as to guide you with what I have learned. The biggest challenge to tuning a helicopter is trying to get enough feedback correction to keep the aircraft tracking the command model(desired attitude). RC helicopters have lightly damped rotor modes that are quickly destabilized by the Angle P, Rate P and Rate D gains. So quantifying what’s good enough for a heli tune is not easy. But I think what I have learned over the last year gets you close. Squeaking out the high performance response takes more time potentially playing with filters to get a tighter adherence to the desired response.

@bnsgeyer
In order to get better repeatability on the ESC governing mode, changed ESC_CALIBRATION from 3 to 0, RSC_IDLE from 5 to 0
Did a short flight, could only apply pitch for short “steady” flight (have only about 10M space free), hope you may deduce some data from that part. At the second part of the flight, shaked the heli in pitch and roll axes. The heli looks and feels a lot more stable.
following is the flight data:
https://drive.google.com/file/d/1OAiIZjPDRAAerYpu9H3vBJ7gTkCksRyT/view?usp=sharing

checked on ground the RPM and got some puzzling data, flipping idle mode up and down

Did another short flight on higher rotor RPM (2200) to get impression of stability effect and gather data.
https://drive.google.com/file/d/11PQYCm0CRkhpuXZyiLHFsE_vrNRsn-Fl/view?usp=sharing

@bnsgeyer,
Flew today another 450 heli I have (#2), this one has a bit different coefficients, also moved the RPM setting to a pre-defined switch, the RPM is about 2200.
The heli flies well, made some transient maneuvers, you may see that at low rates the heli tracks very nice the required attitude, also the rates are close. at high rate aggregation the AP has overshoots, but this is going to happen only at small percentage of regular flight. so maybe my aggressive checks are wrong.
Following is the data from the flight, checking the FFT gets 35 Hz harmonic frequency, 70 Hz is the largest attenuated, this might be the lead-lag movement, probably due to tight grips needed to be released. (waterfall visualisation would have been nice to check it out).

https://drive.google.com/file/d/14AFiVjE9J3OVqE0CudzQzS-QfzUPCT7Q/view?usp=sharing

continuing with #2, changed rotors due to inability to loosen the grip torque.
checked pitch and roll, there is a definite difference between easy and harsh stick movements
can be seen on pitch response here:


and less on roll response here (dew to area constrains):

Following is the log file:
https://drive.google.com/file/d/1mWspPyxu8t0Fr5R9k75BANO2Ktoa1ntk/view?usp=sharing

So did you change ESC_CALIBRATION previously? I don’t remember, aren’t you using an ESC with a governor? If you are using an ESC with a governor then you don’t need to calibrate the ESC. Even if you are using an ESC without a governor, I’m not sure that you would use the ESC Calibration feature. I don’t know much about setting up an ESC for a heli without using an ESC built in governor. Also the documentation for that parameter says that it should not be set manually. I believe it is really only meant to be used by Multicopters. Sorry if the documentation was not clear.

Also when using heli’s with electric motors, the RSC_IDLE should be 0.

First I think you are using the wrong LOG_BITMASK. You need to have Fast Attitude selected. Looks like you selected PID which is good but all of the data is 25 hz sample rate. So we can’t see the noise in the data. but I guess you were looking at the FFTs using the batch sampling. With the batch sampling and FFTs, if you want to see the post filtered data then you have to set INS_LOG_BAT_OPT to 1. Then when you perform the FFT, it will show the filtered data. as for the settings of the Harmonic Notch, you should follow the settings that I gave you for the first heli. You want to set the Freq to half of the rotor speed frequency which is around 17.5. That way it will start following and attenuating noise after you pass through 50% of the operational rotor speed. The way you have it set now, it won’t start working until you get above 36.7 hz. Also change your HMNCS variable to 11. the harmonic notch will only attenuate up to 3 harmonics. Since you have it set to 15, then it picks the first 3 (1, 2 and 3). You want it to attenuate harmonics 1, 2 and 4 for a 2 bladed rotor.

Lastly, in my opinion, you are showing large overshoot for the high rate inputs because of the large amount of I gain (0.6) that is set for pitch and roll. It looks like it holds real nice for lower frequency inputs which makes sense for a large I gain but you risk the aircraft being able to keep up with higher frequency inputs and potentially instability at much lower frequencies (<2 hz). That is why I am pushing for higher ANG_P rather than high RAT_XXX_I.

Hope this helps.

This setting came by default, had not notice that before.
I’m using an ESC’s with governor, alas, the setup point is not consistent, can’t find the reason for the fluctuation off the initial RPM setup. governing is OK, but the RPM setting is not repeatable.

will do that.

good to know that, i’ll try it later.

I was checking the difference since there was no change on the FFT.

Got puzzled by the overshoots, neglected the integral build up, excellent point, now i understand the reason to keep I as small as possible. my I gain was about 0.15 and not 0.6… is it too large ?

Thanks for your great help, I do learn a lot from your replies

You wouldn’t see a difference until you set the INS_LOG_BAT_OPT to 1. Then you can look at that kind of stuff as the batch logging is logging the filtered data.
You do have to be careful in the result you get from comparing two batch logging runs. The FFT is not normalized and so if you flew longer on one run than another with the same settings, you would see higher peaks on the longer run. So comparing magnitudes at specific frequencies between two flights can be misleading.

0.15 is good. Probably don’t want to go much higher than your VFF gain for that axis.

thanks, thought that the FFT is normalized to the block size.

meanwhile, moved back to heli 1 (trex 450 with flybar) did again the parameters swap, had to tinker a lot in order to calm the heli, eventually changed the Pixhawk to a newer version that can handle RPM, added RPM sensor and applied the harmonic notch filter.
The heli flies well now, rates are a bit bellow the required (enlarging the P and/or VFF starts fluctuation).
it is peculiar that the rates are smaller than the required one, and the attitude seems to follow the required one.

Also i could not get decent FFT data to analyze vibration and harmonics.

suggestions ?

following is the data from the latest flight.

https://drive.google.com/file/d/1sOZRHkFjlcbHLW1-Yyc1N47h8lkLPqAL/view?usp=sharing

Checked again and found that INS_LOG_BAT_MASK was not saved as 3 it remained 0…
here is the another flight log with high sampled data:
https://drive.google.com/file/d/1ef2l86EH9VDygLd0hvZKA0DyV7kNQ5SY/view?usp=sharing

Did you use the setting to collect the post-filter data? Based on what I saw with your control signals when I’ve seen your data in the past. the Gyro FFT should look pretty good. Remember that the Accel data does not get filtered by the harmonic notch.