Trajectory Planning Point To Point Interactive Calculator

Getting smooth motion between two points is trickier than it looks. If you pick the wrong profile, you'll see vibration, overshoot, added mechanical wear, or the mechanism might stop short. This Trajectory Planning Point-to-Point Calculator outputs position, velocity, acceleration, and jerk profiles using cubic or quintic polynomials, trapezoidal, or S-curve methods—based on your start/end position, move time, and constraints. Whether you’re working on industrial robots, CNC machines, or automated assembly, the shape of your motion profile really does matter: it affects throughput, accuracy, and how long your hardware lasts. The page below includes the core trajectory equations, a worked engineering example, a straightforward explainer for beginners, and an FAQ.

What is trajectory planning?

Trajectory planning means figuring out how a mechanical system moves from one spot to another—including not just the start and end points, but also how the speed and acceleration change along the way. Instead of snapping to speed instantly, a planned trajectory ramps up and down with a controlled profile you can predict and check against real-world constraints.

What is a simple way to think about trajectory planning?

Think about pulling your car out of one parking spot and into another. You don’t just stomp on the gas and then slam the brakes—you ease into motion, cruise, and then ease to a stop. Trajectory planning applies the same logic to a robot arm or actuator: it defines exactly how you ramp up speed, what speed you hold, and how you slow down, so you avoid shock loads and jolts. The different methods—cubic, quintic, trapezoidal, S-curve—are all just ways of deciding how gradual those changes are.

📐 Browse all 1000+ Interactive Calculators

System Diagram

How do you use this trajectory planning calculator?

1. Select your calculation mode from the dropdown — choose from Cubic Polynomial, Quintic Polynomial, Trapezoidal, S-Curve, Time to Reach Position, or Maximum Velocity.
2. Enter your start position (q₀) and end position (q_f), plus total move time if required. Additional fields for velocity, acceleration, and jerk constraints will appear based on your selected mode.
3. Fill in any constraint values shown — such as max velocity, max acceleration, or max jerk — using the units indicated (meters, degrees, seconds).
4. Click Calculate to see your result.

Trajectory Planning Calculator

📹 Video Walkthrough — How to Use This Calculator

What are the trajectory planning equations?

Below are the standard formulas for position, velocity, and acceleration at any given time for each common type of trajectory.

Where:

• q(t) = position at time t (meters, radians, or degrees)
• v(t) = velocity at time t (m/s, rad/s, or deg/s)
• a(t) = acceleration at time t (m/s², rad/s², or deg/s²)
• j(t) = jerk at time t (m/s³, rad/s³, or deg/s³)
• q₀ = initial position
• q_f = final position
• v₀, v_f = initial and final velocities
• a₀, a_f = initial and final accelerations
• T = total move time (seconds)
• v_max = maximum velocity constraint
• a_max = maximum acceleration constraint
• j_max = maximum jerk constraint

What does a simple worked example look like?

Cubic polynomial, trapezoidal mode. Start position: 0 m. End position: 1.5 m. Total move time: 2 s. Start and end velocities: 0 m/s.

At t = 1.0 s (midpoint): Position ≈ 0.75 m. Velocity ≈ 1.125 m/s. Acceleration ≈ 0 m/s². Peak velocity ≈ 1.125 m/s.

How does trajectory planning work in engineering practice?

In the real world, point-to-point trajectory planning lays out the calculations for moving something from A to B while keeping actuator limits, hardware wear, and precision in mind. If you just tell an actuator to jump to speed, you’re either asking for infinite acceleration or you’ll hit mechanical limits—both are a recipe for rough stops and extra vibration. Trajectory planning lets you move at controlled rates so everything stays within real constraints. The right method depends on your needs. Polynomials give you exact endpoint control; trapezoidal profiles are typically fastest for a given set of actuator limits; S-curve caps jerk for less vibration. For many jobs, the difference between these methods shows up in how much ringing, overshoot, or settling time you get at the end of a move.

Comparison of Trajectory Methods

Polynomial Trajectory Fundamentals

Polynomial trajectories use time-based equations with coefficients set by your boundary conditions. For a cubic (3rd order), you need four conditions—usually position and velocity at both ends. This guarantees position and velocity change smoothly, but acceleration jumps at the start and end, which can shake flexible systems. The cubic method means solving four linear equations for your coefficients. For example, moving from 0 to 1.5 m in 2 s with zero velocity at both ends, you’ll get a₀ = 0, a₁ = 0, a₂ = 1.125, a₃ = -0.375. Peak velocity is 1.125 m/s halfway through the move.

Quintic polynomials (5th order) stretch this idea, giving you control over acceleration at both boundaries for six total conditions. This removes acceleration jumps, so it’s good for delicate jobs—think high-precision handling or optics, where even small jolts can create errors. The price is a slightly more complex 6x6 system to solve, but with modern processors, it’s not a bottleneck. One thing to note: quintic polynomials fix acceleration skips, but jerk (change in acceleration) can still jump at the ends, which isn’t ideal for ultra-sensitive setups.

Trapezoidal Velocity Profiles

Trapezoidal velocity splitting gives time-optimal moves when you’re limited by velocity and acceleration, which are usually a motor’s current and thermal limits. The motion splits into three straightforward chunks: ramp up at constant acceleration to max speed, hold constant speed, then decelerate at the same rate back to zero. For example, 1.5 m at 1.0 m/s maximum velocity and 2.0 m/s² acceleration: accelerate for 0.5 s, go 0.25 m during that ramp, then cruise, then decelerate the final 0.25 m. If the move is long enough, there’s a cruise phase; if not, you get a triangle profile instead.

If your move is too short to reach the cruise velocity, you automatically get a triangular profile—just accelerate up and decelerate down, reaching your peak velocity at mid-move. That peak is v_peak = √(a_max·|Δq|). For 0.5 m at 2 m/s², it’s 1.0 m/s. This adjustment is automatic in most controllers, especially if you’re doing pick-and-place or other variable-length moves.

S-Curve Trajectory Design

S-curve adds jerk limits to tame vibration and reduce mechanical shock. The move is broken into seven phases—including jerk up/down at the start and end—which makes motion gentler for systems with flex, long arms, or heavy payloads. For 1.5 m, v_max = 1.0 m/s, a_max = 2.0 m/s², j_max = 5.0 m/s³: it takes 0.4 s to ramp acceleration from zero to 2.0 m/s², with distance growing per q(t) = q₀ + (j_maxt³)/6. S-curve uses more of your move time for gentler acceleration, meaning longer total moves for the same constraints—but it can pay off by reducing vibration and, in many cases, lowering the overall system cycle time because you won’t have to wait as long for vibration to die out after motion stops.

Your actual acceleration phase is stretched compared to a hard-edged move, and this loss of “time optimality” is really the cost for smoother operation. But on flexible machinery, there are plenty of scenarios where saving time on vibration settling more than outweighs the time spent moving a bit more slowly.

Worked Engineering Example: Robotic Arm Joint Trajectory

Take a SCARA robot shoulder joint moving a 2.3 kg payload from θ₀ = 15.0° to θ_f = 87.5° in T = 1.8 s. Servo motor maxes out at 4.8 N·m torque, joint inertia J = 0.085 kg·m², and max speed ω_max = 180 deg/s = 3.142 rad/s. Let’s weigh options.

Step 1: Compute Required Motion Parameters
Angle change: 87.5° - 15° = 72.5° = 1.265 rad
Average speed: ω_avg = 1.265/1.8 = 0.703 rad/s

Step 2: Evaluate Cubic Polynomial Feasibility
For zero endpoint velocities: peak speed at mid-move = 1.5 × 1.265/1.8 = 1.054 rad/s
Peak acceleration: 6 × 1.265/1.8² = 2.342 rad/s²
Required torque: 0.085 × 2.342 = 0.199 N·m
All under limits—cubic is fine here.

Step 3: Evaluate Trapezoidal Alternative
Max acceleration: 4.8/0.085 = 56.47 rad/s²
Time to max speed: 3.142/56.47 = 0.0556 s
Distance during accel ramp: 0.5 × 56.47 × 0.0556² = 0.0874 rad
Since 2 × 0.0874 = 0.175 rad < 1.265 rad, cruise phase exists.
Cruise time: (1.265 - 0.175)/3.142 = 0.347 s
Total time: 2 × 0.0556 + 0.347 = 0.458 s

Step 4: Design Decision and S-Curve Refinement
Trapezoidal beats the move time easily, so you can slow everything down for less shock. Pick S-curve with a lower j_max, recalc α to smooth things, get a move well within torque limits, and reduce payload vibration.

Step 5: Verify Final Trajectory
At halfway (t = 0.9 s): position ≈ midpoint, velocity ≈ cruise, acceleration ≈ 0, torque well under the motor’s max. Good margin for hardware life and thermal safety.

This underlines a practical point: when your required move is much slower than what your system can actually do, it’s worth switching to S-curve (or at least dropping acceleration limits) for less wear and vibration, rather than just hammering out a fast trapezoidal path and waiting for things to settle. Smoother moves can improve throughput in the bigger picture.

Real-Time Implementation Considerations

On real machines, you want low computational overhead. Polynomial profiles are trivial to evaluate in code using Horner’s method, even on modest hardware. Trapezoidal and S-curve use time-phase checks—again, simple logic and arithmetic. Pre-calculate phase times and store them for fast look-up at each timestep.

One small but important issue: position integration, especially over long or fast moves. Trapezoidal (or Simpson’s rule) integration of velocity generally tracks position much more accurately than Euler integration, especially with longer trajectories or slower update rates. Small integration errors easily add up in real systems, so pay attention to this if you’re after precision.

Multi-Axis Coordination and Path Planning

For multi-axis machines, coordinate each axis so they all start and finish moves at the same time. This lets each axis respect its own speed/acceleration limits, but they all finish together. For example, say the X-move takes 0.5 s at its max speed, Y needs 0.575 s, and Z just 0.083 s; use 0.575 s for all. This means X and Z run slower to stay in step. This approach keeps you from overloading any one axis and is standard for most joint-space point-to-point moves. If you need a straight line in XYZ space instead, you’d use coordinated linear interpolation.

For more information on motion control calculations and other engineering tools, visit our engineering calculator library.

Where is point-to-point trajectory planning used?

What are common mistakes when using this calculator?

1. Choosing cubic when quintic is required. Cubic polynomials produce discontinuous acceleration at endpoints. On compliant systems (long links, flexible joints, sloshing payloads, precision optics), this excites structural resonances and increases settling time. If your system rings after stopping, switch to quintic or S-curve.
2. Ignoring constraint violations mid-trajectory. Polynomial trajectories do not inherently respect v_max or a_max — they only honor boundary conditions. Always evaluate the peak velocity and peak acceleration the calculator returns against your actuator limits. If exceeded, increase total move time or switch to a trapezoidal/S-curve mode that constrains by design.
3. Treating zero cruise time as an error. When the move distance is too short to reach v_max, the trapezoidal profile collapses to a triangular profile. This is the correct time-optimal result, not a fault.
4. Forgetting that point-to-point ≠ coordinated path. In multi-axis systems, this calculator plans each axis independently. The resulting Cartesian path will be curved, not a straight line between waypoints. For straight-line Cartesian motion, use coordinated/linear interpolation instead.
5. Mismatched units. The equations are unit-agnostic, but inputs must be internally consistent. Mixing meters with degrees, or seconds with milliseconds, produces silently wrong results. Pick one system and stay with it.
6. Specifying jerk limits without knowing the system's lowest resonant frequency. Jerk time should be at least 2-3 times the period of the lowest significant structural resonance. Setting j_max blindly either leaves performance on the table or excites the very vibration it was meant to suppress.

How can you verify the calculator output is reasonable?

1. Check average velocity. Total displacement divided by total move time gives average velocity. The calculator's peak velocity must always exceed this average — for symmetric trajectories with zero endpoint velocities, peak velocity is 1.5× to 2× the average. If peak velocity comes back equal to or below average, something is wrong with the inputs.
2. Compare cubic peak velocity to the closed-form. For a cubic trajectory with zero endpoint velocities, ω_peak = 1.5·Δq/T. For a 1.265 rad move in 1.8 s, this predicts 1.054 rad/s — the calculator's "Peak Velocity" output should match within rounding.
3. Compare cubic peak acceleration to the closed-form. For a cubic trajectory with zero endpoints, α_peak = 6·Δq/T². For 1.265 rad in 1.8 s, this predicts 2.342 rad/s² — the calculator should match.
4. Trapezoidal phase-sum sanity check. The reported accel time plus cruise time plus decel time should sum to total move time. Accel and decel times should be equal (symmetric profile).
5. Torque feasibility. Multiply the peak acceleration output by your reflected joint inertia. The result must stay under the motor's peak torque rating. If it doesn't, the trajectory is not physically realizable on your hardware regardless of what the calculator shows.
6. Triangular-vs-trapezoidal flag. If the calculator reports zero cruise time, verify the peak velocity is below your stated v_max (it should be, because the move is too short to reach v_max). If peak velocity equals or exceeds v_max with zero cruise, the inputs are inconsistent.

Frequently Asked Questions