DJI GEO Coming to Your P3 Soon

[ianwood]

@Brendan Schulman, thank you for joining the thread. I posted a link to your video here when I saw it the other day. It helps a lot to understand more of how it works but I think even more detail is needed to get people comfortable with it. Some questions:

• Exactly what will be restricted and how? Currently it gives examples and says "among other locations". Having a very clear picture of what is included in each category is very important.
• Will the unlocking expire after a period of time, per flight, or will it be in perpetuity? It would be very cumbersome to have to unlock it each flight. Can it be unlocked in advance so that should there be an issue on the day, it will already be done? When taking an Inspire Pro on set, I need to be 100% certain it is going to perform and not be crippled.
• When offline (either remote or using non-online device), we need an established protocol. Unlocking beforehand could help with this.
• Finally, with regard to data confidentiality and privacy, I think it would be beneficial to clarify what "compels us to disclose information" means specifically. Would this information be disclosed or shared without a subpoena? Will DJI provide information on who the third party is that is managing the service? To what levels do they adhere to data security, data privacy and data integrity standards?

 

[SteveMann]

We are bringing this decision-making back to the pilots

Why didn't DJI say that in the first place? A little information would have prevented a lot of speculation.

 

[III% Streve]

Why didn't DJI say that in the first place? A little information would have prevented a lot of speculation.

Technically, they did. The conference that the video was taken at took place better than a week ago. Thats actually what started all of this. But no-one went LOOKING for real info.

 

[dirkclod]

Too busy posting Streve

 

[III% Streve]

Too busy posting Streve

Yup.. I'm certainly a tiny part of the 'everyone'!

 

[snerd]

............. But no-one went LOOKING for real info.

And ruin all of the DRAMA around here?! Never lol!!!

 

[ianwood]

Technically, they did. The conference that the video was taken at took place better than a week ago. Thats actually what started all of this. But no-one went LOOKING for real info.

Hmmm... I created this thread on Nov 17, the same day DJI announced GEO. Brendan's video, which has A LOT more detail in it, was posted to Vimeo on the 20th. I posted it in this thread the same day: DJI GEO Coming to Your P3 In Dec

 

[Oso]

Hmmm... I created this thread on Nov 17, the same day DJI announced GEO. Brendan's video, which has A LOT more detail in it, was posted to Vimeo on the 20th. I posted it in this thread the same day: DJI GEO Coming to Your P3 In Dec

I watched the video you posted the day you posted it. All of it. Am I understanding correctly that the video Brendan posted is not the same as the one you posted?

 

[ianwood]

It's one and the same.

 

[III% Streve]

Hmmm... I created this thread on Nov 17, the same day DJI announced GEO. Brendan's video, which has A LOT more detail in it, was posted to Vimeo on the 20th. I posted it in this thread the same day: DJI GEO Coming to Your P3 In Dec

Yes, but the original post wasnt tied to anything official. Just "news" from an outside source. Not that makes it bad, or wrong. It just let to crazy imaginations. DJI formally announced it on the 20th (DJI Introduces New Geofencing System for its Drones | DJI), and went in to far better detail at the conference. There is no link to any announcement in the article from The Verge. They only say it was announced. I wish I could find the actual date that the video was created.. mostly want to see how that date compares to the statement on the DJI site.

 

[III% Streve]

I guess I totally missed your posting it @ianwood... Just went back and finally get what your saying. I missed an entire page!

 

[dirkclod]

Yup.. I'm certainly a tiny part of the 'everyone'!

Hey Streve...Didn't mean for that to be directed at you

 

[huntjock]

Thank you for taking the time to write this long post. I think that what you are expecting here is way beyond what a phantom is supposed to do and sold for. It has not the capability on board for that. Simple as that.
This is not because some have succeded in going beyond line of sight that the P3 is able to do it safely. You need to consider other types of drones designed for mapping for example.
Also, there are aviation regulations that you have to go by. They are your first concern when you use a drone. They are not flexible and if you really need to bind them to your needs, you have to follow what the gov put in place for this type of request.
Writing softwares is one thing but there are many other things to consider here, and this doesn't exclude knowing the possibilities of the machine and the FAA / CAA regulations. For this matter apparemment you need some information in both of them. And other things as well but It would rise other discussions.
Put simply, If it really is what you want to do, you got the wrong machine.

Shorter response here for those who either have little patience or short attention spans...

Forget the purpose I may have bought my P3P for. That is not for you to decide. I am finding great use for it already - doing pretty much what I have described.

All I am suggesting is that there is hope for DJI to lift dumb limits, primarily the HEIGHT ABOVE HOME POINT limit.

Even simpler example: I can fly my P3P out to 4km and back above LEVEL ground at up to 400m above ground - not because the ground is LEVEL but because the firmware is calculating its height relative to the altitude of the home point. Forget what I might be recording during that trip, ok.

With me so far?

Now, why can I fly that simple route but NOT be able to fly my P3P out to 4 km and back where the landscape actually slopes evenly upward to a point where at 4km away it is now 405m (or whatever the current value enforced by the firmware) above the altitude of my home point? Even if I am flying the UAV only 30m above ground during the flight?

Facilement compréhensible

Again, my point is that if DJI has built the technology and infrastructure to do this 2nd generation NFZ, then it most certainly has the ability to move beyond its 1st generation implementation of other flight limits, most notably height relative to home point (1st generation) vs height above ground (2nd generation).

 

[III% Streve]

Shorter response here for those who either have little patience or short attention spans...

Forget the purpose I may have bought my P3P for. That is not for you to decide. I am finding great use for it already - doing pretty much what I have described.

All I am suggesting is that there is hope for DJI to lift dumb limits, primarily the HEIGHT ABOVE HOME POINT limit.

Even simpler example: I can fly my P3P out to 4km and back above LEVEL ground at up to 400m above ground - not because the ground is LEVEL but because the firmware is calculating its height relative to the altitude of the home point. Forget what I might be recording during that trip, ok.

With me so far?

Now, why can I fly that simple route but NOT be able to fly my P3P out to 4 km and back where the landscape actually slopes evenly upward to a point where at 4km away it is now 405m (or whatever the current value enforced by the firmware) above the altitude of my home point? Even if I am flying the UAV only 30m above ground during the flight?

Facilement compréhensible

Again, my point is that if DJI has built the technology and infrastructure to do this 2nd generation NFZ, then it most certainly has the ability to move beyond its 1st generation implementation of other flight limits, most notably height relative to home point (1st generation) vs height above ground (2nd generation).

The simple answer.... Its stupid easy to create a database of a bunch of GPS coords for airport locations. Even world wide that database would be pretty small in the grand scheme of things. But to include a topographical map of the world?!?!? Thats HUNDREDS OF TERABYTES of data! Yes, it would be nice to be able to do what you are describing. But not physically or technologically possible with the hardware we get for a few thousand $$

 

[n6vmo]

I have been flying at these versions for quite awhile with little to no problems. So, I have taken my tablet 'off the grid' by enabling 'Airplane Mode' and disabling WiFi. Since I fly LOS and use Litchi for autonomous flights, the map will only be good for tracking the whereabouts of the craft and assisting me in returning home, no more nice satellite view.

If I want to upgrade the apps, I will down load it to my desktop and then transfer it via USB to the tablet.

No more automatic updates of any kind for me. Trying to stay ahead of that Geo Fence and public NFZ site activity coming in the near future.

 

[III% Streve]

I have been flying at these versions for quite awhile with little to no problems. So, I have taken my tablet 'off the grid' by enabling 'Airplane Mode' and disabling WiFi. Since I fly LOS and use Litchi for autonomous flights, the map will only be good for tracking the whereabouts of the craft and assisting me in returning home, no more nice satellite view.

If I want to upgrade the apps, I will down load it to my desktop and then transfer it via USB to the tablet.

No more automatic updates of any kind for me. Trying to stay ahead of that Geo Fence and public NFZ site activity coming in the near future.

You really need to educate yourself on what the upcoming geofencing actually is. And most importantly learn that there is no implementation private NFZs! PUBLIC NFZ already exist, and are already blocked. ie Airports!

 

[huntjock]

The simple answer.... Its stupid easy to create a database of a bunch of GPS coords for airport locations. Even world wide that database would be pretty small in the grand scheme of things. But to include a topographical map of the world?!?!? Thats HUNDREDS OF TERABYTES of data! Yes, it would be nice to be able to do what you are describing. But not physically or technologically possible with the hardware we get for a few thousand $$

Streve - with all due respect you are making huge assumptions about the implementation. I can tell you with 100% certainty that this can be done and securely so without the overhead you assert.

Think of it this way...

During any kind of planning of autonomous flights (wp mission, orbit, zipline, follow, etc), any wp or wp set would be validated to be within the allowable limits, including "height above ground" - even NFZ limits.

Online wp validation - DJI would validate waypoints in the background.
Offline - waypoints would be validated using only secure (signed) cached data from map tiles, etc.

These processes would securely validate and sign the waypoints. The P3 firmware would require uploaded missions to include signed waypoints for wp outside of certain parameters.
The firmware would verify the signed waypoints; any flights with unsigned or invalid wp for wp beyond otherwise valid limits would be rejected (upload aborted).

Current cylinder limits would still be enforced for disconnected P-mode flights.

