Emlid

Community Forum

UAV Consulting


(Michael Lambert) #63

As far as I know the system lag is a constant. The variable is the airspeed. The figures above were based on 15mph which is a pretty common mapping speed.


(Dave Pitman) #64

Hi Tim,

With EZsurv being so good at grabbing the CORS logs and applying corrections, couldn’t you just skip the Base completely and just have EZsurv apply correction to all the Reach events themselves?

I realize you are also using the Base/Rover to set GCP and Check points. I’m just thinking about the image events themselves.


(Christian Grüner) #65

You will likely have a much longer baseline by only using CORS. Also, there might be a relative difference between the drone points and the GCP’s, if the difference base corrections are used for either.


(Timmyd) #66

Dave, cors stations vary greatly in distance so a sweeping statement that any particular software could simply use the cors logs for PPK flights would be less than accurate, at least imo. But I am always willing to learn :slight_smile:


(Michael Lambert) #67

I think that’s something else you will run across in construction in particular is the ability to relate a drone survey that is not using gcps back to the local grid. If you’re running off of a cors/vrs all the transformations can be problematic. Having the base station on a known point is definitely the best way to go.


(Dave Pitman) #68

In Tim’s case, I don’t think he was on a surveyed, or Known Point? He collected a point, had EZsurv post process that point with a nearby CORS station. Then he used that point to apply corections to the event locations. So, in essence, they are being corrected to the CORS station log, albeit by way of the corrected Base point. Isn’t that correct? In that case, why not just correct the event points directly. It’s not like they are themselves not close enough to the CORS station.

If you already have a known point to work with then that may be different. I could have it all wrong too.

Edit: I would add, that if the Drone was a rover, via RTK to the Base, then that makes perfect sense.
But I’m not quite understanding that if you correct the base with CORS, then use that to correct the event points (via ppk and not rtk) what the difference is in just correcting the events directly with the CORS?

Sorry if this is obvious.


(Christian Grüner) #69

Let’s say you have a base line of 20 km from the CORS to your worksite

Your base will be easier to process, as it is static. With that baseline, the whole log should have a fixed solution.
The rover is different story. Depending on wind (and thus resulting suboptimal attitude), potential obstructions etc the reception of the rover will likely not be as good as with the base. On top of that, it can’t be processed as a static solution.
On short baselines the above doesn’t matter much, but on longer base lines, it does matter!

Now, if EZsurv could do VRS’, then it would likely be another story!


(Michael Lambert) #70

When you’re trying to get to centimeter accuracies the difference in base corrections from 1 mile vs 10 mi does make a difference and as I said before is much easier to transform and localize. If you are a land surveyor that deals with data that was derived from these stations then it makes sense.


(Dave Pitman) #71

Christian’s explanation that the corrected base is superior because of the greater collection time makes sense.

What if the CORS network has a VRS option for corrections, any difference?


(Christian Grüner) #72

Not only because of longer collection time, but also because:

  • it is static
  • it is usually placed in a spot with good reception
  • it usually provides much shorter baseline than a CORS network, which provide greater accuracy and more fixed solutions to the rover

(Dave Pitman) #73

Gotcha!

Although the reach in the air should have the best reception, but it’s in motion.

Thanks guys, good stuff !


(Christian Grüner) #74

Yep, obstructions should be at a minimum, but the attitude of the drone could cause the antenna to see below the horizon, and thus multipathing could give some funky behavior.


(Dave Pitman) #75

Tim, it would be interesting if when you had time, you used EZsurv to correct one of the event points directly with CORS and we could compare that to the results in your workflow.


(Michael Lambert) #76

Had a goof this morning and my base didn’t log on my first job. Do I need to re-setup and fly or can I use my base info from my second project? 45 minutes later and 9 miles away.

*Or, what if I use the observation from our DOT?


(Michael Lambert) #77

I found the Rinex files for two stations during the flight time frame, but no fix on the rover. :frowning: The VRS has a good fix. Do I need to put in it’s coordinates or something?


#78

Michael, if the rinex comes from a vrs network, you might be able to select Read Rinex header. That should have the location of that particular station (to be sure, tryto find a document with published location for the base stations you used and compare to the rinex file header (open in Notepad or something similar))


(Michael Lambert) #79

I found out that it is a CORS and have the latest published coordinates. I tried entering them into positions and no difference on the M+ events. I will try the comparison with the header coordinates. Thanks!


(Michael Lambert) #80

Update. Verified that 5hz is not fast enough for the drone. Going back to GPS only and 14hz. Of course a lot of you guys probably already knew that. :slight_smile:


(Michael Lambert) #81

This is going to be a fun one. Large subdivision with multi battery flight. My first attempt at doing PPK with multi batteries. Three launches so far.


(Michael Lambert) #82

Is it going to be best to process the pictures and chunks? If I can tell where each session was… Or is it typically pretty good at picking up the offset of the time stamps?