Trouble with Loiter and Dual GPS

ArduCopter Traditional Helicopter
1

After more than a two year break from RC flying and Ardupilot. I thought I would drag out my old gasser Goblin 770 and try all the cool new features in Tradheli. Thank you @bnsgeyer and @ChrisOlson for tremendous work you have done.
IMG_0432A


After loading 3.6.9 L1nav and doing a fresh tune/mag cal. I’m see something similar to the dreaded toilet bowel effect in Loiter mode with dual GPS- RTK. Can someone take a look at my log file and provide some feed back, please? The first hover with loiter engaged has “Blended GPS” set and the second hover is using “Use best GPS” set. My initial thought was that the dual blended GPS was causing TBE, because that is the only thing I have change! I couldn’t see TBE in the second hover but it was a little gusty which may have mask it.

2

Steve,
I have never used dual GPS. So can’t vouch for if that works or not.

You have a terrible oscillation in the position controller:

Steve1
Steve1.png952×607 44.8 KB

The highlighted values, IMO, are tuned a little “hot”. We have gone to different tuning in the rate controller, fly them mostly on feedforward, use the PID’s only for damping of the controls. Typical P values of .035 to .045 are common, D-gain values of either zero or maybe .0015 max. I gain values of 0.25 - 0.35. The system is going to like that I-gain for high-speed flight to be stable. In my experience your heli would be highly unstable in high speed flight with the pitch axis tuned the way you have it.

I would also reduce the low pass filters to 12 or 13, except on the yaw which I run up to 25 on some heli’s.

After getting the pitch axis tuned a little more stable, try it again. The position and Loiter controller in 3.6 has been problematic for helicopters compared to 3.5 and earlier, and I’ve never been 100% satisfied with it. Have gone to using Position Hold instead of Loiter for my own heli’s. I prefer the manual control in Pos Hold, then bring the heli to a stable hover manually and release the cyclic if I need GPS position holding. Even in Pos Hold if you have the heli moving, simply center the cyclic and let it brake, it will lunge back and forth like it has gone nuts. Manually bringing it to that stable hover and then gently centering the cyclic works really good and it will hold position no problem even in 20kt wind.

So I think most of this has to do with the braking action, or tuning.

So you can fiddle with the PSC velxy_p gain to see if you get better results. And fiddle with the Loiter braking and max speed settings to see if you get better results. @Leonardthall recommended to me to set the loiter speed to 3000 (~60kts) when I first started messing with the new system in 3.6 to get the best braking action. And that indeed has seemed to work the best here. I’m not 100% certain why that loiter speed setting affects the braking even at slow speed, but it seems to.

I’m working on getting this system to work with fully-articulated heads like full-size helicopters use, where the TPP of the rotor can tilt independent of the frame due to action of the coning and flapping hinges. I’m sure that will introduce some new challenges. So if the head in your Goblin has soft dampers so it acts like the teetering hinge on a Bell Jet Ranger head the system might not play well with that either. The way the system works at present is that it totally depends on sensing frame angle for an attitude input, and more advanced helicopters with larger rotors do not work this way.

If you can tie your Goblin 770 down, give it forward cyclic and get this to happen with the rotor’s TPP, the system is going to have problems flying it. The attitude controller, in its present design, only really works with very rigid dampers in the head.

3

As an addendum to the above, my smaller helicopters which I don’t actually fly much work pretty good in Loiter and Stabilize. The big ones where the rotor can steer independent of the frame, not so much. That’s why I’ve gone to using the new Acro for my manual mode in those, and Pos Hold for the GPS holding mode. The human pilot knows how to handle a helicopter with a big rotor like that, where the autopilot’s attitude controller struggles with it.

In flight, once they go into translational lift, the autopilot does a very good job, except that no autopilot “braking” can be used in high speed flight. The conversion of desired acceleration to frame angles does not work for these bigger machines where the rotor can tip independent of the frame. The way around it, at present, is to not let the autopilot do this stuff and handle it under manual control. Even things like letting it do an autonomous Return to Launch is just plain brutal under autopilot control with these bigger machines, since it does not know how to bring one to a smooth stop from high speed flight to hover.

4

Steve I tried 2 GPS ( different brands) on a 550 Heli in 2017 on a mission. It was not good.
I always use a drone to try the mission first. It looked good.
The heli with a bigger camera camera got it wrong with 2 GPS units.
Look at the old video. https://www.youtube.com/watch?v=bX201xZGOHk
I am not using 2 GPS anymore since, and all is good.

5

