Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can I get the coefficient of friction in rviz? #5

Open
sevenzero70 opened this issue Mar 28, 2023 · 13 comments
Open

How can I get the coefficient of friction in rviz? #5

sevenzero70 opened this issue Mar 28, 2023 · 13 comments

Comments

@sevenzero70
Copy link

Sorry to bother you after a long time, I get part of the mapping effect when running “spot-comp8.bag” under the default configuration as shown in the figure, but the colors shown in the figure I only find that means the classification of the terrain category.
image
Besides I want to get an image similar to the second row of Figure 5 in your paper to represent the image of the coefficient of friction, like this.
image

and what should I do?Maybe I can change something in elmap.py? Waiting for your reply, thanks.

@BuildingAtom
Copy link
Collaborator

Hi @sevenzero70. I'm actually unsure of where those colors, specifically the yellow and orange come from. They don't line up to anything from our package alone, and the colors don't seem to line up to the boundaries of the elements. Is it possible you have something else being visualized which is overlapping the mesh resulting in the off colors? That should should a mostly pink mesh as the hill in spot_comp8.bag should mostly be uniformly classified. spot_comp3.bag which was previously provided may be a better example.

If you'd like to try with the bag from our demonstration video, this is the rosbag we collected from that run: spot_vid2.bag.

Since there was snow for this one, we use terrain_properties:=pascal_context.yaml, and semseg_config:=Encoding_ResNet50_PContext_full.yaml.

@sevenzero70
Copy link
Author

sevenzero70 commented Apr 1, 2023 via email

@BuildingAtom
Copy link
Collaborator

BuildingAtom commented Apr 1, 2023 via email

@sevenzero70
Copy link
Author

sevenzero70 commented Apr 1, 2023 via email

@BuildingAtom
Copy link
Collaborator

BuildingAtom commented Apr 1, 2023 via email

@sevenzero70
Copy link
Author

sevenzero70 commented Apr 1, 2023 via email

@sevenzero70
Copy link
Author

sevenzero70 commented Apr 1, 2023 via email

@BuildingAtom
Copy link
Collaborator

BuildingAtom commented Apr 1, 2023 via email

@sevenzero70
Copy link
Author

rviz_image.zip

@BuildingAtom
Copy link
Collaborator

The files that you have sent to me now do look mostly reasonable, but I do see a possible issue. Can you make sure the buffer size under the Mesh display is set to 1 instead of 10. It seems like this may be causing it to display overlapping meshes instead of clearing the old one like it should be. Though, I'm not running my test system at the moment, so I can't verify that this is the issue for sure and that the .rviz file has no other issues whatsoever.

Otherwise, the files you sent match my expectations given what you've mentioned. The colorscale appears to be working right in the two images you sent. If you added a red RGB value like 0, 255, 0 to the values list, the red gets added as another colorstop for the gradient used in the output, similar to in that picture. The terrain properties also appear roughly as expected.

I was wondering if you had something else visualized in the original image because the yellow and orange colors in the original image don't appear in the colorscale provided from the repository, and they don't seem to line up to the mesh faces. It's most obvious on the diagonals, but the triangle have their main diagonals from top left to bottom right, and there are a few yellow-pink boundaries on the opposite diagonal which shouldn't be possible:

228119762-2570a6b0-9c66-42e6-bde9-aa7991c17dd1

The way the coloring works, it should color an entire mesh face at a time, which is mostly the case in these two example images from the zip file provided. It does seem like there are overlapping meshes (especially in the second image), which is affecting the appearance of the mesh though.

red_gradient_img
terrian_classification_img

@BuildingAtom
Copy link
Collaborator

Hi @sevenzero70, I just wanted to check in to see if you had any progress in figuring out the issue with the mesh? Were you able to try changing the queue size to see if that solved the issue?

@sevenzero70
Copy link
Author

sevenzero70 commented Apr 7, 2023 via email

@BuildingAtom
Copy link
Collaborator

I see, no worries! Hopefully you're feeling better! So it seems like we have at least addressed the issue of overlapping meshes. Can you perform a git diff with the current repository main and verify that all files are the same?

For example:
git diff caea37f61b91f49e84959a8891e933cd7f275146 HEAD >> diff_file.txt
and then attach diff_file.txt to this issue

caea37f61b91f49e84959a8891e933cd7f275146 is the current hash of the main branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants