電流スパイクは実際の負荷下でのみ発生しますか? 同期されたトレースにより、ケーブルの抵抗、ペイロードの影響、および制御限界を分離します。
OpenArm の障害の中には、ロボットに実際の負荷がかかっている場合にのみ発生するものもあります。つまり、電流スパイクが発生し、トルクが予想よりも早く飽和し、空中では安定しているように見えたコントローラーが接触タスクやペイロード タスクで突然信頼性が低下します。
コントローラーのゲインをすぐに非難せずに、OpenArm 上の予期しない電流スパイクやトルク飽和をどのように診断していますか?
一度に多くの変数を変更する前に、ペイロードの影響、摩擦、ケーブルの抵抗、コントローラーの制限、センサーのタイミングの問題を分離する方法を共有してください。
返信する場合は、正確な飽和症状を 1 つと、診断を進めるための正確な測定値またはハードウェア/ソフトウェアのチェックを 1 つ含めてください。
高度なコンテキスト: 以前は正常に動作していたのと同じペイロードで加速中に、ジョイント 2 の電流スパイクが 4 A ベースラインから 9 A に上昇するのが見られました。 空中での動きはきれいに見えましたが、負荷のかかるコーナリングによりトルククランプイベントが発生しました。
高度なコンテキスト: 最も有用なチェックは、現在のログとコマンドされたジャークおよびケーブルの動きのビデオを同期することでした。 スパイクは 1 つのケーブル屈曲領域に位置合わせされているため、摩擦とルーティングがコントローラーの制限とともに寄与していました。
高度なコンテキスト: 修正は、ケーブル ハーネスのルートを変更し、ジャークを 20% 下げ、8 A を超える持続電流を 150 ミリ秒以上継続してウォッチドッグを維持するという組み合わせでした。 その後、2 時間のストレス ランは飽和以下に留まりました。
高度なコンテキストのフォローアップ: 上級チーム向けのフォローアップの質問: 同期した電流、ジャーク、およびケーブル状態のトレースをログに記録していますか?また、どのメトリックが最良の早期警告信号であることが判明しましたか?
最も近い症状を選択して、適切なトラブルシューティング パスに従ってください。
電流およびジャークトレースをケーブル動作の観察と同期させて、相関する機械的要因を見つけます。
python tools/log_current_and_jerk.py --task stress_path --duration 120
python tools/correlation_report.py --signals current,jerk,cable_state最初に機械的制約を修正し、次に軌道の積極性を減らし、必要に応じて制御を再調整します。
まずはチェックリストのテンプレートとして使用してください。 実行前に自分のセルでインターフェイス名、フィクスチャ ID、安全条件を確認してください。