DJI Mandatory, uninterruptible actions are wrong, legally actionable

[GadgetGuy]

Next time you lose signal under tree cover might change your mind. Also, when it simply passes behind a very tall building, I do not want to have to wait while it ascends out of my sight, out of my control, blindly, up up up maybe even 100s of feet to clear the tall narrow building, when simply backing up 15 feet would put it back in signal and right where I left it, a place I know is safe and in VLOS. I'd prefer as little autonomous flight as possible, especially in the most blind direction on this drone, up. Sensors of some kind in every direction except that one and that's where you want it to blindly climb?


Sent from my iPad using PhantomPilots

True. I rarely ever fly under objects, although I have done so at full speed under 4 lane bridges, so I could clear them before 3 seconds of signal loss! My experience with the retracing feature is that it isn't working as it should. There is a significant delay before it kicks in, far greater than the time to restore signal from ascension on the P4 with normal RTH behavior. I only lose signal when flying over a ridge and descending too quickly along the back side of the ridge while flying parallel to the descending ridge. Ascension by even 10-20 feet is all I need in that case, and the old RTH works better. However, I do wish it was user selectible, but last time I looked for the option, to opt out of this feature, I couldn't find it on iOS DJI GO 4.

 

[GadgetGuy]

One solution isn't likely perfect in all cases, of course. Isn't it nice to have more than one solution available?


Sent from my iPad using PhantomPilots

Indeed!

 

[Scubamaniac]

I'm going to try to state this in layman's terms for the readers who might not have a deep knowledge of software development.

Third party apps like Litchi, Autopilot, DroneDeploy and all the others can run without DJI Go - but they do not communicate with the drone directly. They are developed using an SDK (software development kit) provided by DJI which includes basically a "runtime" or a "proxy" of sorts. DJI provides this SDK so that third parties can write software that extends the capabilities of our drones.

The third party software sends instructions to the DJI SDK and the DJI software interprets those instructions, translates them into commands for the drone and then transmits them to the drone. At no time ever does the third party software ever communicate directly to the drone.

As far as your NFZ question is concerned - it's my understanding that they are built right into the firmware that permanently resides on the drone itself. There may be the possibility that this permanent list is augmented by the SDK or by DJI Go or the third-party app (or will be in the future) so that temporary NFZ's and TFR's can be uploaded as they are defined - but the bulk of permanent NFZ's exist in the drone itself and/or in the DJI SDK that the third party app communicates through - so, many of our drones automated behaviors can NOT be overridden/avoided by using 3rd party software.


Sent from my iPhone using PhantomPilots

Thanks, I am in the IT business so I completely understand what you said. Being it's built into the drone and/or SDK I guess the only time the NFZ or TFRs (do they do TFR's or just NFZ?),. I would think it would be impossible for the TFR's to be done as they change much more often compared to NFZ's. Just soaking all the knowledge in as much as I can ;-) Thanks for the info!

 

[Tenly]

Thanks, I am in the IT business so I completely understand what you said. Being it's built into the drone and/or SDK I guess the only time the NFZ or TFRs (do they do TFR's or just NFZ?),. I would think it would be impossible for the TFR's to be done as they change much more often compared to NFZ's. Just soaking all the knowledge in as much as I can ;-) Thanks for the info!

Impossible is a strong word. There could be code in the SDK that attempts to reach out to the internet if a connection is available and download a supplemental list of NFZ's or TFR's and then transmit them to the drone to extend the built in NFZ list.

I don't think they're currently doing so - but it would certainly be possible for them to do in the future if they decided they wanted to. They could limit the size of the transfer by only downloading/transferring the data for NFZ's within a 20 mile radius of your current location. Obviously, the supplement could be defeated by using a device without internet access - but they might decide that "best effort" is good enough - or they could decide to require an internet authentication at least once per month (during which they would download updates).

I doubt they will take it this far - but wanted to highlight that live updates to TFR lists is a long way from impossible.


Sent from my iPhone using PhantomPilots

 

[dwallersv]

The updates can be even more automatic than described above... On Android, the most logical (and most consistent with Android application design guidelines) would be to create a Service component of the app that runs in the background all the time, whether you've launch DJI GO (or Litchi, etc.) or not. The service starts up and runs whenever you boot the device (phone/tablet).

It watches the network availability (again, extremely common functionality, there are interfaces in the Android API for just this purpose), waking up and retrieving updates to the NFZ database whenever there's a connection.

If the Android engineers at DJI have the tiniest modicum of Android experience, I'm as close to 100% sure they implemented it this way as I can be.

iOS I can't speak to.

 

[N017RW]

Impossible is a strong word. There could be code in the SDK that attempts to reach out to the internet if a connection is available and download a supplemental list of NFZ's or TFR's and then transmit them to the drone to extend the built in NFZ list.

I don't think they're currently doing so - but it would certainly be possible for them to do in the future if they decided they wanted to. They could limit the size of the transfer by only downloading/transferring the data for NFZ's within a 20 mile radius of your current location. Obviously, the supplement could be defeated by using a device without internet access - but they might decide that "best effort" is good enough - or they could decide to require an internet authentication at least once per month (during which they would download updates).

I doubt they will take it this far - but wanted to highlight that live updates to TFR lists is a long way from impossible.


Sent from my iPhone using PhantomPilots

What are the limits of App. developers' liability in something like this?
Such that an App fails to advise properly, accurately, etc, and the operator puts him/herself is a situation where there is negligence, harm or destruction as a result.

Despite disclaimers can their be an exposure to several liability?

Even if not held liable, what about costs to defend allegations?

 

[dwallersv]

What are the limits of App. developers' liability in something like this?
Such that an App fails to advise properly, accurately, etc, and the operator puts him/herself is a situation where there is negligence, harm or destruction as a result.

Despite disclaimers can their be an exposure to several liability?

Even if not held liable, what about costs to defend allegations?

Couselor, in your expert opinion, should the automatic braking system available in some cars today erroneously determine a collision was imminent and slam on the brakes, thereby causing a severe rear-end collision by the car behind the offending vehicle, resulting in bodily injury and totaling the car, do you think the auto manufacturer would be sued, and would such a suit be successful?

I most certainly do. Further, I believe, based on MY experience, a decent defense attorney for the owner of the offending vehicle would be able to defend them from any liability exposure whatsoever.

It would be an easy case to win.

DJI is in exactly the same legal position in this case.

 

[Scubamaniac]

Impossible is a strong word. There could be code in the SDK that attempts to reach out to the internet if a connection is available and download a supplemental list of NFZ's or TFR's and then transmit them to the drone to extend the built in NFZ list.

I don't think they're currently doing so - but it would certainly be possible for them to do in the future if they decided they wanted to. They could limit the size of the transfer by only downloading/transferring the data for NFZ's within a 20 mile radius of your current location. Obviously, the supplement could be defeated by using a device without internet access - but they might decide that "best effort" is good enough - or they could decide to require an internet authentication at least once per month (during which they would download updates).

I doubt they will take it this far - but wanted to highlight that live updates to TFR lists is a long way from impossible.


Sent from my iPhone using PhantomPilots

You are right, I shouldn't of said impossible as it would be very possible, however I was just saying at this point, getting real time information on TFR's and getting them to you and cancelling them on your system in "real time" is currently not possible. You never know what the future holds when it comes to software development, but hopefully it's always an improvement and not a bug fest ;-)

 

[GadgetGuy]

You are right, I shouldn't of said impossible as it would be very possible, however I was just saying at this point, getting real time information on TFR's and getting them to you and cancelling them on your system in "real time" is currently not possible. You never know what the future holds when it comes to software development, but hopefully it's always an improvement and not a bug fest ;-)

One of the reasons GEO is not yet mandatory is that it is still a major bug fest!

 

[Tenly]

What are the limits of App. developers' liability in something like this?
Such that an App fails to advise properly, accurately, etc, and the operator puts him/herself is a situation where there is negligence, harm or destruction as a result.

Despite disclaimers can their be an exposure to several liability?

Even if not held liable, what about costs to defend allegations?

I'm not a lawyer - but I would say that if the automation software takes some action that causes or contributes to an incident/accident, then the developers are vulnerable.

I do not however think that the software taking no action - or "not" doing something (like displaying a warning message) is something they could be held accountable for. It doesn't mean people won't try - but they won't be successful.

