Trajectory Post Processing Methods
Question:
I am trying to understand my planning pipeline and what components generate and affect the motion plan result, which is the recorded path of the real robot.
Environment:
Planning motions for a 6 dof industrial robot arm using OMPL and MoveIt! default settings. I am using industrial_robot_simulator to simulate the movement of my robot.
Details:
When I plot generated trajectory vs. real executed path, you can clearly see interpolation at corners. I believe this is the result of the industrial_robot_simulator. I am not sure where planning adapters like time parameterization come into play here. Is the trajectory time-parameterized before it gets passed into the robot simulator? While it does have a "time from start", the points do not appear to be uniformly sampled.
IIRC (it's been a while), the
industrial_robot_simulator(IRS) does not perform the smoothing you seem to be describing. The code is here, it's not too complicated.You write "recorded path of the real robot", but then you mention the IRS, which is still not an actual real robot.
If you are seeing smoothing with actual real hw, then it would most likely be the controller executing your trajectory (ie: the industrial controller) that smooths it. As you already noticed in #q334069, trajectories do not always exhibit the correct level of continuity, so (industrial) robot controllers need to do some post-processing themselves (or pre-processing, depending on how you look at it) before executing them.
If you can provide some more details on your actual hw, I may be able to point you to some literature.
Oh, and:
yes. As one of the last steps in MoveIt's planning pipeline, the trajectory (which is really more a path up till that point) is time parameterised. See here for all the default planning adapters applied by the planning pipeline.
I simulate robot movement by launching my simulation setup with
A reproducable, extreme example would be to plan a cartesian triangular shaped trajectory with three waypoints in a plane. While the trajectory points at corners make an instantaneous 90° direction change turn, the recorded and with FK transformed /joint_state messages show a curved corner interpolation. I assumed this to be a result of the
industrial_robot_simulator?How did you "plan a cartesian triangular shaped trajectory with three waypoints in a plane"? Using MoveIt's
computerCartesianPath(..), or stitching together three OMPL motion requests? The former should result in straight paths (provided sufficient resolution and bar any interpolation by the controller (in real hw)). The latter will most likely not.I used
computeCartesianPath()to ensure I get a 90° kink in the trajectory message. I then assigned this trajectory to a plan and executed the plan under thesim:=truelaunch file as described earlier. For this reason, since I am not using real hw, I can only see the /joint_states that the industrial_robot_simulator publishes. Using FK and plotting these points over the trajectory line, I see that the "real" robot branches out of the straight line before the kink to impose a radius, rather than an instantaneous switch in direction. I tested this witheef_step = 0.005and0.01.