I've got SLAM-mertime Sadness

[Ben_SDI]

Been working on trying to get SLAM to work on our R3Pro for a few weeks now.
First it was a coordinate issue. The errors would send my lidar data, control points and my trajectory to South America, but not the same place in South America (I’m in South Carolina, USA) Went through the laborious process of converting the points I had shot from State Plane Coordinates into WGS84 UTM.
Once that was done, I came back into ROCK Desktop to process.
I did the new alignment processes that are available in Desktop. But unlike the first times I had processed with incorrect points, the separate “passes” are now dramatically misaligned (primarily after step 3, Aligning to GCPs.)

(Pink Line is the trajectory)

I’ve SLAM’d the site twice but I’ve done at least 11 processes and have yet to get a usable SLAM dataset after 3 WEEKS.

I’ve watched all the videos multiple times but I’m still facing the same issues.
Getting on a call today with Jared Martinez from ROCK, but I wanted to put this out there and see if anyone had been having as much trouble getting a half decent SLAM dataset.

[Ben_SDI]

I skipped the 3rd step to avoid the misalignments and sent the job into ROCK Cloud to reproject.
I could observe that there were control points that didn’t align, but I wanted to see how it might come in height-wise, that’s why I pushed past step 3.

I reprojected BUT the height is now incorrect. I used the tools I was recommended to convert the control points (converting SPCS to WGS84 + the height conversion).

I brought in the SLAM dataset to Microstation where I normally work with point clouds. I also loaded the aerial LiDAR dataset for this same site (our offices).

SO we are back where we were where my control points are not converted correctly.

For the record, I encountered this before and I was recommend a vertical datum converter. The vertical change was only 102ft the first time. This is after I used the vertical datum converter so the converter made it worse somehow?

I suppose I’m using this thread for documentation as well as seeing if the community has any better luck than me.

[Jonrowsell]

Ben, we’ve had some SLAM issues too. We’ve done multiple SLAM datasets in an underground metro station, and had issues with the data aligning to GCPs and projecting correctly. We’ve ensured all firmware is correct, followed all the tips in the videos, but had no luck. It seems to get a little confused with stairs especially.
Sorry, no solutions, just a sympathetic ear!

[Ben_SDI]

Thanks for chiming in Jon. Good to know I’m not alone in my troubles.

I talked with Jared and Alex from ROCK yesterday afternoon about my issues with SLAM. Super nice fellas that I believe tried to help me any way they could.
It seems that the main pain points are with how the control is handled when processing SLAM.
We came to the conclusion that my site needed more control points to adjust to, even though it was a very small site. There really wasn’t more of a solution than that I’m afraid.

To forego having to manually shoot stripes in the parking lot, I used an aerial lidar dataset of the site to create more control points using ROCK Desktop.
There were some things that had to get sorted before I could do that though. Things such as uploading and reprojecting the aerial dataset BACK into WGS84/UTM. Otherwise, I would not be able to place the control correct spatially when in ROCK Desktop.

Since SLAM data is in WGS84/UTM, the control to tag it with also has to be in that projection.
This was perhaps the biggest point I had to come to terms with when understanding how the SLAM processing works. As a land surveyor, I’m used to State Plane Coordinates and working in International Feet here in South Carolina. Although, I’m fairly tech savvy and flexible, there is no simple conversion process for getting points from one projection to another. Especially not in bulk. None that I’ve seen or tried so far.

I brought these new control points I made from my aerial dataset into the SLAM project and processed it. The point cloud now seems to align well and all that is left should be reprojecting it into State Plane Coordinates.

But I feel like this was a TON of back and forth just to get a working SLAM point cloud, which as of right now, before I’ve reprojected and exported, I still don’t know for sure if it will align with my aerial dataset.

All that said, I couldn’t imagine your situation. You can’t just fly an aerial dataset to place more control points. You’d have to go and manually place more targets AND rescan likely. I had to add 30 more targets to my site with only two small office buildings, so there’s no telling what you might have to do.

With all respect to the folks who have created this tech and made it available to folks like us, they have made something incredible but it doesn’t feel as refined and usable as they sell in the videos and marketing. I would’ve never known the solution if I hadn’t spent 3 weeks of back and forth with ROCK Support, eventually asking the right question. I simply didn’t know, what I didn’t know.

