Brit Watchkeeper drone crashed because blocked sensor made algorithms crash | Hacker News Reader

Brit Watchkeeper drone crashed because blocked sensor made algorithms crash

theregister.co.uk

30 pointsbaud14725815 comments

I have been teaching myself SPARK 2014 and there are a couple of article on writing different parts of drone software in SPARK. Rust also has my attention, but Spark goes beyond Rust’s current capabilities in proving a program. I started to look at F* and F# as a possible toolset, but SPARK has a lot of work behind it. It’s like the Python of the safe and secure programming world. I work on specialized machinery and rides, and we always perform a very formal HRA (Hazards Risk Analysis), and FMEA (Failure Modes and Effects Analysis), and I can’t believe nobody said what happens if the sensor fails!

I always wonder by pitot sensors are so independently important to determining stalls. Why is it so hard to detect a malfunctioning pitot, and then more heavily weigh inertial or GPS velocity data? You could even use all of these in a filter, adjusting the weights based on confidence in the data. We could even call this filter a Kalman filter.

Disclaimer: not an aeronautics expert.

The problem is that airspeed and velocity are not the same thing. Even with an inertial system where you could get the "forward" velocity of the plane, that's not guaranteed to be the airspeed. It has to do with the angle-of-attack and fluid dynamics around the plane.

This suggestion comes up repeatedly, but I think the practical problem is that the vertical air velocity is unknown, and in turbulence, the naturally-occurring short-term variation in it is comparable to the range of the vertical component of the airspeed over the operating range of angle of attack. Maybe with an accurate model of the airplane's response to both gusts and control movement, and data about control movements together with acceleration and rotation of the vehicle, one could estimate this with sufficient accuracy, but the first thing to consider would be more (and heated) sensors (and more robust sensor-driven software, apparently, that can survive the failure of one of its sensors.)

I would guess that with GPS, an additional problem might be the timeliness of accurate-enough data. I would be interested if someone could comment on the state of the art in this regard.

In addition to pitot tubes and AofA vanes, there are various stall warning sensors that detect the movement of the wing's stagnation point as a stall is approached, and these are widely used, at least in the general aviation category. To be fair, they are also vulnerable to the effects of icing.

Update: On reflection, just holding a reasonable attitude would probably be a reasonably effective response to pitot failure, though if your sensors are failing on account of icing, you probably have other problems.

You're right about vertical airspeed, but this also applies to horizontal airspeed. Flying into the wind, you could have a very small groundspeed and yet be nowhere near stalling, or flying with a tailwind quite quickly and be on the verge of stalling anyway.

I agree about holding a reasonable attitude and throttle setting. It won't work forever in shitty wx, but it'll give you a chance to try to figure out a different plan at least.

Good point - I originally did that comparison in a context (MCAS) where the pitots were working, and just assumed it was the right answer here. I later found, from the report, that this drone does estimate airspeed as a function of throttle position, pitch, engine speed and air density, but doesn't make full use of it as an alternative.

I found this in the report:

Air speed estimation. Another way of adding redundancy to a pitot system, or even dispensing with it altogether, is to estimate CAS using other 'non-air' data. WK uses a CAS estimation algorithm, which estimates CAS as a function of throttle position, pitch, engine speed and air density. Presently its output is not used as a redundancy to the pitots, but to calculate the dynamic pressure reference value, which was used in combination with dynamic pressure readings to identify and disqualify erroneous dynamic pressure readings. Several academic papers on CAS estimation exist and the Panel were able to develop a CAS estimation algorithm and prove the concept using WK flight data.

WK = Watchkeeper drone.

CAS = Calibrated air speed. Note that general aviation airplanes are operated perfectly safely with CAS (or actually just indicated air speed) being used as a proxy for angle of attack.

Instead of using this estimate, the on-board computer averaged the values from the two pitot tubes, despite having already ruled them both as giving invalid data. While this is unfortunate, it is also unfortunate that there were only two pitot tubes, and that both of them are prone to being blocked by moisture in clouds or rain, let alone the ice that they were trying to find (the report attributed the blockage to moisture, not ice.)

I think it was interesting since, as inferred from the article, it look like the same failure as the one from the 737Max

> Investigators concluded that one of its pitot probes used for reading the aircraft's speed and angle of attack (AOA) became blocked, causing the Watchkeeper's onboard flight control logic to enter an erratic series of climbs and dives until it stalled itself and flopped into the sea.

Unbelievable!

Similar to how that Tesla car decapitated it's driver a few years ago because it decided a truck trailer was empty sky.

The combination of bad software and bad sensor data seems to be lethal.

> Similar to how that Tesla car decapitated it's driver a few years ago because it decided a truck trailer was empty sky.

This isn't that different from bad biological sensory input that causes a person to think they are stepping on the brake when they're actually stepping on the acceleration pedal. The main differences being that 1) human beings tend to be able to respond to a wider range of scenarios than software and attempt creative problem solving and 2) we have significantly more sensory inputs and they tend to be quite reliable.

Human sensory input fails remarkably quickly if you ever try instrument flying.

True, but in VFR conditions it works quite well. There's no such thing as IFR for cars (yet).

Why can’t an internal gyroscope substitute for an external AoA sensor?

Gyroscopes measure angles in respect to your velocity. AoA sensors measure angles in respect to the direction in which air is hitting the wings.

Reply on news.ycombinator.com