@@joedouglas6923 hmm, since terra wants LAT/LON and ellipsoid i assume you are using just NAD83 and not NAD83 NAD83(CSRS) / UTM zone 17N since that wants Northing/Easting? I'm really struggling with DJI being so stuck in WGS84 ellipsoid and the work flow when i need gcps and output in NAD83(CSRS) / UTM zone 17N + CGVD2013(CGG2013) height
That would be very situation dependent. For most topography scans, using terrain follow and a higher percentage of side overlap will give you a high degree of accuracy while cutting down on flight and processing time. Although, if you have a specific use case where you may need more information from more angles, a crosshatch flight plan could make sense.
Patrick. Fantastic video! This is Cody P. (just bought an RS3 through you guys). Any qualms with using our local NTRIP connection directly via the DJI M300 RC Plus? We use a command center when flying and always have high speed Starlink internet connected to the RC Plus at all times. If we do so, we wouldn't have to edit any base station coordinates as there is no RTK base station setup when flying? Correct me if I am wrong.
You can definitely run it that way, however your position accuracy from the INS will be less accurate only relying on RTK. Yaw accuracy goes from .2º in RTK to .05º using PPK, likewise pitch/roll goes from .05º RTK to .025º PPK. You could fly using your NTRIP and have your RS3 collecting a static log nearby and use the same method as the video to improve accuracy during processing while still flying using your NTRIP provider if that makes sense to your workflow.
at 14:00 minute when you are entering base station altitude, do you enter it in FT or meters? I follow your routine and when I pull up DJI Terra Quality Report 1. Cannot get reconstructed altitude in "point cloud check point error" 2. I entered base altitude (monument) at 480.632 m but then in report it is showing number itself converted into feet yet shown as "m" meters. Any insight appreciated
I entered it in meters, the output in the quality report is in feet based on the coordinate system settings I chose. I believe it is just a bug in the quality report that it always attaches m as its unit of measure. I also don't have that column under "point cloud check point error", since that is an overall check of the point cloud error vs check shots, there isn't a single altitude the point cloud is reconstructed to. If that column isn't populating in the check point list the checks are likely drastically different from the point cloud and Terra doesn't consider the checks comparable to any points in the point cloud. If that isn't the case, you may want to check your software and firmware versions to make sure they're the latest versions.
You say that you added the height of the rod that the receiver was on in the base settings, but you only adjusted .033m? So were you basically taking away the antennae offset? We keep running into this issue and I want to be able to explain this clearly to my boss when I show my findings. It seems all of our checkpoints are about the total height of our setup off. This is because when you get the OPUS point it is giving you the exact point on the ground, however for accurate lidar data you need the location in the air where the Emlid receiver actually was is this correct? Thank you in advance, your videos have been a tremendous help in figuring all of this out.
We still aren't sure where the original base coordinates come from when you first open those settings in Terra. We tried changing the Rinex header of the base file, but that didn't change the point that was pulled in, and the original coordinate doesn't line up with anything we could see in our log. So the .033m you mentioned wasn't based on the point that was populated that was just the difference between the auto population and OPUS point with the addition of our pole and antenna offset. You're correct that we want the point in the air.
If your receiver can output corrections in RTCM3 and is capable of sending them through the network, then yes you could use Emlid Caster to send corrections to your drone that way.
What is the purpose of flying the drone with RTK if you're going to PPK it in the end? Have you send better results from post-processing RTK data vs post-processing GNSS only data?
The L2 won't produce all of the necessary files for Terra unless it flies in RTK. Since we have a base running anyway using it's logs to improve our accuracy at the cost of a couple additional minutes seems worth it to us.
@e38surveysolutions59 how do you ppk with L2 with no RTK active? I thought ppk was advantageous for Connection denied areas? I am trying to do my first ppk. My base is a CORS that I am pulling corrections from. But I am having trouble finding the right files from the drone.
As far as we're aware the only way to process L2 data without flying in RTK is to use a D-RTK 2 base connected to a computer for the duration of the flight. If you had a D-RTK 2 on-site I would suggest using that to fly in RTK anyway. As mentioned above we're running PPK to improve our accuracy. In use with the L2 that is the only advantage, tightening the pitch(.05° > .025º) and yaw(.2º > .05º) of the INS to produce more accurate points. If you can connect to the CORS base in the field you could use that to fly in RTK, or purchase a base station like a D-RTK 2 or Emlid Reach ( e38surveysolutions.com/collections/emlid-reach-rx-rs2/products/emlid-reach-rs2-base-station-kit ) if you can't connect to the internet for your mission.
@abgnadk that's news to us, we've based this off of information we received from DJI and from what we've seen in our trials. Looks like we have some more testing to do...
Big fan of your work!😊
Great video. When you enter the base known point into Terra is that in WGS 84 ellipsoid? Or in the datum you used which was Nad83 I believe.
NAD83
@@joedouglas6923 hmm, since terra wants LAT/LON and ellipsoid i assume you are using just NAD83 and not NAD83 NAD83(CSRS) / UTM zone 17N since that wants Northing/Easting? I'm really struggling with DJI being so stuck in WGS84 ellipsoid and the work flow when i need gcps and output in NAD83(CSRS) / UTM zone 17N + CGVD2013(CGG2013) height
Great video. Just picked up our L2. Is it best with those big elevation changes to ever crosshatch flight plans?
That would be very situation dependent. For most topography scans, using terrain follow and a higher percentage of side overlap will give you a high degree of accuracy while cutting down on flight and processing time. Although, if you have a specific use case where you may need more information from more angles, a crosshatch flight plan could make sense.
Patrick. Fantastic video! This is Cody P. (just bought an RS3 through you guys). Any qualms with using our local NTRIP connection directly via the DJI M300 RC Plus? We use a command center when flying and always have high speed Starlink internet connected to the RC Plus at all times. If we do so, we wouldn't have to edit any base station coordinates as there is no RTK base station setup when flying? Correct me if I am wrong.
You can definitely run it that way, however your position accuracy from the INS will be less accurate only relying on RTK. Yaw accuracy goes from .2º in RTK to .05º using PPK, likewise pitch/roll goes from .05º RTK to .025º PPK. You could fly using your NTRIP and have your RS3 collecting a static log nearby and use the same method as the video to improve accuracy during processing while still flying using your NTRIP provider if that makes sense to your workflow.
at 14:00 minute when you are entering base station altitude, do you enter it in FT or meters? I follow your routine and when I pull up DJI Terra Quality Report 1. Cannot get reconstructed altitude in "point cloud check point error" 2. I entered base altitude (monument) at 480.632 m but then in report it is showing number itself converted into feet yet shown as "m" meters. Any insight appreciated
I entered it in meters, the output in the quality report is in feet based on the coordinate system settings I chose. I believe it is just a bug in the quality report that it always attaches m as its unit of measure. I also don't have that column under "point cloud check point error", since that is an overall check of the point cloud error vs check shots, there isn't a single altitude the point cloud is reconstructed to. If that column isn't populating in the check point list the checks are likely drastically different from the point cloud and Terra doesn't consider the checks comparable to any points in the point cloud. If that isn't the case, you may want to check your software and firmware versions to make sure they're the latest versions.
This helped tremendously thank you
Great video guys!
You say that you added the height of the rod that the receiver was on in the base settings, but you only adjusted .033m? So were you basically taking away the antennae offset? We keep running into this issue and I want to be able to explain this clearly to my boss when I show my findings. It seems all of our checkpoints are about the total height of our setup off. This is because when you get the OPUS point it is giving you the exact point on the ground, however for accurate lidar data you need the location in the air where the Emlid receiver actually was is this correct? Thank you in advance, your videos have been a tremendous help in figuring all of this out.
We still aren't sure where the original base coordinates come from when you first open those settings in Terra. We tried changing the Rinex header of the base file, but that didn't change the point that was pulled in, and the original coordinate doesn't line up with anything we could see in our log. So the .033m you mentioned wasn't based on the point that was populated that was just the difference between the auto population and OPUS point with the addition of our pole and antenna offset. You're correct that we want the point in the air.
Question bout the DJI terra setting where you input the Base Station Center Point settings. You're adding the rod height not the Antenna Height, right
I added the rod height + the .134m antenna offset, sorry for the misspeak
I also add my payloads to the drone while in the box. Will the emlid caster allow other GPS receivers be used as a base for the drone?
If your receiver can output corrections in RTCM3 and is capable of sending them through the network, then yes you could use Emlid Caster to send corrections to your drone that way.
What is the purpose of flying the drone with RTK if you're going to PPK it in the end? Have you send better results from post-processing RTK data vs post-processing GNSS only data?
The L2 won't produce all of the necessary files for Terra unless it flies in RTK. Since we have a base running anyway using it's logs to improve our accuracy at the cost of a couple additional minutes seems worth it to us.
@e38surveysolutions59 how do you ppk with L2 with no RTK active? I thought ppk was advantageous for Connection denied areas? I am trying to do my first ppk. My base is a CORS that I am pulling corrections from. But I am having trouble finding the right files from the drone.
As far as we're aware the only way to process L2 data without flying in RTK is to use a D-RTK 2 base connected to a computer for the duration of the flight. If you had a D-RTK 2 on-site I would suggest using that to fly in RTK anyway. As mentioned above we're running PPK to improve our accuracy. In use with the L2 that is the only advantage, tightening the pitch(.05° > .025º) and yaw(.2º > .05º) of the INS to produce more accurate points. If you can connect to the CORS base in the field you could use that to fly in RTK, or purchase a base station like a D-RTK 2 or Emlid Reach ( e38surveysolutions.com/collections/emlid-reach-rx-rs2/products/emlid-reach-rs2-base-station-kit ) if you can't connect to the internet for your mission.
@@e38surveysolutions59hmmm weird, i already fly about 10 ppk mission with rtk mode disable… never failed to process… im using CHC I93 as base station…
@abgnadk that's news to us, we've based this off of information we received from DJI and from what we've seen in our trials. Looks like we have some more testing to do...