Limiting error between attitude controller target (ghost) and aircraft attitude in Trad Heli

I don’t claim to be an expert or even proficient with quaternions but I have spent a lot of time trying to understand the attitude controller. The angle error is determined as difference in Euler angles. This error is determined in the thrust_heading_rotation_angles routine. If you look at that code you will see that an angle limit was already there for the yaw axis. It was easy to just follow the same logic in limiting pitch and roll.
Were you planning to apply on limit to all three axes or break out pitch and roll and use one limit on them and another limit on yaw. From what I can tell you would have to determine the rotation from the target to the actual aircraft attitude and then limit beyond a certain rotation. I guess you could make it simpler by staying in the quaternions but it has to be done in the correct part of the attitude controller which is what I learned the hard way.
I will definitely be interested to see how it’s done with just quaternions. I know that I’m just scratching the surface. :grimacing:

Yes, and that’s the reason the EKF blew when my tail servo failed. The resultant spin and tumble caused severe spikes in the x and y axis vibrations that aliased the IMU’s and it lost attitude control.

What I’m trying to figure out is how anybody can generate a real-world log showing the ghost error to be huge that @Leonardthall wanted to look at. Bill suggested it could happen in an out of control situation where the pilot is trying to regain control. That is what I had happen, even though it was in a different flight mode.

The part I don’t understand is:

  1. we need to limit the ghost error from the current attitude
  2. current attitude is determined by the EKF state estimator in all flight modes
  3. the ghost will be limited to say 10 degrees from current attitude
  4. current attitude may be wrong if the EKF can’t handle the out-of-control situation

So what would one have to do to produce that log that Leonard would like to see? I’m willing to try to produce a log like that if I knew what I had to do. I have a 500 stretch pylon racer that I could refit with a Pixhawk and have my friend, Dave, fly it in hard 3D to see if it can handle it. But my gut instinct is the EKF will give out and current attitude will go bonkers before the ghost error diverges. Just a simple tic-toc will instantly blow the EKF due to the accelerations experienced by the IMU’s interpreting them as severe vibration. And then you have no attitude controller at all.

I think this was Leonard’s point, and it’s a good one - prove that it’s actually broken. But how?

Chris,
I think the other thing that should be considered is how much acceleration should the controller be allowed to apply to the aircraft. I know the feedforward is limited by the max accel parameter but is the rate applied due to the attitude error limited? From what I can tell, I don’t think it is. That would be my argument that maybe there is some finite angle the controlller is limited to protect the aircraft from a controller request that could damage the aircraft.

I do not know that. I thought the angular acceleration limits applied at all times. But maybe they don’t. That would be a concern.

we can use a simulator where we have perfect sensors. I tried to do that with the Raptor720 heli in RF8, but I wasn’t able to produce a problem.

Immmmmmm baaaaacccckkkkkkk :smile:

Hi all,

Everybody knows my opinion on liming the ghost relative to the aircraft so I won’t go into it unless somebody wants to ask questions on exactly how the attitude controller works.

But I have a list of features I want to add to the controller to facilitate experimentation and flexibility. (just because they are available does not mean we should use them :open_mouth: )
Maximum angle error based on output saturation.
Maximum angle error specified by the user
Maximum correction rate specified by the user
Maximum output to the mixers.

I need to go over all our conversations and make sure I can support all the features we need to deal with the start up phases of heli. So I will probably need some I term handling as well. I am sure there are a few more. It would be great if you could chime in if there is something you think I have missed.

Another thing I intend to do is separate the output of the feed forward terms from the PID terms. I suspect we should be scaling them differently on the input to the mixers. In general the feedforward term should be linear and PID square rooted for single and coax copters and I suspect heli’s too (but I will need help here). For multi’s the feed forward should be squared and PID linear. More thought needed here though.

1 Like

Hi Leonard! Glad to have you back!

I’m not sure how much we want the user specifying this so I would shy away from 2 and 3. Plus in specifying angle error there is no basis for the limit other than what the user thinks it should be. It makes sense that this should either be limited by the maximum output to the mixers (because that is all the control authority available) or maximum angle error based on output saturation. I’m not sure quite how 1 and 4 are different. I would guess that in number 4 you would feed back the limit of the mixers to the attitude controller to slow the rate request and the ghost. In number 1, does the rate addition due to angle error get included in the calculation of where the ghost is?
The only other limit would be limit angle error (and subsequently rate request) based on max acceleration which is what I think you do now with the yaw axis. The big question there is how do you determine what that acceleration limit should be. It could be based on the acceleration limit the user specifies in setting up the aircraft.

