Climb speed limit in AltHold

[Holger Steinhaus]

I wonder if there is any hard-coded limitation of climb speed in AltHold mode. I have set PILOT_MAX_VELZ to 1000. The copter is able to climb at about 15 m/s in Stabilize. Anyway, I see a very flat line at +-5.5 m/s in the log, if I try to climb or descend in AltHolt or Loiter modes. I also tried to play with THR_ALT_IMAX and other THR_ gains - without any resulting change.

Regards,

  Holger

[Randy Mackay]

Holger,

     I think that the alt hold code only lets the target position get 7.5m above or below the current position.  I suspect that unless this limit is extended the target point can't get far enough from the copter to cause the PID controllers to ask for full throttle.  That's just a guess though, if you have a look at the dataflash's CTUN message, you'll be able to see if the Throttle Out is getting to 1000 or not.  If it's getting to 1000 then it simply won't go any faster in AltHold mode but if it's topping out at less than that it may be possible to coax a few more m/s out of it.

-Randy

--
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.

[Holger Steinhaus]

ThrOut shows a short peak to 650 when accelerating the climb and levels out around 400 after reaching 5.5 ms/s climb speed.

Holger

[Robert Lefebvre]

Which code are you running?  If it's 3.0.1, this could be the performance problem that I discovered with Octos.

Otherwise, I would think that Randy's suggestion is correct.

[Holger Steinhaus]

Should be an up-to-date master (11ece6565). Hardware is Pixhawk 2.4. But the behavior is exactly the same on 3.0 APM 2.5.2 (after looking into old logs). Even the copter type and perfomance has zero influence - always 5.5 m/s (downwards -5.5 m/s).

Holger

[Randy Mackay]

Holger,

 

      Ok, so you’ve got a lot of motor power to spare.  Without making a code change I think you could also increase the Alt P from 1.0 to 2.0.  The problem is that increasing that can also make the copter jumpy.

 

     If you’re comfortable making a code change you could try replacing the “750” in the get_throttle_rate_stabilized() function with something larger like “1500”.

               https://github.com/diydrones/ardupilot/blob/ArduCopter-3.1/ArduCopter/Attitude.pde#L1150

 

-Randy

[Holger Steinhaus]

No flying weather today, but tried it in the SITL sim.

First result: the SITL using the params attached shows almost the same behavior, climbing at 5.2 m/s in ALT_HOLD and 60% throttle. In Stabilize, it climbs at about 17 m/s.

Second result: changing the line you quoted above has no influence on the climb rate

Third result: playing with PILOT_VELZ_MAX: changing from 4900 to 5000 has an effect, from 5000 to 5100 does not

I think the SITL make is very easy to reproduce the effect:

start SITL with sim_arducopter.sh

param load sitl.parm

rc 3 1000

arm  throttle

mode stabilize

rc 3 2000

...

mode alt_hold

...

Holger

[Randy Mackay]

Holger,

 

     I’ve really got my hands full at the moment so I won’t be able to look at it immediately.  If you could log an issue in the issue tracker so that it’s not forgotten that would be good.  Alternatively maybe someone else on the dev team wants to have a look.

[Holger Steinhaus]

Done: https://github.com/diydrones/ardupilot/issues/801

Holger

[Julien Dubois]

Holger,

look at the CTUN log and find the desired_climb_rate value (DCRt) just before the climb_rate.
If this value is close to climb_rate and limited to about 5m/s as well, the problem is not related to the PID or other limitation of the throttle_hold controller as the desired climb_rate is defined in the get_pilot_desired_climb_rate(int16_t throttle_control) function.

And that would mean the limitation is given by g.pilot_velocity_z_max (=PILOT_VELZ_MAX you've changed)
Actually, this parameter is defined this way
    // @Param: PILOT_VELZ_MAX
    // @DisplayName: Pilot maximum vertical speed
    // @Description: The maximum vertical velocity the pilot may request in cm/s
    // @Units: Centimeters/Second
    // @Range: 10 500
    // @Increment: 10
    // @User: Standard
    GSCALAR(pilot_velocity_z_max,     "PILOT_VELZ_MAX",   PILOT_VELZ_MAX),

So, maybe mission planner is automatically limitating your value to 500cm/s if you put a higher value.

Your log will give the answer.

Julien

[Holger Steinhaus]

The flash logs say PILOT_VELZ_MAX=1500, as set. Currently the limits of parameters seem not to be enforced. 

The code change Randy pointed up does work, but needs surprisingly huge values (*10) to show significant effect. Using this hack, everything works here as intended, found no adverse effects yet (with my setup). This solution is goood enough for me until the onion code finally solves the problem.

Holger

[Robert Lefebvre]

Holger, are you stating you need to change the '750' to '15,000' ?

--

[Holger Steinhaus]

7500 works quite well here. Using this value I see about 11m/s with VELZ_MAX set to 12.5

Holger