airborne Velodyne HDL 32 (with bad GPS/IMU trajectory)

[Martin Isenburg]

Hello,

an interesting crowd-sourced technical problem solving discussion has started on one of the social media pages of LAStools:

https://www.facebook.com/pg/LAStools/photos/?tab=album&album_id=2263616743700757  

Have you seen these kind of wobbling flight lines shown in the 32 images? The composite seems to average all somewhat into place but those averages are far far less precise than I would like them to be. You see see the TIN resulting from triangulating the returns of a 15 second LiDAR drone flight. The first TIN is all returns from all beams of the 32 beam Velodyne LiDAR. The following TINs only use the returns from a single beam or channel of the system. The drone flies 70 meter above ground and carries a Snoopy Series A HD system by LiDARUSA with an integrated Velodyne HDL 32 laser scanner. The building in the center is regular shaped rectangular building (i.e. a warehouse), on its left is a small lodge and an empty field, and on its right is a concrete parking lot and a fresh tar road. Clearly the GPS / IMU trajectory was either not applied correctly, or has too low accuracy (there was no base station so that PPP was used to correct the trajectory), or something else. I am usually not involved in that part of a LiDAR processing workflow so ... what do the experts say?

Regards,

Martin @rapidlasso

[Konstantin Lisitsyn]

Hello Martin,

Pretty sure it's the inaccurate time sync between GPS/IMU trajectory and laser ranges.

It'd be worth re-processing this cloud (it seems to be small enough for iterations to be not too long and the exercise to be practical) with different time offsets between trajectory and raw lidar ranges, like +-0.01, +-0.05, +-0.1sec and arrive to accurate enough value with "bisection" iterative method.

--

Konstantin

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

[Martin Isenburg]

Hello,

