Rethinking the descent rate parameters

I had this wild hare of an idea this morning while taking a shower.

In pilot controlled modes with altitude control (Alt Hold, Loiter, Pos Hold, Sport), the vertical descent rate is a range from to 0cm/s to PILOT_VELZ_MAX cm/s. In automatic flight modes with altitude control (Auto, RTL, Land*, Circle, Guided), the vertical descent rate is a range from 0 to WP_NAV_SPEED_DN.

As we’re probably all aware, a straight down vertical descent puts you into wake turbulence from the propeller down wash. So the vertical descent rate has a maximum limit, beyond which the aircraft becomes incredibly unstable. And if you keep pushing it, you could end up in an unrecoverable tumble or vortex ring state. If you have some horizontal movement, this avoids the wake turbulence, allowing remarkably higher descent rates.

Problem #1: The WP_NAV_SPEED_DN parameter needs to be set for a safe straight down vertical descent rate so said descents remain stable. But this is incredibly inefficient when the copter is moving horizontally in a mission. The copter could use a much higher descent rate while in motion, but there is no other choice today. This makes for awkward mission segment profiles where the copter is often reaching the next waypoint before reaching the target altitude. The anemic descent rate is frustrating, especially with short legs of a mission.

Problem #2: In pilot controlled modes, the pilot can either on purpose or by accident, invoke a straight down vertical descent rate that is too fast, as described above. This can lead to landing detection issues, loss of control, crashes, or general confusion. Especially for new pilots. If a pilot is flying a high rate of descent due still being in motion horizontally, the pilot needs to back off that descent rate when transitioning to a straight down vertical profile. None of this really a problem in that there is a bug or malfunction. But I believe the same automation that can improve the waypoint vertical navigation can help the pilot here too.

PILOT_VELZ_SAFE_DESCENT (cm/s, default 0) would be the maximum safe and stable descent rate the aircraft can handle. The operator would need to figure this out on their own since it will be different with every aircraft. But lets say you know it gets ugly after 300cm/s, you can put 300 in this parameter.

If horizontal speed < PILOT_VELZ_SAFE_DESCENT, constrain desired descent rate to PILOT_VELZ_SAFE_DESCENT. The single parameter would work well for both the horizontal envelope and the vertical envelope. If horizontal speed > than PILOT_VELZ_SAFE_DESCENT, the desired descent rate is as normal.

`WP_NAV_SPEED_DN_CRUISE’ would be a vertical rate expressed in cm/s.

Code concept for WP_NAV_SPEED_DN_CRUISE
If the horizontal speed > 300cm/s, use WP_NAV_SPEED_DN_CRUISE rather than WP_NAV_SPEED_DN for descent rate. This will allow the operator to assign a descent rate more applicable to cruise flight without compromising the straight down descent stability. It keeps it a set rate for predictability. I originally thought a sliding percentage scale would be great, but that introduces too much variability in mission planning.

I need to get back to work, but looking forward to thoughts or suggestions on this concept.