Hi There,

second post within minutes - guess I like this forum.

I found an akward and potentially easy to improve behaviour on my Mini 4 Pro.
It affects the location accuracy before takeoff and potentially also causing drift during flight.


That is, if I switch on my DJI Mini 4 Pro indoors, then place it outdoor on my landing/home pad, I often have a relatively low location accuracy.
I.e. - looking at the map on my RC2 controller, and where the drone thinks it is, in can be off - sometimes is wrong by many meters.

Even if I let the drone sit there (not flying, motors not running) for some time - the position is not corrected. It remains completely off / wrong.

If however if power-cycle the drone on the pad... the GNSS position is almost always very good. It re-initializes with a lot of satellites, all is fine.


This is pretty reproducible for me.


It seems easy to understand also where this is probably coming from - call it an educated guess.

Obviously the drones state machine - being powered on - is first in an init state and setting something like an 'initial' location. This initial location can be somewhat inaccurate of not seeing a lot of satellites (or being moved?).


Then, while remaining powered on - the state machine is in a running state, in which the drone location is probably only allowed to be gradually adjusted (slew) with the new satellites becoming available for positioning. Which makes a lot of sense in flight - but not before flight.


It would be better if the drone - being stable, on the ground and not in flight - tries to improve its own location accuracy as fast as possible, in steps (not slowly slewing).

There is no drawback or problem being created making larger steps in this phase. So I am proposing the location to be opportunistically re-initiatlized / corrected before takeoff.


It would also make sense as takeoff is anyway prohibited while insufficient satellites are aquired.


This would also have the benefit of minimizing the need for time/location slewing dring active flight phase, which could lead to other strange behaviour - like drift of the drone.
To be honest, I also feel there my drone sometimes has a drift issue... which might be related to the above.

Cheers

Thank you for your recommendations. Please rest assured that we will register the information and provide feedback to the related departments for evaluation. In the future, we will optimize and improve the product or service based on user comments. For the drifting issue, please try the procedures below:
1. Ensure that the aircraft mode is normal, i.e., the GPS signal is strong and the aircraft is in non-ATTI mode.
2. Check whether the device drift or unsteady hovering is within the hovering accuracy range, which is shown in the Specifications Mini 4 Pro on the DJI official website.
3. Please try moving to a different location with a windless flight environment to test.
4. Check the propellers and the state of the motors. Check whether any motor rotates abnormally when the propellers are not mounted.
5. Ensure that there is no magnetic interference. It is recommended to place the aircraft on level ground for IMU calibration and compass calibration.
6. Check whether the control stick is being pushed. If the stick movement is offset, the remote controller should be calibrated.
Have a great day ahead.

It seems easy to understand also where this is probably coming from - call it an educated guess.
But it's an uninformed guess and it's just wrong.

It would be better if the drone - being stable, on the ground and not in  flight - tries to improve its own location accuracy as fast as  possible, in steps (not slowly slewing).
Just like any GPS device, your drone's GPS receiver will always update it's position as soon as it receives new location data.

So I am proposing the location to be opportunistically re-initiatlized / corrected before takeoff.
What you propose already happens.
There is no need to change anything.

I also feel there my drone sometimes has a drift issue... which might be related to the above.
There other possible explanations for a drone to drift.
But it has nothing at all to do with your mystical misunderstanding of how GPS works.

If you feel your drone is drifting, that's another issue and more information would be needed to tell if it is actually drifting and why that might be.

Well Labdoids - if what you are writing is true and the GNSS based location is always and in any case instantly updated (even if that means a jump/step, in operation) then what I see could not happen, right?
May I ask how you are so sure the implementation already is on a Mini 4 Pro, got access to the source code?

I mean, in case the implementation was already like that - the average positional accuracy shall be always the same, no matter where you power on the drone and what you do after power on - as long as you leave it steady in one place (e.g. the landing pad) for a defined time.

In turn, what I see would be a statistical anomaly or just a misconception. Because from a few dozen take-offs I have seen the power-up location (and me moving the drone to the pad after power-on) is indeed making a difference / has a negative impact on the accuracy.

Anyway - this is probably a good topic for a little experimental exercise in statistics. Maybe I find the time to do a good round of taking samples.


On a sidenote, the "implementation" here is to be seen on system level. So every component in the system (starting from the UI on the RC, the drones main controller timekeeping and geolocation aquisition, the GNSS modules firmware), they all need to behave correctly.
I.e. - what I describe could also be caused by e.g the GNSS module itself, or by other aspects of the architecture... that after having gone through power-up it behaves differently from initial power up.

That said - on system level - it is definitely much more difficult to determine your own geolocation when you are moving ... compared to when you are static.
So I am pretty sure that there must be two different behaviors implemented somehow in the system... thus my suspicion.

Funny idea to initialize the drone indoors, then bring it outside.

DJI_Mini_4_Pro_User_Manual-EN.pdf (djicdn.com)

Well - powering on indoors then taking it outside was just a way to reproduce something I was seeing.

And if the implementation for determining and updating the drones own geolocation was implemented the way I suspected, I believe it would be beneficial to change it.
Thats why I am raising it here.

That said - I am not yet sure what I see is really accurate... as mentioned earlier - need to do some testing.
But testing requires reproducibility ... and till today - the power on indoors then carry outside seems to be the best way to do it.

Pi31416 Posted at 4-21 22:47
Well - powering on indoors then taking it outside was just a way to reproduce something I was seeing.

And if the implementation for determining and updating the drones own geolocation was implemented the way I suspected, I believe it would be beneficial to change it.

And if the implementation for determining and updating the drones own geolocation was implemented the way I suspected, I believe it would be beneficial to change it.
Thats why I am raising it here.
But It isn't implemented the way you've imagined, so there's nothing at all to change.

That said - I am not yet sure what I see is really accurate... as mentioned earlier - need to do some testing.
I guess that taking the word of someone who actually knows how the drone's GPS works wouldn't be acceptable to you?

FYI .. I've been using GPS in my professional work since handheld GPS became affordable back in the mid-1990s and in recreational boating.
I've been flying DJI drones for 10 years and have analysed the recorded flight data from hundreds of flights since 2015.
The recorded data shows the GPS data for every 1/10th of a second and clearly shows that the position data updates 10 times per second (or possibly even more frequently).
The idea that position updating is delayed after startup is ridiculous and goes against everything I've seen in thousands of GPS startups.

Whatever you think you saw, was due to some external factors or poor observation.
GPS just doesn't work like that and there is no good reason that it would.

I feel you are oversimplifying what I am saying so let me briefly comment.

In fact, I do _not_ talk about GNSS updates for the (user/application level) getting delayed after startup or depending on startup condition.
Of couse, the system will continue to provide updated coordinates.

What I am talking about is a geolocation offset that can be created, and which seems to vary depending on the initialization condition.
With some initialization/power up conditions presumably creating an particularly unfavorable offset.
Offsets that are not or only very slowly compensated/changed.

Let me do some measurement to find out if this offset really is worse or better depending on where the power up happens.
Till now, this is really only a hand full of very subjective observations.

Also, in general I agree with what you say about geopositioning systems (not limited to GPS) in general. They do generally allow for "near continous" re-aquisition of the most accurate possible location.
In the context of this discussion, I find [1] to be a nice write up. It is outlining that the information used for geolocating (transmitted from an individual satellite) is coming in at a really low rate.
So depending on the actual GNSS system, it takes seconds till a single satellite as transmitted the data an implementation needs to determine a location.
Hence, sub 1s updates (e.g. 10updates per second) of a location is really only possible with a large number of locked satellites and/or fused sensor data (using e.g. the IMU for relative movement) and/or optical... or or...

Bottom line, receiving an updated GPS position in an application (e.g. flight log) at a rate of 10Hz tells you nothing about the implementation below and how that location is calculated.
There is the concept and system as such (satellites and the information they send) - but there is also real world and implementations (GNSS receiver IC, Firmware of the IC/Module, Application Level Software etc...).

I'll go ahead with some testing to find out if real world implementation is getting in the way here.


[1]
https://berthub.eu/articles/posts/improved-galileo-fix-time/

Pi31416 Posted at 4-22 01:15
I feel you are oversimplifying what I am saying so let me briefly comment.

In fact, I do _not_ talk about GNSS updates for the (user/application level) getting delayed after startup or depending on startup condition.

Re Read carefully the article in the link you just posted.
If you don't understand something, don't hesitate to ask.

As an update:

I am trying to set up some testing to help verify/falsify my subjective (and potentially inaccurate) experience and statements.
As manual shots and position capture does not yield enough data, my idea was to use hyperlapse shots as a quick and dirty way to automate things.

The test concept is to place the done on the ground, at a known geolocation, always the same place and only vary the init conditions.
The expectation would be - if the geolocations 1) absolute offset and 2) variance (relative) are both comparable, between the two different init conditions (init with NO GNSS vs. init WITH GNSS), my statement and perception is falsified.
If however there is more average offset of variance in the NO GNSS reception init case, it would be worth further investigating.

Kindly let me know your thoughts on this.


I have created a small powershell to extract the EXIF position data from multiple images and export them into one single table.
It is working well and I will probably have some first results today to post here.