What I’m failing to see is how the start up phases play into what you have discussed above.

So I have not figured out why the square root factor is used. After our discussions on the attitude controller, I’m assuming this handles the nonlinearities in controlling multicopters. Yet the square root controller is tied to a smoothing gain set by the RC_feel parameter. We should have a discussion on this, maybe skype. I think your idea is to remove the nonlinear effects in the control response so that a rate request input made by the autopilot can be linearly mapped to a rate response? So to compare a multicopter to a heli, your control scheme used to linearize multicopter response would only work on the yaw and heave axis of a heli since they are effectively using the same method to create force/moments (thrust). However, I would think constant speed, variable pitch systems may behave differently than variable speed, fixed pitch but I don’t have any data on that. Now in the pitch and roll axis, moments are created through cyclic blade pitch. The resulting blade flapping causes two types of moments, one due to the thrust vector offset from the CG and the other due to head stiffness (either due to hingeless head design or a teetering head with at stiff dampener). So I don’t know if the square root controller would apply here.

As I said, I think this would be best discussed in person.

@bnsgeyer

I agree on the

Bill. As a default they will be set to no angle error limit but the user will be able to choose between a defined limit and limiting based on output saturation and this is what I would recommend to the Heli yaw controller and quad plane. At the moment I am thinking 0 is no limit and anything above zero will be the minimum of the saturated limit and that number.

People will use incorrectly to address yaw overshoot caused by high rates and poor yaw acceleration ability but that is life.

It will also be used to keep the ghost close to the real aircraft because that idea spooks people out but that will create a slower correction in the case of a flip or large attitude disturbance. In some cases that may be desirable though.

Again this will be set to be off but it is nice for larger aircraft that are carrying gimbals to limit the maximum roll or pitch rate when rotating from left to right. It is also critical for optical flow to ensure the sensor can follow the ground movement.

Again this will be set to be off but it is useful for preventing multirotor aircraft from stalling propellers during fast forward flight and getting control reversal.

I will not be encouraging people to mess with either of these parameters or even publicizing them widely. I have already added maximum rate and will look at limiting the yaw based on output saturation next. The other axis and functions will take longer.

Yes, the idea is that any limit in the controller will set the maximum rate and angle error and therefore ghost position that results in the current output at saturation. This is pretty easy in a single axis controller so I will do it first in the yaw controller and then Alt_Hold. Then I will do it in the 2 axis position controller and finally the quaternion controller for the thrust vector.

Yes, it will limit the maximum rate request but also the angle error and therefore the ghost postion.

So you can limit the output to the roll and pitch mixers to ensure the aircraft settles onto the ground or does not immediately snap level.
You can use the maximum altitude limit to keep the ghost near the current attitude. I personally think that keeping the ghost locked and I term zero will be the way to go but we could also limit the error (and therefore ghost) based on output saturation with the I term kept zero.
Maximum velocity is not relevant here.

The last point has nothing to do with the square root controller but instead the relation of actuator output to acceleration and velocity. I will need to implement this for single and coax copter anyway so it will have to get done. I suspect that heli will benefit from it too but we will need to do some characterisation work first. In any case this is still some time away. In any case that was a side note about tuning, not really relevant. Sorry. But that brings me to another thing. I have pretty much finalised the types and implementation of the system characterisation stuff. So I think I can get that done with the implementation of the Rate controller clean up.

So just to directly address some of the issues talked abou there:

This is the wrong way of thinking about this. In reality, when control is regained, the aircraft tracks the ghost not the other way round. And the ghost is the desired attitude. If a pilot is flying and actively correcting the aircraft in acro when the aircraft is out of control, neither the ghost or the heli are the same as the pilots desired attitude. Because the aircraft is out of control nothing can be done about it.
If the aircraft is in stabilize or alt_hold then the ghost is always equal to the pilots desired attitude no matter what happens to the aircraft attitude (although limiting attitude error will make this statement false).

I have asked if anybody can show a log, real or simulated, that demonstrates a situation where the roll and pitch attitude can be significantly different from the actual aircraft. Also, nobody has pointed to a mechanism where the attitude controller is unable to keep the aircraft on the ghost but the pilot’s inputs are able to control the aircraft. This is not an engineering argument but instead based entirely on an emotional argument. The most basic demonstration of this is the output of the attitude controller has saturated the swash movement trying to level the aircraft, there is nothing the pilot’s inputs can do. Even if you went full manual, the pilot would saturate the swash range and the aircraft would continue to roll/pitch out of control. If the aircraft is controllable then the attitude of the aircraft and ghost are very close.

Exactly!!

Exactly!!

This is where

and

come in. There already is maximum requested acceleration there.

So the requested acceleration is limited. You can get a higher acceleration by forcing the aircraft into a different attitude then letting go. The only way to limit this acceleration is to limit the output to the swash.

So to give an example. You have a heli hovering level. you have a string tied to the end of the tail. You pull on the tail until the aircraft has maxed out it’s pitch output to the swash. So you are in a situation where the aircraft is almost level but with full forward pitch. Then you let go of the string. There is nothing the controller can do because it can’t predict that you will let go of the string and it can’t instantaneously move the swash. In this situation the only way to limit the resultant acceleration is to limit the movement of the swash in pitch.

So yes, the aircraft can experience a higher acceleration but only when an external disturbance suddenly adds or removes a force on the aircraft.

Maybe a reason for the confusion here is that people are getting mixed up with “stabilization” and “attitude control”. Stabilization is easy because you simply feed some stick input to counter any movement in the airframe. You don’t need a ghost because you are relying on the pilot to do all the work and the stabilization is just helping deal with some drift and reacting to sudden disturbances for a fraction of a second. In this situation the pilot commands 75% of the output to the swash. This is like flying next to your instructor in a real heli and have him hold the stick and add a little pressure here and there to correct for things you missed.

In “attitude control” there needs to be a reference, the ghost, that the pid loops are working to achieve with the airframe. Here the pilot does not send any commands to the swash, the pilot only controls the ghost. Here the attitude controller has 100% of the output to the swash. Even when the pilot has a rate input that effectively goes directly to the swash via the feed forward in the rate loop, there is no more control authority left for the pilot’s input to use when the aircraft has lost control. In this situation the ghost IS the pilot and the person on the ground is just giving instructions. The goal is to make sure the Ghost is the better pilot.

  • If the aircraft is controllable, the ghost and aircraft will be very close to each other.
  • If the aircraft and ghost are far apart the full defection of the swash is not enough to maintain control and therefore any input from the pilot to correct the disturbance will not do anything other than make things worse.
  • If the aircraft becomes controllable there will be a fraction of a second where the aircraft will return to the ghost attitude. After this fraction of a second everything will make sense.

Currently the discussion to limit the attitude error (and therefore the difference between the ghost and real aircraft) has focused on the “fraction of a second” for a gun pilot flying in ACRO. A “fraction of a second” that nobody can demonstrate in reality or simulation.

I will eventually limit the attitude error in the quaternion controller but I will do it first in the yaw, altitude and finally the position controller because there is a demonstrable need and justification. I can think of a couple of valid reasons someone may want to limit the attitude controller error so I will do that too but it is not a priority.

Again, I am stoked about the work you are all doing on Heli. Don’t take my long reply as negative in any way!!

This is where I was at when I lost the yaw servo in my 626. The heli was in auto at a fairly high flight speed when the yaw servo went full travel to the left and failed. Honestly, I don’t even remember or know what I did to get it back under control. But it flipped and I know I went for Acro flight mode, got Stabilize by accident, got it upright in a wild spin and managed to fight it in a little closer to me where I had better visual reference. I finally shut down the motor in a spin, which allowed me to autorotate the thing and land it without damage.

Thru all this, I don’t think the attitude controller itself caused any problem, and I think the Stabilize controller helped get it more stabilized upright where if I had actually gotten Acro I likely would’ve crashed it. The attitude estimate was off because the EKF didn’t like what happened in the severe vibration/acceleration levels experienced in the unusual flight attitude. But I was still able to control it and make it do what I wanted - kind of. I don’t even know if I could duplicate it because it was ~1 minute and a few seconds of intense focus in the fight with an uncontrollable machine. So I’m kind of wondering if we aren’t looking at the extreme theoretical here, when in reality the performance of the attitude controller probably exceeds the skill level of even the best pilots?

Let me know what you need to characterize this for tradheli. I would be happy to help.

You confused me here. Finalized what types and implementation of characterization stuff? Please explain.
Thanks!
Bill

Yeh, emergency reaction is best to go with Stab because it will keep the thrust vector vertical. If the aircraft is moving the way I suspect it was then I can almost guarantee it was the attitude controller that got it level… ish. It is probably a good indication that there are not any videos on youtube showing a heli with a lost yaw servo being landed. With simple mode it would have made it a little easier for you. Provided the EKF is hanging in there the attitude controller can handle a fast spin.

