-
Notifications
You must be signed in to change notification settings - Fork 40
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
Collision checking with custom .obj object #65
Comments
The collision checking may depend on your use case. First, the visual point cloud will be different from the simulated collision if the object is not convex, since the simulator requires convex collision shapes. So you need to be aware of this. If you just want to do collision checking between the robot and the point cloud, a solution is to read the pose of all robot links and then manually check for collisions. We also have this use case in our motion planning tasks, and we have implemented a planning library mplib where collision avoidance with point clouds is used. You can check the documentation here https://sapien.ucsd.edu/docs/2.0/tutorial/motion_planning/collision_avoidance.html#add-environment-point-clouds. And we also have the source code available https://github.com/haosulab/MPlib. |
Thank you so much for this! I was not aware that the simulator requires convex collision shapes, so this is very useful to know. I just wanted to clarify -- if we have a non-convex object, you are suggesting that the visual point cloud from this object will be correct, but the simulated collision will not be (because the simulator requires convex collision shapes), right? And because the visual point cloud is correct, we could utilize mplib for collision checking using the visual point cloud (and cannot do this natively in Sapien)? Thanks for the help! |
Your understanding is correct. mplib can be potentially used in real robotics as well as in simulators, so it will not be part of SAPIEN simulator. However, SAPIEN will probably include this library (as a python utility) in the future. |
Got it, thanks! A quick follow-up question: If we load a non-convex object into the simulator, is it possible to disable collisions with this object (for the robot and all other objects in the scene)? |
The solution is to not load it as collision shape in the first place. You can just call functions to add visual shapes but not collision shapes. Is that what you want to achieve? |
I would like an RGBD camera to still detect the non-convex object (to obtain both RGB images or depth / pointcloud from the object) but I don't want the robot or the other objects in the environment to collide with it. Is this possible? I'm currently loading this object as:
This way, the RGBD / point cloud seems to be accurate, but collisions are not disabled and so collisions result in very strange behavior (which I would like to turn off, while still receiving RGBD / point cloud sensory information). |
Without collision shape, it cannot compute the mass and inertia of the object, which will result in a different type of strange behavior. Maybe you can provide a .srdf file to disable certain collision pairs? Or maybe you can remove the collision tags in the URDF file and add reasonable mass and inertia to the URDF file. |
I see, thanks!
In MPlib, were you thinking of I tried to construct the following simple example: Here, the scene simply consists of a robot and a box (loaded using a custom .obj file -- I know the collision avoidance tutorial creates the box directly, but I want to be able to do this using custom .obj files). I place the robot to be in collision with the box, and I would like to detect this collision. I obtain a 360 degree pointcloud (as done in the gym environment), center the pointcloud to be around the robot's base, and then use
With the collision detection portion at the end commented out, we can see in the viewer that the robot is clearly in collision with the box. However, when we uncomment this part, we see that For completeness,
and
Apologies for the incredibly long post. |
The point cloud should be in the root frame of the robot since mplib does not take robot root pose as an argument. So maybe the maniskill point cloud is not in the robot root frame? |
The ManiSkill pointcloud is in the world coordinate frame, which is why I tried translating this manually using I've also posted an issue on MPlib. Thanks so much for your help! |
The root frame is the pose of the robot root link. You can get this pose by |
This worked, thank you so much! Really appreciate all your help. |
Hi, I have been using the following code to 1. remove points from the robot, and 2. convert the points from the world coordinate frame to the robot frame:
I first remove the background points from When I drastically change the height of the robot by modifying I have verified that changing the base position (e.g. moving it further away from the box) correctly changes the mean of these points to be further away, but the same does not seem to work as we change the height... Apologies if this is not enough information. I would be happy to clarify what I mean, if unclear. |
I am not sure what is |
Is your feature request related to a problem? Please describe.
I have verified that placing a custom .obj object in the scene changes the sensory input point cloud information that the robot receives, but I'm wondering if I can see whether a given configuration of the robot collides with this object -- is this possible?
Describe the solution you'd like
A function for collision checking which works on custom .obj objects.
Describe alternatives you've considered
Writing a custom collision checker which takes in the x y z points from the .obj file and verifies whether any point on the robot is in collision with any point on the object.
The text was updated successfully, but these errors were encountered: