名称 MIRS1704 走行機能開発報告書
番号 MIRS1704-SOFT-0005

版数 最終更新日 作成 承認 改訂記事
A01 2018.2.09 鈴木皓仁 初版
A02 2018.2.23 鈴木皓仁 牛丸先生 第二版

ドキュメント内目次


1.はじめに

 本ドキュメントは、走行機能ソフトウェアについての開発報告書である。

2.評価試験結果、完成度の評価

 評価試験については、詳細な試験内容を用意しておらず、十分な試験も行えなかったため報告書は作成していないため、完成度の評価のみを行う。

2.1 RaspberryPi
詳細設計書に示していたモジュールの評価を行う。
まず、詳細設計書におけるmulti_getモジュール、mainモジュールについて、二つをマルチタスク化して超音波およびタッチセンサによる走行補正で使用する予定であったが、詳細設計後の思案により、必要ないと結論が出たためマルチタスクをやめ、シングルタスクで動作させることにした(これについて、詳しくは以下で記す)。
それにあたって、メインプログラムを標準機どおりのpilotモジュールで動かすことにした。
表1に各モジュールの状態を示す。


table1 RaspberryPiモジュール
Fig.1
2.1.1 pilotモジュール
デモコースのマップを距離、方向、壁の3つの情報に分けて保持することができた。
また、スマホからの指令によりエレベータを考慮しないデモコースを走行することができたが、方位センサで現在の角度を取得することができなかったため、エレベータを考慮するマップでは進行する方向が決められず、走行することができなかった。

2.1.2 ussモジュール
新規機能として、前後左右の超音波センサの同時取得機能、左右の壁情報の取得機能を追加した。
前後の超音波センサの値は結局使用することはなかった。
壁情報の取得については、かなりの精度で壁の状態を取得することができたが、あらかじめ道の幅を定めておかないと取得が不可能になってしまうので、一定のタイミングで左右の超音波センサで道の幅を取得するなどの対応をする必要がある。

2.1.3 requestモジュール
標準機から変更点無し。
主に直進、回転のためにpilotモジュール、correctモジュール、等で利用した。

2.1.4 arduinoモジュール
標準機から変更点無し。
requestモジュールが利用している。

2.1.5 soundモジュール
詳細設計の時点ではひとつの音声を再生するのみの機能とする予定であったが、それだと関数化、およびモジュール化する必要性がないということで、与えられた引数によって全部で5種類の音声を再生できるようにした。(日本語でしゃべる)
なお、音声再生にはAquesTalk,OpenJTalkを使用した。以下に詳細リンクを示す。
AquesTalk Pi - Raspberry Pi用の音声合成アプリ
~https://www.a-quest.com/products/aquestalkpi.html~
Open JTalk
~http://open-jtalk.sourceforge.net/~

2.1.6 correctモジュール
詳細設計の段階より、次のMIRSの動作が直進か回転かによって、もし補正を行った際、回転だったら超音波センサから本体の一番後ろの部分までの長さを考慮して直進し、曲がるときに本体の後部が壁に接触しないようにする機能を追加した。
ussモジュールの壁情報取得関数を利用し、目標地点に達していない場合、目標地点まで距離を進めることができた。

2.1.7 delayモジュール
requestモジュールを利用してMIRSの状態を取得し、連続して走行指令をArduinoに送るとき、正しくすべての指令が出せるよう、遅延をすることができた。

2.1.8 dataモジュール
スマホが新規ファイルを作るまでループを繰り返し、プログラムが実行されている状態でスマホから新規csvファイルが作成されれば、その瞬間にデータを読み込めるようにした。
しかし、時たまファイルデータの取得に失敗することがあり、原因を考察したところ、ファイルの作成とデータの読み込みは同じRaspberry Piで行うため、その処理がかぶってしまうと異常な値を取得してしまい、セグメンテーション違反を起こしてしまうというバグがあることがわかった。
対応を試みたが、それに気づいたのが発表会当日であったため、改善はできなかった。

2.1.9 directionモジュール
ネット上のサンプルコードを元に開発を行い、方位センサ単体では正確な値を取得できていたが、統合してから正常な動作をしなくなってしまったため、使用を断念した。

2.1.10 elevaterモジュール
プロジェクトとしてエレベータ機能が廃止されたため、ソースコードは存在するが実際に動作を確認してはいない。

2.1.11 runモジュール
詳細設計に記した中央走行フローチャートを元にプログラムを組み、目的とされる動作である進行方向補正は、正確に動作をしたが、指定距離の走行する上での誤差が大きく、その調整が十分といえるほどできていなかった。
発表会のデモ走行では、直進距離が短かったため、壁への接近を判断する前に走行が終わってしまうため、必要性がなく実装されていない。

2.2 Arduino
詳細設計書に示していたモジュールの評価を行う。
Arduinoは、ほとんど標準機プログラムをそのまま使用した。
ここでは、開発に着手したioモジュールと、詳細設計の時点では記述していなかったが、新しく追加しようとしたswモジュールについての評価を行う。
表2にモジュールの状態を示す。


table2 Arduinoモジュール
Fig.2
2.2.1 ioモジュール
タッチセンサから取得できる値を6つに増やした。

2.2.2 swモジュール
swモジュールは障害物回避のモジュールである。
走行中、タッチセンサが押されたら、押されたタッチセンサ位置によって設定された回避行動をとることができた。
回避行動はあらかじめ設定された動作をするのみなので、完璧な障害物回避はできていない。

3.詳細設計書へのリンク

 走行機能ソフトウェア詳細設計書

4.ソースコードへのリンク

 Raspberry Piソースコード
Arduinoソースコード

5.総括

 目標としていたスマホで指令をしたら目的地まで走行するという機能は、形だけは実装できた。
しかし、走行補正がエンコーダだけだったり、スマホ指令の受信にも問題があったりと、全体として実装できた機能は非常に少ないという結果になってしまった。
原因としては、詳細設計への取り掛かりが遅かったこと、設計段階での見積もりがいろいろと甘かったこと、班員全員の力を十分に発揮しきれなかったことなどが挙げられる。



MIRS DATABASE