altitude control using throttle input in wp_run()

[graheeth]

Hey everyone,

I've made a way to adjust altitude on-the-fly in auto-mode. Gave it a spin in SITL and also took it for a real drone test flight – works like a charm! 👍

[Hwurzburg]

Overall, this is an incredibly dangerous change in my opinion. At the very least it would constraints, be transient like stick mixing, and an option whose default is off. But in general I am against pilot manual altitude control in AUTO/GUIDED for obvious safety reasons, especially BVLOS

[Hwurzburg]

changes to this file are totally inappropriate...pleas delete all changes.
If and when a new feature is added, it could be announced via a blog post, if judged noteworthy enough and approved, in discuss.ardupilot.org

[rmackay9]

Hi @graheeth,

Thanks very much for the contribution to try to solve this long standing issue!

[graheeth]

@Hwurzburg , should I introduce an option with a default setting of 'off' that can be toggled on to enable this altitude waypoint control? Do you think this idea might not be valuable, or that it won't be utilized much? I'd appreciate your advice. P.S. I apologize for altering the readme.md; I'm still getting acquainted with Git.

[Hwurzburg]

It definitely would require an AUTO_OPTIONS bit...as well as other changes:

• the change is a single line...dont repeat the code, just use the option to modify the altitude target in existing code
• the rate of altitude change should be determined by a proportion of the WP up and down speeds, not an arbitrary number of 2.5m/loop at max throttle, see get_pilot_desired_climb_rate..this also incorporates throttle dead zone,which your code does not
• I am concerned that allowing negative altitude changes in AUTO mode is a very high crash risk and should not be allowed in AUTO mode which is expected to have been setup with a mission considering obstacles/and or using terrain.
• I have not sim'd this so I do not know if it is transient target changing (what stick mixing does for roll/pitch) or persistent...persistent would be bad in my opinion,even if only till next waypoint

what is the exact use case for this?

[khancyr]

@Hwurzburg there is a demand for this feature for long for all those are doing inspection or spraying. Something you have unexpected obstacle or need a small ajutements for optimality.
So yes, that should be done better on planning in first place, but from activity point of views, starting again the mission would be a lost of time/money, so this is interesting, but need a good bunch of safety.

Previously I had the idea to implent this like that :
add as an option on switch : with an action on throttle stick doing some climb/fall change, and same for yaw like it is done on POS_HOLD. You control a altitude target and not directly the throttle.
The option could be split in two : keep the override only for the current travel to the next waypoint, or keep it until the end of the mission.
It need to cope with radio lost and some min/max altitude (should not breach fence, nor crash on ground, etc.)

[graheeth]

@Hwurzburg , this feature is intended for agricultural drone spraying. I've been directed to work on it due to frequent requests from pilots. I apologize for copying the entire function that was an oversight on my part. The request they also had was that releasing the throttle would revert the drone to its preset altitude.

Just to clarify, the code does limit the pilot's control to a maximum of percent of the set altitude. I squared the fraction, thinking that a higher throttle input might indicate a preference for a greater altitude, while a slight push would imply the pilot wants more precise control.

I recognize my approach might seem unpolished. However, if I can successfully integrate a toggle button and ensure its functionality, would there be a possibility of my code being accepted into the main branch? It is amazing to have any feedback from all you people working so hard, I truly appreciate the time and effort you guys put and thank you for replying to me too.