Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
CNC 5 Axis program doesn't return error for invalid pose
#1
When generating a program using the C++ API for the Reis RL130P CNC, if the requested pose is not reachable, the api still return a joint position.  When using a Robot like a Staubli TX-90, an invalid joint is returned usually when a position is not reachable.

This is quite dangerous as there is no way to tell that there is an error for a 5 axis CNC.

I have attached 2 images, one showing the wanted path generated using RoboDK API (valid path.png) and one showing the result of a not reachable targets (invalid path.png) with no error returned from RoboDK C++ API.

I also attached a station with program and targets for both case.

I am using the latest version of the C++ api as well as the latest version of RoboDK available for download on april 4 (v5.4.1.22034)


Attached Files Thumbnail(s)
       

.rdk   cnc-5axis.rdk (Size: 139.22 KB / Downloads: 73)
#2
In the Python API, You can use MoveL_Test() or MoveJ_Test() which returns 0 if the movement is free of collision or any other issues. If the robot can not reach the target pose it returns -2. If the robot can reach the target but it can not make a linear movement it returns -1.

Would a C++ implementation of this methods solve your problem?
#3
(04-04-2022, 09:47 PM)Alex Wrote: In the Python API, You can use MoveL_Test() or MoveJ_Test() which returns 0 if the movement is free of collision or any other issues. If the robot can not reach the target pose it returns -2. If the robot can reach the target but it can not make a linear movement it returns -1.

Would a C++ implementation of this methods solve your problem?

I am using SolveIK() with the robot item, this should return an invalid tJoints in case no movement is possible (RoboDK_API::tJoints::Valid()==false), here is the from the C++ doc itself:
Quote:/// \brief Check if the joints are valid. For example, when we request the Inverse kinematics and there is no solution the joints will not be valid.
   /// (for example, an invalid result after calling class: IItem::SolveIK returns a non valid joints)
   /// \return true if it has 1 degree of freedom or more
   bool Valid() const;

So this method is clearly not returning the expected result in case of CNC 5 Axis machine (note: we use SolveIK for other machine without issue (invalid pose are correctly reported) ).

I will try what you suggested and report what result.

Thanks,
Francois.

Hello Alex,
I have tested MoveJ_Test and MoveL_Test but it doesn't help, all moves are valid.
But when you think about it, it make sense that it wouldn't return any error since the joints position I am using is the one returned from the SolveIK(), and since SolveIK() return a joints position that the robot can reach (even if the joint position is not a good one, ie the joint position is far from the requested pose), testing using that joint will succeed.

So the problem still lies in SolveIK() not returning an error as it should for CNC 5 Axis machine.

Thanks,
Francois.
#4
SolveIK may returns valid joints for 5 axis CNC mechanisms when one or more joints are out of limits. We'll try to improve this in a timely manner.

For the time being, you can check if the joints are valid by checking if the returned joints are within your desired joint range.
#5
(04-06-2022, 08:34 AM)Albert Wrote: SolveIK may returns valid joints for 5 axis CNC mechanisms when one or more joints are out of limits. We'll try to improve this in a timely manner.

For the time being, you can check if the joints are valid by checking if the returned joints are within your desired joint range.

That's the point, the joints returned are valid and are not out of limits of the 5 axis CNC mechanism, there are just not at the requested pose: check any moveJ from the attached rdk station and you will see.

I guess I will have to double check the return joint position from SolveIK using SolveFK, and then compare the pose from SolveIK with the one I initialy requested until the bug is fixed.

Best regards,
François.
  




Users browsing this thread:
1 Guest(s)