New Loiter Mode - Alpha Testers Wanted

Here’s what I’m looking at, attempting to get this really “locked in” (what an engineering term!)

Looking at the target velocity vs actual in New Loiter it looks like my velocity gains are OK - these are from the 626.

But I cannot 100% get rid of the slight oscillation in the position. In the old Loiter controller the POS_XY_P gain was 1.0 default, and normally did not have to mess with the Loiter settings to get good results. This is with PSC_POSXY_P set to 0.5 and it still slightly oscillates.

OK, so in the old controller the velocity PID’s were 1.0, 0.5, and 0.0 default and they worked on the velocity request instead of the velocity error. They convert the desired speed towards the target to a desired acceleration. The resulting accel becomes a lean angle which is then passed to the same angular controller used in Stabilize.

In New Loiter those were set to P - 2.0, I - 1.0, and D - 1.0 by default. Setting those to the old values and just playing with the D gain can make the heli act anywhere from totally drunk to not too bad. I’d have to pull the params to see where I ended up on this last test flight.

I wish there was some sort of sensible tuning procedure for these PSC gains instead of making stabs in the dark to try to figure it out. After comparing one heli with New Loiter side-by-side with another one in Old Loiter this morning it was obvious New Loiter is not quite ready for a full-blown Auto test yet.

This is what I’m trying to get New Loiter to look like - taken from the logs from the Comparison Heli flying Old Loiter. New Loiter is close, but no cigar.

I just recently got a new pixracer tuned up as a beta tester so i can test before I add to my larger quad. I can just upload this as custom firmware and then add my param file and do a few tweaks to the new loiter param, are they at somewhat of a default already and just looking for more input from others so this isn’t a sluggish as the old loiter?

Rob,
I totally agree with your opinion of Loiter & PosHold.
I love the flexibility offered by Arducopter. DJI has no where near the customizable configuring that is offered with Arducopter. I never look back to DJI as an option.
This statement:
"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."
This still is a MAJOR problem with Arducopter, There is very little information or understandable guides to tuning loiter Parameters. They remain a mystery that must be sorted through.
I would say that it would be a far better use of developer resources to create some loiter tuning guides & videos than revamp the entire Loiter Mode.
I honestly can say I am still learning Arducopter and find some areas of the parameter setting very vague. Loiter parameters & related parameters obviously need a good review & better explanation as per your statement above "people simply didn’t know how to tune Loiter to fly more sharply like they liked."
the biggest problem for me is how to tighten the Attitude in loiter to make it much stiffer and less wobbly in the wind. I love the stability of ALTHOLD… it is unbelievable…PID is nearly default except YAW, I just wish I could get Loiter to feel as tight for aircraft Attitude (not Position Holding) ) as ALTHOLD.

That’s actually what I liked about Pos Hold. It has the “feel” and handling of Alt Hold (or Stabilize), the position holding of Loiter, with no speed or acceleration limits (other than the Stabilize tuning), and I think is by far the best mode for helicopters if you want to fly an augmented flight mode. The minimum braking angle for Pos Hold is 20 degrees. But I forced to accept 8 degrees for a heli, and it works really well.

I also agree about the tuning thing for Loiter. I’m waiting to hear from some other testers on New Loiter to get feedback on the slight position oscillation I’m seeing with it. I don’t know if it’s just because I’m flying a helicopter with it, and maybe it’s ok with multi’s?

I have not yet been able to tune that out here. It looks ok when I watch the heli, and the slight oscillation is barely noticeable with the naked eye. Unless I compare with Old Loiter, and the log shows it’s not quite as precise. So I think there might be some tweaks needed to the Position Controller yet. But I don’t know if those tweaks are in the settings, or needed in the code on how it’s applying the correction to the velocity error instead of the velocity request, and then passing that to the angular controller that is used in Stabilize.

@Leonardthall

Just had a thought, based on some of the things Chris has been saying. Not sure if this is already in the code yet, but it seems like not. From what I’m reading in Chris’s comments, is that he’s having to set the angle limits very low because helicopters are so “slippery” at speed.

I think what we need for heli (if not also for multis) is two angle feedforwards. The first, is the speed-vs-angle feedforward. The second is acceleration-vs-angle feedforward. The total angle feedforward would then be summed.

Now, this is still a gross over-simplification of the true aerodynamic model. The real model would have to consider the angle of the rotor disk vs. a 3-dimensional estimate of the relative airflow, and then considering the collective pitch of the rotor blades.

ie: A helicopter with 45 degrees nose-down pitch and high collective setting, if it is starting from a stand-still, will be achieving a very rapid forward acceleration. However, if the helicopter is already in high speed flight, with a rapid downward velocity (ie: it’s flying at 45 degrees downward) that same 45 degree no-down pitch angle will result in nearly no accleration.

Similarly, if a helicopter were at a standstill, and then was given a 45 degree nose-up pitch, we would expect something like a 1G acceleration rearward. However, if the helicopter were already in a fast forward straight and level flight, and we commanded 45 degrees nose-up pitch, the heli would experience very rapid upward acceleration, on the order of 6G.

This is the complexity of the aerodynamic model. And why I really believe that the entire navigation system needs to be done on a 3D velocity and acceleration domain, instead of 2D North-East plus Altitude.

I don’t know if the bug with the velocity error limit is causing the slight position oscillation I’m seeing. I have to rebuild with that change and see if it fixes it.

I think New Loiter should provide all the same functionality as Old Loiter for helicopters at slower speed. Higher speed, I don’t think it’s suitable for heli’s. The braking action is not smooth enough. The angle you set only has to do with pilot inputs, not what the FC will do otherwise. So what happens is, if you let go of the cyclic with the settings for the brake suitable for slower speed, it flares the heli. The it seemingly goes, “WHOA! We hit the MINA accel way faster than what we thought.” And it porpoises the heli trying to maintain that acceleration, which changes quite a bit with very small frame angle changes in a helicopter.

Can set the transition time longer to make it smooth. But then it’s too slow for precision hovering work.

Position hold works better for me for high speed. I set the angle at 8 degrees, which provides fairly aggressive braking from high speed flight. But it’s smooth because no acceleration limits are being applied. Two second transition to 8 degrees nose-up, the acceleration hits its peak then gradually bleeds off as speed decreases. And the heli smoothly transitions from the 8 degrees nose-up to hover attitude as it comes to a stop.

So I guess I’m fine with New Loiter, get the position oscillation problem fixed, and as long as nobody gets the idea to remove Pos Hold thinking New Loiter replaces it.

Hi Chris,

Could you give me a log with Pos hold set the way you want it and Loiter set to the equivalent acceleration minimum acceleration (8 degrees is 136cm/ss). If you could do the same basic flight plan for each mode that would be great!!

I suspect what is happening is the higher lean angle input is causing the offset to move backwards when you release the sticks causing immediate breaking. A log will help me understand what is happening.

I will think about how we could address this if this is the case.

Thanks!

I think I understand what you are saying but Loiter works under the assumption that Alt_Hold is doing it’s job and therefore the aircraft is not accelerating vertically when you pull back. The Alt Hold assumption also means that the aircraft will not be falling rapidly. Basicly, because we are using Alt_Hold, Loiter assumes that we are always providing 1G of force vertically.

Generally I agree that we need to move to a 3D velocity acceleration domain. This is trickier than it sounds as we need to consider drag and lifting forces. I have not found a suitable solution yet… Fingers crossed.

@Leonardthall I was actually more concerned about the position oscillation I seem to be getting. How can we fix that? I was going to merge the bug fix for the velocity error limit in my heli code and build it and try it again.

Can you send me a log?

I been testing different firmware and had to make sure I got the right one. This one should be a log where I had it in Loiter without moving the sticks. What I was looking at was target position x and y vs actual. I didn’t sync the scaling in the graph - I just snapped the screenshot to make sure this is the right log where you might be able to tell something.

https://drive.google.com/open?id=14fR8Kj4lUdbeni8eGtZuFOilS5aSVm0v

Hi Chris,

You are flying your own version of this arn’t you? Could you send me a link to the repo you are using?

There seems to be some strangeness in your log. I am trying to work out where it is coming from but I can’t find it in my code.

Yeh, I am definatly seeing something strange that I am not seeing in my logs. Your repo would be really helpfull.

@Leonardthall the repo is 3.6-dev cloned with Randy’s lthall-new-loiter5 branch merged, then code added to fix the broken DDVP drives in the current Copter code so I could fly it in my heli with a DDVP drive. Then the name changed to ArduHeli, which is what I name any custom branches to designate that it is different than Copter in one respect or another, and so I can identify the build later if I want to go back to it.

Just to clarify the history of this branch, Leonard; I cloned 3.6-dev some time back. You’ll see on Nov 23 where I added the DDVP fix. Then I rebased it to get current with 3.6-dev. Merged Randy’s lthall-new-loiter5 branch. So it is not exactly like Randy’s branch because his branch was aways behind 3.6-dev at the time. But there was no merge conflicts when I pulled the lthall-new-loiter5 branch in to build it for heli testing.

Yes, I understand that Loiter is assuming Alt_Hold is working. But that is why I call it 2D North-East + Altitude. The concern, is that without considering a complete 3D airflow field, the system will never perform as well as we’d like. We’ll always be chasing our tail on this as the altitude controller and 2D position controller fight eachother, bouncing off eachother’s limits.

ie: The Loiter controller shouldn’t be commanding things that the altitude hold controller can’t do, and then we just react to the deficit later.

1 Like

Unfortunately we don’t have the level of understanding required to do that right now so it is up to the tuner to ensure that the Loiter parameters don’t take Alt_Hold past it’s ability to control the altitude.

Then as dev’s we need to do our best to ensure that the XY and Z position controllers handle when they are overpowered in an elegant way.

When we have a unified 3D approach well enough defined that we can implement it I am all for doing it. For now though we need to focus on ensuring the current Pos controller is doing it’s job as well as it can.

Hi Chris,

Well it has taken quiet a few hours but I have worked out what is happening. Your choice of low maximum velocity and relatively high maximum acceleration is resulting in a high gain on the breaking behaviour that is then oscillating.

So the problem here is I don’t have a Breaking Gain. I have hard coded it. Bugger… I have missed a parameter.

So the aspects we need to control here are:
Maximum distance the controller can use to correct position.
Maximum velocity the controller can use to correct position.
Maximum acceleration the controller can use to correct position. (WPNAV_LOIT_MAXA)
The delay before the aircraft starts to break.
The speed with which the aircraft transitions to full braking
The maximum braking acceleration (WPNAV_LOIT_MAXA)
The breaking gain, we could use PSC_POSXY_P

I think I have mixed up a couple of items here in an attempt to keep the number of parameters down.

I have used WPNAV_LOIT_MAXA for both the maximum correction acceleration and the maximum braking acceleration.
I don’t have a breaking gain and hard coded it to 2. I should make it a separate parameter or use PSC_POSXY_P or half PSC_POSXY_P.

I will talk to Randy about it some more and sort out a response.

On a side note…

I have also been thinking about having a parameter that represents the maximum lean angle at maximum speed. This would let people use higher accelerations and lean angles when stationary but then at maximum speed reduce the maximum lean angle that the pilot can access. But it would have some ramifications.

So in the situation of Heli, you would get to have 45 degrees at hover but 10 degrees at full speed. That would mean if you pushed forward at full stick it would start out at 45 then reduce to 10. If you then pulled back at full speed it would lean back to 10 and gradually increase to 45 as the speed slowed. This would mean that your maximum turn angle would be 10 degrees at maximum speed though…

For now I am going to focus on getting what we have here working properly and then we can look at the next steps…

Thanks Chris.

Ok, cool. I was going do another build with the bug fix for the velocity error limit and see if that was doing it. What’s the best branch to pull from for doing builds to test the latest New Loiter changes? Just use Randy’s lthall-new-loiter5 branch?

Yeh, I just have to talk to him about the fix.

Hi Chris,

The commit:
AC_WPNav: Breaking gain is based on VelxyP
is the one you want.

All it does is effectively set the braking gain to Vel P /2. This should be a nice conservative value without adding a new parameter.

Randy and I have come up with a way of dealing with the lean angle issues but that will take some time. But it is just an extension here so we need to make sure this is all working correctly first.