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

The Angle error limit - which one, at what point in the code?
Angle Error leak back to zero - What justification do you have for this? Over what time? How will you deal with the fact this will allow the aircraft to drift around and not hold attitude.
Angle rate limit - Why, how does this help anything. I think you are just adding changes for the hell of it.

You have to not only show that things directly address a problem but that they also don’t create additional (or worse) problems. Many of these issues are trade offs. We didn’t get to this point by hacking half baked ideas into the control code. I can justify every decision I have made in writing the attitude controllers, it is fair to expect the same of anybody making changes.

Now that I have the replies done.

I suspect that I am one of only a very few people that are pushing acro to a point where I regularly overwhelm the attitude controllers and cause the aircraft to blow out in one axis or another. The speed of these blow outs and the speed at which the attitude controller corrects the problem makes it impractical to expect the pilot to catch the vehicle in anything resembling the same time frame the attitude controller does.

In short, reducing the maximum angle error to 10 degrees in any axis in acro would dramatically reduce the safety of the aircraft when a blow out happens.

There are three issues here. We should be addressing each one and moving forward.

The point at which it existed before you removed it, worked well.

Over about 4-5 seconds is common. The justification, is that it solves problems if the sticks are moved before it has left the ground.

The drift should be easily taken care of by I-term. If not, then we turn it on/off with the Dynamic Flight function, same as we do for I-term leakage.

Not adding it. Returning it. It was there when I wrote the initial controller. You removed it without discussion.
And why? Large helicopters, which can’t achieve high rates. Particularly if they have horizontal or vertical stabilizers.

Ok. But you also have to show that your changes don’t cause problems for others before you make them. This keeps happening. I’ve had at least one crash, I think two, from changes that you made without discussion.

Angular Rate Limit should prevent error exceeding Angle Error Limit in normal situation.
Angle Error Limit is still needed to prevent tip over during take off
Leakage also is nice
Maybe only leak out error exceeding Angle Error Limit?

About how to return to previous angle (in case of blow out) after the aircraft regain control, IMO that’s not required when pilot is using Acro in the first place. If one wants it to, they probably have used Stabilize.

Keep in mind, angular rate is controlled in Acro mode by Acro_RP_P and the yaw is Acro_Y_P, but it affects yaw rate in all modes (yes, that’s pretty confusing).

But angular rate could be useful in Stabilize, if you whack the pitch stick from full forward to full backwards, with a horizontal stabilizer for example.

I don’t think you have experienced this. The effect is not dissimilar to being hit by a bat without warning. When flying fpv it is impossible to orientate at all until the spinning stops, if you have nothing but sky in the camera you have no idea which way to correct to bring the aircraft level. In line of sight the aircraft is back to the original orientation and flying again before even an expert pilot could orientate (for small aircraft).

This isn’t a if you want auto level fly in stabilize argument. This is a your aircraft just flipped upside down without warning in a turn 1m off the ground. Simple choice do you want to crash if so then you will appreciate the limited error design.

Leonard, why are your needs the only valid needs? You just stated, that you are probably the only person flying like this and needing this feature. Meanwhile, others of us, are saying “this does not suit us, we preferred it the way it was.” And then we are told that what we want, is wrong. You are saying that decades of research into controls engineering by other engineers is wrong, or unimportant.

It’s like when you removed the angular rate limit from having affect during a mode change from Acro to Stabilize. I told you it risks cutting off the tail on a helicopter. But you did it, changed an existing feature that somebody else wrote, without asking, and then didn’t fix it. You wanted maximum response from a multirotor to right itself. Reasonable in most cases as multirotors have more limited angular accel capability. But you didn’t consider the effect on helicopters, which have virtually unlimited angular accel capability up to the point of structural failure.

I have to say, this exact thing, is a large part of the reason I stopped developing and resigned as heli maintainer.

I have no problems with an angular rate limit to address the specific issue of the main rotor hitting the tail boom. There is heli specific rate controllers that could be used to do this without even asking me.

