ardupilot
ardupilot copied to clipboard
ArduPilot
Take-off throttle slew time
This PR adds control over the throttle slew time as the aircraft moves from landed to flying. The autopilot looks for vertical acceleration, velocity or position changes to detect take-off. If 90% throttle is reached take-off is declared, limiting the maximum time delay.
The primary benefit of this PR is making the take-off behaviour independent of the vertical position controller tune. It will also improve the consistency of take-off when different payloads are used.
test flight on cubeblack, f450 frame 2022-07-11 11-21-20.zip
Thanks for testing, what did you think?
Looking at your log it looks like it was triggering of something early. You have a pretty low vertical acceleration of 1m/s so the ground noise may be enough to trigger it because it only needs to get to 0.5 m/s/s. The trigger thresholds are 50% max acceleration, your target climb rate (limited to 10% to 50% max velocity).
I may need to add a counter for consecutive detections to de-bounce the detection......
Thanks a bunch for testing. This shows a nice weakness to fix!!
I just pushed a commit that adds a de-bounce. May not be the best way to implement it but I hope this helps with the lower filter settings.
@chobitsfan Any chance you could test again once the tests pass?
@chobitsfan Any chance you could test again once the tests pass?
Sure. I will test it today (or tomorrow)
I have tested it with updated code. It looks good. Thank you @lthall
For some reason the first two flights trigger immediately.
Hi @lthall I am very sorry for late reply. Yes. it seems a little strange. I will try to test it more. Thank you
@chobitsfan No problems. I need to understand how this can happen and add some logging or something before you test again.
I have made a little progress. It is only happening in Loiter so it is something in the pilot takeoff.
I do another test today, fly in both loiter and guided. it is strong wind here. 2022-07-19 11-19-53.zip
It is only happening in Loiter so it is something in the pilot takeoff.
I suspend maybe it is related to https://github.com/ArduPilot/ardupilot/blob/7ae32c94efc17f100508f3ff039f568cef069289/libraries/AP_Motors/AP_MotorsMulticopter.cpp#L655
In loiter mode, pilot need to raise throttle input to takeoff. But in guided mode. I always take rc throttle stick in low end.
@chobitsfan I have added some logging to try to work out why your aircraft is detecting take-off immediately. Could you test with this code please.
@chobitsfan Ok, I have found and fixed the problem. Are you happy to test again?
Hi @lthall It works fine. Except for once, copter flip over during takeoff in loiter mode. I am unable to produce it again. It probably due to soft grass field. 2022-07-21 13-53-47.zip
Hi @lthall It works fine. Except for once, copter flip over during takeoff in loiter mode. I am unable to produce it again. It probably due to soft grass field. 2022-07-21 13-53-47.zip
Confirmed the leg got stuck in the ground. The aircraft was doing all it could to pull that side up.
Ok, I am going to remove the counter change and squash this all together. I think we have pretty much got this sorted now. I really appreciate your help @chobitsfan !!!!
Ok, I have rebased on master, cleaned everything up and pushed again. @chobitsfan if you have some time you could do one more check to ensure we are still good to go once all the checks have passed. I think I am good to get this in then.
@rmackay9 I'd like to get your perspective on the parameter name. To me TKOFF_THRTIME would be the time in seconds to start takeoff, but this isn't, as you'd need to multiply by the hover throttle. we could do TKOFF_SLEWRATE, but to be consistent with plane that would need to be a percentage, but @lthall doesn't want any percentages
The user currently doesn't know how long it takes to get off the ground so that value is not relevant to the user. The actual time to takeoff currently changes each time during a manual takeoff based on the vertical velocity commanded by the pilot. In all modes the takeoff time depends on the PSC Z tuning and the vertical climb rate setpoint and weight. We also don't know what the actual hover throttle is due to change in payload, fuel load, or even inaccurate settings of hover throttle with learn turned off. (I set hover throttle to be the hover throttle at maximum payload with learn turned off as this is what I think the best balance given the various issues)
The goal here is to provide a consent takeoff behaviour that is tolerant to all the factors above and easy to understand and set for the user. The throttle rate of change is the single variable that we can use to define this independent of all other factors.
So we have two options, takeoff slew time or take off slew rate.
I chose slew time because I could describe this to a user as "This is how long it takes to move the throttle from minimum to maximum while it is waiting for the aircraft to leave the ground. It is also the maximum time before the aircraft will give up trying to detect take-off and assume it is flying".
In reality most people will simply increase or decrease this number by a factor of 2 if they want a faster or slower take-off.
As a general rule I move from time constant to rates based on the nominal magnitude. So for this case we are on the edge there. We are talking throttle rates of 0.25 to 4 and ramp times or time constants or 0.25 to 4.
I agree with @lthall that slew time makes more sense. Most users will not be looking to have the aircraft takeoff in a specific time but will notice if it was too aggressive or too slow, and then adjust the parameter accordingly. I think time to hover throttle is meaningless and most users have no sense of what a good number would be let alone look to set it to some exact fraction of a second. I can take slew time and think of applying full throttle/collective in that time and get a physical sense of the rate and how it compares to a piloted takeoff.
I have added a commit addressing the "else" feedback. I will make the parameter name and parameter description name changes based on the feedback on the next DevCall and squash everything before we accept this PR.
Cool. Looks like it also have conflicts with master so perhaps rebase it on master too.
Note that this conflicts with this PR that removed the use of "blended" accels https://github.com/ArduPilot/ardupilot/pull/21278
This PR is rebased and cleaned up and I believe I have addressed all the concerns by adding a backup check that should revert to the existing behaviour if a corner case is found. This also calls a flow control error.
@lthall I think the line of code you pointed me to is fine for heli. I did some quick testing in real flight simulator. I thought the not landed flag is set on the actual initial climb rate but it appears that it is being set almost immediately after setting the auto mode. Is that by design? Also you can see in the plot that the desired climb rate is not tied to the actual climb rate while the aircraft is on the ground and the collective is being raised. Then it appears to be reset at the point the aircraft takes off. Would it not be better to have the desired climb rate just track the actual until lift off?
I think the line of code you pointed me to is fine for heli.
Thanks Bill.
I thought the not landed flag is set on the actual initial climb rate but it appears that it is being set almost immediately after setting the auto mode.
I need to see the log but it looks like the heli detected take-off immediately. It may have been due to the non-zero throttle on entering Auto, or maybe there is some acceleration noise in the simulator that is triggering it immediately. Take-off only resets the climb rate at the end of ramp up so there must be something funny about how this is being graphed or something. I need the log.
Heli simulations look like this for guided:
and Auto:
