Re: How to fix porpoising

[Leonard Hall]

First step is to get a collection of .log files that show the problem. Even better if it has RAW turned on and at a higher rate for the ATT. This starts us off on the right track because we can start to examine the relationship between the various loops in this flight mode.

I have some ideas about how we can possibly handle this but without this we are just fumbling in the dark.

Thanks everybody for your help!!!

Leonard


On Tuesday, 8 January 2013 04:32:00 UTC+10:30, robert.lefebvre wrote:

Just wanted to get a new email thread started to talk about the porpoising problem at high speeds with the new Alt_Hold controller. 

The inertial Alt_Hold is much better than it was before, but this problem is new.  I had made attempts in the past to fly and high speeds in Alt_Hold which generally were unsuccessful, but I don't think it was prone to this porpoising problem.

I think partially what is happening is that the Alt_Hold controller now is pushing the aircraft to higher speeds than ever before.  I couldn't believe when I saw 100 km/h in a straight line on my little 450 heli.  When you pitch it forward, the AH controller automatically dumps in tons of throttle, and this makes it accelerate to a very high speed.

Typically when flying like this in Stab, I have difficulty doing the same thing, as my collective control isn't good enough and I either end up rising or falling, and have to abort the run.  Now in AH, I can hold 45° forward pitch for long periods of time.

However, I have had instances where I did get it up to a high speed in Stab, and I didn't see this effect, at all.

I think what is happening is simply aerodynamics and controls theory.

At high speed, the pitch response of the copter is very sensitive.  Just the slightest thing threatens to pitch it back.  I think this is made worse with the AH throttle controller, possibly giving little bursts of higher throttle.  It tips the disk up just enough, and then the oncoming "wind" catches it and tips it back, which is a highly divergent control problem. Once it starts tipping, it's hard to catch.

At the same time, when it pitches back, the lift is greatly increased, and the copter shoots up.  The AH controller sees this lift, and dumps collective, at the same time as the pitch controller tries to push the nose back down.  The pitch controller is aided because the collective just got dumped, so it over-responds. Likewise, the noise pitching down helps the AH controller to reduce lift, and it over-responds.  So then we set up this generally diverging pitch/altitude oscillation.

So what do we do?

One idea I've had is to automatically reduce the gain on the Z-axis controller at higher speeds.  Likewise, reduce the gain on the Stab_Pitch_P term.  Notice, I suggest Stab_Pitch_P, not Rate_Pitch_P.  I think maybe that controller should still be highly gained to try and prevent the rate error which leads to a pitch back.  But once the pitch back has occured, I don't think the Stab controller should try to push it back so fast.

Likewise, I think the Thr_Accel_P and I should be de-gained.  I don't want them responding to the change in lift as much, instead, we should respond to actual altitude errors more.  Presumably people won't be flying at 100 km/h, 2 m above the ground?

Anybody else have ideas?

Rob

[Robert Lefebvre]

Ok, I'll see if I can get something.  I didn't have data from before because of the logging issue.

Do we want Z-Accel PID data, or pitch rate PID data, or both?  I'll try to get both.  But obviously can't on the same run.  I'll disable my Z-Accel FF hack.

I don't this should hold up 2.9.  This is a "have your cake and eat it too" thing.

--
 
 

[Robert Lefebvre]

Ok Leonard, here you go.  I hope we get something out of this because it was miserable collecting the data!

3C (warm actually!) with winds 40km/h gusting to 60km/h.  Amazing I could even fly!

Now, the bad news, is that for some reason the PID logging didn't come in.  You'll see some in the second half of the log, but that is after when I tried tuning the yaw.

I'm not sure what you'll be able to see.  But basically I took off, did a couple high speed passes, saw the porpoise action, and then started cutting back gains and kept trying.  At no point did I get what I thought was an acceptable result.  Sorry, I haven't had a lot of time to look at this.  At first glance, I can see that the Pitch/Pitch_In data looks TERRIBLE.  I had no idea it was that bad.  The roll is not so bad, but the pitch is really bad.  Strange.  Must be because of the extra inertia in this direction.  Also keep in mind, when flying forward, the wind and downwash tries to push the tail boom down.

I guess I have to keep in mind I was dialing back the Stab Pitch P gain quite a lot.  At one point I had completely lost control and had to crank it up to save it.

I can see the Gyro data looks not too hairy, and the Accel Z is decent, can clearly see a signal in that.  But the Accel X and Y are sorta bad?  Probably to be expected on a heli.  

I can't find too much useful data though, hopefully you can.

On 7 January 2013 18:33, Leonard Hall <leonar...@gmail.com> wrote:

Perfect mate!

 

INAV, RAW, and Pitch PID.

 

 

From: Robert Lefebvre [mailto:robert....@gmail.com]
Sent: Tuesday, 8 January 2013 8:53 AM
To: Leonard Hall

Subject: Re: [drones-discuss] Re: How to fix porpoising

 

Oh, INAV logging?  I wasn't even aware of that one.

 

So how about INAV and Pitch PID logging?  And Raw.  Best case?

 

On 7 January 2013 17:20, Leonard Hall <leonar...@gmail.com> wrote:

Hi Robert,

 

What I do in these situations is I go into the code and I manually set PID loop on.

But even if you don't have any PID loops being monitored and just make sure the INAV message is on it would be great!

 

Thanks again,

Leonard

[Robert Lefebvre]

And heres the Tlog in case that helps.

[Robert Lefebvre]

Oh, and so I did play around with degaining things and just couldn't get anything good out of it.  I still do think that we need to stop using the Z-accel Alt_Hold at high speeds and just use the Altitude error.  But lowering gain on pitch didn't do anything good.

Can I just try turning the Z-accel Alt_Hold off?  There's a param for that?  I'd like to keep using the improved height estimation, but not the direct Z-accel response.

[Robert Lefebvre]

