IJCAS 2025 · Kwangwoon University

LiPo.

A Lightweight Post-optimization Framework for Smoothing Action Chunks Generated by Learned Policies

Dongwoo Son · Suhan Park

Department of Robotics, Kwangwoon University, Seoul, Republic of Korea

International Journal of Control, Automation and Systems, vol. 23, no. 11, pp. 3284–3292, 2025

Paper · IJCAS arXiv Code · GitHub pip install action-lipo Video

The problem

Learned policies speak in chunks.

Imitation-learning policies do not emit one action at a time. They emit a chunk — a whole stretch of future actions — and the robot plays it back while the next chunk is being computed. The seams between those chunks are where the trouble starts.

At a seam the commanded trajectory is continuous in position but not in velocity. The arm jerks. On a slow pick-and-place you may not notice. On a dynamic task — throwing a ball, swinging a heavy object — that discontinuity lands exactly where momentum matters, and it shows up as vibration, as a weaker throw, and as stress on the hardware.

At a chunk boundary the two action sequences disagree, and the commanded velocity steps. LiPo overlaps the chunks, blends them across the overlap, and smooths what is left.

Core idea

Three steps, after the policy.

LiPo does not touch the policy. It sits downstream of whatever produced the chunks and rewrites them into something a position-controlled arm can actually track.

Scheduling around inference delay

Computing the next chunk takes time. If the robot only asks for it once the current chunk runs out, it waits — and the wait is visible in the motion. LiPo schedules chunks to overlap, so the next one is ready before it is needed.

Blending the overlap

Inside the overlapping region the two chunks are combined by linear blending. The handover stops being an instant switch and becomes a transition, which removes the step in velocity at the seam.

Jerk minimization

What remains is refined by minimizing jerk inside a bounded perturbation space around the blended trajectory. The result stays close to what the policy asked for, while being smooth enough to execute.

No retraining, no policy changes. LiPo is a post-processing stage, so it attaches to any method that outputs action chunks — ACT, Diffusion Policy, or anything else with the same interface.

Experiment

Ball toss, side by side.

A position-controlled arm tosses a ball into a box. The same policy drives both runs; the only difference is whether its action chunks pass through LiPo before execution.

Without LiPo The wind-up stutters where one chunk hands over to the next.

With LiPo The same motion, carried through the seams in one stroke.

Slow motion, ×0.25

Without LiPo Watch the wrist at the moment of release.

With LiPo The release is cleaner, and the ball leaves with more of the arm’s momentum.

The four clips above are cut from one recording. Full video with sound (45 s).

Try it

Run the method yourself.

This is the actual pipeline, not an animation of it. A synthetic policy emits chunks that disagree slightly at their seams. Reference construction follows Eq. (4)–(5) of the paper and the refinement follows Eq. (6), bounds and all; every curve below is recomputed in your browser as you move the sliders.

individual action chunks executed after LiPo allowed perturbation ε(t) inference delay, ε = 0 blending zone

Replan every 30 steps Inference delay t_d 5 steps Blending horizon 10 steps Policy disagreement 50 Blending bound ε̄_b 0.020 rad Path bound ε̄_p 0.003 rad

The paper keeps ε̄_b above ε̄_p: chunk boundaries carry more uncertainty, so they are given more room.

What does a wider blending bound buy you?

Equation (6) gives the blending zone its own bound. Widening ε̄_b smooths the handover — up to a point — at the cost of a larger perturbation, while the path bound ε̄_p keeps the rest of the stroke close to what the policy asked for. Drag across the chart to set ε̄_b.

Benchmark

Cheap enough to sit in the loop.

Post-optimization is only useful if it finishes before the next control tick. The repository ships a benchmark that times the reference implementation against a QP formulation of the same problem.

Benchmark plot comparing the LiPo reference implementation with an OSQP quadratic-program implementation

Implementation	Avg [ms]	Std [ms]	Max \|Δ\| vs LiPo
LiPo (reference)	7.207	1.112	—
OSQP QP	0.553	0.119	0.005626

Both implementations solve the same post-optimization. The QP formulation runs about thirteen times faster and stays within 0.006 of the reference trajectory, which leaves plenty of headroom inside a millisecond-scale control loop.

Reproduce with python lipo_benchmark.py in the repository.

Resources

Paper, code, citation.

Paper · IJCAS arXiv:2506.05165 GitHub PyPI · action-lipo

@article{son2025lipo,
  title   = {LiPo: A Lightweight Post-optimization Framework for Smoothing Action Chunks Generated by Learned Policies},
  author  = {Son, Dongwoo and Park, Suhan},
  journal = {International Journal of Control, Automation and Systems},
  volume  = {23},
  number  = {11},
  pages   = {3284--3292},
  year    = {2025},
  doi     = {10.1007/s12555-025-0537-0}
}