kinova jaco2 robot model description .xml to use in RL library

[engr-zubair]

hi there, I am using kinova jaco-2, 7 D.O.F spherical wrist robot for my research work, and also using RL library in conjunction with vision ...if you can upload a model of kinova jaco2 7d..o.f robot xml description file...that will be so helpful .. I have tried to develop using the format and tutorial provided in RL website and also trying to develop from URDF model , but it was not successful yet. As lots of other people are also using this robot in research nowadays, it will be beneficial for all of us. thanks Zubair PhD scholar HIT university

[rickertm]

If you could point me to the correct CAD files and documentation, I'd be happy to include this model in RL.

The resources page of the manufacturer has several different models. I assume it's the one labeled "Gen2 7 DoF" with the Spherical - CAD Models geometry and this Product Spec Sheet?

[engr-zubair]

Yes, you got it right, this is the model I am working with. furthermore , this guidehttps://www.kinovarobotics.com/sites/default/files/UG-009_KINOVA_Gen2_Ultra_lightweight_robot_User_guide_EN_R02.pdf contains all other neccessary parameters DH frames and detail drawings of gen-2, 7 D.O.F spherical wrist jaco-2 robot. its name in ROS and moveit is j2s7s300. thanks for your help dear !

[rickertm]

I've looked into the CAD files and documentation and created a corresponding model. Due to some mismatches in the coordinate frames in the given examples and without access to the hardware, I may need your assistance to identify the correct kinematic configuration.

Page 46 gives the configuration [180°,180°,180°,180°,180°,180°,180°] as this

Page 59 shows the configuration [180°,240°,0°,60°,90°,90°,180°] including coordinate frames. With the given DH parameters and the above geometry reference, I can match the pose, but then frames T₅ and T₆ are different and the joint directions shown in the image at the bottom of the page are incorrect for joints 3 and 6.

The URDF model for j2s7s300 uses a different approach compared to the mentioned DH parameters and does not match these frames at all. It however results in the same pose given the above configurations and also does not match the joint directions of joints 3 and 6 on page 59.

With these DH parameters, the frames only match with a configuration of [180°,240°,0°,60°,−90°,−90°,180°] and slightly modified links 5 and 6.

This however also leads to a difference in the pose configuration [180°,180°,180°,180°,180°,180°,180°] as seen here

Changing the joint directions is not an issue, however I'd like to make sure the kinematic model matches the actual hardware.

[engr-zubair]

thanks for your detailed working and quick response. I can also see the problem in the model as you described , and I would love to provide the hardware support for this issue ,but unfortunately ,due to Covid -19 pandemic my lab is closed and i am working from home. I will provide you the pose attained by robotic arm in this configuration as soon as I get back to my lab. Meanwhile, if you can provide the raw xml description file for robotic arm ,so I can practice around and develop some code. Later on we can fix the model issue and you can release online in your library. thanks for your support.

[rickertm]

You can find my work-in-progress version here #2. Let me know if you find any issues or when you get a chance to verify this against the actual hardware.

[engr-zubair]

hi, I have tried the above model it is working good in most of the applications, however I am unable to use it in rlplan.demo tutorial as you have mentioned on robotic library robotic library . i have changed the scenario.sg file and 'robot.rlmdl' robotic arm description files and 3D model files with kinova-jaco-2 robot description by adding 'q' angle for joint 7. but the demo application is not working ,without giving any error. can you please tell the procedure to run this rl-plan-demo with kinova robot. thanks.

[engr-zubair]

@rickertm screen shot of folder for kinova robot rl-plan-demo , running rl-plan demo from bin and passing arg file scenario.rlplan. (not uploading ..some error this time) send you later

[rickertm]

I've added an optimized convex geometry of the Kinova in f782d0e26d5251ebf799cddf4df16de766f1aca0, please use this for collision detection. I also added a simple path planning example for the Kinova arm in 0a2a69676682139096586ff4fb265d2ec41c189a.