At the end of the day, the pilot in command is the responsible party - at least as long as he is in control of the craft. If the software takes that control away from the pilot - the software becomes the pilot in command and MUST be held accountable. It's not much different than me happily and safely flying my Phantom when some goon comes along, knocks me out and grabs the remote from me without my permission and then proceeds to fly it into a crowd of people. Who's responsible? Me for owning the drone and beginning the flight? Or the pilot who was in control/command when the accident happened?

As for individual developer liability - not likely. The company that they work for - certainly. The company that owns/releases the software is responsible for determining *when* that software is ready for release. It doesn't matter which developer creates it - there is a QA process that happens before it is released that is responsible for ensuring its ready. The developer is adequately isolated and protected from liability. If buggy software is released, the company is negligent because they did not perform adequate testing/review.



Sent from my iPhone using PhantomPilots

 

[Scubamaniac]

One of the reasons GEO is not yet mandatory is that it is still a major bug fest!

Ah ha!!

 

[dwallersv]

Not sure if this has been mentioned... On p. 47 of the manual it clearly states that when in ATTI mode the only restriction enforced is altitude limits in Restricted Zones. And if one is encountered in A mode and then the RC switched to P mode, it will descend to 15 feet below the limit, and hover.

Regarding NFZ, it says this: "If the aircraft enters the NFZ in A mode, but is switched to P mode, the aircraft will automatically descend, land, and turn off its motors".

Which makes me wonder: What happens if you switch to A mode from P mode when encountering an NFZ? Will that stop the autolanding, and enable you to fly? Do you still get AC GPS telemetry even though you're in A mode (which would assist greatly in flying clear of the NFZ as fast as possible)?

Can someone safely test this out as follows: Go to a known NFZ that is basically unnecessary (like one around a small airstrip that may go days sometimes with no one taking off or landing). You should not be able to take off in P/S mode, but you should be able to in A mode.

Take off in A mode and ascend to 20 ft or something. Switch to P mode and it should force-land.

Try again, but when it gives you the warning and starts the forced landing, switch it back to A mode and see if you regain control.

If this works, it is at least a workaround to the problem when the warning appears on the screen.

 

[42FrankZ]

Not sure if this has been mentioned... On p. 47 of the manual it clearly states that when in ATTI mode the only restriction enforced is altitude limits in Restricted Zones. And if one is encountered in A mode and then the RC switched to P mode, it will descend to 15 feet below the limit, and hover.

Regarding NFZ, it says this: "If the aircraft enters the NFZ in A mode, but is switched to P mode, the aircraft will automatically descend, land, and turn off its motors".

Which makes me wonder: What happens if you switch to A mode from P mode when encountering an NFZ? Will that stop the autolanding, and enable you to fly? Do you still get AC GPS telemetry even though you're in A mode (which would assist greatly in flying clear of the NFZ as fast as possible)?

Can someone safely test this out as follows: Go to a known NFZ that is basically unnecessary (like one around a small airstrip that may go days sometimes with no one taking off or landing). You should not be able to take off in P/S mode, but you should be able to in A mode.

Take off in A mode and ascend to 20 ft or something. Switch to P mode and it should force-land.

Try again, but when it gives you the warning and starts the forced landing, switch it back to A mode and see if you regain control.

If this works, it is at least a workaround to the problem when the warning appears on the screen.

So you are asking someone else to go test this, which might mean doing something illegal or that they could loose their aircraft?

Why don't you volunteer to be the guinea pig instead?

 

[Drestin Black]

Not sure if this has been mentioned... On p. 47 of the manual it clearly states that when in ATTI mode the only restriction enforced is altitude limits in Restricted Zones. And if one is encountered in A mode and then the RC switched to P mode, it will descend to 15 feet below the limit, and hover.

Regarding NFZ, it says this: "If the aircraft enters the NFZ in A mode, but is switched to P mode, the aircraft will automatically descend, land, and turn off its motors".

Which makes me wonder: What happens if you switch to A mode from P mode when encountering an NFZ? Will that stop the autolanding, and enable you to fly? Do you still get AC GPS telemetry even though you're in A mode (which would assist greatly in flying clear of the NFZ as fast as possible)?

Can someone safely test this out as follows: Go to a known NFZ that is basically unnecessary (like one around a small airstrip that may go days sometimes with no one taking off or landing). You should not be able to take off in P/S mode, but you should be able to in A mode.