So I am looking at providing a number of excitation signals:
Chirp function
Sinusoide stepped in frequency
Maximal length BPSK sequence

I may also provide a magnitude sweep capability to do multiple tests at increasing magnitude.

The signal will be injected into the rate loop output. We will record the excitation signal, the rate loop input and output and the RAW IMU output, all at full rate. We may need to subsample some of this data if we run out of bandwidth.

This will be great! What frequency range are you looking to characterize? Do you have an idea of what helicopter rotor head types you want data on or were you just going to look at a fairly typical setup (2 blade teetering). By the way, what is BPSK?
This is coincidental because I was planning on doing some characterization work over the Christmas holiday. I have a chirp set up in my repository to look at pilot stick to response, rate output to response, and disturbance rejection (chirp input on attitude signal into attitude controller). The chirp code was built on AC 3.5.0-rc7 but I was going to bring it into 3.5.3 or 3.5.4 if it comes out in a week or two. In any case, I would be interested in working with you on this from the Tradheli side of it.

Binary Phase Shift Keying. It is a widely used modulation scheme for one of the most popular digital modes in ham radio (PSK31).

Yes, so this is a way of exciting the aircraft with multiple step functions that would then allowing us to combine all those responses into a single representative step response. It ensures that a single resonance would not mess up the result or cause a resonance in the aircraft.

Provided I add the signal to the output of the rate controller (input of the output mixer). The aircraft should be able to be excited up to frequencies of half the output rate to the servo or esc’s. To make maximum use of the characterisation signal it should be injected as late as possible into the system and measured as early as possible. The problem with passing it through the attitude or rate loops is the signal will be attenuated/distorted significantly by the PID loops. This would significantly reduce the bandwidth that we can characterise.

The advantage of the BPSK signal is it will let us characterise the actuator/airframe/IMU system to half the IMU sample rate even if the servo output rate is only 50 Hz.

I’m fairly familiar with PSK, use it in ham radio applications for years and designed and built a few hardware modulators/demodulators for it. I don’t know what you’re using for a modulator/demodulator, or what the data rate is. But normal BPSK is two-phase, with the phases 180 degrees out of phase, and rather limited data rate since it’s modulated one bit per symbol. Or are you really using a quadrature 4-PSK scheme for higher data thru-put? And if so, modulating/demodulating 4-PSK involves a fair amount of processor overhead.

I guess the question is more along the lines of whether you are after just rigid body modes of the aircraft response or do you want to capture elastic modes as well. I know for bigger models the elastic modes may be closer to the rigid body modes. I suspect that most of the response you are interested will be less than 5 hz. With the X3 heli, I had FF_ENABLED off and a P gain of .05 and the aircraft was getting out of phase with the stick at less than a half hz. The gain was crossing zero db around 2 hz. Point being that even though the excitation frequency can be up to 25 hz for heli’s, I think our freq sweep should only go to 5 or 10 hz at most. For Helis I don’t think there will be useful control response above 5 hz. From what I have read, you need a sample rate of 25 times that to conduct a good spectral analysis.
Let me know what frequency range you want the chirp to sweep and I will look at getting some data.

I think that is 2.5 times. For most of my DSP work I like to have 3 or 4 times but when you are collecting data it doesn’t really matter because in the last bit you get what ever you get.

So regarding the frequency range. I want to support as much research as possible. So the maximum frequency range will be specified by the user. That way we can get really clean data at say 0 to 40Hz for control optimisation or 0 to 500Hz for mechanical analysis. In both cases the data is being recorded by the IMU at up to full rate of something like 2KHz.

That would be very interesting. At this stage I would be happy to get what every you thought was safe for you to collect.

Well then I just want to warn you and others that may do this on a helicopter. There is a rotor mode called the lead lag regressive that is lightly damped. You want to be very careful exciting this mode. Personally I may just choose not to sweep through this frequency. I don’t know for sure but I think it will be around 15 to 20 hz for our model helicopters. But you can just do a FFT on the lateral acceleration signal and look at what frequencies pop out. It will show up at about half of the rotor speed depending on how tight your blade mounting bolt is

1 Like

Good to know! Thanks @bnsgeyer

This is where the BPSK excitation is useful as it shows the full frequency response of the system with a bunch of small step inputs. If we use 1000 steps we can use 1/1000 of the magnitude to get the same accuracy of the response.