The issue is you are using a problem to justify changes that are unrelated to that problem. You are misrepresenting problems to exaggerate the importance of your issue. You are shutting down conversation on the actual problem because it is not leading to the outcome you desire. You are arguing to revert code without understanding the reasons it was done or the problems it solves. You are claiming crashes caused by code without logs or even a description. Finally, you are pretending that limiting the angle errors is the only solution (it isn’t the only solution or the best solution).

I have designed the attitude controller to be flexible in the way we use it. None of the issues here are a significant problem if they are handled in the right place and right way. The issue here is heli has a lot of short cuts in it that need to be cleaned up.

Before we handle problems they need to be clearly defined. We can then make discuss solutions and make changes that are a step forward not sideways or in this case backwards.

Ok, I think we’re done here.

We’ll just have to write the controller we need. No need to argue about it further.

Another unusual behavior I found on mine.
This is on custom code for dual heli but I can’t find any part of custom code that causes this.

I want to ask if this also appears on normal firmware?

Symptom: giving cyclic command while holding full rudding causes shift in phase angle.

Ok, if anybody thinks these issues are significant and is interested in finding a real solution I would like some feedback.

There seems to be a couple issues here:

  1. Swash plate tests look different with 3.4. Yes they do and there is nothing to worry about. This will look funny when testing on the ground but that is not what it was designed for. In any case be very careful interpreting swash movements with any controller engaged as the I term and angle loop will pull the swash plate in unusual directions. Apparently you can test directly by setting H_SERVO_MODE = 1. I don’t think we need to address this in the attitude controller but there may be better ways to handle the unarmed state to make it easier for pilots.

PittRBM, if you are in a stabilized mode there, your apparent change in phase angle may be because by rotating the desired frame (the ghost aircraft you are really flying) relative to the real aircraft. You will then see the outputs attempting to move the real aircraft back on top of the ghost aircraft. So for example if you pitch forward and then apply left rudder you will see the pitch axis move to the left. This is what I was saying about being very careful about how you interpret the outputs when there is a control loop between you and the servos. In flight the real and ghost aircraft stay very close to each other so you don’t see the same issues. So much depends on the mode and control loop parameters you have set.

  1. You may over power the yaw control by flying backwards in heli or quad plane. This will result in the aircraft rotating towards the wind. Depending on your settings the aircraft will rotate back again in auto and in manual modes including acro. This may be disconcerting, as your inputs will be based on the original aircraft orientation. So what behaviour do we want here when the heading error is small vs large. When the aircraft rotates to close that error do you want it to weathervane completely into the wind, to within a set angle of the wind (max error approach), or to the angle it is able to maintain with maximum output to the yaw actuator?

  2. Boom strike during hard pitch maneuvers. This is an interesting one. We have two examples here, commanded pitch and recovery from disturbance. I am not sure how many people have seen a heli flip and need to recover from a disturbance but I would be very interested to hear about how this could happen. The second question is what do we need to do to prevent a boom strike, we can limit the output, the acceleration, the rate, and the position. The closer to acceleration end the better the overall performance we can get from the aircraft. So the question, precisely what governs how close the rotor disk gets to the boom. Is the distance proportional to output, acceleration, or rate (I assume it isn’t positon). If the relationship was relatively simple a pilot could look at the aircraft from the side and put a command into the system that hits the boom strike limit in the code (whatever it is). They could then say “it only moved 30% of the way to the boom so I should be able to double the parameter X and still have a margin of 40%”.

  3. Heli is not handling the initialisation of the modes properly. This means the pilot is able to build up I terms by exciting the controller when it isn’t flying. This can result in a prop strike during take off. With proper initialisation in the heli code this should not be a problem unless someone is leaning on the sticks during take off in which case the pilot commanded the prop strike.

  4. While there has been a lot of discussion about adding the error constraint back into the attitude controller there has not been any indication of a problem the current implementation has caused other than to highlight the 2. issue with the heli and quad plane input shaping code. In all the discussion above I can’t see any complaint or issue that has been raised that is caused by this part of the code.

if you have any input thoughts or opinions on the issues above I would be very interested in hearing them. Please take the time to precisely describe how your issue or problem happens, what you think the reaction should be. Then it is always a good idea to think about ways in which your desired reaction could be a problem in other flight states.