[engr-zubair]

thanks @rickertm , for your help, I have implemented successfully rlplandemo for kinova robot using above files. i have simulated same environment as was in demo and it is successfully implemented plan prm and rrt con for kinova robot. now, can you guide me how I can use this output trajectory for real robotic arm for the same rlplan demo. ?

[engr-zubair]

hi there, @rickertm , i really appreciate your time and effort , kindly guide me further how to implement this path trajectory in rlplan demo to real robot... which variable has the path trajectory joint velocities in rl-plan demo files? thanks

[rickertm]

The result from a planning algorithm is a path of joint configurations. You can access a std::list of these vectors via the planner's getPath() function. In order to execute the solution path on your robot, you will have to transform the path into a trajectory that fulfills the requirements of your hardware, i.e., maximum velocity/acceleration/jerk. This is either done by the robot controller itself or by creating a suitable interpolation function with derivatives for velocities etc. that can be sampled at the command intervals.

To precisely follow the path at all points, you would however have to stop at each waypoint. Common alternatives to this include blending at waypoints or cubic splines, but these may deviate more or less from the solution path. You can either use a safety margin to compensate for this or check this trajectory against collisions, while updating it accordingly.

For creating a trajectory interpolation function, you can use the polynomial and spline functions in rl::math. rl::math::Spline::TrapezoidalAccelerationAtRest allows specifying a trajectory between two configurations with a specified maximum velocity, acceleration, and jerk. For multiple configurations, you can for instance use rl::math::Spline::LinearParabolic or rl::math::Spline::CubicFirst, however these currently require specifying time intervals rather than kinematic constraints.

[engr-zubair]

I've looked into the CAD files and documentation and created a corresponding model. Due to some mismatches in the coordinate frames in the given examples and without access to the hardware, I may need your assistance to identify the correct kinematic configuration.

Page 46 gives the configuration [180°,180°,180°,180°,180°,180°,180°] as this

Page 59 shows the configuration [180°,240°,0°,60°,90°,90°,180°] including coordinate frames. With the given DH parameters and the above geometry reference, I can match the pose, but then frames T5 and T6 are different and the joint directions shown in the image at the bottom of the page are incorrect for joints 3 and 6.

The URDF model for j2s7s300 uses a different approach compared to the mentioned DH parameters and does not match these frames at all. It however results in the same pose given the above configurations and also does not match the joint directions of joints 3 and 6 on page 59.

With these DH parameters, the frames only match with a configuration of [180°,240°,0°,60°,−90°,−90°,180°] and slightly modified links 5 and 6.

This however also leads to a difference in the pose configuration [180°,180°,180°,180°,180°,180°,180°] as seen here

Changing the joint directions is not an issue, however I'd like to make sure the kinematic model matches the actual hardware.

dear @rickertm

concerning your question rgd this pose and orientation problem arising from model making from dh parameters and frame assignment , the lab is recently re-opened after covid pandemic and i arrnged these actual pose of robotic arm on required joint angles , please refere below images for pose 1 : 180,180,180,180 ,180,180,180 and pose -2 : Pose-2:  [180°,240°,0°,60°,−90°,−90°,180°]

[engr-zubair]

pose 1 : 180,180,180,180 ,180,180,180 Pose-2: [180°,240°,0°,60°,−90°,−90°,180°]

[engr-zubair]

there is an error in website provided ref manual as there is no such pose as [180,240,0,60,90,90,180] near the picture shown in manual, only configuration pose [ 180,240,0,60,-9-,-90,180 ] is there with change in end effector direction as shown in above real manipulator pictures. Sorry for the late reply about this issue as the lab was closed due to pandemic, Now i would be grateful if you could you please make the desired changes in rl-lib -kinova robot model files accordingly thanks .

[rickertm]

Thank you for providing the pictures of the actual hardware with given configurations. I'll have a look and try to update the models accordingly.

[rickertm]

