Using a different type of Cartesian Motion Planner

[MohammadKhan-3]

Running into this error when using MoveIt's Cartesian Motion Planner: [ERROR] [1648220633.617375544]: Validation failed: Missing velocity data for trajectory pt 0

Potential reasons:

• MoveIt Cartesian Interpolator has no time parametrization, so no control over velocity or acceleration and does not store the values.
• Additionally, PickNik, creators of MoveIt, say that MoveIt Cartesian Interpolator easily gets stuck in local minima as it does not provide any functionality for avoiding joint limits or restarting. Source: https://picknik.ai/cartesian%20planners/moveit/motion%20planning/2021/01/07/guide-to-cartesian-planners-in-moveit.html

Computer Environment:

• Ubuntu 20 LTS
• Noetic
• Python 3.7

Next Steps:

• Look into other Cartesian motion planners like Descartes, PILZ, Tesseract `

[acbuynak]

I'm working on implementing an pure C++ example of the Descartes Planner. My notes are here https://github.com/OSU-AIMS/paper-glider/issues/2, but I'll cross-post here if/when I get it working.

[acbuynak]

Out of curiosity, I dug into the Python API on the default move_group.compute_cartesian_path().

def compute_cartesian_path(self,
         waypoints,
         eef_step,
         jump_threshold,
         avoid_collisions=True,
         path_constraints=None )

Thus far, I don't think we've ever tried setting the path_collisions parameter. According to the C++ API, this parameter is an instance of a custom moveit_msg called Constraints. Msg format here.

Unfortunately, this message doesn't detail any time based info, but does allow tolerancing the positioning system. ie Applying a tolerance to joints or tool position/orientation. @hansen95 This may be useful for you on future projects.

[acbuynak]

One option to consider instead of pursuing an entirely separate planner would be to only grab the position data from the output path trajectory. Then write your own velocity/acceleration into the trajectory message and send that to the robot.

compute_cartesian_path() returns two variables: path and fraction. fraction is the 0-1 (0-100%) portion of the path that the solver generated. path is a moveit_msgs::RobotTrajectory message object containing a list of waypoints. Each waypoint has position, velocity, acceleration, and time_from_start information.

Basically, we could go in and overwrite the velocity, acceleration, and time_from_start data for each waypoint. Velocity and acceleration could be computed from a combination of the desired time to achieve, the position data, and a velocity scaling equation.

I don't think this is a great solution, but it would get you going. Further, you would be able to more finely generate a trajectory then issue additional commands.

Initially, I think we should be sending trajectories starting from each 'point' (or light-pixel) of the path to the next one and not one long continuous motion (I don't think this was your intention though). But I don't know how well this will transition to the continuous light-painting demo, but it would help get us moving.

[acbuynak]

Successfully deployed a basic demo using a Descartes DensePlanner to build a trajectory. This is a pure C++ implementation in the osu-aims/paper-glider repo.

[acbuynak]

Finished an ROS Action server implementation of a Descartes Cartesian planner which accepts an input goal pose and linear interpolates in Cartesian space from current to goal pose.

Applied in the /descartes-action-server branch.