Gah!  This new group is not playing well with my Gmail, I keep responding only to Leonard.

Leonard, I had a closer look at the data, and there's definitely some good info there.  I have prepared... what became an info-graphic which details some important points and highlights the worst places.  The data tends to be noisy and you can't see the signals if you don't know what to look for, so I highlighted them.

But first to answer your question, if you are looking at *altitude error*, you won't see it there. I looked at that, and I agree, altitude control is very good.  This shows up only in a "short" amplitude but high frequency domain, and you see it in the Z-accel, INAV climb rate, Throttle Output, and Pitch Error.  You even see it in the Y-gyro!  As I say, it's a violent shaking, not really an altitude problem.

A couple points:

The worst and longest instances of the porpoising actually occurred on upwind legs.  Since the GS is much lower, I could hold it for longer.  On the downwind legs, it goes so fast I have to turn around quickly.  I circled in red what was the worst and longest case.  I think after that point, I started dialing back on the gains.  That agrees with my memory.  I have only shown a pitch/pitch_in graph, but the roll/roll_in and yaw data will have the effect too in some places, because what happens is the oscillation sets up, and gets stronger towards the end of a leg, so I'd try to stop and turn around.  The roll for the turn ends up with a roll oscillation, which then gets into a terrible yaw oscillation too.  Sometimes I had to basically hands-off sticks and let it settle down.

One thing is clear, the baro data looks very clean.  I graphed the Baro Alt from CTUN, and it's super smooth.  Shockingly so,  actually.  So I don't think this is coming from aerodynamics/pressure.

Then notice, the noise shows up on the Z-axis accel, and then in the INAV climb rate.  And then you see the throttle output also lighting up in response.  

I plotted the INAV Climb Rate vs. the Baro Climb rate, and that is interesting.  It looks like sometimes the Z-accel is what drives the INAV CR to oscillate and then winds up affecting the Baro climb rate which is actually just collateral damage of the porpoising.  But two other times, it's not clear who started it.

I was also surprised to see that the Angle Boost might be a factor.  I'm not sure if it's cause or simply effect of the pitching motion.  But it probably isn't helping the situation.  In stabilize, I believe I have angle boost turned off. I'd like to try doing so for Alt_Hold as well.  Is there an easy way?

I think looking at the data, the solution is fairly simple.  At speed, the altitude controller should absolutely not respond to climb rate or Z-accel. It should only respond to altitude errors.  Altitude is being controlled extremely well.  And I hope nobody is attempting high speed nap-of-the-earth flying so we could tollerate an error of 1m easily.

Again, I come back to the idea of some sort of fuzzy-logic controller, which uses 100% the Z-accel controller below 5m/s, and 100% Altitude above 10m/s, with a blending zone in the middle.  Because landing with the Z-accel controller is FANTASTIC.  It's just in the higher speed regime that it starts to act up.

Rob

On 8 January 2013 07:54, Leonard Hall <leonar...@gmail.com> wrote:

That would be great Robert,

 

Maybe you should wait for some better weather and do pass that you don't find too risky but still shows it. If that is possible at all.

 

In any case a calm day will make everything that much easier to diagnose.

 

There is no rush on this (from my end anyway) as I can't see this getting into 2.9. And I suspect that it won't be an easily solved problem.

 

Chat soon and thanks for your time and patience with this one!

 

Leonard

 

 

From: Robert Lefebvre [mailto:robert....@gmail.com]
Sent: Tuesday, 8 January 2013 11:21 PM

To: Leonard Hall
Subject: Re: [drones-discuss] Re: How to fix porpoising

 

Well, the error probably is less than 1m.  20 cm probably is what we are dealing with.  The thing is, with the speed, and the frequency of it, it is actually quite bad.  We might be talking +/-20cm at 2-3Hz at 50-100 km/h.  I would not be surprised if it does not show up in the baro data.  But what about inertial altitude estimation?

 

Unfortunately there was only so much I could do.  It was dark and windy, and the effect can get very bad very quickly.  I actually had to modulate the pitch to avoid it getting too bad because it can become so violent it could break up the heli.  Also, I can only see the lights.  So it was harder to judge how bad it was.

 

I'll look at the data more thoroughly today.  Maybe I'll have to shoot video on the weekend.  It's real, and it's bad, but maybe not what you were expecting to see. We won't be able to fly high speeds like this.

 

 

 

On 7 January 2013 23:58, Leonard Hall <leonar...@gmail.com> wrote:

How much variation are you seeing?

