More Air Force drones are crashing than ever as mysterious new problems emerge
washingtonpost.com
washingtonpost.com
Once the problem was diagnosed, fielding the solution is / was another challenge. Some of these aircraft are in pretty remote areas.
These aircraft gained popularity and rapid adoption because they're substantially less expensive and VASTLY quicker to manufacture than any other option. Almost all customers prioritized cost and acquisition speed over long term reliability, which of course comes with a certain amount of risk. Testing and certifying an airframe to standards is expensive and time consuming [2] but has the advantage of improving reliability.
Also, this is just hogwash journalism.
> Last year, the Army reported four major drone crashes, each involving the Gray Eagle — a model identical to the Predator.
Warrior / Gray Eagle / MQ-1C [3] is a 40% payload increase over Predator / MQ-1 [4] and the airframe was almost completely redesigned. Hell, the engine is even different. It's a different aircraft.
[1] https://en.wikipedia.org/wiki/General_Atomics_Aeronautical_S... [2] http://www.ga-asi.com/certifiable-predator-b [3] https://en.wikipedia.org/wiki/General_Atomics_MQ-1C_Gray_Eag... [4] https://en.wikipedia.org/wiki/General_Atomics_MQ-1_Predator
Any more details on this?
Why was the article produced and disseminated? Why now? Why with the noted quality issues?
Fishy
Strong EMF next to an un-shielded chip? (Bit flips, no ECC and no lockstep systems to validate against)
Improper coating causing a thermal problem, either causing a sensor to fail, lie or some electronic component to break it's solder.
Some wild ass guesses on my part
This is the leading theory. Most of the observed failures seem heat related and are likely due to an increased resistance of the brush to shunt connection. This can be caused by quality issues of the brush rivet during initial manufacturing (coil coating) and/or improper torque of the brush shunt screw during assembly (installation error).
The variation in resistance at individual brush sets can lead to uneven current density, causing high heat at the brush to commutator interface which results in excessive wear and damage to the commutator surface and/or brush and ultimately leads to a starter generator failure.
In addition, the software wasn't reporting failure of the component.
I should add a disclaimer that root cause failure investigation is extremely complicated and difficult. It's possible that not all failures were / are the same and there are many other possible contributing causes.
It sounds like for now, contractors are only running surveillance missions.
What if contractors:
* Fly the drone and release ordnance that kills someone.
* Fly the drone but military personnel pushes the button that kills someone.
Does the contractor as a civilian bear liability differently than a member of the armed forces? Could a foreign country try to extradite and prosecute them? Could a foreign country arrest them if they left the USA?
As long as the guys frame it in terms of protecting the homeland, national security or some other vague excuse, we don't seem to care.
It's when the guys that we don't like do it that we raise hell.
It's sickening, but that's what we've become.
This will always happen in a military context, and this is why it is so important to have real civilian oversight. Expedience plants the seeds of future wars.
What we've become? You think if armed drones were in the inventory during Iraq, Vietnam, Korea, or WWII they wouldn't have been used because of some lost sense of nobility?
That said contractors have been doing the intelligence analysis behind missions to kill people using drones. Even though the missiles are fired by uniformed soldiers, there's a big gray area right behind them.
Hmmm...
There is a disconnect, flying by wire you don't feel turbulence and changing conditions, rather you logically go about it, being overworked its not hard to see where one can whoopsie daisy it.
I find it incredible that they know where the problem is, but not how to fix it. Get 100-1000 of them and start stress testing them in a lab. This stuff isn't rocket science.
They should just print out a sign that says "lab" put it on an empty room, place the starter motor in the middle of it, and then suddenly they would know why it was broken. It is in a lab after all! This isn't rocket science! Or if one in an empty room fails put 100-1000 into the empty room, it has GOT to work!!! It is too easy to fail! Being in a lab is all that it takes!
I'd suggest you watch this[0], this issue was literally costing human lives, they knew there was a rudder issue, they placed it in a lab, testing it for thousands of hours and ultimately found it by a little luck. It moved our understanding of failure states forward.
There's no reason to assume that finding the issue with the starter motor is easy or trivial. No amount of lab hand waving changes that, it will take just brute effort.
Obviously figuring out which circumstances are the ones that are actually responsible for failures will be more difficult. But it's not too hard to do some sensitivity analysis to get some clues.
If they're highly sensitive to having too much current drawn then that might make you suspect that somehow, somewhere the system's power demands are overwhelming the generator and that's what is causing the failure.
The point behind "it's not rocket science" is that rockets are very, very expensive to make and so you can't just test as many of them as you'd like, for as long as you'd like, until you through trial and error reproduce the conditions that caused the failure. You also don't get the rocket back when it either succeeds or fails.
But in this case the starter/generators are cheap, and they are able to in many cases sort through the debris of the crash. So that does make it qualitatively and quantitatively different than rocket science.
That's very, very different than physical objects.
When software controls hardware, yes things can get weirder. But the software can't cause magical things to happen; the atoms don't rearrange themselves.
Bit flips tend to be much more like magic, if applied to the real world. A wrench doesn't stop working because you swap out a single atom. But software can, if you flip the wrong bit.
> That's very, very different than physical objects.
True... spontaneous changes to the structure of physical objects are quite a bit more likely. One of software's greatest features is that it's not subject to the physical wear that physical tools experience.
Actually if the components catch on fire or something finding out which one shit the bed is by far the easiest part of the entire ordeal, assuming it's not spread over the face of a mountain.
In the case of something like the 737 rudder problem, those planes were designed 40 years ago, in an era when it wasn't practical to record every bit of operating data in real time, or add cheap, lightweight sensors to everything in sight. That's not true anymore. Whether they're building a drone, a fighter plane, a spacecraft, or even a modern passenger car, there is no excuse for requiring people to stand around some wreckage scratching their heads. The onboard controllers should be able to tell them exactly what went wrong. If they can't, then that's the problem to be solved first.
And this can provide incredible amounts of information, and get us closer to the source of issues much faster. Many times, it makes the issue immediately obvious and documented.
HOWEVER! Do NOT make assumptions and fool yourself into thinking this is a cure-all. There are many problems that, while the logged sensor data narrows it down and provides clues, it can sometimes either not provide the critical clues, or can even be misleading. Yes, sometimes adding more sensors focused on the issue may help, but not always.
Sometimes it is just down to the hard work of finding the peculiar circumstances and interactions that cause previously unknown failure modes.
Been there, done that (UAV & motorsport systems), seen lots of very smart & experienced engineers stumped for way longer than you'd expect.