Take off in A mode and ascend to 20 ft or something. Switch to P mode and it should force-land.

Try again, but when it gives you the warning and starts the forced landing, switch it back to A mode and see if you regain control.

If this works, it is at least a workaround to the problem when the warning appears on the screen.

I've tried it, still forces an automatic and uncontrollable landing, ignoring everything below it.


Sent from my iPhone using PhantomPilots

 

[AlecW]

My 2 cents:

The driving force on this issue are DJI's American lawyers. If a drone owner causes a catastrophic accident near an airport who do you think the victims are going to sue? The drone owner might be good at best for a few hundred grand, they would for sure also go after DJI.

 

[Tenly]

So you are asking someone else to go test this, which might mean doing something illegal or that they could loose their aircraft?

Why don't you volunteer to be the guinea pig instead?

Why are your posts all so antagonistic and miserable? A little bit of sarcasm is okay once in a while if a post has something valuable and interesting in it - but so far I haven't seen one like that from you. No value and nothing interesting - just condescension, derision and misplaced arrogance with a touch of contrarianism. Going forward, if you don't have any value to add or anything nice to say - please don't hit reply, just hit next. (Thanks)

The guy you replied to, did some research and brought something new to the table which might have, at least partially mitigated the problem reported by the original poster.

Obviously he has no way to test his theory safely near him, so he posted the information he discovered and asked if anyone else could test it - SAFELY. And you snapped at him for it. If you don't want to test it for him - that's fine. Let the rest of us consider the risks and rewards of doing so and decide for ourselves whether we can do the tests safely and if we are willing to.



Sent from my iPhone using PhantomPilots

 

[42FrankZ]

Why are your posts all so antagonistic and miserable? A little bit of sarcasm is okay once in a while if a post has something valuable and interesting in it - but so far I haven't seen one like that from you. No value and nothing interesting - just condescension, derision and misplaced arrogance with a touch of contrarianism. Going forward, if you don't have any value to add or anything nice to say - please don't hit reply, just hit next. (Thanks)

The guy you replied to, did some research and brought something new to the table which might have, at least partially mitigated the problem reported by the original poster.

Obviously he has no way to test his theory safely near him, so he posted the information he discovered and asked if anyone else could test it - SAFELY. And you snapped at him for it. If you don't want to test it for him - that's fine. Let the rest of us consider the risks and rewards of doing so and decide for ourselves whether we can do the tests safely and if we are willing to.



Sent from my iPhone using PhantomPilots

Just because I don't buy into your view of life doesn't make me a contrarian. before you 'cuse you better take a look at yourself.....

I think I had a valid question, which you swept aside with your need to show how much better of a human being you are. Of course you have no idea of why he is asking people to do something that he could do, if he really wanted the answers.

Next time you can keep your opinion to yourself, just post things that further the hobby, don't ask questions or comments otherwise.

 

[dwallersv]

So you are asking someone else to go test this, which might mean doing something illegal or that they could loose their aircraft?

Why don't you volunteer to be the guinea pig instead?

I certainly plan to next time I'm reasonably within range of an NFZ. For now, it simply isn't practical.

However, I judged that to be a pretty foolish reason not to share what I found in the manual.

 

[GadgetGuy]

I've tried it, still forces an automatic and uncontrollable landing, ignoring everything below it.


Sent from my iPhone using PhantomPilots

Thanks for testing it. The results are scary!
Which aircraft, which version of the app, and with GEO on or off?
The results may be different in each case.
I encountered an NFZ (presumably not inside of it) and it said the P4P aircraft, on iOS with GEO off, would just hover in place, which then still allowed me control to fly around and away from it.

 

[Gerald Lee]

p.s., DJI - there is a really quick and easy fix you can do for flying into No Fly Zones, by the way. Instead of initiating a unstoppable automatic landing. Initiate, without delay, a Smart Return to Home. This way, the NFZ isn't violated but you leave control of the craft in the pilots hands.

Ok now there's a solution i can agree with, a safe RTH initiated at the point of NFZ breach. That way we stay in control of our machines and our responseability. Absolutely head of the logical nail good job. And also, thank you for opening this subject up it definitely needs to be addressed and solved before, like others have already stated "before someone is hurt or worse.