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?