What I heard (third hand knowledge) is that the DJI Android software stack can't handle AABs and for some reason it's easier for them to just get people to sideload instead of fixing their toolchain.
Ok you’re saying DJI doesn’t understand that modern software is build on top of a moving base whose interface changes over time. It’s called lifecycle support
Most hardware companies operate this way: their devices are on fixed release schedules, and once they're done, they're "done." Virtual Flight was part of the release cycle for some drone or another (I think the FPV potato, if I recall correctly?) and now that it's done, there's nobody allocated to or tasked with fixing it.
So, software is treated the same way. Engineers copy and paste whatever stuck-together yarn ball of code off Gitee they need to produce an artifact which passes QA, then ship it.
The problem comes in when there's software that needs to live for a long time in the real world - Virtual Flight, for example, was broken by some Apple update or another, and their Fly app has to support a broad range of drones so it creaks under the weight of everything being pasted together.
IMO, almost all "hardware" companies trying to make software are the same way. From industrial controls to mobile phone vendors. If anything, DJI have gotten better in recent years about after-sales updates, fixes, and support than they used to be.
This feels to me like an order from a Chinese project manager to have their code "obfuscated". The developers had to comply and put something that satisfies him. This doesn't matter in the least, and the conspiracy theories about this being used for military or intelligence purposes are ridiculous. Any obfuscation will be overcome and the only way around it is for DJI to release both their own hardware and software.
The mention of software bugs seems worrying - I mean, isn't avionics supposed to be second only to NASA in code quality and being bug-free? Or do they just not care that much since there's not a pilot involved?
It takes too long and would achieve little. Flight turnaround times are very tight. The process for updating software on aircraft is, understandably, tightly controlled and only takes place via physical access. Pilots wouldn't know how.
It sure doesn't look good to have two software issues very late in the product development cycle, on a live test. While the first one would have been averted by a human crew, the second one would not be so benign.
Software is hard. Embedded software doubly so, but... Come on... This should not be happening to Boeing.
Thanks for the honest technical write up - not easy to air one's dirty laundry to users. Given the scalability and stability issues, I am curious to understand the percent of apps deployed to fly are actually used in production/critical to business. Sounds like they have quite a few hobby/free tier users (myself included) who probably won't notice certain issues unlike paid customers.
The aerospace industry has realized this a long time, and for some things they will have 3 different devices from 3 different vendors doing the same job
My guess is that IBM believes the software works according to specification. And maybe it does. Maybe the specifications are wrong. Most likely, it's a combination of bad specs and programmed logic errors that don't always follow the specs that are correct.
Of course, this requires testing and time to hash out. It would be a major mistake to scrap a project in it's final phase of refinement. They should have switched over slowly, department by department, handling and resolving issues along the way. But scrapping the entire project now only means another $1B investment and repeat down the road. Trudeau would join the ranks of the FAA in flushing multi-billion dollar software projects. It's a waste. I don't know about this project, but software engineers died on-the-job working on the FAA's AAS that never launched.
The problem isn’t the update itself, which is actually straightforward. It’s the fact that as soon as you modify the software you must do a c check on the craft.
Which is a horribly long process, around 6,000 man-hours and puts the aircraft out of commission for a few weeks.
And on the other hand, there are massive requirements at all levels for this kind of software.
I'm not sure what the right answer is at that point. From dev-experience, I wouldn't want half-assed software directing flights. From ops-experience, I don't want software directing flights requiring specific hardware so you can just replace the hardware with easily available hardware.
I'd be fine with that if it meant that the avionics software was cheaper because it cost less to develop. Your average private pilot in North America is never going to need their avionics to be able to deal with this, just like they don't need the GPS in their car to be able to deal with it either.
As a software developer (not a pilot), I think this misses the mark. Airbus has succeed in commercial fly-by-wire because their system provides protection over the full flight envelope of the airplane (the specs it can withstand without crashing) and also lets the pilots back off on that automation when they need to.
The Boeing MCAS solution isn't full flight envelope protection. As a family member of an Ethiopian crash victim put it, "Why does the software intervene to push the nose down if it thinks it's stalling but not to push the nose up if it's going to hit the ground?"
This is a case of failure to properly certify mission-critical software and it reminds me of Toyota's unintended acceleration problems with the Prius, where the company was found in court to have willfully ignored standard protocols in testing mission-critical apps.
I’m having trouble digging into their tech stack and can mostly just find advertising copy, but from what I can tell they must be integrating software (run on an iPad) into the flight controls. Which makes this a fancy skin on an automatic flight control system, something that most larger helicopters have to varying degrees. I’m not really sure what the actual product that Skyryse has developed. If they are including the requisite servos to manipulate flight controls into their hardware stack then their business proposition is going to run into the problem of any modifications to the flight control system (both digital and mechanical) to that level will necessitate a new type certificate from the FAA. That makes this system far less modular and turn key then they seem to be selling.
The reason you don’t see small helicopters or fixed wing aircraft with complex autopilot systems coupled to the flight controls is that it’s expensive for a lot of the reasons you want it to be - the reliability, airworthiness and usability requirements that make it safe are also expensive to implement. At that price point it’s usually easier to have a human do all that work, especially for the types of missions those aircraft do. The technology has been there for decades, and there’s probably a reason why it hasn’t trickled down to these sorts of small aircraft yet.
Also, do you really want your flight control system to be entirely reliant on ensuring that the latest update to iOS doesn’t inadvertently brick the app that lets you control your aircraft? Let alone the possibility of someone exploiting a vulnerability in iOS to degrade your flight performance. There’s a reason that flight software is not trivially updated.
reply