I did a first comparison of your pictures, the documentation, and the model. Could you please confirm, that the sixth joint in your second pose is indeed set to -90°? With +90° for this joint, the model would match the pictures. According to the manual, the lower/upper limits for this joint are [65°, 295°], this is also what the URDF description is using. Or is this maybe a special setting in your robot setup?

[engr-zubair]

hi, yes you are right the pose used for 2nd second pose is   Pose-2:  [180°,240°,0°,60°,−90°,−90°,180°] , and leading joint six to +90 will lead to pose as shown in your rl-model.   Pose-2 corrected to match rl-model :  [180°,240°,0°,60°,−90°,90°,180°] the joint limits you are referring are for software control using API , i have attained that−90° pose-2 with joint controller using joystick, so it does not implied joint limit, may be while using software it will not allow to to move gripper beyond 65deg, as it will collide with the robot arm body itself. so the true achievable pose is Pose-2 Corr: [180°,240°,0°,60°,−90°,90°,180°] (matched rl-model :)

2- please also confirm me , calculating jacobian with rl-mdl file you provided uses DH parameters of robot ? or the jacobian computed through rl lib is based on rl-robot model ? because the jac i calculated given input set of joint angles is not matching with robotic arm real jacobian computed in its API .? is there any relation between correction of model and calculation of jacobian? or the jacobian only depends on dh parameters .

[engr-zubair]

update on pose-2, using pose -3 : 180,240,0,60,90,90,180 will cause the following behavior on robotic arm in real and shown the same config from manual in comparison

[engr-zubair]

and joint directions are anti clockwise for joint-4 as shown in above picture , i.e opposite to shown in manual , as when i turn joint 4 from 60 to 90 deg it moves anticlockwise to the desired position opposite to manual.

[engr-zubair]

the pose shown in manual can be achieved on real robotic arm by pose 3: 180,240,0,90,90,90,180

[engr-zubair]

there are some problems with the controller in different setups like windows ros and api centre ..but after checking from all and refreshing robot to hard home i got the following pose   Pose-2:  [180°,240°,0°,60°,90°,65°,180°] in all 3 setups. consider this final pose for kinematic modelling in rl-lib model. and the first pose picture straight upwards 180,180 all 180.

[rickertm]

Thank you for your comparison with the actual hardware and explaining the difference in joint limits when using the joystick.

I modeled the current model to match the DH parameters in the documentation and the URDF description in Kinova's ROS package. rl::kin directly uses DH parameters (classical notation according to Richard Paul) for its model, so you can find values directly matching those on page 58 of the documentation in rlkin/kinova-gen2-7dof.xml (node <dh> inside each <revolute> node). This notation expects a rotation around the positive z axis. The rotation directions shown in the lower right picture on page 59 however deviate from this in the third joint ("joint2" in the rl::kin model file) that uses negative z, while Kinova's ROS model matches the rl::kin model's positive z rotation. The current rl::mdl description is modeled to match the rl::kin description.

All three models (rl::kin, rl::mdl, URDF) match your latest pictures for Pose 2 [180°,240°,0°,60°,90°,65°,180°] and Pose 3 [180°,180°,180°,180°,180°,180°,180°]. As Kinova's URDF description matches the positive z rotation direction of the classical DH notation, I assume that this is the correct one while the arrow in the image of the documentation seems to be incorrect. Maybe you can verify this also with your hardware in each control mode?

The robot's Jacobian matrix depends on the current joint configuration, its full notation is J(q). Its values also depend on the chosen base and tool reference frames. If there's a mismatch with the one provided by the API, could you please provide an example of the Jacobian matrix for a few poses?

[engr-zubair]

thanks, i got it, i am working on implementing rl-mdl jacobian on real jaco-2 robot , can you please tell me how to calculate a jacobian in end effector frame . kinematics->setPosition(j); // j joint angles in radians kinematics->forwardPosition(); kinematics->update(); rl::math::Transform t = kinematics->getOperationalPosition(0); kinematics->calculateJacobian(); // modify model // calculates jac in tool frame or world frame ?? // const rl::math::Matrix& jac = kinematics->getJacobian();

