I would cast my vote for this scheme as a great first step for testing. The highlighted part above would be kind of like how a flybar acts on the ground when it’s running up which would be really cool for a FBL helicopter when compensating for wind, tilted takeoff pad, etc…
Hi olliw42,
Yes, I can relate to the challenge. We went through a similar process back in the 2.7 days (probably 5 years ago for us too now that I think about it, time flies) with the early APM2 boards. Low pass filters you discribe result in large errors with high inputs and slow response with low rates. Hard to make feel good.
Switching between out of heading hold results in poor slow rotation performance and little kinks as you switch between states. Gives the pilot an unsettled feeling and is both sloppy and over aggressive at the same time. It looks good to start off with but that nice feeling is elusive.
Acceleration input shapers work well but feel twitchy or a little sharp around mid stick. ACRO pilots don’t mind it but doing smooth transitions and flying smooth and slow is harder and feels unnatural.
We went through all this and more and none of them work well. They are all hacky and unsatisfying when you are dealing with the range of users arducopter supports. To get really nice feel you need acceleration and jerk limited input shaping and a tight tune. That was when it started to all make sense and feel good.
Yes, but Rob is seeing something that doesn’t make sense. It might be a tuning issue, it may be an input shaping issue, it may be a nonlinearity in the system that is messing up the PID loop, or as Rob said, it may be a fundamental problem with something we are doing in the controller. Pointing out problems or questions is the first step to understanding.
We will have to agree to disagree on that one. I feel confident that the community will bring it all together very soon!!
I 100% disagree with the concept of using hobby FBL controllers downstream of the autopilot. It’s a wrong-headed move. It’s throwing in the towel, and admitting that Ardupilot can never be good enough. That sort of message indicates that Ardupilot is not a top-quality controller, a hobby-grade system, and not professional grade. Do professional-grade closed-source systems rely on a hobby FBL controller? No.
The worst part about it, is that acceptance of this concept means that we’ve given up trying to make the rate controllers better.
And, not to say that things are really very bad. I was told by a commercial helicopter UAV user, who purchases systems at $100k+, that doing this was impossible:
But there it is. Notice, there’s no issue with yaw control.
1 Like
I agree, the first and most basic step is to lock the ACRO ghost to the current attitude during start up. This will make things safer and easier for people to understand.
Then have a look at I term handling and do some experimenting with the threshold thing. I would seriously look at locking the I term to zero though. It makes it clear things are working properly and minimises the risk of a pilot not paying attention and taking off with I term build up.
Once we get those two things sorted out we can look at the niceties such as:
But until then things like this just complicate the development. And I think you will find that doing this makes things more dangerous during take off just to make things look sexier on the ground. In any case we can discuss the pro’s and con’s of this when we get to it.
You are correct Rob, it will react like a rate only controller and show the reaction to an external disturbance or the pilots rate command. So rate disturbance rejection and rate command response. So the pilot could use this to look at the rate responses and flick to Stabilize to look at attitude disturbance rejection and attitude command response. This seems to be a really clear and predictable behaviour, especially if the I term is zero.
Just another thought and it might be a bad one… You could leave the I term unlocked when the aircraft is unarmed to show I term build up as well as the rate response like Rob is more comfortable with. This would also be consistent with the behaviour you want with false positive on the land detector and premature disarm. That way you can look at the response before and after arming to look at with and without I term.
I think I might have left that in by accident. I would like to see it not leaked but just released with some takeoff criteria to be defined.
I think that is the current implementation of the I term. I’m ok with it but I thought what I had proposed was much clearer from a controls check to the uninitiated. Plus then in conducting the controls check with nonzero ILMI, you have some I term buildup that you would have to correct for upon arming/spin up. It probably would be ok.
The idea of just resorting to using a hobby FBL controller is…
It’s like asking the question “Why would you bother trying to make an open source gimbal controller? DJI had this market locked. They’ve been doing it for years and know what they’re doing. Just buy theirs.”
There’s two answers to that question:
-
I’m doing it because it’s fun.
-
I’m doing it because I think I can do better than them.
Throwing in the towel and resorting to hobby FBL controllers, eliminates the possibility of #2. That leaves you with #1. Which is fine. Messing around with software is fun. But that’s not what I’m doing, it’s not why I was involved in this project. I’m doing this because I believe Open Source is a better system for end users. And because I believe we have attracted a unique group of people who can do better than the closed source systems.
But that does not mean that we won’t have a few bumps in the road along the way.
1 Like
That’s a good point. I think it makes a sense to zero out the I-term on arming, to clear out any I-term that was stored due to IL-Min.
I had a thought about what the problem with yaw control is. This is based on intuition, not data, so it needs to be looked at. But here it is:
Well, the first thing that has to be understood, is that the helicopter tail control is very non-linear, or more to the point, it’s very asymmetric. Stronger one direction than the other. We need to try to linearize this to get the best performance. I’ve thought about simply having a parameter such as a asymmetry adjuster. You would use a number such as 1.1.
What it would do is that when the yaw control output is pushing nose-right on a CCW helicopter, it would multiply the final yaw output by 1.1. When the yaw control output is pushing nose-left, it would divide the output by 1.1. This accounts for the fact the tail rotor has to work harder in one direction than the other, to resist the main rotor torque.
One question I have had, is where is the zero-crossing point? Is it tail rotor zero blade pitch? Or is it essentially the “trim” pitch, the pitch the heli is using during hover? Not sure.
Ok, now back to the large overshoot. And I’m saying it’s large. This is not a PID tuning issue, it’s a controls issue.
Here’s what I think it happening.
When I first created the angular acceleration damping code, it was an input shaper ONLY. It slowed down the acceleration of the yaw input target. It was supposed to prevent I-term windup, and angle error tracking windup, due to the pilot asking for accelerations rates that the vehicle control authority are capable of matching. It only limited the rate target, but it did not limit the rate error correction. The RATE PID loop always got unconstrained effort to close any angle error.
However, since then, I believe Leonard changed it, such that not only is the Rate Target being subject to the angular acceleration limits. But he also as moved the Angle Error Correction effort, to be subject to the accel limits. This makes sense if the Acceleration Limits are tuned to the maximum possible angular acceleration the vehicle systems can support.
However, I’m using them for more than that. The large helicopters are probably capable of somewhere around 540-720 deg/s/s accel rates. But I’m tuning them with values like 45-90 deg/s/s. This is more about pilot feel. A nice, soft, predictable response, for users operating a large UAV, often with sensitive payloads under it.
But, I suspect this is not working out well, because, any errors in yaw control which build up an angle error (which may be due to the non-linearity of yaw output), the controller is only attempting to close the error at 45-90 deg/s/s. That’s why I’m seeing this large, exaggerated overshoot and spring-back.
What’s needed, is the ability to have a difference between pilot input shaping angular acceleration limits. And the controllers error correction angular acceleration limits.
Correct me if I’m wrong Leonard, but this is how I understand the controller is working now.
I think if you check with tridge on why they did that, it was not because of shortcomings in the attitude controller. Both Rob and I have flown Pixhawks on helicopters over 70 mph with no issues. The Canberrra team was flying a piston helicopter at high speed, engine operating at maximum power output, collective pitch at maximum in turns - in a contest. An environment where the EKF can have an issue due to extreme vibrations and having redundant systems is quite important.
In the previous contest the Canberra team had used a flybar helicopter and actually had the EKF blow up in flight and had to fly it home in Acro. With FBL that redundancy can only (currently) be provided by using a downstream FBL unit, that just like flybar, does not depend on EKF. They set it up as a flybar helicopter with Flybar Mode set to 1 to be able to use the straight-thru control offered in Acro with the flybar code.
Since then, I think everybody automatically assumed Pixhawk/ArduPilot is not “up to the task”. It actually is. But in a contest like that, operating the helicopter continuous at the edge of its performance envelope, putting in a system to provide some redundancy is kind of a normal thing to do. How it got perceived by the rest of the user community is the unfortunate part.
Where I think the discussion about the I-term Leak vs. Lock/Unlock/Zero is going is this:
I’ve still not seen any technical reason why I-term Leak is bad. Or any user-perception reasons why it doesn’t feel right, conversely, I think most think it “feels” right on the ground, and it does appear to be the same as what FBL controllers do. (in fact, that’s how I came up with the idea, so no surprise).
I think Leonard’s issue with it, is that in flight, it can lead to sub-optimal performance, as it limits I-term build up. The I-Leak Min was an attempt to fix that. But not many are using it. Partially because it’s not well documented. But also because most just aren’t looking. The Heli Wiki is terrible to non-existent. But Lord knows I’ve talked about it enough on forums, etc. I know that there are commercial users building helis that are NOT using the ILeakMin, and that’s unforgivable… but anyway.
When we’re talking about locking/unlocking and/or zeroing the I-term when transitioning states, I much prefer Leaking the I-term instead of simply setting it to zero instantly. The servos jumping like that doesn’t seem right. And it if happened in flight, due to false ground detection or something, would be pretty bad. Leaking towards zero is soft, and allows the P and D-terms to largely catch the error if the aircraft is actually still flying.
I do agree that flying around with a Leaky-I is less than ideal. There is definitely merit to improving when it transitions from Leak to Full I-term.
Whether we keep Leaky, or go to some Lock/Unlock scheme, they both rely on effective guestimation of when we’re flying. However, I will point out… using Leaky-I is much less bad if we have false ground detection, than simply zeroing out the I-term.
Thing is, I’ve also flown a gas powered helicopter at high speed, with turns, etc. I was the first to do it remember. I’ve had a TRex 800 gas conversion flying for 3 years now. With no external FBL. And last summer, I got a Gaui GX9 flying, with no external FBL. And have never had an EKF blowup.
The fact is, there’s nothing wrong with Pixhawk/Arducopter that makes it require an external FBL. Even on a gas helicopter. However, it does require a very well engineered Pixhawk installation. I’ve sort of been beating around the bush on this over the past year because I didn’t want to potentially insult CUAV. But it has to be clearly said, because the issue just won’t go away. The problems they had were due to the Pixhawk installation. It’s just that simple.
Chris, remember the problem you had with vibration aliasing, which you solved by simply making a cable softer? Or it was rubbing on the case, or something? Gas helis are even worse for things like that.
Why are FBL controllers more tolerant? I’ve talked to Paul Riseborough about this. And it simply comes down to the fact that because the EKF in the Pixhawk is so much more complicated than what’s running in an FBL, it’s more sensitive to vibration. The Arducopter EKF is tracking not just angular rate, and possibly attitude angle, but also global position, altitude, including north reference, velocity, and even time.
Notice that the Skookum UAV controller, uses vibration isolators that look an awful lot like what we’ve been doing with Pixhawk for years. 
And this, from a company that knows how to build FBL controllers.
Hah, I just spit coffee all over my keyboard… I just pictured someone in a bright blue vest with a big yellow “watch for falling prices” button doing a receipt check on Joe Public while he is on his way out the door with his new Phantom to start his “aerial photography business”! Thanks for that Rob. 
In all seriousness though, I have to agree with you in regards to what will make helicopters a viable platform for “most users”. That is sad but true. Sales are what create money for whatever market we are talking about and these days in this “I want it now without any of the work” society, if its not easy it doesn’t sell. Pretty much every new entry into helicopters at my local flying field is rocking a Blade helicopter with SAFE system, why? Because its easy.
I agree with your sentiment that they offer many benefits and to get wider industry adoption they need to be at parity with multirotor’s in ease of flight, or people will just continue to use the former.
Tim
Yes, I certainly do. The problem was caused by a fairly stiff PVC sheath on the GPS/compass cable being zip-tied to the frame and that sheath was touching the Pixhawk case with the wires coming out of it going to the GPS and I2C ports. It was transferring vibration from the frame directly to the Pixhawk case and causing aliasing of the IMU’s. Simply trimming that sheath back so it wasn’t contacting the case of the PIxhawk totally solved the problem. And it turned that helicopter into one that was flying kind of so-so into one that flies so accurate at any speed that it’s about as picture perfect as they come.
Something as simple as that that could be easily overlooked as “no way that could be causing it”.
And that’s kind of what I was saying about why the Canberra team did that - it was a quick and easy “fix” to provide some redundancy for a problem they were having, likely under time constraints testing and getting ready for a contest. And because they had a problem before with the flybar heli, tridge figured building some redundancy into the FBL one would be a good idea. How it got perceived by the user community is the unfortunate part. And then the heli went down anyway due to an engine failure. The FBL unit didn’t save it from that. But ArduPilot could if we could work out some autonomous autorotation code. Which I would be more than happy to test if somebody could figure out how to do it.
Chris,
I think at some point in the thread I started I mentioned something about this. I believe I had asked if it was possible to somehow circumvent the EKF in the event of failure and go to a rate control relying on gyros? I have no idea if that would be possible with Copter and understand its shortcomings, IE you would have to be LOS to the aircraft for it to be a viable option, but I think in theory it could at least be a backup?
I believe this idea was spawned from my FBL experience with some of the higher end controllers that in the event the accelerometers saturate and fail it stops using them and goes to gyros only.
I have decided to go Pixhawk only as I did not want to add more failure points, but I understand now what “could” go wrong because of my decision.
Just a thought?
Tim
I agree that instantly setting it to zero is a bad idea. There has to be some decay when setting the I term to zero. The same goes for setting the ghost to current upon landing, there has to be some decay.
My other thought on this was to use Rob’s idea of having two levels of the integrator max. Currently, ILMI could be thought of as an integrator max for the landed and low airspeed regime because the leak works to reduce it if the integrator rises above ILMI. Then IMAX is the maximum integrator value that encompasses the rest of the flight envelope. You could choose to leave the integrator running with some integrator max value for hover and then expand it to the IMAX value based on some criteria (takeoff, ground speed…) When that criteria is no longer met the IMAX is shrunk down to it’s hover integrator max value. Thoughts?
Rob, I’m pretty sure the crossing point would be trim point, and not zero tail pitch. The problem is, the trim point changes depending on whether the helicopter is hovering, or cruising in flight.
For my bigger heli’s I’m using 200 deg/sec^2 angular acceleration. I fiddled with the tail on the 700 to get it smooth for aerial camera work with no gimbal. And using the same basic setup on the 600. This is the yaw plot from a flight I did yesterday with the 600 in about 10-12 mph wind aloft, flying at 17m/s. I don’t see what’s wrong with this? The tail doesn’t vary by more than maybe .5 degrees from desired at any time.
At the current time that is not possible with FBL. I believe the EKF to be robust enough that it should not be a problem with electric helicopters with a properly designed mount. It is more of an issue with piston helicopters that have a lot of vibration. Even with a good mount a piston helicopter idling on the ground will cause the the roll or pitch attitude (depending on which axis has the worst IMU aliasing) to start to deviate and your HUD will show maybe 25-30 degrees of roll with it sitting on level ground and warnings going off on the ground station about bad EKF variance. It is why I use primarily acro for takeoff and landing with the piston engine (flybar).
So you get 'er spooled up and in flight and it all settles down and goes away (with a good mount). With the 700 piston I have never had a problem in flight with the EKF (AC3.3.3). With the 600 I have had EKF Velocity Variance from time to time flying at higher speeds, and I have not figured out what’s causing it (AC3.4.6). It never seems to lose attitude solution with a EKF Velocity Variance. One of these days I’ll figure out what’s causing it and fix it. But it is not vibration or aliasing of the IMU’s. It might be an issue with my GPS receiver.
Chris,
I guess its not the day to day operation that is in the back of my mind, its that radial bearing that decides to let go in flight and cause excess vibrations, or a gear that chips a tooth or gets deformed by fatigue etc… There are a million scenarios, and although good mechanical check practices guard against most of these scenarios, it still can happen.
To date, I have had zero issues with vibrations. After looking at some other peoples logs I am finding mine are quite low comparably, so I am not too worried anymore about vibes from the airframe in a hover or slow forward flight. I do still have some “what-ifs” in the back of my mind concerning how the EKF is going to behave with auto missions in FFF. It could be much ado about nothing, but the prospect of a problem still looms. Having access to a gyro based plan B would be very comforting to me anyways. I guess whether that would work at all depends on how far thew airframe is from you and most importantly your piloting skill. Not everyone can control a helicopter manually as you know and furthermore many panic when things go wrong, RBS as an example. Been there, hit RBS in a high speed pass and I am amazed to this day how quick things happen but I regained control and landed nonetheless, but had to change my shorts… 
I often wonder how Pixhawk would handle an RBS scenario?
I personally would love the prospect of a manual backup for situations where I am flying very expensive camera gear, which usually means the helicopter is close to the pilot. When it comes to auto missions where the helicopter is quite a distance away it will be carrying far less expensive gear so it does not worry me as much.
I think instituting some form of backup like that would harden the system a bit and attract more people willing to use a Pixhawk only solution vs adding in Hobby Grade FBL controllers and creating more failure points?
But I guess i’m bring this thread off topic so I’ll shut up now…
Tim
I think that’s a great idea. The “sliding I_Leak_Min” could move up and down based on a synthetic calculation that attempts to guess what the likelihood is that we are really flying.
And also cheaper. And faster, not having to spend hours in the shop rebuilding a helicopter.
The hobby heli industry is paying dearly for being so slow to adopt new technology and new ways of thinking. Many many aspiring VTOL pilots jumped from helicopters to quadcopters. They wanted to fly a VTOL airframe. Not become helicopter mechanics.
I think the heli industry previously created this Macho attitude of “you have to earn it” because for a long time, it helped their bottom line. More crashes, means more repair parts.
Have talked about this in the past. I think the idea has merit.
One issue that was raised, is that Gyro have a bias that has to be zeroed out. That used to be done only during startup and again at arming. But, it changes with temperature. So the EKF now does it throughout the flight. The problem is that the the EKF will often totally screw up the Gyro Bias before it fails. And as Paul says, there’s no way to unscramble that egg.
IIRC, we talked about concepts like remembering the gyro bias on arming, and using that if things go wrong. It won’t be perfect, but good enough to save it?
This could actually be fairly easily sketched up I think. A bail-out rate mode. Would be pure rate, with no error angle tracking. The Rate PID would just get pilot inputs (could be input shaped or not) and would use the raw gyro reading with the bias that was stored on arming.
Being there’s multiple gyros why can’t one be used for backup redundancy, not connected to the EKF State Estimator, and keep it calibrated using a different method in flight like the old DCM? And have the system revert to it if the primary system blows? Pixhawk 2.1 has three of 'em, and one is not being used with EKF2, as far as I know. Maybe that third gyro could be put to better use than EKF3, and even be able to bring the helicopter back home with EKF2 totally scrambled.