目次

1. ドキュメント概要
2. ROS2を用いた制御系統構成
3. 自律走行
4. 椅子の認識機能
5. ジャッキ制御機能
6. WEBアプリケーション
• 全体制御
• フロントエンド
• バックエンド
7. 総括
8. ソースコード

1.ドキュメント概要

本ドキュメントはMIRS2403 華蟻のソフトウェア開発報告書である。

2.ROS2を用いた制御系統構成

概要

ROS2を中心に据えた制御系統を新規に作成した。

最終的なノード図は以下のようになった。

評価

一からの構成であったが、まとまったシステムを構成することができた。一部パラメーターの更新に関する部分が余計な処理を挟んでいるので手直しが出来る早期に改修しておくべきだったかもしれない。

3.自律走行

概要

Navigation2を中心としてLiDARとエンコーダーを利用した自律走行システムを実装した。

評価

目的地への自律移動や人を自動で避けるなど最低限必要な機能は実装することができた。
位置精度、角度制度を上げようとすると足回りの構造上細かな位置調整が難しいためか目的地への到達判定が出ず、挙動がおかしくなりやすかった。
精度に関しては誤差23cm、角度は0.1rad程度が限界のように感じられる。（機体0.5台分くらいが目安）

BehaviorTreeと連動させることで自律行動を記述しやすくすることもできた。詳細な実装方法や構造についてはMIRS2403-REPT-0002に記述している。

4.椅子の認識機能

4.1. LiDARによる椅子認識

概要

処理の流れは以下の通り

1. LiDARのデータを取得（取得時に一定の距離以上の点群はフィルタで排除している）
2. 点群の形式をlaserscan型からpointcloud型に変更（極座標 → 直交座標変換）
3. DBSCANアルゴリズムでフィルタリングし、クラスタを分ける
4. 一定範囲外のサイズのクラスタを排除（椅子の足であろうサイズのクラスタだけに選り分ける）
5. 4つのクラスタを選出し、それぞれの距離が一定範囲内であるかをチェックし、適合する組を全通りの中から選出（隣り合うクラスタの距離と対角になるクラスタの距離を見る）
6. 選出された組み合わせの中心位置を算出。ランダムな横並びの二つの足の間と中心のベクトルを椅子の向きとしてパブリッシュする

評価

椅子の足が細すぎるとLiDARに映らなくなるため、体育館の椅子に関しては脚を太くするカバーを取り付けた

椅子の足が認識さえできれば高精度で椅子の位置検出が出来ていた。ただし向きがランダムになってしまうので、決まった位置からしか椅子の下に入れない場合に不都合が多かった。

点群処理っぽいものを実装出来て楽しかった

4.2. ArucoMarkerによる椅子認識

概要

ArucoMarkerを椅子の下に貼り付け、前方カメラで椅子を認識する。

評価

座標系の変換が必要だったが、それさえできればある程度の精度は出すことが出来た。
カメラの取り付け位置の登録は大雑把に計測したもので、カメラの固定も不十分だったため精度の向上をするならこの辺りを機械班と協力して値を決定していく必要があるように感じた。

カメラの処理が重く、二台をjetsonで同時処理するのは不可能で、当初は前方の椅子発見用のカメラと上部の椅子下での位置調整用のカメラで二台使用する予定だったが最終的には前方の１台だけを動かしていた。

出来れば小型PCなど高性能なマシンを機体に積んで処理すべき。

5.ジャッキ制御機能

概要

ジャッキの昇降動作を制御する。

リミットスイッチが押されるまでモーターを回転させるプログラムをESP32側にserviceとして実装している。

全体制御をしているBehaviorTreeから呼び出して使用する。呼び出すだけのclientプログラムも実装しているのでコマンドラインからの呼び出しも可能。

評価

呼び出しに関しては問題なく行えていた。

ジャッキの停止が時々動作しなくなり、ジャッキを破壊することがあった。もう一度動かすと正常動作をする。不具合を起こす確率は体感5~10%

原因は不明。ESP32の内部でこの処理はスレッドを分けて実装するようにしているので、これが悪さをしている可能性はあるが検証はできていない。

本来はROS2のserver機能ではなくaction機能で実装すべきであるが、micro-ROSでのactionの実相の情報が不足しており、実装することができなかった。
終了の検出がservice単体では出来ないので、一定時間動作を停止してジャッキの動作終了を待つという動作しか全体の流れで実装できなくなってしまった。

action自体ROS2の内部では独自のシステムではなく、2つのserviceと1つのtopicの合成として定義されているため、自作するのも手だったかもしれない。

6.WEBアプリケーション

6.1. 全体制御側

概要

BehaviorTreeからserverをたて、webアプリ側がこれに対してアクションを起こすまで動作待機をするように実装している。

評価

問題なく動作していた。パラメーターの取得もでき、これによる全体制御の分岐も実装出来ていた。

6.2. フロントエンド

概要

python3 のhttp.serverを使ってローカルWebサーバを作成し、Webアプリをローカルネットワーク内に公開した。
実際のWebアプリ画面を以下に示す。ユーザは画面の人数、配置場所、配置パターン、選択し、formを送信することで手配を行う。

fig2. Webアプリケーション画面

デモ用のアプリを示す。デモアプリは以下に示す。

fig3. Webデモ版アプリケーション画面

評価

直感的に操作できるようなUIにできた。cssではサイズ指定をremで行い、スマホからでも操作できるようにした。

6.3. バックエンド

概要

[1] オーダー情報について

オーダー情報はcsvファイルを用いて管理するようにした。

[2] ROSとの通信

rosbridge_serverを経由したWebSocket通信を行い、ブラウザとROSを連携するようにした。ブラウザ側ではroslibjsを使ってサービス通信でやり取りをしている。

[3] データ送信時の制約について

情報が未入力の箇所がある場合は送信を制限し、アラートで通知を送るようにした。
数値を入力する際にエンターを押すとページが更新されてしまう動作をしたため、エンターを押すと入力フォームが閉じるように設定した。

7. 総括

分担した作業をそれぞれが十分こなすことが出来ていたと思う。ROS2の導入に伴い全体的な開発が遅れてしまったが、機械の開発終了までに最低限動かせる状況までもって行けていたのは良かった。椅子を運ぶ機能で手一杯になってしまい、ユーザー側の使いやすさの調査までたどり着くことは出来なかったのが悔やまれる。

8. ソースコード

GitHubのリンクは以下