Ardupilot: Copter: allow RTL without GPS

[night-ghost]

times are now vague, the GPS data can not only be muffled but also tampered with, and the existing mode of handling the loss of GPS (in auto and RTL mode) is landing - leading to the loss of the aircraft.

However, during the loss of GPS, we have quite a lot of information on board:

1. the last valid coordinates of the aircraft
2. coordinates of the house
3. velocity vector
4. we also have compass and barometer data.
5. also we can remember relation betwen controls and grounspeed - throttle for plane and angle for copter

From these data, we can calculate the direction and distance to the starting point.

The offer is: when loss of GPS occures, instead of landing, to start moving along the magnetic azimuth in the direction of the take-off point, at a distance no more than the calculated distance to it, in the althold mode. High accuracy is not needed here, the goal of the mode is to get the device out of the jamming zone and allow to get reliable coordinates of the aircraft.

[night-ghost]

sorry but I think this mode suitable not only for copter but for plane too

[DavidIngraham]

Plane will already do this if you have an airspeed sensor. This is feasible because dead reckoning with compass and an Airspeed sensor is semi-reasonable.

Dead reckoning on copter seems like it could be very dangerous, but I suppose this method could work appropriately under a very limited set of circumstances.

[night-ghost]

if you have an airspeed sensor

Yes _if it have_. My plane have a weight of 204 grams, yes I bought the airspeed sensor but I can't set it to because of its size.

Dead reckoning on copter seems like it could be very dangerous

If we try to go out from dangerous zone then we can to loose aircraft. If we will land in dangerous zone then we loose aircraft guaranteed.

[magicrub]

Since dead-reckoning degrades rapidly, for plane you can quickly grab the heading to home and just integrate your time/airspeed and get home-ish.

[magicrub]

Pull Requests Welcome!

[Naterater]

It would be nice to continue on toward future waypoint(s) too using dead-reckoning. Not just to home/rally point.

[lvale]

considering the latest "developments" that are being tested around here regarding "anti-drone" situations this might become "useful" :)

[magicrub]

It would be nice to continue on toward future waypoint(s) too using dead-reckoning.

yes, of course.. but position degraded RAPIDLY. This is all easier to say than do. Pull Requests welcome!

[tridge]

plane already does dead-reckoning even without airspeed sensor. It just isn't as accurate.

[Vaibhav911]

You may want to create a trajectory to its destination, and keep updating it every instant. As for keeping up with physical parameters, you can use gyroscope to maintain its altitude(or change as required) and accelerometer to ensure that it don't speed up or down(or as required). Thus it can maintain its trajectory.

[night-ghost]

but position degraded RAPIDLY

so just forget about position! We have baro and compass, 100 years ago it was enough to fly 1:1 planes.

plane already does dead-reckoning even without airspeed sensor. It just isn't as accurate.

Excellent, so nothing prevents to port this code to copter :)

[Pedals2Paddles]

so just forget about position! We have baro and compass, 100 years ago it was enough to fly 1:1 planes.

Not true. It also involved the pilot's eyes to cross check the course, knowledge of the wind conditions, and calculations to determine a wind correction angle based on wind and aircraft performance data. None of which we have in copter. You can't just point it down a heading and go. That would be incredibly unsafe and not a good feature.

Excellent, so nothing prevents to port this code to copter

Not even remotely close. We're you planning to do a PR on this to make it happen?

[night-ghost]

It also involved the pilot's eyes to cross check the course

when flying over the sea?

knowledge of the wind conditions,

We know the wind at GPS loss time too.

and calculations to determine a wind correction angle based on wind and aircraft performance data

we can calculate relation between copter's angle/plant throttle and airspeed when GPS is OK. As some sort of in-flight calibration.

You can't just point it down a heading and go. That would be incredibly unsafe and not a good feature.

but sometimes we MUST do it to escape from high interference zone. To land a plane unknown where and not known how - is it safer?

[rmackay9]

I'm sure it is a very difficult problem for a few reasons:

• we do not yet have wind estimates in Copter. It's easier to calculate in vehicles that "fly forward" only. @priseborough is planning to add this at some point this year though.
• the EKF's position and velocity estimates degrade very quickly once we lose an absolute position source. The older DCM does better but it's overall accuracy is much lower. Copter's velocity and position control algorithms all rely on the EKF to provide position and velocity estimates. This dependency would need to be changed to work on the higher level AHRS and tested to see how it performs with the lower quality data.

Of course it is fine to argue about whether it is possible or not but in the end it will certainly take much effort from a developer. @night-ghost, if you're volunteering to take this on great! For me personally, although I'd love this to work, I'm not confident enough of success to try and tackle it any time soon.

[Pedals2Paddles]

when flying over the sea?

All of the other things like wind and aircraft performance data are used. Which again, we don't have in copter.

We know the wind at GPS loss time too.

No we don't.

but sometimes we MUST do it to escape from high interference zone. To land a plane unknown where and not known how - is it safer?

I would rather it land gently than fly off in some random direction with no control on a bunch of unproven assumptions that can't be trusted.

When a feature/function is added to ArduPilot, the users expect that it will work. ArduPilot doesn't roll out features that only sort of work sometimes. Who here wants to stake their reputation on a function that cannot possibly work in any accurate and repeatable manner today?

It would be unprofessional and unsafe without a lot more development and testing. Were you offering?

[lthall]

The approach I have taken so far is to ensure that the pilot will lose the aircraft not us. This would break that rule (only my personal rule).

If it lands where it is then the pilot only has to follow the waypoints to find the aircraft. If the pilot has maintained visual line of site and is monitoring the aircraft then the pilot can take over. If the pilot has not then they are probably breaking the law, especially if the aircraft is unable to land where it is flying.

I think features like this one do not add to the reliability of the system unless the error can be well characterised and bounded.

[Pedals2Paddles]

The approach I have taken so far is to ensure that the pilot will lose the aircraft not us. This would break that rule (only my personal rule).

Very well said. That's exactly the point I was making when I say that ArduPilot doesn't put in features that only sort of work sometimes. It would be completely impossible to make the aircraft meet the operator's expectations on a repeatable basis. And it would not be acceptable to make the operator's expectations be "this might work or it might fly away, good luck."

[rmackay9]

.. but of course if @night-ghost wants to work on it and can show it works reliably, we are very happy to evaluate and hopefully accept it into master.

[night-ghost]

The older DCM does better but it's overall accuracy is much lower.

yes this is a problem. I always wondered why DCM was banned completely in copter, and not left as an fall-back replacement in case of EKF failures. I still have copter on 8-bit controller, and it still fly rather well, so it will be OK for emergency modes. And I still want to check how DCM will work on 1kHz cycle.

I would rather it land gently than fly off in some random direction

this is a joke? Land gently into sea/forest/etc? One my сopter has sunk, having got a battery failsafe and accurately having sat down into the river. Thank you, no more.

[rmackay9]

Actually the last few versions of Copter on the AVR boards didn't use DCM, they used "inertial nav" which had the same very quick position estimate degradation as the EKF has. The last version of Copter to use DCM was 2.8.1 (I think).

[night-ghost]

If the pilot has not then they are probably breaking the law, especially if the aircraft is unable to land where it is flying.

situation: The lake, and the radio relay line above it. Once in the beam, the copter loses all its connection, and drowns in the lake. My good friend,whose house is near to that lake, had drowned so 5 (!) copters, until hi understood what's wrong. If the copter had turned around and attempted to exit from the beam for at least one minute, this would not have happened.

Do you still think that it was not you who drowned these copters? :)

[night-ghost]

the last few versions of Copter on the AVR boards didn't use DCM, they used "inertial nav" which had the same very quick position estimate degradation as the EKF has

Can inertial nav algorithm to forget about position estimate, and just maintain a constant slope, altitude and azimuth? For one minute, for example.

[Pedals2Paddles]

Do you still think that it was not you who drowned these copters?

One my сopter has sunk, having got a battery failsafe and accurately having sat down into the river. Thank you, no more.

Are you kidding? The operator being unaware of their surroundings and repeatedly crashing their copter doing the same thing over and over? That's your justification for this? That is operator stupidity, and you can't fix * with firmware.

And flying a copter with a depleted battery to the point at which it crashes into a river is also operator error. Again not something that can be fixed with firmware.

And again, your entire point is moot. Copter can't do it as it is today. It requires rather extensive development and very extensive testing to make it even somewhat reliable. Something that does not reliably work will never get into ArduPilot, and this doesn't currently reliably work. You've been asked several times now if you're volunteering to do that development and testing? You haven't answered yet.

[night-ghost]

You haven't answered yet.

You think I should answer such questions, really?

[Pedals2Paddles]

You think I should answer such questions, really?

I asked if you were volunteering to develop and test the feature that you want. Yes, I do think you should answer such questions. Was it an unreasonable question? Does this mean the your answer is no, you will not be doing anything to develop and test this feature?

It is a serious question. I'm not asking it to give you a hard time. If you are willing to put that time and effort in to making this a reliable and trustworthy function, that is great. It can certainly be a beneficial feature and your contributions to ArduPilot would be most appreciated. When I've asked for features, the first thing someone asks is if I'm willing to work on those features. That's kind of how it works.

But if instead you want it to just do something unreliable and untrustworthy sometimes under some conditions, and you want someone else to do it for you, you're probably not going to get a positive response.

[rmackay9]

A couple of answers:

• the EKF's altitude and vertical velocity remain accurate even without the GPS because the baro provides the absolute height estimate.
• you definitely could try to create an RTL that just flies in the direction that it last "saw" home but one way or the other, the vehicle will still need to estimate its position because it will need to decide when to stop leaning and flatten out and start landing.

Doing some simple math, imagine the vehicle is 300m away and 50m up can fly at about 10m/s. The vehicle could get above home in about 45sec (including acceleration and deceleration), and then it would take perhaps another 20 to descend. If the velocity estimate was off by 1m/s the vehicle would be >60m off from home when it landed, if the estimate was off by 2m/s it would be >120m off, 3m/s it's 180m off.

.. so the question becomes, how close can you get the position/velocity estimate and what is acceptable for users? .. in any case the answering the first part (the accuracy) is the most important. Give it a go and report back!

[night-ghost]

the vehicle will still need to estimate its position because it will need to decide when to stop leaning

just a time, 5-20 seconds as good starting point. Will not fly away from known course but still can escape from interference. If still no GPS then land, if GPS returned then RTL

I asked

But before you have allowed yourself an insulting value judgment in relation to people you do not know. Conversation with you is over.

[Pedals2Paddles]

But before you have allowed yourself an insulting value judgment in relation to people you do not know. Conversation with you is over.

Incredibly untrue and also incredibly ironic... lol

[auturgy]

Accidental or otherwise, you did come across a bit rude and judgmental there Matt. I know some of this conversation is a bit rough around the edges, but I think everyone involved actually has good intentions.

[lthall]

You describe an interesting situation. The aircraft loses both RC link and GPS at the same time due to electromagnetic interference low enough over water such that it does not regain RC link and GPS before landing in the water.

I think this is a very unique failure mode but you are correct that flying for a period of time back the way the aircraft came would have regained GPS and RC control.

However, this needs to be measured against all the ways this can go wrong in all the other situations that someone can loose RC and GPS link.

With compass accuracy and varying wind conditions an aircraft can go a long way in 20 to 30 seconds.

My thoughts are that in Australia a pilot must maintain 30m from buildings and people. Therefore I can expect the aircraft has at least 30m in any direction before it can injure someone or damage property. Until now I have considered the most important thing to do with that distance is to get the aircraft onto the ground (or into the water) before it can travel that 30m and damage property or injure people. I don't consider 30m a significant space to do this in.

Can we design a system operating on lean angle and flight time that can navigate back along some random approach path without incurring a position error of more than 30m from the approach path taken by that vehicle?

I don't believe we can do this but I would be very interested to be proved wrong. However, if we do not regain GPS or RC control then we must still land in as safe way possible. I believe that attempting to do this would remove all of the initial 30m safety margin.

I feel partially responsible every time an aircraft crashes or is lost, especially when it is effectively under my control through my input into the design of the failsafes. However, I dread the through of an aircraft hurting a person or resulting in the pilot being sued because the aircraft traveled an unnecessary distance before attempting to make itself safe.

When a feature like this works we won't hear about it. When it doesn't it will be called a fly away and the developers will be blamed for the damage caused and the logs will prove that to be true.

[night-ghost]

My thoughts are that in Australia a pilot must maintain 30m from buildings and people

1. not all lives in Australia and 2. not all flies in city. So pls give to pilot an ability to choose which rules he should follow. I fly only not closer to 100km to nearest city so my rules are jungle :)

You describe an interesting situation. The aircraft loses both RC link and GPS at the same time due to electromagnetic interference low enough over water such that it does not regain RC link and GPS before landing in the water.

here it is not necessary to distort: RC failsafe can be caused by any reason, or it can be RTL from mission outside of range of RC.

[Pedals2Paddles]

Accidental or otherwise, you did come across a bit rude and judgmental there Matt. I know some of this conversation is a bit rough around the edges, but I think everyone involved actually has good intentions.

Not my intent. I do tent to be blunt though. It's frustrating when all the possible problems with the proposed feature are completely ignored, simply demanding it be done without consideration for the big picture.

I should reiterate that I agree that this would be a nice feature if it could be done safely, reliably, accurately, and repeatably. Something I observe has been the premise of any new feature going into ArduPilot. If you can't check all those boxes, then it's not ready for inclusion IMO. That's part of what makes ArduPilot such a rock solid autopilot, and essentially the defacto standard for open source autopilots.

From what I'm reading here, @night-ghost wants this feature added without any of those boxes checked. And furthermore he's unwilling to develop or test any of it. And the purpose is to satisfy a rare edge case failure that was essentially caused by operator error. Honestly it's mind blowing, but I'm trying to be objective.

Now I'm all for protecting even rare edge case operator error, but only if it can be done safely, reliably, accurately, and repeatably. That will require extensive development and testing to get there, and not even guaranteed to be successful. Night-ghost is not going to do that development and testing. Will someone else do it? It would be great to try out and see if it can succeed, if a developer has the time and skill to do it.

[lthall]

To answer the question you posed earlier:

Do you still think that it was not you who drowned these copters?

Yes I do feel like it was me and I feel bad about that. However, there are hundreds of thousands of aircraft being flown by hundreds of thousands of pilots. I need to consider everybody when I make suggestions as a developer.

I believe this feature will result in more crashes and crashes that are more dangerous. I don't believe that the extremely rare situation where this feature would help justify the additional risk it poses to the user base as a whole.

[night-ghost]

From what I'm reading here, @night-ghost wants this feature added without any of those boxes checked.

you a really annoing, please ** the fountain and do not interfere with constructive conversation. If I ever will hit my head so hard so I will want to know your opinion, I will definitely ask.

[Pedals2Paddles]

I believe my comments are constructive, factual, and accurate. I'm sorry you're so troubled by those facts. My intent is not to upset you with those facts.

[night-ghost]

I believe

Believers better go to church and worship their lord.

[khancyr]

not all lives in Australia and 2. not all flies in city. So pls give to pilot an ability to choose which rules he should follow. I fly only not closer to 100km to nearest city so my rules are jungle :)

Nope ! We are ArduPilot, we try to simply flying for every user, not just expert one. And that is also the problem.... I think the general rule here is not to give to much option to the user ... We can already see that with the arming check ... most crash are with disabled arming check and no failsafe behaviours. Adding this kind of option is a double edge failsafe, in my opinion : you try to get back to nominal state but you also lose further possibility to land your vehicle safely as it will already be drifting ...
And finally, Australia isn't an exception ! Most European country impose to RTL or LAND in case of problem. I believe we can only propose this option as compile time option, to prevent to much problem to the project.

We surely can improve the failsafe behaviour, but I don't think we should propose this to the mass. Humm, I just think that this option could be add at a RC_option, it would be an option expressely activated by user (and then his responsability to use it) and won't be saved between reboot.

And about flight over water, we should have a special configuration, like don't automaticly land on the boat, as it may have drift on water, etc .

[Naterater]

Ok, so obviously this solution is not easy to implement in copter due to wind and algorithms/estimates, but I do see a benefit to the community from this.

Suggestions:
-Add options into FS_EKF called "fly toward home" and "attempt RTL"
-Add parameter FS_EKF_AUTO with options "continue" and "revert to FS_EKF"
or
-Add options into AFS for the same options.

These values would not be selected by default, but could save a few aircraft from autolanding or AltHold until they drift to eternity... The fly toward home could be as simple as turn toward home and fly straight forward (not even compensating for wind). It's better than landing in water, and in the event of RC loss, you at least have a chance to regain control.

FYI I ripped the GPS and telemetry out of my plane at the same time this weekend during a FBWA maneuver. I'll check the logs to see what happened during the FS, but ultimately I kept control in FBWA. Luckily the RC receiver wasn't also on the same panel that came undone. If it was, It would have been nice to have a failsafe-glide function when all comms and absolute XY positions are removed from the autopilot.

[rrr6399]

I don't know if the RSSI of the R/C transmitter or GCS telemetry is available to the copter, but if it is, has anybody tried using the RSSI power to get back home? I've heard of older navigation systems that used some type of hunting approach to stay on track using received power from a beacon.

[Naterater]

I don't know if the RSSI of the R/C transmitter or GCS telemetry is available to the copter, but if it is, has anybody tried using the RSSI power to get back home? I've heard of older navigation systems that used some type of hunting approach to stay on track using received power from a beacon.

I'm pretty sure this hunting approach for old airplanes used directional antennas of some sort (on the ground or on the airplanes). ADF was the system that I'm familiar with. Considering most antennas used in this community are multidirectional, I doubt that type of system would work any better than estimating a return to home.

[rmackay9]

