# Trajectory generation for motor

I want to implement a s-curve trajectory generator for a motor controller, but I'm struggling with how it should behave to be useful. There are different papers out there with the implementation for s-curve generation, but none seems to take the time to the destination as input.

How I imagine a trajectory generator:

• Input: Pos_Dst, T_to_Dst, Pos_is, Vel_is, Acc_is, Vel_max, Acc_max, Jerk_max

• Output: Pos_ref

T_to_Dst (Time to destination) seems not to be taken into account in real generators, why? Is it hard to run it online? I think this might be really useful, since it uses the boundary conditions on Vel, Acc and Jerk only if necessary.

• What are: Pos_is, Vel_is, Acc_is? – Marko Buršič Sep 6 '19 at 6:47
• The Position, Velocity and Acceleration before the new strategy is calculated – HansPeterLoft Sep 6 '19 at 7:06
• Note that this is the part of traj, planner itself and it can't be an input parameter, it's rather a static type residing in the planner instance memory. – Marko Buršič Sep 6 '19 at 7:28

The trajectory planner calculates incrementally (recursive). Each cycle (sample time) it calculates next point, so it never knows the time needed for the travel.

To know that, the generator should calculate the entire trajectory before outputing the first point (a priori), this is computational time and memory consuming, so not implemented.

Suppose you have a long travel (for example 10s) and very high sampling rate (1ms), then you would require to store 10000 points in memory.

Now let's suppose, you calculate just the travel time, and then you calculate the entire trajectory again, recursively. This would take a lot of time to calculate, so making synchronised moves for multi axis system is not possible anymore.

EDIT: A synchronised move has at least two axis, that you have to synchronise. Each axis has a dedicated traj, planner. The input setpoints are:

• target position
• at the very first time it also needs the axis actual position that is copied as planner actual position. Note that planner actual position $$\\neq\$$ axis position. The planner is calculated open loop, no physical feedback is allowed except for starting point.
• setpoint velocity
• setpoint acceleration/deceleration

The planner outputs :

• position.
• done signal (when position = target position)

The planner has to retain values for position and actual velocity, next position point is calculated with regard to constraints of setpoint velocity and setpoint acc/dec. For each recursion it has also to calculate the distance to go (target position - actual position) and required path for coast to a standstill = breaking distance. If the breaking distance => distance to go, then the planner starts to compute the coasting trajectory.

At each recursion you begin with actual position = position

• Ok, you are right, so how is this done for example in a 3d printer then? Is the current target position given from external to the trajectory generator and the time constraints on this target position are also calculated external? – HansPeterLoft Sep 6 '19 at 7:08
• @HansPeterLoft I don't quite understand your question, are you referring at synchronised move? In this case, yes the constraints have to be calculated before, else each axis would move on its own. – Marko Buršič Sep 6 '19 at 7:23
• Yes, a synchronised move. When I want for example to drive a special trajectory on a single axis, do i have to give the target positions directly withing a given interval to the trajectory generator? – HansPeterLoft Sep 6 '19 at 7:25