25
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Cisco Systems JapanAdvent Calendar 2022

Day 14

UWBによる測位と意思決定のあり方について

Last updated at Posted at 2022-12-13

最近少し気になることがあったので、UWBという無線による測位について調べてみました。

Ultra Wideband (UWB)

UWB1は、Ultra Widebandの略で、無線の通信技術の一つです。直訳すると「超広帯域」なのですが、通信方式や規格を意味する場合が多いようです。

500MHz以上の帯域幅2を使って通信します。通信帯域が広いとマルチパス3に強いという特徴があります。マルチパスに強いと送信機から受信機までの距離を比較的正確に計測できるという利点があります。

Real-Time Locating System (RTLS)

RTLS4は「リアルタイム位置測位システム」と訳されるようです。

とある空間の中で対象となるモノの位置をリアルタイムに計測するシステムです。基準となるモノ(アンカー)を3つ以上用意して、対象となるモノ(タグ)との距離を計測して、三点測位からタグの位置を計算します。

測位の精度は、タグとアンカーの距離をどれだけ正確に計測できるかによります。距離を計測することを測距といいます。電磁波がタグからアンカーに到達する時間(ToF: Time of Flight)に光速cをかけると距離が得られます。

レーザーを使うとmmオーダーで測定できますが、距離が数メートルで、かつ間に障害物がないことが条件になります。また、電波強度(RSSI)を使う方法は、マルチパスの影響を受けやすいため精度がmオーダーになります。UWBは、マルチパスの影響を受けにくく、ある程度の大きさの障害物であれば影響を受けません。また、数十メートル離れていてもcmオーダーの精度がでます。したがって、比較的広い空間で正確な距離を計測したい場合はUWBが使われるようです。

RTLSの技術は、sweioの比較表5が簡潔にまとまっているので参考にしてみてください。

UWB RTLSで使われる測距技術は用途に応じてTWRとTDoAが使われるようです。

Two-Way Ranging (TWR)

TWRは、IEEE 802.15.4a-2007 Annex D 1.3に記述があります。タグとアンカーの時刻を同期させなくても距離を計測できることが特徴です。

TWRは、その名の通りタグとアンカーがそれぞれメッセージを1つ送信します。しかし、この方法では「高精度の時計」を使っても誤差が1m以内に収まらないため、もう1つメッセージを追加したSymmetrical Double-Sided TWR (SDS-TWR)が一般的に使われるようです。

図はSDS-TWRのフローです。

twr.png

初めにタグからアンカーに対して開始のメッセージ(Poll)を出します。それを受信したアンカーは、タグに対して応答メッセージ(Response)を返します。最後にタグからアンカーに対して完了メッセージ(Final)を送信します。タグの識別子Tag-IDと、それぞれのメッセージの送信時刻、受信時刻がアンカーに集まります。タグは少なくも3箇所以上のアンカーとこのメッセージのやり取りを行います。

それぞれのアンカーは集められた数値からタグとの距離を計算してRTLSサーバに送信します。RTLSサーバは集められた数値から三点測位でタグの位置を計算します。ToFを計算する方法はいくつかあるので比較論文6を参考にしてみてください。

Pollメッセージに対して複数のアンカーが応答しそうですが、アンカー同士が時刻を同期させて使用するスロットを決めておいたり、事前にアンカーの識別子をタグに仕込んでおいて、特定のアンカーの識別子をPollメッセージに入れたりと、いくつか方法があるようです。

タグが1つの場合で誤差が許容できるならば、最初のメッセージはアンカーから送信できるので元のTWRを使う選択肢もあります。いずれにしても、3箇所の計測が終わるまでにタグが動いてしまうと三点測位ができなくなります。このためTWRやSDS-TWRは、タグが高速で移動する場合には使えません。

Time-Difference-of-Arrival (TDoA)

TDoAは、IEEE 802.15.4a-2007 Annex D 1.4に記述があります。TWRとは違い、タグと全てのアンカーの時刻を同期させる必要があります。

図はTDoAのフローです。

tdoa.png

タグは識別子Tag-IDと送信時刻t0を含めたメッセージ(Blink)を出します。Blinkメッセージを受信したアンカーは受信時刻t1からタグとの距離を計算してアンカーに送信します。RTLSサーバは集められた距離からタグの位置を計算します。Blinkメッセージが届く範囲にアンカーを3つ以上設置することもポイントになります。

メッセージを1つ送信するだけで計測できるという特徴は下記の利点を生みます。

  • 高速に移動するタグでも計測できる。
  • タグの電池寿命はTWRと比較すると長くなる。
  • メッセージの混信7が減るため多くのタグを扱う、または細かい時間粒度で測位できる。
  • タグはアンカーを識別する必要がないため、アンカーを簡単に増やすことができる。

ただし、時刻を同期させることは簡単ではないため、システムが高価になりがちです。また、時刻の精度が許容範囲を超える前に時刻を合わせる必要があります。

時刻と測距の誤差

