Discussions

This discussion is a proposal towards an approach that allows an autonomous aircraft to detect sensor anomalies without duplicating sensors. I'm going to discuss this topic from the perspective of multirotors only, since it's a bit simpler, but it would be equally valid for planes.

Most autopilots available in the market today couple the control outputs to the sensor inputs with a bit of processing inbetween. A position and velocity read from GPS are processed to determine, through a control loop, what the changes should be to the motors for this autonomous aircraft to (usually) head towards a waypoint. So in this control loop, the sensor input, the motor output and the control loop are intrinsically connected and there's no indication in this loop which tells anything about a potential failure that may be occurring.

An example: on a multirotor, if a magnetometer is badly configured, heading towards a waypoint means heading towards the wrong direction, increasing the position error and therefore resulting in a fly-away condition. The aircraft does not recover from this situation and will eventually crash in a remote, unknown location unless taken over manually. This is a contributing reason why RPA's and UAV's must have constant pilot attention, because even aircraft in an isolated location cannot be guaranteed to
remain within the constraints of its location (even geofence can fail).

It has been suggested, as is the case in avionics, that duplication of sensors is one of the best methods for averting such disasters. One can read from both sensors at the same time and simply compare one reading with another to monitor large differences. The differences can be thresholded such that the vehicle indicates either a sensor failure and ignore the specific sensor input (if possible), or engage an emergency procedure. The problems with the duplication approach is that the duplication of sensors means adding more weight and that it also doubles the probability that a sensor failure occurs, since there are now two. Also, the onboard system cannot tell whether the system in control is failing or the backup system providing the verification. It will be able to indicate failures and respond to that, but at the cost of extra weight. For very small RPA's, this is a very expensive solution.

In this proposal I'm suggesting an alternative approach which is based on probabilistic filtering. Most control systems at the moment do not develop estimates on the results of the output of the control loop. There's a feedback loop to 'measure' from sensor inputs what the state of the system is, which is then used to adjust the actual outputs, but there's no additional feedback loop which estimates what the result is of that motor output and uses that to compare this with the actual sensor readings to determine if the motor output has the desired effect.

How is this useful?  Well, a very simple feedback loop that is already very effective is to calculate the distance to home. Let's say someone is now 200m away from home and engages RTL.

In the RTL situation, one would expect that the distance would decrease over time. If there's no such feedback in place, then the vehicle could in theory move anywhere over the field and the calculated distance would increase without boundary. If the vehicle determines that it starts to engage a procedure that would result in the reduction of this distance, then it has a measure to verify the actual meaures being taken are having the intended effect.

Similarly for any reading from the GPS with the specified frequency, immediately after that reading the craft could calculate what the next probable position *should* be over time on the basis of the setpoints into the PID controllers. If the actual read input deviates largely and continues to deviate over time, then either the sensor is failing or there's a mechanical failure at play.

This approach fails when a sensor can fail in such a way that it provides the correct reading, yet is actually not faithfully executing that particular action in the real world. So for example, the sensor indicates it's heading to 020 when in reality it's heading towards 170. This is where it becomes important to correlate sensors with one another, since the probability of two failing sensors in this intricate manner is probably nihilistic.

What this enables a control system to do is:
- detect failures in non-essential sensors and deactivate those for control and sometimes rely on backup sensors (for planes, a magnetometer can be disabled and replaced by the GPS direction instead).
- it can detect sensor failure and engage emergency procedures
- it can detect mechanical failures (motor, esc) of the aircraft

The estimates mentioned in the above solution allow for a certain range of error. Rather than hardcoding a  specific threshold between sensor reading and allowed deviation (this I think would yield bad results),
my proposal is to use estimators within histogram filters (possibly kalman filters where needed), which are not fed with the actual motor output (the action), but fed with the requested control output. In usual situations these filters are used to derive location in robotics, but I reckon that if you assume that control in normal cases works correctly, then the same should be usable to allow variation to 'vary' and use that as a measure on how well the system tracks the requested input.

These filters also allow for developing correlation between related sensors, for example magnetometer and GPS dir,  which therefore do not require additional work to describe how they are related between them. Each sensor can be associated with a probability measure (its 'noisiness'), which in this setup is a measure on how long the system may take to action the vehicle into a state that corresponds to the desired input.

The most important attribute to monitor using this system is location.


The solution works like follows:
- there is a 'belief' system which develops an idea about the state (location) of the aircraft. This could be a set of 27   grid cells around a 'current' assumed position of the aircraft.

- when a GPS reading occurs, the system updates its belief system based on that reading. This means that it stays in the same cell or moves to a different one ahead. This step increases information, thus significantly ramps up the probability of being in one specific cell whilst still allowing for sensor reading noise, so also attributes some probabilities in others.

- then the system immediately updates the belief system again before the next GPS read cycle on the basis of a vector where it is intended to go (not where it *thinks* it's going). This means it points out the cell it should be staying in or where it should go if all is correct. This update is done "probabilistic", because the real action of the craft is not entirely known. So it could go left, but also left and up a bit or left and down. What this step does is make estimates on what could happen in real life and this redistributes the probability of being in a specific cell around the belief system. This step "removes" information.

- If the vehicle does track the intention aggressively, the distribution of probabilities of being in any of 27 cells will converge onto one cell. So one cell has a very high probability and others around a bit more with others in "wrong" directions much lower values.

- If the vehicle does *not* track the intention well, then it can be shown that this specific belief system approximates a uniform distribution of values across all grid cells. This means that as far as the system is concerned, the vehicle could be in any grid cell with equal probability. In that particular condition the vehicle should be considered "lost".

The "lost" condition is then the point when the system knows there's either sensory or mechanical failure.


The math for achieving this is actually relatively simple. There are some concerns about memory for containing the grid cells. There are also concerns about processing speed. So the grid should be small and be chosen in such a way that it encompasses a reasonable area per cell. This solution doesn't scale very well if the grid needs to be increased. The grid already makes it clear we're talking about a discrete space allocation here.

An alternative would be the use of a kalman filter, but this unfortunately requires a lot more complex matrix math and convolutions since there are 3 dimensions involved. It's something that's certainly worth doing on PC's, but on embedded software it's more costly. The approach would be similar: use the 'intention' to calculate a vector of 'change' and calculate its new actual position in continuous space and then verify that with the measured position. The calibration of the noises in this model allow for the balance between what's considered ok and what's considered a violation.

Both systems work better if the navigation routines describe a spline because there wouldn't be sudden deviations in intended orientation at waypoints. So probably when the craft hits waypoints it should reset the model and start again, to track the progress from wp to wp.


Anyway, this is my proposal. It's a bit more robust in comparison to other more direct possibilities.
For example, you could derive an "intention vector" and a "real vector" of travel and verify the two and any serious deviations can be flagged as violations. This doesn't cover border cases near waypoint changes very well though and doesn't account for hicups in sensor noise. You would have to specifically include temporal filters and such to make this more reliable.

I would love to hear your comments on this approach.