Throttle and Pitch auto control issues

@MagicRuB & @tridge

Thanks for offering to help look into this issue. I’ve started this new thread as requested. Sorry about the extra posts in the release thread!

As mentioned I’m facing an issue with my aircraft (My Twin Dream) with pixhawk FC with Arduplane 3.7

It usually only occurs in cruise mode and it seems to depend what throttle position I have (or what demanded airspeed I have, since throttle nudge is on) If I change the throttle up and down enough I eventually can get a spot where the throttle and pitch respond as predicted but otherwise the throttle surges up and down very quickly:

7.5 minute mark: https://www.dropbox.com/s/4vs6tvkrr7h8gb1/8.BIN?dl=0
17.5 minute mark: https://www.dropbox.com/s/hw6y8csr3jmkib8/7.BIN?dl=0

It seems to be TECS related as it presents as an oscillation on the pitch and the throttle (height/speed control?).

I have tried re-flashing and re-tuning numerous times both manually and using auto tune as the basis. I have changed all hardware on the plane with the exception of the ESCs and the Pixhawk itself. Maybe I just have something in the tune wrong?

I have also tried adjusting throttle slew (various settings down to 10%) and TECS time constant (up to 7.0) with no difference in terms of the error.

Massive thanks for any help anyone can offer :smiley:

Looking at your plot it seems the pitch PIDs are going into oscillation. Probably need to cut back on D term, however what you really need to do is run AUTOTUNE. Your params tell me you’re running the older default PIDs. On v3.7 (or was it v3.6?) we lowered the factory reset default PTCH2SRV_D value from 0.2 to 0.15. You currently have it at 0.2. Please run an AUTOTUNE so it’s set correctly for your aircraft.

1 Like

@MagicRuB thanks so much for looking into this.

Sorry that those last examples were on the default tune. On those flights I reset everything to default initially to see if it would change things. As I mentioned I have tried numerous times to autotune and manually tune with no success in removing the oscillations.

Today I flew a new autotune flight. Autotune ended with a PTCH2SRV_D value of almost 0.06 (as I understand the old default was 0.02 and the new default is 0.015).

After this the oscillations were still present. I landed and changed the PTCH2SRV_D value back down to 0.015 and left all other values as per the auto tune. The results were still the same with oscillations.

Further to this I tested RTL mode back to back with cruise mode in this flight to demonstrate how the issue usually occurs in cruise mode and not in other modes. FBWA was also demonstrated to show that the pitch loop is working at least in that mode as it should.

Please see the log below:

How long were you flying in autotune? Per the wiki instructions it says to do it for a long time, >10min, so it can slowly learn your aircraft. Longer the better.

@MagicRuB Around 8 minutes. I followed this guide which doesn’t mention a specific time frame just that you do over 20 iterations which I did:

http://ardupilot.org/plane/docs/automatic-tuning-with-autotune.html

I think if it was as simple as D then you would surely expect to see a difference in the oscillations between the previous flights at 0.02, the section after the autotune at 0.06 and the end of the flight at 0.015 wouldn’t you?

It’s also unexplained why it oscillates in cruise mode and not RTL or other auto modes. Especially since cruise in theory is just auto mode with a continuously updating waypoint isn’t it?

@MagicRuB @tridge

Any other suggestions on what I could do to try and iron out this kink?

I really appreciate any time you can spend looking at the last log I posted. Thanks in advance! Arduplane is awesome on all my other planes, I just can’t wait to have this one working properly too :slight_smile:

@Glen

I talked to @tridge about it and we think we figured it out. In general it’s a param configuration problem but we have some code changes in mind that will keep this from happening in the future.

  1. TRIM_ARSPD_CM = 1375 - cruise airspeed is 13.75m/s
  2. STALL_PREVENTION = 1 & ARSPD_FBW_MIN = 11 increase throttle if you drop below this airspeed and increase it even more on turns (See TEC2.LF - load factor)

Scenario:

  • Everything is fine but you were flying a little slow (11.2m/s) and commanded a controlled hard rudder+aileron turn.
  • Commanded roll was limited to 25deg due to increased load-factor (peaks at 1.1) due to low-speed.
  • Commanded roll was limited to 25, but actual roll was almost 35. Roll PIDs were not tuned well enough for your aircraft to allow it to react fast enough. I see oscillation in your roll on every hard commanded roll I see. This could also be a side effect of flying too slow, your aerodynamic control will degrade when near stall.
  • During the turn your airspeed drops to a low of 9.6 m/s. You are well below your declared stall speed.
  • demanded airspeed is internally 9.6 m/s * 1.1 = 10.56 m/s which is actually still below your stall speed and the throttle controller did not like that scenario.

Root cause:

  • cruise airspeed was too low
  • cruise airspeed was too close to the declared stall speed

Solution:

  • suggest increasing TRIM_ARSPD_CM for your aircraft
  • suggest performing an autotune for your roll PIDs (pitch is OK)
  • propose code change to force demanded load factor adjusted airspeed to be >= stall speed. I’ve created a bug report to track this code change: https://github.com/ArduPilot/ardupilot/issues/5036
1 Like

@MagicRuB Thanks so much for taking the time to look into this! I will adjust the parameters, work on the roll tune and give it a run this weekend.

I’m still curious regarding the last log I posted (10.bin) from around 41 minutes to 45 minutes. There are some big osscilations there on pitch and throttle when in cruise mode but the airspeed is above 12.5m/s and no major turns are demanded during that time.

Does the STALL_PREVENTION code activate above the ARSPD_FBW_MIN? The actual stall speed is around 9.3m/s and the ARSPD_FBW_MIN is set 20% higher as per the wiki instructions. From your response am I correctly reading that the STALL_PREVENTION code works based on ARSPD_FBW_MIN being the “stall speed”?

Yes. That is the minimum speed before it takes drastic measures to increase speed. I suggest raising your cruise/trim airspeed.

Thanks! I’ll do everything you suggested and report back. Really grateful for your help :smiley:

@MagicRuB I did as suggested. First I flew with the TRIM_ARSPD_CM adjusted to 16m/s. The issue still occurred. Then I did a bit more autotune on roll and the issue still occurred.

I don’t think the issue is related to the STALL_PREVENTION code as the throttle/pitch oscillation can occur at speeds far above the ARSPD_FBW_MIN. I also did another flight after this one with STALL_PREVENTION set to 0 to confirm that the issue isn’t related to this feature. That being said, the code change that you suggested is a very good idea in any case.

By nudging the throttle up or down to increase or decrease the airspeed away from the speed that is oscillating the issue can be temporarily resolved until next time you change the throttle or disengage/re-engage cruise mode.

Thanks so much for continuing to look into this! It’ll be so good to have the plane flying around properly :slight_smile:

@MagicRuB Do you think this is a tuning / setup / code issue or could it be a faulty pixhawk? If there’s a chance it’s faulty I will just get a new one.

Otherwise I have been trying to think of other causes and I noticed I have quite a lot of elevator throw with limited end points ( MAX,1905 TRIM: 1495 MIN,1164 ). Is it possible that the elevator is too sensitive for auto tune to tune properly? In normal manual flight I only use 1495 +/- 100. It’s good to have the extra travel in extreme situations but if it’s better for the autopilot to use closer to the full range I can change the setup.

@tridge could you look into this?

i had a similar problem
the solution was to change the CG of my plane (twinstar II).
please check again and make MTD a little nose heavy.:slight_smile:

@kostaslbc Thanks for your input. I’ve tried a wide range of CG’s with no improvement unfortunately!

@MagicRuB Thanks for encouraging @tridge to look into this. I hate to be a bother when you guys already put so much time into this project so I really appreciate any advice you guys can give me!

have you also checked the TECS_SPDWEIGHT?
I changed it to 2.0 (i am using a digital airpseed sensor).
I have height errors but the speed control is more accurate.
Since the throttle is more “lazy” the pitch is also “lazy” (in cruise mode).

If we don’t understand something, that is bad. We made it a point to be able to explain all behavior.

@MagicRuB That is a great way of looking at it if you want to build a super reliable platform (which Arduplane is).

I just hope it’s not a hardware issue with the plane. Though, since it flies fine in manual and in stabilise / FBW / RTH I don’t think it would be. If there is any chance you or @tridge think that it might be hardware I’m happy to try another pixhawk in the plane. Any further thoughts on the issue? Any testing you would like me to try?