Unusual swashplate behavior using AC 3.4.5 in ACRO with full cyclic input

I don’t have a good answer other than, we never got around to it, because it was less important than the auto-throttle/collective modes.

Heli should have a mini state-machine to handle the resetting of yaw. It is only activated when it’s first armed. Once it makes it out of it, it doesn’t go back.

Hello,

Is the main problem fixed in version 3.4.6? I found this “bug” last year and published it on github but without any answer:

I found this problem during a flight with this machine:

Not so funny in the air :-).

Greetings
Fabian

This is the bug that Leonard and I argued over.

A few of us are working on a fix for it. Not sure if it will ever end up in master or not.

Hi Rob,

good to know. I was reading the whole topic here 15 minutes ago… so now Im informed.

And sometimes a little bit of bad mood here… so guys: relax ;-).

Greetings
Fabi

PS: One day I wanna fly this helicopter with pixhawk power… a big step at the moment :-). (The little heli at the left side is a T-Rex 550).

Hi all,
I was just going over the code to look at limiting the yaw error and I found that it has never been taken out. The form of the error limitation is a little different in that it lets the error get large enough where it won’t ask for dangerous accelerations from the controller rather than a simple angle error. This approach is a little more flexible but still not as generic as I would like.

So the current yaw error limitation is: 120 / angle_yaw.kP

This limits the acceleration on the controller to 120 degrees per second per second. A pretty low number. So depending on the value of your angle_yaw.kP it could be larger or smaller.

I think the approach I suggested is more thorough and works better on a larger range of vehicles so I will look at implementing that.

If I could get help answering questions in a constructive way that would be great. http://discuss.ardupilot.org/t/trad-heli-attitude-controller-requirements-help-requested

Hi!
I know this is an old thread, but I’m experiencing the same problem as described by the threadstarter in the beginning. I’m running Copter 3.5.5. When I arm the helicopter and basically simulate a flight on the bench (with the ESC disconnected) and I put in full right cyclic, then the swashplate tilts to the right (as expected) and after a while (still holding the stick) the Swashplate flips over to the left and after a while starts to act completely crazy. I’ve read the thread carefully, so I know, that this problem is caused by the ghost helicopter moving around freely and the real helicopter not being able to track it (because it’s on the bench of course). But here is my question which I’m concerned about and which hasn’t been discussed jet I think:

Imagine a large scale helicopter in fast forward flight. It’s creating a strong pitch up moment due to dissymmetry of lift in forward flight. Also it has a horizontal stabilizer which creates a downforce that increases the pitch up tendency. Now the I-term will build up until it reaches IMAX. Assumed your IMAX is not very high it definitely is possible that the pilot has to counteract this force to prevent the helicopter from pitching up and slowing down. So there is an error built up between the ghost helicopter and the real helicopter.

Actually this isn’t a problem and when the helicopter slows down, the real heli and the ghost will align again. But what if the error rises above 180°? (I’m not sure if this is likely to happen in this kind of situation, but it could be, right?) Than the swashplate will snap over and suddenly flip the helicopter nose up. I’m pretty sure the model can’t handle the mechanical loads in this situation and will be destroyed.

Would it be possible to implement something in the code that prevents the swashplate just to flip over? Or maybe implement a new parameter that can switch this functionality on and off? As I understand Leonard, fast recovery could be really important for small multicopters, but for large traditional helicopters in fast forward flight conditions flipping over of the swashplate is definitely undesirable.

Leonard had asked for a log to prove this is a problem. I attempted it by flying one of my big gassers that has a lot of power to Vne during cert testing for my operating certificate until it nosed up and ran out of left aileron. But was unsuccessful in producing the log he wanted.

Bill and Leonard talked about limiting the ghost error but at this point it is a low-priority issue until it is proven to be a real world problem, so I’m not sure of the status of that. Nobody has proved that they can get it to happen in flight yet.

Thank you very much for the explanation!
So maybe this problem is depending on a lot of parameters which make it difficult to prove that it really can happen. But if it does, it could (and probably will) destroy the helicopter.

Actually I’m experimenting with some sort of modified horizontal stabilizer, so I guess it could be a real problem in my configuration. Or just imagine a loosened battery pack moving around in the helicopter. The pilot fights the sudden force and the ghost starts to deviate from the real helicopter.

