DJI A2s having problems with recent firmware - Multiple reports including crashes

P13

P13

Well-known member
Problems with the DJI A2 (probably firmware related but not entirely confirmed) have resulted in some UK dealers recommending the Wookong instead and one experienced user going as far as stating the A2 "is not fit for commercial use" http://www.multirotorforums.com/sho...ade-Guinea-Pig&p=165469&viewfull=1#post165469

Problems appear to be around the 2.1 and 2.2 firmware: http://www.rcgroups.com/forums/showthread.php?t=1982087&page=101

People have had smashed kit as a result, including a Canon 5D Mk3 up to a Red Scarlet, DJI by their own admission (totally contrary to good software practice) have replaced the 2.2 firmware with a different version (fixing a bug in an earlier version) without updating the version number, one commenter said of this "I find this very sneaky and feel very sad for the people that have had equipment damaged."

http://www.rcgroups.com/forums/showthread.php?t=1982087&page=99

It's so sad that all these problems could be avoided with proper software testing, I find it puzzling that open source flight controllers are under going lengthy testing cycles, whilst an expensive supposedly commercial product clearly isn't.
 
The firmware 2.2 has been reflashed. Engineers said it is safe now. I'm going to run a test on 2 of our S1000 and 2 of our S800 tomorrow. Standby for an update
 
Thanks for the reply Willis.

There are some very serious concerns here, for one, the norm, adhered to worldwide by any company serious about software development is to have proper version control and release notes. DJI unlike any company I've ever seen in software/hardware seems to show disregard for such proper process.

DJI release notes only ever list items as enhancements, even when they're clearly bug fixes, the release notes I'm sure don't list all changes, as for example I don't believe anyone was aware of the DRM battery check being present until after it started creating false positives causing Phantoms to auto land (even over water). DJI without doubt have the poorest release notes of any common FC that I've come across, for sure 3D Robotics and Openpilot are doing proper release notes and this difference is being noticed.

This situation worries me a lot, it's bad enough customers are having expensive video gear destroyed with crashes caused wholly or in part due to bugs or malfunctions, even when insured that's a £500 excess customers are having to foot, but sooner or later DJI will have a bug that's going to seriously injure or kill someone if you don't get a grip of your software QA, that would be unforgivable.

I've been a long term DJI owner but I've seen clearly in that time firmware releases that introduce bugs so significant as to prove little or no software testing has taken place, this led me to start looking at other flight controllers and the testing behind them and I'm gobsmacked at the difference.

I recently quizzed a 3DR developer and was informed that for each major release over 6 months with > 50,000 hours of testing is done, whilst I've not asked for a detailed figure on it, Openpilot appears to also adopt testing over at least as many months. I can look online and see developer notes, chats, bug discussions, I can even watch YouTube videos of the testing taking place proving the development has been over months and been field tested repeatedly.

Meanwhile, it seems DJI at best mention bugs only after they become public and only do so on RC forums, leaving the rest of the customer base in the dark. You should e-mail and warn your customers at very least, then take a long hard look at your software development, get it audited and start making some changes, before someone gets hurt.
 
Last edited:
I have updated from 2.1 to 2.2 back to 2.1 to 2.2(new) and now to 2.3. All seems to be working well again. This is on an S1000 with GH3 Zenmuse and A2 of course. We do use ours on commercial shoots. I will say that I do wait a fair amount of time before doing firmware upgrades, and only do them if there is a change that will make exactly what I am doing better. Problems are going to happen with technology, same reason cars have recalls 5 years after they are released. We are in emerging technology, if you want things to be super safe, always fly in manual mode.

Gotta take a chance at some point.

Nick
 
The defense this is an “emerging technology” doesn’t at all excuse little or poor software testing, you’ve to remember I’m comparing against practice the world over in software development and also in the same field by the Open-source community and at least one other commercial builder. Software development processes date back decades so aren’t new, having a proper testing process that doesn’t just involve unit testing on simulators is crucial, testing over a period of time with real hardware and having proper release notes is key, if for no other reason than it lets people decide if they need to apply a new firmware or not.

For example 3D Robotics had a beta programme with 100 testers before the IRIS got sold to consumers and where faults have been found since, the users have been e-mailed, instructions have put on video and >free< parts (even internationally) are shipped to customers to ensure they’re running without any known faults.

Manual isn’t even truly manual either as the controls are still being directed through the flight controller, just less processing is taking place on them (you’d assume it would be purely a pass through but that assumption might not be true), so don’t assume manual shields you from bugs, it's already been proven to not be the case, for example the battery bug in the Phantom would happen regardless of flight mode.

In a nutshell, all I’m saying is that good common sense practice should be adopted.

  1. Test not only on simulators but end to end, having testers using real hardware, preferably in different countries, the latter to pick up GPS or compass issues. Consider a proper beta programme.
  2. E-mail customers about serious bugs as soon as they are known and don’t rely on posting on one or two RC forums as a way to communicate news.
  3. Provide detailed and complete release notes that clearly identify bug fixes from new features.

None of those recommendations are rocket science, unreasonable or controversial.
 
Last edited:
P13 said:
The defense this is an “emerging technology” doesn’t at all excuse little or poor software testing, you’ve to remember I’m comparing against practice the world over in software development and also in the same field by the Open-source community and at least one other commercial builder. Software development processes date back decades so aren’t new, having a proper testing process that doesn’t just involve unit testing on simulators is crucial, testing over a period of time with real hardware and having proper release notes is key, if for no other reason than it lets people decide if they need to apply a new firmware or not.

For example 3D Robotics had a beta programme with 100 testers before the IRIS got sold to consumers and where faults have been found since, the users have been e-mailed, instructions have put on video and >free< parts (even internationally) are shipped to customers to ensure they’re running without any known faults.

Manual isn’t even truly manual either as the controls are still being directed through the flight controller, just less processing is taking place on them (you’d assume it would be purely a pass through but that assumption might not be true), so don’t assume manual shields you from bugs, it's already been proven to not be the case, for example the battery bug in the Phantom would happen regardless of flight mode.

In a nutshell, all I’m saying is that good common sense practice should be adopted.

  1. Test not only on simulators but end to end, having testers using real hardware, preferably in different countries, the latter to pick up GPS or compass issues. Consider a proper beta programme.
  2. E-mail customers about serious bugs as soon as they are known and don’t rely on posting on one or two RC forums as a way to communicate news.
  3. Provide detailed and complete release notes that clearly identify bug fixes from new features.

None of those recommendations are rocket science, unreasonable or controversial.
Click to expand...

Well said
 
You must log in or register to reply here.
Back
Top