<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>安定性 on Physical AI Hub</title>
    <link>https://physicalaihub.net/tags/%E5%AE%89%E5%AE%9A%E6%80%A7/</link>
    <description>Recent content in 安定性 on Physical AI Hub</description>
    <generator>Hugo</generator>
    <language>ja-jp</language>
    <lastBuildDate>Tue, 03 Nov 2026 15:28:56 +0900</lastBuildDate>
    <atom:link href="https://physicalaihub.net/tags/%E5%AE%89%E5%AE%9A%E6%80%A7/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>移動マニピュレーターの全身動作計画：台車とアームを同時に最適化する方法</title>
      <link>https://physicalaihub.net/posts/mobile-manipulator-whole-body-motion-planning/</link>
      <pubDate>Tue, 03 Nov 2026 15:28:56 +0900</pubDate>
      <guid>https://physicalaihub.net/posts/mobile-manipulator-whole-body-motion-planning/</guid>
      <description>&lt;p&gt;台車とアームを別々に安全と判断しても、全身では別の問題が現れる点が気になります。&lt;/p&gt;&#xA;&lt;h2 id=&#34;先に結論&#34;&gt;先に結論&lt;/h2&gt;&#xA;&lt;p&gt;移動マニピュレーターの全身動作計画では、台車とアームを別々に計画するのではなく、台車姿勢とアーム関節を結合した一つの構成空間として扱うのが基本です。平面移動なら台車状態をSE(2)、高さや姿勢も変化するならSE(3)として表し、全身状態を &lt;code&gt;q=[q_base,q_arm]&lt;/code&gt; とします。&lt;/p&gt;&#xA;&lt;p&gt;この状態と軌道に対して、エンドエフェクタの可到達性、台車・アーム・把持物を含む衝突、支持多角形に基づく安定性を同じ検証ループで評価します。衝突と安定性はハード制約、可操作性、経路長、台車移動量、クリアランスなどは目的関数またはソフト制約として分けると、設計意図を明確にできます。&lt;/p&gt;&#xA;&lt;p&gt;MoveItのPlanning Sceneはロボット状態、環境中の衝突物、付着物を管理し、衝突判定に利用できます。一方、Nav2のフットプリントは主に台車外形を2Dコストマップ上で扱う仕組みです。これらだけでアームの掃引体積やペイロード依存の安定性まで自動的に統合されるわけではないため、共有状態モデルと追加の妥当性判定が必要です。&lt;/p&gt;&#xA;&lt;h2 id=&#34;なぜ統合が必要なのか&#34;&gt;なぜ統合が必要なのか&lt;/h2&gt;&#xA;&lt;p&gt;台車だけを見れば障害物を避けていても、アームのリンクや把持物が接触することがあります。反対に、アームの逆運動学が解けても、その姿勢で重心が支持領域の外側へ移動すれば、転倒余裕が小さくなる可能性があります。台車姿勢が変われば、同じ関節値でもエンドエフェクタの位置、障害物との距離、可到達性が変化するためです。&lt;/p&gt;&#xA;&lt;p&gt;Nav2では円形または多角形のフットプリントを設定し、台車の衝突・通行可能性をコストマップで評価します。しかし、アームのリンク形状、把持物、アームの動作による掃引体積までは自動的に表しません。MoveItのPlanning Sceneはロボットリンクと環境形状を含む3D衝突モデルに向いていますが、Nav2のフットプリントや安定性評価との同期は別途設計する必要があります。&lt;/p&gt;&#xA;&lt;h2 id=&#34;用語と内部の仕組み&#34;&gt;用語と内部の仕組み&lt;/h2&gt;&#xA;&lt;p&gt;可到達性はアーム単体の性質ではありません。台車姿勢と、エンドエフェクタに許される位置・姿勢の組み合わせとして評価します。Task Space Regionは許容されるエンドエフェクタの位置・姿勢領域を表し、その範囲でのIK可解性を計画へ組み込むために利用できます。&lt;/p&gt;&#xA;&lt;p&gt;候補状態 &lt;code&gt;q&lt;/code&gt; について、まず台車姿勢とアーム関節から全リンクの姿勢を計算します。次に、エンドエフェクタが目標領域に入るか、IKが解けるかを確認します。そのうえで、台車、アーム、把持物と環境の衝突を判定し、支持多角形と重心投影、または設定した転倒余裕を評価します。アーム姿勢、ペイロード、把持物の位置が変わると重心も変わるため、安定性はアーム計画から切り離せません。&lt;/p&gt;&#xA;&lt;p&gt;サンプリング型計画では、ウェイポイントだけでなく状態間のモーションも検証します。ウェイポイントが安全でも、補間区間でアームや把持物が障害物を横切る可能性があるためです。状態妥当性チェッカーとモーション妥当性チェッカーを分ける構成では、全身軌道の区間にも衝突・安定性検証を適用します。補間分解能、形状近似、連続衝突検出の有無によって検証精度が変わる点には注意が必要です。&lt;/p&gt;&#xA;&lt;p&gt;計画問題は次のように分けると扱いやすくなります。&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;ハード制約：関節限界、全身衝突、支持条件、設定した安定余裕&lt;/li&gt;&#xA;&lt;li&gt;ソフト目的：経路長、台車移動量、可操作性、クリアランス、速度・加速度&lt;/li&gt;&#xA;&lt;li&gt;目標条件：エンドエフェクタの位置・姿勢、または許容姿勢領域&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;figure class=&#34;mermaid-figure&#34;&gt;&#xA;    &lt;pre class=&#34;mermaid&#34; role=&#34;img&#34; aria-label=&#34;台車、アーム、把持物、環境を共有状態モデルで扱い、可到達性・全身衝突・安定性を状態と軌道区間の両方で検証する計画ループ。&#34;&gt;flowchart LR&#xA;  S[&#34;環境センサ・ロボット状態&#34;] --&gt; W[&#34;共有ワールドモデル\n台車・アーム・把持物・環境・予約済み空間&#34;]&#xA;  W --&gt; B[&#34;台車候補姿勢・粗い経路の生成&#34;]&#xA;  W --&gt; Q[&#34;全身状態 q=[q_base,q_arm] の生成&#34;]&#xA;  B --&gt; Q&#xA;  Q --&gt; IK[&#34;全身IK・可到達性評価\nTask Space Region を確認&#34;]&#xA;  IK --&gt;|&#34;可解&#34;| C[&#34;全身衝突判定\n台車・アーム・把持物・環境&#34;]&#xA;  IK --&gt;|&#34;不可解&#34;| R[&#34;候補を除外&#34;]&#xA;  C --&gt;|&#34;衝突なし&#34;| ST[&#34;安定性評価\n支持多角形・重心投影・設定した安定余裕&#34;]&#xA;  C --&gt;|&#34;衝突あり&#34;| R&#xA;  ST --&gt;|&#34;条件を満たす&#34;| O[&#34;軌道最適化\n経路長・台車移動量・可操作性・クリアランス&#34;]&#xA;  ST --&gt;|&#34;条件を満たさない&#34;| R&#xA;  O --&gt; V[&#34;補間軌道全体の検証\n状態と軌道区間の衝突・安定性&#34;]&#xA;  V --&gt;|&#34;妥当&#34;| E[&#34;軌道実行&#34;]&#xA;  V --&gt;|&#34;不妥当&#34;| R&#xA;  E --&gt; X[&#34;環境またはロボット状態の変化&#34;]&#xA;  X --&gt; S&lt;/pre&gt;&lt;figcaption&gt;台車、アーム、把持物、環境を共有状態モデルで扱い、可到達性・全身衝突・安定性を状態と軌道区間の両方で検証する計画ループ。&lt;/figcaption&gt;&lt;/figure&gt;&lt;h2 id=&#34;計画方式の比較&#34;&gt;計画方式の比較&lt;/h2&gt;&#xA;&lt;table&gt;&#xA;  &lt;thead&gt;&#xA;      &lt;tr&gt;&#xA;          &lt;th&gt;方式&lt;/th&gt;&#xA;          &lt;th&gt;特徴&lt;/th&gt;&#xA;          &lt;th&gt;向いている場面&lt;/th&gt;&#xA;          &lt;th&gt;主な制約&lt;/th&gt;&#xA;      &lt;/tr&gt;&#xA;  &lt;/thead&gt;&#xA;  &lt;tbody&gt;&#xA;      &lt;tr&gt;&#xA;          &lt;td&gt;別計画&lt;/td&gt;&#xA;          &lt;td&gt;台車経路とアーム動作を独立に生成&lt;/td&gt;&#xA;          &lt;td&gt;単純な環境、動作範囲が明確な場合&lt;/td&gt;&#xA;          &lt;td&gt;全身衝突や安定性の不整合を見落としやすい&lt;/td&gt;&#xA;      &lt;/tr&gt;&#xA;      &lt;tr&gt;&#xA;          &lt;td&gt;階層方式&lt;/td&gt;&#xA;          &lt;td&gt;台車候補や粗い経路を先に作り、全身IK・衝突・安定性で絞り込む&lt;/td&gt;&#xA;          &lt;td&gt;計算量を抑えたい場合&lt;/td&gt;&#xA;          &lt;td&gt;先に除外した台車姿勢を後段で使えない&lt;/td&gt;&#xA;      &lt;/tr&gt;&#xA;      &lt;tr&gt;&#xA;          &lt;td&gt;全身同時最適化&lt;/td&gt;&#xA;          &lt;td&gt;台車とアームの変数を同時に探索・最適化&lt;/td&gt;&#xA;          &lt;td&gt;狭い環境、把持姿勢と台車位置の依存が強い場合&lt;/td&gt;&#xA;          &lt;td&gt;状態空間が大きく、計算量とモデル設計が難しい&lt;/td&gt;&#xA;      &lt;/tr&gt;&#xA;      &lt;tr&gt;&#xA;          &lt;td&gt;ハイブリッド方式&lt;/td&gt;&#xA;          &lt;td&gt;候補生成、全身IK、最適化、軌道検証を組み合わせる&lt;/td&gt;&#xA;          &lt;td&gt;実装と性能のバランスを取りたい場合&lt;/td&gt;&#xA;          &lt;td&gt;各層の状態・環境同期が必要&lt;/td&gt;&#xA;      &lt;/tr&gt;&#xA;  &lt;/tbody&gt;&#xA;&lt;/table&gt;&#xA;&lt;h2 id=&#34;実装構成と使いどころ&#34;&gt;実装構成と使いどころ&lt;/h2&gt;&#xA;&lt;p&gt;現実的な出発点は階層型です。まず台車候補姿勢、または粗いベース経路を生成します。次に各候補について全身IKと可到達性を評価し、目標を実現できる候補だけを残します。その後、Planning Sceneなどで台車・アーム・把持物・環境の衝突を判定し、安定性評価を加えた全身計画または軌道最適化を行います。最後に補間された軌道全体を検証し、環境やロボット状態が変化した場合は再計画します。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
