kevinzakka / mink

Python inverse kinematics based on MuJoCo
https://kevinzakka.github.io/mink/
Apache License 2.0
234 stars 9 forks source link

Add the combination of Mobile Kinova + Leap Hand setup #26

Closed Zi-ang-Cao closed 1 week ago

Zi-ang-Cao commented 1 week ago

On the top of Stanford Tidybot equipped with 2F85 Robotiq gripper, I provide a modular MJCF description of Mobile Kinova robot, enabling seamless swapping of end-effectors.

Please note the nested class naming convention in the tidybot.xml file. For compatibility, this convention has been removed in the mobile_kinova.xml file.

Additionally, I marry the Leap Hand with the Mobile Kinova platform in the example script mobile_kinova_leap.py. This script also include updated recommendations for controlling the mobile base, aiming to minimize unnecessary rotation.

Screenshot 2024-09-07 at 3 26 15 PM

Zi-ang-Cao commented 1 week ago

Updated the CHANGELOG.md for the combination of Mobile Kinova + Leap Hand setup.

kevinzakka commented 1 week ago

Thank you for the awesome contribution @Zi-ang-Cao!

kevinzakka commented 1 week ago

@Zi-ang-Cao How is mobile_tidybot.py different than the newly added mobile_kinova.py btw? And what do you mean by: "This script also include updated recommendations for controlling the mobile base, aiming to minimize unnecessary rotation."?

Zi-ang-Cao commented 1 week ago

@kevinzakka Thanks for merging my contribution to your awesome repository! The followings are the response to your questions.

How is mobile_tidybot.py different than the newly added mobile_kinova.py btw?

  1. The mobile_tidybot.py script represents a full robot setup, which includes the mobile base, Kinova arm, and 2F85 Robotiq gripper. This robot is loaded from the tidybot.xml file, which originally used a nested class naming convention for the robot components. While the default 2F85 Robotiq gripper can be replaced with more dexterous hands, like the Leap Hand, the nested class naming convention complicates the end-effectors swapping procedure. To address this, I removed the nested convention in the mobile_kinova.xml file, which is used by mobile_kinova.py.

  2. mobile_kinova.py is designed for more general use cases. In real-world experiments, the arm and end-effector are often controlled separately. Typically, we focus on solving inverse kinematics (IK) for the arm, while the gripper or dexterous hand is controlled through joint mapping or a separate IK process relative to the wrist. For complex systems like a mobile Kinova with a LEAP hand, excluding the dexterous end-effector from the model can significantly speed up IK computation, enabling more efficient compliant control for the arm. Therefore, in real-world scenarios with mobile manipulators, mobile_kinova.py may be a better starting point due to this optimization.

"This script also includes updated recommendations for controlling the mobile base, aiming to minimize unnecessary rotation."

  1. Regarding the above statement, it primarily refers to how posture_cost and immobile_base_cost are designed. In the most case, we want the mobile base to move freely in the xy-plane to extend the manipulator’s workspace, so the posture_cost for xy-plane motion should be set to zero. However, rotating the base is generally discouraged, as it tends to be less accurate compared to using the arm’s first joint. Excessive rotation also complicates collision avoidance in crowded environments. Based on these real-world considerations, the posture_cost for rotation is set non-zero, discouraging unnecessary base rotation. On the opposite, when enter the fix_base mode by pressing return, allow the mobile base to rotate in place will slightly extend the limited workspace and alleviate the singularity issue. For the truly immobile setup, we should directly remove the joints of the base from the model, instead of using a damping task.

For a clearer visualization, try quickly rotate the target object around the Z-axis by a large degree and then fix the target pose, in the default mobile base setup. You’ll notice that in mobile_tidybot.py, the robot tends to rotate the mobile base excessively to face the target, and then slowly spins the base back, resulting in undesired additional motion. In contrast, the mobile base in mobile_kinova.py basically maintains its forward orientation and stops unnecessary motion once the goal pose is reached.

kevinzakka commented 1 week ago

Gotcha, thanks for the detailed answer @Zi-ang-Cao. In hindsight, I think we should have just merged your change with my tidybot example directly and had the separate example with the leap hand, but it is what it is :)