[cathylee6905]

I am currently encountering an issue with Cartesian coordinates synchronizing between RoboDK and TM Flow in my robotic setup. Specifically, I am focusing on aligning the reference frames of the RoboDK simulator with those of the real robot.

In my RoboDKApi script, the process involves setting the Tool Center Point (TCP) and reference frame, followed by a movement of 150mm along the Z-axis with a rotation of -180 degrees using the designated TCP and reference frame. The simulation in RoboDK appears as expected, showing the position {0, 0, 150, -180, 0, 0} after the movement (as depicted in the left image "150_Program_MoveL").

Here is a snippet of the C# code for the RoboDKApi:

Code:

var tool = Mat.FromTxyzRxyz({ -4.166, -149.685, 93.163, 0.000, 0.000, 0.000 }); // My TCP var frame = Mat.FromTxyzRxyz({ 3.261, 705.458, 1098.752, -0.155, 0.098, 0.018 }); // My Reference Frame robot.SetTool(tool); robot.SetPoseFrame(frame);

Mat Coord_X0Y0;

Coord_X0Y0 = Mat.FromTxyzRxyz(0.0, 0.0, 150.0, -180.0, 0.0, 0.0);

robot.MoveL(Coord_X0Y0);

However, when I transmit this MoveL command from RoboDK to TM Flow using Modbus, the real robot moves to a position with unexpected variations from the target position, as shown in the right image

"150_Real_MoveL" {-0.932, 1.082, 148.635, 179.883, -0.09, 0.152} with

joint values {105.510000, -2.360000, 127.470000, -34.850000, 90.080000, -164.660000}.

Upon inspecting the RoboDK log, I noted that the correct joint values for the MoveL command

{105.459460, -2.566570, 127.563420, -34.873580, 90.135770, -164.558550} are being sent for the
pose {0.0, 0.0, 150.0, -180.0, 0.0, 0.0}.


Next, I examined the TM Flow log. Since I primarily program the TM12 through RoboDK, interpreting the TM script in the log proved challenging. It would greatly help if someone could provide me with the software manual for these scripts, as I have been unable to locate them online. One line in the log,

Code:

$TMSCT,88,1,Line(\"CAP\",3.518,705.864,228.751,179.8450,0.0980,0.0177,100,0,5,true)\r\nQueueTag(2,0)\r\n,*25

appears to give a set of values close to my set reference but with some deviation from my specified reference {3.261, 705.458, 1098.752, -0.155, 0.098, 0.018}.



I seek guidance from experienced individuals proficient in using RoboDK for TM12 control to address these challenges. Additionally, I have a few questions:

How can I decipher the scripts' meaning in the TM Flow log? Is there any example code available to assist in modifying them?

I struggle to match the simulator's pose while attempting motion design using the "MoveL" command in RoboDK. In contrast, as expected, the "MoveJ" instruction works correctly for the real robot, but I require linear movement for my application. How is "linear movement" defined in TM Flow?

Many thanks,

Cathy

TMflow Version: 1.88.24

RoboDK version: v5.5.4

Model: TM12

[Albert]

When using the driver, RoboDK automatically calculates the coordinates of the TCP with respect to the robot base, not the active coordinate system (contrary to when you simulate or program robots using post processor). This is the default behavior.

However, you can change the default behavior and force outputting the target coordinates the same way the are set in RoboDK (TCP with respect to the active coordinate system) by following these steps:

1. Select Tools-Options
   
2. Select the Drivers tab
   
3. Check the option Provide Cartesian coordinates with respect to the reference (instead of the robot base)
   

Make sure to re-run your program from the beginning so the reference frame used is sent to the robot controller via the driver.

[cathylee6905]

Thanks Albert.

I conducted a quick test by activating the "Provide Cartesian coordinates concerning the reference (instead of the robot base)" option, but unfortunately, a new issue arose. See capture below

When this option is enabled, TM Flow halts with the robotic arm, accompanied by a warning stating "Robot Controller Function Library Issue" (TM Flow Log).

I am confident that there are no singularities in the robotic arm, as the "MoveL" instruction functions works normal on the real robot when the "Provide Cartesian coordinates with respect to the reference (instead of the robot base)" option is not activated.

As highlighted previously, the "MoveJ" instruction works accurately (within ±0.1mm) for the real robot, whereas discrepancies (>0.3mm error) persist for the "MoveL" command, as illustrated below:

Mat Coord_X0Y0;
Coord_X0Y0 = Mat.FromTxyzRxyz(0.0, 0.0, 150.0, -180.0, 0.0, 0.0);
robot.MoveJ(Coord_X0Y0); // Moves to a pose close to {0.0032, 0.009, 150.005, -179.998, 0.005, 0.0002}
robot.MoveL(Coord_X0Y0); // Moves to a pose around {-0.932, 1.082, 148.635, 179.883, -0.09, 0.152} with a significant (>0.3mm) error

For "MoveJ", the expected pose {0.00, 0.00, 150.00, -180.00, 0.00, 0.00} displays correctly in RoboDK before transmission to the real robot achieves an acceptable pose {0.0032, 0.009, 150.005, -179.998, 0.005, 0.0002}.

Conversely, for "MoveL", despite the expected pose alignment, the actual pose after the transmission is { -0.932, 1.082, 148.635, 179.883, -0.09, 0.152}.

The log messages from RoboDK and TM Flow during the execution of "MoveL" and "MoveJ" with the same pose are captured for reference.

Based on the validation from RoboDK logs that the accurate robot arm can correctly capture the reference frame and pose conversion from task space to joint space, the issue might not stem from activating the "Provide Cartesian coordinates concerning the reference (instead of the robot base)" option.

Returning to the "MoveL" dilemma and my earlier inquiries, the current understanding is as follows:
1. Reasonable joint values are transmitted from RoboDK for both MoveJ and MoveL instructions.
2. Interpretation of TM scripts from the TM Flow log remains challenging. I seek a software manual or example codes to enhance script comprehension and modification. Additionally, clarity on how "linear movement" is defined in TM Flow is necessary. The Line(\"CAP\",3.485,705.873,228.751,179.8471,0.0931,0.0158,100,0,5,true) segment in the log appears to correspond to the "MoveL" instruction.

The primary question is whether there are ways to adjust the Line("CAP",3.485,705.873,228.751,179.8471,0.0931,0.0158,100,0,5,true) command in TM Flow through RoboDK to enable the direct generation of linear movements with accurate poses on the real robot via the "MoveL" command in RoboDKApi.

Alternatively, a temporary solution involves appending MoveJ(Pose) commands following each MoveL(Pose) to ensure the robot reaches the correct target. However, this workaround results in program complexity and suboptimal motion behaviour.

Many Thanks,
Cathy

[cathylee6905]

Please let me know if there is any solution to this issue. Thank you.

[cathylee6905]

I am still waiting for a solution. How are the movement instructions possibly correct in the simulator but incorrect on the robot? This is a fundamental function that I expect RoboDK to perform accurately, and the issue is critical. Please assist with this matter promptly.

[Albert]

I'm sorry we didn't get back to you earlier. Did you calibrate your robot using RoboDK or any other software and then updated your table of DH parameters?

Can you share the RoboDK project file that you use to obtain the logs you shared? We'll take a deeper look.

[cathylee6905]

(1) I calibrated the robot using RoboDK. The TCP calibration is normal and matches my expected dimension of TCP.

For Reference frame calibration, a cal plate of about 50x50mm is used. After the "Define Reference Frame" with a real robotic arm to obtain frame "CalPinCNC_TM12Base," the frame centre is translated by about X25 and Y25 mm to get the "Cal Pin CNC_TM12Base_TranslateToCentre."

As the frame in my program is in the Project base, while I discovered that the "Define Reference Frame" of the Reference frame only supports the robotic arm base with a real robotic arm, I obtained the project base by plugging the X and Y values from "Cal Pin CNC_TM12Base_TranslateToCentre" to the "Cal Pin CNC_Project_Base."

For the Z value, as the workplace setting is not exactly the same as the simulator in reality. I discovered that though the "Define Reference Frame" X and Y values are incorrect for "Cal Pin CNC_Project_Base" in the project base, the z value is correct using the RoboDK "Define Reference Frame". Till this step, the X, Y and Z value of the calibrated with frame centre at mey desired location is obtained, the W, P, R of "Cal Pin CNC_Project_Base" is just the same as "CalPinCNC_TM12Base".

The accuracy of this frame is tested by program with the robotic arm using "MoveJ" instruction,
1. Set the Cal Tool and Cal Frame in the Program
2. Using a MoveJ instruction move to Pose {X=0.000 mm , Y=0.000 mm , Z=150.000 mm , Rx=-180.000 deg , Ry= 0.000 deg , Rz= 0.000 deg}
3. Stop the program
4. On the RoboDK side "Connection to TM12" Panel, Click "Command" >> "Get joints modbus" to obtain the exact joint values from Robot
5. On the TM Flow side, Capture the joint values and ensure they are equivalent to the target obtained on the RoboDK side.
6. Measure the distance between the Cal pin (TCP) and the Cal plate centre (frame)

Recall issues: MoveJ go to the correct position while MoveL does not see the comparison below


(2) What do you mean by updated the table of DH parameters?

The RoboDK project file and the driver are attached for your reference.

[Albert]

It looks like you didn't calibrate the robot with RoboDK.

It is important to note that TM robots have its own calibration performed and the kinematics may be unique for each robot. Therefore, unless you import the robot kinematics in the RoboDK DHM table, you'll see these small differences in the Cartesian space given the same joint values.

If you want to rely on the kinematics of the robot controller I recommend you to output movements using Cartesian values instead of joint values.

[cathylee6905]

It looks like you didn't calibrate the robot with RoboDK.

It is important to note that TM robots have its own calibration performed and the kinematics may be unique for each robot. Therefore, unless you import the robot kinematics in the RoboDK DHM table, you'll see these small differences in the Cartesian space given the same joint values.

If you want to rely on the kinematics of the robot controller I recommend you to output movements using Cartesian values instead of joint values.

Thanks Albert. I have taken note of two points from your response, but they do not sufficiently explain or resolve the issues.

1. Regarding your response, "you didn't calibrate the robot with RoboDK.":

I am currently following the documentation for Tool & Frame calibration from the link: https://robodk.com/doc/en/General.html#CalibrateTCP. Are you suggesting I add additional steps, such as importing the robot kinematics into RoboDK? Does this involve manually entering the DH Table parameters for the robot at a specific location in RoboDK? Does this mean that RoboDK or the TM12 Driver cannot automatically obtain the DH parameters from the robotic arm?

I noticed an option under "Robot Parameters" > "Kinematic parameters" called "Use Controller Kinematic". Is this the option for RoboDK to retrieve kinematics from the real robot? When I check the "Use Controller Kinematics" option, a message stating "Robot kinematic parameters have not been imported" appears. I looked for the procedure to update robot kinematics for UR Robots here https://robodk.com/doc/en/Robots-Univers...atics.html but couldn't find one for Techman robots. Please provide a method to import the DH parameters from a TM12 robot to RoboDK.

2. Regarding your response "output movements using Cartesian values instead of joint values":

In my previous post, I mentioned that I am already outputting movements using Cartesian values in the Pose {x, y, z, w, p, r} format (e.g., 0, 0, 150, -180, 0, 0), and RoboDK automatically converts these to joint values in the log.

If I have incorrect kinematics, I would expect both "MoveJ" and "MoveL" instructions to move the robot to a position with some variation. However, currently, the MoveJ (Pose) instruction moves the robot to the accurate task position with (<0.1mm) error, while MoveL (Pose) does not (>1mm error). Why do "MoveJ" and "MoveL" show different levels of accuracy when using the same Pose value?

Please correct any misunderstandings in my response. My primary objective is to move the robotic arm through linear movements (MoveL) and ensure the tool reaches a precise position with an error within 0.2mm.

Many thanks.