AC Servo Linear Actuator with PID and Feed-Forward Velocity Control

I've been developing an AC servo linear actuator using PID control combined with feed-forward velocity control. This is enabled by an AC servo controller that provides quadrature encoder outputs for position feedback.

Many might ask: Why bother? Isn't this a solved problem? For me, it's an intellectual exercise, and I believe I can improve on existing solutions. I'd love to hear any differing insights.

I chose the Teensy Arduino for several reasons:Ample memory for my needs.

• Excellent performance from its ARM CPU.
• FlexPWM for direct frequency control.
• Built-in hardware quadrature encoding (4 channels).

For this discussion, I'll refer to the controlling computer as "the Arduino," but it could be any real-time system. This approach applies mainly to ball screws, as gear motors typically offer low resolution (~512 count range). Servo motors might provide 30,000 counts for the same distance, enabling finer control. With gear motors at low counts, velocity might drop to just 2 steps per game interval, which performs poorly.

AC servos operate as pulse-direction devices, similar to steppers: pulse rate dictates motor velocity. Velocity and acceleration loops are usually closed within the AC servo itself. The Arduino sets the speed and tracks total pulses sent (for position control), while the servo handles acceleration to prevent overruns. This is how most solutions I've seen function—some are very smooth and ideal for flight sims.

With position feedback available, I can apply standard PID control to the AC servo. This limits acceleration only by the move's specifics, allowing very abrupt starts and stops. However, pure PID struggles with smooth motion.

Traditional PID aims to reach setpoints quickly, often with overshoot or abrupt stops—fine for racing sims (which are trajectories too, just with expected jerks like suspension bottoming). Flight sims prioritize smoothness (except on the ground): SimTools sends a continuous stream of trajectory points, and the Arduino must follow them fluidly, minimizing unnecessary acceleration. Velocity-based control excels here by emphasizing consistent speed along the path, rather than forcing rapid corrections to discrete targets.

Velocity control calculates speed simply as (p2 - p1) / interval. We don't want to stop at p2, as the game sends a trajectory, not isolated stop points.

Games provide position updates at fixed intervals, typically 33ms (for 30Hz or 60Hz rates). SimTools outputs at a user-set fixed interval— I usually use 10ms, so each game position is sent multiple times. The interval is crucial for velocity calculations. We need the game's interval, not SimTools'. To find it, I build a histogram of incoming data change timings; the largest bin represents the game interval. I use this fixed value for all velocity calculations. Velocity profiles are often noisy, and varying the interval amplifies that noise.
I've been integrating velocity control with PID. The algorithm follows these steps:

• Calculate target velocity over the full game interval.
• Interpolate the target position at each cycle (currently 4kHz).
• Compute error based on the interpolated target.
• If error is small, use velocity directly.
• If error exceeds a threshold, gradually accelerate to reduce it.
• If error surpasses a higher threshold, switch to PID control.

I'm not done yet, but this hybrid yields smoother motion than pure PID, though not quite as fluid as pure velocity.

I wanted to share this now, but I'll soon add a video comparing pure velocity, the hybrid, and pure PID performance. Stay tuned!