フロア横断ディスパッチは、RCSプロジェクトが死ぬ場所です。単一フロアでは見事に動くフリートが、2階層目を加えた瞬間にエレベーターを逃し、タイムアウトし、タスクがデッドロックし始めます。車両が問題になることはめったにありません。AMRは階段を上れないため、エレベーターに依存します。そしてエレベーターは建物全体で共有される資源です。あなたのRCSはロボットを制御します。エレベーターの気まぐれは制御しません。
エレベーターの1回の乗車を分解する
1回のフロア横断移動は、実は5つのフェーズから成ります。呼び出し、待機、入場、乗車、退出です。各フェーズで詰まる可能性があります。プロトコルが一致しなかったため、エレベーターは呼び出しに一度も応答しませんでした。到着したのに、状態信号が落ちたためドアが開きませんでした。ロボットは入場したのに、障害物のためにドアが閉まりませんでした。順調に上がったのに、自己位置がドリフトしたため退出できませんでした。
重要な洞察は、ロボットがエレベーターの状態を推測してはならないということです。エレベーターコントローラーが唯一の信頼できる情報源であり、RCSはその状態機械（かご位置、ドア状態、積載重量、進行方向）からすべてを駆動しなければなりません。4つの信号すべて、例外なしです。そのいずれかを推定したり、タイムアウトから仮定したりするのは、地雷を埋める行為です。
このハンドシェイクには業界のフレームワークがすでに存在するので、プロトコル層をゼロから再発明しないでください。ROS2エコシステムでは、RMF（Robot Middleware Framework）がリフト統合メッセージの完全なセットを定義しています。フリートマネージャーとリフトコントローラーは標準化された状態ハンドシェイクで交渉し、ロボットは実行するだけです。シンガポールのIMDAが策定した商用ビル内AMRの技術ガイドラインも、ロボット・リフト・ドア間のデータ交換を仕様に盛り込んでいます。機器側では、ドイツのLödige Industriesが、OlympusやSherpaラインのような貨物リフトとAGV・AMRが直接通信できるリフト自動化モジュール（公開されている数値で最大20メトリックトン級）を販売しています。カスタムで作る前に、リフトベンダーとミドルウェアが既に対応しているものを確認してください。
エレベーターを呼ぶのは誰か
最初の分岐点は、誰が呼び出しを発行するかです。2つのアーキテクチャがあります。
車両からリフトへの直接接続：ロボットが乗り場に到着し、自分でエレベーターを呼び出します。シンプルですが、1台か2台のデモにしか向きません。スケールアップすると、N台のロボットが同時に呼び出し、エレベーターは四方八方に引っ張られ、全員がかごを奪い合い、誰も動けなくなります。
RCS集中呼び出し：すべてのフロア横断リクエストはまずRCSに集約され、RCSがエレベーターに単一の命令ストリームを発行して、各ロボットを割り当てます。どのかごに、どのフロアへ。本物のフリートにはこれが正解ですが、RCSがキューを所有しなければなりません。私が譲らないキューイング規則は3つです。
方向別の相乗り：同じ方向に向かうロボットを1台のかごにまとめます。エレベーターの往復1回のコストは固定です。かごの中の追加のロボット1台1台が純粋な利益です。
餓死回避つき優先度：緊急のフロア横断オーダーはキューを追い越せますが、待機には上限を設けます。通常タスクは最大Nラウンド待ち、その後は強制的に通します。低優先度タスクを永遠に乗り場で待たせてはいけません。
タイムアウト追放：ロボットが時間予算を超えてかごを占有したら（例えば、入場動作が数分経っても完了しない場合）、RCSはそのかご割り当てからロボットを追い出し、再キューイングします。エレベーターは希少資源です。かごに居座る権利はどのロボットにもありません。
私の結論：フロア横断移動のスケジューリング権限はRCSが持たなければなりません。車両には状態報告だけを残します。到着した、入場した、退出した。責任を分離しないと、障害の原因を解きほぐせません。
エレベーターが止まっても、システムは止めない
エレベーターは機械です。故障します。しかも多くは半壊です。ドアが1つ故障する、あるフロアのボタンが死ぬ、かごが時々非常停止する。ダウングレード計画を3段階で事前に書いてください。
第1段階、単一かご故障：RCSはタスクを自動的に稼働中のかごに再割り当てし、キューはそのままです。これには、現場にロボットが利用できるエレベーターが少なくとも2基必要です。エレベーター1基＋フロア横断業務＝単一障害点です。プロジェクトのキックオフで指摘してください。
第2段階、全エレベーター停止：すべてのフロア横断タスクを停止し、RCSを単一フロアモードに切り替え、同一フロアの作業は継続します。フロア横断の貨物は手動搬送（貨物ルートまたは階段経由のフォークリフトや手押し台車）で動かします。システムは遅くなりますが、止まることはありません。
第3段階、通信喪失：RCSがリフトコントローラーのハートビートを受信しなくなったら、すべての車両は指定の待機地点で停止します。かごへの盲目的な入場は禁止です。これは安全のレッドラインです。あのドアの向こうに本当にかごがあるかは、誰にも分かりません。
トレードオフは正直に：ダウングレード計画は効率と安全を交換するものです。SLAに書き込み、エレベーターが全停止したときに何を保証するのかを顧客と事前に合意してください。最悪の結果は、それを一度も議論せず、起きてから互いを責め合うことです。
フロア横断タスクに公正に価格をつける
フロア横断タスクは、同一フロアのタスクより本質的に高コストです。エレベーターの往復1回と、両端での待機時間を消費するからです。優先度設定の3つの規則です。
オーダーの緊急度で重み付け：運送会社の締め切りと競う出荷タスクには、フロア横断の重みを上げます。
エレベーターの往復をコスト化：エレベーターの往復1回をタスクコストに換算し、スケジューリング時にRCSが満車のかごを優先し、空車運行を最小化します。
重み付けプールを分離：フロア横断タスクを通常タスクと同じ優先度プールでランク付けしてはいけません。独自の重み付け階層を与えます。そうしないと、同一フロアの作業の洪水に埋もれてしまいます。
一言で：エレベーターは建物で最も高価な共有資源です。スケジューリング戦略全体は、空車運行を減らし、待機するロボットをゼロにすることに尽きます。
壁に貼っておきたい落とし穴：マルチロボットのフリートで、ロボット自身にエレベーターを呼ばせないでください。そこが混沌の始まりです。荷重を確認してください。車両＋貨物はエレベーターの定格容量を下回らなければなりません。1キログラムたりとも超過禁止です。これは安全の問題であり、効率の問題ではありません。火災警報インターロックを配線してください。警報が鳴ったらエレベーターは使用停止となり、RCSは信号を受けてすべてのフロア横断タスクを即座に凍結しなければなりません。まずプロトコル統合を行い、それからフリート規模の話をしてください。車両を追加する前に、接続されたコントローラーと滑らかな状態機械を。順序を逆にすると、追加するロボット1台1台が新たな地雷になります。可能であれば、ロボット専用のエレベーターが1基あるのが最もシンプルな生活です。少なくとも、ピーク時間帯のディスパッチ権限は確保してください。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
