Was checking if, by any chance, it was added the ability to change altitude during auto to latest firmwares. It is a feature we have been needing for a while and we had a dev doing it for us, but is a bit of an hack (dev words for it), and we have to make the mod at each new firmware.
Are we the on ly ones who would greatly benefit from such a feature?
regards,
Corrado
What do you exactly want?
Change the altitude of when going to a mission item or changing the altitude that will be maintained during the whole AUTO mode?
Also, do you want this to be done in the mission item list or externally (some script in companion computer or ground station)?
I would need to be able to offset the set altitude of a mission during the mission. Something that increases or decreases the mission alt by an offset proportional to a channel setting or something similar.
Lets say i run a mission at 30 meters, i would like to be able to offset that 30 meters to 31-32… or 29-28…
Hope it is clear.
I don’t think there is no solution out of the box for this.
I think this can be done with Lua scripting.
You need to defined mission items in some Lua script as an array.
This array will hold lat, lon, alt of the locations.
With one switch, when you toggle it you can iterate in this array and send command to the vehicle.
Another switch (as a potentiometer) you read the PWM value of it and map it to some altitude offset within range.
This is probably the easiest way to implement this without changing the source code.
Thank you but i already tried with lua the way you describe it but it is not ok with our application because it changes the altitude of the next waypoint and if it is far it takes ages to raise, we need it to change altitude on the spot.
No, it’s on the to-do list here but no developers are actively working on it. I’m sure it will be done eventually but we can’t promise when I’m afraid.
Thanks Randy, seen that but it has been sleeping for almost 3 years 
, guess it is a feature nobody needs/wants.
Then you can add a new target location before the next waypoint like (current_lat, current_lon, adjusted_alt) and give the command. Why not?
I will take a look at it when I am free.
You mean i should raise the mission and maybe add a point 1-2 meters in front so that it raises immediately?
Another think with lua is that for evey variation it rewrites the complete mission to the controller, or maybe i didn’t implement it right? If for example i modify the altitude 50 times during a mission than i need to rewrite the whole mission to the controller 50 times.
No, no, no.
The vehicle will be in guided mode.
Mission item list will be stored in the script or some other txt file inside sd card.
Lua script will handle the autonomous navigation in guided mode with altering the target location periodically.
No need to set target location with different location, just the current location with different altitude.
Ok understand what you mean now, don’t know if lua has any advantage vs doing the same with pymavlink from companion, what do you think?
Well, if you already have a companion computer on board, you can easily implement this in it.
If you add a companion computer to just fix this issue, it will be overkill.
Basically, LUA bindings and external guided mode commands use the same functions in the guided mode part of the autopilot code, so will be no difference.
Already have a companion onboard and feel more confident in pymavlink, so if there is no adverse i’ll do it with python.
Thank you very much.
I think the way Leonard and I were planning to handle it was to add a 3D offset that can be set by external callers (Lua, RC knobs or sticks) and then this offset is added to the output of the SCurves within WPNav. It would be similar to how we do terrain following which adds a vertical offset.
It’s not super simple of course though especially making it work properly as the vehicle travels through waypoints or reaches it’s final destination.
I think it will be a better implementation if it can all be done within the existing C++ instead of trying to do it all externally.
Yes that would be great Randy. What we use now puts an offset to the altitude proportional to a channel, channel can be assigned and maximum offset can be set (+ or - in meters). We had a dev from ardupilot dev list add it to an old 4.x.x firmware and has been working great since. Obviously we would much prefer to have it implemented natively so that we could upfdate firmware.
We take pictures of photovoltaic panels with very low F set on a camera so that or focus depth is very strict and we need to follow very precisely. Usually we fly 5 meters above panels and we are able to keep it ±10cm precision, we read altitude with 1 lidar and 1 radar, we apply some filtering and move the offset channel to keep it at the altitude needed. All of this is possible only if we use RTK as altitude source. Basically it is an home made terrain follow 
@rmackay9 Randy do you have any idea when there will be some beta of the change altuitude released?
thanks
Well, I could definitely use this feature! I can see a real use for this in film and TV work along with the variable speed (already available using Ch6 etc). In other words I could set a very specific path to follow and then change the height and speed as the director wants. Have had the need for this so so many times. Would make tracking vehicles and other action shots so much easier
Is this working since S-curve integration? It wasn’t but that was awhile ago and I don’t recall what the latest is.
I think wp_nav can be assigned to a knob (channel) since years ago.
Yes, I know that used it all the time (WP Speed chan 6 tune). But S-curve broke that at least for awhile. Perhaps it’s not an issue.