Your logs say that during the first two runs in Alt_Hold you only got more than 1m from your altitude set point once, and that was during a fast decent. I am talking about the calculated inertial altitude that is being used to control the height. In fact, during any single fast run where I can see you with full Pitch input, it only varies by about 20cm. (I only looked at the ones that lasted more than about 3 seconds

 

It is a little hard to tell exactly what is happening because the runs seem quiet short and there doesn't seem to be any obvious proposing that I can separate from your control input.

 

I am wondering if this is an aerodynamic effect that is pushing the Baro around. If this was the case, no amount of tuning would help, you would need to do something physical to change the way the air pressure is behaving around the APM.

 

Chat soon,

[Robert Lefebvre]

Leonard, Randy:

What is the difference between Throttle_Hold and Throttle_Stabilized_Rate?

The look the same except the latter one includes a check for zero throttle.  What's that about?

So, trying to understand the numerous controllers we have here:

Currently Alt_Hold_Throttle is Throttle_Hold

In Update_Throttle_Mode, case: Throttle_Hold has us establishing a desired climb rate with get_desired_climb_rate()

I notice there is a get_throttle_rate and get_throttle_rate_stabilized.  The main difference I see here, is that the "stabilizer" basically integrates the desired climb rate and uses the error of current height versus the integrated height to drive the rate controller, instead of just using the pilot_desired_rate directly.  The unstabilized rate controller ignores the effect of previous rate errors.  Correct?

When using get_throttle_rate_stabilized, that integrated desired rate is set as the altitude target, and then we use get_throttle_althold to calculate the error, determine the speed we want to try to achieve, and then send that rate on to get_throttle_rate. 

Get_throttle_rate takes the input rate and current rate to get a rate error, and uses the throttle_pid to determine an output which we send to set_throttle_accel_target.  Unless we have throttle_accel_enabled set to 0 (off).

So if I want to turn off the z-accel stuff to see if it helps, it's just a simple matter of setting that to 0.  Now, do we have ANY idea if throttle_pid will be anywhere near correct with a P of 6?

And now I see why I'm getting angle_boost.  It's practically hard-coded in. :/

[Leonard Hall]

Hi Robert,

 

It looks like you understand things correctly. And yes it does look like you have angle boost. It might be worth trying without it and see if the oscillations are still bad. It is possible that this is a feedback between the angle boost and the pitch.

 

The Alt Hold can quiet happily work without the boost throttle and I couldn't tell the difference.

 

Thanks for explaining those logs and what you are seeing. I am looking over them again based on what you have said.

 

Chat soon,

Leonard

 

Ps. I just realised I was having the same problem with my replies.

[Robert Lefebvre]

I'm going to try a few simple things first.  Weather is OK tonight, but it's dark (it'll be dark until April'o'clock) so no video.  Weather bad on the weekend too.

I'm going to first set Thr_Rate_D to zero.  I bet that if something comes in on the INAV Rate, that Rate D-term pokes the Accel PID pretty hard.

Then I'm going to try to turn the Thr_Accel_Enable off.  I imagine I have to completely retune Thr_Rate PID.  I'll test fly that, see if it's any better.  Might tell us if this is the Accel controller, or the Rate that is the prime suspect.

--
 
 

[Leonard Hall]

Ok, I can see this now! And it is interesting.

 

Ok, here are some plots of the incident that Robert points out.

Quick summary of what the data shows:

·        Small Pitch oscillations start at 128 seconds

·        Tune results in 10 to 15 degree error between requested Pitch and Measured Pitch

·        Oscillations increase to +- 10 degrees in both roll and pitch at 133 seconds

·        Robert selfishly backs off the pitch to save his copter rather than see how bad this can get at 132.5 seconds :)

·        Throttle bumps are seen at 128 seconds maxing out at 133 with peek to peek (pp) of 405

·        Throttle boost is there but small

·        Climb rate oscillations max out at 1.5 m/s pp

·        Climb rate dt reaches 5.85 m/s/s (but gets to 15 m/s/s probably)

·        Acceleration oscillation of 30m/s/s pp is seen

·        Acceleration delta t reaches 130m/s/s/s

·        INS Z_EF Corrections show oscillations due to large X, Y, Z correction factors. 8m/s/s pp

 

 

Alt_Hold Pid settings

 

THR_RATE_P: 6.000000

THR_RATE_I: 0.000000

THR_RATE_D: 0.200000

THR_RATE_IMAX: 300

THR_ACCEL_P: 0.250000

THR_ACCEL_I: 2.500000

THR_ACCEL_D: 0.004000

THR_ACCEL_IMAX: 500

 

Approximate throttle outputs based on observed inputs:

Rate_P: 112

Rate_D: 30 to 75

Accel_P: 375

Accel_D: 52

Accel_I: 4.12

 

So as Robert says, the velocity and Rate controllers look like the major contributors to the throttle jumps.

 

Ok, There may be a number of problems here. In no particular order:

·        Pitch loop may not be stable enough at these speeds requiring only small kick to set it off. We can test this by doing the same thing with manual throttle and seeing if we can reproduce the problem (I suspect not).

·        Alt Hold isn't stable enough, probably the accel loop, an maybe the velocity loop. Testing with Rate D set to zero Dropping the accel P and I terms then the Rate P and D terms may stop this from happening.

·        Inertial navigation may be causing problems due to corrections being transformed from the body frame to the earth frame.

 

Solutions:

Well, the only thing I have been thinking about is a speed based filter on the acceleration error. So basically the corner frequency will be scaled by the velocity. At 10m/s it becomes 0.2 Hz filter. The problem with this is it needs to be the air speed, not the ground speed. This is also the problem with any control change that relies on a velocity measurement. We could also relate this to the airframe angle with a slow response. So we assume that at an angle of 30 degrees we will be doing 20m/s and get there in 6 seconds. We then use that relationship to define a speed guestimate. That speed could then be used to smoothly change the controller in some way.

 

Ok, food for thought.

Leonard

 

 

 

[Robert Lefebvre]

Leonard, thanks for doing this. I've also been thinking about a damper, or a de-gainer, which tries to soften the response of the throttle, but I agree the problem is we don't have any real airspeed data.  Visions of AS probes have danced in my head, but what a nightmare.  I've thought about just going ahead and using Ground Speed, with the assumption that most people don't fly in high winds.  But I like your idea of guessing airspeed based on airframe angle over time.  I wonder if we could also look at the X-Y accel data?  If we are leaned over in a direction, and have stopped accelerating, we must have reached our steady airspeed for the given bank angle.  I don't think we would even need to guess at an actual number for the airspeed, it would simply be a scalar used for the purposes of this damper which gets tuned for a given airframe.  It could be dimensionless.

It's still not clear to me from the data if it's a pitch problem that kicks this off, or a Z-Accel problem that kicks it off.  The two start almost simultaneously.

I'm also thinking of re-jiggering the Alt_Hold controller for Helis, as I'm not totally happy with it currently.  The INAV altitude estimation appears excellent, it's the actual output controllers I'm not happy with.  I've hacked in a FF based on the Z-accel input, but I don't think that's right.  What we need is a FF based on *rate*.  This is immediately apparent because we know we have a strong physical effect, where if you give full collective, you get a finite, fixed, and repeatable climb rate.  So it makes sense to put a FF from requested rate to servo output, and then just use PID for the errors.  I'm thinking something like have a Rate PID+FF.  Then have an Accel PID.  If Thr_Accel is disabled, then throttle output is simply the Rate PID+FF outptut.  However, if we have Thr_Accel enabled, then Output is Rate I+FF, and send the Rate P output to the Accel PID controller.  The total output is basically Rate_I+Rate_FF + Accel_PID.  I'd use a leaky I-term for the Accel I to try and avoid it conflicting with the Rate I.  A little crazy, but it makes sense in my head.  I will do something in a clone/branch/fork.  And I plan to basically make new functions that are heli specific like what I did for the Pitch/Roll controllers, to help streamline the code.

Also, looking at the steady-state pitch error that I have in fast forward flight, I'm thinking of trying some Stab I-term again.  I'm pretty sure this is the aerodynamics of the tail.

In the meantime, more data. Conditions were fair tonight, so I went for it again.  Wind is essentially zero, 3 km/h.

I started out by doing a baseline run with the same settings as last night, same result, no surprise.  Then I set Thr_Rate_D to zero, and tried again.  This time, I think that maybe the oscillation was slightly reduced, but still unacceptable.  Then I turned of Thr_Accel, and had to spend quite some time retuning Thr_Rate PID, but think I got a decent setting.

What is interesting here, is that in fact I got *better* rate response and control than I ever could with Thr Accel turned on.  It was much better doing bulk altitude changes in a hover.  I didn't feel like it was falling behind the stabilizer and then punching the throttle when the error crossed zero as I went up-down.   However, there was a weird effect on non-moving descents.  It did this sort of pulsing descent, not violent, just stuttering.  Climbs were fine.  I think what was happening is that on descent, it was starting the descent, and then falling into vortex ring state, so it starts falling too fast, and the PID reacts and breaks it.  This little heli has a very pronounced VRS, and it can be difficult for me to control it myself.  Most descents are too fast and I really have to punch it to stop it and usually bounce up.  But it shows that I can't get enough Z Accel P with getting oscillation.  Though, without Z-accel, it also seemed like in a stable hover, there were more small little errors, maybe +/- 1" up and down.  Pretty minor, but not as steady as with Z-Accel.  

Anyway, I went for a high speed run, and I think the oscillation was still there, again better but still unacceptable.

So then I went and played around.  I managed to push it full bore in Stab mode (so manual throttle) and got it up to 107 km/h, no tail wind, INCREDIBLE!  No porpoising at all, though the tail starting shaking.  Later I found that in all my playing around to tune Thr_Rate I had set Rate_Yaw_I to zero by accident.  Fixed that, all was good but no more super high speed runs.

Also in stab mode, I was able to achieve real, sustained 13 m/s climb rates.  This was by getting to a high speed, and then pulling back on the elevator and pointing the heli up.  Sustained from 20 to 60m.  (though the rate slowed as energy bled off).  Just to show what's possible.  I'm curious how many Z-g's it pulled.

I had to put the data on my Google Drive because it's so big.  The interruption in the middle is a Skype call with Randy. :)

https://docs.google.com/open?id=0BzWH4Q7IAU5Yck9TckNzV0ZnOGM

Rob

--
 
 

[Robert Lefebvre]

So here's an explanation of my planned changes to the Alt_Hold controller for helis.  This is not to fix the porpoising, though it may help because it gives us a more manageable way to de-gain the acceleration response with speed.  If we use a variable scalar on the Throttle_Rate_PD_Output, we can shrink that output with speed, and be left with only the soft output.

https://github.com/R-Lefebvre/ardupilot/commit/efcc6a7fdb1664f42413...

Basically what I've done is re-jig the AltHold controller for TradHeli.  What I've done is this:

- Moved my Thr_Accel_FF to a Thr_Rate_FF instead.  It is now acting off the desired climb rate rather than desired acceleration.  This makes more sense to me.  We know that if we are in manual collective, and we push full collective up, we get a fixed, finite, relatively stable climb-rate.  There's a solid and linear connection between collective position, and climb-rate.  An FF makes sense here.

- I turned off angle boost.  This was a thing where, if you lean it over 45°, it automatically boosts the collective by 70% I think?  40%?  Whatever the trig works out to.  This is great if you were hovering, and then pitch it forward suddenly.  But it's the wrong thing to do to hold altitude in a heli almost any other time.  Flying fast forward, and slam it back to stop?  You don't want angle boost or it will make it rise.

- If you have Throttle_Accel turned off, now you have the simple Thr_Rate_PID plus FF.  So that part is easy.  The FF give you a steady-state rate control.  I will ramp up to accommodate the headspeed as it falls.  P and D manage the error and acceleration.  This is pretty simple to understand.

- Here's the tricky part: If you have Throttle_Accel turned on, the Thr_Rate controller calculates the P, I, D and FF terms,  It sums the I and FF terms, and reserves those (this is "throttle_rate_soft_output").  It sums the P and D terms (and calls them "throttle_rate_pd_output"), and sends that to the Throttle_Accel PID.  That PID uses the desired accel input, and does it's thing.  It determines what to output for the accel.  However, the total collective output is the sum of the accel_PID controller, and the throttle_rate_soft_output.  I plan to leave the Accel_I at zero, and maybe the D was well.

So, it's slightly complicated and weird, but makes sense in my head.  I have yet to test fly it.

[Leonard Hall]

Hi mate,

 

If the Accel loop isn't helping the heli, you could turn it off permanently!

 

The good landings are caused by the part of the control loop, the set point, and the integration term on the last part of the control loop. This could be done with the P->PID controller too.

 

Good work Robert!

--
 
 

[Robert Lefebvre]

Leonard, I did try turning it off completely. I explained in my by note above, but here's the brief:  Didn't fix it.  The INAV is still outputting huge altitude rate errors, which the hit the Thr_Rate P-term and output a huge spike on the throttle, causing the same problem.  It seemed slightly better, but not good enough.

What I did discover was that I got better *rate* control with the Accel loop turned off.  It highlights the fact that, just like with the Attitude loops, the servo lag means that I can't turn up the Accel P term high enough to give me the rate control I need, without causing oscillation.  So, the Accel loop off means that I get better rate control, but it does not give me as good fine control, cm accuracy, as I had the Accel loop turned on.

So I'm trying a hybrid of the two.  Rate I and FF will give me the big movement I need for rate changes, and the Rate PD will feed the Accel loop, which gives the fine control.

Again, none of this fixes the porpoising problem.  But that's a bigger issue.  Once I realized how much rate control I was missing with the Accel loop turned on, I decided to tackle this.

I could still use help setting up a variable rate filter which we can use on the Z-accel.  I don't know how to do that.

--
 
 

[Robert Lefebvre]

Well, I tried test flying this.  The code seems to work, but I'm not sure if it's an improvement.  I tried pulling all the Rate P and D, and just flying on I and FF, and it just seemed to bounce around, probably on the I-term, about a 2-3 second period.  I only realized after, maybe I still just didn't have enough FF, I'll play with it more.

I then turned Accel on, and tuned everything up including P and D.  Got a really nice static Alt-Hold out of it.  I still get this really harsh reversal from a fast descent to a rise.  I'm starting to wonder if it's not the control loop, but in fact just the heli breaking out of VRS.  It's really hard to control this manually as well.  I think the only way to stop it would be to fix the acceleration rate when it's changing from negative to positive.  Obviously there are downsides to that.

I then test-flew it.  The porpoising seemed greatly reduced, even with lots of accel P.  The air is dead-calm, and I'm sure that helped with disturbances.  It still happened though.  

I then turned the Accel P and D terms off and tried it so it was only flying on the rate FF and I terms again.  I was able to go full speed without the high speed oscillation, but it ended up bouncing up and down on the I-term again.  It was also super-sloppy when I tried to stop it, obviously because it has no ability to respond to the climb that is induced when I pull back.

I'll keep playing with it, but I don't think it'll be a solution.

I would like to investigate a variable frequency filter.  Either on the accel-input, or the throttle output.  

[Leonard Hall]

Hi Robert,

 

Sorry I have been distracted with work at the lately. And I just got back from moving 9000 kg of wet concrete, with a wheel barrow, for a mate (that was my half, there was 18000 kg total). So I am a little pickled at the moment.

 

Maybe we can have a chat on Skype some time and discuss some of the possibilities with the variable frequency filter.

 

Chat soon,

 

Leonard

--
 
 

[Robert Lefebvre]

Hey Leonard, you know they make machines that do that eh? ;)

Yes, we can chat anytime.  Maybe after work today, which will be Saturday morning for you?

One question I've had, is that for the filtering I'm doing for pitch/roll rate on the heli, I'm using the functions you and Randy told me to use:

rate_roll_filter.set_cutoff_frequency(0.01, 2.0);

and later:

current_rate = rate_roll_filter.apply(current_rate);

But I notice that in the Z-accel controller, you're doing this:

// calculate rate error and filter with cut off frequency of 2 Hz

        z_rate_error    = z_rate_error + 0.20085 * ((z_target_speed - climb_rate) -z_rate_error);

Why the different approach for a function that seems to be the same?

If the equation for a filter is that simple, isn't this just a case of making that '0.20085' a variable?

--
 
 

[Robert Lefebvre]

Ok, so I did some research, looked at the LowPassFilter lib and figured some things out.  What you have done is functionally equivalent.  Not sure why you choose one method or the other, but that doesn't matter much.  I was able to figure it out partially because I remembered you rattling off some equations in a Skype call weeks ago, and there they are in the lib.  I'm surprised this is, at least in practice, this simple.  I assumed the calculation for filtering was far more complex.

So anyway, I went ahead and prepared a little spreadsheet with the Alpha numbers for frequencies from 100Hz to 1/2Hz with both a 50Hz and 100Hz time constant just to give myself something to look at:

https://docs.google.com/spreadsheet/ccc?key=0AjWH4Q7IAU5YdFNkQTZKWGhxWlNCUnRUZzh1TF85N3c#gid=0

So the whole thing is fairly easy now.  I think we should just have a variable Alpha.  When hovering, we set it at 1.  When we lean over, we start to move it down ton increase the filtering.  I think we might need to make this a variable, or a #define at least, which is how far we want the filtering to go at maximum speed.  2Hz for little guys, 1Hz for bigger copters...  Don't know yet what we will need.  I might try a hack where I steal an unused Ch6 Tunable parameter and use it to control the Alpha. I guess we might as well figure out if the filtering even can solve the problem before we go to all the work designing the Alpha controller.

But to continue some other thoughts:

1) Do we filter the Z-acceleration, or the throttle output?  I'm not sure how we'd filter the Z-acceleration properly.  At what stage?  We can't just filter the effect of Z-accel on the Thr_Accel_PID loop because the Z_accel strongly effects the INAV alt rate estimation, and it still ends up driving the throttle via the Alt Rate error.  I've tried flying with the Thr_Accel turned off, and it still does the porpoise because of this Rate error.  I think we should try filtering the throttle output.

2) An estimation of the Alpha controller... I have in my mind that, from a hover, if you pitch it forward 45°, it takes about 5 seconds to reach full-speed, and this is obviously not a linear equation.  So, how do we move the Alpha around?  Well, I'm going to use a 5 second filter!  So as you hold more stick, the 5 second filter drags the active filter Alpha down towards the scaled alpha setpoint.  (are you going insane yet?)

So, if you have a Max Throttle Filter Rate of 2 Hz.  And you start from a hover.  And then push the stick for 10° pitch and hold it, the Alpha for the throttle filter will slowly move towards 0.8224.  That corresponds to a frequency cut of 7.2Hz, which is probably not bad.  As you push the stick over further, to 45°, it will slowly move that variable alpha towards 0.1116, which corresponds to a 2Hz filter.