That said - there is unfortunately another issue (ECO mode kicking in during hyperlapse) that is preventing me from generating really large data sets.
Anyone here in the forum can give me a pointer to an alternative route to capture geolocation data from the drone, every few seconds.


Can I directly and periodically receive the drones geoposition while on the ground - possibly also preventing ECO mode?

In case anyone can make use of the aforementioned PowerShell or is interested, I wanted to post it here.

1. #############################################################################
   
2. # Extract Exif-geolocation from sets of images (folders) and export to CSV
   
3. #############################################################################
   
4. 
   
5. #
   
6. # user defined parameters
   
7. #  1) the directory to extract and 2) the filetype
   
8. #
   
9. param(
   
10.     [Parameter()]
    
11.     [string]$filesDir = ".",
    
12.     [Parameter()]
    
13.     [string]$fileExt = "jpg"
    
14. )
    
15. 
    
16. ...
    
17. # !! incomplete - upload to DJI forum not working !!
    
18. # download from github instead (see link below)
    

Copy the code

Unfortunately, the code does not go through/cannot be posted as a whole.
As soon as I add the complete powershell code, I receive an error:
'Web Server updating. This site is currently unavailable. Sorry for the inconvenience. We'll fix it soon.'
Also uploading the script as an attachment is not possible as poweshell seems to be prohibited.

So I uploaded on a github gist instead:
https://gist.github.com/poeggi/364edb0ad9621db208c879fde688d2be
Cheers

Pi31416 Posted at 4-24 22:45
As an update:

I am trying to set up some testing to help verify/falsify my subjective (and potentially inaccurate) experience and statements.

ECO mode?
Not sure what that is .. I've never encountered that before.

The recorded flight data has GPS location data for each 1/10th of a second without taking photos and finding location data in the image files.

Flight data however cannot be generated/recorded before takeoff, can it?

My intention is to have the best possible static setup, which is why I wanted to use a fixed position on the ground.
This will prevent mixing actual GNSS module reported location changes with real location changers from the drone due to movement.

Pi31416 Posted at 4-25 02:32
Flight data however cannot be generated/recorded before takeoff, can it?

My intention is to have the best possible static setup, which is why I wanted to use a fixed position on the ground.

The .txt file shows data from motor startup.
The .dat file probably shows data from power on.

I can't understand what it is that you are hoping to find or why you think there's something to look into.
I've never noticed or heard of anyone reporting a problem with the way the drone's GPS works.

As I did not find a way to digest the DAT files (that as @Labroides mentioned,  would contain pre-takeoff coordinates) from my mini 4 pro, I instead finalized testing with the hyperlapse approach outlined earlier.

I have 6 testcycles conducted, out of which in 3 I initialitzed the drone indoors (with NO GNSS reception) and 3 where the init was done outdoors, on the landing pad.
Pdf reports attached for all 6 in case someone is interested in the details and some GNSS statistics of the mini 4 pro.


Long story short - what I choose as measures to verify/falsify my perceived correlation between init scenario and geoposition accuracy was 1) geoposition delta, 2) variance and 3) drift behaviour after placing the drone on the landing pad.

Outcome is: none of those measurements seem to clearly indicate a correlation.

While the worst case scenario [1] was one in which I did the init indoors (noGNSS), there is also one pretty bad where the init happened outdoors (with GNSS available during init).
So I think the data shows there generally are some pretty bad cases in positional accuracy, but caused by other factors then what I originally assumed, not clearly correlated to power up or init logic / FSM.

Would be great to learn from others if this is a normal range?



Anyway, I think this thread should be closed as its subject line is not accurate. There seems to be no init/FMS problem.

Cheers


[1]
no-GNSS-init_3:
almost 10m worst case offset (to real geoposition)
almost 5m average offset
approx 3m variance in position
up to 3.5m position drift in 15 seconds

Pi31416 Posted at 4-24 23:44
In case anyone can make use of the aforementioned PowerShell or is interested, I wanted to post it here.Unfortunately, the code does not go through/cannot be posted as a whole.
As soon as I add the complete powershell code, I receive an error:
'Web Server updating. This site is currently unavailable. Sorry for the inconvenience. We'll fix it soon.'

In case someone can make good use if it, I also attach the spreadsheet I created for digesting and visualizing the output of the script I posted earlier.

It takes a set of geolocations and does some statistics on them.


I had to zip the file before being able to attach it here, inside is only a single spreadsheet (created with LibreOffice).

Cheers

Pi31416 Posted at 4-25 23:31
In case someone can make good use if it, I also attach the spreadsheet I created for digesting and visualizing the output of the script I posted earlier.

It takes a set of geolocations and does some statistics on them.

Good job! A negative result is also a result.