My 450 heli is sluggish in loiter mode, checked out PSC parameters.
@bnsgeyer, Bill, is there a “cook book” for loiter tuning ?
Went over the talks you and Chris had with David, is there recommendation for startup parameters ?
Checked the data again, it seems that i have VIBX problem from time to time
I have 3 different 450 helis, with different installation and configurations:
#1 has flybar , Pixhawk 1M, installed on shock absorbers
#2 is flybarless, Pixhawk 2M, Installed on the frame
#3 is flybarless, Pixhawk 2M, installed on shock absorbers
all have Arducopter 4.0.4.
All helis behave great in Stabilized mode, and wonder on loiter
Looked for something in common…
VIBY and VIBZ are significantly more quiet, so it must come from the tail.
Checked Tail rotors, changed blades… the same behavior…
My guess is according to @ChrisOlson warning over lose cables that induce vibration,
that this might be the reason.
As can be seen on the following graphs, vibration was dumped during flight,
which i think, means it’s not coming from the tail rotor
Do you have any suggestions ?
This is a dumped X vibration in flight:
Here the X vibration changed during the flight
@ZvikaF I am pretty certain that the vibrations aren’t causing it to wander in loiter, especially since they are low(<30). Is the heli toilet bowling or just randomly moving around? The big thing to check is to ensure your velocities are tracking (desired vs actual). If they are tracking then it may just be the GPS accuracy.
Another way to check that it is not the EKF solution but the GPS is to compare the GPS Position to the EKF however you would need to put them in the same units (I.e convert distance from home to latitude and longitude in deg:min:sec.
@bnsgeyer Thanks Bill for the reply.
This movement is mostly random, I will try checking and compering the EKF, velocities seems to follow the commanded, but, as my checks are done in a confined area, I have to interfere at about 2 meter drift.
Some times the hellis that flew perfect before, initiates toilet bowling out of nothing, this happens in stabilized mode, could not find the reason, especially, as this is random.
any suggestions ?
In reference to the toilet bowl concept, I have a few questions. We experience some of the same symptoms, albeit minor, and generally let it slide to blame it on environmental effects that are inducing the toilet bowl oscillations.
Today I pulled my logs and see that my PSC.PX and PSC.PY show a sine wave around my position PSC.TPX and PSC.TPY respectively. I then looked at the velocities, and found that my PSC.TVX is essentially 1/2 of my PSC.VX. Same with Y axis. Accelerations look quite close to target (PSC.TAX = PSC.AX).
My questions are -
Where is the oscillation being generated, in the position PID or the velocity PID? I’m sure that is practically impossible to answer without more info, but I am sure there is a feedforward or something in the control to weight the two. How can I learn more about that control architecture?
For now, I can self educate if I go do more tests. In the quick,
Should I tune the PSC_VELXY_P (I&D) to suit the target velocity I see in the logs?
I will add some experience that may help others, and it comes from another thread on similar topic Trouble with PosHold and final tuning) - the RC input dead band does matter, however it took us a minute to figure it out. Most of our pilots don’t TRIM the RC Tx when in Stabilize mode, we just fly the position, because we can’t really evaluate environmental inputs. Not trimming the Tx can cause a problem in PosHOLD mode if your dead band values are too low for whatever trim offset you have. Eg. we flew yesterday with no RC trims, entered PosHold and it drifted slightly. This, I assume, was because we were ‘commanding’ a position change on cyclic with our commanded RC PWM outside our set deadbands (RC1_DZ = 10, RC2_DZ=10). We trimmed, the Tx and flew again with zero drift. Now we either; 1) trim the Tx or 2) set the RC_DZ values higher. I’m considering just putting our RC dead band values way higher (default is 20, we may go as high as 40) to see what happens. I’d rather stick bang a position in PosHold than get this drift. For now, if we see ‘toilet bowl’ we know it isn’t RC commanded, if we see drift, we first tune the RC DZ then look at the rest.
@LoopZilla I consider toilet bowl effect to be more of a tuning issue if the phasing of the requested velocities and actual velocities are off by 90 deg or more. I’ve found in that case that add some PSC_VELXY_D helps to damp this issue and make the velocities more in phase with each other. I have also been told that the default PSC gains were designed for the default attitude command model that has max accelerations of 1100 deg/s/s. Many times in trad heli, max accels are set to 500-600 deg/s/s. So this toilet bowl effect could be due to the PSC gains being too high and it was suggested to me to cut back the PSC gains to get better performance of the position controller. I have not tried this.
There could be other causes for toilet bowl effect even if the desired and actual velocities are in phase with each other. In that case, I think this is a commanded effect due to the EKF or sensor. I am not familiar with how to fix this type of issue.
Using trim in the Tx can cause problems in many of the position stabilized flight modes. You release the pitch and roll Tx joystick and if the Tx trim is not inside of the deadband of the ardupilot controller then the aircraft will follow the commanded input. I set my deadbands pretty tight as large deadbands can become problematic when flying in stabilize or acro. They are fine for those that strictly fly in position stabilized modes like loiter or poshold as precision is not necessary as you are just setting the posiiton over the ground with the Tx pitch and roll joystick.
My recommendation is to set the TX trim to the center position and don’t touch it. Set up the aircraft in stabilize mode so that it hovers in calm winds with no drift as described in the tradheli wiki. Those more experienced with ardupilot may set trims in the RC Tx based on conditions for stabilize or acro but know that once they change to loiter or poshold, they have to move the trims back to the neutral position for the controller to hold position.
So we did more testing yesterday on PosHold, and found a magic value for our system. I’m sure it isn’t the only aspect that has helped, but it has allowed us to continue our process on this platform.
(Caveat - aircraft size matters a lot here, this is a 1.7m disk with what we consider a high disk loading - AUW with sensors is like 26lbs. Smaller size platforms or lighter disk loading have produced quite different symptoms and solutions for us.)
From my last post in this thread the main piece of information leading to our success was the PSC_TVX(Y) vs PSC_VX(Y). We were seeing a max of 0.66m/s on the target and 1.86m/s on the actual. 3x offset, so I knew something was up there (and NOT 1/2 as I mentioned last post). Accelerations looked fine. So my thinking was that I was overshooting the position, and my velocities were 3x too fast. Our PSC_VELXY_P was set to the default 1.0.
So, we went down to 0.5 on the P and 0.25 on the I, leaving D at 0. It was way worse, and the data showed a 6x offset.
Duh - the P being low was actually slowing the system down, as the math teaches us, but my brain wasn’t keeping up. So, we set the following:
PSC_VELXY_P = 3.0
PSC_VELXY_I = 1.0
PSC_VELXY_D = 0.0
And it was magic. Toilet bowl GONE. It took a second or so to settle down on the position, so we added some D, started at 0.2 and ended up at 0.4. We then decreased the I down to 0.75 and we are happy.
Now that we had it staying on a position, we increased our accelerations, braking, and IMAX to help with the transitions:
PSC_VELXY_IMAX went from 300 to 600 to a final setting of 1200.
PHLD_BRAKE_RATE went from 4 to 6 to 8 to final of 10.0
PHLD_BRAKE_ANGLE went from 800 to 1200 to 1600 to final of 2000
Finally, we tested position P to see if we could make it oscillate and back it off:
PSC_POS_XY went from 0.8 to 1.0 to 1.2 where it oscillated, but we went back to 0.8 which felt the best.
Today we completed around 20 auto landings, no toilet bowl, and it nails the position within GPS limits (0.5m or less, no RTK).
As well, per my last post, we thought the dead band was somewhat of a factor - nope. We went back and set trims at all zeros, and played with the deadband numbers for cyclic (10 to 20 to 40 to 5 to 0). We ended up putting it back to the default setting of 20 just so we wouldn’t worry about it ever again.
Now I’m happy and this platform is performing more like all of our others!
2 Likes
Sounds great @LoopZilla,
Do you have a method on how to adjust the coefficients or just hunting solution ?
Trying to solve TBS in the heli, seems that the attitude response is fine, commenced in remote tuning of I and P … with puzzling response.
First one (tune 21) went real fast to large oscillations:
Second one (tune 4) did the same…
could it be that P needs to be below 0.05 ?
Sorry if this is apparent to everyone else, but which P and I are you remote tuning? That looks familiar for the attitude controller, not the position control - but I am just guessing.
@LoopZilla you are right. I folded back to attitude tuning, those are the rate loop PID.
I started having TBS and could not figure out how to stop it, went back to the basics.
Today i sweeped P assigning Min as 0.005 and Max as 0.06 (Tuning recommended using 0.05 as a starting point).
The TBS stopped at 0.015, which is my new setting for the ATC_RAT_xxx_P.
does it sound OK ?
Following is the log from the tuning flight.
https://drive.google.com/file/d/1el_XQ2kEb-NiGMHoRFNSbC3aHSqSIKlf/view?usp=sharing
We did almost the exact same thing, after having done the attitude control testing several times. We just couldn’t make the TBS go away. Back to the basics again and again. For such a handy mode, I couldn’t seem to find enough correlative comment in the forums as to how people fix this issue, or I assume most give up (since AUTO flies so well). So, we studied and took a very systematic approach to find the issue. Test cards for days, one parameter at a time, land and look at logs. It was worth it, as we did over 25 auto landings yesterday in winds up to 20kts, and with payloads ranging from 0-10kg. We were looking for the downwash effect in landing with the heavier payloads, but never saw any ill effects.
In reference to your 0.015 for P, I am not familiar enough with what those graphs should look like for a perfect setup. I will say we tuned up to oscillation, as per the ArduCopter Tuning docs, and came down away from that. Once we did that like three times and stopped at the same number each time, we moved on from attitude control being a possible cause.
Could you fly a PosHold session again and upload that log? I may not be able to help much, but I am curious if it would look similar to what we were experiencing.
Thanks @LoopZilla,
Sounds great, Auto landing at 20 knots, I suppose the heavy load calms the heli a bit, was it gusty as well ?
I will add PosHold data later. as I’m flying in my confined back yard, and the PosHold is a bit lose, I have to manually steer the heli a lot.
I feel that the helli is sluggish commencing my commands, so probably i will have to temper with the position coefficients as well.
It is good to know that you ended up with parameters far away, as i was puzzled by this issue.
Did some flights to refine yaw, to my astonishment TBS was back. Remote P tune again, and apparently at 0.002 it stopped.
Flight characteristics are good, could fly long time in PosHold mode.
noticed intermittent whistle sound, which i previously thought was coming from the servos, seems that one of the bearing is making it, have to dismantle the main shaft, to find out.
This seems to initiate the TBS.
With the low ATC_RAT_xxx_P the TBS is minute while the whistle, and none without.
Attached my flight log:
https://drive.google.com/file/d/1jq6ezpwWY-MxPK25D_1_r3atGMtetK57/view?usp=sharing
@ZvikaF
I took a look at your log and I’m skeptical that your attitude controller is tuned well enough to allow it to follow the position controller commands to provide good position control. There are pretty consistent deviations of up to 5 deg from the desired attitude.
Based on what I have been learning from my research on attitude controller tuning, it is more important to have increased ANG_P gain than trying to get increased rate P gain. In fact my research is showing that rate P creates more of an oscillatory response rather than dampening it. Rate D gain is more important of the two because it does dampen the rotor flap regressive mode however it excites the rotor lead lag which is pretty high frequency. So there is a little bit of a tradeoff there.
So my suggestion to you is to first use the harmonic notch to remove the rotor vibrations noise in the control signals. Looks like your rotor speed is around 2400 ish RPM. I can help you with the settings if you need help.
Then zero rate PID gains and start increasing the ANG_P for pitch and roll. Take it to at least 6 if you can without seeing oscillatory behavior. A little bit of oscillation is ok but you don’t want it where it takes more than 4-5 overshoots before it dampens after making a sharp stick input. Then increase the Rate D gain until you see oscillation. Take that gain and use 50 % of that as your final value. What you should notice when adding the D gain is that the oscillation you were seeing with the Ang P (if you saw any) should subside before you start seeing an oscillation due to the D gain instability. I would expect that instability oscillation to be at a higher frequency (most likely in Roll) because I would expect you are destabilizing the lead-lag regressive, which I have seen on my heli to be around 10 hz. I don’t know what you will see with yours since it is a 450. I don’t know what frequency the instability in D gain will crop up on the pitch axis. I am doing some more testing today to look at that. I will let you know.
After you have the Ang_P and Rate D gains set then add I gain. I would not use any more that 0.15. I use 0.1 for my heli. You just want enough I gain to keep any bias between actual and desired from developing.
Hopefully this helps.
@bnsgeyer
Thanks a lot for your precious help.
Took apart the heli today dew to a bad shaped tail rotor belt drive pinion bearing, changed the component, assembled and continued with the flights.
Flight characteristics are basically the same.
The information you provided on the importance of increasing ANG_P is excellent, i will try it tomorrow by remotely sweeping the range with the RC (this is a great methode).
ANG_P is 3.8, hopefully taking down the rate P will allow the ANG P to be increased even to 6.
The rotor is about 2000 RPM, i have telemetry for it in the data, which should be correct.
I did not apply constant RPM and have the ability of changing it with one of the potentiometers in the RC. I will apply the notch filter, should i set it at 17Hz ? ( for 2000 RPM two blades)
I can back you up with the rate P and D exciting the instability.
Here is a visualisation of the instability happening with taking P up:
Data log of this flight : https://drive.google.com/file/d/17EeL-tqSJ99XYuiXo-aqHs5GSU4pG98h/view?usp=sharing
@LoopZilla, Next flight was doen in PosHold mode,takeoff to landing.
Air was somewhat calm and i was able to stay in that mode for the whole flight.
Apparently, in this mode, DeadZone of the collective stick kicks in which makes tight flying annoying a bit.
here is the flight log:
https://drive.google.com/file/d/16HBwDzbzzYhnPTzxha6EnwzUzYk4dNEZ/view?usp=sharing
Yes, that thing is all over the place. I may be reading the log wrong, but it looks like your PosHold flight was not anything like I am used to (enter PosHold, go have a coffee, take some selfies, text some friends, etc.).
For the DeadZone comment, did you mean cyclic stick? Or was your altitude hunting as well?
I totally agree with @bnsgeyer, the attitude controller needs focused attention first. But, keep uploading your logs, as I am learning with you…
@ZvikaF
Thought I would upload one of my current logs, just so you could see where we are at the moment. At least you would be able to see the differences in the way the graphs look for a particular set of values. That is not to say that this log is something to aim for (I wouldn’t presume to know enough), just to see differences.
The first part of the flight is a photogrammetry grid, so if you see everything periodic, it was. The last part of the flight is me handing the controls to our interns in PosHold, and letting them fly around, command LAND, etc. So, who knows what is in there.
https://drive.google.com/file/d/1b0olOE14Hv6UjAA68URmVUwCDvJ8xb_Y/view?usp=sharing
Maybe that will help, or at least serve as a comparative for discussion…
@LoopZilla
That’s great … thank you.
I will look into the data to try and find the clues for stability or instability.
If I may ask, What is your AP and setup ?
@LoopZilla
Awesome fidelity for the auto mode
it is hard to see your rate and attitude, as the data collected is in low rate, but it gives me some notion about the gap between the designed and actual data.
Thanks again