You can see the relationship in the spreadsheet attached above.

Then, I simply apply that variable alpha to the throttle output.

I have sketched this out here:

https://github.com/R-Lefebvre/ardupilot/commit/71dfe5713ce47840db4d61944bfc0e7994ffb3e1

[Leonard Hall]

Hi Robert,

 

This is very close to what I was suggesting!

 

Do you want to chat via Skype?

 

To answer your question, the reason I did it this way is because I was more confident to do it this way than use the filter that Randy and I put together. Changing it over is on my list of things to do.

 

1) We filter the throttle output. OR scale the throttle Accel Gain (or both). The reason I say this is that the filtering may cause too much of a delay and cause oscillations. But we will have to try it and see.

 

2) Agree, a filter with a time constant of 5 seconds in your case (and I think that is probably reasonable generally).

 

3) Just change the filter on the Accel Error to be variable by dividing the output of the above filter in such a way you get the desired lower frequency cut off when at maximum. This isn't critical as this is all soooo non-linear anyway. I would suggest leaving the upper end 2 Hz and just choosing a lower end that stops the porpoising, maybe .1 Hz or .5 Hz.

--
 
 

[Leonard Hall]

I think it looks ok Robert.

--
 
 

[Robert Lefebvre]

Ok, will test fly it today.

--
 
 

[Leonard Hall]

Hi all,

 

I have put together a concept video of the loiter that Randy, Jonathan and I have been working on.

 

http://www.youtube.com/watch?v=nYMcT9wZgtU

 

Let me know what you think.

 

Leonard

 

[Robert Lefebvre]

Is this public?

--
 
 

[Leonard Hall]

Yeh, it is public.

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Robert Lefebvre

Sent: Tuesday, 15 January 2013 2:58 PM
To: drones-discuss

--
 
 

[Emile Castelnuovo]

That is really cool!

I don't understand what you mean with yaw problem. In the video it is difficult to see.

You mean the compass if off by some degrees so when flying straight it tends to traslate (is this the correct word?) to the right or left?

Could this be a compass offsets problem?

Emile

2013/1/15 Leonard Hall <leonar...@gmail.com>

--
 
 

[Leonard Hall]

Hi Emile,

 

Yes, I think this is a compass offset problem. We think that the current flowing to the ESC's is causing the fields to be distorted and this is causing an error in the heading. This then means that the intertial navigation thinks we are moving in a different direction to what we are.

 

There are a number of things we can do to fix this problem that we are looking into.

 

Thanks for the feedback,

Leonard

--
 
 

[Robert Lefebvre]

Yeah, I think that this effect is much stronger, since you now are doing such highly dynamic GPS guided flight.  You know, it was always there, but sort of hidden because everything was done so slowly in the auto-modes, that the I-term compensated without the user noticing.  But now the error is being amplified.

--
 
 

[Robert Lefebvre]

Is the compass error fairly constant?  ie: is it constant over time (ie: throttle position) and constant for the entire 360° heading range?  I wonder if it would be possible to simply have the APM automatically develop a "compass fudge factor"?  Like: True_Heading=Compass_Heading+Compass_Fudge

Probably overly simplistic.  Even if it varied with compass heading, maybe we could break it up into a few chunks.  Different correction factor for every 5 or 10 degrees of the compass?

--
 
 

[Emile Castelnuovo]

DCM has a drift correction based on GPS and/or Mag but I think the GPS drift correction is mostly used on planes.

But maybe it was actually the drift correction that made the copter yaw on high speed.

Leonard what was your gps_gain and gps_use set to in your tests?

E.

2013/1/15 Robert Lefebvre <robert....@gmail.com>

--
 
 

[Robert Lefebvre]

I'm not talking about DCM.  I don't think this is a DCM problem at all.  It's just that, say he was oriented straight north, and he pushes straight up, the copter should tilt straight north, and fly straight north.  The problem is, the copter was not actually facing straight north.  Due to compass error, it's facing 5°.  So when it tilts forward to fly straight forward, it's actually flying on a 5° bearing.  So a longitude error starts to build.  The controller corrects for  this, and tilts a little to the west to push it to the west so that it returns to the longitude line it should have been following.  This is what results in the curving motion. 

So is it possible for the program to simply look at it and figure out that "every time I tilt due north, I end up with the 5° error, so obviously my heading is off, so I'll use this fudge factor to make sure my heading it right".

The trick obviously is that the program can't tell the difference between a 5° error to the east, or a wind blowing it to the east.

--
 
 

[Robert Lefebvre]

When I said that Leonard and Jonathan's controller is more "dynamic" than DJI's GPS ATTI mode, this is what I'm basing that on.  The only videos I've seen show very very slow flight.

http://youtu.be/a8rYReqRH1k

http://youtu.be/sBi9qxWGgqg

http://youtu.be/ffqfxQx_Th8

It appears like ONLY the $11k Heli-only Ace One unit has "GPS CRUISE" mode which is basically a GPS guided speed/position control. I am no sure on the maximum speed, I have heard both 10 and 20 m/s.  I think all the Wookong and Naza units only have a "GPS Atti" mode which, when you push the stick, it unlocks the GPS hold, and you have pure stabilize control, subject to wind drift, etc.  When you release the stick, it auto-stops, and then goes back to Loiter.

I can't find any videos demonstrating high speed GPS Cruise mode, like what Leonard was doing. 

[Leonard Hall]

My GPS gain is set to 1. Unfortunately I don't understand how the various DCM features work.

 

Thanks for the feedback!!!

--
 
 

[Leonard Hall]

Actually it should be able to tell the difference because if the wind is pushing it the inertial navigation will follow that and it won't cause an error between the intertal and the GPS. The error we are seeing is an error between the inertial navigation and the GPS caused by fast flight. We should see the same thing if the wind pushes us away at 10m/s as we see when we fly away at 10m/s.

 

So Robert, I think you are right. We should be able to use this to correct the compass.

--
 
 

[Jonathan Challinger]

The potential exists for the current AHRS algorithm to fly a copter with no compass, as long as the copter frequently (or at least occasionally) accelerates laterally. The same algorithm could allow it to come up with a declination error, which is what Robert is talking about. I think one of the practical barriers to this is the lack of delay compensation in the AHRS. If we delay compensated the AHRS, we could make it able to dynamically correct the compass and yaw solution to match up with the GPS during accelerated flight.

--
 
 

[Robert Lefebvre]

 The error we are seeing is an error between the inertial navigation and the GPS caused by fast flight.

Yeah, my gut feel is that this problem gets worse, the faster you fly.  The GPS position system knows whether or not you are flying exactly on a true heading.  The Inertial system does not.  It can only fly in the direction it thinks is true north,  and that is subject to compass error.  When you fly very slowly, it gives the GPS position plenty of time to correct the path, so I expect that the compass error would be much less apparent.  When you make very fast accelerations, you're relying more on the inertial/compass heading, between GPS fixes, so the error shows up much more.

--
 
 

[Robert Lefebvre]

Right, the occasional bursts of acceleration sort of "probe" the yaw/compass fix.  Not that I'm suggesting we do this, but say you had the copter automatically give bursts of acceleration, pitching it forward 45°, with 0° roll and stable yaw.  The algorithm could look at which direction it actually flew according to the GPS, and that will give it a compass heading.  

So, the trick is to try and get it to do this on the fly, without actually needing to periodically run a test.

--
 
 

[da...@wylam.co.uk]

Robert, it's unusual I disagree, but DJI are possibly better than you think. I agree that their ' twist your compass till your quad doesn't toilet bowl' advice is crude, but it works. Loads of people have probs, friends of mine included, but with my friends, once I've verified the 'distance from Cog measurements' of the IMU and GPS/MAG in the software and got the unit straight, then it works a treat. 

But more importantly is the gps mode. I flew a tiny 330 naza on a beach, gopro, OSD, the works, in 30mph winds onshore. Normally madness, the missus was pleading for me not to take off and standing downwind with her gloves on ready to catch it - against my advice....

As i took off in GPS mode it just leant into the wind and stayed put. I then went hell for leather down the beach with the 30mph wind 90 degrees from the side. Full forward pitch gave me exactly that, no sideways drift in the wind. It was following a gps/mag line, or was measuring external influences, or just using the force. Either way I don't think the nav controller just lets go when you move your stick.

By the way you can fly full bore in GPS mode, provided you are prepared to over-tune a bit. A stock f450 with a 250% over-tune of rate and stab will shake a bit but fly in gps mode like its got a rocket up its arse. Then it just pulls up and hovers when you let go.

I definitely think we (you ;) ) are on to a much better solution though, it shouldn't matter which way your compass is pointing, as long as you know which way it is pointing!

I'm supposed to be working tomorrow, but if i get an hour I'll show you naza and wookong high speed gps mode. For info i always fly either full manual or GPS mode when FPVing with the NAZA. GPS mode makes Stab redundant really, cause the flying experience is the same, just with position hold thrown in. And slow NAZA FPV back flip in manual is still one of my favs :)

I have to say though, I think we have caught up and are well on the way to surpassing them at this rate :) I'll do a back-to-back once we are clearly ahead :D

[Robert Lefebvre]

Ok, well that's good info Dave.  I looked and looked for any examples of DJI products doing anything fast like what Leonard was demonstrating, and couldn't find it.  And then I based what I said on their somewhat unclear marketing materials.  They made a seemingly deliberate point of stating that the Ace One has this GPS Cruise mode.  Possibly just trying to justify the $11,000 price.  They describe GPS Atti as being different.  They say that it holds position at center stick, but once you move the stick, it's basically just in stabilize mode.

If you say it can hold a line against a cross-wind, then that's interesting.

Maybe what's going on is more of the same.  All of the Helicopter products are dumbed down compared to their multi-rotor equivalent.  Neither the Naza-H or WK-H will RTL.  Only the Ace One.  But then the Naza-M will (IIRC) so figure that one out.  Maybe the "GPS Cruise" is unique on the heli side, but they recreated it on the multi-rotor products?  But just call it GPS Atti?

--
 
 

[David Crone]

Yes sorry, is suppose I missed the most important bit, even my lowly Naza will fly in IOC modes, (simple and supersimple equivalents) in 30 mph on a beach, straight lines whilst yawing heavily. So yeah they definitely fly the compass.

 

I have sniggered to myself about the ‘GPS cruise mode’ too, i bet its better, but not by much.

--
 
 

[da...@wylam.co.uk]

ah found the vid i was looking for, all this was done FPV in GPS mode on a tiny naza 300 full osd etc. wind was hard on the way out, (100second flight) easy on the way back (30 second flight - 52 mph max speed), i only ever really held full forward pitch. Skip to 2:15 for the full 'forward stick', turn around, forward stick, precision.

 

http://www.youtube.com/watch?v=2Y3GqbnzJJM&lch=email&feature=em-comment_received&lc=SP1YSRdDc9Nfr0LLxpR1SzdjHHd6drRuqPwrhl-l1jM&lcor=1

 

 

On Tuesday, 15 January 2013 22:47:33 UTC, David Crone wrote:

Yes sorry, is suppose I missed the most important bit, even my lowly Naza will fly in IOC modes, (simple and supersimple equivalents) in 30 mph on a beach, straight lines whilst yawing heavily. So yeah they definitely fly the compass.

 

I have sniggered to myself about the ‘GPS cruise mode’ too, i bet its better, but not by much.

 

 

 

From: drones-discuss@googlegroups.com [mailto:drones-discuss@googlegroups.com] On Behalf Of Robert Lefebvre
Sent: 15 January 2013 22:12
To: drones-discuss
Subject: Re: [drones-discuss] Loiter Concept

 

Ok, well that's good info Dave.  I looked and looked for any examples of DJI products doing anything fast like what Leonard was demonstrating, and couldn't find it.  And then I based what I said on their somewhat unclear marketing materials.  They made a seemingly deliberate point of stating that the Ace One has this GPS Cruise mode.  Possibly just trying to justify the $11,000 price.  They describe GPS Atti as being different.  They say that it holds position at center stick, but once you move the stick, it's basically just in stabilize mode.

 

If you say it can hold a line against a cross-wind, then that's interesting.

 

Maybe what's going on is more of the same.  All of the Helicopter products are dumbed down compared to their multi-rotor equivalent.  Neither the Naza-H or WK-H will RTL.  Only the Ace One.  But then the Naza-M will (IIRC) so figure that one out.  Maybe the "GPS Cruise" is unique on the heli side, but they recreated it on the multi-rotor products?  But just call it GPS Atti?

 

 

Robert, it's unusual I disagree, but DJI are possibly better than you think. I agree that their ' twist your compass till your quad doesn't toilet bowl' advice is crude, but it works. Loads of people have probs, friends of mine included, but with my friends, once I've verified the 'distance from Cog measurements' of the IMU and GPS/MAG in the software and got the unit straight, then it works a treat. 

 

--
 
 

[da...@wylam.co.uk]

 edit 50 secs on the way back

[Leonard Hall]

I completely agree.

--
 
 

[Jonathan Challinger]

Re "Yeah, my gut feel is that this problem gets worse, the faster you fly."

The error is actually more related to how hard you want to accelerate. If your yaw is off, accelerations are applied in the wrong direction. Your actual velocity doesn't really matter.

Re "say you had the copter automatically give bursts of acceleration, pitching it forward 45°, with 0° roll and stable yaw.  The algorithm could look at which direction it actually flew according to the GPS, and that will give it a compass heading."

The AHRS already does this on the fly, minus the pitching around at random. The only problem is that it is not delay compensated. I'd imagine it would be good if we could get our accel-based yaw state estimation good enough that we could mostly ignore the compass (compass could apply a very slow correction to the gyro, accel-based could apply a much more rapid correction when available, while also adjusting the compass declination).

And keep in mind that we're not talking about simple mode here.

--
 
 

[Leonard Hall]

Yes and no,

 

The distance error is:

 

DistanceError = ( 0.5*Accel*Time^2 ) * 2 * sin(Yaw_Error/2);

 

for constant acceleration, note that if the time is small the DistanceError will be smaller than the stationary GPS error.

 

And after a short acceleration reaching a velocity of V:

 

DistanceError = ( V*Time ) * 2 * sin(Yaw_Error/2);

 

All together:

 

DistanceError = ( V*Time + 0.5*Accel*Time^2) * 2 * sin(Yaw_Error/2);

 

So you are correct that the error is caused by an acceleration in the wrong direction. The actual distance error that we measure increases linearly with velocity.

 

So we could use the last equation to calculate the Yaw angle error. And it doesn't really matter if we are only doing the correction over a particular velocity because we don't care if we are stationary (as long as we are close).

--
 
 

[Max Levine]

I really like that idea !!

The YAWing on fast flight can be because those landing fins, I have original ArduCopter frame (with MultiWii no compass) and it start to spin at fast speed, you need to try higher gyro correction on YAW,

flying on different frame (flat) will not spin with the same settings.  

BTW all DJI products have external compass even on the new Phantom its on the bottom of the landing skid. 

[Robert Lefebvre]

Been a while since we talked about this.  I started flying my little heli again, took a while to fix it after that Alt_Hold video crash.  At the same time, I replaced the swash servos with the highest performance servos available for it. Very fast, strong, accurate and zero slop.  This has allowed me to double my Rate P terms.  

I now have code running which uses the Leaky-I term which is in the standard code, only during the take-off and landing phase.  In flight, it goes to a full I-term.  There's a bit of logic controlling this that I won't get into here unless somebody wants to know.

So now that I have full I-term, I can pitch it forward a full 45° in fast forward flight.  Something I couldn't do before.  It would only achieve about 25° in FFF with the leak-I term.  

Interestingly, what has turned up is I am now getting porpoising in Stabilize mode!  I haven't yet figured out why, but it's interesting to note.  I'm not sure if the extra pitch angle allows me to achieve higher speeds, which is causing the same problem as I had in Alt_Hold.  Or maybe now it's actually the aerodynamic retreating blade stall...

As mentioned in the past, I suspect I have a geometric problem with the servo arms when pitched forward.  I need to do some trigonometry in AP_MotorsHeli to solve this.  But I need to run 3 sin() functions, and 3 asin() functions, at 100Hz, it'll take 500uS which I just don't think we have time for.

I'd started thinking about not calculating servo outputs at 100Hz, instead do it at 50Hz, or even slower.  We're filtering the AHRS inputs at 20Hz, so why bother calculating servo positions at 100hz anymore?  

--
 
 

[Leonard Hall]

You could run the servo outputs at 100 Hz but just set their position at 50 Hz or less. That might be simpler to implment.

 

Leonard

 

[Robert Lefebvre]

Yeah, the servo updates go out at 125hz typically, but it is the update that I'm interested in possibly reducing.

I had thought that, with set_servos_4() called at 100hz, within AP_MotorsHeli I could average 2 sets and update the servo outputs at only 50Hz.

But then I figured, if we were doing that, why bother even running the control algorithm at 100Hz at all?

On 25 March 2013 17:51, Leonard Hall <leonar...@gmail.com> wrote:

You could run the servo outputs at 100 Hz but just set their position at 50 Hz or less. That might be simpler to implment.

 

Leonard

 

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.