I also build a firmware with plane.ahrs.groundspeed() set to > 6 to check if it’s really the root cause.
What I don’t get is the plane.is_flying() call. It’s seems that it is not enough to know of the plane is actually flying or not.
I build a fw based on 4.0.4 where I replaced
if (plane.is_flying() && plane.ahrs.groundspeed() > 3)
by
if (plane.is_flying() && plane.ahrs.groundspeed() > 7)
With that change, I was able to run and launch and have a real takeoff without skipping to circle mode.
I might be wrong but whithout other guess and with what I experienced :
- takeoff mode is all right with small plane that can be launched by hand without initial speed.
- for my eavy fx61 for exemple, I need to run to help it taking off and for that I had to change that speed in the code. But no idea of the side effect that could occur with that change.
Great job!
Do you know any tutorial for learning how to change the code? thank you!
I could be really helpful to make this parameter configurable and commit your findings to master.
Thanks!
already open a feature request about that but no comment so far.
maybe @peterbarker who requested the log had the time to have a look at it.
Thanks for any suggestion about that.
I would appreciate first to be sure that I am using take off mode in the correct way.
i think i had a crash related to this same issue. is there a way to implement this fix right now or do i just need to wait for an official update to arduplane?
wait so this means I need to achieve min accx and also make sure at that point the plane is not already moving at 3m/s?? this seems to contradict each other because by the time you reach a reasonable acceleration like the 12m/s2 suggested, you could have already reached 3m/s, right? I’m about to test my first hand launch, now I’m having second thoughts
It has been solve with this PR but not sure that it has been included in the last stable yet.
If you are not running when hand launching it should be just fine.
You can still use a mission with takeoff command which perfectly works even when running before launch.
you mean if I set up a mission with a loiter point for example and just hand launch in AUTO mode, it still works?
exactly. what I do is setup a mission with :
1/ take off with angle 25 and reach 100m alt
2/ RTL (or loiter)
with these param:
TKOFF_THR_DELAY,1
TKOFF_THR_MAX,90
TKOFF_THR_MINACC,15
TKOFF_ACCEL_CNT,1
1 Like
well, my takeoff position is actually not suitable for RTL so I set it up to fly to a loiter point in a safe spot and loiter to altitude. But, I didn’t know I also need to place a takeoff point? This takeoff point needs to be exactly where I stand when hand launching, right?
Never place such position.
Home position is placed when arming with GPS fix, I don’t think takeoff need this. In your case when takeoff command will be over, it will run the next command. In my case takeoff command is over when target alt is reached.
1 Like
Is the fix for this definitely implemented in 4.1.6?
I almost had a crash today, and the issue is eerily similar. I launched by hand in takeoff mode after “shaking” the aircraft to spool the motor up and minimize the effect of torque on this very powerful aircraft. I quickly threw it, and all was well initially. However, the aircraft began an extremely tight loiter with almost 90 degrees of bank about 2 seconds after launch, slowly climbing from about 20 feet of altitude. I switched into manual mode to prevent it from hitting nearby trees. The flight controller is an Omnibus Nano V6 with Arduplane 4.1.6 in a VAS “Hellkite” built for speed. Unfortunately I have no logs. A screenshot of my TKOFF parameters are below, and WP_LOITER_RADIUS is set to 75. Any thoughts on what the issue could be are appreciated. DVR video: TKOFF Issue - YouTube
I use takeoff mode in a few other aircraft without issue.
Wow, that thing is fast.
Without a log it’s going to be hard to offer much. The wp target on your OSD looked like it was tracking the correct direction and distance for the take off point. That suggests to me the flight controller intended to go the right way, and something pushed it off track.
How does this plane fly normally? Is it tuned for FBWA/Auto? Is everything trimmed? Any chance there was an aileron stick input? Stick caught in your coat? Or someone accidentally bumped the aileron trim?
Good on you for getting in manual and under control that quick.
Thanks for the reply. It had been through 2 brief autotune sessions, but roll seemed to occasionally oscillate at times, and the mechanical rates needed to be reduced, as manual mode was still very sensitive in roll. It was trimmed relatively well.
The stick inadvertently moved is a good theory. I can’t think of anything else that would make sense. Fingers crossed all goes well on the next flight. Thank you.
If you’re still getting oscillations after the auto tune you might need to lower RLL_RATE_SMAX. It seems that flying wings are more prone that oscillation but SMAX does a good job clearing it up. All the same for PTCH_RATE_SMAX.
That is good to know. Thank you!
Hi @avi8orn8 ,
Yes it is implemented in the code of AP4.1.6 stable:
https://github.com/ArduPilot/ardupilot/blob/Plane-4.1/ArduPlane/mode_takeoff.cpp#L63-L64
1 Like