フォークリフトとAMRの衝突防止、同じ通路を走るときに座標を渡して回避する仕組み
2026-09-16
フォークリフトとAMRの衝突防止を考えるとき、まず思い浮かべていただきたいのは、ラックが6メートルほどの高さまで積み上がった通路の端、T字に分かれる交差点です。一方からはAMRがトートを載せて決められた経路を進んできて、もう一方からはフォークリフトがパレットを持ち上げたままラックの端を回って出てきます。二台はまだお互いを見ていません。ラックが視界を遮っているからです。AMRのLiDARがフォークリフトを捉えるのは、フォークリフトの前輪が交差点に入った後で、そこから減速を始めても残る距離は数メートルしかありません。
AMRを導入してフォークリフトと混在させる工場が増えるにつれ、この場面が新しい問題になりました。フォークリフトしか走っていなかった頃は、運転者同士がクラクションと目配せで交差点をやり過ごしていました。AMRはクラクションを聞くことも、目配せを読むこともできません。自分のセンサーに映るものだけを避けます。そのためライン増設の会議では「AMRの区間とフォークリフトの区間を完全に分けよう」という話が出ますが、通路が一本しかない区間ではそれができません。
お問い合わせを受けてみると、質問の形はほとんど同じです。フォークリフトの位置をリアルタイムの座標で受け取ってAMRを制御できるか、人と物流機器の位置を上位システムで一緒に見て動きを調整できるか、というものです。この記事では、その質問に答えるフォークリフトとAMRの衝突防止の構成を整理します。要点は一行です。フォークリフトの座標をAMRに渡しつつ、避けるかどうかはAMRに判断させます。
I. LiDARは見えるものしか避けられません
「AMRにはLiDARが付いているのだから、自分で避けるのではないか」。導入検討の場で最初に出る反論で、半分は正しいです。LiDARは視界に入った障害物を正確に捉え、AMRはその手前で止まるか迂回します。問題は視界です。LiDARは光が直進する範囲しか見えません。ラックの端を回って出てくるフォークリフトは、ラックに隠れている間は存在しない物体であり、ラックから出た瞬間に突然現れる物体です。
フォークリフト側にも事情があります。パレットを持ち上げたフォークリフトは積載重量の分だけ制動距離が長くなり、マストが運転者の視界を遮ります。LiDARがフォークリフトを見た時点で、AMRとフォークリフトの両方がすでに急制動の区間に入っていれば、残された選択肢は急停止だけです。急停止は事故を防ぎますが、積載物が偏り、繰り返されればAMRの運行計画全体が遅くなります。
ですから必要なのは、より高性能なLiDARではなく、LiDARに見える前に接近を知らせる情報、つまり接近検知です。フォークリフトが交差点から15メートル離れた通路をどのくらいの速度で向かってきているかをAMRが事前に知っていれば、急停止ではなく減速と進入待機で切り抜けられます。
前回の記事「ロボットは自分の位置を知っているが、人の位置は知らない」では、人にタグを持たせてロボットの地図の上に載せる方向を扱いました。今回の記事は方向が逆です。フォークリフトにタグを取り付け、その座標をAMR制御システムに渡します。
II. UWB位置測位の座標は渡しますが、判断はAMRが行います
フォークリフトとAMRの衝突防止の構成は四つの段階です。フォークリフトに固定したUWBタグが信号を発し、通路上部のTwinTracker UWBがその信号を受信します。ORBRO Serverが受信時刻の差から座標を計算し、工場のレイアウト図を基準とした位置に変換します。そしてフォークリフトのID、座標、測定時刻、有効状態をひとまとめにしてAMR制御システムに送ります。
ここで一本の線を引きます。渡すのは座標であって、命令ではありません。減速するか、停止するか、迂回するかは、AMR制御システムが自分の経路とフォークリフトの接近位置を比較して判断します。理由は二つあります。第一に、AMRの経路と積載状態と制動特性を知っているのはAMRだからです。第二に、AMRにはすでに自前の安全センサーと安全定格の機能があり、上位システムから入ってくる座標はその安全対策を置き換えるものではなく、それより先に届く補助情報だからです。座標が途切れてもLiDARは動き続けます。
同じ理由で、通信が途切れたり座標の到着が遅れたりしたときにAMRがどう動くかは、私たちが決めません。AMRメーカーと一緒に定義します。最後の座標を何秒まで信用するか、その後は交差点の手前で待機するのか、LiDARだけで通過するのかは、ロボットの運行基準に属する問題だからです。
測定時刻と有効状態を座標に付けて送るのも同じ文脈です。座標だけが届いても、AMRにはその値がたった今のものか3秒前のものか分かりません。時刻が付いていてこそ古い値を捨てられ、有効状態が付いていてこそ受信品質の低い値を制御入力から外せます。
III. 二つの地図の原点が一致していなければなりません
座標を渡す前に解決すべき問題があります。UWB位置測位で計算した座標と、AMRが使う地図座標が、同じ原点と同じ軸方向を使っていなければなりません。二つのシステムがそれぞれ自分の原点を持っていると、同じフォークリフトがAMRの地図上では見当違いの通路に表示されます。
そこで工場のレイアウト図を共通の基準にします。主要な通路と基準点を数か所、現場で直接測り、その値でUWB座標をAMRの地図座標に変換する変換値を定めます。生産ラインやラックの配置が変われば、この変換値も取り直さなければなりません。レイアウトが変わったのに変換値がそのままだと、座標は正確なのに地図が間違っている状態になります。
受信機の位置も視界と同じ論理で決めます。TwinTracker UWBは工場のH形鋼と通路上部に設置し、ラックの端とAMRの交差区間を先に覆うように高さと向きを決めます。設備や積載物のない空の工場で測った受信範囲は当てになりません。実際に設備とパレットが置かれた稼働状態で、フォークリフトの座標が途切れずにつながるかを通路ごとに確認します。
タグはフォークリフトのヘッドガードに取り付けます。UWB Tag RU-O3405は66×50×20mmのサイズで、左右の取り付け翼で固定し、振動に耐えるように設置します。取り付け位置を決めるときは、マストが信号を遮らないか、交代時間に電源をどう維持するか、整備の動線に干渉しないかを先に確認します。タグが一つでも正しく取り付けられていないと、そのフォークリフトは地図から消え、AMRはそのフォークリフトを再びLiDARだけで相手にすることになります。
IV. フォークリフトとAMRの衝突防止は四つの状況に分けて試験します
連携が機能するかどうかは、一度通過してみるだけでは確認できません。正常なときはどんな構成でもうまく動きます。差が出るのは正常でないときです。そのため状況を四つに分けて繰り返し試験し、毎回の試験で座標の伝達状態とAMRの結果を一緒に記録します。
| シナリオ | 座標の伝達状態 | AMRに期待する動作 | 記録する項目 |
|---|---|---|---|
| 正常通過 | フォークリフトの座標が正常に更新 | 接近を事前に認識して減速し、通過後に復帰 | 減速開始距離、通過所要時間 |
| 交差接近 | 双方が同時に交差点へ接近 | 進入待機または迂回 | 待機位置、再出発の時点 |
| 急停止 | フォークリフトが交差点の直前で急加速 | 停止 | 停止までにかかった時間、積載物の状態 |
| 通信断 | 座標の受信が中断または遅延 | メーカーと定義した動作（待機またはLiDAR単独で通過） | 最後の座標の時刻、復旧の時点 |
四行目には正解がありません。その欄はAMRメーカーと一緒に埋め、埋まってから初めて連携を運用に乗せます。
試験にはフィルタリングも含まれます。登録済みのフォークリフトのタグと、別の区域から入ってきた信号を区別し、座標品質が低い値や最終受信時刻が古い値は制御入力から除外します。フィルターを変更したらその前後を比較し、外部のタグは除外されつつ正常な対象は残るかを確認します。フィルターを強くかけすぎると肝心のフォークリフトが抜け落ち、弱すぎると隣の区域のフォークリフトのせいでAMRが止まります。
試験の履歴は捨てません。どの交差点でどんな条件のときに減速がどれだけ早く始まったかが残っていれば、次の生産ラインの受信機配置と連携条件を決めるときにその記録が根拠になります。
V. フォークリフトとAMRを混在させる導入時の検討事項
- どの交差点から始めるかを決めます。高いラックと設備が視界を遮る交差通路が優先です。通路幅と車両の制限速度を反映して、進入待機区間と減速判断区間を設定します。
- 座標の更新条件を運用基準に合わせます。車両の速度が速く、通路が狭いほど、更新は細かくなければなりません。
- AMRメーカーと定義する項目をリストにします。入力形式、許容遅延、通信断時の動作、有効状態の判定基準です。このリストがなければ、試験表の四行目が空のまま運用が始まります。
- フォークリフトのタグの電源と点検を運用手順に入れます。交代時間にタグの状態を確認する一行が手順にあってこそ、地図から消えるフォークリフトが生まれません。
- 配置が変わったら再校正の日程を一緒に組みます。ラックを移設する工事計画に座標変換値の再確認を一項目として入れておけば、工事の翌日にAMRが見当違いの通路で止まることはありません。
おわりに
同じ通路を使う工場でフォークリフトとAMRの衝突防止を決めるのは、より敏感なセンサーではなく、見える前に知る情報です。フォークリフトの座標を捉えてAMRに渡し、判断はAMRに任せ、正常でない四つの状況をあらかじめ試験しておく。それがこの構成のすべてです。
ORBROはこの構成を一式で提供します。TwinTracker UWBがフォークリフトの座標を受信し、ORBRO Serverが工場座標に計算してAMR制御システムに渡し、同じ座標がORBRO OSのレイアウト図の上にフォークリフトとAMRと人の位置として一緒に表示されます。位置測位システムが何で構成されるかは「UWB位置測位システムは何で構成されるのか」で、カメラでフォークリフトと人の衝突リスクを捉える方法は「フォークリフトの衝突防止、AIカメラによる危険区域検知」で扱いました。フォークリフトとAMRの衝突回避の構成はソリューションページにまとめてあります。どの交差点が問題なのか、AMRメーカーはどこなのかをお知らせいただければ、その区間から一緒に検討いたします。
