プランナーは安全なパスを拒否しますか、それとも危険なパスを許可しますか? プランナーのアルゴリズムを非難する前に、シーンのメッシュと現実を調和させてください。
OpenArm 計画のイライラする問題は、現実世界でロボット、ツール、または設備が変更されたにもかかわらず、計画現場ではまだ古いジオメトリが信じられている場合に発生します。 パスは、明確な理由もなく失敗するか、実際のものを切り取っているときに計画上安全に見えるかのどちらかです。
実際のロボットやワークスペースのジオメトリと一致しない衝突モデルによって引き起こされる OpenArm モーション プランニングの失敗をどのように診断していますか?
プランナー自体を非難する前に、衝突メッシュを現実と比較し、古いツール ジオメトリを検出し、プランナーが信頼できるシーンを使用していることを検証する方法を共有してください。
返信する場合は、正確な計画症状を 1 つと、不一致を明らかにした正確なジオメトリまたはシーン チェックを 1 つ含めてください。
高度なコンテキスト: Planner は、手動ジョグで実際のクリアランスが 12 ～ 15 mm であるにもかかわらず、万力のコーナー近くのパスを拒否し続けました。 計画されたシーンのジオメトリを現在のツール ハードウェアと比較するまで、症状はランダムに見えました。
高度なコンテキスト: それを暴露したのは、RViz のライブ点群と衝突メッシュのオーバーレイでした。 アクセサリの交換後、ツール フランジのメッシュが X 方向に約 12 mm 古くなったため、プランナーはゴースト障害物を正しく回避していました。
高度なコンテキスト: 現在の承認は、更新されたシーンで再生された 50 の軌跡と、最も狭い領域での 2 つの物理的クリアランス プローブです。 どちらかが失敗した場合は、デプロイメントがブロックされ、衝突アセットが再構築されます。
高度なコンテキストのフォローアップ: 上級チーム向けのフォローアップの質問: シーンと現実が異なる場合、点群からメッシュへの距離メトリクスに基づいて展開を制御しますか? また、許容される最大距離はどれくらいですか?
最も近い症状を選択して、適切なトラブルシューティング パスに従ってください。
クリアランスが狭いゾーンの周りにライブ点群と衝突メッシュを重ね合わせ、体系的なオフセットを検査します。
python tools/export_scene_mesh.py --out scene_mesh.ply
python tools/compare_cloud_to_mesh.py --cloud live_scan.pcd --mesh scene_mesh.ply軌道の再生と物理的なクリアランスプローブが必要です。 メッシュ距離のしきい値違反時のブロック解除。
まずはチェックリストのテンプレートとして使用してください。 実行前に自分のセルでインターフェイス名、フィクスチャ ID、安全条件を確認してください。