![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
人間や車が行き交う実環境下において , 自律走行ロボットを走らせる実験走行会 の一つに「つくばチャレンジ」というものがある . つくばチャレンジではロボット の自律走行以外にもいくつかの課題が用意されている . 例として , 「横断歩道の信 号認識」 , 「特定の人物検出」 , 「障害物回避」などが挙げられる . このような課題 と自律走行の達成を目指し , 参加者同士で経験と知識を共有することでロボット技 術の向上を図ることがつくばチャレンジの目的である.
以下の画像は実際に使用したロボットと,走行したコースである.
つくばチャレンジの実験走行は一日をかけて行われる , そのため待機場所を用意 する必要がある . 今回のつくばチャレンジ 2019 での待機場所は , 上の図 2 上の START 位置に置かれていた . しかしロボットに帯同する人は , 図 2 上の右下に位 置している公園内まで移動することが少なくなかった . つまり待機場所にいる人 は , ロボットの動向を確認することができないということだ . このように待機場所 で待っている人がロボットの動向を把握できないという状況は , つくばチャレンジ 側も良くないと考えており , 遠隔でのロボットの状態把握を推奨している . 遠隔でのロボットの状態を把握するための比較的容易な方法として , インター ネットを利用したモニタリングシステムを考えた . そこで , 本研究の目的は実際に つくばチャレンジで使用することを目標とした,モニタリングシステムの開発とす る . また本研究はモニタリングシステムの初期段階として,位置情報の送受信をす るものである。
システムを構成するにあたって必要となるデバイスは , 「ロボット」 , 「サーバ」 ,
「モニター」 , の3つである.
構成は以下の図に示す.
ロボット , モニターには「クライアントプログラム」を , サーバには「サーバプ
ログラム」を設置する .
それぞれ通信には Boost ライブラリの TCP の機能を利用した .
ロボットから取得した座標 (x, y, θ ) を TCP クライアントによってサーバである 太田研究室 PC へ送信 . 太田研究室 PC からクライアントであるモニターへ送信し , モニターで位置情報を反映した地図を表示する .
モニタリングシステムを開発するにあたって , 初めに重要となるものがネット
ワークの設計である .
つくばチャレンジで使用するロボットにはネットワークへ接続する機能が備わっ
ていない . そこでネットワークへの接続には , スマートフォンの USB テザリング 1
を使用した . その結果 , ロボット
( スマートフォン ) の IP アドレスは動的なものに
なる . 固定されていない動的な IP アドレスは外部から特定することができないた
め , モニターから直接接続することはできなかった . したがって直接の通信をする
のではなく , 固定 IP アドレスを持った太田研究室サーバを間に設置する以下の図3
のような設計とした .
上記の設計でシステムを開発していく過程で太田研究室サーバに「パケッ トフィルタリング」が存在することがわかった . パケットフィルタリングには接続 可能なポート以外への接続を遮断する効果がある . また , その接続可能なポートは 使用目的が決まっておりその目的以外での使用はできない . その影響で太田研究室 サーバにプログラムを設置してもロボットやモニターからアクセスできないこと が判明した . そこでパケットフィルタリングの影響を考慮に入れた開発をした .
太田研究室のサーバにサーバプログラムを置いたとしても , ロボットやモニター からアクセスすることはできないことが判明したため , サーバプログラムを太田研 サーバに設置しない方法として「ポートフォワーディング」を導入した . PC から直接接続することができないサーバ A と ,PC から SSHを利用すること で接続可能なサーバ B を考え , それら2つのサーバが同じネットワーク内にあると する . このとき以下の図5のようにサーバ B を踏み台としサーバ A へアクセスす ることができる .
以下の図6は実際に太田研究室のネットワーク内で, ポートフォワーディングを利用したシステムの様子である.
上の図6の通り太田研究室のサーバの左右にはパケットフィルタリングが存在するが ,
もともとSSH 用に用意されているポート番号を使用する
( ポートフォワーディングを利用する ) ことで , パケットフィルタリングによる干渉を避けている .
ロボットと太田研究室サーバ , モニターと太田研究室サーバそれぞれを SSH の
ポートフォワーディングを有効にし接続する . その結果接続は転送され , クライア
ントである ロボット , モニター , から太田研究室ネットワーク内の PC( 太田研究室
PC) へ接続することができる . このときロボット , モニターには「クライアントプ
ログラム」を太田研究室 PC には「サーバプログラム」を置く .
以下に示す図 7 は更に詳細なポートフォワーディングの様子である . ロボット , サーバ側での接続を示す . またモニター , サーバ側も同様な接続となっている .
予めポートフォワーディングの設定ファイルで , ローカルホストと呼ばれる 自身のOSを示す特殊なIPアドレスの XX 番ポートへの接続は, 転送先である太田研究室 PC の IP アドレスの YY 番へ転送されるという設定をする . 上の図7では以下の表 1 のように IP アドレスとポート番号を指定した .
| IPアドレス | ポート番号 | |
| ロボット | 127.0.0.1 | 13389 |
| 太田研究室PC | xxx.xx.xx.x | 31400 |
SSH の接続を確認したのち , サーバプログラムが置いてある太田研究室 PC の サーバプログラムを起動する . その後ロボットの座標送信プログラムを設定した IP アドレス (127.0.0.1), ポート番号 (13389) を指定し起動 . 接続は転送され IP アドレ ス (xxx.xx.xx.x), ポート番号 (31400) である太田研究室 PC への通信が開始される . したがって最終的には ( ロボットー太田研究室 PC), ( 太田研究室 PC ーモニター ) という以下の図8のような通信路が完成する .
本研究での実験場所は群馬大学桐生キャンパス構内となった .
そのため実際に使用した地図は桐生キャンパスのものとなっている .
使用するマップは太田研究室修士2年の村上が実際にロボットを走らせ, センサーで取得した3次元の点群データから作成した地図である.
ロボットの座標を矩形で示している . ロボットの制御 PC からは座標のみではな く角度情報も送信しているため , ロボットの向いている方向も反映した表示をして いる . 送信される座標に変更がない場合停止判定とし赤で表示する . また座標に変 更がある場合は移動中と判定し緑色で表示する . 下の図の通り , 左側に全体の地図 その右隣にロボット付近の拡大地図を表示する . 元の画像である左側の画像はサ イズが 6999*9999 と大きいため , 元画像をそのまま使用した結果かなり小さくなっ てしまっている .
以下の図の通り実際に群馬大学構内で実走実験を行った.
このルート以外であったとしてもモニタリング可能であることは確認済みであ る . 以下にロボット走行中のモニターの様子を示す .
本研究では通信のシステムから始まり , 位置情報の送受信 , 地図の描画 , を組み合
わせモニタリングシステムの開発をした .
完成したシステムは位置情報を文字列型にし , その文字列をバイナリに変換し送
信 , 受信側でバイナリを文字列に直すという仕組みになっている . 先行研究でもあっ
た文書ファイルを送信する手法とは異なり , データの送受信であるため余分なファ
イルを生成することがないシステムの開発ができた . 実験の結果からも , 通信に成
功し地図の描画にも成功しており , 位置情報のみの送受信を試みたモニタリングシ
ステムとしては申し分ない結果と言える .
本システムでは動作しているロボットを長方形で示している . ロボットは基本
的に前進するという前提のもと長方形で示したが , 実際のモニターを確認したとこ
ろ , 少々分かりずらいところが多々あった . これを改良するのであれば方向が判別
できるような二等辺三角形にしようと考えている . また移動時は緑 , 停止時は赤で
示しているが実験時のモニターを確認すると , ロボットは停止していないが赤と緑
でちらつく様子がうかがえた . これは送信する座標にちらつきがあることが原因
だが , これはロボットの自己位置推定の結果に拠るため送信座標のちらつきを抑え
る事は難しいと考えられる . したがって改良するならばシステムの方である . 今回
は座標受信ごとに座標の変化を見ていたが , 一定期間ごとの座標変化を見る , つま
り送信座標が一定時間変更が無ければ停止判定とする . というプログラムに変更す
る必要がある .
桐生キャンパス構内でのモニタリングが成功していることからつくばチャレンジでの利用も , つくば市役所付近の地図がすでに完成しているため問題なく行えると言える .
本研究では , つくばチャレンジで使用することを目指したモニタリングシステム の開発をした . 結果として実際のつくばチャレンジで使用することはかなわなかっ たが . 今後のつくばチャレンジでもモニタリングシステムは推奨される事項であ る . 次回以降のつくばチャレンジで使用するシステムとして , 群馬大学桐生キャン パス構内での実験を進めてきた . 通信システムとして SSH のポートフォワーディングを利用し , 太田研究室の PC をサーバとし , ロボット , モニターを接続する設計を完成させた . ロボット内の制御 PC から座標を取得しロボットの TCP クライアントから座標を送信 . サーバで座 標を受信し , その受信座標をクライアントであるモニターへ送信するというもので ある . 座標を受信したモニターでは全体のマップとロボット付近の拡大マップを表示 する . 角度の情報も追加で送信するためロボットの向いている方向を判別できるよ うに , ロボットは長方形で示してある . ロボット移動中は緑 , 停止中は赤で表示して いる . しかし考察でも述べた通り受信座標のちらつきから表示しているロボットは 点滅するようになってしまった . 明らかに停止している場合でも点滅してしまうた め , この処理は残念ながら意味をなしていない . 手法を改善する必要がある . 桐生キャンパス構内での実走実験を通して , 開発システムの実用性を検証してき た . サーバとロボット , モニターの接続は成功していることが確認できたが , これも 考察で述べた通り SSH の接続に問題がある . スマートフォンのテザリング以外の 手法を検討し改善する必要がある . また , 本システムは接続の順番を間違えると接 続できないという使い勝手の悪さがある . 実際に使用する際に注意すれば問題な いが , この問題もシステムの GUI 化をする際に , 見直していきたい . したがって今 後の展望としては , 送信する情報を追加しシステムを GUI 化することで , 実用性の 高いモニタリングシステムを構築することである .
[1] https://opencv.org/
[2] https://www.boost.org/
[3] Scamper による ROS ＆ RaspberryPi 製作入門・鹿貫悠多 [ 著 ]
