I haven’t tried Auto yet with the 3.6-dev build. Not until I can determine that’s it’s solid. Having a heli break into an oscillation in high speed flight is a no-no. Especially in pitch where it changes the AoA of the wing. It will climb and go vertical or dive nose-down faster than the autopilot can react.
Yeh, exactly!!
Start with Loiter and work up to higher speeds there then look at auto.
Chris, I have to disagree with your points about Loiter. It is the mode that people should be using to fly around with. It should be tune-able to feel exactly however the pilot wants it to feel. From a soft camera ship, to more sporty performance. The pilot should not be aware that he is even benefiting from GPS assistance, other than the fact that it rejects external forces and moves precisely.
IMO, the only reason why PosHold occurred, was because people simply didn’t know how to tune Loiter to fly more sharply like they liked. Particularly on stopping. I’ve got some helis flying with 20-25 m/s Loiter speed and 1/2G accelerations. To 15 m/s with 200 cm/s/s accelerations for sling loads.
Loiter is superior to all other modes for manual piloting of sling loads. And that includes piloting the aircraft into position manually, but at speed.
If the pilot wants gentle, be gentle on the sticks. The flight mode should not have artificial limits set.
And there we have the differences in pilot preferences. If I’m going to fly I do not like a augmented flight mode. Full manual control is what I like. Loiter is a tool I use for a different purpose, so it has to meet the criteria I outlined.
Today’s flight test was still a failure. All I’m trying to do is get it to hover with no stick inputs.
- position control gains set to half of default
- Loiter angle 7, Loiter speed 20
The helicopter will not hold position and the controller still oscillates in both pitch and roll.
Looking at the NTUN messages:
Position X and Y
Velocity X (we’re getting some over-shoot of the velocity target)
Velocity Y (over-shoot here too)
Acceleration looks pretty good - I’ll just post one graph of the X
So all indications are the velocity gains are too high yet. Reduce those in half (now 25% of default). The oscillation is better now.
But the heli wanders around the sky like it’s drunk without touching the sticks
Basically the only option I can think of that I have left is to reduce the mechanical rate in the helicopter’s swash linkages again to get the position controller to stop oscillating and be able to run higher gains. I did get a decent hover out of it by doing that test. But I’m not going to do that because there should be no reason I have to cripple my helicopter to slow down its response, when it works fine with 3.5.3.
OK, so I think I traced the problem with heli’s to a different area probably not related to New Loiter. I tried tuning the velocity gains by setting D to zero, and several other things, all to no avail. The heli is unstable and wanders all over the place.
My testing heli has not been acting or handling right even in Stabilize flight mode. So I flew out over the field and tried some full cyclic maneuvers in Stabilize. It immediately broke into a severe oscillation that rendered it uncontrollable. A flybar, no less! I was able to regain control in Acro with straight-thru stick-to-swash control.
So… before I can do any more testing here have to debug 3.6-dev and figure out what has happened with the attitude and rate controller from 3.5 to 3.6 to break heli functionality (again). This is the first time I have EVER seen a flybar heli break into an oscillation in Stabilize with PID’s zero’d out and just flying with VFF.
@ChrisOlson ,
I’d be interested in looking at the log file. Also please post your PARAM file. My first inclination is that somehow the Attitude feedback path is causing this due to some change to the attitude controller, if there was one. I have not kept up with the changes made to the attitude/rate controllers in 3.6-dev. So looking at changes to the attitude controller would be my first step or if the VFF path was changed in the rate controller that makes it more sensitive, essentially amplifying the attitude feedback inputs.
I can certainly understand your frustration. You bring up a great point that before we begin testing any advanced features, we should make sure the basic flight modes have not been broken in the process. So much of these advanced features rely on the aircraft being properly tuned in stabilize. So if something changed that requires the aircraft to be tuned again, then that should be provided up front. Or if the design change did not intend to change the tuning requirements then that’s good to know too.
I know @Leonardthall mentioned something regarding separating VFF from the PID in our discussion but I wasn’t sure if those changes were already made. The problem you are having could be stemming from that change. Again I’m not sure if he already incorporated this in 3.6-dev.
I determined this morning that 3.6-dev is fine. I loaded a build to test in a safe condition in a hover a couple meters off the ground to see if I could excite it and it was stable as a rock. Loading the New Loiter test build, I was able to excite it in a hover and get it break into an oscillation again. It is a pain to do that because parameters have been moved around from 3.6-dev to this test firmware. So just to be sure, I load Plane in the controller to wipe out any old params before changing firmware.
The default position controller gains were doubled in this test build, as compared to 3.6-dev or 3.5. And that was a problem on the initial test flight. It is a very strange thing to get a flybar to break into an oscillation! Where a FBL is kind of controllable when they oscillate, a flybar is not. The oscillations will start, the flybar amplfies it trying to catch up with what the swashplate is doing and it will oscillate at 80-90 degrees amplitude @ 20 Hz.
I’ll pull the logs and we’ll look them over now that I narrowed down where the problem is coming from.
Gah! If a flybar heli is not stable, then something is definitely wrong with the controller. They are aerodynamically/mechanically stable and don’t need computer control. So the computer control has to be blamed.
What changed with Stabilize mode in this branch and why wasn’t it mentioned?
Yep. And is the primary reason I prefer to test new stuff with a flybar. If something goes wrong I can recover from it with full manual control in Acro with no computers in the picture. A flybar can be flown with the EKF totally blown even.
Browsing the commit messages to this test branch, I did not see anything right off that should cause a problem with Stabilize. I will pull the log when I get back to the office so we can take a look at it. But I suspect it won’t show anything other than the Stabilize controller went into an oscillation. Need to determine what’s driving it, and there is no PID messages because that’s turned off. Unless something inadvertently broke flybar mode, but it flew fine once I got manual control in Acro. So I don’t know. We’ll look the log over in detail once I get it off the microSD.
Here’s a log from this morning’s flight when I was able to excite an oscillation in hover three times in a row. It’s not stable in Loite,r you’ll notice, which it’s going to be if it’s not stable in Stabilize.
@bnsgeyer the params are in the log file and can be extracted from there. I tried three different things to try to identify the problem area
- normal rate I-gain set at .12 for a flybar
- turn the I gain off - no difference
- reduce the VFF from the normal .25/28 for pitch/roll to .22 on both axes - no difference
All it takes a quick nudge on the cyclic and the heli will explode into action, reminiscent of trying to run rate P gain with a flybar.
There has to be something here was tweaked specific to multi-rotors to be causing this. The problem we always have in TradHeli is that applying stuff from multis to heli is like comparing the performance of a 100hp compact car to a 1,000hp F1 race car. A quad rotor, to have the same disc area as say a 700 class heli would have to have 30" diameter props on it. And the helicopter can produce instantaneous acceleration and attitude change easily 10x faster than the quadrotor. So tracing these things down can be a real challenge.
https://drive.google.com/open?id=1TcLLLCs6bMH_G5v4wxCpiPoY7lTWTzQr
I completly agree @bnsgeyer.
I don’t believe that anything has changed in the attitude controller. I think the only change related to the attitude controller at all is I added the ability to have the stick input related to a maximum lean angle of something other than Angle_Max but that is just a translation from sticks to euler angles.
@ChrisOlson Have you reverted back to a known good firmware version to make sure it isn’t a mechanical issue? (scratch that I see you did)
@Rob_Lefebvre I agree that Loiter should be able to be used the way you suggest (given pilot preference). These changes are supposed to improve that pilot response time giving a direct feel of Alt_Hold but with GPS position feedback working quietly in the background. The trick is to make it work properly, reliably, and generally!
Yes, I did. I think we need to review changes made to AC_AttitudeControl_Heli since our ArduHeli 3.5.3 development branch to current master, and the changes made here to the smoothing_gain on the angular velocity feedforward.
I made another test flight late this afternoon and got the heli to fly stable in Stabilize by reducing the VFF gain to .18. My flybar heli is decidedly sluggish with that setting, but I’m not getting the feedback oscillation from the VFF any longer with it turned down. So something changed from our working code to here. Just not sure what it is yet.
I tried New Loiter briefly with the VFF turned down and it acted like it might actually work. Not that I could fly the heli with that “tune”. But it narrows the problem to the feedforward.
I just went through the code in the Attitude Controller. The only thing I can see there is the addition of the angular rate limits but if you have them set to zero then you should be fine.
There is a chance there is some sort of more advanced issue or interaction that is beyond my skills to understand… I hope it is something simple and silly though!
Yep. All set to zero.
ATC_ANG_V_P_MAX 0
ATC_ANG_V_R_MAX 0
ATC_ANG_V_Y_MAX 0
I hope it is simple. But it is certainly not silly suddenly hanging on to a flybar helicopter that has apparently become possessed 
Maybe the problem only happens with a flybar. I’d like to try one of my smaller FBL heli’s with it, but not quite ready to risk a $3,500 helicopter to unproven firmware yet. 
There’s been changes like inverted flight added (heli only), the FF was moved to AC_PID, etc…
I pulled upstream for my 3.6-dev branch to get it up-to-date, going to build it and fly it tomorrow to make sure the problem does not happen there again.
I’m a little leery of the inverted flight change. I wanted to remove it anyway, as I have no use for it in a UAV heli, and it doesn’t work properly. So I might remove it, rebuild this branch without it and see if there’s something there that is interacting with something here that is causing issues.
@Leonardthall a couple times you’ve mentioned concerns about navigation performance. What are we looking for related to this concern? What part of the controller, and is there tunable parameters to address the concern? I got pretty promising results from New Loiter after turning the VFF down on my last test flight. Makes a big difference when the heli is stable and not on the edge of oscillation. It responded nicely (in New Loiter) to the cyclic, nice smooth braking, horizontal position accuracy was good. I could see it can be tuned any way you like it. The problems I’ve had with it so far, I’m now 100% convinced is something unrelated. Once I find and fix that I want to tune New Loiter to my liking, then try an auto flight with it.
Simply put, I am not here looking for complements, I am looking for problems and mistake 
There is now a formal D term based on the velocity error where before there was a hard coded D term based on the requested velocity.
I want to be sure that we get the right defaults that will give the majority of people a good starting point. So provided there is no issue with the position controller then the next major worry is the default selection of loiter speed, lean angle, and breaking settings.
The first time we released loiter we made the mistake of listening to people that were scared of any auto mode being allowed to move too quickly. As a result loiter did not feel good at all on the defaults and most people never understood that you need to increase the maximum speed considerably to make it feel natural. I want to make sure this Loiter does not suffer the same issues.
Then there is always the chance of a basic mistake some where.
Focus on the negative until you can’t find any.
This is PSC_VELXY_D?
From what I see there is a relationship made between the set loiter lean angle and the speed. Your instructions were to fly the aircraft at the lean angle and enter the speed that it tops out at at that lean angle. This could be done for heli, but it will be a pretty shallow lean angle and quite high speed. Is this still ok with the design of the controller? I think we need a few degrees anyway. 6 or 7 degrees gives me ~23 m/s.
The braking settings, I think, are pretty much self-explanatory. The MINA and MAXA works like Old Loiter. And we have a delay and transition time to set. I was using 0 for the delay and .5 for transition, which seemed to work pretty good at slower speeds. If the heli is cruising at 20 m/s, however, and I let go of the stick it had better not exceed the 6 degrees in nose-up braking or it will pull some serious G’s. If it is allowed to go to the frame angle max setting, that is a problem for heli’s at higher speeds. They will produce G-forces that will rip a camera and gimbal right off the belly of the aircraft.
So those G-forces can be controlled or set with the MINA param. We’ll see how much of a “coasting” we get at reasonable G-forces in braking if the frame angle is not limited by other than the ANGLE_MAX.
I think I can test all this with the VFF turned down, and maybe get some of my response back by turning up the angular accels.
So now, the next question - what happens (as far as the design of the controller) if I set my angle to say 10, but limit the speed to 5 m/s, as was the default with OId Loiter? Does this screw up some calculations for lean angle vs acceleration and velocity? Or should it still work fine?
@ChrisOlson and @Leonardthall let’s not get ahead of ourselves. Something has unintentionally changed stabilize mode. We should not move forward until we figure this out. I will look at this tonight.
@Leonardthall my thought would be to run simple step inputs in stabilize mode thru the 3.6-Dev and then your new loiter branch. The outputs to mixer should be identical, right?