1. 3年次


2. 4年次

1. サブシステム試験
2. プレ競技会
3. 競技会

1. メカニクス
2. エレクトロニクス
3. ソフトウェア
   

1. 3年次



開発項目	開始(計画)	開始(作業)		終了(計画)	終了(作業)
行動計画検討・決定	2000/11/7	2000/11/7		2000/11/21	2000/11/21
技術調査	2000/12/12	2000/12/12		2001/1/9	2001/1/9
基本設計	2001/1/11	2001/1/11		2001/2/1	2000/02/1

2. 4年次



開発項目	開始(計画)	開始(作業)		終了(計画)	終了(作業)
詳細設計書(メカ)	2001/5/1	2001/5/1		2001/5/31	2001/6/22
詳細設計書(エレキ)	2001/5/1	2001/5/1		2001/5/31	2001/7/10
詳細設計書(ソフト)	2001/5/1	2001/5/1		2001/5/31	2001/7/3
製造仕様書	2001/6/1	2001/6/23		2001/6/15	2001/7/20
製造(メカ)	2001/6/19	2001/8/20		2001/10/15	2001/9/18
製造(エレキ)	2001/6/19	2001/8/20		2001/10/15	2001/11/27
製造(ソフト)	2001/6/19	2001/8/20		2002/11/23	2002/1/20
改善設計 改善(メカ)	2001/8/1	2001/10/1		2001/9/31	2002/1/24
改善設計 改善(エレキ)	2001/10/16	2001/11/28		2001/11/30	2002/1/24
改善設計 改善(ソフト)	2001/11/30	2002/1/20		2002/2/8	2002/2/8
ドキュメント整理(メカ)	2002/01/09	2001/12/1		2002/2/15	2002/2/15
ドキュメント整理(エレキ)	2002/01/09	2002/1/25		2002/2/15	2002/2/15
ドキュメント整理(ソフト)	2002/02/01	2001/2/15		2002/2/10	2002/02/15

以上が開発計画と対比させた開発過程である。計画と実作業がかなりずれてしまった。
計画どおり進ませることが大変であることを知った。

1. サブシステム試験

以下のドキュメントを参考とする。

• MIRS0001 メカニクスシステム試験報告書(MIRS0001-ASSY-2002)

• MIRS0001 エレクトロニクス試験報告書一覧(MIRS0001-ELEC-5001)

2. プレ競技会


• 12/19(プレ競技会１)
  結果は一つ獲得できただけであった。いける！と思った自分があまかった。まだまだ修正必要…。
• 1/23(プレ競技会２)
  結果は二つ確実に獲得できた。だいぶ確実になってきた。さらなる修正を！
3. 競技会


• 2/8(MIRS2000競技会)

  	1回目		2回目		合計		順位
  	獲得数	タイム	獲得数	タイム	獲得数	タイム
  1班	5	3分12秒	4	3分2秒	9	6分14秒	1
  2班	5	4分3秒	4	2分59秒	9	7分2秒	2
  3班	2	1分12秒	2	2分45秒	4	4分7秒	5
  4班	2	3分28秒	3	3分13秒	5	6分41秒	4
  5班	4	5分	2	5分	6	10分	3

  見事優勝を勝ち取りました。
  最後にタッチセンサのバンパがポストにひっかかってしまい残念・・・。
  本当なら10個すべてとれたはずなのに…。
  

開発項目		工数(h)
メカ(3人)	001.調査、学習	3.0
	002.システム開発計画立案	11.5
	003.基本設計	0.0
	004.詳細設計	331.5
	005.製造	242.5
	006.サブシステム試験	53.5
	007.システム試験	0.0
	008.改善設計	21.0
	009.ドキュメント整備	68.0
	010.ミーティング	3.0
	011.その他	60.0
メカ合計		794.0
エレキ(3人)	001.調査、学習	9.0
	002.システム開発計画立案	7.5
	003.基本設計	0.0
	004.詳細設計	143.5
	005.製造	438.5
	006.サブシステム試験	158.0
	007.システム試験	18.0
	008.改善設計	65.5
	009.ドキュメント整備	138.0
	010.ミーティング	3.5
	011.その他	79.5
