Closed xela-95 closed 9 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
5f4815a
) 83.31% compared to head (efe775d
) 61.25%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@traversaro with https://github.com/robotology/gz-sim-yarp-plugins/pull/86/commits/599fab040180120c314e66cd77eceed108ee70e7 I started having a working (not passing) unit test. It was quite hard to understand how the fixture works but basically it calls the callbacks (OnConfigure, OnPreUpdate, OnPostUpdate) after having called the corresponding methods for the plugin, so it's easy to obtain data directly from the device without having to duplicate configuration code already done in the plugin classes.
Here the logs of the test launched with $ ctest -R ControlBoardTest --verbose
for 10 iterations:
The mismatch between joint and link quantities is due to the fact that I can access from the Link API link quantities expressed in world frame. I have to understand how to change the reference frame.
With the last commit I introduced some modifications to the SDF model used for the test:
I've modified also the unit test code: now it uses the correct inertia for the link and while I'm trying to understand how to get the joint acceleration, I'm using the finite differences computations of the joint velocity. An alternative could be to use the link angular acceleration.
The test is now passing, but is numerically fragile due to the finite difference computation of the joint acceleration. I've posted questions on how to get the data from Gazebo in the OSRF Discord channel and on Robotics Stack Exchange).
Now I can focus on testing different models (e.g. when the joint frame is defined wrt the child link or arbitrary frames) and check whether my code to compute the torque projected on the joint axis works.
I've seen that on macos the test on the controlboard is failing: https://github.com/robotology/gz-sim-yarp-plugins/actions/runs/7974385463/job/21770152674?pr=86#step:12:40257
It seems to be related to a lock issue... strange that is happening only there, maybe there is still a mutex error that happens in a transient way 🤔
Based on https://stackoverflow.com/questions/66773247/libcabi-dylib-terminating-with-uncaught-exception-of-type-std-1system-er, perhaps we have some static mutex somewhere? If we can't find the culprit easily, I have also a macos mini you can used for debug. If we can't find the solution, we could also just suppress the test on macos for the time being.
Based on https://stackoverflow.com/questions/66773247/libcabi-dylib-terminating-with-uncaught-exception-of-type-std-1system-er, perhaps we have some static mutex somewhere? If we can't find the culprit easily, I have also a macos mini you can used for debug. If we can't find the solution, we could also just suppress the test on macos for the time being.
Yep we use static mutexes in every singleton class of each plugin, plus the robotinterface singleton. Do you suggest any tool useful to debug such errors?
With commit efe775d I disabled the second unit test, in order to make the CI pass. This issue will be addressed in #90, since it is unrelated to the current issue and it could affect all plugins.
Closes #81
This PR aims at computing the value of the joint torque from the corresponding
JointTransmittedWrench
returned by the gz-sim simulator. At the moment this is supported only for revolute joints.