It made sense when you said that you’ve watched the videos and had no luck, because there are things that are not mentioned in videos that are pretty big pieces of the puzzle, namely the control situation.
The aerial aspect is fantastic, no complaints there. But the SLAM seemed too good to be true, and I hate to admit that I’ve felt that be true since we’ve bought it.

[Ben_SDI]

Continuing documenting my SLAM journey here…

We scanned another site. This time we had 90 GCPs shot in the field.
I’ve found a new conversion process that I believe may be like striking gold for converting field shots in SPCS to UTM. This is my first try with the new method I found, so I’m not going to talk about it until I know it works for sure. The main concern is the elevation conversion because its more of a manual process where I multiply everything by 0.3048 (This essentially just converted the international feet to meters).

I processed this in ROCK Desktop. I was under the impression that once SLAM processing came to Desktop, the time limit would not be a thing anymore.
My dataset here is about 32 minutes long. If you look to the top left of the picture, you’ll see an incomplete figure 8 (our attempt at loop closure). That’s where Desktop actually cut my trajectory off at 1800 secs (30 min). I contacted ROCK Support about that and got told that they RECOMMEND no longer than 30 mins but I should be able to process longer. So I’m not sure why it cut my trajectory off if that’s true. Something to watch.

After my first SLAM process, I’m thinking this won’t be enough control to keep everything matched. I had a section on the first SLAM where the whole site was covered with about 20 something targets but there was a 20 foot section that was slightly bare of points and the data drifted there and did not align. Not awful but I’d hoped it could withstand no GCPs for at least that little bit of time.

This is processing step 3 of the alignment process in Desktop now, will hopefully update this with my results soon.

[Ben_SDI]

Finished processing Step 3.

Things are decently aligned but there are areas where the point clouds seem to be separating still. I find this strange because the very initial process of the SLAM data aligns everything quite well, but when you add the GCPs, it makes the point clouds separate.
If I had a note for the developers, I would say that since the point cloud passes are normally well matched from the initial process, I would recommend that any control tagging processes NOT disturb that. Instead it might should view and adjust the point cloud as a unified item instead of moving each pass. This way, the beautifully aligned point clouds do not separate when control is tagged.

Exporting now to the cloud for reprojection and scaling. Will hopefully update soon.

[Ben_SDI]

Update:

We obtained a “usable” point cloud for this. There were still issues with separation of passes. I’m assuming this was drift-related, but like I said before, they matched fine before Step 3 in Rock Desktop Control Aligning. I digress.

I did an elevation conversion from meters to feet and when I pulled the SLAM data in and compared to NOAA LiDAR data, the SLAM was about 103 ft high.
Not sure what I’m missing there on the elevation conversion.

Either way, I pulled in the ORIGINAL control collected from the field (correctly elevated). Use this to drop the SLAM data down in ROCK Cloud. Exported and pulled it back in against the NOAA data, and it mostly matched. There were still some areas that didn’t align with the NOAA data so idk what to do with that. More control I suppose.

Looking ahead…
We are scanning a MASSIVE private school grounds. Nothing inside but hoping to get some building footprints and other useful As-Built information.
Should be interesting!

[wallsLANDwater]

Thanks for your real world review of your experiences with SLAM. I’ve been trying to arrange a demo of the R3Pro without any luck. I’ve used the geoSLAM products before but found it can be finicky as well when aligning to control. I often need ground data to supplement aerial LiDAR flights especially under canopy and an all-in-one aerial/SLAM product is tempting, but I would need the point clouds to align. 90 GCPs is a lot and I would hope that I wouldn’t need that many. Sounds like it is not quite there yet.

Just curious, have you tried aligning to control after processing the SLAM?

[Ben_SDI]

Happy to help and inform!

Concerning aerial LiDAR and having sparse data, low and slow is the mantra to live by for getting extra data. Been doing aerial LiDAR for a while now and there will always be a need for some field shots in there. The R3Pro is fantastic in terms of vegetation penetration. We’ve been pretty happy so far with our results on that front.

90 GCPs IS a lot. But the way things are, its necessary if you want a decent SLAM dataset. Im talking about points at every corner and in-between. Hopefully the drift gets solved someday. I believe the upcoming SLAM w/GNSS will help a lot, but you’ll want targets in the covered areas still. SLAM mount version 2 should be coming out at the end of this month/beginning of next, this will help things along.

