Motion System Sizing Framework

Executive Summary

Axis sizing usually happens in fragments: the motor is picked from the move profile, the encoder arrives from a catalog, and bandwidth targets appear after the mechanics are frozen. This framework chains the decisions into one auditable pass — every requirement constrains the next, and violations surface before hardware is ordered.

The chain is implemented as a dependency-free, unit-tested TypeScript module and exposed as the online Motion Sizing Calculator. Version 1 covers a symmetric trapezoidal profile on a linear direct-drive axis; the parameter model and architecture mappings below define the full scope the framework is built toward.

Engineering Questions

The framework exists to answer six questions with numbers instead of intuition:

1. Does the motor have enough force margin for the requested move, including friction and process forces?
2. What peak power does the move demand, and can the drive deliver it?
3. Will the axis overheat under the duty cycle — is the RMS load within the continuous rating?
4. Is the encoder fine enough that the error budget is not consumed by quantization?
5. How much phase does the loop delay burn at the intended bandwidth?
6. Is the desired bandwidth compatible with the first mechanical resonance?

System Boundary

Question — what does the framework model, and what does it deliberately leave out?

In scope

• ✓ Rigid-body profile kinematics (position, velocity, acceleration, jerk)
• ✓ Force / torque chain with lumped friction, gravity and process forces
• ✓ First-order motor electrical limits: force constant, current, voltage, I²R loss
• ✓ Encoder quantization of the position error budget
• ✓ Lumped loop-delay budget and its phase cost
• ✓ Mechanical resonance target as a bandwidth-ratio heuristic

Out of scope

• ○ Flexible-body / FEA structural simulation
• ○ Thermal FEA (only I²R and RMS-vs-continuous checks)
• ○ Servo loop tuning and stability proof
• ○ Trajectory optimization and path planning
• ○ Drive firmware internals beyond a lumped delay and bandwidth

Interpretation — everything inside the boundary is first-order and analytic on purpose: the framework is a decision filter for early design, not a replacement for detailed simulation of the shortlisted concept.

Input Parameter Groups

Question — what is the minimum parameter set that makes a sizing decision auditable?

Six groups. Symbols below are used in all equations on this page.

Motion requirements

Mechanical parameters

Electrical parameters

Feedback and control

Disturbances

Group 6 is the mechanical architecture selection itself — next section.

Supported Mechanical Architectures

Question — how does the same sizing chain apply across different drive concepts?

Every architecture reduces to the same chain once load force/torque and reflected inertia are expressed at the motor. The mapping differs per concept:

Interpretation — “mapping defined” means the reflection formulas are specified in this framework but not yet implemented in the calculator; “planned” means the concept needs additional model structure (contact, MIMO coupling) before it fits the chain.

Analysis Workflow

Question — in what order do the calculations constrain each other?

Each step consumes the previous step’s output: a change in move time propagates through kinematics, force, current, heat, and finally shifts the resonance requirement. Running the chain in this order makes the first violated constraint visible, which is the design signal that matters.

Motion Profile Model

Question — what velocity and acceleration does the requirement imply?

Method — v1 supports the symmetric trapezoidal velocity profile with acceleration time $t_a$, valid for $0 < t_a < T/2$:

$$v_{pk} = \frac{D}{T - t_a}, \qquad a_{pk} = \frac{v_{pk}}{t_a}$$

D

Move distance [m]

T

Total move time [s]

t_a

Acceleration time [s]

v_pk

Peak velocity [m/s]

a_pk

Peak acceleration [m/s²]

Interpretation — shorter acceleration time lowers peak velocity but raises peak acceleration; the product chain below converts that trade directly into force and heat.

Force / Torque Calculation

Question — what force must the motor produce at the worst point of the move?

$$F_{tot} = m \, a_{pk} + F_{ext} + F_{fric} + F_g$$

F_tot

Peak force demand [N]

m

Moving mass [kg]

F_ext

External / process force [N]

F_fric

Lumped friction force [N]

F_g

Gravity component along axis [N]

$$T_m = \frac{F_{tot} \cdot N}{\eta} + J_{ref}\,\alpha_m, \qquad J_{ref} = J_{motor} + J_{trans} + m N^2$$

T_m

Motor torque demand [N·m]

N

Transmission ratio (motion out / motor in) [—]

η

Transmission efficiency [—]

J_ref

Reflected inertia at the motor [kg·m²]

For direct drive, N = 1 and η ≈ 1 and the two equations coincide.

Interpretation — with a transmission, the $mN^2$ term makes the inertia ratio the real design variable: gearing down trades force margin against reflected-inertia mismatch.

Power and Thermal Margin

Question — can the motor deliver the peak, and survive the average?

$$P_{pk} = F_{tot}\, v_{pk}, \qquad I = \frac{F_{tot}}{K_f}, \qquad P_{loss} = I^2 R$$

P_pk

Peak mechanical power [W]

I

Motor current [A]

K_f

Force constant [N/A]

