ardupilot
ardupilot copied to clipboard
ArduPilot
Copter: add stick mixing for height in Auto
We should add (optional) support for the pilot to adjust the vehicle's height using the throttle stick while the vehicle is in Auto mode. In other vehicle's this is called "Stick Mixing".
The pilot should control the climb rate At the next waypoint it should keep the adjustment across waypoints We should have an enable/disable parameter to turn it on/off
@rmackay9 Should this be a Auto mode modifier or a new Flight Mode ( 2D Auto) ?
@AeroScanTech what is that source? Look like you've posted a couple files and a binary. What was changed?
The .rtf files show the changes this will enable throttle stick inputs to control the altitude in Auto, there is a parameter AUTO_MAN_ALT to enable the feature, At this point if the altitude change is more than 10mt aprox the vehicle will stop
there was something similar done for skyviper RTL: https://github.com/tridge/ardupilot/blob/skyviper2018/ArduCopter/mode_rtl.cpp#L135
On Wed, 23 Dec 2020, Sitha Sek wrote:
Any update on this?
This sort of thing will come in on top of our new s-curve navigation code. It has been discussed, but is still off in the future.
you can have a look at this, its technically not letting you control the throttle but you are adjusting the height of the waypoints and the drone will move accordingly.
https://github.com/graheeth/AutoModeAltControl.git
you can have a look at this, its technically not letting you control the throttle but you are adjusting the height of the waypoints and the drone will move accordingly.
https://github.com/graheeth/AutoModeAltControl.git
Hi @graheeth Can you clarify exactly how it works? Do you have to maintain the throttle at a certain position for it to maintain a height offset on the waypoints?
Hello @js-motocrane , you'll need to keep the throttle at a specific position to maintain a height offset for the waypoints. I've designed it as a quadratic function, so smaller throttle adjustments provide more precise control. Additionally, I've limited the height offset to a fraction of the total height, approximately 10% (you can adjust this percentage as needed by changing the fraction multiplied). This means you can't go below 90% or above 110% of the total height. Feel free to modify the numerical values in the code to suit your requirements.
Thanks @graheeth . It seems like a good starting point. I'm wanting to add some kind of persistent value for the waypoint height offset (e.g. in meters) that's incremented or decremented by an RC channel. It would be like what you have, but the offset value would be persistent and stay at a certain offset, even if the throttle was returned to neutral. So, for example, you would hold the throttle above neutral for a second or two, and the offset would increase proportionally during that time you were holding it above neutral. When you return to neutral, your offset stays at where it was adjusted. If you want to bring the offset back the other way, you would move the stick below neutral for a period of time. Do you think this is easily accomplished with a small code modification?
No problem @js-motocrane , I believe accomplishing this task is feasible. I apologize for any previous shortcomings in my comments and coding approach. It's possible to modify the approach by which the 'update_z_controller_edited' function manages throttle input in 'AC_PosControl.cpp'.
@graheeth Thanks, I'll take a look at it and see what I can figure out. Why did you build this in the first place? For your own application or at somebody's request?
@js-motocrane it was meant to be used for agricultural purposes and given to me for my internship.
@graheeth I found that with this method if you finish the mission and you are offset by more than the waypoint radius distance, it will not detect the end of the mission and will not RTL, until you return the copter manually closer to the waypoint (reducing the offset). Do you find this as well?
@js-motocrane I did not notice this, Thanks for the info. I will try to test it next week, I will keep you posted but its most likely going to be the same results.
Apologies, @js-motocrane for not getting around to the testing earlier. I've revised the code to enable continuous adjustments as opposed to relying on a percentage of the height. This approach directly influences altitude, akin to the previous setup. Notably, the controls now utilize a squaring function. This ensures a slightly finer control at lower throttle inputs, while enabling more power as the throttle increases. The pilots seem to be okay with this and hope you are too. I hope this helps.
The method of updating the altitude of the objective WP to match the amount of throttle operation resulted in the expected behavior in SITL. However, in the actual vehicle, it changed on the stairs. This change on the staircase has not been resolved.
Could you please provide more clarity on what is meant by 'change on the staircase' in your message? The term is a bit confusing to me. @muramura , I'm having some difficulty understanding this part.
@graheeth san It is about a vehicle changing altitude on a stairway.
This was done by a method that compares the target WP with the current position at regular intervals to update the altitude in response to throttle operation. Since the altitude changed at each fixed cycle, the vehicle changed altitude like a staircase.
Thank you @muramura for explaining.
It's interesting to hear about the staircase-like changes in altitude. In contrast, my drone's altitude adjustments seem quite smooth and don't exhibit this stair-step pattern.
Could you point out which specific function or algorithm in your system is responsible for the staircase effect in altitude change when comparing the waypoint and current position? I'm keen to understand the differences between our systems.
The expected flight is a smooth altitude change that matches the throttle operation. Therefore, I expect that @graheeth process will be incorporated.