As far as control tagging AFTER SLAM processing, I did attempt this. It was how I aligned the incorrectly elevated SLAM dataset to the control in my most recent post (several minutes ago). It does help align things but it is a rigid alignment where the point cloud seems to average the shots you tag and rotates and translates according to ALL of them. The averaged change is applied but the point cloud.

It helps some but if you have any drift in your data, it won’t do much to fix it.

If you have any more questions, let me know. I’m learning more everyday.

[wallsLANDwater]

Good to hear about veg penetration, just curious did you use R2A (which is what I have currently) before? Curious how it compares. Definitely seems like you get less fuzz but would be curious to see if it’s better for veg.

I definitely fly as low as slow as possible, but I am often surveying rivers and creeks where the riparian veg can be very dense leaving gaps in point cloud for top of bank that I need to fill in with total station. Also sometimes there are 250ft+ redwood trees which makes a low flight impossible. But from the creek channel you could pick up most of the understory with SLAM, which is my hope! Also want to be able to locate and measure tree diameters (dbh).

Anyways, appreciate the info and please keep updates coming, thanks again!

[Ben_SDI]

We actually used a Riegl MiniVUX1 from LiDARUSA before the R3Pro.
A solid unit for accuracy, okay for vegetation penetration, and awful to process data. AND too heavy for an M300/350. R3Pro data is much denser and less noisy, but the latter is because of the smoothing that occurs when you optimize in ROCK Desktop. I have seen R2A data and the R3Pro is certainly better.

I understand what you mean about the creeks. During summer specifically, we have our field crews actually shoot the creeks to ensure accuracy. Haven’t seen if that will be necessary with the R3Pro or not, but summer will be here before we know it.

[leo_stan]

Hi @Ben_SDI! I’m one of the developers behind SLAM at ROCK

Thanks for sharing your experience with aligning the data to GCPs, we’re always happy to hear feedback to help improve our products further! I’ll try and answer a few of the points you made throughout this thread and provide some explanation.

You are correct that if you only do step 2 (Align to World), the program will try to align the dataset as a whole to all the provided GCPs as best it can. Unfortunately, SLAM datasets have an inherent drift over long distances (due to lack of GPS), so this method will not be able to align the point cloud perfectly to the GCPs.

To align the point cloud perfectly to GCPs, we need to “break” the SLAM trajectory into pieces and align those pieces individually to the GCPs (This is what step 3 “Alignment to Control” does). As you saw, it works well in areas where GCPs are present but can introduce misalignment in areas lacking enough GCPs. We only recently introduced this alignment tool and are currently working on improving our method to prevent misalignment in areas that don’t have a lot of GCPs. I’m glad you were able to use the tool to get a useful point cloud in the meantime.

Regarding the maximum duration, we do recommend 30min maximum and that’s why it defaulted to that in Rock Desktop, however, you could push this limit under “advanced settings”. We have now removed the default limit, so you can process as much data as you want without having to change any settings.

If you have any other suggestions/issues feel free to share!

Thanks,
Leo

[Ben_SDI]

Hey Leo,

Thanks for commenting and giving me some insight on the process. I appreciate the work you all have put in and are continuing to do.

I did want to address the misalignment after Step 3 subject. I have areas with multiple GCPs (would likely be considered good coverage) and the data misaligns in those areas after S3. Is there anything I can do better to prevent that?

Also, while I’m thinking about it, you mentioned is S3 it breaks the trajectory into pieces to align to GCPs. If I broke up the trajectory manually, would it still break it up automatically? Does it pick a distance/time for how and when it decides to break up the pass? If that’s the case, I would like to experiment with breaking the trajectory manually so that I can decide how much of a pass might use the GCPs WITHIN that time range. I hypothesize that could concentrate which control are used for which sections.

I hope that makes sense, if it doesn’t I’ll attempt to demonstrate with a video or something.

[patriotlands]

Just checked my only slam project 3ac with 6 gcps on sky high lidar targets lidar targets.

Horizontal is fine (hundreths) but only if scaled from meters which throws off vertical as the point cloud is scaled in 3d of course. I am heading out now, on a saturday to shoot manually before I get sued to oblivion.

I have previously asked for the boat/vehicle lever arm setup to no avail. The slam is the only reason I bought the R3Pro otherwise I would have bought the Zenmuse L2 and saved 17k, actually 22k when the useless onboarding is factored in. Its unfortunate it doesn’t work as advertised for slam, aerial mode no problems at all.

