Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Physical robot position and RoboDK disagree - Causes crash

#1
I have a Meca500 and I'm programming with the python api.

When I run with RUNMODE_RUN_ROBOT the position of the robot in robodk is different than the physical position of the robot.  The difference seems to be equal to the "Tool Frame with respect to robot flange".  I suspect the issue is that robodk is interpreting MoveL taking into account the TRF while its not getting set before running on the robot it self.  

Interestingly, when I generate a program instead by setting RUNMODE_MAKE_ROBOTPROG it does emit a
Code:
   robot.Run('SetTRF', [16.000, 0.000, 46.000, -0.000, 0.000, -0.000])

before sending linear moves. 

my program consists of one moveL.  When it runs the screen shots below show both robodk and the meca500 web interface show the robot at the same coordinates but the joint angles disagree. 

Code:
  p = Pose( 200.0, 0.0, 210.0, 0.0, 90.0, 0.0)
  robot.MoveL(p)

   
   
#2
Any input for the Robodk team?
#3
Hi Chris,

I'm sorry to hear you had a crash with your Mecademic robot. This issue can happen if you run a program without setting the tool. In this case it will use the robot's TCP definition (they one you probably see in your web interface).

Make sure to add the instructions specifying the tool and the reference at the beginning of your program (this is done by default).
 
Albert
#4
I haven't changed any defaults. Which instruction are you referring too?

Also if that was missing shouldn't it be reflected in the simulator?

why would the run-on-robot and the make robot program do different things?!
#5
When you add robot movements in a program you'll see that it links to the reference frame and tool frame you are currently using:
   

These 2 instructions are important to make the robot aware about your TCP and Reference.

If you don't set them it will be up to the robot settings to choose the right tool and coordinate system.

The run on robot option resets the tool to the flange, however, if you change it later it will change the robot movements.
#6
what is the equivalent in the python API?
And again does that explain why the pose in robodk is different from the pose on the actual robot? If so is that proper behavior for a simulator?
#7
The equivalent in the Python API would be:
  • setPoseFrame to set the reference
  • setPoseTool to set the tool (TCP)
It is important to set the base and tool to make sure the robot uses the same setup you have in RoboDK.

When you move the robot to Cartesian targets from Python you should also update the tool and the reference:
Code:
robot.setPoseFrame(robot.PoseFrame())
robot.setPoseTool(robot.PoseTool())

This may look redundant but it forces an update on the real robot controller.

A more complete example here:
https://robodk.com/doc/en/PythonAPI/exam...rogramming
#8
This seems to be working intermittently.

Yesterday this worked

Code:
    RDK.setRunMode(robolink.RUNMODE_RUN_ROBOT)
    robot.setPoseFrame(robot.PoseFrame())
    robot.setPoseTool(robot.PoseTool())
    robot.RunInstruction("GripperOpen", robolink.INSTRUCTION_CALL_PROGRAM)
#... MoveL here


This morning it didn't but this worked
 
Code:
   RDK.setRunMode(robolink.RUNMODE_RUN_ROBOT)
    robot.RunInstruction("GripperOpen", robolink.INSTRUCTION_CALL_PROGRAM)
    robot.setPoseFrame(robot.PoseFrame())
    robot.setPoseTool(robot.PoseTool())
#MoveL here
  




Users browsing this thread:
1 Guest(s)