I have seen too many problems fixed at the cost of creating 5 more.

2 Likes

I would like to let you know that a day before I moved house to a new address I did a test flight with a just loaded FW AC 3.4.5 . There was just a calm day for it. The Heli crashed in Pos Hold unexpectedly.
My camera underneath survived and revealed that the motor stopped in mid flight. The log file showed crash detection in mid-flight.
It is not impossible that I had a servo problem but don’t know it yet.
The new house is still a mess and I have no time to start my hobby again for a wile.
One thing to Rob L replies to you.
I do not like his style of response to your thoughts and explanation. That’s all for a wile from me.

This is what I THINK is the main problem.

It is a common safety practice to check servo operation by moving sticks in every direction before take off.
This will screw up virtual frame orientation.

There are people around the world using your code and you can’t expect all of them to handle this properly.

What Rob suggested may not be the best solution but they are most practical.
The best? solution is to lock the vitual frame whenever the real aircraft can’t get to the desired angle, is that possible?

Also people react differently, imagine someone lost control then panicked and start swirling their stick around

You should see what I did to my transmitter the day I got belt static build up.

That’s what used to happen. The “ghost aircraft” couldn’t be more than 10 degrees in any direction from the current aircraft.

So how will it be different in real life, in the air, if I am flying a high powered high performance helicopter, at 140 km/h, and I attempt to do a pirouette. As the boom passes 90° to the flight path it CANNOT maintain the desired yaw rate. This is normal, and is not a tuning error. It is a physical limitation.

The “ghost” aircraft will not be lined up with the real aircraft, and roll errors become pitch errors?

Did you consider how this change would conflict with the Pirouette Compensation code in Heli?

Hi Fred,

Sorry about your crash.

I believe Tridge has looked at this and has added additional checks to ensure this doesn’t happen. Did you post your logs somewhere? I would like to check to make sure this is not still a problem.

Hi PittRBM,

Yeh. I would also want to check the servos before flight and Acro would be an obvious choice. In Copter we always reset the ghost before arming and in doing so ensure there is no I term build up or mismatch between real and ghost. Limiting the error between real and ghost does not prevent I term build up and would not stop the rotor disk hitting the ground.

I suspect that you should not be able to run any controller in the disarmed and pre-spool-up states and your stick outputs should map directly to the maximum throws of the roll, pitch, yaw, and collective output to the mixers. That would enable the pilot to check the servo throws and connections without fear of anything bad happening. The attitude controllers should only kick in when the aircraft may take off. At this point if the pilot gives a command to roll over the aircraft should roll over and put the disk into the dirt if instructed.

Hopefully this will mean there is a clear process that everybody can use, new or experienced, that does not have traps set for people that attempt to deviate from the path.

Is there anything I am missing here. What I have said seems obvious but does not appear to have been done and I assume it is for a good reason or to avoid a particular problem.

I believe a better choice would be to ensure all the initialisation features used in copter are present in heli. I have been working to add features to copter that enable things like spool up states and servo feed through. So hopefully you are able to check the servo movement before spooling up and not excite the attitude controller. These differences between heli and copter are one of the main reason heli is so hard to maintain. Randy and I have already removed much of the heli specific code from the body of Arducopter, I think it is mainly the heli frame in the motors library that needs to be brought up to speed. While I was comfortable to bring all the other frames up to speed Heli is much more complicated and messier. It also requires a deeper knowledge of the code and an understanding of all the little problems and issues that have been avoided and worked around to do the job correctly. It will take me quite a while and a lot of discussion with people before I am comfortable to work on Heli myself.

Coincidentally the attitude controller makes the heli library look like a tic-tac-toe game next to Chess or Go. That is why there are a number of ways to address problems and many more ways of creating them. It is easy to see ways of fixing a problem but much harder to see all the ways that fix can create problems. This is why I insist on a thorough description of the problems, discussion of the possible solutions before attempting to work out the best changes in the code.

To answer your questions (and maybe ask a couple):