エレキ合計		1061.0
ソフト(2人)	001.調査、学習	1.5
	002.システム開発計画立案	10.5
	003.基本設計	0.0
	004.詳細設計	74.5
	005.製造	409.5
	006.サブシステム試験	107.0
	007.システム試験	27.0
	008.改善設計	12.0
	009.ドキュメント整備	5.5
	010.ミーティング	2.0
	011.その他	91.5
ソフト合計		741.0

• 作業工数各部門別グラフ

1. メカニクス

   	問題点	原因	解決策
   1	走行中、車体本体の側面が壁に衝突しても、気付かずにそのまま進もうとする。	側面の障害物を感知するセンサがUSSのみなので、USSの感度が悪いと車体の横に何があるか全く判らない。	ある程度側面まで感知できるように、前側面のバンパーの幅を拡大した。
   2	バンパーの動きが渋くて、戻らないことがある。	シャーシとバンパーにあけた蝶番取付けのための穴が寸法とずれていたため、蝶番がねじれて抵抗力が生じてい た。	取付け穴を拡大して、寸法に余裕を持たせた。それでも解決しない場合は、取付けるネジを 少し緩めて対処した。
   3	走行中、極端に車速が遅くなる。	キャスターが抵抗となり、フィールドとの摩擦が増えることに起因する。	キャスターの取付け位置を少し上方にずらした。
   4	配布された部品（MIRSATLM-ASBY-1005）を使うと、ISAボードが固定しづらい。	すぐずれる。	新たな部品（MIRS0001-ASSY-1036）を作り、固定方法を変更した。
   5	前側部バンパーがポストのスイッチに引っかかる。	赤外線を感知しポストと対面しようと車体を90度旋回させるとき、旋回速度が速いと遠心力でバンパーが外側に開き、ポストにぶつかってしまう。	競技中初めて生じた問題点であり、現在ビニールテープを貼って対応している。

2. エレクトロニクス

   	問題点	原因	解決策
   1	超音波センサのテストプログラムを走らせても2か3か4の値しか出ない。	・超音波センサからの入力が常に"1"になっていた。 ・ドーターボード上でショートしている所があった。	・超音波センサの可変抵抗を調整して増幅度を調整した。 ・ショートしている所を訂正した。
   2	超音波センサのテストプログラムを走らせると常に999という値が表示された。	FPGA内の回路データで、超音波センサの部分の割り込みを出すピンのピン配置が間 違っていた。	ピン配置をFPGAの取り扱い説明書で調べて正しいピン配置をした。
   3	FPGAの回路データ（TTFファイル）をFPGAにダウンロードできない。	ISABUS上につながるピンに対して、なにも施さなかった。	BUSに関係するPINのすべてをハイインピーダンスにした。
   4	ttfファイルをdownloadしようと、すると"download fail"ト表示される。その1	回路データで使うゲート数を減らすためにアドレスレコーダーでアドレスの界8bitだけを 参照していたのだが、上位のアドレスも参照しなければ他のアドレスが呼び出されたときでも反応してし まうというバグがあった。	アドレスは、16bitずべてを参照してモジュールを選択するようにした。
   5	ttfファイルをdownloadしようと、すると"download fail"ト表示される。その2	IO-readの信号は負論理であるのに、正論理で考えて回路を作っていた。	回路にnotを付け加えて反転することで解決した。
   6	電源ボードから５Vの電圧が供給されない。	基盤上の回路が間違っていた。	間違っているところを探し、改造報告書のとおりに修正を施した。
   7	符号化するように作成した赤外線センサモジュールから信号がよめない。	赤外線センサは負論理であるのに、正論理で考えて回路を作成していた。	notを回路上に付け加えて修正した。
   8	電源が突然落ちてしまう。	・バッテリーのの電圧が低下した。 ・安定化で電源が実際に使っていると不安定である。	・充電されたバッテリーに取り替える。 ・安定化電源の電圧は少し高めに設定する。（９Ｖくらい）
   9	ひとつだけタッチセンサが反応しない。	コネクタの接触不良。	ハウジングを付けなおし、コネクタを直した.。
   10	モーター制御のテストプログラムで、速度-100で回転させるとモーターは停止してしまっ た。また、-1で一番速く回転する。	モーター制御用のＩＣの機能として,後ろ周りのときにＰＷＭ信号も反転してしまってい た。	ＦＰＧＡ内部回路データのＰＷＭ制御モジュールの部分で修正を加えた。詳しくは、方 向データと速度データで変調したＰＷＭ信号のEX-ORを出力として左右のモーターに出力した。

