My 500 class is now flying pretty well in stabilized mode in FW 3.5.4, but once I toggle to the ALT HOLD mode, the heli reacts really slowly to my in inputs. For instance, in stabilized mode the heli can do some 35-degree pitch and roll maneuvers (I set the cyclic limit to 35), but in ALT HOLD mode, the tilt and bank angle was seemingly “limited” to an angle around 10 degrees. Is it normal? My previous understanding is the only difference between the stabilized mode and ALT HOLD mode is ALT controlled by hand or Pixhawk, in terms of pitch and roll, two modes are supposed to have similar agilities.
I compared the RC In and RC Out in two modes, judging from the wave form, the RC out signal is kind of cut in half for some reason.
No, it’s not normal, and I actually noticed this myself a few weeks ago. My helis are basically unflyable in Alt Hold. So I switched to using Pos Hold where it responds normally (although with the braking angle set to 8 degrees and 4 deg/sec for the transition to braking).
I was going to test Alt Hold some more and see if I could figure out what the problem is. But I had not gotten to it yet, and have not heard any reports from other users related to the issue. Until now. Thanks for pointing it out. I have to get to testing that and see if we can figure out what is causing it.
@joolayoyo it appears in Copter 3.4 there was some stuff that got “fixed” for heli. It basically broke functionality for helicopters for the mode because it doesn’t allow them to even make a banked turn anymore.
The theory behind the “fix” is to limit lean angle with multi’s to prevent them from falling out of the sky - basically prioritize altitude over lean angle. Of course, helicopters don’t have this problem, need to be able to make banked turns and so on, but it got “fixed” for heli anyway.
We’re looking at how to unfix it so helicopters can fly again in Alt Hold.
In the mean time, there’s a param that might be associated with this, ATC_ANG_LIM_TC. That is the attitude controller angle limit time constant and the range for setting it is 0.5 to 10. You should find it set to 1 by default. I do not know what the effect of setting that param to different values has. Since it is set to 1 by default and that doesn’t work, could maybe try moving it up to a higher value and see if it returns normal response in Alt Hold.
Would appreciate some feedback on this if you try setting that to different value. I would like to test it myself first, and maybe it’s just a matter of a different default value for heli. If that doesn’t seem to do it, barring any other sort of solution, I will just remove the angle limiting “fix” from my custom code so the mode is flyable for helicopters again.
When I discovered this some time back I transitioned from hover to forward flight then peeled off in what supposed to be a tight banked turn and the heli slid around the corner like it was drunk. I tried flying it and it was a disaster. So I scrapped the mode out of my setup because I was thoroughly disgusted with it. Then forgot about it.
@ChrisOlson time constants typically govern the amount of time in seconds that it takes to reach a steady state condition. In this case I guess it is the max angle. If this is first order lag which is tylicallly the case when you say time constant, then it take three times the time constant to reach the steady state. So what I am trying say is that the response will get quicker, or reach the steady state quicker, if you lower the time constant value.
I have not tried althold in 3.5. Hope this helps.
The default is 1 and the max allowable range goes down to 0.5. I think it was actually 3.4.6 where I had discovered this. Unfortunately I forgot about it until @joolayoyo mentioned it. But it does make the mode unusable for heli’s because without banked turns they don’t work very well.
@bnsgeyer ok, so there’s a problem with the math in the alt_hold angle limiter for heli. @tridge had noted this in the blog on the test QuadHeli as well:
It’s not a problem in the motors backend, it’s a problem in the attitude controller. The math for heli was copied and pasted from multi and the “throttle” in heli is essentially different than it is for multi’s because a good portion of the “throttle” is used for negative collective pitch. So the result is that angle limiter is effective at hover collective pitch.
I fixed it and I’ll test it tomorrow in a real heli. @joolayoyo do you happen to have the tlog for that flight that you posted the bin log for? I’d like to take a look at that if you have it from your ground station.
Thank you for looking into this issue! I actually tried few days ago with tuning ATC_ANG_LIM_TC param to 0.5 and to me it didn’t feel much differently than setting to 1, still hard to control roll and pitch in ALT HOLD. BTW, the loiter mode feels exactly the same to me, very slow response to pitch and roll inputs. I haven’t tried the POS hold mode yet, the difference between Loiter and POS hold is that the POS hold mode uses a optical flow sensor and Loiter uses a GPS unit to provide position info, is it correct?
Really looking forward to your code to fix this issue, unfortunately I haven’t tried any ground station controlled flights yet, I only fly in Stabilized, ALT hold and Loiter these three modes for this period of time, and ground station is only now used by me to do settings and tuning. So I assume the tlog doesn’t contain much info, is it?
After looking the code over, the ATC_ANG_LIM_TC is not going to make any difference. It can set the time it takes to reach 66% of the steady state condition. But the steady state condition is met at takeoff due to improper overhead and range for the collective pitch on a heli. The code was written specific to multi, and simply copied and pasted into heli without any testing or verification that it works properly. I did the fix on 3.5.4, and after I test it the fix will be in the ArduHeli dev code. Then I’ll do a diff on 3.6-dev to make sure it wasn’t fixed there in the mean time, and if not I’ll submit a PR to master to get it working. @tridge will have to look at it to get the fix into 3.6-dev because there’s a couple different approaches that could be taken to fix it. Either a new param for throttle/collective overhead (probably undesirable to add another param). Or hard-code the overhead for heli as I can’t use the hard-coded definition in the parent class for heli.
Originally, the ATC_ANG_LIM_TC was hard-coded and that was made an adjustable param. So I don’t know which direction the dev team wants to take.
@joolayoyo if you want to test the Alt Hold fix there’s some builds available here. These are built on 3.5.4 so no changes to your params should be required. I don’t think you’re flying a Pixracer so I didn’t do a Pixracer build.
It should turn your heli back into a real screamer in Alt Hold. I tested it in my 696 by flying it down to the end of the field, turned it around and made a maximum power run up the field at full nose-down. I think the Alt Hold angle limiter kicked in for a brief instant when I first accelerated it because it appeared to nose up just a bit, then leaned back into the run. It went by like a rocket sled on rails and I made a full aileron left turn with it. The poor girl in my ground station said something about 28 m/s but I was having too much fun to pay much attention to that. I’m running 15 degrees of pitch and it hit the frame angle limit in the turn before the Alt Hold angle limiter would kick in. I haven’t reviewed the log yet. But I’m confident it will work with a lower-powered heli and should start limiting frame angle when she hits 95% of the max collective range.
Heli’s do not require the overhead that multi’s do because a heli still has full pitch and roll control at maximum collective pitch. If a multi maxes out the throttle they can’t maintain attitude control. Now, QuadHeli’s might be a different situation because they are somewhat crippled with no cyclic pitch. So they might require multi-rotor overhead on the collective. When I submit the PR for the fix, @tridge will have to take a look at that and make a determination as to how to fit the QuadHeli into the situation.
WOW this is quick, I will try your FW ASAP and give you feedbacks! Yes I have replaced the V4 controller with a V2, so it will be fine.
I use a relatively low rotor head speed and a high collective pitch (+8 degrees for hovering, MAX at +13) to achieve a more power efficient flight setting. Even though I think with your FW it will make the control way better in ALT HOLD mode. The original 3.5.4 FW is like what you said, almost “unflyable”. And I really hope the Dev team can correct this issue in coming FWs.
Unfortunately I haven’t got my radio telemetry installed yet so there is no effective tlogs available. I am still connecting the controller and the ground station by a USB cord for merely tuning and setting the heli.
Hi Yi,
Yes, that’s why the Alt Hold angle limiter was on at hover. Depending on what you set your negative pitch range to, if it used 80% of the total pitch range it would turn on the angle limiter. The total pitch range used also includes negative pitch with a heli. So for the typical user setting up with -8 to +10, 18 deg of pitch range, the Alt Hold angle limiter was turned on at 6.4 degrees of positive collective. Which happens to be hover collective for most UAV heli’s.
What happened is that the code was designed for multirotors to limit their frame angle at 80% throttle so they got enough overhead to still have attitude control. And the code was arbitrarily just applied to helicopters, despite the fact that the only thing the same between the two is that they both got fans going around.
Unless you fly fairly aggressive you’d probably never notice it. But it sure crippled heli handling for being able to do any decent coordinated banked turns, etc.
Edit:
As an extra note, that’s why I was running 15 degrees of pitch, positive and -3 negative. I knew there was a problem and I found I could “fix” it by moving the pitch range up, which increased the available pitch range from full negative to full positive, and moved where the Alt Hold angle limiter kicked in up the scale a bit. Now that I got it fixed I can set my pitch back to normal ranges.
I submitted a PR to fix it. But it probably won’t work for the QuadHeli and Tandem frames now, as they require more collective overhead for yaw control, and the QuadHeli frames require it for attitude control. So somebody flying one of those, and who has done enough testing to know what the overhead should be, will have to provide some feedback on the PR so it can be modified to fit all these new frame types into the picture. And I doubt that knowledge or data exists right now for those frames because it requires maximum performance testing to know what it should be.
I see, because the Multi-Rotor needs extra lift power redundancy when they tilt and roll, so a protective limitation was added to make sure when the throttle input is too much, which cause the redundancy to reduce, then the limitation would kick in to make sure the tilt and roll angles to be within the safety allowance.
I am still a little confused with the way you set your collective pitch though. What I did was in the heli basic setup page, I make sure the min / mid / max pitches are mapped to my -12 0 and 12 degrees mechanical collective pitch (readings on a digital collective pitch gauge). Then I use the stabilized mode curve underneath in the same setup page to tune the mid point of my TX throttle stick map to the mechanical collective at +8 degrees which is my hovering pitch. In this way I can make sure when I switch the flight mode from stabilized to ALT Hold, the TX throttle stick are always at the mid point, to prevent any sudden rise or drop by the mode switch.
So if I just reset the min pitch to -3, without tuning anything else, can I achieve the same effect as what you did?
If you set the MIN pitch to -3, you will have to retune your stabilize curve. The percentage of pitch being used (this is called “throttle” in the code because it was originally designed for multi’s), depends on the H_COL_MIN/MAX settings. Those will define the range. So you set up 24 degrees of pitch range. At 80% “throttle” (using the multi terminology), the Alt Hold angle limiter would kick in at 7.2 degrees of collective pitch, which is well below your hover collective. With your setup I changed it so the Alt Hold angle limiter won’t kick in until it gets to 10.8 deg of positive pitch.
Say you moved your pitch endpoints to -3 and +10, now the Alt Hold angle limiter would not kick in until your collective gets to 9.3 degrees of positive collective. So it should leave just enough overhead so the angle limiter can kick in and limit frame angle before the collective maxes out, so the heli should maintain altitude.
Obviously, with heli, a user can set their collective pitch MAX to an unreasonable value that exceeds the heli’s available power, and still defeat it. So that’s kind of up the user to make sure their heli is set up correctly on the mechanical side.
I did get a chance to review my log from yesterday’s full power run. And the Alt Hold angle limiter “kicked in” when I first accelerated it. It initially limited the frame angle to about 33 degrees, even though I have the max frame angle set to 45 degrees. As it built speed it leaned into it more and accelerated at 990 cm/s/s at full 45 degrees nose-down pitch. My Ground Station Girl said 28 m/s but there must’ve been some latency on that because the actual top speed was 34 m/s when I tossed it into the turn, and then I pulled up the nose and it bled off some speed.
If I would’ve had the max pitch at 12 degrees, then the alt_hold angle limiter would’ve “kicked in”. It was at about 92%, which means it was taking about 14 degrees of bite on the blades.
I pulled the Castle logs from that run to see what it hit. And it showed 142 amps @ 45.6V, which is right around 6.5 kW at maximum acceleration
@joolayoyo The alt_hold fix was merged into Copter master this morning. I’ll submit a PR for the next point release of Copter 3.5 as well, so hopefully we can get it fixed in the stable release when it comes out.
Thanks again for bringing this issue up. I would’ve forgotten about it otherwise, because I had modified my pitch range to compensate for it in the heli I’m flying right now
Hi Yi,
Sorry to hear about your crash. I guess we’ve all been there.
Great to hear the Alt Hold works now. And that reminds me - the fix was merged into Copter master. But I have do a PR for the next point release of Copter 3.5 as well. I determined the issue did not affect all helicopters. It depends on how your pitch ranges are set up.
Hi Chris, have been having the alt hold and loiter issues as well… (limited bank and pitch angle). Just updated to Heli 3.5.5 and still same results. I noticed you have other builds there for 3.5.5 and some Dev on 3.6. as well.
-Im interested in trying the builds you provided, but can you shed a little light about any differences to althold fix v2~v3 3.5.4?
-Is the althold fix subsequently fixing loiter mode as well?
-Is your althold fix being applied to your other betas?
It is PR’d to 3.6-dev (Copter master) but I did not PR it to 3.5 as only a couple users complained about it. It depends on the cyclic pitch range that is set, as to whether or not it will cause a problem. In our dev code, which is normally a few steps ahead of Copter stable due to implementing new things, and testing, the ArduHeli 3.5.4 build has it and you can load that one.
I recently updated the firmware to Arduheli 3.5.4 final, and I noticed every time when armed and the rotor started to rotate, the controller would give me a red-yellow flash signal, and I found in the log that it was a warning message EKF-Check-2, usually followed by a EKF-Check-0 message(the controller goes back to normal flashing blue or green) , so what does this mean and how could I fix the problem?
Thank you very much, and also, I’d like to know what is the major update of your 3.5.6 FW? I noticed that it has something different in setting the parameters.
Usually EKF problems are related to vibration issues, but it can also be GPS problem. Not being an EKF expert, looking at your logs it appears to happen during spoolup when the vibrations are quite low. It is switching EKF processes because of something that causes the EKF to think the second process is better than the first. It could be related to the area you are flying from, magnetic anomaly, or multipathing of GPS signals that are being reflected off nearby objects. And as soon as the main starts turning it sets it off. I notice the number of sats jumps back and forth rapidly.
In the heli, mechanically, I’d look at things like wiring running parallel’d to the cable for the GPS/compass that may be causing crosstalk. In heli’s running wires neatly bundled and parallel’d is not a good idea unless they are twisted pair.
If you are using the internal compasses try disabling those and use just the external.
It is obviously related to when the rotor first starts turning and then seems fine after that. So saying exactly what is causing it is really hard. Try taking the blades off the heli and spooling it once and see if it’s “shadowing” of the GPS receiver during those initial moments of spoolup. Or try flying from a different location and see if it’s something location related.
The 3.5.6 firmware’s only change is the throttle curve and being able to change collective direction for the Thunder Tiger 135 swashplates. There was a bug in the initial code for the throttle curve so 3.5.6 is for long-term testing of that feature as well as other enhancements for the 135 swashplates that will be PR’d to Copter eventually.
