I was flying a quadplane that had successfully RTL-ed 3 times already that day. During my last AUTO mission, the quadplane went into RTL mode and flew towards the point where it should have transitioned as usual, but then kept flying past without going into QRTL as I expected. I had to take over the aircraft to not lose it behind the trees.
I initially suspected that it did not actually hit the altitude that it aimed to be at for QRTL, but this is not the case it seems. The altitudes it managed to reach were the same as my previous flights.
However, I had set the transition radius to be 10 meters, and by measuring the closest point of approach on Google Earth it seems that it was about 25 meters off (red line was the measured distance)
The blue line indicates the RTL approach path, the purple and yellow lines mark my own FBWA -> QHOVER landing.
I have two questions: am I right about the cause of not reaching QRTL (being too far away from the edge of the transition radius), and is this expected behavior?
yes, that is the current behavior. It will switch to QRTL when it starts orbiting around the target point. If the navigation is bad enough then it could indeed circle around.
We could add a check for passing the “finish line”, a line through the target perpendicular to the flight path. That would have made it go to QRTL, but it has the disadvantage that if its a long way off it will use a lot of battery flying VTOL back to the landing point.
I would recommend using the default RTL_RADIUS of 50 meters for mid-size and larger VTOLs. This distance has proven to work well on the FireFLY6 due to momentum on the approach.
Thanks for the advice Greg, I’ve really enjoyed reading your posts about your quadplanes on this forum.
I expect that I will have to increase the RTL_RADIUS, I was keeping it low for these tests because our quad batteries are pretty small and I was a bit concerned about flying even that short distance with the quad motors.
Just a warning about a change in 3.8.3. To fix this problem and to make it easier to predict the transition point I’ve made two changes:
it now triggers the change to QRTL at a distance of RTL_RADIUS, rather than on path capture for the loiter
if it does go past the destination, then it will trigger QRTL once passed the “finish line” through the destination
This has the effect that some people may want to increase RTL_RADIUS, as the previous switching radius depended on the L1 navigation parameters, and would have been switching well before RTL_RADIUS. It previously switched when the loiter code started to turn to meet up with the circle about the destination, which is usually well before the radius is reached.
Previously the quadplane had to intercept a circle defined by RTL_RADIUS around the RTL landing point before it switched into quad mode
Now, it proceeds directly to the RTL landing point once it has gone into RTL mode without using the L1 circle-based navigation, and once it has reached RTL_RADIUS distance away from the landing point, it goes into QRTL mode (or when it has crossed the “finish line”).
What i’m not too sure about is the idea of the “finish line”, at what angle is this drawn through the destination point?
yes, but the point at which it started to deviate away from a straight line towards the destination and start to head along the circumference wasn’t something that was easy to estimate for someone setting up a mission. That was the point it switched to QRTL mode. The result was that it wasn’t easy to predict the transition distance.
yes, and if RTL_RADIUS is zero, then it uses WP_LOITER_RAD instead
the finish line is the same thing we use for waypoint completion. It is a line through the destination and perpendicular to the line between where we entered RTL and the destination. If we cross that line then we’ve gone past the destination, and if that happens then we switch to QRTL.
Full discIosure… I don’t use Ardupilot so I have no “dog in the hunt”, although may want to try it in the future. I’m no code writer either so I can’t speak much on that, but VTOL development interests me. I’ve been following Greg’s builds…
In any event, would it make more sense to make the calculation using ground speed rather than an arbitrary distance? The distance radius works in calm winds, but if it’s approaching the home point with a tailwind, it could potentially overshoot or if it’s headwind, it’ll have to fly in MC longer than planned for, wouldn’t it?
Great practical observation. As an operator flying a relatively high-momentum aircraft, typically in high wind, I would find this very useful/comforting.
It’s really nothing new. The idea is from a common practice for full scale pilots on a cross-country trip to calculate when one should start descending from cruise altitude to initial approach altitude at the outer marker or pattern altitude (whichever is applicable). You can only do this by knowing what your distance to the outer marker (finish line) vs. groundspeed vs vertical speed (descent rate). It’s commonly referred to as T.O.D. (top of descent).
Airline pilots, especially, calculate and watch this because you can preserve a lot of fuel by pulling back the throttle to idle, trim the aircraft to a 1000 ft/min descent but still maintaining your cruise speed and not have to touch that throttle again until you’re setting up for final approach. That extra fuel in the tank will come in very handy if you have to go around/miss approach or divert.
For VTOL, it translates to battery power for either longer endurance or safe levels for VTOL landing with high winds.
Well, I guess my IFR rating was never really put to good use. I did fly a lot of x country, but rarely over 1000 AGL, so never had to plan many descents.
I believe this became very relevant today. I’ve just started my post-mortem on a flight this morning where the aircraft switched very late (to me) into QRTL and flew into a tree.
I was on the Plane 3.8.3beta2 firmware and running RTL after a FBWB tuning flight for TECS. Once in RTL, it seemed like the aircraft sped up to ARSPD_FBW_MAX (if TECS.spdem is the desired airspeed) and then on transition perhaps could not stop fast enough. I’m not sure if it was targeting my home location or the one rally point I specified (and I tested the rally point to be working in a previous AUTO mission).
I hope there wasn’t too much damage!
The plane was travelling at about 20m/s, and RTL_RADIUS was set to -10, giving a 10 meter distance for entering QRTL. At 20m/s to stop in 10m would require an acceleration of 2G, which is far too much.
If we assume your WP_ACCEL is accurate then the stopping distance would be 200 meters. If we assume it stops by leaning back at half the Q_ANGLE_MAX then the stopping distance would be 80m.
I think I’ll add a stopping distance calculation, possibly based on a Q_STOP_ACCEL parameter, so it can be tweaked per frame based on the drag characteristics of the frame. I’ll default it to 2m/s/s, which would have given you a 100m stopping distance.
That will automatically account for wind, as it will be based on ground speed.
Ah the frame was a write-off but all of the electronics survived thankfully
I’m concerned that the aircraft went to 20 m/s on RTL - my TRIM_ARSPD_CM is less than that but the TECS.spdem is 21. Is the existing logic aiming to maximize airspeed on RTL?
From previous tests when flying at a lower airspeed (around 15 - 16) it seems like the aircraft can come to a stop in around 15 - 18 meters, which is why this behavior surprised me quite a bit.
This would be great, I can go and test this on our next airframe (we have three identical ones being built and fitted with Ardupilot at the same time).
Hey Tridge, the current Q_TRANS_DECEL param has a default of 2 m/s/s which seems a bit low for quadplanes in our category. Like you said, it would give us a 100m RTL radius for a 20 m/s flight speed? Perhaps the option to use this deceleration-based transition radius should be put behind a flag (like Q_TRANS_DECEL_ENABLE?). I could put in a pull request for this if need be - I expect that keeping this enabled by default to 2.0 m/s/s would surprise a lot of quadplane users during the landing transitions once they update.
Also I’m still quite puzzled by the TECS.spdem of 21 that I observed for my aircraft on RTL, do we expect aircraft to aim for ARSPD_FBW_MAX during RTL?
I did fly a lot of x country, but rarely over 1000 AGL, so never had to plan many descents. 