Skip to main content

Drone Maker DJI Rolls Back Update that Blocked Flights in DC Airspace

drone-crashed-at-white-house-secret-service[1]After being embarrassed when a customer crashed one of its drones on White House grounds, and then rushing out a firmware update to make sure it doesn’t happen again, drone maker DJI is back in the news again today.

It seems that hastily released firmware wasn’t quite as ready to be released as DJI thought. They’re now advising customers to revert to an earlier firmware, and are reporting on their website that some users are having issues:

There have been a small number of reported issues with the latest Phantom firmware, v3.10. In response to these reports, DJI has proactively suspended this firmware update.

In addition to the unspecified bugs, this update was also supposed to add an automatic enforcement of the FAA-mandated no fly zone centered on Washington DC. The FRZ, or flight restricted zone, is an area where it is illegal to fly anything from a model airplane to a full size aircraft, a fact which DJL acknowledges on their website. This includes drones, although of course that never stopped drone owners from ignoring the rules.

DJI had already blocked flights in the flight restricted zone surrounding airports, and this update extended that block to include DC.

Only something went wrong, and DJI isn’t talking. I first read about this story early this morning, and I’ve spent a few hours browsing the DJI forums. The worst I’ve found so far are a few posts that the drone misbehaved after the update.

For example, one user has reported that while running the new firmware, his drone had problems with the battery sensors, and kept declaring the batteries as invalid. A downgrade fixed the problem.

That might not strike you as being enough to go back to the old firmware, but we are talking about $1,000 drones here. If one developed that fault mid-flight it would soon become a very expensive piece of abstract performance art: Drone Descending a Staircase, as it were.

As always, testing for bugs simply can’t be rushed.

Similar Articles


Comments


Jim Self February 6, 2015 um 2:53 pm

Oh, the most insidious bugs take an enormous amount of time to uncover. That’s what non-coders don’t seem to realize: getting it written is step 1. Getting it working is steps 2 through 10.

The Commons February 6, 2015 um 8:38 pm

And then sometimes steps 6-8 repeatedly.

"If you don’t know why it works—it doesn’t."


Write a Comment