search

CEAD-group / py-opw-kinematics

Python bindings for a Rust implementation of inverse and forward kinematic solutions for six-axis industrial robots with a parallel base and spherical wrist.
MIT License
2 stars 0 forks source link

[Feature] Add cartesian path simluation #19

Open tdamsma opened 1 month ago

tdamsma commented 1 month ago

To properly simulate traversing a cartesian path, the angles for the robot should be simulated at regular intervals (related to the size of the robot, e.g. 1-10cm). Otherwise computing the angles might completely miss the singularities on the way. This could be achieved by evaluating the inverse kinematics at a set interval. A more optimised algortihm might look for singularities and refine the distance only when appropriate. But I don't think that added complexity would be worth it.

bourumir-wyngs commented 1 month ago

rs-opw-kinematics is supposed to be singularity-free for usual OPW robots (cases when last and pre-last links are axis-aligned are all covered).

You only need to care not to start the first pose from a singularity, which would be a rare yet unlucky case. In this case, the algorithm will propose some angles for joints that can freely rotate, but these angles will be far from the angles in the following position, resulting in a jerk at the beginning of the path, probably strong enough to stop the robot by triggering overspeed protection.

Also, if there are multiple joint configurations to start the Cartesian stroke, only one of them may be good enough to finish it without significant changes in joint configurations somewhere in the middle of the path. This is especially true if also constraints apply.

tdamsma commented 1 month ago

The key issue I am trying to solve is simulating a robot controller that allows cartesian movements (a straight path with smoothly interpolated (slerp) angle changes). rs-opw-kinematics allows simulating point-to-point transitions. As long as the path does not go near singularities and the total joint angle change is limited, there is no difference in the final joint angles if only the final pose is evaluated with the start angles or when a straight line is simulated.

I am thinking if there is a way to guarantee the final joint angles are equal to a cartesian path simulation by (dynamically?) evaluating the joint angles at intermediate steps along the way.