[Ben_SDI]

I understand where you’re coming from.
Our president only approved it because of the SLAM capabilities. It was both our understanding that you could collect survey accurate 3D point cloud with ease. We intend to use it for as-built purposes. But we have yet to be able to use it for anything because of how long it takes to get a working point cloud.
We are testing now to see if we can just draw the point cloud in its untagged format. It’ll be scaled and located incorrectly, but we will take shots in the field that we can also see in the SLAM and scale and position the linework that we are extracting from Microstation/TopoDOT.
We hypothesize that to be the most rapid and reliable way of getting our as-built info without control tagging which is a royal pain with little pay off.

[leo_stan]

Hey Ben,

You are right, in areas with sufficient GCPs it should not separate at all. If you send your dataset (including GCPs) to support@rockrobotic.com we can take a look to see what’s going on.

Regarding manually breaking the trajectory, the algorithm will automatically break the trajectory based on time. While you could try to break it manually by editing the trajectory file, I think you would still end up with separation between the different “pieces” of trajectories once you merge everything. This is a tough problem better solved globally by a computer and we’re hoping to have an improved version soon for you to try.

Thanks,
Leo

[leo_stan]

Hi @patriotlands!

I’d like to hear more about your issue with vertical scaling. Just to make sure I understand correctly, you’ve aligned to GCPs in meters scale within Rock Desktop, and once you scaled to another unit the vertical alignment was off but not the horizontal?

Thanks,
Leo

[patriotlands]

Hi Leo, yes I have since installed RD 1.11.8 and reprocessed. That result was still off vertically but only by 0.7’ instead of 2-3’.
Also I processed a new slam project on Tuesday in 1.11.8 on a 104’ square parcel and the cloud fit fine (hundreths) with the 4 gcp’s horiz & vert.

I was going to test on a larger piece yesterday but the slam mount will not power up the R3 lidar at all now. Charged battery from 83% to 100% with no result. Cable and mount have no damage and R3 powers up on drone every time. Until yesterday had no problem powering up R3 on slam mount whatsoever. Please advise, promised projects are pending.

[jared.martinez]

Hi @patriotlands Could you send an email with your SLAM dock power issue to support@rockrobotic.com? Thanks!

[Ben_SDI]

ChristChurch - BLDG E | ROCK Robotic Cloud

Here is a sneak peek at a site we are currently SLAM-ing. There are probably 11 other buildings on this 70-ish acre site. If folks are interested, I will post some of the others.

This dataset is NOT tagged to any control because that would’ve been a TON of control to collect in the field. We would just survey it conventionally in the same time it would take to do the control for this.

Our plan is to draw this in it’s raw form (meters and arbitrarily placed) and then scale and rotate the linework to control points that are shot in the field that can also be seen in the point cloud.
We aren’t going to worry about the elevation while using the SLAM data, we are just using it for location for, essentially, planimetrics. We will be flying the R3Pro for topo. We would’ve done it in reverse order but getting flight approval has been a HUGE pain with our local airport here.

I think I would’ve loved to have the v2 SLAM mount with colorization and GPS. I may have lost GPS signal near this building but it probably would’ve been helpful for placing this CLOSE to where it actually is in real world. If I really want to tag this site, I’ll do it from the aerial point cloud and port it back in to the SLAM projects and reprocess. ALTHOUGH, that would make my point clouds become misaligned if I’m going off of my past experience. EHHH… we’ll see if I want to fool with it.

Anyways, this was the first time that I am experimenting with a more effective loop closure technique.
If you’ll notice, there are a TON of little tiny loops and crossing back and forth in short distances. Loops at corners and loops in the middle of walls. I’m thinking this is a much better way to get the loop closure needed. Dylan Gorman came to our office here in Greenville and gave us some pointers on SLAM technique. If you’re not following his Youtube channel, its time to crawl out of the hole you’re in.

Dylan Gorman

Anyways, with the tips he gave us, we have been able to SLAM multiple of these large and intricate buildings and essentially obtain a lot of survey info that is going to save our field crews plenty of time.
Is the way I did this the best way? No, I don’t think so. But it is the easiest way CURRENTLY to use a SLAM dataset for actual survey information.