Open-RMF 座標はロボットフリートや施設資源全体で機能します。ディスパッチはフリートを選択し、フリートアダプターはRMFとベンダーシステム間で翻訳を行い、交通スケジュールは時間依存の旅程を共有し、ドアやリフトアダプターは移動意図を建物機器に接続します。各境界はそれぞれ独自の責任を負います。
ロボットの定位、 SLAM、障害物回避、低レベルのモーションコントロールの代わりにはなりません。接続されたアダプターでも、地図やフレーム、ウェイポイント、時間が不一致するとロボットを誤った場所に送ることがあります。成功した統合には、メッセージ交換だけでなく国家の合意と回復が必要です。
このガイドは フリート割り当てガイド や ロボットフレームガイドと一緒に使ってください。まずはシミュレートや単一リソースのテストから始め、その後施設へと拡大しましょう。
オーケストレーションレイヤーに配置Open-RMF
公式 Open-RMF リポジトリ では、複数フリートのロボット管理プラットフォームについて説明されています。ベンダーナビゲーションシステム上でタスク、トラフィック、共有インフラを調整します。失敗を割り当てたり、RMFがロボット局所知の欠陥を修復すると約束したりする前に、この層境界を引いてください。
すべての記録システム(タスク、ロボットの状態、地図、ドア、エレベーター、ユーザー権限)をリストアップしてください。どのコンポーネントがコマンドを行えるか、どのコンポーネントが観察のみできるかを定義します。1つのロボットや施設セッションに対して2人の権威あるライターがいると、各APIが正しく動作してもリカバリーが競合します。
タスクをディスパッチからロボットの実行まで追跡する
タスクリクエストはディスパッチャーに入力され、候補フリートが評価し、アワードによって実行者が選ばれます。その後、フリートアダプターはタスクをベンダー固有の計画やコマンドに変換し、進捗を報告します。すべての翻訳でタスクの識別子と状態を保持すること。
依頼時間、入札または見積もり、授与、アダプターの受理、ロボットの実行および完了を記録します。重複または期限切れの賞は冪性的に拒否してください。ディスパッチャーの成功は、物理的なワークフローと必要な納品証拠が完了するまで最終タスクの成功にはなりません。
| 境界 | 入力 | 出力 | 一次故障 |
|---|---|---|---|
| ディスパッチャーからフリートへ | 課題と制約 | 受賞歴 | 実現可能な入札も古くなっていない |
| RMFからアダプターへ | 計画と旅程 | ベンダーからの要請 | 翻訳ミスマッチ |
| ロボットへのアダプター | ベンダーコマンド | ロボット状態 | 拒否または古くなったコマンド |
| RMFからドアへ | アクセスリクエスト | ドアセッション/状態 | 間違った飼い主か、返答がないか |
| RMFをリフトに | フロアとキャビンセッション | 揚力状態 | セッションまたは占有の対立 |
フリートアダプターをインターフェース境界として扱う
アダプターは、RMFとベンダーフリートAPI間でロボットの名前、ポーズ、バッテリー、モード、経路進行、タスクコマンドをマッピングします。すべてのフィールド、単位、状態、誤差に対して換算ルールを作成しましょう。心拍からアクティブな動きを推測したり、未知のベンダー状態をアイドルに変換しないでください。
Free Fleetリポジトリはサポートシステム向けの統合パスを提供しますが、本番契約はベンダーごとに異なります。アダプターの更新速度、使用年数、再接続の挙動を測定してください。正規化されたRMF状態のほかに生のベンダーエラーも保持してください。
交通スケジュールの時間的側面を理解する
RMF交通調整は、占有中の地図点だけでなく、計画された軌道と時間を用います。遅延や経路変更、休止は旅程を更新し、他の参加者が現在の意図に反して交渉できるようにすべきです。スケジュール更新なしでローカルで逸脱するロボットは、競合予測を無効にする可能性があります。
選択したスケジュール許容範囲に合った時計を十分に同期させ、データの年齢をモニターします。遅延アップデートと再接続をテストしてください。 ロボットの時間同期ガイド を使って、クロックオフセットとネットワークやアダプターの遅延を区別してください。
ドアの意図を施設の状態に結びつける
ドアアダプターは、要求されたアクセスセッションを実際の建物制御と状態に変換します。モデルリクエスター、ターゲットモード、現在モード、タイムアウト、リリース。ロボットは開いたコマンドが送信されたため、閾値を超えてはいけません。ドアの状態とルートクリアランスの確認が必要です。
テスト:アクセス拒否、開閉が遅い、障害物、手動オーバーライド、コントローラー再起動、そしてロボットがドア口で止まっている。RMFが待機、ルート変更、キャンセルのいずれかを定義します。施設の安全とアクセスコントロールはドアに対する権限を保持します。
| 施設試験 | 注入状態 | 予想されるオーケストレーション | 必要な証拠 |
|---|---|---|---|
| ドアディレイ | 遅いオープンステート | ロボットは閾値の前で待つ | 要求と検証された状態 |
| ドア拒否 | アクセス拒否 | ルート変更または失敗タスク | 理由と権威 |
| リフトセッションの損失 | オーナーが行方不明 | 有界クリーンアップ | キャビンとロボットの乗員数 |
| 間違った階だ | 状態の不一致 | 終了コマンドなし | フロアセンサーとセッション |
| 手動オーバーライド | 人間が機器を交換する | 一時停止自動化 | モードとオペレーターの同一性 |
リフト使用をセッションと占有の問題として扱う
リフトのワークフローには、呼び出し、キャビンセッションの取得、正しいキャビンとフロアの確認、進入、目的地の選択またはリクエスト、乗車、到着の確認、出発、解放が含まれます。単一のボタンコマンドではこれらの所有権および居住状態を表現することはできません。
他のユーザーが入ってくる、ドアが再び開く、床の不一致、ロボットの位置特定喪失、キャビン内の通信障害などをテストします。誰が古くなったセッションをリリースできるかを決めてください。キャビンを別のロボットに割り当てる前に、物理的な居住証拠を活用してください。
地図名、フレーム、ウェイポイントの意味を整列する
RMFマップ、ベンダーマップ、施設フロア名は異なる起源、縮尺、軸、識別子を用いることがあります。複数の測量点で変換を校正し、一つの翻訳だけでなく見方も検証してください。数値的に有効な変換はルートをミラーリングまたは回転させることができます。
バージョンマップ変換とウェイポイント。すべてのドアとエレベーターの出入り口を両方向からテストしてください。未知の地図名は明示的に拒否すること;デフォルトの階を静かに使うと、ロボットが間違った物理的な場所に動くことがあります。
1つのワークフローでコンポーネントの状態を追跡
各タスクごとに、ディスパッチャーの状態、アダプターの状態、ベンダータスク、ロボットのポーズとモード、交通行程、施設リクエスト、リソースセッションを関連付けます。タイムスタンプと識別子を一つのトレースにまとめます。これにより、最も初期の意見の相違が見えてくる。
単一の緑色統合インジケーターは避けてください。古いデータ、セッションオーナー、そして最後の成功した移行データを露出させましょう。ロボットがドアの前で停止した場合、オペレーターはそれが交通、アクセス、ドアの状態、ナビゲーション、アダプターの確認を待っているかどうかを知る必要があります。
自動回収前に故障所有権を割り当ててください
故障をロボットローカル、ベンダーフリート、アダプター、RMFコア、ネットワーク、または施設に分類してください。どのレイヤーがリトライし、どのレイヤーが報告のみを行うかを定義します。同じコマンドを複数レイヤー繰り返し行うと、重複やルーティングチャン、またはドア操作の繰り返しが発生することがあります。
最初の故障と各回収試みを保存してください。再試行を制限し、証拠の変更を求める。持続的な故障を報告する建物コントローラーは、施設運営にエスカレーションされるべきであり、終わりのないロボットの再計画を引き起こすべきではありません。
シミュレーションから一度に一つのリソースへ統合する
Open-RMFデモンストレーションを使ってフローを理解し、その後シミュレートされたフリートアダプターを接続します。物理的なロボット1台、通路1台、ドア1台、リフトフロア1台に移行し、多くの同時作業を可能にする。
各段階で、通常のワークフローや失敗したワークフロー、キャンセル、再起動、手動の引き継ぎを繰り返します。 ROS 2、 Open-RMF パッケージ、アダプター、施設APIのフリーズバージョンを使います。証拠やロールバックが再現可能である場合にのみ拡張してください。
VDA 5050とOpen-RMFは明確な境界線で保つ
VDA 5050 は中央制御と移動ロボット間の通信インターフェースを規定し、 Open-RMF はより広範な複数フリートおよび施設のオーケストレーションを提供します。それらはアダプターを通じて交差できますが、両方に名前を付けることでマッピングや責任が定義されるわけではありません。
どのコンポーネントがマスターコントロールとして機能するか、命令や状態がどのようにマッピングされているか、誰が交通や施設のリソースを所有しているかを文書化してください。VDA 5050ガイドを使ってプロトコルの挙動を独立してテストしてください。
厳重な警備、手動回収および作戦
制御インターフェースの認証、ネットワークの分割、派遣、施設開放、セッションのオーバーライドを制限する。ログオペレーターの行動。通常状態の間に立ち往生したロボットやリフトの安全な手動回復方法、物理的アクセスやタスクの調整を定義します。
境界チェックリストをつけてリリースしましょう。
- 各タスク、ロボット、施設の状態に対して1つの権限を割り当てます。
- 地図と時間の換算を測定された証拠で検証します。
- ドアやエレベーターを所有セッションとしてテストしてください。
- バウンドは責任ある層で再試行します。
- 再開、手動の取り越し、状態の照合を証明してください。
よくある質問
ロボットSLAMやナビゲーションに代わるものOpen-RMFでしょうか？
いいえ。車両、交通、資源を調整しつつ、ベンダーやロボットシステムはローカライズとモーションコントロールを維持します。
ベンダーAPIだけでフリートアダプターを構築するのに十分でしょうか？
統合契約で求められるコマンド、状態、タイミング、キャンセル、エラーの意味論を公開している場合のみです。
すべてのドアとエレベーターは一つのプロトコルを使わなければならないのでしょうか？
いいえ。リソース固有型アダプターは異なるプロトコルを翻訳できますが、状態およびセッションの意味論は一貫していなければなりません。
プロジェクトは Open-RMF と、 VDA 5050のどちらかを選ばなければならないのでしょうか？
必ずしもそうとは限りません。これらは異なるスコープに属し、定義されたアダプターや権限モデルを通じて接続可能です。
どの失敗を最初にテストすべきでしょうか？
各境界でステイル状態やロスト状態から始めましょう。これにより権威、タイムアウト、回復の仮定がすぐに明らかになります。
オーケストレーションおよび施設制御境界
Open-RMF の調整はロボットの安全性、建物のアクセス制御、リフトの安全性、緊急手順を上書きしません。これらのシステムは必要な権限を保持しています。