Ok, cool. So we need to test auto flight performance too.
One of the thing on the to-do list for heli is to implement the L1 Nav controller from Plane for heli. The current nav controller is badly inadequate for helicopters. In high-speed flights it’s more like the heli averages the waypoints instead of actually hitting them. Now might be a good time to start looking at that more seriously.
Hi Chris,
I suspect you have not set your WPNAV settings up optimally for the heli or what you want from your mission. The copter navigation controllers should perform like they are on rails. The L1 controller follows the track much more loosely in comparison.
I would suggest we work our way up to 30m/s in the loiter controller settings then start testing Auto missions. The loiter stuff will make sure your navigation controllers are tuned properly and then your auto mission stuff should be pretty easy to sort out.
It does, in the middle of the lines. The problem is that at typical heli high flight speeds, it will shortcut the turning points really badly. This is because the leash length is very long, and goes around the waypoint track much faster than the aircraft. So the leash pulls it around and down the return leg before it even gets close to the waypoint.
I have to use very large overshoot lengths on mapping runs to make sure it actually covers the needed area.
For magnetometer flights, we have to do a crazy mission profile where we change speeds to slow it down around every corner, then accelerate again down the new leg. ie: 17 m/s slowing down to 10, then 5 m/s before the turn, go around, then speed back up again.
The other problem that we would hope L1 would solve, is being able to get the heli to corner like an airplane. Currently, it slams on the brakes before the corner, then accelerates out of it. So it is destroying and creating kinetic energy, instead of taking advantage of the rotor disk which acts like a wing, allowing the heli to pull many G’s with no power input.
This is probably not the best place to discuss the L1 controller requirements further but it would be good to get a discussion going to summarise what the Heli community sees as the unique requirements of heli’s, how the L1 controller can help that and the limitations of the current navigation controller.
I suspect the best solution will be a combination of the current controller and the L1 controller and I have some ideas based on that.
Lets try to keep this discussion thread focused on Loiter and the position controller changes and their impact on Auto missions. (no offence meant here at all, I do want to address the navigation concerns)
I tried another test flight this afternoon to see if I could get New Loiter to “feel right”.
My question for today is, what is the settings for New Loiter that will make it “feel” and act like Old Loiter defaults?
Edit:
I’m going to strike what I wrote above because it loses focus and I was just trying to get a “feel” for New Loiter and what the settings do. That is not a problem with New Loiter. It is a problem with me trying to figure it out and become familiar with it.
Here is the issue that I’ve noticed with New Loiter when I’m talking about moving the heli around.
Some points:
I think we’re losing focus because it’s been modified to provide a mode that multi’s can fly around with like DJI’s “GPS Mode” or whatever they call it.
So here’s the problems (so far):
The position controller went into oscillation in my heli with the defaults. Why? I looked at what we adjusted. Postion XY P gain and velocity gains. I have to look this code over in detail and try to figure it out. But are we translating desired velocity and acceleration to frame lean angles?
New Loiter (so far) does not have the same precision in holding or rejecting wind. I noticed that right away today when I loaded 3.5.3 in to compare. it tightened the heli right up putting 3.5.3 back in it. What would cause that? Position controller gains too low? I mean, it holds position fairly well. But not with the precision of 3.5.3.
I’ll see if I can generate some more logs. The logs from today are terrible because I changed settings 20+ times trying things out.
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.
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
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. 