I assume you are doing this with the rotor head stationary and not spooled up, is that right? If it was spooled up you would see the whole disk tilt to match the ghost and the error would stay small anyway.

I completely agree. I hope that the initialisation stuff present in copter but missing in Heli would take care of that as I described above.

The problem with this approach is the real aircraft is always a little way from the desired angle. How do we define “unable to reach the desired angle”. More than 10 degrees, maximum output, moving away from the desired angle? Each of these creates different problems from reduced ability to fight a disturbance to jerky movement or potentially complete loss of control. For example if we limited the pitch error to 10 degrees but during forward flight you needed an 11 degree error before the attitude controller would fight hard enough to overcome the pitch up moment. In that case it is a race between the I term limited by Imax and the time it takes to rotate upside down and crash. There are better, easier, safer places to implement these things that I built into the code. We just need to have the discussion so we understand the desired behaviour across all similar situations.

I do appreciate that but from the attitude controllers perspective all it is doing is following that stick swirling as closely as possible given the information it has. Loss of control from the pilot is often not loss of control from the attitude controller. If the attitude controller loses control of roll or pitch then the pilot has no hope. The narrow margin between these points is when the attitude controller briefly loses control of roll or pitch and then regains it again and is working to close the very temporary error between ghost and real. If it wasn’t temporary the aircraft is gone anyway. Stick swirling or not the error should be very quickly reduced to near zero and the pilot inputs should be directly reflected in the aircraft response again.

I hope that explains things…

That is correct and I consider it a serious issue. It can result in the pilots inputs not matching the aircraft axis. This is exactly the problem I would like to discuss. Unfortunately you don’t seem to be able to get past the “we already had a solution, just limit the error to 10 degrees for everything” argument.

I don’t have to. That is not a feature supported in the attitude controller and should be handled by the heli library. The heli library has access to both the ghost attitude and the real attitude so I don’t see what the attitude controller has to do with it. If the Pirouette Compensation code in Heli is affected by the attitude controller then it is using the attitude controller incorrectly and needs to be fixed. The attitude controller has worked on a ghost and real concept since my first rewrite.

I’m thinking about situation such as
1.Sitting on the ground
2.Heavy Weathervaning effect
3.Grabbed by a bird?
4.Servo(s) decided to sleep for a few seconds for whatever reason.
5.Future features that can temporary overwrite orientation?

During these situations (loss of control),some pilot may panic and start swirling stick, if the aircraft eventually breaks free, the target orientation is simply randomized.
If I were to be in this situation, I prefer my heli to stay at the angle it got released.

Aside from the contentious issues of how to handle some of unique concerns with helicopters, this has been very educational on what decisions went into the design of the attitude controller and past changes for the unique concerns with helicopters. I don’t have the experience with RC helicopters (at least in highly dynamic flight) to speak to some of the issues presented here. I do agree that some of the issues with how users test the control system before flight and the ground/air transition should not affect the attitude controller design in flight. The use of leaky integrator or leaky attitude can be used to address air/ground transition issues but can cause undesirable drift in attitude in flight. Unfortunately, it sounds like air/ground transition is difficult to determine especially when this code is supporting multiple configurations both multicopter and helicopter with unknown user setups.

Obviously I will hold off on proposing any changes to the attitude controller because there is more to consider than I originally expected.

@PittRBM you had asked about a potential project for GSOC. I think working with the appropriate developer on handling air/ground transition and initial flight checks for Trad Heli might be a good project.

The current traditional helicopter firmware version of the Acro mode pilot control feel, for aileron system FBL / DFC structure, the control feel really bad. In the Acro mode, if there is no RC helicopter flight basic skills, it is difficult to control the aircraft stability. In the aileron helicopter rotor head structure, because the aileron mechanical stability, control better; but to the aileron structure of the helicopter, the control is very easy. The traditional such as Vbar, MB and other FBL system, control the feel and the ability to maintain stability of the body much better. I really hope that the firmware update can greatly draw on the control of the FBL system feel, then the Acro model is a very effective emergency mode and special conditions under the flight control of the direct control mode.