一般的に時刻はReal Time Clock(RTC)モジュールから取得します。そして汎用的なRTCモジュールは、「刻み」を491520回カウントして1秒8としています。つまり汎用RTCモジュールの時間分解能は約2us(= 1/491520 = 2.0345e-6)になります。

UWB RTLSは距離の計測に電磁波を使いますが、電磁波は1usの間に約300m進みます。1nsで約30cmです。30cmの移動を計測しようとすると1ns以下の分解能が必要になります。つまり汎用的なRTCモジュールを使っていては600m以下の距離の計測ができないのでcmオーダーの計測には使い物になりません。

そのため、専用モジュールを使うことになります。しかし、専用モジュールを使っても「刻み」は常に同じ時間幅ではなく無視できない揺れがあります。また、タグとアンカーが時刻を含んだメッセージを電磁波に載せて相手に伝えますが、電磁波が空間を伝わる間にも様々な物理的な影響を受けます。

MicrochipのUWBモジュールATA8352の資料9によると、165psの時間分解能で、±4.5cmの距離分解能になるようです。Quobo10やInpixon11など他社の製品仕様を見ても15cmから30cmとなっています。

UWB RTLSはcmオーダーというのも納得できます。

高速度カメラの性能

さて、唐突ですが、ここで高速度カメラの性能について考察しておきます。

Phantom12やFastcam13など、世の中には4K(4096×2160)の大きさで1000fpsで撮影できるカメラがあります。1000fpsのカメラでは1msの映像を1コマに記録します。仮に30m/sで直進する物体を考えると、1msに進む距離は3cmになります。コマ送りしても次の瞬間には3cm進んでいることになります。言い換えると、3cm以下の移動をとらえることは不可能ということです。ちなみに、30m/sで移動する物体の1mmの移動を捕らえるには30000fpsの性能が必要になります。

解像度を下げたり、撮影する範囲を狭めたり、高速でストロボをたいたりと条件をつけると20000fpsで撮影できるという製品もありますが、屋外で数十メートルの距離から撮影するというのは現実的ではありません。

Hawk-Eyeの性能

次に、テニスの世界大会でよく使われるHawk-Eyeについて考察してみます。

Hawk-Eyeは簡単にいうと映像からボールの移動を予測して軌跡を表示するシステムです。SONYの解説14では、「8~12台のカメラで、1秒あたり最大340フレームのフレームレート(静止画像数)で実行」とありますので、複数のカメラからの映像を合成すると実質的には1000fps以上で様々な角度からの映像を集められると予想できます。また、「時速200kmを超えるテニスボールの軌道も誤差2mm以内で予測できる」とあります。集められた静止画像から地面や壁など静止している物体との跳ね返りも含めて軌道を正確に予測できると思われます。

ただし、正確に予測できるのは高速で移動するボール以外は静止している場合であって、途中に不意に割り込んできた障害物との干渉まで予測できるには至っていないと思われます。

システムの考察

ここまで読んで頂けた方は見当がついているかもしれませんが、本稿ではVARについて考察してみました。

移動体のスピードを約30m/sにしていたのは、話題になった例の時15のゴロでセンタリングされたサッカーボールのスピードを想定していました。通常のセンタリングは60m/sらしい16ので半分にしました。

判定では、約30m/sで移動する22cmのサッカーボールが12cmのラインを完全に超えていたという証拠があったかどうかに注目が集まっていたと思われます。

今回の判定において、UWB測位システムは誤差が大きすぎて役に立たなかったと思われます。Kinexonのボールトラッキングシステム17の測位の周期は10msと書いてあります。仮に30m/sで直進するボールを測位しようとすると、このボールは10msで30cm移動するので、ライン上のボールの位置を正確に知ることはできません。

KinexonはIMU(慣性計測ユニット)を使って2ms周期でボールの移動データも収集しています。また、測位の精度は10cm以下だそうです。具体的な方法については書かれていないので予想になりますが、実際の測位はUWB測位で粗い位置を計算し、IMUで取得した3軸加速度からボールの移動方向や移動距離の補正を加えて最終的な位置を決定していると考えられます。

たしかにUWB測位とIMUを組み合わせれば、ボールの軌道上に不意に現れる障害物にはねかえって不規則な移動をするボールの位置もある程度は推測できます。しかし、推測の基準となるUWB測位の精度が今回の判定には不十分なので、結局は役に立っていなかったと予想できます。

今回の判定において、Hawk-Eyeの主機能であるボールの軌道予測は直接的には役に立たなかったと思われます。なぜなら、ボールの軌道上に突如割り込んでくる選手の足に当たって跳ね返る軌道を予測・計算できるようには作られていないと考えられるからです。一方で、Hawk-Eyeには12台のカメラから集められた様々な角度からの画像があります。今回の判定結果から予想すると、全ての画像でボールがラインを完全には超えていなかったことがわかります。ただし、だからと言ってボールがラインを完全に超えていなかったということが真実だったかはわかりません。なぜなら340fpsの画像の寄せ集めではボールがラインを完全に超えていた瞬間を撮影できていなかったかもしれないからです。

FIFAの説明18によると、VARには8台のスーパースローモーション(SSM)カメラと4台のウルトラスローモーション(USM)カメラを使っているそうです。SSMとUSMの違いは明確に書いてありませんが、こちらの記事19から予想するとUSMは4Kで1000fpsの性能があるのではと思います。しかし、前述のように1000fpsでは1ミリ秒の間に何があったかを知ることはできません。

もし、Hawk-Eyeやスローモーションカメラからの画像の中に跳ね返りの瞬間があれば、あのように判定に時間がかからなかったと思います。おそらく実際の判定は、VARのカメラで撮れた数十枚の画像をもとに、VARチームが目で見て頭で空白の時間を埋め、最後は主審が総合的に判断したのではないかと予想できます。

ちなみに後日、上方から撮影された画像20が出ましたが、この前後数ミリ秒の間に何が起きていたかが分からないので、ボールがラインを超えていないことを証明するものにはならないと思います。

さいごに

みなさんが注目していた今回の判定は、UWB測位システムを含むVARに事実が記録されていたからあの判定になったような声が散見されますが、私はそうではなかったと考えています。

JFAではVARをこう説明しています。21

VARは、最良の判定を見つけようとするものではなく、「はっきりとした明白な間違い」をなくすためのシステムです。

上記で示した事実から、あの時、おそらくVARでは真実はわからなかったと思います。しかし、審判は判定しなければいけません。ある程度のVARの後押しもあったかとは思いますが、最後は審判が審判の責任をもって判断したのだと思います。

明確に間違いではないと判断できれば、ものごとを進めるのもやり方ではないかと、今回の判定を見て思いました。

どこかの国でありがちなのですが、最適解を探すことに固執するあまりに時間を費やしチャンスを失うことがあります。何度も実証実験を繰り返すことも大事なことかとは思いますが、ひとつ先に進めて新しいことを発見する方に期待してはどうでしょうか😉。(誰に言ってる?)

あと、今回の件で、移動する障害物との跳ね返りの予測について、Hawk-Eyeがバージョンアップするかもしれませんね。楽しみです。

さて、ここまで読んで頂きまして、ありがとうございました。
皆様、寒い日が続きますが、暖かくして良いお年🐇をお迎え下さい。

免責事項

本サイトおよび対応するコメントにおいて表明される意見は、投稿者本人の個人的意見であり、私の所属する組織の意見ではありません。本サイトの内容は、情報の提供のみを目的として掲載されており、私の所属する組織や他の関係者による推奨や表明を目的としたものではありません。各利用者は、本Webサイトへの掲載により、投稿、リンクその他の方法でアップロードした全ての情報の内容に対して全責任を負い、本Webサイトの利用に関するあらゆる責任から私の所属する組織を免責することに同意したものとします。

  1. https://en.wikipedia.org/wiki/Ultra-wideband

  2. FCCやITU-Rでは、500MHzまたは中心周波数の20%のいずれか小さいほうの帯域幅を超えて通信を行う技術を指します。実際に使われる通信は3GHzから10GHzを使うので、ここでは500MHz以上としました。

  3. 反射などで複数の経路から信号が伝わることです。結果的に受信側でノイズになったり信号強度が弱まったりします。

  4. https://en.wikipedia.org/wiki/Real-time_locating_system

  5. https://www.sewio.net/uwb-technology/rtls-technology-comparison/

  6. https://www.researchgate.net/publication/330813914_Numerical_and_Experimental_Evaluation_of_Error_Estimation_for_Two-Way_Ranging_Methods

  7. 複数のタグがメッセージを同時に送出すると干渉してノイズになります。

  8. 35678Hzで動作する水晶振動子を使い15回カウントして1秒とします。

  9. https://onlinedocs.microchip.com/pr/GUID-3DEE8FD6-3D1E-4178-A506-A130BBE38229-en-US-1/index.html?GUID-EC523CB2-4535-4721-959B-CD37D9FC7200

  10. https://www.qorvo.com/products/wireless-connectivity/ultra-wideband

  11. https://www.inpixon.com/technology/rtls/modules/swarm-uwb

  12. https://www.phantomhighspeed.com/products/cameras/4kmedia/flex4k

  13. https://www.photron.co.jp/products/hsvcam/fastcam/novar4k/

  14. https://www.sony.com/ja/SonyInfo/technology/stories/Hawk-Eye/

  15. https://www3.nhk.or.jp/news/html/20221203/k10013911711000.html

  16. https://yoursoccerhome.com/how-fast-is-a-soccer-ball-kicked/

  17. https://kinexon.com/technology/ball-tracking/

  18. https://www.fifa.com/technical/football-technology/football-technologies-and-innovations-at-the-fifa-world-cup-2022/video-assistant-referee-var

  19. https://www.ravepubs.com/for-a-gives-livehd-4k-ultra-slow-motion-in-time-for-fifa-club-world-cup/

  20. https://news.yahoo.co.jp/articles/a1ece929d6a350b8d60c22778b7e7b7b4e8a9d92/images/000

  21. https://www.jfa.jp/rule/var.html

25
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
25
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?