Closed Celinna closed 1 year ago
Hello @Celinna
Sorry for the late reply as I was away last week.
I think the best approach here is to use a canonical module, this will allow you to fully exclude your gripper joints from the optimization problem (the joint selection only achieve this at a task level).
An example is provided via JVRC1
You should provide two robot modules:
This will ensure that the gripper values are only handled by the generic_gripper code
Note 1: I'm not sure I fully understood your issue, normally since https://github.com/jrl-umi3218/mc_rtc/pull/365 the alphaOut will have correct values for the grippers based on the generic_gripper.cpp control, however the values at the control model level might still be off in closed loop indeed
Note 2: if you are using a custom interface to your actual robot/simulation, make sure to use the GlobalController::robot()
/GlobalController::controller().outputRobot()
accessor rather than GlobalController::controller().robot()
since the former is a view to the canonical model while the later is a view to the control model
Hi @Celinna
I'm going to close this for now. Feel free to re-open with more details if you are still having some issues.
Hi,
We are using robots with generic grippers that are represented as revolute joints. We noticed that during closed loop control with mc_solver::FeedbackType::Joints the alpha_out values for the corresponding gripper joints are constant even though alpha_in is zero. Since the constant velocity, the q_out values are also increasing over time until over-written by the code from
generic_gripper.cpp
. This behavior persists even when the gripper joints are set as unactive per the tutorial.The problem is not present for any of the continuous joints or when we set the grippers to continuous joints. Is there a way to ensure that q_out and q_alpha values are updated based on feedback instead of the seemingly random output values for revolute joints? Perhaps there was a key setting that I missed?