I am trying to ascend 200 feet (~70 meters) in a few seconds (shoot up the face of a small cliff). It does this fine in stabilize, but during a mission, it seems to max out vertical speed ~20 feet per second (7M/s). I tried WPNAV_SPEED_UP from 5,000 to 50,000 (in 10,000 increments) does not seem to make any difference and a couple other parameters (like WPNAV_ACCEL_Z). Is there a ramp-up parameter or?
Quad specs, 250mm, 4s-1300, 2206-2250kv, 6040 bi-blades, pixhawk lite AC v4.0.3.
tia
EDIT: WPNAV_ACCEL_Z is the parameter I needed, thanks to Anubis.
I don’t see any hard-coded limits to vertical speed in the code. My only guess is that you might actually be limited by horizontal speed - if the high waypoint is not directly on top of the low waypoint, the drone still has to move in the horizontal direction and must respect the horizontal speed limit. This will limit climb rate as well, depending on the slope of the line between the two waypoints.
edit: now that I think about it, I’m not sure if that is true. I don’t remember if the drone will try to follow the line between waypoints, or will treat vertical and horizontal movement separately.
You can post a flight log and maybe we can see what is limiting your vertical speed.
@Anubis Thanks for the quick reply. I will adjust the waypoint distance closer to see if that helps and report back. In my current testing I am 200 feet up and about 20 feet horizontal for the next waypoint. I have the yaapu telemetry lua and i see 21 feet/per/sec max rate. I notice there is a long ramp up time (relativity) to get to the 21f/s rate, is there a parameter to adjust the ramp time, I tried WPNAV_ACCEL_Z but it didn’t seem to help? Part of the problem is 200 feet does not take long to get there even on a old school mini quad, maybe I need to try 300 feet and retest. I need to dive deeper into log analyzing, so many parameters, I need to figure out which ones to look at. When i last looked at logs, I noticed the ACC Z axis was backward (going down while accelerating up). In betaflight I am used to looking at the BB logs for ACC Z axis, this is a standard parameter we test preformance, its a simple number (truth detector) of thrust to weight, this quad is 6:1, my normal LOS quad is 9:1, the lightweight guys are hitting 15:1, these ratios are why AC is sorta difficult to tune for mini quads, as AC is not used to this kind of preformance. I will also get a log. thanks.
@Anubis Sorry for the delay, life/work gets in the way
Here is a log with one auto mission to 100M high and the param file from the flight. I dont recall anything higher than around 9M/s (27f/s on yaapu). My up speed is set to WPNAV_SPEED_UP 20000, should be 200M/sec, so i am guessing something else sets the ramp up speed/time, thoughts? You can see it took half the way up to reach the peak vertical speed. When I looked at the ACC Z axis on another log, it was backwards (going up, the ACC showed negative, and coming down positive), but for now i dont care about that (maybe I am reading it wrong).
Looks like you’re being limited by WPNAV_ACCEL_Z, which you have set to 100 cm/s^2. You said you tried changing this? The climb rate and rate output lines up with the parameter setting in this log.
Excellent! That was it! Not sure why before it seemed to not change anything, could of been the shorter 100 foot vertical distance I was going. I will edit my first post with your correct analysis. Thank you.
The next issue is the throttle pulsing (looks and sounds like slow oscillation) when asking for more throttle in AUTO (like above auto mission) and ALT_HOLD modes. When the FC is asked for more throttle in these modes, like 50% and higher throttle. Being a mini quad, quite a few parameters needed to be lowered to get it to fly without oscillation in stabilize mode. Do you know the tuning parameters I can play with? Any throttle position is fine in stabilize mode.
Hm I don’t see any obvious evidence of that in the log. I might need a cleaner log of you throttling up in alt hold or something (loiter should work too, it uses the same Z controller as alt hold and auto).
But anyways, the relevant parameters would be PSC_POSZ_P, PSC_VELZ_P, and PSC_ACCZ_*. These are the position control PIDs for the vertical axis.
Just to be clear, its not a vertical only issue, it’s when the FC controls the throttle and is above say 50~60% throttle. The thro when I control it in stab mode is fine at any position, I believe this is because I control the throttle and is not in the FC control loop. When the FC controls the throttle (like in alt_hold) and “it” needs to throttle up (above say ~60%) to keep the altitude the same when I tilt the craft to max lean angle (something like 45 degrees), this is when the throttle pulsing happens. It also happens in auto mode when climbing at faster rates (that you just fixed for me). So not when I just punch the throttle in alt_hold mode (trying to gain altitude), because its so numb to climb (some setting) the FC is limiting the throttle to some low value to do a slow climb.
Are your suggested parameters the correct ones to adjust ( PSC_POSZ_P , PSC_VELZ_P , and PSC_ACCZ_*)?
Oh I see, then those params may or may not help. I can’t say what the problem is without seeing it in a log. Is it easy for you to reproduce and log? Or maybe you can point out in your provided log where it happened?
I will make another log, but first a semi setback. Late yesterday I was changing several parameters to try and get the throttle oscillation under control, some seemed to help but not completely fix it. i was losing daylight and not taking notes of my changes. So today I was gonna start from a saved full param list from two days ago, the load from file went ok and then started saying x parameter is out of range(x10), y/n, I said yes to all of them, then some read only messages, then said a small list of battery parameters. Upon reboot, turns out I lost frame type, acc/mag/tx cal, most if not all telemetry settings, flight modes, well you can see, basically everything, little bummed.I save and reload setting all the time with betaflight, not so much with AC. Will kill my testing for early tomorrow morning. Will get it going again and provide a log.
Update to 4.0.4 Stable and you’ll not lose params on boot. Also, you can load the params from the previous log. Check the dataflash log directory, you’ll get the param file for the corresponding logs. Hope this helps!
