Its a new feature, were still learning if the thresholds are correct, can you share a log. We should be able to tell if its a genuine issue or the warning is happening too soon.
@jinchengde this will probably be very common for heli users because the tail rotor thrust will change based on collective so the amount of yaw input required changes whether you are in a hover or in forward flight.
As @iampete points out, we are still determining what a good threshold might be. I think for heli users, it could point out which users have not mechanically trimmed the tail rotor for hover. If you are an experienced arducopter heli user, then you may choose to just disable the warning by setting bit 1 to zero for the FLIGHT_OPTIONS parameter.
@iampete I definitely think the tolerance is too tight for heli’s. I would propose that this more so alert heli pilots that the control is nearly saturated ( > 80% in one direction) in trim conditions. This is not so much about having the yaw trim centered as the yaw trim point moves during flight. It is ensuring the pilot doesn’t run out of control authority.
How does this determine the imbalance?
Yaw imbalance is most often caused by motor mounts that are slightly twisted on round arms. Sometimes it is caused by arm or even frame flex. There’s also been CW and CCW props that are not created equal and produce different thrust, and hence affect torque and load.
You can start by visually checking if all the props are spinning in exactly the same plane and none are tilted -> each prop tip should point at the next props tip.
This quick visual inspection could be followed up with something more scientific, like maybe using a straight edge to set the motor mounts all straight and level.
Having the yaw not imbalanced allows for better yaw control and more headroom for stability control.
Shawn,
Thanks. That all makes sense. Single main rotor/ tail rotor heli’s are a different breed. I was just curious how @iampete determines the imbalance in the code. Does he use the trim yaw out or the integrator?
Its all done on the yaw I value. One threshold is 75% of IMAX. I suspect the second threshold is the one the is causing the issues it just a fixed value of 0.1. The roll pitch and yaw contributions are in the range -1 to 1. So having 10% throttle fighting yaw seamed like a reasonable threshold.
There area few things to do, the first is to get our hands on a log of it triggering and check there is not a genuine yaw imbalance that should be fixed. Secondly we could raise the fixed warning or just remove it.
I’m not 100% sure if the 0.1 yaw I term being equal to 10% throttle applies to helis, and I guess they would have a ‘yaw imbalance’ by nature anyway, maybe we should use a larger value for them in anycase, we could always have one value on copter and a second for heli.
For a quad copter that may be reasonable. However if you’re talking about like maybe a quad plane that has vertical tails, the aircraft may have to use more yaw control in crosswinds to maintain a hover. Which is the similar case for helicopters with a tail rotor as they will require more yaw input to hold a hover in crosswinds. In addition as I said earlier, changes in forward flight speed also cause changes in yaw or tail rotor requirements.
Agreed. let me look at real heli data. My initial thought for heli’s would be to get rid of the 10% warning and keep the 75% IMAX warning.
Based on PR https://github.com/ArduPilot/ardupilot/pull/17574 (which will be included in -beta4 probably next week) I think we’ve resolved this issue now right? I’ll move it to the “resolved” pile but please tell me if I’ve got this wrong and/or the problem comes back.
It might be good to post an onboard log file so we can be sure it is a real problem. But otherwise the cause is normally a hardware issue. Perhaps an angled motor, a propeller spinning in the wrong direction (on a copter with many motors).