So the feature of the flipping swashplate brings a potential risk to the helicopter (which could result in a total loss of the aircraft) without a benefit for large helicopters. I understand what Leonard is trying to achieve for small multicopters e.g. for FPV use. But I think it’s something else in trad. helicopters especially large ones. As a pilot I want to be sure that if I move the cyclic to the right the helicopter rolls right (and not suddenly to the left with max swash deflection). So the possibility to turn it off (e.g. by limiting the ghost error to 180°) would be a huge help. Then you could be sure that the helicopter flies safe. At least for me, safety is always the first thing to consider and if there are any concerns about it, one should take it very seriously whether the problem is proven to happen or not.

Felix,
It would be unlikely with a traditional helicopter that you could cause the ghost to get that far away from the actual aircraft, unless your aircraft is very poorly tuned. The big concern with traditional helicopter is when the aircraft is on the ground because control inputs can be made but the aircraft can’t respond because its on deck and so the ghost can get away from the aircraft attitude. This is tends to take care of itself because most heli pilots know that you don’t make large stick inputs when on the ground with rotors turning. Once we see the aircraft moving, the pilot is on the controls correcting.

As for your experimental horizontal stab, that could cause an issue. Now there is another control in the pitch axis that can fight the rotor. Typically this is not an issue with a fixed tailplane but I could see it potentially being an issue if the horizontal stab is being controlled and it is not part of the Attitude controller. Still I think the rotor is powerful enough to make the necessary moments to keep the aircraft matched to the ghost. Again it depends a lot on your tuning. Keep us posted.

Thanks
Bill

It may for a RC heli. In full size the horizontal stab is there to stabilize the heli in cruise flight and provide some lift on the tail to reduce pilot workload because the main rotor is normally tipped slightly ahead so the heli’s frame cruises nose on the horizon. The result is that they hover nose high.

That is not normally done in the design of RC heli’s so it’s going to be fighting it unless the horizontal stab’s AoA is adjusted to stabilize at the frame angle the heli cruises at (normally ~5-7 degrees nose down with my heli’s).

Yes, that might be true. I don’t know how far the ghost will get away in a well tuned heli. I’m going to use high IMAX-Values, so the problem hopefully doesn’t appear. At least I can look at the logs closely and see if I’m anywhere near it…

And yes again. I’ve read here

that the ghost is released after arming and turning on the motor interlock switch the first time. So this shouldn’t be a problem anymore.

But I think the problem with the horizontal stab – modified or not – still exists. In full size helicopters the horizontal stabilizer produces a downforce to keep it in a stable flight condition. If the pilot lets go of the stick, the helicopter slows down by itself. It’s basically an upside down airfoil…

I’ve noticed another problem in my bench test: When I switch back to stabilize after “flying” around in acro, the swashplate shows some pitch movements when I’m only commanding roll and vice versa. I guess that’s also because of the ghost not being aligned with the real helicopter and not something to worry about, right?

I’ll keep you updated.

From what I remember from that thread and other conversations, I think it was not more than 15 deg. I believe @Rob_Lefebvre had mentioned that. Like Chris, he had done some flights to see if he could make the ghost deviate from the actual aircraft.

So what is your plan for horizontal stab experimentation? With the flight modes that arducopter provides, I don’t see much of a need for a horizontal tail. What you describe above for full scale helicopters is classical flying qualities in the absence of advanced flight control laws. Once you put an attitude hold system on the aircraft, ideas like static longitudinal stability go away because the system is now designed to hold attitude. if the aircraft is disturbed, the flight control system works to return back to the trimmed attitude. If you make an input then you change the reference and it now holds a new attitude. Acro is basically a rate command attitude hold flight mode and stabilize is an attitude command, attitude hold flight mode. So a modified fixed horizontal tail will certainly help the autopilot, but this will probably be pretty transparent to the pilot.
Just my thoughts.

So these pitch movements with roll control only occur after you go back to stabilize after you’ve been in acro? or do they occur in stabilize even before you’ve gone to acro? So there is logic in the code that adjusts pitch and roll based on heading. I would have to go back and look at this snipet to see what it is actually doing but this may be causing it. But I’m not sure. This is a pretty complex control system.

Hi Bill!
Thanks for your detailed answer. Ok, if we’re talking about something like 15 deg it should be safe enough to give it a try and see, where I actually am with my configuration.