Something along these lines would work. You can verify with independent security experts that this is a sound and secure model - so long as the private key(s) used to sign firmware code and to sign waypoints are never compromised.

The data size overhead for the signed waypoints (vs unsigned waypoints) is negligible. The overhead for the firmware (signature validation)/library (extended API to support requests for signed waypoints as well as code to securely verify validity of cached map data) and possibly the RC code would be relatively small. No overhead of loading terabytes of map data in either the P3 or in your app device.

Certainly doable - and would be another positive move in the direction of supporting using our UAVs for legitimate purposes in legitimate places.

Good to see the DJI guy Brendan Schulman chiming in as well on this thread. I am hopeful that he will take this and champion it in the near future.

 

[III% Streve]

Streve - with all due respect you are making huge assumptions about the implementation. I can tell you with 100% certainty that this can be done and securely so without the overhead you assert.

Think of it this way...

During any kind of planning of autonomous flights (wp mission, orbit, zipline, follow, etc), any wp or wp set would be validated to be within the allowable limits, including "height above ground" - even NFZ limits.

Online wp validation - DJI would validate waypoints in the background.
Offline - waypoints would be validated using only secure (signed) cached data from map tiles, etc.

These processes would securely validate and sign the waypoints. The P3 firmware would require uploaded missions to include signed waypoints for wp outside of certain parameters.
The firmware would verify the signed waypoints; any flights with unsigned or invalid wp for wp beyond otherwise valid limits would be rejected (upload aborted).

Current cylinder limits would still be enforced for disconnected P-mode flights.

Something along these lines would work. You can verify with independent security experts that this is a sound and secure model - so long as the private key(s) used to sign firmware code and to sign waypoints are never compromised.

The data size overhead for the signed waypoints (vs unsigned waypoints) is negligible. The overhead for the firmware (signature validation)/library (extended API to support requests for signed waypoints as well as code to securely verify validity of cached map data) and possibly the RC code would be relatively small. No overhead of loading terabytes of map data in either the P3 or in your app device.

Certainly doable - and would be another positive move in the direction of supporting using our UAVs for legitimate purposes in legitimate places.

Good to see the DJI guy chiming in as well on this thread. Yale/Harvard grad, I think. I am hopeful that he will take this and champion it in the near future.

I see where you are going, but its not just the waypoints that would need validated. Every point BETWEEN those waypoints would as well. Lets set up a mission to fly to the other side of a mountain top for instance. Point A and B are both at an altitude of 1500 ft ASL, but only 50 ft AGL. YOUR altitude is 1050 ft. What you want to do is be able to get to waypoint A, rightly should be able to, except its more than 400 ft above you, so its beyond some imaginary limit or boundary. I get that frustration! But the problem is really that the path between A and B has a peak blocking it. Without an ability to track, in real time, what altitude changes are, there is no safe way to do the mission. It also forces a person to be web-connected while creating missions. Sometimes that might be feasible. Many times it wouldn't be.

 

[huntjock]

I see where you are going, but its not just the waypoints that would need validated. Every point BETWEEN those waypoints would as well. Lets set up a mission to fly to the other side of a mountain top for instance. Point A and B are both at an altitude of 1500 ft ASL, but only 50 ft AGL. YOUR altitude is 1050 ft. What you want to do is be able to get to waypoint A, rightly should be able to, except its more than 400 ft above you, so its beyond some imaginary limit or boundary. I get that frustration! But the problem is really that the path between A and B has a peak blocking it. Without an ability to track, in real time, what altitude changes are, there is no safe way to do the mission. It also forces a person to be web-connected while creating missions. Sometimes that might be feasible. Many times it wouldn't be.

Streve - Your example brings up the point that a valid waypoint A doesn't necessarily imply an uninhibited path to a valid waypoint B. The purpose of signed waypoints is nothing more than to say that "this waypoint, although it may be outside of an otherwise system-implemented limit - is valid - and the UAV can set its course to *attempt* to fly there - that the UAV can be in the air space represented by the waypoint at the specified altitude"

So, yes, you can still actually setup a mission with valid signed waypoints that would crash your UAV.

It is up to the pilot/operator to use maps that actually SHOW impediments like the peak in between points A and B that you used in your example when setting up waypoints - regardless of whether planning while online or offline. ...and then setting additional waypoints to avoid flying INTO such objects. At least you would hope. Validation of all signed waypoints specified by the pilot/operator is performed prior to a successful mission upload/execution, not in-flight.

No realtime calculations needed other than those currently being calculated.

Maybe I am misunderstanding your example (which I have thought through several similar ones already), or maybe I am not being clear in my overly simplistic explanation.

 

[John N Kronyak]

I highly doubt it. There is no way to enforce an action that restrictive

Sent from my SM-G920P using Tapatalk

I forgot to add, 'But not for me".