R

Phase resistance [Ω]

$$F_{rms} = \sqrt{\frac{1}{t_{cyc}} \int_0^{t_{cyc}} F^2(t)\, dt}$$

F_rms

RMS force over one cycle [N]

t_cyc

Cycle time incl. dwell [s]

The thermal verdict compares F_rms/K_f against the continuous current rating, and F_tot/K_f against the peak rating.

Interpretation — peak margin decides whether the move is possible; RMS margin decides whether it is repeatable. Aggressive duty cycles fail thermally long before they fail on peak force.

Encoder Resolution Analysis

Question — is the error budget spent on servo performance or on the sensor?

$$N_{err} = \frac{e}{r}, \qquad \Delta v_q = r \cdot f_s$$

N_err

Error band expressed in counts [counts]

e

Target position error [µm]

r

Encoder resolution [µm/count]

Δv_q

Velocity-estimate quantization step [µm/s]

Interpretation — below roughly 2 counts the loop dithers between adjacent counts and no tuning recovers it. The second expression shows why finite-difference velocity from a coarse encoder is noisy: the quantization step scales with sampling rate.

System Delay and Bandwidth

Question — how much phase does the control loop lose to pure delay at the intended crossover?

Method — all loop delays are lumped into one budget:

$$\tau_{tot} = \tau_{drv} + \tau_{com} + \tau_{cmp} + \tau_{zoh} + \tau_{sen}$$

τ_tot

Total lumped loop delay [s]

τ_drv

Driver delay [s]

τ_com

Communication delay [s]

τ_cmp

Computation delay (control box) [s]

τ_zoh

Sampling / ZOH delay ≈ T_s / 2 [s]

τ_sen

Sensing and filtering delay [s]

$$\varphi(f) = -360 \cdot f \cdot \tau_{tot}$$

φ

Phase lag (negative) [deg]

f

Frequency of interest [Hz]

Try it — the calculation runs in src/lib/engineering/phaseLag.ts (unit-tested):

Interactive · phase lag from delay

Total delay (µs)

Frequency (Hz)

Phase lag

-4.50°

phaseLag = −360 · f · T. Runs locally in your browser; nothing is uploaded.

Interpretation — a 250 µs budget costs 4.5° at 50 Hz but 18° at 200 Hz: delay is what makes “just raise the bandwidth” stop working. If the lag at the intended crossover exceeds roughly 10–15° of the phase margin budget, reduce delay before retuning gains — that allocation is an engineering heuristic, not a universal design rule.

Mechanical Resonance Requirement

Question — what must the mechanics provide so the servo target is even possible?

$$f_{res} \ge \beta \cdot f_{bw}$$

f_res

First structural resonance [Hz]

f_bw

Desired control bandwidth [Hz]

β

Resonance ratio [—]

β default 4; the ratio is an engineering heuristic, not a universal design rule — required separation depends on damping and disturbance spectrum.

Interpretation — this closes the loop back to mechanics: if the structure cannot reach $\beta \cdot f_{bw}$, the honest options are lowering the bandwidth target or redesigning the structure — not notching and hoping.

Disturbance Model

Question — which disturbances must the force budget and the error budget absorb?

Interpretation — constant terms (gravity, drag, Coulomb) consume force margin; periodic and random terms (cogging, ripple, current noise) consume the error budget at frequencies the servo may not reject. The split decides whether a problem is a bigger-motor problem or a better-control problem.

Calculation Example

Reproduce every number live in the Motion Sizing Calculator — it ships with exactly this example as its reset state.

Engineering Decisions

Limitations

• Symmetric trapezoid only; no S-curve, asymmetric or jerk-limited profiles yet.
• Rigid-body force model — no resonant load amplification inside the force estimate.
• Thermal check is peak-only in the v1 tool; RMS duty-cycle margin is defined but not implemented (TBD).
• Architecture mappings beyond linear direct drive are specified, not implemented.
• Disturbance catalog is qualitative in v1; no predicted error spectrum.
• The framework has not yet been benchmarked end-to-end against a sized physical axis (validation level: Simulation).

Roadmap

1. S-curve profile with jerk limit and its effect on peak force and settling.
2. RMS force / thermal duty check over a move-and-dwell cycle (closes question 3).
3. Ball-screw mapping implemented in the calculator (reflected inertia, critical speed).
4. Measured-FRF import to replace the β-ratio resonance heuristic with data.
5. Exportable sizing report (copyable text exists; file export planned).

Related Tool

Related Tool

• Motion Sizing Calculator Interactive implementation of this framework — trapezoid chain, warnings and motion profile charts, all client-side.

Revision History

1. 2026-05-20

   Initial methodology write-up (profile, force, margin chain).

2. 2026-07-21

   Online calculator published, backed by the tested motionSizing.ts module.

3. 2026-07-22

   Case-study restructure: system boundary, parameter groups, architecture map, delay/phase model with interactive estimator, disturbance catalog, data-provenance labels.