jgvictores
commented
6 years ago From @RaulFdzbis on October 19, 2016 16:15
Some advances have been made in this area. Some problems and solutions have been found working in this issue. The followings are: Good things
- The initial idea behind ConvexDecompositions was to be used for collision checks, just as we wanna do. So thats good, i guess.
- If we want to set the cdmodel parameters, the generate(**kwargs) function should be used instead the autogenerate function used in the checkconvexdecomposition example. This function is used in our code to set the padding value of our model.
- A CheckConvexDecomposition test based on the one used in this example was performed. Initially all the tested points were returned as points inside the convexmodel. The picture below is one of the results of this initals experiments. This result showed us there was some problem with the generated cdmodel.
This problem was later solved setting some padding to the cdmodel using the generate function.
Not so good things (TODO)
- [ ] Some of the OpenRave examples do not work properly using ubuntu 14.04. So far these problems are only presented in the examples using robots different than the barrettwam robot used here. Some similar issue have already been reported, however no solution have been found yet. Since this is not critical for the resolution of this issue, this is not a priority.
- [x] When the convex decomposition model (cdmdel) is generated, this cdmodel is saved in the openrave database as a function of it's geometry. This means that if some padding is done in the cdmodel, the geometry changes and therefore its name. This is an already reported behaviour in OpenRave. At the end, this implies that a new model have to be generated everytime we want to work with a padded model. The load function doesn't work. To solve this problem, the temporal solution is to (since the "load" function always load the not padded cdmodel) to manually rename the padded model to have the same as the not padded one.
- [x] Checkselfcollision() does not work in the experiments done with the TEO cdmodel. These experiments consisted on using a large padding value to force the cdmodel to have some selfcollision without the need of moving the robot. Below is a picture example of the resulting cdmodel. Different padding values have been tested. However no selfcollision was detected.
SelfCollision function was called in two different ways, directly using the robot variable loaded in openrave in two scenarios (with and without cdmodel.setrobot()), and using the robot variable referenced in the cdmodel class this means cdmodel.robot.checkselfcollision(), without success. No collision were detected in any of the cases. As a note there is an open issue in openrave, with the goal of disable selfcollision using cdmodels. However is an OPEN issue, so it should not be implemented. Further study should be done in this direction.
- [x] I am not yet sure of how to use and how setrobot() function works. Maybe this is behind why checkselfcollision does not work.
- [ ] When a cdmodel.show() is executed in the code, the execution of the rest of the program stops. Is this normal?
At this moment the direction of the work done in this issue is to be able to perform a checkselfcollision test using the cdmodel. However this is not as critital as could seem. The reason is because there are many other ways to do a padding in the robot model. This could be done manually changing the xml file of the robot (rude way of doing things), or creating some new trimesh and assign it to the robot collision mesh (something similar as what is done in CD). However right now the best option still is to use the convexdecomposition module. So some more work should be done in this direction.
From @jgvictores on October 14, 2016 8:22
Started work on C++ teoCollisionAvoidance, but may be more practical to do in Python.
Copied from original issue: roboticslab-uc3m/kinematics-dynamics#63