You are correct in your initial assessment and this is where we started from and the basis of a rate only controller. The devil as always is in the details. So a brief history.
First there was rate only control. This needed much larger I terms to quickly react to small rate errors that would cause the attitude to drift around when confronted by disturbances. Flying in Acro would give the feeling of skating in bowls as any air movement would slowly rotate the aircraft.
Then I did some work on Rate controlled yaw. This had a 10 degree maximum error and the pilots input was fed directly into the rate controller and the desired heading calculated by integrating that error. This resulted in very good heading hold that would work for stationary heading, slow moving heading and fast movements. The problem was when the pilot requested changes in rate that the aircraft would not meet. This would then result in over or undershoot so the maximum error kept this to a reasonable value.
Later input shaping limited the input request to accelerations the aircraft could handle and that combined with autotune meant that the aircraft needed an external force to hit the error limit.
The other step forward was Robâs error integrator in acro that let us track these errors and react to them in the same way any angle error is handled. The problem with this is disturbances would cause it to wander because the angle change would depend on exactly how those errors were removed. So pilots were complaining about the lack of attitude holding capability and the slow change precision capability.
We then moved to tracking the desired angle and using Robâs approach to cover the gimbal lock regions. This provided an ACRO that was both precise and held a fixed or slow moving angle well but also could keep the rate consistent though gimbal lock. Later input shaping further improved this in the same way it did the yaw controller I described above.
Finally we implemented the quaternion attitude controller. This was a great step forward in that it no longer suffered from the numerous gimbal lock related issues and increased the flip recovery by 2 to 3 times faster. It also enabled a range of flight modes that are not possible with a single euler implementation. At this stage we had all the input shaping developments and the current acro was created.
Something to highlight. While your aircraft can handle your inputs the error between the ghost and real are small. When your aircraft canât handle the inputs then the pilot doesnât get the desired rates and the ghost and real diverge. This divergence is exactly what helps keep the aircraft rates close to the desired rates from the pilot. Without it we would be back at the initial ACRO that everybody hated. Based on what Rob has said, I donât believe anybody is seeing a problem in ACRO based on the Ghost vs Real error in roll and pitch. If you disagree please provide a log. If you canât provide a log then I donât believe you are being honest with yourself or the community.
The other think to keep in mind is switching controllers in and out almost always lead to bad issues from the aircraft that will be very noticeable to the pilot. Using angle hold when the sticks are centred for example will result in good performance with the sticks centred and noticeably bad performance when the sticks are requesting a slow rotation. Often with a jerk as the stick are moved or centred.
So by attempting to fight up to a particular angle then abandoning the attempt when the pilot come s on the controls results in a sudden increase in rate error away from the pilots desired rate. This is because it is precisely that error that is fighting the disturbance. I know this because I worked through this train of thought and tried these things.
I have seen no evidence that the roll and pitch controllers are causing a problem. Nobody has been able to show that they have seen such a problem. The argument that ACRO should be rate input no matter what assume that the aircraft can achieve the rate and in that case the current controller doesnât have an issue.
So far the only issue is that the tail of the heli can easily swing around and in this case it is not nice to have the error build up. So maybe we should talk about thisâŚ
Iâm speaking strictly from the response type (rate command, attitude hold) for the design of the controller. I finally have been able to tune my Heli to the point that I can fly Acro and can feel comfortable doing so. I appreciate the history on the controller. It sounds like a lot of hard work and thought went into it. I think it is great but i was just pointing out that in corner cases where the aircraft does not match the target angle.Then at some point the pilot only cares about the actual angle and not what the target is which the pilot knows nothing about. It sounds like you are looking to address these cases.
I think the big concern for Heli users is the controller behavior prior to arming/turning rotors and how it impacts the initial aircraft response during start up. In my opinion, this not safe. Hopefully this can be addressed in an update soon.
Thanks to all the developers past and present. This is an immense undertaking with the number of frame types it can support.
Youâre going to fix my mechanical setup? Or youâre going to make a stability patch to benefit helicopters that have setup problems? To me that seems like needlessly complicating the code. You can do as you like regardless. I already know nothing I say, will change your mind.
We did talk about a lot of things. But not this. You never told me you were planning on a completely disconnected âghost helicopterâ with unlimited angle error that will continue to integrate the users input for long after the system has departed controlled flight. Nor did we talk about how the system should behave on the ground.
Iâm so glad, that after all these years, you have so little empathy or understanding of my situation. I crashed my development helicopter on the very first test flight of 3.4. I didnât know how I was going to pay my mortgage that month. But I should spend more time and money fixing it, to continue to test software for otherâs benefit, and when Iâm in a situation where itâs crashing because changes are going into it which have issues, and were not discussed.
That makes total total sense, doesnât it.
âFoot stomping silliness.â I⌠after all these years, and all Iâve done, and the situation. This REALLY makes my blood boil. That I considered you a friend, and to come up with a comment like that⌠Iâm literally shocked.
And âbetter for itâ? Are you objectively looking at any of this? Put aside the attitude control issues here, and look at all the other problems with 3.4 for helicopter. There is a lot of broken functionality, and there have been a number of crashes due to it.
Another reason I stopped, directly related to ALL of this, is that I take it VERY seriously to only sign my name on product that I can stand behind. I knew that I could not do that with 3.4. I didnât have any control or say over what was going into it, nor the time and money resources to do a good job quality testing it.
Yeh, I get that Bill. I think people are confused because they picture the reaction with this error present as âif the error feedback wasnât there the heli would just follow the pilots rate commandâ. I think the bit that people donât appreciate is if that error is getting larger the heli isnât following the rate command at in the first place and without the error feedback fighting the external force the difference between the commanded rates and actual rates would be much larger.
The issues happen when the external force or error is so large it becomes noticeable. The problem is people canât really give honest feedback on this state unless they can actually create it in flight. Otherwise they wonât really understand how bad it needs to get and the speed of the disturbance relative to their own reactions. If anybody can share a log and their experience it is really valuable. Unfortunately when people give feedback without having the experience they tend to picture themselves with god like reactions and an aircraft that is simple recovering from inverted flight with full control. I will be getting back into testing racing quads and I will be keeping an eye on this issue to see if we need to do something more.
So yes, I think the initialisation is a serious problem and Randy is going to look at that. Given Rob has said it didnât do this before I assume it is safe to reinitialise the controllers. If it isnât for any reason then it would be good if someone could clearly explain what shouldnât be reinitialised and why.
I will have to come up with a sensible way to limit the error on yaw. I think this can be done elegantly without limiting the control authority to fight the disturbance. I donât seem to be getting any real interest into discussing the detailed tradeoffs so I will come up with a plan and discuss it with the control minded people in the dev team before implementing it. I do have a question for anybody who cares to answer.
When you have a blow out, would you prefer the aircraft to completely turn around into the wind or just to the point where it is able to take control again?
I understand what you are saying. From Robâs posts, it sounds like retreating blade stall (RBS)(which is what I assume he is referring to for high speed flight) is one of those instances that can cause this situation. I have never taken an RC heli to RBS so I donât know what kind of rates develop. The other part of that situation is the rotor system no longer has the moment producing capability to overcome the response because of RBS. Once the aircraft slows down or moves to a dynamic state that restores sufficient lift on the retreating blade, then full control can resume. I think this would be a similar situation in the yaw axis with loss of tail rotor effectiveness. I see where you are coming from with regard to in some instance rates will develop so fast that the pilot isnât able to respond quick enough and the controller can. At some point though if the disturbance is so great, personally I would want the controller to stomp on the rates to allow me to come in the loop and fly out of it. But that is me and all of my acrobatic experience is in airplanes. If I really want it to get me back to a known state (wings level, nose on the horizon) couldnât I flip into stabilize mode. At least now I know the attitude Iâm commanding. Again for high rate short (doesnât cause pilot to come into the loop) deviations, I think what you are proposing is great!
So let me tackle this from another angle. The attitude controller has no idea about the moment producing capability of the aircraft. So it is capable of requesting unreasonable rates from the aircraft, far greater than the max requestable rate from the pilot? From what I remember of the code and please correct me, the attitude error is multiplied by ATC_ANG_XXX_P which is typically around 3.5. So a 90 deg attitude error results in a 315 deg/s rate? So you could limit the angle error by the max allowable commanded rate. This would at least keep the error to something less than infinity but still allow the controller to input max rate. Thoughts?
So to clarify, you are say that Rob said that Copter 3.3 didnât have an issue with users potentially winding up the attitude controller prior to start up and then find the aircraft tipping itself into the dirt after the rotor turns up? I believe the initialization issue was handled in Copter 3.3 just by the fact that the Attitude controller angle error was limited. From what I can tell the attitude controller was not relaxed in pitch or roll in a pre-armed state. I think Robâs concern is that disabling or relaxing the attitude controller in the pre-armed state removes a safety net in the event that changes were made that prematurely cause the system to disarm. I would be ok with it being relaxed in the pre-armed state as long as due diligence is taken to ensure that users donât find themselves with the aircraft disarmed while in flight.
I suppose one simple solution is that in some cases, such as when the controller believes it is on the ground, there is simply no error accumulation. Pilots rate demands, are passed through directly to the PIDs. In combination with the Leaky-I, this will ensure the copter isnât in a state where it will flip over when the rotor starts. It will also solve your issue with placing the helicopter onto uneven ground from take-off. It will also make the swashplate behave as people expect it to on ground testing.
This can be turned on and off, by using the vestiges of rotor speed estimation I have implemented. From disarmed, and after the motor is started, there is a counter which estimates when the rotor is up to âflying speedâ at which point the attitude controller can be given more authority to do itâs job. When stopping the motor in flight, such as auto-rotation practice, or accidental disarms, it counts down the rotor speed, and after a certain point, it assumes the rotor is going too slow for flight control. This is a bad assumption, but without rotor speed feedback, itâs all we have. At that point it can transition back to pure-rate pass-through.
The ultimate solution, is direct rotor speed feedback. Iâm running this on my fork based on 3.3 right now.
The problem with RBS, preventing it, and recovering it, which I think is not understood here, is that RBS control loss occurs 90 degrees out of phase. RBS does not occur when the controller runs out of pitch authority, or when the pitch authority is not keeping up with the pitch error. It actually occurs when the roll authority is gone. In forward flight, the swashplate must tip forward, as you would expect, but much less than assumed. But itâs also tipping heavily to the left (on a CW rotor). When the retreating blade stalls, it results in a pitch up. But the solution is NOT to apply more forward pitch output. Thatâs one of the big problems with all of this. And thatâs what the proposed controller is going to do.
Anybody attempting to design a helicopter controller, should get a copy of Gordon Leishmans seminal title on the subject. Rotary aerodynamics are extremely complicated. Much moreso than a multirotor which is a much simpler model. The answer to every question, even from PhD level Rotary Aero Engineers is âit dependsâŚâ. There are no simple answers or solutions.
I donât think RBS can be stopped by an automatic controller once it sets in. The retreating blade has stalled, itâs got nothing left to give. When I hit it, the heli uncontrollable pitches back, until it is basically vertical at which point it slows rapidly. This will rip a UAV helicopter to pieces and must be avoided at all costs. Surely adding wild rate outputs to the thing, will not help the structure. There are plenty of other things that need to be done for a UAV controller besides trying to solve it with the attitude controller, which is futile. Airspeed sensor, adaptive rotor speed control, etc.
I agree Bill, that the attitude controller should never attempt to achieve a rate output greater than the setpoint. No matter what. This is a particular problem right now, for Acro pilots using Stabilize mode as a Bailout from an inverted attitude. It used to be, that the return to level was constrained by the Angular Accel parameters. But for 3.2 or 3.3, this was changed, again without discussion, to be a maximum output effort. This is what threatens to cut the boom off. Hasnât happened to me yet, but eventually it will.
I do appreciate any attempt to make the attitude controller more high performance. But not if it is done at the cost of good human machine interfaces. I cannot think of any case, where a human operator is given a live rate-based control input, where the control system will accumulate error, and actively tries to close that error resulting in movement even after a control is centered. If anybody can think of a single case where that happens, from any field, from flight control to economics, Iâd love to see it. I can see the point of returning to the last commanded attitude in an FPV situation, where attitude is lost, and the pilot has lost orientation and canât see the attitude, nor does he have any feel for the forces or orientation of the vehicle as heâs not inside it. But thatâs a very specific case, and I donât think the solution to it should be applied across the board.
On the question of a tail blowout, IMO, itâs best to just let it blow out 180(ish) degrees. This will be a low-power condition now. Once control is lost, control is lost. The tail is snapping around, and it canât be stopped. Helicopter pilots must understand this condition, and be prepared for it. As far as the pilot is concerned, if itâs 180 degrees nose forward, or 45 degrees from that point, or 90 degrees, it doesnât matter. Itâs not a situation where âOh, good news, it only rotated 150 degrees so Iâm much better offâ. He has to deal with the situation he finds himself in. For the controller to command the tail to keep moving after the event, with maximum power, trying to push the tail upwind, does absolutely nothing good for the pilot. And itâs certainly not good for the machine.
IMO, this all comes down to this simple point: Ardupilot is almost exclusively used as a UAV controller. Nearly nobody is using it for Acrobatics or FPV racing. And that will not change, no matter how good the controller becomes. Thereâs a whole host of reasons for that. From cost, to weight, to public perception. The FPV racing market is all about the Hype Cycle. Ardupilot cannot hope to keep up. While I can appreciate that Leonard is using Ardupilot for these very large FPV racers, itâs a very small use-case. Even if you do not agree with that projection, I do not think that the wants and desires of that endeavor, should be over-running the control strategy that the vast majority of the existing users want. Most of our users, cannot even understand why a copter would keep drifting in the wind after theyâve released the sticks in a non-GPS mode. They certainly will not understand why the copter would keep rotating after they have released the yaw stick. Given their sense of orientation is often tenacious at best⌠why would a controller ever give Phantom Movements. Acro is one thing. Only skilled pilots use Acro. But the yaw controller is used the same way across modes, from Acro, to Loiter.
And it could not be any simpler than this:
I have attempted to make Ardupilot for Heli attractive to existing helicopter users. Whether beginner, or scale, or sport flying, I want them to try using it. I have attempted to emulate the behaviors of existing FBL controllers. They work very well, people like them, people are familiar with them. Having the controller give rate outputs when the sticks are centered, is not going to be accepted.
Everybody wants the rate controller to do itâs very best to achieve the demanded rates. Nobody questions that.
Iâve never heard anybody state that they want the controller attempt to output a rate other what the control inputs are currently demanding.
Itâs just that simple.
Maybe thereâs a good use-case for FPV flying where the pilotâs orientation is lost, and the controller can take it back faster than the user can. Fine. Provide an option for that. But itâs hubris to force your will on others, especially when itâs counter to every control system ever engineered before. Itâs not because youâre just smarter than everybody else. This exact issue has been thought about at great length by others equally as smart. And itâs been decided, time and time again, that electronic rate controllers should not sum rate demands. Period. Itâs a live rate command. Thatâs it.
Thanks for that. It is good to get some real feedback.
I am a little confused about this as if the disturbance is so great it is impossible for you or the controller to fly out of it. In this case the outputs are saturated and there is nothing you can do. Even if there was a check to switch you to direct rate control you could not actually take control. In the same situation with completely manual control and a similarly tuned flybarless controller you would still not be able to take control. You may be able to take control with complete manual to servo output if it let you get additional throws or something.
Then there is the second after the aircraft is able to physically control itself. In this case you will see the current controller appear to roll back to the angle it was at in the moment control was lost plus your corrective input during that time. So it will appear to rotate one way, then back the other, then converge with your requested rate input, normally over a fraction of a second after control is regained. With the old code exactly the same thing happens but it only rotates back by 30 degrees before the rate converges to your request. Understanding that for the aircraft to rotate by more than 30 degrees it has to be a MASSIVE disturbance.
This is almost correct. It is also limited by the acceleration parameter ATC_ACCEL_Rll ect. So the maximum rate is sqrt(2accel(error-accel/(2P^2)) for large errors and Perror for small errors. This limits the maximum stopping acceleration the aircraft experiences to accel.
Now that is a good suggestion⌠I was thinking if we do the limit we should do it to the point that results in maximum actuation against the disturbance. That would mean the aircraft would fight to the very limit of itâs ability before sliding.
Yeah, maybe but the maximum error was 30 degrees so that is a pretty large error. I canât see that error not putting the disk into the ground. If that was all that was stopping it then it is a complete misuse of the attitude controller and also heavily dependent on the tune of the aircraft. I think we can do a lot better than that. It would be great if you could take the time to tell me exactly how you think the aircraft should behave on the ground before take off. And we are able to treat the disarm stage differently than the arming stage so it would be interesting to hear you thoughts there as well.
Based on what Rob has said in his reply my take on roll and pitch disturbances of the order we are talking about here, RBS is the only thing that will cause it in a Heli. Given Robs statements along the lines of fighting the pitch is not the right thing to do. The attitude controller wonât do the right thing and never has. This case may need special handling and detection in the heli code and may simply be left to the pilot/tuner to ensure the aircraft doesnât ever enter RBS. This brings me back to the question of, has anybody got a log that demonstrates errors during flight approaching or past 30 degrees in roll and pitch.
The Yaw issue is different and should be handled.
Thanks for your help here Bill. Your insight and discussion are very helpful!! Let me know if you disagree with what I have said above and why as it helps me a lot!!
Now we are talking. So I assume that heliâs are carefully setup so that zero output from the controllers result in zero rate from the aircraft. This simplifies things significantly if it is true. I understand that leaky I is not necessarily used though. What would be helpful is a detailed description of exactly what the pilot should see throughout the start process. That would help determine what we can reset and pass through. If we can pass the rate only outputs why not pass the output directly and avoid the rate loop and I term buildup completely?
Ok, so we can take expecting the Attitude controller to deal with RBS off the table. That simplifies things. Cool, now we are getting somewhere.
So it doesnât matter where it ends up so it taking control gain as soon as it is able would be an appropriate response. If the attitude controller only slid until it could control the heading with maximum yaw output that would be an acceptable solution? I would have to think about this in terms of quad plane too of course.
Then you will love the very old rate only controller Rob. I was thinking of making that available for tuning purposes again. Every ACRO since we left that was the sum of rate commands, requested and corrected. The whole reason for this was feedback from ACRO pilots that didnât like the fact that rate only controllers didnât give them exactly the requested rate. With the attitude feedback the two line up and the ACRO pilot likes it. I have been working with ACRO only pilots to get feedback since I started working on the old and hated rate only controller.
I donât see the point of looking in to a heading where the outputs are or are nearly saturated. Youâre basically guaranteeing a loss of control again. There has to be some headroom left. I believe that itâs a happy chance that, when a standard FBL controller blows out, as the tail swings through 90° to the airflow, the loss of control is even worse, the rotation rate increases even as the output is at maximum. As it goes past 90° to airflow, aerodynamic load decreases, the control output approaches that of the aerodynamic loading, but due to the stored kinetic energy, it doesnât actually stop and lock on to a new heading until well past the point where it has sufficient control authority again. Happy chance. It ends up 180° backwards, lightly loaded, in control. It stops. The pilot gathers their wits and continues. It feels ânaturalâ.
One of the key design goals of most dynamic control systems, is to give a natural feel to the user, such that they donât even know that there is a control system in play.
No, I donât think so. That leaves it flying with the tail powertrain maxed out, and just waiting for a gust of wind or collective pitch torque load to make it slip again. And thatâs also a key point in this. The anti-torque load is heavily influenced by collective pitch output, which varies widely. Itâs not just aerodynamic loading on the tail boom, but the torque load from the collective. If you have a blow-out due to aero loading, and then stop when the yaw authority is maxed out, and then the pilot gives it some more collective, itâs just going to slip again.
And thatâs why, again, if it stops at roughly 180 degrees out, and locks on that as the new heading, so aero loading is at a minimum and there is lots of control authority to accommodate motor torque, thatâs the best case. Not that 180 degrees should be programmed in. If the helicopter was flying sideway, it may only blow-out 90 degrees.
Point being, when control is lost, it will rotate beyond a point where the control power is equal to the load, because the system has to decelerate. This will naturally move it to a location where it has a range to work with to hold the new position. Trying to have the control system push it back until the output is saturated, is just guaranteeing another loss of control is imminent.
Oh, and that reminds me of something else that needs to be done. The yaw control output force is asymmetric with the control output. The tail rotor works better in one direction than the other. This is something else Iâve been wanting to add linearization for. There are so many other things more important to do, than this stuff, that will make a bigger difference in normal operation than these at-the-limit things.
I would love if you could fix the issue where the auto controller pulls back for some reason, after completing a waypoint turn and itâs supposed to be accelerating to the next waypoint. Thatâs the biggest thing preventing me from having helis push harder and faster in auto flight.
Or velocity feed-forward in the auto controller so that the heli can go around acute-angle corners without stoppingâŚ
Itâs very possible, that with the latest changes to the code, everything is running faster, more accurately and with less latency than it used to, that things would be just fine in pure rate. Itâs worth trying.
Argument from authority, sure, I think thatâs what Iâm arguing against right here. Iâve always been anti-establishment, which is why I am involved in this project.
Oh, interesting log I looked at for another issue yesterday. Case in point about not needing Stab Patch for helicopter. This is a 1-kg helicopter, doing Figure-8 Auto flight at 25 m/s, and then Acro flight up to 36 m/s (for 10 minutes of this, I might add, with lots of battery left) with no indication that itâs coming anywhere near the limits of the control outputs. This is the same heli that you thought was needing it.
And thatâs typically the only time a helicopter would lose control. Remember, they are inherently aerodynamically stable. Humans can fly them with direct output control.
Thereâs only two situations, where Iâve had a helicopter lose control. RBS. And tail blowouts. And hitting things. None of these can be saved by any control system, because they occur when outputs are saturated.
Sure, that I can agree with.[quote=âLeonardthall, post:89, topic:15658â]
I think we can do a lot better than that. It would be great if you could take the time to tell me exactly how you think the aircraft should behave on the ground before take off.
[/quote]
The swash plate should operate in a direct rate pass-through fashion. Just doing a direct servo output passthrough is not what we want, as it doesnât actually permit us to check if the system is working properly. It also doesnât help with midair disarms.
Further, the helicopter should not lock on to any attitude when itâs on the ground. You should be able to boot it up upside-down. Walk over, and place it on the ground, right-side-up, or maybe 5 degrees off level, and it should accept that as the target attitude when the rotor is started. It should not try to roll over. Nor should it try to achieve level if it was started 5 degrees off level.
What most people want, is a controller which feels like a mechanical flybar. A flybar is not smart. It just tries to control the attitude rate. Electronic FBLâs have been designed to replace flybars, but be better. Most particularly, stronger error rejection, and faster responsiveness.
This is something that I think needs to be improved. I donât think the controller currently saturates the output before control is lost. It should fight harder. However, it shouldnât use attitude error as the means to load up the outputs.
The easy answer is âwell just increase the gains until it saturates earlierâ. But we canât, because they we get control oscillation from small disturbances.
I donât know what the answer is, but this is the key to better performance, and I donât know what the solution is. I just know the solution is not âload up the outputs as a large attitude error builds up, and then snap back to unwind the attitude error when control is regained.â
If you play with a heli with a FBL controller on it, or a tail gyro, the tail gyro will go to maximum output with very little movement. Our system does not do that. And I canât just increase the gains, or we get control oscillation.
And cue Billâs discussion on Notch Filter allowing higher gains.
I was talking to a colleague of mine regarding this situation. He was telling me that manned implementations using a model following control architecture have to address this situation. In a model following control system an accurate physical model of the aircraft bare dynamics is inverted to convert pilot rate command inputs into proper swashplate inputs to provide that commanded rate. When the aircraft departs from controlled flight, the model is no longer valid and the controller is designed to switch to direct control mode (not sure what it would beâŚrate command or sticks to actuators) until controlled flight is established. The Ardcopter attitude controller uses a similar architecture in that youâve established a model however, due to the wide range of aircraft it supports, you use a response feedback implementation to achieve the desired requested rate. So I think it would be the same with this controller that once the aircraft departs controlled flight, the controller helps the pilot fight rates until controlled flight is achieved
I donât see how we can take RBS off the table when we are still address a tail blow out. In either case, the controller is no longer in control. May be I misunderstood your comment. What to do when the aircraft departs from controlled flight, which is possible with RBS, should still be handled appropriately in pitch and roll.
Let me qualify this, if I may. In Acro mode, it should operate as a rate command without attitude feedback. I think rate feedback is ok because it demonstrates the controller is working appropriately. For Stabilize, it should act as attitude command so again, the user can see it is behaving appropriately. This is where it gets difficult to decide when it should behave this way. I was planning to propose (in a separate discussion) my thoughts on integrator error and attitude error handling during ground/air transitions. I think it is appropriate to leak the attitude at some slow rate so as to provide better takeoff handling from uneven terrain. I also want to propose instead of leaking the integrator, that the IMAX be zeroed when on deck. Now at liftoff, the attitude leak is turned off and the IMAX is ramped in to the user set value over 5 seconds. The reverse would be done on landing. So if this is done, the pre-arm characteristics would behave as I think a heli user would expect for Acro and stabilize mode.
I am not sure of the code specifics for this, but the above quoted is important from a pilotâs standpoint. I never take off from level ground or attitude with my helicopters. Never. I fly from fields where I donât have time to prepare a level landing/takeoff site. The heli is usually booted sitting on the tailgate of my pickup and set on the ground in a wide enough open spot where I can take off from, which may be leaning 8-10 degrees one way or another. I donât like any controller that would try to correct what I as I the pilot want that the helicopter to do on takeoff.
Say the helicopter is leaning forward and to the left or something. As the collective comes up to hover itâs going to try to fly in that direction it is leaning. The pilot counters it to make the heli lift off vertically. The controller canât be messing with that control input or the heli will hit something. I tried turning the leaky integrator down with the ILMI param, and it simply doesnât work. The I-term builds up and it darts off in some direction I donât want it to go. Or it simply tries to tip over.
Ok, so âyesâ again. You misunderstand. I was thinking it would stop at the point where it no longer needed maximum actuator output to stop. This would take it past the maximum angle at which it would maintain control due to inertia as you said.
You said we needed it I put it on my list of things to do or look at. You said we didnât need it and I took it off my list of things to do and said:
Anybody would think you arenât paying attention Rob.
Cool, Heli doesnât care about how the roll and pitch error is handled. If the attitude controller looses control then the heli is toast anyway. All agreed. Closed until logs are supplied. Lots of work and time for you to just agree with me.
So the feedback I have from other heli pilots is using the rate controllers is very hard to test the system because the pid loops are doing other things and to be honest they go to a lot more effort to explain their point of view. From my conversations direct rc passthrough before initial take off and continue to run the controllers after disarming is the balance we need. All this is assuming we can do that. We will have to see.
Wow, just wow. Now you are just being silly again.
I got that Rob. Donât worry, I will take care of it. No need for you to worry.
If the Attitude controller is initialized in ACRO properly it will initialize to itâs current attitude. In Stabilize, it will attempt to be at the angle commanded so you will need to hold stick over matching the lean if you donât want it to move.
This is a problem. The thing with the leaky I term is it is pretty much equivalent to simply limiting the I term to a lower value. With the leaky I term you get a maximum I term that is proportional to the Rate error so there is something to say for that. In any case I think the rate tuning is very poorly understood by the Heli community. The maximum error can be calculated for this case but I suspect the defaults have not been defined with this in mind.
This is a very serious issue and should be addressed!! I will have to think about this some more. Again though, this isnât an attitude controller issue, this is a heli specific issue.
Your typo made it difficult to understand what you were saying.
Who agreed with that?
During pre-flight checks, how does the user confirm that control actions are correct to attitude control if itâs just RC Passthrough? Whatever, it would be trivial to do this, as itâs all set up in the heli library already. Couple line change.
I wonât use it though. Will continue with the existing working implementation.
But Iâm glad to hear youâre volunteering to be helicopter lead developer. Somebody needs to be responsible for it.
Sorry Leonard, do you have any data logs to back that up? You know, engineering problems require engineering solutions? When is the last time this has been tested? The last time I tested it on a heli, was with a cheap Chinese clone HK450GT with analog servos and an APM2.5 and servos running at 50Hz. And it wasnât bad. It was multirotors that were the problem. And that was before we had fast-response ESCâs and running the attitude control system at 50Hz. ie: when I tested this and it didnât work well, I was using a 3DR OG quadcopter kit with APM2.5.
Iâm curious if the current popular FPV racing controllers are doing attitude lock. Anybody know?
So, hereâs some more info, from the same flight. Again, this is a ~1kg helicopter doing Auto waypoint flight with 5 m/s/s accelerations to 25 m/s. And then high speed and dynamic Acro flight to 36 m/s.
So, not a lot of pitch error to speak of. During the auto portions, there are pitch errors of 6-7 degrees during the nose-up deceleration periods.
Then in the acro flight you see a few spots. Those 4 large repeating patterns with errors on them are a neat move I like to do. 30 m/s, pull back and high collective power, pulling up 4Gs into a 20 m/s straight vertical climb. Hold until speed bleeds off, then as it stalls at the top, I yaw it around sort of like a hammerhead stall on a plane. Only, I yaw it around 2-1/2 full rotations until itâs facing nose down. Pick up speed in freefall, then full power collective, pull back 4 G into another 20 m/s climb, and repeat.
There are worst case 14° errors here. Itâs curious, Iâm not quite sure why, they occur as the pitch rate demand levels off and itâs holding a straight nose-up attitude. Itâs actually the least demanding part of the routine. Could be it simply needs more pitch tuning. I usually donât tweak pitch to the limit.
Roll Error; about 4-8 degrees maximum. Thereâs a few false errors when the target angle flipped past 180.
And hereâs what Iâm talking about. Hereâs Pitch Out. Despite up to 14 degree error in some places, itâs not trying very hard. The two large spikes, I believe are pitch-flips, so all of that output is due to demanded rate, not error correction. As I said, the controller needs to work harder to close angle errors. But without causing oscillation. I know for sure Roll is tuned as tight as it will go. And Yaw as well. Iâve never actually gotten a pitch oscillation from tuning. I typically set it to about 20-50% higher than roll, and so that it looks good with no overshoots when I do +/- 45° pitch rocks.
Given all this, pretty dynamic flight on a small helicopter, and absolute maximum pitch error of 14 degrees, and only for a short period in certain circumstances⌠Iâm not sure why we would need 30 degrees error tracking for 99.99% of users that are UAVâs. Certainly, not sure why 180 degrees would be required.
I understand where Rob is coming from with respect to his concern with handling a tail blow out in this manner but I think Leonardâs solution is acceptable because the controller is letting the ghost aircrafts heading swing with the actual aircraft heading until the controller can regain control of heading. I realize that the pilot can make other inputs that exacerbate the situation but then the controller will let it slide more until it can regain control. I think this would be a good solution. @Leonardthall I would like to hear more on this type of implementation. Iâm sorry that I didnât respond to this earlier. Sometimes itâs difficult to keep up with all the responses and different subjects covered in the same response.
I think this behavior should be anytime the aircraft is on the ground, both pre-arm and armed with rotors turning. In stabilize, I think it is more than the integrator that is causing the aircraft to want to tip. I think that turning the angle error into a rate to close the loop is also contributing to this. Once the aircraft lifts off then the attitude control should resume its normal function.
Iâve always been anti-establishment, which is why I am involved in this project.
