I have a 7 DOF robot arm (urdf and USD) and want to start planning motion for it. I can already build the robot, load articulation, and controller to move it with a script. I want now to do something useful with it by tasking it to follow a pose in space.
I saw this tutorial about LULA, but it is expecting custom files that are not available for my robot, like the “motion_policy_configs” and “/franka/rmpflow/robot_descriptor.yaml”.
Is there a systematic way for users to generate those files for any robot arm? Please let me know.
If there is no way yet, I want to help implement it if it can be automated.
It may be good to have some community mentors for this forum. This will make good use of the community’s accumulated knowledge and not waste time on the same things. It looks like Isaac Sim’s extensive documentation makes it easy to get lost in many cases.
I found that the easiest way to start generating motions for our robots is by editing the provided RMPflow config files of similar morphology robots.
It is like a temporary fix, honestly. There should be a way to automate the supplementary robot description file generation for RMP config.
After adopting the Franka 7DOF RMPflow config files to my 7DOF robot, here is what I got. :D
I have done what the documentation suggests. Editing the provided config files for a similar morphology robot, and got a crazy robot. What should I change now?
NVidia made extensive documentation for Isaac Sim that lacks entry points for beginners. Showing impressive things does not make good documentation I learned to spawn a robot in Gazebo and make a basic motion in one session. In ADAMS, it was longer, but their written documentation was made for beginners. Despite their unfriendly software UI, their documentation took me from a beginner to making award-winning simulations.
Isaac Sim’s documentation needs to show how to deal with custom robots. Not every manipulator is Franka. Please find a way to get the community feedback and contributions. The learning curve for Isaac now is extreme.
Everyone, please be careful. My crazy robot may hit you.
The previous problem was partially due to links with zero or uncomputed masses. The robot can follow the target, but it goes crazy sometimes. Any help is appreciated, guys. Can the support team help, or someone who got their robot to move with RMPflow? Please try to help.
One reason may be the robot does not have collision objects when I visualize them. Are not they loaded from the URDF?
@Robotawi 2022.1.1 just went live today and we have a new set of tutorials for adding a new robot arm that will go live in a day or so. Will have someone follow up when they are available
As for encountering behavior where the robot goes out of control, this is likely a gains-tuning issue. When RMPflow sends joint targets to the robot Articulation, the motion of the robot is resolved by a PD controller. When the PD gains are not well tuned, it can create a negative feedback loop between RMPflow and the robot Articulation. Reference RMPflow Debugging Features to see how to decouple RMPflow from the simulated robot in order to correct your robot’s PD gains.
Are you referring to the robot Articulation having collision meshes in the Isaac Sim?
This will not impact the behavior of RMPflow or controlling the simulated robot.
Collision meshes can be imported by the URDF → USD converter. Check out the downloadable zip file in the RMPflow Tutorial Zip. It has a URDF file for Cobotta Pro 900 robot, which references visual and collision meshes that are also in the ZIP. Opening this URDF in the URDF → USD converter imports everything correctly. See in the image below that the resulting USD robot has a collision mesh listed under each link.
This new tutorial fulfills the requirement for having a robot arm imported and tuned for smooth motion planning. I figured out that the problem was the tuning and fixed it. The gain tuner tutorial is also excellent. It will make roboticist’s life easier. Thank you!
You can imagine that I got the robot working without using your new SingleManipulator class and configured the RMP files by comparing them to Franka’s and UR10 files. The new tutorial feels very familiar! 😂
In the new tutorial, I think it is worth mentioning that we can edit other joints and link properties when the USD is open (without being added as a reference to the stage). I found that auto-computed link masses can cause problems similar to out-of-control motions. It also makes sense to tell users they can decrease the drives Break Force, Break Torque, and Max force.