3. ソフトウェア
   

   	問題点	原因	解決策
   1	読み込みアドレスを変えると標準MIRSでのテストができなくなり、自チームのFPGAが安定するまで、テストが 出来ない。よって開発が停滞する。	MIRS0001と標準MIRSの仕様が異なる。	エレキのヘルプにまわる。
   2	ドライバとFPGA回路を両方作成する場合、どちらが原因で不具合がおきるのか分かりにくい。	ドライバ、FPGAともに徹底不足。	ソフトウェアのエラーは普通のプログラムと同様修正すればよいが、ドライバは指定されたアドレスを読むだけ であるので、FPGAのエラーをそのまま通してしまう。エレキと綿密に連絡を取って、早め早めに対応する必要がある。ソフトウェアのエラーは普通のプログラムと同様に修正すればよいが、ドライバは指定されたアドレスを読むだけであるので、FPGAのエラーをそのまま通してしまう。エレキと綿密に連絡を取って、早め早めに対応する必要 がある。
   3	座標のﾃﾞｰﾀがうまく記憶できない。	超音波、ロータリエンコーダの値が曖昧である。	何度もMIRSを走らせ座標がうまく出るようプログラムを調整した。
   4	直進できない。	まっすぐ走るのに左右のタイヤの速度を与えているだけだった。	左右のタイヤの速度を与えているだけだと、競技場などの影響で途中から左右のタイヤの速度が異なってくる。左右のタイヤの速度比が一定になるようフィードバックするプログラムを組んだ。
   5	うまくポストの周りを周回できない。	直進のときと同様、左右のタイヤの速度を与えているだけだった。	直進のときと同様、左右のタイヤの速度比が一定になるようフィードバックするプログラムを組んだ。
   6	ポストの周回が一周ぴったりとまれない。	毎回走らせるたびに、周回軌道が競技場などの外乱によりずれる。	フィードバックがあまかったと思われるから、プログラムを試行錯誤して改良した。それでもまだ微妙にずれるから、何回も走らせて一番うまくいく値を見つけ出した。
   7	指定した距離でとまれない。	ロータリエンコーダのコネクタ接触不良。	ハウジングを付けなおし、コネクタを直した.。
   8	haltできない、コンパイルできない、OSが立ち上がらない。	OSの損傷。	OSの再インストール。
   9	OSが立ち上がらない２。	CPUボードの損傷。(なぜボードが損傷したかは不明である。)	CPUボード交換。

全体的な反省点としてはやはり計画性であろう。
自分たちはしっかり計画しているつもりであっても実際作業にはいっていくとその計画どおりにはしっくりいかなかった。
作業の進め方にも問題はあったかもしれないが、計画が不十分であったことももちろんあるだろう。

メカ:

各センサの取り付け塩ビ板などを設計する際は、ATL‐MIRSや過去のMIRSを参考にしながら細かく設計したため、製 造後寸法の変更はほとんどなかった。しかし2階シャーシフレームは1・3階のシャーシフレームとの連結部のナットとセ ンサの位置が重なってしまいと、設計の変更しなければならないという問題点も出てきた。また、ほとんどの塩ビ板の 寸法はほぼ正確だったがネジの位置が合わない、といった細かい問題点が出てきた。 製造後に発見された一番大きな設計ミスは、バッテリラックの位置と形が悪かったため、下にあるモータと干渉してしま うことだった。バッテリの位置を変更するという案もあったが、重心位置の問題などから、形をH型にすることによって同 じ位置にバッテリを入れることが可能となった。 ソフト、エレキが完成し実機を走行する際には、バンパの動きが悪いためタッチセンサがONになったら、ONになりっぱ なしになるかもしれない、という問題点が出てきた。これに関しては取り付けネジを緩めたり、ネジ数を減らすことによっ て解決できた。 他にはそれほど大きな問題点はなく、完成後は走行時にバンパが壁やポストにひっかからないように一部を熱でまる めたり、ISAラック内のボードが安定するように補助金具を製造するなどして、補助的な製造に徹することができた。

エレキ：

全体的に開発は遅れてしまい、ソフトの開発に対して大きく遅らせてしまった。ボードの設計もATLMIRSを頼りにするところが多かったが、その際十分な理解をしないまま流用しようとしてしまったことがまず問題発生の原因であったように思う。システム上で、その他のボードと接続するところのインターフェイスの仕様を完全に理解しないまま作り、作った後に調べて理解していったりと、開発としては間違っていることもしてしまった。そのような事を開発計画、設計段階で急いで怠ってしまったことが、結果的に製造、試験の段階で大きな遅れとして悪い結果を出してしまったのだと思う。
また、参考に出来るドキュメントの多くはATLMIRSの物しかなく、不充分なものもいくつかありました。超音波センサ試験については、試験方法もまったく分からず、ボードを作成してから試験方法を考える必要が出てきてしまいました。本来このような試験の方法は、試験仕様書として詳細設計書を上げるときに一緒に上げておかなければいけなかったのですが、そのような点で詳細設計の段階での詰めの甘さがとても悔やまれる。
他にも、問題は多く発生したが、その多くは先輩方のドキュメントを信頼しすぎた。悪く言えば、自分たちが開発に対しての意識が薄かったことでおきてしまったものであると思った。
また、特に大変だったのは赤外線符号化の機能を持たせたことだが、幾度となく仕様の変更をしてしまったことは、詳細設計の段階での手抜きが原因であることは明らかである。特に、ソフトへデータを受け渡すところのソフトウェアビジビリティーを度々変更してしまい、ソフトでドライバを開発するところで苦労させてしまったことに対してとても反省している。
次の人たちではなるべく上で書いたことのような所で苦労してほしくないと思い、ATLMIRSのドキュメントで不充分であると感じた部分についてはなるべくドキュメントとして残すように努力した。

３年生のころやはじめのころは全然ソフトについては理解できていなかった。実際、本当にMIRSができるのかなぁと不安になったこともあった。RT-linuxということでいろいろ戸惑うこともたくさんあった。でも今となってはだいぶ知識がついたと思う。
今回MIRSのソフトをやってみてロボットというのは思いどおり動かないものだと改めて知った。ある程度は覚悟はしていたが、これほど大変だとは思っていなかった。今までこれほど長いプログラムを組んだことがなかったから大変だった。
コンパイルを通しただけではまだまだである。コンパイルが通っても実際搭載してみて動くわけではない。むしろ動かない…。
ソフト開発というのはデバッグの繰り返しである。ということを知った。
MIRSというものから僕らが得たものは大きい。確実に僕らの人生の糧となることは言うまでもない！

MIRS0001諸君！おつかれさまでした。
まあ僕なりにマネージャーとしての役割を果たしてきたつもりですが…。どうでしょう？
この開発完了報告書を作成していく段階で、いろいろなことが頭へと浮かんできました。
思えばよく残業をしたものです。
でもその成果がしっかりと出たではないですか！
今となってはいい思い出です。１年半みなさんよくがんばってくれました。
１年半どうもありがとうございました!!!!!!!!!!!!
以上をもってMIRS0001の開発が完了したことをご報告いたします！
同時にMIRS0001は解散いたします。さよなら〜！