Re the RSSI idea, our EKF supports "Beacons" (like the Pozyx system) which provide a distance from the vehicle to a known location. Normally we require three beacons to maintain a good position estimate but even one helps. So not saying the RSSI thing will work but we have some code to handle this type of thing.

[rmackay9]

Re heated discussions near the top of the thread. The key to not getting into vicious arguments is to not get personal but keep the discussion focused on the arguments for and against. If possible, avoid using "you" - it may sound difficult but sentences can be constructed to avoid it.

[priseborough]

If we add the fusion of body specific forces and a drag model, then wind estimation becomes possible in multi-rotors, but not as accurate as plane. I have already added this to the PX4 ecl estimator and it is being used to estimate and compensate for airspeed effects by a commercial drone model. This did require airframe specific testing and tuning.

With development, this could be extended to provide a rudimentary dead reckoning navigation, but the airframe specific testing and tuning effort required would be significant for it to work reliably and would require specialist technical knowledge, so there are no plans to add it any time soon.

[night-ghost]

Re the RSSI idea, our EKF supports "Beacons"

In high electromagnetic interference low-frequency telemetry dies first

so there are no plans to add it any time soon.

no navigation!

What does the dog/cat/etc do when suddenly find themselves in an unfavorable situation? Jump back! Millions of years of evolution have developed this absolutely uncontrolled movement, because first you need to return to normal conditions, and then look around.

So, I do not know how the rest, but I'm talking about this very jump-off in a short time. Not an entirely blind return, but one movement away from danger.

[rrr6399]

Randy, I was thinking of an approach based on the gradient of RSSI where the copter would continuously change direction to maximize RSSI. It wouldn't need to calculate a position, it would just use direction and speed to navigate home. (Similar to way the bad guy, Chigurh, in "No Country for Old Men" used his simple power sensor to find the briefcase of cash with the hidden beacon in it.)

[rrr6399]

Couldn't the PX4Flow sensor be used to determine speed for a copter similar to an airspeed sensor for a plane? It'd be better than dead reckoning with wouldn't it? (I haven't tried the current optical flow capabilities in Arducopter. Would it just work if GPS failed now?)

[rmackay9]

@rrr6399,

The optical flow sensors can definitely be used as a velocity source as long as we also know the distance to the ground. At the moment we rely on a lidar providing that height (the sonar on the px4flow sensor is only good to about 4m) so a long range lidar (i.e. 100m+) plus an optical flow sensor could allow the vehicle to come home fairly accurately.

I've tested this up to about 40m altitude but I've found the vehicle starts to move around a fair bit above that. Still, it might be good enough to get home. By the way an optical flow can be used together with a GPS. The EKF should blend them although I haven't tested it all that much.

[night-ghost]

so a long range lidar (i.e. 100m+) plus an optical flow sensor could allow the vehicle to come home fairly accurately.

what height shows lidar above forest - from level of ground or from tops of trees? I think that baro height will be more adequate.

[rmackay9]

@night-ghost, in general the lidar will show the top of the trees but it depends upon how dense the leaves are. If it's winter it will likely show jumps as it occasionally gets through the trees and hits the ground. As much as possible we want the range returned by the lidar to match the movement detected by the optical flow camera.

A "flat earth" assumption (i.e. only using baro) may work in some situations but not others I suspect. I think it would lead to unreliable behaviour. Using terrain data (sent from the ground station map and stored onboard the flight controller) would do better although it wouldn't include trees and buildings.

If we are looking for other position estimate sources, we have the 3D ZED camera of course as well. It can be pointed in any direction but it can only see depth to about 15m so I'm not sure how well it will perform when it's very high up (probably not well).

Another futuristic option might be machine vision/machine learning. If there were a high powered companion computer on the vehicle with a downward facing camera recording images along with their location as the vehicle flew, then when the vehicle lost GPS, it's possible the machine vision/machine learning could step in with an estimate. This is beyond my abilities to implement though.

[night-ghost]

Another futuristic option might be machine vision/machine learning.

Why futuristic? Mavic Pro flies a year, VISLAM in ROS works pretty fine, but this requires a very powerfull CPU on board with a consumption comparable to hovering current (I tested VISLAM on Atom Z8350, it takes ~3A), so it suitable not for all cases.

BTW - Australia, 30 meters... RTL is doing in assumption that there is no obstacles at RTL_ALT. Which can be set by user eg. to 1 meter. Will be Ardupilot team responsible for caused damage? sure no.
So why so much indignation caused by the desire to move aside without control of direction / distance, but with time control, at the same RTL height, supposedly safe?

[lthall]

Australia is 30 meters from people or property and visual line of sight. So the aircraft should always be able to come directly back to the pilot without hitting anything. This is the 99% case (number pulled from my ass). There is another 1% that are both flying responsibly that a standard RTL could cause a problem. However those pilots are able to use the smart RTL or staging points to ensure safe automated landing in the event that the pilot loses control. Both of these forms of RTL do not add significant risk to a less experienced pilot and are extremely predictable.

To give one example of how what you are suggesting could cause an issue. The pilot is flying away and goes into an area of interference. The Pilot sees the interference rising as the number GPS satellites drop and they get RSSI messages. The start turn around and head back and gain some height to be safe. The slight increase in height pushes them further into the interference causing a failsafe as both RC and GPS is lost.

RTL without GPS is enabled. The aircraft reverses direction back into the interference ensuring that communication and GPS can not be re-established. The aircraft continues for 30 seconds at 10m/s hoping to emerge from the interference. Because the pilot turned around just before the failsafe happened the aircraft is now heading in the wrong direction. The aircraft travels 300m before attempting to land.

So the point is the proposed feature is unpredictable. Failsafe modes should always be extremely predictable with the focus on avoiding harm or damage to third parties.

To take this story to the silly extreme now (just for fun). The radio tower is 250 m behind. The aircraft hits the tower directly in the high gain mm-wave dish, denting the dish with a $250,000 replacement cost. The aircraft falls down the tower hitting the technician working on the tower. The technician fall to his death. And somewhere a baby drops their ice cream. I know this is ridiculously exaggerated but it is the general catch all for the pilot or the arducopter developers are charged with negligence or sued for damages.

So on the flip side. The only way this reaction could make any sense is if the aircraft used the smart RTL points to pick a point that it was at 5 seconds before. It could then travel towards that point for 5 seconds in an attempt to exit the interference. After 5 seconds the aircraft would then land as usual but now it is traveling at 10m/s instead of 0m/s. This would probably keep the aircraft in safe airspace and may move the aircraft 50m out of the interference.

Still a complex and relatively unpredictable response to protect against a situation that is extremely unlikely.

Some ideas have more negatives than positives.

[night-ghost]

The radio tower is 250 m behind.

this game we can play together.

In baseline conditions, the height of RTL_ALT was assumed to be safe - you break that assumption. While maintaining the assumption of safety of RTL_ALT, uncontrolled movement to the side on the same altitude remains safe, but landing becomes dangerous. So if the plane is near tower, got GPS failsafe and decides to land, it will getting into the same mm-wave dish.

[lthall]

Sorry, I don't understand what you said there.

In the same situation if it does an immediate land then it will descend and drift with the wind. So it will move down wind by a distance of the air speed times the time it takes to reach the ground. That could be more than 30m, it could even reach the tower in a strong wind. However, it would reach the tower at a much lower altitude with much lower energy, doing less damage and giving everybody more time to get out the way.

That is all very predictable.

I am not sure what the RTL_ALT has to do with anything unless you are suggesting that the aircraft should increase to RTL_ALT before attempting the RTL without GPS........ That would just increase the potential position error and increase the energy of the aircraft. If the pilot set RTL_Alt correctly then it would mean it missed the tower though. But that assumes the pilot intended to fly on the other side of the tower. The Pilot may have just intended to fly to the tower and therefore not increase the RTL_Alt to clear it.

The point of my example was that the algorithm could easily head in completly the wrong direction if the pilot already started backing out of the dangerous area.

I am sorry but I didn't understand the point you were making in your last message.

[night-ghost]

I didn't understand the point you were making in your last message.

RTL_ALT is an altitude that we considered to be safe to return by a straight line, so there is no any obstacles, right?

So it is safe to do any maneuvers at this altitude, right?

But if aircraft starts to land, it will be at least altitude which already is not safe, and in the end this crazy meat grinder will be on the ground where children, cars and mm-wave dishes.

So I can't understand why you tell me that to land aircraft without GPS is safe and predictable, where to move aircraft on RTL_ALT terribly dreadfully dangerous.

However, it would reach the tower at a much lower altitude with much lower energy, doing less damage and giving everybody more time to get out the way.

The damaging factor of the copter is not the kinetic energy, but the rotating propellers. In this case, if you take care of safety, you must turn off the engines when GPS loss

[lthall]

No, you can't fly over people or property at any altitude and you are not supposed to exceed 400 ft. This is allowed if you are licensed and have permission. So RTL_ALT should be set to clear any obstacles you may encounter as you fly back to home.

So no RTL_ALT is not considered safe for any maneuvers. You must still keep your horizontal distance 30m from people and property to minimise the chance of the aircraft falling and hurting someone.

So by doing a no-GPS land can result in the :) child meat grinder :) but it will be the suspense style horror film style where the blades descend slowly rather than the sudden shock style film where it happens quickly.

As for predictability We have the decent rate (R), height (H) that the aircraft lost GPS and RX and wind speed (W). The aircraft will be grounded and safe in an approximate distance (D) where:

D = WxH/R.

At impact it will have a maximum ground speed of approximately W.

So from that we can calculate the maximum impact energy and danger radius (actually a down wind wedge). So a pilot can be informed and easily understand the risks of flying in a given set of conditions and environment. There are very few people that couldn't do this maths and understand this behaviour.

Can the kids end up in the meat grinder, yes. But given the predictability of the aircraft the pilot is in a position to know that the kids could end up in the meat grinder.

It is not true that kinetic energy is not a factor. I have been in the unfortunate position of having to do the risk assessments and there are detailed studies of exactly what kinetic energies and masses do to the human body. The risks are well studied and widely available.

With the current behaviour there is a serious risk of meat grinding in a down wind wedge up to D from the failsafe and very little risk of serious blunt force trauma.

The risks of the behaviour suggested here is far greater and far less predictable. You have the same meat grinder, you have a much larger radius and it is in all directions, and you have much higher potential/kinetic energy of impact.

[Pedals2Paddles]

The damaging factor of the copter is not the kinetic energy, but the rotating propellers. In this case, if you take care of safety, you must turn off the engines when GPS loss

Untrue. A 6lb+ copter falling out of the sky because you turned off the motors hitting someone in the head, or hitting a vehicle, or hitting a building, is extremely traumatic, possibly fatal. A copter descending slowly to a landing is noisy, slow, and predictable. People have plenty of opportunity to notice it and move away. And if they don't notice it, some lacerations are far less traumatic than a skull fracture. Suggesting that the motors should stop and drop like a brick would be extremely reckless.

[night-ghost]

Untrue

It was ironic if anyone did not understand.

It is not true that kinetic energy is not a factor.

all deadly/traumatic cases was caused by propellers, not by kinetic energy. Kinetic energy is more important for targets like cars.

But in general it's fun to observe the attraction for the ears of arguments to justify own position :)

Back to beginning: forest, lake and radio relay line. No kids, mm-wave dishes

[lthall]

I am glad you enjoyed my justification :)

Back to beginning: forest, lake and radio relay line. No kids, mm-wave dishes

If we were just designing this for you I would say fine, just sign here to say that you absolve me of all responsibility. Then I would give you my invoice and be on my way.

But you are just one of many hundreds of thousands of pilots and while there are no kids in your example there are kids in many many others. And we must consider the feature request in a much wider context than just the one that interests you.

As for no mm-wave dishes, true, no mm-wave dish but you do have a microwave dish at both ends of that radio relay line........

Anyway, it has been fun but I think I have explained pretty clearly why I don't think this is a good idea and why I would actively not support including it. It is only my opinion though, it wouldn't be the first time things have been included that I strongly disagree with. All part of an open source project.

[night-ghost]

while there are no kids in your example there are kids in many many others

some countries have banned flights in general - so we honor their laws, so project is closed and all free, sure? Or maybe it's better to let the pilot decide what is permissible in his case and what is not?

but you do have a microwave dish at both ends of that radio relay line........

sure, that's why even FC in plastic case died in 1st copter. But people can't to see the microwave field, and it's unrealistic to get a map of relay lines for an ordinary person, so one have to send the copters to the bottom to understand what happens. The last of the drowned ones had floats, so we could to get the logs and to see that GPS, radio and telemetry gone in one time.

why I would actively not support including it

do not want to help - go away and do not bother (C) Russian proverb. Yes this is open source and I already maintain my fork, so it will be one more additional feature. As with SafeRTL - you have 100points of return path, I have >4000 :-p

[Naterater]

I guess I'm still not understanding why attempting a RTL is more dangerous than the other options (landing/AltHold). Obviously this would be an advanced feature that is set to land by default.

All of this "safety" discussion is going nowhere. It's obviously situation-specific. If the same ardupilot is going to support the all different shapes and sizes of aircraft in many environments, then it needs to be adaptable. This is a feature that makes it adaptable and applicable to a wide context.

Set the default parameter to what you consider safe and allow advanced users to change it with a warning if necessary. I think a significant number of them would implement this feature.

[night-ghost]

I'm still not understanding why attempting a RTL is more dangerous than the only option (landing)

