With Winter coming in the USA I wonder about pushing the envelope for my Arudpilot (Navio2 and Pixracer) projects.
Is it possible to use the motion and altitude sensors to perform navigation without the benefit of the GPS? Maybe even as a backup RTL capability in case the GPS fails?
I think that the accelerometer data could be turned into positions based on calibrating from a known starting point.
Do you know of any work in this area with ArduPilot?
GPS-denied navigation is a very active area of research and development.
Integrating INS data (accelerometers, gyros) is a form of “dead reckoning” and minor errors from sensor noise inevitably cause your position estimate to diverge from the truth. Lower quality sensors diverge faster. Yes, you can just ignore this error and fly assuming your estimate is the truth, but that’s a VERY risky strategy, probably not worth pursuit.
The active research (a.k.a. GPS-denied navigation) is in using some other external-based sensor (e.g. a camera, or optical flow, or acoustic beacons) to discover the error and remove it from your state estimate. This is hard, but possible.
In fact GPS is doing this exact thing, it’s just SO good and SO cheap that we’ve come to rely heavily on it. Thus trying to fly well without GPS is considered hard.
I don’t know what active projects the ArduPilot community might be working on, but I hope to communicate the difficulty of the issue.
Yes you can fly in GPS denied environment using OpticalFlow that act as a velocity estimator and it is fully fusioned into the EKF for a precise Loiter mode.
You check on this here: http://ardupilot.org/copter/docs/common-px4flow-overview.html
Please note that you need a rangefinder, preferably a Lidar to make this work with ArduPilot.
you didn’t say what sort of vehicle you are wanting to do this on. ArduPilot already does dead-reckoning with fixed wing aircraft. We could do a primitive dead-reckoning with multicopters too, but it is likely be to a lot less accurate.
Doing dead-reckoning with an inertial solution (ie. from integrating accelerometers) doesn’t work for more than a few seconds as errors rise as time-squared. You need to use an algorithm that rises at most linearly with time. That is what fixed wing in ArduPilot does now - basically it is the equivalent of orienteering - using airspeed plus wind estimate plus compass bearing. The error for that rises linearly with time.
It would be interesting to see rudimentary support for some external higher-end INS/AHRS systems, such as the VectorNav VN-100 (or even the VN-300, with dual GPS). Such units also offload the extended Kalman filtering from the flight controller, opening up the possibility of additional sensors (freed up SPI bus?). In essence, these units give you an attitude, velocity, and position solution directly, potentially reducing I/O loading.
The Ardupilot firmware as it is enables very low-cost solutions, but better characterized commercial sensor systems may make inertial fallback more feasible - especially in combination with secondary methods such as optical flow. Naturally, it would not be reasonable for drivers to be made in Master for the hundreds of such products out there, but a framework for the implementation of external AHRS systems which bypass the EKF is a little less unreasonable - perhaps something similar to how external compasses are currently handled?
I wouldn’t object to someone adding support for these types of external estimators, but I don’t see that there is any reason to think they will work better than our current EKF code.
These units have exactly the same maths limits for dead-reckoning as we have now. Error will still rise as T squared for inertial position if you don’t have an external position estimation.
I would like to test this with an airplane. I suppose I could fly line of sight out to some position in a field, then switch to RTL - but with the GPS turned off? Can the existing capability work without an airspeed sensor (perhaps less accurately)?
yes
I mostly test this in the simulator, but I have occasionally tested it in a real aircraft. The aim isn’t perfect navigation, the aim is to get it back close enough that the pilot can take over to land.
I should note that it only works if you did have GPS lock earlier in the flight. It needs that to build up a speed, wind and position estimate.
If you want to test this in a real aircraft the easiest method is to change GPS_TYPE to 0 while flying. Or use the SITL simulator.
I was just typing a new post asking how to do it when your note came in. I had just speculated: Set the home position, take off, fly around in some set pattern for awhile, use a remote telemetry command to turn off GPS, then switch to RTL. As it approaches take over with manual mode. This would have to be a carefully performed flight test.
yes. It’s actually best if you continue to log GPS data but don’t use it. That way the log shows how well the dead-reckoning is performing. Right now there is no remote way to log GPS without using it. I added a method on a transmitter switch when I first developed this feature, but didn’t keep that option in the released code.
I could build you a firmware that does this if you want to try it. You’d need to tell me what board type, and what RC channel you’d like to use for disabling the use of the GPS.
I will try it first in line of sight while circling over a big field with a telemetry-commanded GPS disable. I’ll be able to tell if it is working right away. On the bench I was able to turn off the GPS using telemetry, then switch to RTL using RC control. Then using RC control again, switch back to manual mode.
I read that the autopilot will declare a failsafe condition if it doesn’t see the GPS for twenty seconds - is this applicable here? Hopefully the RC control back to manual mode will supercede the automatic GPS failsafe.
I appreciate the kind offer to make a special release. Please do not do it just for me. If I get that far, it would be with a Navio2, ArduPlane 3.71, and using RC channel 5.
I am actively trying to do this at the moment for my thesis, I am working on the vehicle, while someone else is giving me nice attidude and position/inertial position data over tcp. I have been trying to work out how/where to modify the code, but nothing has been obvious to me. Do you already have something running?
Thanks!!
Tom
Ps not trying to hikjack your post but i couldnt make a new one and were doing similar cool stuff!!!,
While the idea of adding an external, fully integrated navigation solution sparked my interest, I’ve yet to do any significant work on it. My first step would be gaining a better understanding of the low-level, underlying I/F for attitude and positioning, and whether the above layers (DCM, EKF1/2/3) may be elegantly cloven from the stack.
If you’re going this route ahead of me, I look forward to hearing about your results!
Hi there. A few years have passed since the last update on this topic. Perhaps something useful has been introduced during this period that can improve inertial navigation capabilities?
cc @tridge