Motion Interface¶
Before going in-depth on how to use the Jacobi motion interface, let’s first define the used terminology, i.e., how the terms Motion, Planner and Trajectory relate to each other.
In Jacobi, the Motion classes represent a high-level description of how the user wants the robot to move. A Motion can encode the following: “I want the robot to move from point A to point B, while keeping the end-effector orientation constant. I want the robot to approach the goal linearly from the z direction for the last 5cm.”
The Planner takes the Motion and generates a Trajectory, which is a low-level description of the same movement that can be directly executed by the robot. As previously described here, Trajectory includes all information about the calculated joint positions, velocities, accelerations and their timings.
Our motion interface currently supports four different types of motions, each with its own pros and cons and intended use-cases. The following table gives a brief overview of the different motion types:
Motion type |
Description |
Limitations |
|---|---|---|
|
A general point-to-point motion with arbitrary waypoints, linear approach and retraction, and task constraints. |
Max. 3 intermediate waypoints. |
|
A singularity-free linear motion in Cartesian space between any two waypoints. |
Depending on the settings, a motion may not be exactly linear to avoid singularities. |
|
A motion that exactly follows Cartesian paths with a desired end-effector velocity. Can automatically compute piecewise linear paths with circular blends. |
Singularities may occur due to exact following. |
|
A motion between joint-space waypoints. Very fast to compute and allows for temporal constraints such as a minimum duration parameter. |
No collision checking. |
In the next tutorials, we will take a look at each of these motion types in more detail. We start with the Motion class, which is the most used motion type in Jacobi.