what is bool inworld frame and how to switch it true or false in code //

[rickertm]

In order to calculate the Jacobian with rl::mdl, you first have to set the current joint configuration via setPosition(). If you want to transform the Jacobian to the world (root/base) frame of your model, you then have to update the operational frames of the model via forwardPosition(), otherwise you can skip this step. The Jacobian can then be calculated via calculateJacobian(inWorldFrame), where the inWorldFrame parameter is used to specify if the Jacobian should be transformed to world frame (default=true) or is calculated in the end-effector frame (false).

kinematics->setPosition(q);
kinematics->forwardPosition(); // for inWorldFrame=true
kinematics->calculateJacobian();
const rl::math::Matrix& jacobian = kinematics->getJacobian();

[engr-zubair]

hi @rickertm , hope you are well, i have tried this model in rl lib for generating end effector jacobian for jaco-2 7 dof robot, but validating on robotic arm i found that , the eJe we get from rl lib kinova7dof model has to be multiplied or transform by a matrix for actual robot jacobian EJe = T. eje T = 6x6 matrix with all zero and diag elements as [ -1 -1 1 -1 -1 1 ] which implies that the x , y axes for robots needs to be changed by 180 deg / pi rads, it can also be seen in manual

[engr-zubair]

above ref manual page 58 , this placing of robot is important and creates difference in position of end effector and in turn end eff jacobian of rob.arm also this happens when i use the conventional methods to calculate jacobian , but when i add 180 deg to the initial joint angle in conventional methods the robotic arm actual and calculated positions matches. still for your purpose i have tried in different end eff jacobian applications , that the real ee jacobian for robotic arm can be obtained using the above mentioned transform matrix , which is related to changing the x, y axes of robotic arm by 180 deg. now can we integrate this transform in the model while defining the joint 1 base joint position w.r.t robot base frame.?? thanks.

[rickertm]

This relates back to my earlier comment regarding the last three frames of the model. The image in the documentation on page 59 deviates from the frames defined by the classical DH model. For the end-effector Jacobian however, only the last frame is important. If frame 7 in the image correctly matches the real robot, then the end-effector frame can simply be rotated by updating the z value of the rotation in fixed12 to 180°: https://github.com/roboticslibrary/rl-examples/blob/0a2a69676682139096586ff4fb265d2ec41c189a/rlmdl/kinova-gen2-7dof.xml#L352

You should be able to check the end-effector frame on the real robot by using the joystick control to move relative in the end-effector frame (not in base frame). In the [180°,240°,0°,60°,90°,90°,180°] configuration and from this perspective, the robot should move up for positive y, right for positive x, and toward you for positive z.

The offsets in Table 32 in the manual are already present in the model, as is the transformation from BASE to 0 axis system as shown in page 59:

Q1 https://github.com/roboticslibrary/rl-examples/blob/0a2a69676682139096586ff4fb265d2ec41c189a/rlmdl/kinova-gen2-7dof.xml#L104 Q6 https://github.com/roboticslibrary/rl-examples/blob/0a2a69676682139096586ff4fb265d2ec41c189a/rlmdl/kinova-gen2-7dof.xml#L322 BASE to 0 axis system https://github.com/roboticslibrary/rl-examples/blob/0a2a69676682139096586ff4fb265d2ec41c189a/rlmdl/kinova-gen2-7dof.xml#L72-L81

[424358225]

老铁666,您知道怎么自己生成rlmdl的xml运动学的描述文件吗?用的小众机器人,不知道怎么改rlmdl

[engr-zubair]

请访问 rl 库教程的网站， 这是解释如何使自己的 rlmdl 文件为任何机器人。 https://www.roboticslibrary.org/tutorials/