sure. See discussion about safety of RTL_ALT. if it comes to that, then the return in a straight line at the height specified by the user is much more dangerous - set 1 meter and into the crowd...

Scenario:
Climb up to RTL_ALT. Set a bank 30 degrees for some time, keeping altitude. If no GPS then bank to opposte direction for same time, then land. No additional horisontal speed, no need to maintain position. And warning to user by big red letters - DANGEROUS

[night-ghost]

please ** the fountain

@rmackay9

Randy, you definitely do not know the Russian classics. Kozma Prutkov: "if you found a fountain - shut it!". But Google translator, which I use when lazily to think, seems to have translated not quite as it should. Or in Russian:
Козьма Прутков: "если ты нашел фонтан - заткни его!"

[lthall]

All of this "safety" discussion is going nowhere. It's obviously situation-specific. If the same ardupilot is going to support the all different shapes and sizes of aircraft in many environments, then it needs to be adaptable. This is a feature that makes it adaptable and applicable to a wide context.

Yeh, I know. Because nobody is having a discussion. There have been no counter arguments to what I presented and no demonstration that this feature could meet the standards I set out. The only argument is I want it and everybody else can turn it off. Every developer knows this is not a practical approach.

I am going to close this feature request as it is going nowhere. (excuse the joke)

If a developer wants do build this feature, test this feature, demonstrate that it is a sensible approach and convince the rest of the Dev team it is worth supporting for the rest of the life of the code the feel free to open it again, but for now I am closing it.

[rmackay9]

It is definitely possible to add another option to the failsafes to attempt another behaviour that others may or may not want. So I think ardupilot is "adaptable" as @Naterater suggests.

I actually think we should leave this issue open. I agree it's not going anywhere until a developer attempts it. I don't think any of the core developers think the "aim home and fly" method is going to work but others can come, read this discussion and see the reasoning and try themselves if they like.

I don't think it s worth arguing further whether it the "aim home and fly" will work or not. Someone (perhaps the person who believes it it most - @night-ghost) should try it and report back.

[lthall]

No problems Randy.

[night-ghost]

perhaps the person who believes it it most - @night-ghost

I would like to, but I'm still not very good at the high-level logic of Copter. So, I have not yet found a mechanism for switching to the landing mode when the GPS is lost

[lordneeko]

@night-ghost If you don't understand these articles, then you won't ever understand why this feature won't be considered until it is perfectly safe. The life (or well-being) of the pilot and craft is inconsequential to the life of the innocent by-stander.

http://www.dailymail.co.uk/news/article-462038/How-Spitfire-hero-sacrificed-save-airshow-crowds.html
"The father of three made a last-minute diversion when he realised the emergency landing strip was full of people..."

https://www.cnn.com/2016/06/02/politics/military-plane-crash/index.html
"he was maneuvering so he wouldn't hit any houses. "He made a conscious effort to direct his aircraft away from some of the local neighborhoods."

There are MANY more I could find. As MANY have said, if this can be proven to be safe and reliable, then it could go in. So, I add my agreement to previous comments, PRs are welcome!

I recommend closure.

[rmackay9]

Let's not fire up this conversation again. If someone wants to implement it then they're welcome to and we can see how well it works. No need to argue if nobody's actually going to write it.

[umer936]

So I stumbled upon this issue and believe there's enough information to RTL without GPS. I also see the value in this as someone could be flying over a lake or have taken off from a not-moving boat. Having a parameter to change RTL from LAND/LOITER/RTL without GPS (and without a companion computer) could be useful.

In Texas Aerial Robotics, we were able to navigate using Optical Flow in Guided without GPS. We initialized the EKF origin and home positions manually (sending to Pixhawk2 from a Jetson TX2) to 0,0,0 prior to takeoff and were able to navigate to waypoints. Sending 0,0,2 as the waypoint, then issuing a LAND works just fine in our testing.

The relevant code is here: https://github.com/Texas-Aerial-Robotics/Controls-ROS/blob/master/src/setHome.cpp and here: https://github.com/Texas-Aerial-Robotics/Controls-ROS/blob/master/src/followWithScan.cpp

Don't know how best to implement this in ArduCopter, but it can definitely be done.

[rmackay9]

@umer936, txs for sharing.

If there's an optical flow attached and it's working then AP should be able to fly all autonomous missions (including RTL). I have tested RTL with optical flow only (there's a video on my youtube channel) and it seems to work as long as the vehicle isn't too high. I think this issue is more about the case where we don't have any additional sensors.. just trying to dead reckon back to home which is very difficult.