There's no specific date set yet I'm afraid. The issue is that for 2.8.1 we modified the rate controllers to work in the body frame and we may have broken the heli controls while we were doing that. The additional problem is that both Robert and my helis are out of action at the moment.
Robert Lefebvre is actually master of the heli code these days.
I am very pleased with what I have going and I thank the guys!
I was able to do a very stable flight today plus a very accurate altitude hold. I know there are some small adjustments that need to be made from 2.7 to 2.8 firmware including Alt Hold not holding altitude in fast forward flight and some of the waypoint logic. Hope to see 2.8.1 soon.
Sean, I tested the prototype for 2.8.1 yesterday. It went pretty well. I have some changes to push to my clone so that Randy can bring them into trunk.
Overall, I found the 2.8.1 transformed highly sporting flying in stability mode in the same way that it did for multi-rotors. Banking and Yanking feels much more responsive now, whereas before it was always mushy. I was having fun with the heli and even started getting the blades to "bark" in some manoevers for the first time, so it was being pushed and responded well.
However, when it comes, everybody needs to be prepared to do EXTENSIVE retuning of the PID's. You will not be able to fly with your old setup. Everything changes. Luckily, for the most part it is straight forward, and I can walk you guys through the conversion process.
So the only downside is I was having too much fun again, and did the same stupid mistake I've made before leading to a crash. I use the ESC control mode which drives my governor equiped ESC direct on Ch8 from the APM. This does not use any input channel. Soon as you arm it, and raise the collective off the bottom, it sends a preset PWM to the ESC. Soon as you drop the throttle, it shuts down.
I had made a mix in my Tx, where I could flick a switch which locked out the bottom 1% of the throttle range, which prevented an in-air shut-down. But, I was so busy tuning the PID's, that I forgot...
So I have to change this mode. It's too dangerous, I've done this twice now.
What I'm going to do is control the throttle off of Ch8 input.
Now, when will this all hit the downloads? I'm not sure.
Randy is looking to bring in his accelerometer augmented position hold, and then pushing the whole thing out as 2.9, but that might delay things a bit more. I could consider having a special push of 2.8.2 just with what I have now for Helis only.
But the only problem is, that I only have 3 flights on it before my crash. I'm not totally happy with that. So it depends on you guys, how you feel about it.
I tested hovering precision, high speeds, and full acrobatics (well, whatever you can do with only 45° in stab mode). I am a little concern about some weird imprecise feeling in Acro mode, but then you guys never had Acro mode before, so anything is better than nothing?
I just found that the control wasn't precise. But then, I don't have a lot of experience in acro or manual flying so... maybe it's just me. I have done a bit, in full-manual flybar mode in the past, it did feel fine. This new mode in Acro on a flybar... I'm not sure. Maybe it was just a bad day.
Anyway, the 600 is down for a while, I blew the ESC. I hope my 450 will be running again soon.
Oh, and as for Alt_Hold and high speed waypoints, that won't be coming with 2.8.1. That part is not improved.
I expect that if the accel-augmented Alt-Hold works for the helis, then it will help with this issue a lot. But we still have a serious problem with helis climbing and diving at high speeds when you pitch them. The current Alt_Hold model does not really work with the real aerodynamics of helis. I'm working on that, but I don't think it will be soon.
Ok guys, so I have a question for you. You can have input on the future code. ;)
Previously, Randy had a piece of code called "heli angle boost". Basically it was similar to what the multirotors have. It's a piece of code that attempts to increase the throttle (collective pitch) automatically whenever you lean the heli over, in order to give it enough throttle to maintain altitude. So, say you're leaned over 45°, it would increase collective by maybe 70%.
But I actually took it out of the program that I'm working on here for 2.8.1
Reason is, I am attempting to create a two-level collective pitch range. You get to set up a full range for acro mode, and then can have a reduced range in Stabilize mode. I had trouble integrating it with Heli Angle Boost.
Secondly, I'm not sure if Heli Angle Boost is really doing what we want. Theoretically it could work if you are doing all your manoevers at zero airspeed. But with a heli in particular, there are some really large aerodynamic effects that completely swamp any of these angle boost functions.
If you're flying foward at 50 km/h, and pull back on the elevator just a bit, the heli will climb far beyond anything than the collective could do. Simply put, you don't need Angle Boost at speed.
In fact, if you are going fast and trying to stop by "slamming on the brakes", it can actually fight you because in that case you need to dump collective pitch to avoid climbing, but the Angle Boost will be adding a bit of collective.
So what do you think? Leave it out, or try to figure out a way to keep it in?
I think leave it out.
The only problem we have is fast forward flight, when the collective (AltHold) can’t compensate for alt loss anymore. But this is different from heli type to heli type. The only way I guess to prevent this, is to limit the max pitch angle because we don’t measure air speed, only ground speed. Otherwise we could limit the max air speed.
I think AltHold does a good job, as long we operate in the limits of the collective. If we break from speed flight, AltHold will always compensate in its limits and that’s all we can do, like in the real Heli world, there you have your limits you shouldn’t exceed.
My thoughts on this:
Helis are set up pretty conservatively in terms of max collective pitch angles, to keep the heli from being to twitchy for a human to operate it.
So when it comes to fast forward flight, can we increase the max pitch angle to compensate for when the current altitude hold algorithms run out of room on the collective to keep the heli in the air?
This would be a good application for a fuzzy logic controller. If you guys can send me some data on when the controller starts to need more pitch, I can start roughing out fuzzy membership functions for a controller that modifies max pitch angle based on ground speed.
Heli’s have physical limits regarding collective, let’s say -3 to +12degr.
If you reach that maximum in fast forward flight you can’t keep altitude anymore, AltHold reached its limits.
And you always need a safety margin to get out of those downdrafts, so never push it to that limit in fast forward flight.
AltHold should use the full range of collective fit for the specific Heli type. You can’t go past that. I think AltHold does that already.
No code can change that, the only thing the code can do, is to keep the Heli within its limits.
I still think AltHold does a good job, but the problem might be in the speed controller.
Imagine the Heli is on a 45degr forward pitch and you increase collective to compensate for alt loss you will also increase speed, because half of that energy is pointed forward. So you need to increase collective again... and so you will end up in a death spiral.
And I think that’s what Robert experienced.
Yes, that is essentially what I experienced. Well... sort of.
The thing is, I typically had the target speed setpoint set at 10 m/s, and the heli would overshoot that by quite a bit. I learned that that was due to the "Tilt" param, which is a feed-forward, and I recommend that be set to "5" for helis, instead of 54 for quads. This is initially what forced the heli to keep going way too fast.
So then I got the heli controlling the speed OK. It was at least reasonable.
But I still had a problem where it didn't hold altitude well. Everything looked fine, until it turned the first corner. I think what happens is that when it turns the corner, it is of course increasing the roll attitude, which causes a rise in altitude, so the altitude controller tries to bring it back down. It would start bringing it down, just as I start turning the second corner so it rises again due to the attitude. Now the Alt_Hold controller starts winding down again. When the heli straightens out, it starts to fall again.
The issue with the Alt_Hold controller is that it struggles because it's only sensor is the baro sensor, and the sensor is very noisy. Since it's very noisy, we can't use a lot of Rate_P gain, or else the copter will bounce around a lot. Jason tried to get around this by really limiting the output from the P-term, but that left us without enough output. So then he added a feed-forward term, but I think this is tuned for quads, not helis, same problem as we had with the "Tilt" parameter. I think a solution may be to do what we have been doing lately with the attitude rate controllers. That is, use a LOT more I-term than we currently do. Make it really high. The I-term can be run much higher than P-term with a noisy input, because the nature of the way it works, it filters noise naturally.
Now in fact, the current Alt_Hold controller already does use a lot more I-term than most of the other controllers do by default. But I think it still wasn't enough to make Alt_Hold effective.
In fact, on my last auto mission attempts, I did exactly the wrong thing. I thought the rise and fall I saw was due to an I-term overshoot oscillation, so I actually reduced the I-term to almost zero, and increased P-term. In theory make it respond faster. But what I didn't realize, was that there's a strong constraint on the output of the P-term*error. It's something like -80/+100 IIRC. So the P-term just can't do much! I had basically completely broken Alt_Hold, because now it had no I-term, a really constrained P-term, and then a feed-forward which isn't tuned for helis.
I'd like to go run the mission again, but this time with TONS of rate I-term.
However, I wouldn't spend too much time on this part right now, because this is all going to change. Randy has pushed in the new accelerometer based Loiter and Alt_Hold code, and this will change everything. With luck, we'll get a really great Rate measurement which we can base an effective Alt_Hold on. This will help a LOT.
However, we will still be faced with the problem where, if the navigation controller tries to change the attitude too much, or more importantly, too rapidly, we will get Z-rate which the Alt_Hold does not have enough collective pitch to control. I think this will mostly happen when rounding fast corners, and if you only have -3° collective, you won't be able to stop the rise.
There's two potential ways to deal with this. One, is that when the collective pitch is close to min or max under Alt_Hold controller, we start limiting how much the navigation controller is allowed to control the attitude. You have a default max attitude angle of 45°, but we could start to pull that back, say if collective is within 80% of min or max.
That's a very direct way of managing the problem, but it's maybe not the best.
Another way to do it, and Leonard thinks this is the better way, would be to change either the desired speed, or the acceleration rate the navigation controller is using, which is what leads to the high attitude angles.
I'm not sure which is better at this point.
Thanks for that great explanation.
And yes the only thing is, the code can do is to keep limiting the attitude angle and therefore the speed if you reach the collective limit. To include the accelerometer in AltHold is a good idea too.
I think we on the right track.