Map making error #167
Comments
|
That print out only happens in lifelong mapping mode, which I think I print warnings everywhere that its incomplete and a research tool for the time being. Switch back to one of the non-lifelong mapping executables. You can still update maps over time by serializing and deserializing, but automatically degrading laser scan nodes is a work in progress and is available as a reference implementation at the moment. Admittedly, its a work in progress on the backburner but I’m hoping either I will get back to it or some interested third party will come along to work with me on building it. Its in an experimental subdirectory in the codebase |
|
Thanks for your reply. |
|
If you want I can make a gif out of it to show it. |
|
Also when I fire the localisation mode using: and these as config I am getting this error quite consistently unless I remove hte loop closure function.
I think there might be an issue with the loop closure setting or function, as with at least lifelong mapping, online async and localisation modes, there are strage behaviours (like the previous comments) when doing the loop closure. As soon as a remove the loop closure part, the system seems to behave better. |
|
I’m going to need more information: OS, install, ROS distro, laser type/manufacturer/driver, etc If you have a bag of data that shows this behavior I can test with, that is best. I have never seen that behavior before outside of lifelong mode, which you shouldnt use (or use any derivatives of, if you happen to be mapping or localizing against a map originally made from it, dont) for the above reasons. |
|
ubuntu 18.04, melodic, using the melodic-devel branch. |
|
I’d be curious if you tried this with another non-360 lidar if it continued to happen. Also, how are you liking the S1? I’ve wanted to poke at it, but I wasn’t going to shell out the money myself when I have better lidars at home already. The map quality posted isn’t reassuring of its quality, but that could be this problem too 🙃 I will admit, I’m super swamped right now. I’ll try to look at this over the weekend but my availability is a little short. If this is new, try looking at recentish commits and see if you spot something. Also check that the Ceres library didn’t update & mess something up. How did you install ceres? Just from rosdep or a custom build / different version? Ive heard from users having problems with ceres if they didn’t use the default version, but I didn’t get specifics as to how that manifested. |
|
Hi, I got a chance to play with it today @joekeo. I'm not seeing the issue you describe on my side, see gif below. Sorry for the gif quality, I'm still working out how to do screen casts on my new monitor (its stupid big and stupid high update rate) so I had to substantially compress it to get it to load here (and <1gb). If you see, the costmap follows the robot, then around the time that I think you see the jumping it deviates. I think that's because its using the transformations from your issue situation, but not reflective of the "working" transforms I was producing.
My steps to reproduce:
on the bag file, to remove the transformations your recorded from your SLAM runs, so I was just left with the raw data to provide my own.
I think from that "jumping" there's an issue with your configuration or if you manually installed Ceres - is your laser inverted or not inverted? Is your TF tree correct for that laser inversion? In your gif - I'm seeing: Robot moving, robot flipping position, you dragging rviz window around, and then the map orientation correcting in the next publish update cycle. Is that correct? Is there anything you're doing between "working correctly" and before it flips around? That shouldn't happen if the first nodes are being properly held constant. In the Ceres plugin solver I check if we have a first node and we lock down the pose and orientation of it so that it cannot move as the graph updates. Please confirm how you installed Ceres. |
|
Many thanks for your help. Today i will be looking at this and let you know what was the issue (If we can find it) |
|
Update? |
|
Sorry for the big radio silence, Been working on fixing some electronics of the robot and took much longer than expected.
I am not sure what do you mean by this, I cloned your repository and built it. Should I make a separate Ceres installation? (sorry if it is a dumb question) |
|
Well it seemed to work on my machine without an issue after I threw out the TF generated by your run (which is a typical requirement for SLAM testing). That makes me think your install, version, or settings if not using the defaults I mention above are off. Given you see the error when Ceres updates, it makes me think that’s suspect. How was Ceres installed? It doesn’t just come batteries included with Ubuntu so you must have installed it somehow. Did you use rosdep to install them or did you build a version of it (for instance, from running cartographer, which requires a snowflake version). Nothing else, sometimes nuking a workspace and clean rebuilding helps when you see weird stuff that others can’t reproduce. Pull latest melodic. Or maybe architecture? What’s this running on? |
|
I did: |
|
Install ceres via rosdep only. If you had cartographer around you may need to track down ceres there on your system and purge it. Or run through docker or something containerized. |
|
Good idea, will do that. Will let you know how it goes |
|
There’s a dockerfile in the repo (though I just glanced at it and now that eloquent is the default branch the clone step needs to specify melodic-devel. If you use that it would be great if you could submit the one-line PR). |
|
Solved! The error was due to a bad installation of Ceres. I purged it then installed it again and everything seems to work fine. |
|
Do you happen to know what version/install? I’d merge a PR that set the get package to the exact rosdep version to help resolve. From my quickness to ask, you can probably tell this has come up before. |
|
So... I thought that it was resolved, but it wasnt, I am going to do a
clean install of the nav computer and document all steps and let you know.
…On Tue, 10 Mar 2020 at 15:16, Steve Macenski ***@***.***> wrote:
Do you happen to know what version/install?
I’d merge a PR that set the get package to the exact rosdep version to
help resolve.
From my quickness to ask, you can probably tell this has come up before.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#167?email_source=notifications&email_token=ABDLJIHVELA5F7EMIK2KXULRGZKT3A5CNFSM4KUM2BA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOL2XYY#issuecomment-597142499>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDLJIGR5SJY5AYOHC33YKTRGZKT3ANCNFSM4KUM2BAQ>
.
|
|
So i did a clean install and installed slam_toolbox form rosdep only and the issue persists. There seems to be 3 instances where there was some loop closure happening, I could not see form RViz the first loop closure happening, but in the GIF above you can see what happens with the second and third loop closure. If you can see something interesting in the debug logs for the solver summaries let me know, I dont really understand them. And on the bottom of the thread you can see the config file that I used, might be some useful info there. I have checked my TF and I dont see anything out of the ordinary. And this is my config file: |
|
The only 2 things that stand out in the param file is you’re updating the slam problem every 1cm. A typical number is 10-20cm. Not only will that not scale well with mapping spaces, it breaks the assumptions of most scan matching methods (even ICP). No global slam system should be run that frequently- you have fused odometry for a reason. Try backing that out to reasonable numbers in that range. Also consult the default configs. Do those work for you? Send me a bag. I can quickly sanity check. |
|
Hi @joekeo did you resolve this issue? Are you still seeing it? |
|
Thanks for the follow up. As always thanks for all your help. You are a legend |
|
Awesome, thank you for closing the loop here. I hate leaving strings that might imply deeply rooted regressions, it makes me very nervous 😄 IMU off by 180 degrees... jeeze, how did that ever work. Well, good catch. |
|
We are currently facing that error. The map is quite good in starting. After a few time, the drifting occurs. And we also get these Any suggestion to fix these. Confirmation |
I am also getting this error. Any progress on a fix? |
Hello,
I am back on working with slam toolbox for a project.
I am having issues when trying to map a simple environment. While mapping the map suddenly jump out of place and start mapping over the current map. I believe this is the loop closure trying to sort it out. But it seems that it produces bad results more often than not.
Any Idea why this happens? The gif below shows the situation.
The terminal shows the following information while making this gif:
And my configuration looks like this:
The text was updated successfully, but these errors were encountered: