Continuing R&D on the use of Emlid GPS hardware for construction. Got the Emlid Reach M+ mounted and ready to test. I will run it in a traditional Base and Rover set up with the Reach RS+. If it works the package (excluding the P4P) will be $1200.
The one unknown at this point is creating a repeatable way to ensure that the GPS transponder is precisely positioned… And yes I broke out a plumb-bob…
How well does the drone balance? Do you need to add a counter weight on the other skid?
We made the first steps with the kit a few days ago. First, we tested how exactly we could determine a known geodesic point on the ground. We left the drone with the kit for 45 minutes at this point (open, flat terrain without obstacles). Setting: Kinematic, Fix Hold). The PPK showed a difference to to the well-known coordinates of 25cm X axis, 1.2m Y axis and 4m Z axis at 16km baseline to CORS Station OAX2. After 30 seconds Fix-Solution which never broke again (99.9% fix).
After that we also hit the same point for 45 min with a Reach RS and did the same PPK. This gave a deviation of 3cm X axis, 4cm Y axis and 5cm Z axis. We think that this huge divergence between Phantom Kit and Emlid Reach RS is due to the inclination of the Tallisman antenna on the Phantom. After that we wanted to make the first flight, but the battery was empty. 90 minutes of battery life is very little for field trials. So our first recommendation: Take two or three batteries with you. However, we still flew a mission without switching on the Emlid M + to observe the stability of the Phantom. Very calm and stable flight behavior at first glance. This week we will do a test flight with Photoshooting.
But we are not quite clear how we can integrate the time delay into the PPK (for the moving drone) with RTK-LIB
All in all, we find this a good installation and are confident to get fixed the above mentioned deviation.
Just trying to close this thread out. Linking some information back in that came up in another thread. Processing test missions and creating all my analysis documentation now so I should have a decent outline of the project soon!
Other threads assisting this project.
Everything is coming together. We are starting to get consistently good results and have the workflow down. Just bought another M+ kit to put on the Yuneec H520!
Measurements of distance, area and volume within the map should be accurate to within 1-3 times the ground sampling distance. Map measurements are typically within 1-3% of ground-based measurements.
|Ground Sampling Distance (GSD)||0.74 in/pixel|
|Approx Horizontal Relative Accuracy Range||0.14 in|
|Approx Vertical Relative Accuracy Range||0.14 in|
|Optimized Camera Location Error||X 0.04 in Y 0.14 in Z 0.14 in|
|Optimized Camera Location XYZ RMSE||0.2 cm/pixel|
Ground Control Points
Global accuracy, when using ground control points (GCPs), is directly correlated to the accuracy of the positioning equipment used. When processing a map without checkpoints, the accuracy is inferred from residual error in the GCPs after calibration, which is only an approximation of accuracy. To verify the accuracy of your map, use checkpoints. ASPRS guidelines require use of checkpoints in order for a licensed surveyor to specify that a map is survey-grade.
|Label||X Error (Inches)||Y Error (Inches)||Z Error (Inches)|
What are you using for time offset?
Are you getting all of the events to match the photos taken?
The time offset for my setup has been between 12-15ms, but this is taken care of in Geosetter.
Thanks for getting back to me. I thought the offset to use was 30 ms. I might need to check the results I get using 15 ms.
I base mine off the PPK results as synchronized by Geosetter so we may not have the same process. Also, it depends on where you mount the antenna. Looking at the exif data of my images the average tilt angle on the P4P has been about 15deg. When I diagram the forward offset of the antenna at that pitch at an average of 15mph 22(ft/s) it only equates to 0.02’ of delay which is about 15ms. I think someone missed that factor and calculated at 0deg pitch when they came up with 30ms as just the LED lag.
I was using the Tuffwing “recommended” settings. In geosetter, do you synchronize with one of the track points? I am also getting more events than images almost everytime.
Yes, I create the GPX using the events.pos file and it has been good matching the last several flights. I have never had extra events, but have had missing events. I am then forced to go back to the full track and find the same time offset as points that we’re in the events file. It definitely doesn’t “feel” right in my opinion, but it has worked the few times I have had to do it. At 14hz it does take a while to find those specific events.
Hello Michael, I have accompanied him on several topics and observed his work.
But I still have two doubts:
Do you apply any correction due to the camera’s rotation angles?
How did you measure the latency between the led and the trigger?
Are you talking about pitch of the gimbal? Because yaw and roll are compensated for in processing. The only problem you could really have that would still probably be corrected in processing is if the gimbal yaw was out of alignment with the centerline of the drone.
That is the spec on the sensor. The adjustment for any dimensional variances can be done in RTKPOST, but quite honestly the deltas are so little after processing that you measure close and that’s about as good as it is going to get anyway. In our workflow we always use GCP’s so none of this matters.