Closed domrachev03 closed 2 weeks ago
coveralls
commented
1 month ago | Totals | |
|---|---|
| Change from base Build 9283206227: | 0.05% |
| Covered Lines: | 1515 |
| Relevant Lines: | 1531 |
domrachev03
commented
1 month ago Also big thanks to @simeon-ned, since he contributed a lot in the process of creation of the barrier, despite not listed in the commit history
domrachev03
commented
3 weeks ago Thank you once again for your attention to the details! The method compute_jacobian surely was unnecessarily overcomplicated, and we've already fixed this issue.
While the implementation was correct, the test you've mentioned definitely wouldn't have caught such a problem. Hence, if you still think it is necessary, we could spend some time and implement it.
stephane-caron
commented
2 weeks ago Thank you both for this new barrier and the corresponding example 😃
This PR continues the series of PRs, aimed at introduction of Control Barrier Functions, mentioned in https://github.com/stephane-caron/pink/issues/86 . This PR implements self-collision avoidance barrier, namely one of the following form:
$$h(q) = |p_1(q) - p2(q)|^2 - d{min}^2$$
where $p_{1,2}$ are positions of first and second frame of interest. It takes names of two frames of interest and minimum distance that they have to have between each other.
The functionality is demonstrated on the Yumi two-armed robot with custom frame definition w.r.t. end-effector (that is, one could define shifted frames and so make use of those constraints more practical):
https://github.com/stephane-caron/pink/assets/28687492/6cc3524c-c79e-435b-a4e9-af1e1271a148
We have some draft work on implementation of self-collision avoidance using hpp-fcl, see here. However, it proves to be very computationally expensive, and we are not sure should be proceed with development of this feature or not. Any comments on that matter are more than welcome!
Any further suggestions would be welcome, waiting for your feedback!