IMO using dual GPS receivers introduces some inherent problems. I don’t really know the reasoning behind why that is even in the code. In all the hours I’ve flown I don’t even need one hand to count the number of times I’ve had a receiver failure in flight, because there hasn’t been any.

I would need both hands to count the number of times GPS itself has failed in flight, however. But dual receivers don’t do any good when the GPS reception goes away. And that happens quite regularly during periods of active space weather when the aurora is so beautiful at night here where we live. You can put 10 of 'em on your helicopter when that happens, and all 10 'em don’t work.

6

Sorry for the slow reply, Chris. Thank you for looking at my log file and explaining in detail the how and why. :+1:

You have found a lot more issues than I thought there would be and in area’s I wouldn’t have looked. :blush: I haven’t had the opportunity to try your suggestions yet, hopefully this weekend.

Having followed the new tuning guide and getting these “higher” values which are half of when the violent shaking starts. I can only think they are due to the rotorhead that I’m running. This Goblin is an old two blade SAB Urukay with two independent spindles and soft dampers, the worst, from what you are saying! I went to this rotorhead in an effort to try and reduce vibration while using a Pixhawk 1 Tradheli 3.3! My experience in Astar and the 206 influence my decision to try it.

HPS2_1__17059
HPS2_1__17059800×600 177 KB

The TPP of the Urukay rotor can tilt independent of the frame and may explain the “hot” tune values! I’ve never flown any high-speed flights with this machine, always been under 8m/s ground speed with a longline on. This is an old video in gusty conditions and at times into wind would have been 35kts IAS.

I agree that running dual GPS receivers has its problem. But I’m purely looking for a fall back/redundant GPS unit solution. In my case late 2016, I was flying a survey and the heli was about 600m away (30m longline/ 20m AGL). The airframe had about 66 hours on it, and it was very reliable. I grew confident (should have known better) and walk away from the GCS/ FPV monitor for a couple of minutes. Still had the TX in my hand but with only limited telemetry (RPM/Temp) and watching the heli the whole time. I didn’t know it at the time, but a GPS wire broke at the Pixhawk connector end and she went into Land mode (descending slow/ drifting downwind away from me.) The sling caught a fence and she back in into the top of a tree. I had my finger on the kill switch and as soon as I heard it hit the trees, I killed it. I learnt my lesson that day, that is to stay with the FPV screen as I could have flown her home. There was very little damage $500 in parts and the next day, I was back in the air.

7

Hey Fred, saw your video a year ago and thought…Wow, you got luck that day!

8

@Steve_Mitchell this is not why you are seeing the higher P gain values for the pitch axis. It is due to the pitch axis having more inertia than the roll axis. You can typically get more P and D gain before experiencing an instability in the Pitch axis. I would venture to say the frequency of the oscillations when you were tuning were probably fairly low around 3 hz or less. How does the aircraft feel in stabilize? Does it feel responsive at higher input frequencies?
I will try and look at your log tonight. Chris’ rate PID recommendations could work. I would guess that this has more to do with the position controller PID gains. BTW what is your ATC_INPUT_TC?

9

Steve, indeed this style head is going to run smoother than a rigid head. It has the equivalent of flapping hinges, so borders on being more of a fully-articulated head than a teetering head like a 206.

The problem is, since it can steer independent of the frame, that will allow the “hot” tuning values. But it will also cause the autopilot to chase the helicopter like a student pilot learning to hover. Maybe @bnsgeyer has some ideas on how we can tune for that style head to prevent the chasing. What happens is the autopilot thinks it needs, say, 3 degrees roll to the left to correct attitude. So it makes this control input. The rotor tilts in that direction and the correction is made. But the autopilot doesn’t sense any change in the frame angle, so over-corrects. And it just keeps doing this and chasing it all over the place.

Instead of converting desired accelerations to frame angles, which does not work for more advanced heads, it should be using the actual sensed accelerations to fly an articulated head. I’ve had this discussion with @Leonardthall before too, in that converting desired accels to frame angles is problematic for helicopters. Works great for multi’s because that’s all they know how to do. But helicopters are more dynamic machines and considerably more complicated than multicopters.

I think I would take the extra GPS off, if it was me. And put a good FPV system on it to recover from loss of GPS. That has worked well for me in several hundred hours of flight time with UAV heli’s, and lost track of how many times GPS went haywire and just flew it home. At least two dozen times I’ve aborted flights due to GPS anomaly.

I have all the failsafe stuff for the EKF disabled in my heli’s so they don’t do something stupid like land in trees. And with the new acro they can be flown easily with the EKF totally blown or wonked out. The new acro doesn’t care if it thinks the heli is flying upside down as long as the pilot knows which way is right side up. If it thinks the attitude is off and the pilot corrects it, it just bleeds the desired attitude off to what actual is, and it don’t matter what it thinks actual is.

With FPV the new acro is just like flying the A-Star or 206, and if the attitude solution is blown, it’s like flying the big one in turbulence. Not fun, but you can fly it and bring it home.

That is a far better backup than dual GPS receivers, and something I wanted in heli for a long time - independence of the attitude solution and still be able to fly it like an old flybar.

10

@Steve_Mitchell I think what I would try to tune your articulated head is to use just VFF with a bunch of I-gain and turn the P and D gain off. Or maybe use a very low P-gain value like .01 - .02, just enough to damp it a bit.

This works for flybars, which also steer independent of the frame, except can’t use any P-gain at all with a flybar or it makes it shake like a leaf in the wind.

Another thing you could consider is that we now have quite nice telemetry right to the RC radio with the FrSky passthru and Alex’s quite excellent lua script for the Taranis or Horus. This now makes the use of the ground station computer/tablet optional, except for loading flight plans or making settings. I’ve gone to this this year, it works good for me. You have all the same warnings and messages on the RC that you have on the GCS. I have small 4.3" TFT FPV monitors mounted on the radios. I don’t use FPV goggles for commercial flights because they’re not legal without a spotter.

So this gives you everything you need to fly the heli in one hand-held unit. Got First Person View of where the heli is, and what it’s doing, with a wide-angle dedicated camera. Got all your controls. Got all your MavLink stuff. With the newest ver 1.8.0 version of the scripting can integrate up to six additional FrSky sensors for Erpm, Rrpm, engine temp, backup altimeter, FrSky SPASS-70 airspeed indicator, OAT temp sensor - or any combination you want. And it’s all on one screen.

The only thing you don’t have is the moving map display. But that’s not needed anyway when you got FPV because it’s better to keep track of where the heli is on FPV and visual reference so you can abort and fly it home at any time it may be required. Sure, you can set the RC radio down and walk away from it too. But you’re less likely to do that than ignoring a computer screen you normally can’t see in sunlight anyway. Trying to see what’s going on with the ground station is actually distracting from the flying task. Having it on the RC, you got it all right where it’s needed for manual intervention at any time, and on a display that it’s not a problem in bright sunlight.

I can autorotate a heli on FPV with that little 4.3" TFT monitor. The wide angle camera gives a pretty good reference of depth perception on the screen so estimating altitude and speed is pretty easy with it. Little bit of tunnel vision with 170 deg FOV. But it’s my main tool when I’m flying. The actual telemetry screen I glance at now and then and scan it. But the visual and audio feedback from the FPV is my main thing to keep track of where the heli is and what it’s doing. And it has zero latency.

G0016804
G0016804.JPG640×763 301 KB

11

In Stabilize there is a fair amount of deviation in the actual vs desired attitude. But I think, IMO, we need to get rid of this constant primary GPS changing back and forth.

Screenshot%20from%202019-07-01%2014-42-23
Screenshot%20from%202019-07-01%2014-42-231011×461 81.6 KB

It does this 5 times in less than a minute.

Another thing that should be considered is that there is a setting for EK2_IMU_MASK that sets the number of EKF processes that can run. I prefer to set this to 1 so it only uses the primary IMU and doesn’t swap back and forth.

All this dual stuff that got put into the design is kinda like the old argument on single vs twin-engine airplanes. You’re twice as likely to experience an engine failure in a twin. And according to NTSB stats twice as likely to die in a twin if you experience said engine failure :astonished:

12

I think @ChrisOlson makes a pretty good point here. It is possible that the way that Leonard designed the position controller does not predict the correct control inputs to achieve the desired acceleration for heli’s. I will have to look at this more.

My current thinking is that there is lag being introduced in how the desired pitch and roll angles are being calculated. So the acceleration needed is never being achieved or it is achieved some delta time later. So the target aircraft gets ahead of the actual aircraft and its off to the races. I don’t know that there is sufficient weighting on making the requested acceleration match the actual accel. Taking and feeding back velocity and position error only creates more lag because velocity is one integration removed which introduces 90 deg phase lag and position is two integrations removed which introduces 180 deg of phase lag. So feeding these back will only help so much and then it just causes problems. We have to get the acceleration right to begin with.

13

The position controller just outputs the desired roll and pitch angle so if it isn’t getting that because the attitude controller isn’t tuned properly or there is a basic lack of control then it will be wrong. In this case you will need to work with much softer tune and lower expectations.

Yes the defaults are set around the response time of a multi so you may need to back them off for some heli’s.

Basically you need to get the attitude control tuned up as well as possible. Then you will be able to tune the pos controller and loiter to operate within the limits of the aircraft.

14

really the parameter that really sets the quickness of the target aircraft for the attitude controller is ATC_INPUT_TC. That dictates how the target aircraft achieves desired attitude smoothly. And then, like you said, the tuning of the PIDs and FF must be such that the aircraft achieves the desired attitude.

But your premise is that horizontal acceleration is primarily a function of attitude but that is not really the case with Heli’s. Certainly it is a big contributor but for heli’s the tilt of the tip path plane also contributes. I have a heli with a rotor head similar to Steve’s. I will have to investigate this more. I was never really happy with how it performed in loiter but I never spent much time trying to get it right either.

15

@bnsgeyer Thanks for explaining it Bill, it makes sense with heavy tailboom and RF900 radio out at the tail rotor to. Yes, the pitch frequency of oscillation was low/benign. In Stabilise mode It feels like flying an old Bell47, not going anywhere fast! The collective around hover is very soft. The rotor is run at 1500rpm with 800 blades.

Does it feel responsive at higher input frequencies? Not sure what you mean by higher input frequencies?

My ATC_INPUT_TC is 0.15

This is a little over my head but I willing to learn. I’m guessing that this issue needs to be sort out one day if Tradheli is going to fly fully-articulated heads?

16

@ChrisOlson After seeing all the primary GPS changes in the log file, I agree with you that the second GPS needs to go. If there was another GPS PRAM setting that gave me the option to use the 2nd GPS only if the 1st had completely drop out for 3seconds or more, then I would be inclined to leave it on. I’m fine with using an FPV system for backup. I’ll change the EK3_IMU_MASK to 1.

I’ve never used acro and would like to try it. Are there any gotcha’s in set it up? Also, set up all the different failsafe (EKF, GCS, TX and mavlink radio’s) correctly is becoming too complicated. Reverting back to acro and FPV sounds way more appealing and simpler.

Okay, I’ll try this next time I’m out in the paddock. My backyard is to small for anything other than basic hover testing in Stabilise mode.

Thanks for the suggestion. I’m already using it and love it. Couple changes to it would be nice but not important at the moment. I’ve got the Frsky gas suite but would like an extra timer on Alex’s lua script. This is my current setup with medium size FPV screen and Connex ProSight VTX/camera. Lots 3D printer bits😊.

IMG_0391A
IMG_0391A807×605 187 KB

IMG_0390A
IMG_0390A807×605 160 KB

17

@Leonardthall Hey Lenoard, this is the same heli that you and Tridge tried to tune at the Canberra developers conference in 2017.

18

ATC_INPUT_TC,
ATC_ACCEL_P_MAX,
ATC_ACCEL_R_MAX,
ATC_ACCEL_Y_MAX,
ATC_RATE_P_MAX,
ATC_RATE_R_MAX,
ATC_RATE_Y_MAX,

Are the main input shaping parameters that define how the aircraft tries to react to the commanded attitude change. They are sort of the Jerk, Acceleration and Velocity components of the target response. The Accel and Rate parts are also used as limits when recovering from a large disturbance.

exactly.

It is a good first order approximation but I agree there is a lot more going on with a heli like this. The disconnect between the tip path and the flight controller adds a bunch of questions. However, the PID loop on the position controller is also very forgiving if tuned well.

On the two gps solution it currently switches based on which is reporting the best performance. We are looking at being able to assign each gps to it’s own EKF to do it internally.

It all fell into place when you said that!!

1 Like
19

Acro is really easy to set up. The new acro uses the BAL settings for pitch and roll to set how fast you want it to bleed off like a flybar. If you set those to zero it’s rotate and hold like old acro. If you set them to 3 it’s almost direct stick to swash.

1 Like
20

Yeah, I think this is the problem I have with Pos Hold. Aris at Velos Rotors has noted the same problem, and they are flying articulated heads on their machines too. It’s fine as long as the pilot flies it manually. And it’s fine once it goes into flight in auto mode. It doesn’t seem to depend on the frame tilt so much in auto for some reason. As long as it reaches the target speed it doesn’t care about that.

It’s just the hovering part in GPS modes, or allow it to do any sort of autonomous braking, that it can’t do. I modified the braking behavior for auto mode, and that modification is in the ArduHeli build. It’s still not perfect but it’s a lot better than the stock code.