search

plusone-robotics / moveit_simple

A wrapper around MoveIt that enables more traditional industrial robot programming.
Apache License 2.0
15 stars 12 forks source link

Path timing constraints and interpolation #6

Open shaun-edwards opened 7 years ago

shaun-edwards commented 7 years ago

The current interface allows uses to define the time at which a trajectory point is achieved. The current execute method makes no determination about whether the desired path timing is achievable. It simply sends the path down to the controller as is. As a start, the execute method should reject paths that aren't physically possible (assuming some n-th order path constraint). A more complex implementation could be used for better interpolation between points (possibly related to #5).

shaun-edwards commented 7 years ago

@geoffreychiou, could you take a look at this. Perhaps @BrettHemes could chime in. I know he has taken a look at several interpolation/path timing methods.

BrettHemes commented 7 years ago

In general there are lots of different approaches to this depending on the desired result. @shaun-edwards, what is the envisioned scope of this library? Ultimately do you see it providing all of the functionality that an industrial controller offers?

shaun-edwards commented 7 years ago

@BrettHemes, this library will make it as "easy" to program a robot from ROS as it is from the teach pendant/robot programming language. While the paths will be more constrained than a MoveIt goal, we will be able to leverage ROS/MoveIt capabilities like better planning and collision checking.

I'm focusing a lot on motion, but I can imagine including IO handling as well.

BrettHemes commented 7 years ago

I like this idea in general. MoveIt! seems biased towards fast-as-possible joint-space motions and could benefit from some straightforward industrial-like motion interfaces.

So like MoveLin/Circ etc. then with some constant (max) Cartesian velocity? I have a quick and dirty implementation of MoveLin using trapezoidal acceleration and SLERP while obeying joint limits. It is nothing special but works for what I needed it for... I could look into sharing if you are interested (or at the very least I could dig up the reference to the algorithm it is based on). Additionally, I think the Traclabs guys have something similar as part of CRAFTSMAN as well but would have to double check.

shaun-edwards commented 7 years ago

A related discussion in Move it. https://github.com/ros-planning/moveit/issues/160

shaun-edwards commented 7 years ago

A related issue in Descartes: https://github.com/ros-industrial-consortium/descartes/pull/197

shaun-edwards commented 7 years ago

I think this issues/lack of feature is the root cause of the work around in PR #12

henningkayser commented 5 years ago

Hi @shaun-edwards, MoveIt is designed to be used with the full planning pipeline which includes a time parameterization step for applying the configured velocity and acceleration limits (from urdf or config). All trajectories that are being passed to the execution manager should have been parameterized with valid limits. The execution manager doesn't validate the times or checks for physical limits just as your implementation. But this would maybe be a job for the controller handle (since not only the timestamps but also velocity and acceleration values should be verified depending on the controller). But this should really only be necessary if we don't trust the settings for velocity/acceleration or try to run unparameterized trajectories.

A trajectory validation function that uses the configured limits could be implemented by simply iterating the states of a RobotTrajectory check the results of RobotState::satisfiesBounds() and RobotState::isValidVelocityMove(). These checks can be implemented accordingly for generic joint state values.

There are currently three different time parameterization methods available that could be used for fixing trajectory time profiles. Lately we added a new trajectory generation method that computes trapezoidal velocities by interpolating points from the target waypoints (https://github.com/ros-planning/moveit/pull/1365). Does this match your expectation of a more complex implementation?

(Edited after code review)

shaun-edwards commented 5 years ago

All trajectories that are being passed to the execution manager should have been parameterized with valid limits.

I think this is correct, but not what we are currently doing in moveit_simple (hence the issue). moveit_simple specifies a trajectory with waypoints and timestamps. Even if we populate the velocity/acceleration, it is still possible that the resulting trajectory (once translated to joint points) is not possible. In the case where the trajectory is not possible,moveit_simple would either (depending on a function argument) slow down the motion until it is executable OR fail.

henningkayser commented 5 years ago

All right, this seems straight forward to me so just a quick rundown: We read the physical acceleration and velocity limits from the urdf (or desired limits from parameters) and validate the waypoints. If not successful execute() fails by default or optionally recomputes the timings using the loaded limits. I would use the mentioned robot state functions satisfiesBounds() and isValidVelocityMove() as reference for the test and apply the Time-optimal Trajectory Generation method for time parameterization.