プロジェクト / Basic Mouse 2003

１．要求分析

1.1 前提条件

ハードウェア構成

森永さんの「マイクロマウス初心者講座」で作成したBasicMouseを使用する。

BasicMouse

**BasicMouseハードウェア概要**
CPU		AKI-H8/3664F, clock 16MHz, ROM 32KB, RAM 2KB
モータ		２相ユニポーラステッピングモータ　KH39FM2-801 ×２個
ホイール径		47mm（直径）
トレッド		70mm（ホイール中央からホイール中央間）
センサ		赤外線方式アナログ距離センサ　×４個
ボタンSW		４個（うち、CPUリセット１個）
LCD		16文字×2行　キャラクタディスプレイモジュール
バッテリ		16.8V 1800mAh ニッケル水素二次電池
大きさ		136×76×67[mm]（全長、全幅、高さ）
全備重量		850g

周辺機器

迷路走行時はマイクロマウス本体のみ使用。
デバッグ時や走行結果確認時には、迷路情報を表示するためにPCを使用。

使用環境（走行環境）

マウスが走行する迷路の規格は、基本的には全日本マイクロマウス大会の迷路規格に準拠。
テストや調整に使用するため、区画数、ゴール位置等は設定の変更が可能。
屋内での走行を想定し、直射日光等の強力な外乱光は無いものとする。（スポットライトはあるかも？）

**迷路仕様**
迷路全体の大きさ		最大16区画×16区画、最小3区画×3区画
単位区画の大きさ		180mm×180mm（ただし、壁間の幅は168mm）
スタート位置		迷路の左下隅
ゴール位置		自由に設定可能

OSなど

OSは使用しない。その代わり、自作の簡易スケジューラで擬似マルチタスクを実現する。

1.2 機能的要求

**機能的要求一覧**
カテゴリ	管理番号	要求	要求の必要性	優先度

基本機能	1.1	自律走行により迷路を探索して、ゴールまで到達できること。	マイクロマウスはそのようなロボットだから。	1st
	1.2	センサの動作チェック、モータの動作チェック等を行えること。	マウスの動きがおかしいと思ったときに、すぐにハードウェアにトラブルがないかどうかを確認できるようにするため。	1st
	1.3	プログラムを入れ替えずにデモンストレーションを行えること。	人に見せるときに、迷路がない場合が多いから。	3rd

走行	2.1	N区画前進とその場旋回（角度or方位）の基本走行コマンドを有すること。	探索走行時に必要な最低限度の走行コマンドだから。	1st
	2.2	信地旋回が可能なこと。	最速走行時に必要。	2nd

状態表示	3.1	常にバッテリの電圧をLCDに表示すること。	いつでもバッテリの電圧を確認できるようにするため。	2nd
	3.2	バッテリの電圧が充電が必要なところまで下がったら、LEDとLCDでその旨を表現できること。	走行が不安定になる前にバッテリ交換を促すため。	2nd
	3.3	エラー発生時やスタート前やゴール後などをLEDとLCDで表現できること。	ロボットが停止するだけでは、エラーでとまったのか、ゴールと判断したのかがユーザにわからないから。	2nd
	3.4	エラー時には、エラーコードをLCDに表示すること。	どんなエラーが発生したかをユーザに知らせるため。	1st

補助機能	4.1	探索走行後に、ロボットが生成した壁情報、等高線情報をPCに転送して表示できること。	探索が上手くいかない場合や最速経路が生成できない場合に、ロボットが迷路をどのように認識したのかを知るため。	2nd

迷路探索	5.1	探索アルゴリズムには、等高線マップ法を用いること。	等高線マップ法であれば、探索も最速経路生成も両方可能だから。	2nd
	5.2	探索走行時には、ボタン操作で迷路をクリアできること。	マイクロマウス競技のルールに基づく。	1st
	5.3	ゴール到達後は２秒以上停止してから、人間の操作を介さずにスタート地点まで帰ってくること。	競技はフルオートで行われるのが美学とされているため。	3rd

設定変更	6.1	探索する迷路サイズを変更できること。（プログラムを入れ替えてよい。）	練習用の迷路と本番用の迷路は大きさが異なるから。	1st

1.3 非機能的要求

**非機能的要求一覧**
カテゴリ	管理番号	要求	要求の必要性	優先度

保守性	1.1	CPUやセンサ、モータが変更になった場合でも、最小限度の修正でプログラムが動作すること。	後々までプログラムの基本設計を使いまわすことができるようにしておくため。	1st
	1.2	探索アルゴリズム、最速経路計画アルゴリズムの差し替えが容易であること。	様々なアルゴリズムを試すことができるようにしておくため。	2nd

走行性能	2.1	最速走行時にはフレッシュマンクラスの迷路で３０秒以内にゴールできること。	やるからには上位入賞したいから。（３０秒以内なら、ベスト５入りできるはず）	3rd

操作性	3.1	走行中には（リセットボタン以外は）どのボタンを押しても走行を中断できること。	走行中にロボットを止めることができるようにするため。	2nd

1.4 開発条件

分析、設計にオブジェクト指向技術を用い、C言語で実装を試みます。（GCCのコンパイラを使えば、C++が使えるそうですが・・・）

**開発条件一覧**
設計手法		eUMLをカスタマイズしたもの？（eUMLはRUPを組み込みに特化させた開発プロセスだそうです）随所にXP的要素を入れてみるつもり。
作業標準		特になし
ドキュメント標準		特になし
設計言語		UML 1.4
実装言語		C言語
開発環境	統合環境	YellowIDE ver.6	Yellow Soft社
	Cコンパイラ	YCH8 ver.4.11
	デバッガ	YellowScope ver3.03
	UMLモデリングツール	Jude -竹- ver.1.2.1	オブジェクト倶楽部

PC上でプログラム作成する場合、

Visual Basic 6.0 Learning Edition
Visual C++ 6.0 Standart Edition

が使用可能。

参考文献

渡辺博之、他：組み込みUML---eUMLによるオブジェクト指向組み込みシステム開発、翔泳社、2002．

1.4 リスク管理

深刻度　１：走行は可能だが、要求された品質水準には達しない
深刻度　２：システムダウンこそしないが、ゴールにはたどり着けない
深刻度　３：エラーがでてシステムがダウンしてしまう

**表　技術的リスクの管理表**
番号	内容	深刻度	対策案	対策完了日
1	探索アルゴリズムが正しく動作せず、ゴールまでたどり着けない。	２	シミュレータ上で探索アルゴリズムが正しく動作することを確認する。
2	車輪のすべりや計算の誤差により、地図上でのロボットの位置と実際の迷路上でのロボットの位置がずれてしまう。	２	探索走行の中に、誤差を修正する仕組みを盛り込む。
3	試走をするだけの十分な広さをもった迷路が手元に無いため、姿勢制御や走行速度のチューニング等を行えない。	２	（１）調整用迷路を購入する。（２）迷路を自作する。

リスク回避として、１～３の対策を全て実施した。調整用迷路の購入には（担当者と連絡が取れずに）多少時間がかかったが、購入して正解であった。置き場所には困ってるけど。

1.5 プロジェクト終了条件

11月22日の全日本マイクロマウス大会が終了して、まとめと反省を書いた時点で、本プロジェクトを終了する。