Jerk 制限が要る理由
加速度ステップ (jerk = ∞) が機械と制御に何を起こすか。オンライン OTG (Ruckig 等) を下流に置く根拠
要点
加速度が階段状に変化する指令 (jerk = ∞) を機構に入れると、電流ステップ・機械衝撃・ 構造振動励起・追従誤差 の全部が同時に出る。jerk 制限 = C² 連続な軌道。
軌道を上流で dense に書けば同じことができるが、それは Ruckig を自前で再実装 する のと等価。online OTG を 1 か所に置いて goal だけ投げる方が実装コストも teleop 対応も 安く済む。
数字 / 式
| 影響 | 因果 |
|---|---|
| 電流ステップ | I ≈ kt × a → dI/dt = kt × jerk。電源電圧と電流ループが追従できない (時定数 ~ms) |
| 機械衝撃 | shock load。ボールベアリング寿命は L10 定格の 1/N (N は衝撃応力の指数関数) |
| 振動励起 | 加速度不連続 = 広帯域スペクトル。構造弾性帯域 (5-50 Hz) を必ず含む |
| 追従遅れ | 電流ループ tCurr ~1-5 ms、速度ループ ~10 ms。加速度ステップは 1 ループ分だけ overshoot |
| 静定時間 | 残振動が減衰するまで位置精度が出ない (端点で待つ時間) |
7-segment jerk-limited profile: 加速上げ / 加速一定 / 加速下げ / 定速 / 減速上げ / 減速一定 / 減速下げ。vmax, amax, jmax の 3 制限で決まる。
詳細
「上流で dense に waypoint を書けば良い」の帰結
事前計算で jerk-limited な軌道を作る方法:
- 目標点間で 7-segment polynomial を解く
- 途中で目標変更 → 前状態 (pos, vel, acc) を保ったまま再解 (retarget)
- multi-joint の時間同期 (律速関節に合わせる)
これらは すべて Ruckig がやっていること。Ruckig は「target 1 点 + limits」を投げると online で dense な smooth setpoint を吐く online OTG (Online Trajectory Generator)。
自前で書く場合、
- 7-segment を毎目標変更で解き直す実装
- 数値ロバストネス (limits 境界でのゼロ除算回避)
- multi-joint 同期
- キャンセル・停止セマンティクス
を再実装することになる。モジュール性が失われる (計画側とスムージング側がくっつく)。
teleop はそもそも事前計算できない
ゲームパッドスティックは online で来る反応的な入力。目標は次フレームまで分からない。 事前 waypoint 計算では扱えない。online retarget が要る = Ruckig の得意領域。
下流に置く 3 番目の利点
BT (自律) と teleop (手動) と posture (姿勢マクロ) の 3 系統が別々に上流にある場合、 それぞれで軌道生成すると リミット管理が 3 か所に分散 する。max_vel / max_acc / max_jerk を関節ごとに 1 か所 (下流 OTG の param yaml) に集約すれば、実機チューニングの 可搬性が上がる。
参照: [[ik-and-trajectory-pipeline]] — 3 系統前提の 2 段構え
上流に Cartesian OTG を置くケース
手先を 直線に降ろす ような要件は下流 joint OTG では出せない (関節直線 = Cartesian 円弧)。 このときだけ上流に Cartesian OTG を挟む。下流の joint OTG は残す (teleop/posture の ガードとして)。二段構え が自然。
参照: [[task-space-ruckig]]
関連
- [[task-space-ruckig]] — Cartesian OTG の一般論
- [[ik-and-trajectory-pipeline]] — salamander で 2 段構えを組む理由