Open torydebra opened 4 years ago
At the end I used numexpr. It should be safe to use (not like eval), any info about? I also need to substitute ^ with ** for python code.
Hi Dav, I d like to know why you are doing that in ordet to understand. thanks :)
Hi Dav, I d like to know why you are doing that in ordet to understand. thanks :)
I am working on providing a way to put a nonLinear relationship for mimic joints
For example, I can say joint_mimic_pos = joint_father_pos ^ 2, simply indicating x^2 in the urdf, among the mimic tags. We will use this for HERI (not x^2 obviusly)
perfect! I get it!
Maybe I also have to remember to specifically put some tests for this part
yes! I suggest you too to provide some usage examples and or some explanation of how to use it :)
Updates: With nonlinear functions, it has become important to enforce the limit of mimic joints; because approximating non linear function can cause weird joint movements if the father move more than expected by the function approximation.
Joint state publisher does not do that, there was a PR https://github.com/ros/joint_state_publisher/pull/13 but it has not been implemented. I copied the line in my fork to enforce these limits.
Gazebo mimic plugin does not need to enforce limits; it seems that gazebo already consider limits and stops the mimic children (I tested with default engine which is ODE, other engines do this? It is a feature of gazebo or of the specific engine?)
FindActions has been modified in the setToRandomPosition, now also there after setting the non linear position, we enforce the joint limits.
I noticed that we can have problem if the father of a mimic joint is a mimic joint itself (i.e., there is a "grand-father" or more). This because we iterate the mimic map, and we do not know if the "children" will be updated BEFORE the "nephews", as it should be. BTW, I think this is a really strange case, and we can keep this. Only remember to warn the user that the father of a non linear mimic joint cannot be a mimic NL joint itself (this is instead possible with the "standard" official mimic tag). This warn is also for the fork of the mimic plugins and joint state publishers
I should add a check too see that all the "father" joints are effectively contained in the "activeJoint" list (ie not mimic, nor passive)
I am working on providing a way to put a nonLinear relationship for mimic joints. With ROS standards, only mimicPos = multiplierfatherPos + offset and mimicVel = multiplierfatherVel is possible. I added an attribute nlFunPos (bad name, proposal accepted) in the
<mimic>
tag like this:Things that ROSEE uses that need to be updated
[x] joint_state_publisher (fork here) which we use to propagate position of actuated joints to their mimic joints, when using rviz only. (ROSEE correctly send commands to only actuated joints, not mimic ones). Easy to do, python code
sudo apt install python-numexpr
Also explain syntax for expression (like use ^ for power) October 2021 update : added this install in the rosendeffector package manager.[x] Move robot when looking for collisions. (branch nonLinear_moveit_col) For pinches, we use moveit and setRandomPosition() function, to then check for collisions. With moveit, each time a joint pos is updated, mimic joints are updated also (with the linear standard params). There is no way to not call the updateMimic method, because of private function. So I simply solved first calling the setRandomPosition(), and then overwriting the nonLinearMimic joint position with the correct relation. I used muparser to compute the equation, it seems nice
[x] Gazebo Plugin (fork here) We should need to fork the mimic joint gazebo plugin, and modify also this to consider the nonlinear relation.
Pull request for ROSEE here #59