I myself do not actually have access to software (such as ScanLook which did our first export that is shown here) that can turn the trajectories and the Velodyne *.pcap files into LAZ files as I was experimenting with a local company here in Costa Rica on that and the computer with the dongle-protected software is 4 car hours from the beach and surf community where rapidlasso has set up their semiannual surf, code and scan camp ... (-:

But as this data is ultimately meant to become open data I couldshare the raw trajectories and the Velodyne *.pcap files with anyone who is willing to volunteer their time to process it for me. It's a contest now: Who got the skills and the software to turn the raw sensor recordings without local base station into a coherent set of LAZ flight lines with good relative accuracy. (-:

The nearest base station for getting Rinex files from Costa Rica's National Geographic Institute network of continuous operation GNSS reference stations is 30 km from the site where we flew. What software do you use to process the output of your airborne Velodyne LiDAR system?

Regards,

Martin @rapidlasso 

[James Young]

Martin,

The repeatability of the velodyne is terrible and with my experience of flying them at Precisionhawk has resulted in us abandoning that laser completely. I saw an average noise of 8 to 20 centimeters between the laser returns. This being from the multiple lasers.! I had to develop an algorithm to best estimate ground based on the noise.! It got me with accuracies of roughly 8cm. 

We had our own Lancaster LiDAR which used the velodyne and we never flew it above 40m AGL and still saw what was stated above.we discontinued that system about a year ago because we had so many problem with it and our clients required engineering grade products so now I only use riegl for service and my geodetics for mapping grade but I have seen some exceptional results for the geodetic system but average between 4 and8 cm accuracy with it compared to 1 to 3 cm with the riegl ! 

We currently sell geodetics LiDARS which also use the velodyne and recommend flying those at no higher then 40 meters as well. The results are much better then what I see in your pictures. We have several clients that are very successful with the geodetics systems. I believe this is because of their (geodetics) POS system. It is by far the best velodyne drone LiDAR in the market but it requires strict adherence to their field collection regiment.! 

I would recommend developing an algorithm that statically best guesses the ground and comparing it to the ground and transforming to control to resolve the issue. It took me about a month to develop the math to resolve this issue when it occurred and it was enough to change my course on sensors as it related to our Lancaster sensor.!

Also both riegl and geodetics have kick ass A6000 camera sensors and processing tool to colorize points and make orthos. 

Didn’t mean to make this sound like a sales pitch. So sorry if I did.!

Jamie Young

--

Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

<super_new_china_channel_15.jpg>

<super_new_china_channel_31.jpg>

<super_new_china_channel_all.jpg>

[Martin Isenburg]

Hello James,

interesting assessment. However. looking at the LiDAR returns that are produced by a single rotation of the Velodyne HDL 32 scanner head operating at 20 rotations per second (aka 50 milliseconds of data) gives really clean looking surfaces even flying at 70 meters. So the alignment between the 32 scanners seems to be overall okay. But as soon as I start combining multiple of these 50 millisecond  "clean freeze frames" the issue is showing. That's why I don't think the Velodyne HDL 32 scanner itself is the issue but the math that puts all of them into one point cloud. I could imaging that a SLAM approach that uses our current trajectory only as a suggested starting point for aligning the scans could be promising. What I had seen the Hovermap team at CSIRO in Brisbane do just using the Velodyne Puck makes me hopeful that a SLAM algorithm can fix these miss-alignment issues. But I agree with you that we should not have flown at 70 meters and that we will do a 50 meter flight next time. I am a complete newbie to this kind of surveying and my help during the scanning activities was mainly that of carrying boxes. Traditionally my expertise only start once I get the LAZ files and now that I tried to branch out from there I know again what it feels like to be a beginner ... (-:

Below two individual consecutive "clean freeze frames" of 50 milliseconds of data each corresponding to one scanner head rotation. They all look this clean. But when I put 2 together aka 100 milliseconds of data the issue starts showing.  And when I put 4 together aka 200 milliseconds of data it gets worse. And when I put 10 together aka 0.5 seconds of data it is really no longer pretty.   

Regards,

Martin

[Mark Levitski]

I will begin by stating that I am hardware neutral. I have processed data from both the Velodyne 32 with a good STIM IMU  and the Riegl mini VUX with an even higher end FOG IMU. Both for “survey grade” uses. I can say that although the Riegl produces better results, the Velodyne was accurate enough for the same purposes with some extra but minimal processing. Our supplier did some extra work to calibrate the individual lasers, so that might explain the different opinion I have. Our current Riegl system supplier has software that makes it easier to calibrate the multiple lasers of the Velodynes.

 

UAV lidar is not as simple as attaching a lidar to a drone and looking at the resultant point cloud. The industry is following the same evolution as did (is) UAV photogrammetry and SFM software. I think at one time everyone thought they could buy a cheap drone and a camera and pull it out of the trunk of their car to fly for survey data. Eventually the wake up call came.

 

Good GNSS, IMU, and flight parameters are needed. Some of that costs money, more than most are willing to invest. Then there’s the know-how to post process and the software needed. More investment, but worthwhile. The survey people are by nature accuracy freaks. And they have formed much of the world with their work. We need to give them what they need.

 

Unless for research, educational uses, or just playing around with the technology for fun, my advice is to stay with a supplier who has put his business reputation on assembling a turn-key package that is already proven to yield a deliverable result that will not put your own business reputation at risk. Many of our potential clients have been through and experience with someone who gave them bad data. Their attitude is difficult to overcome to sell them the real thing.

 

Too much coffee, I digress. Main point here is no differential corrections, question re: IMU, and individual laser calibrations for my two cents.

 

Mark

 

 

 

Sent from Mail for Windows 10

[Sam Hackett]

Hi Martin,

If your flight was logging GPS for longer than 10min I would suggest the pre-processing include the CORS GNSS 30km away if it has 1sec or 5sec data available.  The 30km distance will reduce the relative accuracy of the baseline, however the precision (fluctuation during the mission) should be completely appropriate for this type of task.  I know of success of reasonably long logging missions (MLS) using a backup CORS 100km distant.

Hi Mark,

I use a Velodyne 64 on an MLS for some of our work.  Not my tool of choice, and I use other top of the range MLS units as projects require.  For the Velodyne 64 I have developed a workflow to calibrate the lasers for any capture project so that I have a scan surface along a road from many lasers that has a noise similar to the individual laser precision - i.e. about 0.04m.  With some additional workflow we can satisfy survey grade accuracy requirements, meaning we can survey a typical road to survey spec using the GIS grade mapper.   I'd be interested to connect with your contact who performs the similar correction to swap some notes.

Regards

Sam

[Mark Levitski]

Having been advised by different lidar hardware suppliers as well as surveyors, 30KM is too long of a baseline to rely on for CORS corrections, that is if it is the sole source. We go no more than 5-6 miles.

For fluctuation corrections (they are extremely minor with the system we fly with) we use Terramatch as a routine part of the workflow.

 

Sam, I’m afraid my source is commercial and would likely not share their proprietary work. I know that LidarUSA, the supplier of the previous system I worked with, somehow calibrated the lasers in a more manual and tedious way. But they are also commercial and I suspect guarded about sharing things. They are great people and I wouldn’t hesitate to contact them. They have a lot of experience with Velodyne for surveying. I am a bit out of my league with the research and educational world of lidar. I am a true turn-key end user that relies mostly on GUIs and only strives to learn what I need to produce the best data for my clients. I am in awe of what it takes behind the scenes for all this to work. God bless the developers and code writers! Swapping is uncommon in this world. LOL

 

Best……………Mark

 

Sent from Mail for Windows 10

 

[Martin Isenburg]

Hello,

an update. The company making this laser scanning system (the "Snoopy Series A HD") has taken a closer look at this and has produced a much better result using an older version of the software that I personally do not have access to. I am not sure if something else needed to be done different, to get a better result. Either way, after a lot of experimentation and including the data from the same system from other users of the very Snoopy system, my current working hypothesis is that the at the export software ScanLookPC has a bug that was introduced after sometime after version 1.0.171 and is definitely present in versions 1.0.182 through 1.0.192 that either causes only some or in fact all of these issues.

Do you you have a  "Snoopy Series A HD" system? Do maybe you know anyone who operates one? Please email me or have them email me at sno...@rapidlasso.com. If your ScanLoopPC version is 1.0.171 or older then you should be good and I strongly suggest that you do not upgrade until this is resolved.

Regards,

Martin

[Shavers, Ethan]

Hi Martin,

Have you looked at Veloview, the open source Velodyne software? It is my understanding that it can be used for exporting corrected Las files.

Thanks,

Ethan

Ethan Shavers

Center of Excellence for Geospatial Information Science

National Geospatial Technical Operations Center

US Geological Survey   

573-308-3688 (office)

[Martin Isenburg]

Hello,

actually it seems the problem was solved already six days ago by the team at LiDARUSA but am still waiting for them to tell me how they fixed it, The comment by the team from LiDARUSA that came with the attached image (that I find absolutely awesome!!!) only states "Here is a screenshot of your data correctly processed using an older version of ScanLookPC and no base station (was not included)." ... stay tuned!

https://www.facebook.com/pg/LAStools/photos/?tab=album&album_id=2263616743700757  

Regards,

Martin

PS: Btw ... if you use MiniVUX system by LiDARUSA and export with ScanLook to LAZ there is a good chance that you cannot distinguish between shots resulting in single, double, triple, and quadruple returns because of an error in the way the "number of returns" is exported. Contact me if you have such exports for how to fix them.

[Martin Isenburg]

Hello,

if you own either a "Snoopy Series A" (Velodyne-based) or a "Snoopy Series B" (RIEGL-based) system you should probably pay attention to this discussion here. Contact me with sample data if you want to see if your exports have the same issue.

The export bug for the miniVUX and VUX systems that I have seen is a little worse than I had initially anticipated. It does not, however, affect the geometry so if you are not using the return numbers for anything this may not concern you. But the LAS files are not entirely speficiation conform.

After attempting to fix an error in the way the "number of returns" is exported I noticed that the number of single returns (returns where both the return number and the number of returns have value 1) seemed higher than usual and lasreturn reported tons of "duplicate" first returns. Turns out that in the miniVUX and/or VUX exports that I have seen recent versions of ScanLookPC export both the first and the second return of a multi-return shot are given the return number 1. My current working hypothesis is that this bug was introduced when LiDARUSA fixed the bug where return number 0 was given to the first return. Below a more detailed analysis.

I thought I had fixed the sample "Snoopy Series B" miniVUX LiDAR data set that was exported by ScanLookPC and that is visualized in this tweet: 

https://twitter.com/LAStools/status/1117832210885771267  

Yet the number of single returns in the tree canopy looks awfully dominant, no? I paid too little attention to that but fortunately lasreturn is more rigorous on this issue. Below the sequence of commands I used to debug. You may do so on a small sample of your own exports.

There was a time when LiDARUSA started the return numbering in the LAS files at 0. That was wrong. What they did as a fix - so I assume - was to always write a 1 instead of a 0. That is correct for all single returns. But they must have applied the same rule to all double, and trips, and quadruple, and ... returns. So they mapped the real first return which used to be numbered 0 to the number 1 which was already used by the second return without changing the number of the second return to 2. In summary. All shots that return more than 1 return, hence those that return 2, 3, 4, 5, 6 or 7 returns use the return number 1 for both the first and the second return.

Below the sequence of command lines that validates this.

 

==========  CHECK  ===========

lassort -i mini.laz -gps_time -odix _sorted -olaz

lasreturn -i mini_sorted.laz -check_return_numbering

checked returns of 106994 multi and 356166 single return pulses. took 0.57 secs

missing: 1820391 duplicate: 106878 too large: 0 zero: 0

missing

=======

101 returns with n = 5 and r = 1 are missing

435138 returns with n = 5 and r = 2 are missing

459138 returns with n = 5 and r = 3 are missing

462864 returns with n = 5 and r = 4 are missing

463150 returns with n = 5 and r = 5 are missing

duplicate

========

106878 returns with n = 5 and r = 1 are duplicate

=======  ATTEMPTED REPAIR   ======== 

lassort -i mini.laz -gps_time -odix _sorted -olaz

lasview -i mini_sorted.laz -steps 500 -color_by_return

lasreturn -i mini_sorted.laz -repair_number_of_returns -odix _repaired -olaz

lasview -i mini_sorted_repaired.laz -steps 500

==========  CHECK  AGAIN ===========  

lasreturn -i mini_sorted_repaired.laz -check_return_numbering

checked returns of 106994 multi and 356166 single return pulses. took 0.567 secs

missing: 127 duplicate: 106878 too large: 0 zero: 0

missing

=======

68 returns with n = 2 and r = 1 are missing

29 returns with n = 3 and r = 1 are missing

20 returns with n = 3 and r = 2 are missing

4 returns with n = 4 and r = 1 are missing

4 returns with n = 4 and r = 2 are missing

2 returns with n = 4 and r = 3 are missing

duplicate

========

79039 returns with n = 1 and r = 1 are duplicate

23874 returns with n = 2 and r = 1 are duplicate

3678 returns with n = 3 and r = 1 are duplicate

278 returns with n = 4 and r = 1 are duplicate

9 returns with n = 5 and r = 1 are duplicate

The high number of duplicates is suspicious.

========   CHECK AGAIN with LOG   ==========

lasreturn -i mini_sorted_repaired.laz -check_return_numbering -vv 2> log.txt  

The resulting log.txt has a list of all "seemingly" duplicate returns (same time stamp and return number) and below I track down one of each kind via their GPS time stamp ....

=========================================

shot with highest returns number being 1

las2txt -i mini.laz -keep_gps_time 236397.519396 236397.519398 -parse txyzrnai -stdout

236397.519397 11786181.095 3746045.176 220.818 1 5 74 121

236397.519397 11786180.886 3746043.667 215.364 1 5 74 187

las2las -i mini.laz -keep_gps_time 236397.519396 236397.519398 -o mini_2.las

lasview -i mini_2.las

=========================================

shot with highest returns number being 32

las2txt -i mini.laz -keep_gps_time 236397.519401 236397.519403 -parse txyzrnai -stdout

236397.519402 11786181.332 3746045.099 216.076 1 5 74 88

236397.519402 11786180.858 3746041.551 202.929 1 5 74 131

236397.519402 11786180.656 3746040.040 197.329 2 5 74 185

las2las -i mini.laz -keep_gps_time 236397.519401 236397.519403 -o mini_3.las

lasview -i mini_3.las

=========================================

shot with highest returns number being 3

las2txt -i mini.laz -keep_gps_time 236397.519414 236397.519416 -parse txyzrnai -stdout

236397.519415 11786182.396 3746048.629 218.462 1 5 75 167

236397.519415 11786182.235 3746047.289 213.176 1 5 75 162

236397.519415 11786181.820 3746043.834 199.548 2 5 75 93

236397.519415 11786181.733 3746043.112 196.700 3 5 75 83

las2las -i mini.laz -keep_gps_time 236397.519414 236397.519416 -o mini_4.las

lasview -i mini_4.las

=========================================

shot with highest returns number being 4

las2txt -i mini.laz -keep_gps_time 236397.519418 236397.519420 -parse txyzrnai -stdout

236397.519419 11786182.830 3746050.792 223.855 1 5 75 97

236397.519419 11786182.529 3746048.200 213.442 2 5 75 150

236397.519419 11786182.618 3746048.961 216.497 1 5 75 73

236397.519419 11786182.414 3746047.211 209.467 3 5 75 101

236397.519419 11786182.040 3746043.988 196.515 4 5 75 162

las2las -i mini.laz -keep_gps_time 236397.519418 236397.519420 -o mini_5.las

lasview -i mini_5.las

=========================================

shot with highest returns number being 5

las2txt -i mini.laz -keep_gps_time 236397.519290 236397.519292 -parse txyzrnai -stdout

236397.519291 11786171.970 3746016.844 212.091 2 5 66 94

236397.519291 11786171.665 3746015.367 208.561 3 5 66 127

236397.519291 11786171.095 3746012.608 201.966 4 5 66 88

236397.519291 11786172.629 3746020.037 219.724 1 5 66 97

236397.519291 11786172.269 3746018.291 215.552 1 5 66 77

236397.519291 11786170.626 3746010.337 196.538 5 5 66 14

las2las -i mini.laz -keep_gps_time 236397.519290 236397.519292 -o mini_6.las

lasview -i mini_6.las

[Martin Isenburg]

Hello,

We are growing inpatient as our time here in Samara is winding down and we still have not the usable data to kick off the "environmental grassroots citizen science" project we did that survey for which aims to create  a baseline inventory of trees, building, vegetation, and other structures of this little surf and beach community whose anticipated tourism growth is likely going to cause environmental impacts that we would like to be able to monitor quantitatively with regular reflights using all kinds of scanners. As the speed of the round-trip communication with the manufacturer of the device is not at all satisfactory to us here at rapidlasso GmbH - which may well be our fault given that our company is used to literally operate with laser-inspired velocities to resolve critical problems - we are now offering the raw data to anyone who 

(a) has an older bug-free versions of LiDARUSA's ScanLookPC software to re-process the data

(b) will have access to the latest ScanLookPC software once they have fixed the bugs we reported
(c) has software from another vendor that can process these files also, or
(d) is willing to try a SLAM solution to align and self-georeference the data

Here is the link to all of the raw data:

https://mega.nz/#F!zJ9EkCBT!wQ9WfPbsFQ_OLp723WZttg

The NYCO image and ZIP folders contain the Rinex data from the nearest base station located at Nicoya town 30 km from our flight site. The Rinex files are from the national geographic institute network of continuous operation GNSS reference stations.

Regards,

Martin @rapidlasso

[Martin Isenburg]

Hello,

it seems there is a new version 1.0.193 of ScanLookPC online. Yay! And the CHANGE log is updated. Yay!

http://wiki.lidarusa.com/doku.php?id=scanlook-pc-release-notes&do=revisions  

Maybe it was a double release. One on April 12th and then another one on April 17th. So make sure to download this 1.0.193 again if you had already downloaded 1.0.193 before April 17th because I had reported the RIEGL miniVUX and RIEGL VUX numbering bugs between those two dates (i.e. that the first and the second return of a multi-return echo are both specified as the first return) and it might be that this was only fixed in the version from April 17th.

Make also sure you hold onto your 1.0.171 or earlier ScanLookPC version until this latest version was vetted. (-:

If you can send me a pair of small sample exports (ideally from UAV) for the exact same scene from before and after you upgrade from your current 1.0.xxx to 1.0.193 (April 17th) Scanlook version that would really be great!

Thanks,

Martin

[jordan.litt...@gmail.com]

Operator error.  You cannot turn the UAV 90 or 180 degrees like this operator did.  Practice makes perfect, and attention to detail really pays off in this profession. 

[jordan.litt...@gmail.com]

I would like to add that it is very difficult to learn proper operation of these systems without in-depth, hands-on training. I hope I did not come off as rude in my previous comment. Have a good weekend everyone!

[Martin Isenburg]

Hello Jordan,

Thank you soooo much for taking the time to look into this. Personally I have no training or experience with any such LiDAR system and relied on the operator to do those steps as he was trained to do them. However, what I was able to contribute myself was to check the integrity of the exported LAS / LAZ files for any cues of what might go wrong and in doing so I found a total of four (4) different LAS export errors in the LAS / LAZ files that were produced by ScanLookPC that were either introduced in recent bug fixes or had already been there ever since the release. So either way this "wobble" issue will finally be solved, the exercise was already helpful for every user of ScanLookPC because those four LAS export errors should already or will soon have been eliminated from ScanLookPC. I will write up a concise summary of the four LAS / LAZ file export errors that I have seen in version 1.0.181 though 1.0.191 of that software ... (-:

But first I want to get a correct set of LAZ files for our 4 surveys. Note that in our exports we did *not* include the turns of the drone. From the little experience I have I do remember that turns are difficult for flight line matching software to deal with, so we generously clipped the scanned parts of the flight where the drone was turning during the processing of the data. I think that incorrect settings in the Intertial explorer that you mention on LinkedIn (*) might be the key to these wobbles ...

(*) https://www.linkedin.com/feed/update/urn:li:activity:6524399929589317632

Regards,

Martin @rapidlasso

On Fri, Apr 19, 2019 at 8:58 PM <jordan.litt...@gmail.com> wrote:

I would like to add that it is very difficult to learn proper operation of these systems without in-depth, hands-on training. I hope I did not come off as rude in my previous comment. Have a good weekend everyone!

--

[Martin Isenburg]

Hello,

now also Nelson was able to export a reasonable point cloud. It was - as many have already suspected - an issue with the trajectory processing. Nelson told me he reprocessed his Inertial Explorer solution a different way and was able to export the point cloud shown below. I have yet to get the details on what the crucial setting was that made the difference.

Note however, that there really were four (4) different bugs in the LAS / LAZ export of ScanLookPC that were found as a "side effect" to me investigating the "wobble issue" at the LAS / LAZ file level - the only thing I really know a lot about - and one of these 4 bugs (i.e. the GPS time mangling) seems to also affect the geometry as far as my analysis has shown so far (albeit by far not as drastically as those "wobbles"). We will also publish our final findings on those four different export errors and follow up with LiDARUSA until they are all fixed. Thanks to all who already gave us useful feedback and test data. But we will need a few more to reach the final conclusion ...

Regards,

Martin

[Martin Isenburg]

Hello,

Have you seen our first blog post that is somewhat a result of this "wobble" and "LAS export bugs" episode:

https://rapidlasso.com/2019/04/27/smooth-dtm-from-drone-lidar-off-velodyne-hdl-32a-mounted-on-dji-m600-uav/ 

Another blog post detailing the 5 "LAS export bugs" that have existed at least in ScanLookPC 1.0.181 though 1.0.191 is in the works but we are still waiting (sigh ... |-:) to get the exact same second of UAV data exported both from an older (correct GPS time stamps) and newer (buggy GPS time stamps) version of ScanLookPC to finally conclude this odyssey ... (-:

We are also looking for someone to process our four surveys for us, ideally with ScanLookPC 1.0.193. All the raw data can be downloaded here. No basestation. Just use PPP:

drone:
https://mega.nz/#F!zJ9EkCBT!wQ9WfPbsFQ_OLp723WZttg

pedestrian "jungle":

https://mega.nz/#F!aFlC0SYR!PbOF4Q528MZr-V7tlnVFfw

pedestrian "casa":

https://mega.nz/#F!LF8EjQha!YNML6HhaT8kkozusv-Uldg

truck:

https://mega.nz/#F!3VdEgQKR!tsMEfBvP8B1Sfn24flEBxQ

I'd be thrilled to have you submit your best set of LAS/LAZ files if you can afford to volunteer your and your computers time. The best results will be part of my story at SilviLaser 2019 in Brazil titled: "Tales of a Rascal (Scientist): What I did for Love (of Points)" ... (-:

https://www.silvilaser2019.ipef.br/speakers.asp

Regards.

Martin

[Blake Lytle]

Martin, do you have the boresight information for your platform?

[Martin Isenburg]

Hello,

Below are the lever arm and boresight values.

I only have the Rinex files for the drone flight (they are in the mega.nz main folder). For free download of Rinex files from "Nicoya GNSS base station" anyone can access the system here:

https://gnss.rnp.go.cr/spiderweb/frmIndex.aspx 

If you are going to process the pedestrian and / or the truck data you would need to spend two minutes creating a free account and maybe five more minutes downloading the Rinex files for exactly the time range that you will need. I do not really know anything about this process quite yet but I would be happy if someone could get the correct time ranges and send me the Rinex files so I can eventually put together one complete archive for this raw data.

Lever arms truck / pedestrian

X:  0.04

Y:  0.28

Z:  0.10

h: 1.69

Lever arms Drone:

X: -0.13

Y:  0.10

Z:  0.35

h: 0.71