Actin  Version 5.5.5
Software for Robotics Simulation and Control
Acceleration Limiter Tuning


The acceleration limiter can limit the joint acceleration and base acceleration (if not fixed base) during end-effector motion. It works by on-line finding a series of discrete time scaling factor to each time step using dynamic programming.

Motion Parameters

Click the menu "Edit" -> "Position Control System" -> "Control System Parameters...", the "Position Control System Properties" dialogue will pop up. Double click the active control descriptions, the "VelocityControl Descripton" dialogue will pop up (Figure below). Click "Control Parameters" button and enter the acceleration limits, deceleration limts, and velocity limits for all joints. Note that the length of acceleration/deceleration/velocity limits must be equal to the number of joints if the robot is fixed base. If the robot is not fixed base, the length must be equal to number of joints + 6, with the last 6 parameters being the limits of the base.

Control Parameters Configuration GUI.

Acceleration Limiter Parameters

In the "Position Control System Properties" dialogue, click the "Edit" button next to "Acceleration Limiter:". The figure below shows the interface for changing acceleration limiter parameters.

Acceleration Limiter Configuration GUI.

Turning on the Acceleration Limiter

Click "Is On" to turn on the acceleration limiter. Then click "OK". Click "Edit" again to doublecheck if "Is On" is still checked. If not, most likely the length of motion limits are not correct (see the section above).

Number of Td (Integer)

This parameter ( \( N_{T_d} \)) controls the number of candidates of time scaling factor. In the above figure, \( N_{T_d} = 100 \) means the limiter uses time scaling factors as {0.01, 0.02, …, 1.00} and is able to slow down the time 100 times, and reduce the velocity to \( \dot T = 0.01 \) and acceleration to \( \dot T^2 = 10^{-4} \) of the original. Therefore, if the acceleration could reach \( \ddot q^{\max} \) before applying acceleration limiter and the acceleration limit is \( \ddot q^{\lim} \), the number of Td should be at least:

\[{N_{{T_d}}} \ge \mathop {\max }\limits_j \sqrt {\frac{{\ddot q_{^j}^{\max }}}{{\ddot q_{^j}^{\lim }}}}\]

To find a feasible trajectory (all joint accelerations within limits), this parameter should also satisfy:

\[{N_{{T_d}}} \ge \mathop {\max }\limits_j \left| {\frac{{\dot q_j^{\lim }}}{{\ddot q_j^{\lim }\Delta t}}} \right|\]

where \( \Delta t \) is the time step of the position control system.

However, the larger \( N_{T_d} \) is, the more CPU power will be required by the acceleration limiter. Therefore we would like to find the smallest number than can limit the accelerations. \( N_{T_d} = 100 \) is always a good start.

Deceleration Braching Factor (Integer)

This parameter ( \( b_{dec} \)) determines the branching factor the limiter uses when searching from a larger \( \dot T \) to a smaller \( \dot T \). For example, if \( b_{dec} = 5 \), the \( \dot T \) of the previous time step is 0.50 and \( N_{T_d} = 100 \), the limiter will try \( \dot T = \left\{ 0.50, 0.49, 0.48, 0.47, 0.46, 0.45 \right\} \) for the next time step.

\( b_{dec} \) should be greater than 0 and is no need to be greater than \( N_{T_d} / 2 \). The time delay caused by building up the buffer is:

\[{t_{bd}} = \frac{{{N_{{T_d}}}}}{{{b_{dec}}}}\Delta t\]

\( b_{dec} = 20 \) is a good start. With \( N_{T_d} = 100 \) and \( \Delta t = 0.008 sec\), the delay will be \( 0.04 sec\).

Acceleration Braching Factor (Integer)

This parameter ( \( b_{acc} \)) determines the branching factor the limiter uses when searching from a smaller \( \dot T \) to a larger \( \dot T \). For example, if \( b_{acc} = 3 \), the \( \dot T \) of the previous time step is 0.50 and \( N_{T_d} = 100 \), the limiter will try \( \dot T = \left\{ 0.50, 0.51, 0.52, 0.53 \right\} \) for the next time step.

\( b_{acc} \) should be greater than 0 and is no need to be greater than \( b_{dec} \). If this number is too large, it will increase jerk. \( b_{acc} = 4 \) is a good start.

Max Future Iteration (Integer)

In order for the acceleration limiter to work, it needs to buffer enough future states. The required time length of future states for always finding a feasible solution is:

\[{t_f} = \mathop {\max }\limits_j \left| {\frac{{\dot q_j^{\max }}}{{\ddot q_j^{\lim }}}} \right|\]

This can be done by either calculating future time steps or by creating an artificial delay or a combination of both. Each has its pros and cons. Calculating future states will increase CPU load while artificial delay will increase the task finish time.

A non-zero max future integration ( \( N_{mfi} \)) will tell the limiter to move at most \( N_{mfi} \) steps to calculate future states. If this number is too small, the limiter will not be able to accumulate enough future states and the acceleration limits will likely be violated. If this number is too large, the CPU load will be too high and we may miss time steps. \( N_{mfi} = 8 \) is a good start.

Note that the max future iteration does not need to be greater than the max iteration of the position control system, but must satisfy the following equation, otherwise, the simulation time will never catch up with real time.

\[{N_{mfi}} \ge \frac{{\Delta {T_{sys}}}}{{\Delta {T_{pos}}}}\]

where \( \Delta T_{sys} \) is the simulation time step while \( \Delta T_{pos} \) is the position control system time step.

Delay Time (Real Number)

A non-zero delay time ( \( t_d \)) will tell the limiter to buffer \( t_d \) seconds of states and the robot will start to move after \( t_d \) seconds. There is no need for \( t_d \) to be larger than the max time length of future states \( t_f \). Set \( t_d = 0 \) if artificial time delay is unacceptable.