Copter RTL thoughts

After working on a quadplane for a few weeks, getting it flying and crashing due to pilot error - 3 times, I set it aside for a while and went back to my multi-rotors.

Left over from the quadplane experience were RTL operational thoughts.

I live and fly in a small-ish valley in New Mexico USA. From my “pad” to the south is all rising terrain. I only fly generally south and southwest due to neighbors. Directly west is a low ridge about 300ft above pad elevation that runs north south and is approximately 350-400 yards away.

The terrain south is gently sloping up and if I get out to “extreme” line of sight range with strobe lights attached, I might have to gain 500-1000 feet of altitude to maintain visual, radio and video, while keeping in mind the 400AGL rule.

I’ve reviewed the Copter WiKi concerning RTL with the above in mind and have setup my quad with RTL at the present altitude. This is to clear the west ridge, though then, if I understand the setting, the frame will return at some very high altitude putting me in the situation of having the frame very high for a vertical descent over the home point, with a possible low battery, and being above the 400AGL rule.

Further reading about RTL_CONE_SLOPE perked up my interest in how far away the parameter would work and while the frame climbs up to intercept the angle if below the angle(and distance from home), does it RTL at that altitude, still putting me in the high altitude return situation once near home.

The cone parameter brought me to the idea of using the cone angle and a radius from home, where the frame returns to the radius distance having climbed or descended to whatever altitude is calculated at the radius. Alternatively, the pilot would pick an altitude at the radius, like in my case, enough altitude to clear the west ridge and the cone angle is calculated from there - to be used a bit later.

The other piece of data needed would be the RTL_ALT (or equivenlent) above the home point. This would be the final altitude above the home point to start the vertical descent with the RTL_ALT_FINAL being “zero” for landing.

The 4 scenarios:

-if the frame is within the radius and below 350ft(my ridge clearance elevation), then it climbs up to the “cone” derived altitude before coming home.
-if the frame is within the radius and above the 350ft, it immediately starts a descent toward home to arrive at the 50ft home altitude(my selected altitude above the home point), using whatever descent rate and speed to accomplish it, keeping in mind the last 20ft or so of the vertical descent and is set by LAND_SPEED.

-if the frame is outside the radius and below the 350ft, it immediately climbs to 350ft, turns to home and when it hits the radius, begins a descent toward the home altitude
-if the frame is outside the radius and above the 350ft, it turns toward home and begins a descent based on arriving at the radius at 350ft, then completes the rest of the RTL normally.(Alternatively, if above the cone angle, returns in a descent directly home and arrives at the RTL_ALT above the home point)

I understand similar procedures have been used by other FCs, notably the EagleTree Vector.

My second thought on a terrain dictated RTL is some type of approach setup, not unlike an ILS instrument approach used by normal aircraft. Those approaches take into consideration terrain and obstacles. In my situation with terrain close by to the west, an approach could be setup with initial altitude and azimuths to the south to get the frame away from terrain into a clear area, then conduct the RTL final operation. This would be very similar to a pre-programmed AUTO mission. As an RTL, it would work for me, but many other pilots wouldn’t find it helpful in a low battery situation, especially if the frame was returning from the opposite side of the approach operation.

I also looked at “smart RTL”. I have also seen the messages about “the buffer being full, etc.”, so it doesn’t sound like SRTL would be helpful.

If anyone has thoughts on how to make RTL better for my situation, I would appreciate your input.

Ron

Just my thoughts, not necessarily fixing your situation:

RTL_ALT is the minimum altitude for an RTL action. So if you are already higher, or RTL_CLIMB_MIN sends your copter above RTL_ALT then the copter doesnt descend until over Home and then starts the descent phase. This could indeed mean your aircraft is much higher than 400AGL if the terrain drops away.
RTL_CLIMB_MIN is good if there might be a obstacle between the aircraft and the home point, like a small tree, but you could be near or within the cone slope. RTL will do RTL_CLIMB_MIN every time.
It’s a good visual indicator too.

Also experiment and check logs to find you most efficient speed and set this as RTL_SPEED to avoid excess battery usage.
Check your fastest descent rate where instability is just creeping in and set as LAND_SPEED_HIGH
Set LAND_SPEED as a nice safe, stable descent rate, and LAND_ALT_LOW for the change-over altitude between the two descent rates.

The default RTL_CONE_SLOPE is quite steep, a value of 2 is good if you dont have obstructions near the Home point.

I’ve never got the Terrain following working for RTL but to be fair I didnt try very hard. You’d have to at least ensure the terrain data is on your SD Card.
https://terrain.ardupilot.org/

Shawn:

I’ve been playing around with this RTL question for a few days and have a semi-workable solution. The airframe is an Arducopter quad with Frsky R9 RX and Taranis X9D+ with R9M.

To differentiate near RTLs from far RTLs, I used Frsky telemetry “distance” as a trigger. This allows me to have a normal RTL when the frame is within 1100ft of home, which includes some of the ridge to our west. Beyond that, my Taranis SF switch triggers an AUTO mission that flies the frame to a known, high enough waypoint and then to subsequent waypoints to get it down to a reasonable altitude. Once the frame hits the 1150ft radius, the last waypoint being located closer, it reverts back to a traditional RTL and proceeds home at the altitude at which the mission turned it over.

Initially, I used “terrain” elevations for my waypoints, wanting 75ft above the west ridge, etc. as the highest point. For some reason, the frame didn’t like that and I almost lost it behind the ridge. Brought it back in and changed the waypoint elevations to “relative” and it worked - initially climbing to the first waypoint, turning and descending back around and finally turning over control to normal RTL at 150ft. That last waypoint was set to 100ft above home elevation, which worked out correctly since it’s about 50ft higher down there than at home.

My 2 distances for the OpenTX logic switches were “less than 1150” and more than 1160". From the video, it looks like normal RTL didn’t take over until about the 950-1000ft point. It works though.

The radio failsafe remains as a normal RTL situation.

That’s the latest.

Ron

Re-directing this thread to:

https://discuss.ardupilot.org/t/suggestion-being-able-to-define-an-rtl-approach-path-i-e-approach-rtl.

Tested the procedure this morning and it works as advertised.

1 Like