I totally agree with that. I’m not trying to improve flight characteristics of my rc-helicopter. I’m just using it as a testbed for some aerodynamic experiments I’d like to do with the new stab. So the flight modes arducopter provides are actually just perfect for it. Especially because I can see what the controller is doing (servopositions etc.).

Yes, it’s only after I’ve been in acro. When I arm in stabilize and stay there, the movements are exactly as commanded. But when I go to acro, move the stick around a bit (actually it is sufficient to just command e.g. roll) and go back to stabilize then the phenomenon occurs. It doesn’t look like just a phase shifting in the controls. It’s more like a wave: When I move the stick to the right, it also makes a pitch movement but goes to neutral again. (Of course roll stays there as I hold the stick to the right.) And when I then centre the stick again, roll is centered as expected, but it again makes a strange pitch correction (this time in the other direction) and goes back to neutral.

I’ve noticed a problem in my setup. I think it doesn’t have to do something with the described pich movements when roll is commanded. But just to be sure…

The cyclic deflections of my swashplate are not symmetrical. I can measure 6.2 deg when I roll to the right and 8.4 deg with roll left. Of course I checked it on 0 deg of collective and also with H_COL_MID set very precisely. It doesn’t have something to do with my mechanical setup because all my servo arms are perfectly horizontal and also I can see in the servo monitor of Mission Planner that my Pixhawk is commanding a greater servo travel to the left than to the right. Of course I had to make some adjustments to the servo trims in ardupilot. They look like this:
SERVO1_TRIM,1542
SERVO2_TRIM,1580
SERVO3_TRIM,1480
(Servo 1 is left, 2 right and 3 on the rear.)
Could this cause the problem? E.g. ardupilot is trying to prevent the servos from binding? But in reality there is enough space for the movements.

Felix, are you performing this check with the swashplate in manual mode (H_SV_MAN=1)?

Hi Bill!
Thank you for your fast reply! Yes, I’m performing the check in manual mode. Sorry I forgot to mention that.

So you adjusted your servo trims so that the swashplate was level and thus perpendicular to the shaft. 6.3 to 8.4 is a big difference. What is the pwm difference with full left cyclic and full right cyclic?
Truthfully I have never looked at this like you are doing. I set up the head making sure the swashplate is perpendicular to the shaft using the servo trims and really don’t check cyclic. I have never had an issue.

Actually I adjusted the servo trims so that all servo arms were perfectly horizontal. (Couldn’t get the trim values smaller, because of the mechanical restrictions of the servos and levers.) Then I adjusted the mechanical links to the swashplate so that it was level (or at least almost level, because I can’t do half or quarter turns on the ball links. Finally I corrected the trim values a tiny little bit to achieve a perfectly level swash plate. I used a swash leveling tool to be sure it’s perpendicular to the shaft.

What could also be important is that the swash is only moving about ¾ of the way of the stick. When the stick is near the endpoints the swash doesn’t move at all. But I guess that’s ok. I also redid the rc-calibration (over and over again), but this doesn’t help.

The PWM values Pixhawk is commanding in manual mode are:
Stick: left middle right
Servo1: 1290 1534 1744
Servo2: 1322 1580 1775

Especially on servo2 you can see it. From mid stick to full left there is a difference of 258 microseconds, but to full right it’s only a value of 195. Maybe you’re right and it doesn’t matter, but I’m always trying to do my whole setup very carefully, because I know it can help a lot to get the best out of the helicopter.

With the servo trims set that much different, the head is not geometrically perfect. If the head geometry was perfect all three servos would be at 1500 pwm with the swash level and blades at zero pitch, and the angle between the servo horns and swash links would all be the same.

Depending on what you have the servo directions set to, Pixhawk is already putting out higher pwm value on one side in a static condition with the swash mechanically leveled due to the trims being that far off.

If it was me, I’d center the servos at 1500 and make sure the angle between the horn and links was all identical, then level the swash and zero the pitch mechanically with the turnbuckles instead of doing it in software. You can certainly do what you have done in the software, but the heli won’t fly perfect because those actuators travel in an arc. They are not linear. And the difference will show up at maximum travel.

If you would put two dial indicators on the swash links for servos 1 & 2 you will likely see what the problem is.