1. 3年次


2. 4年次

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

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

1. 3年次



開発項目	開始(計画)	開始(作業)		終了(計画)	終了(作業)
行動計画検討・決定	2001/11/06	2001/11/06		2001/11/22	2001/11/22
技術調査	2001/12/11	2001/12/11		2001/12/13	2001/12/13
基本設計	2002/01/08	2002/01/08		2002/01/24	2002/01/24

2. 4年次



開発項目	開始(計画)	開始(作業)		終了(計画)	終了(作業)
詳細設計書(メカ)	2002/04/18	2002/04/18		2002/05/21	2002/05/21
詳細設計書(エレキ)	2002/04/18	2002/04/18		2002/05/21	2002/05/21
詳細設計書(ソフト)	2002/04/18	2002/04/18		2002/05/21	2002/05/21
製造仕様書	2002/06/04	2002/06/14		2002/06/21	2002/06/28
製造(メカ)	2002/06/25	2002/07/09		2002/10/01	2002/10/01
製造(エレキ)	2002/06/25	2002/07/09		2002/10/01	2002/10/23
製造(ソフト)	2002/06/25	2002/07/09		2002/10/01	2002/10/30
改善設計,改善(メカ)	2002/11/01	2002/10/16		2002/12/20	2003/01/31
改善設計,改善(エレキ)	2002/11/01	2002/11/16		2003/01/10	2003/01/31
改善設計,改善(ソフト)	2002/11/01	2002/11/16		2003/02/07	2003/02/08
ドキュメント整理(メカ)	2003/02/10	2003/02/10		2003/02/14	2003/02/14
ドキュメント整理(エレキ)	2003/02/10	2003/02/10		2003/02/14	2003/02/14
ドキュメント整理(ソフト)	2003/02/10	2003/02/10		2003/02/14	2003/02/14

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

1. サブシステム試験

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

• MIRS0105 メカニクスシステム試験報告書(MIRS0105-MECH-0005)



2. プレ競技会


• 2002/12/18(プレ競技会１)
  起動もできなかった。
• 2003/01/17(プレ競技会２)
  ポスト周回と獲得動作はできた。しかし、超音波による探索が出来ない…。
3. 競技会


• 2003/02/07(MIRS2001 競技会)
  
  MIRS2001 競技会のポスト数は3つでした。

  	1回目		2回目		合計		順位
  	獲得順序 (獲得ポイント)	タイム	獲得順序 (獲得ポイント)	タイム	獲得ポイント	タイム
  1班		5分00秒		5分00秒		10分00秒
  2班		5分00秒		5分00秒		10分00秒
  3班		5分00秒		5分00秒		10分00秒
  4班		5分00秒		5分00秒		10分00秒
  5班	2→1→3 (3 point)	5分00秒	2→1→3 (3 point)	5分00秒	6	10分00秒	1

  見事優勝を勝ち取りました。
  
  

開発項目		工数(h)
メカ(3人)	001.調査、学習	25.0
	002.システム開発計画立案	22.5
	003.基本設計	34.0
	004.詳細設計	97.0
	005.製造	268.0
	006.サブシステム試験	7.5
	007.システム試験	9.5
	008.改善設計	3.0
	009.ドキュメント整備	2.5
	010.ミーティング	5.0
	011.その他	95.0
メカ合計		569.0
エレキ(2人)	001.調査、学習	23.5
	002.システム開発計画立案	22.5
	003.基本設計	23.5
	004.詳細設計	79.5
	005.製造	218.5
	006.サブシステム試験	13.5
	007.システム試験	153.5
	008.改善設計	21.0
	009.ドキュメント整備	19.0
	010.ミーティング	4.0
	011.その他	111.0
エレキ合計		689.5
ソフト(3人)	001.調査、学習	18.5
	002.システム開発計画立案	28.5
	003.基本設計	30.0
	004.詳細設計	71.0
	005.製造	281.5
	006.サブシステム試験	0.0
	007.システム試験	3.0
	008.改善設計	32.5
	009.ドキュメント整備	40.5
	010.ミーティング	6.0
	011.その他	89.0
ソフト合計		600.5

1. メカニクス

   	問題点	原因	解決策
   1	走行中にいろいろな部品（特にナット）が外れる。	ワッシャーを嵌めていなかった、仮止めのまま走行した等	ワッシャーを嵌めなおし、ねじも強く締めなおした
   2	モーターが回らない。動作が不安定。	前年度のMIRSから取ったモーターが間違った組み立て方をしてあった。	分解して汚れも取り、調整しなおした。
   3	MIRSが動いたり動かなかったりと、作動状況が不安定。	機体がアルミ主体なため、どこかが導通していた。	電源ボードを真っ先に直し、導通している可能性のある場所は全て基盤を削るか、スペー サーを入れて解決。
   4	タッチセンサがよく壊れる。	MIRSの当たりが強い。前年度の部品が壊れている。	バンパーに緩衝材（ソルボダンパー）を追加。新たな部品を発注した。
   5	ポストにMIRS側面がひっかかる。	MIRSの設計上、側面の溝にスイッチが嵌ってしまうことがある。	タイヤに干渉しない程度に側面のガードをつけた。
   6	超音波センサの値が正確に取れない。	地面に跳ね返ってしまっていた。	超音波センサ送信部の下にバレルを伸ばした。送信部を覆うタイプのバレルでは値が取れ なかった。
   7	結合作業がしにくい。	シャーシ間の間隔が狭く、ISAラックの設計が作業効率を重視していなかった。	シャーシ間にスペーサーを入れて作業しやすくし、ISAラックを開閉可能なように設計し なおした。

2. エレクトロニクス

   	問題点	原因	解決策
   1	超音波センサが動かない。	ドーターボードで超音波センサの送信信号のプルアップをしていなかった。	プルアップさせることで動いた。
   2	モータが回るときと、回らないときがある。	FPGAとドーターボード間のジャンパが少しずれたり、ケーブルの接触が悪くなることで動かなくなった。	FPGAとドーターボード間のジャンパをきちんと差し込み、ケーブルもコネクタ部分を付け替えた。
   3	電源ボードからでてくる電圧が一定でない。	・可変抵抗を使っているため、衝撃によって抵抗値が変わる。 ・三端子レギュレータの計算式が、atlmirs のものと、三端子レギュレータの製造会社のものとで違っていた。	三端子レギュレータの製造会社の計算式を元に、可変抵抗を固定抵抗にして、回路も変えた。
   4	電源ボードの回路の線がとんだ。	線が細めであった。	基板には電源用のケーブルでジャンパし、電源ボードのPCBの線を太くした。
   5	超音波センサのIRQが入らない。	IRQ3は既にシステムの予約番号であり、ユーザーは使えない。	/proc/interruptsの中に予約番号が書かれており、ユーザーが使用できるIRQ番号に変更した。
   6	FPGAの回路データがダウンロードできない。	ピン割り当てされていないピンがある。	使用していないピンはすべてハイインピーダンスにした。
   7	Disk On Moduleからブートできない。	配線ミスにより、スレーブとして認識されていた。	マスタとスレーブの区別をする線をGNDにした。
   8	ロータリーエンコーダから波形が出力されない。	コネクタの老朽化により、接触が悪くなっていた。	コネクタ部分を再度半田付けをした。
   9	超音波が地面を感知してしまう。	超音波は指向性が悪い。	送信側マイクにカバーを取り付けた。

3. ソフトウェア
   

   	問題点	原因	解決策
   1	ネットワークにつながらない。	アルミ板を通して電源ボードとドーターボードが導通していた。そのためOSのシステムにバグが起きた。	導通の原因はネジとアルミ板のネジで止めてある部分とが導通していたためなので、導通しないような素材でコーティングした。その後、OSを再インストールした。
   2	起動中に止まる。	プログラムの実行中に電源不足で強制終了したことで、ファイルシステムにバグが起きたと思われる。	OSを再インストールした。バッテリーはこまめにチェックするようにした。
   3	うまく直進できない。	ソフト側からDuty比を左右そろえて送っても、実際の動きは本体の重心位置や、モーターの精度によりそのDuty比通りに動いてくれないため。	左右のエンコーダのカウント値をみて、リアルタイムに左右のDuty比を調節するようなプログラムを作った。
   3	RT_FIFOにカーネル側から書きこみつづけると途中で書きこめなくなってしまう。	RT_FIFOは書きこまれるとその値を読み出されるまで保持するため。	RT_FIFOに書きこむのは必要な時だけにし、書きこまれたら随時ユーザー側で読み出し、さらに保険として、RT_FIFOの確保するメモリサイズを増やした。(100byte→4000byte)
   4	エンコーダモジュールを組み込むとフリーズする。	無限ループでまわしているスレッドの中でRT_FIFOのクリエイトとデストロイを繰り返していた。	RT_FIFOのデストロイとクリエイトはモジュール組み込み時に行うようにした。
   5	ポストの周りを一周すると回転開始位置と終了位置がずれる。	3の原因と同様	値を変えながら繰り返し動作を観察して、最適な値をみつけだし、ポストを回っている途中で左右のDuty比を変えるようにした。
   6	赤外線センサが読み取れない。	使用する赤外線センサの番号の指定が間違っていた。	ユーザープログラムとカーネルプログラムで処理が重なっていたため、カーネル側のその部分を削除した。
   7	MIRS競技中にポストをうまくまわれず、途中でぶつかってしまう。	回転するときの右のタイヤのDuty比が小さすぎた。	右のタイヤのDuty比を大きくした。

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

メカ:

塩ビ板よりもアルミの方が軽く、丈夫だということでアルミ製のシャーシを作ったが、なか なか険しい道のりだった。まず硬すぎるために作業がしにくく、金属なので電気を通す。一箇 所どこかが導通すれば、MIRSに実装している限りどの基盤でもショートする可能性があるとい う危険性があった。チェックに次ぐチェックにより、その問題点は解消された。しかし、アル ミの粉に鼻をつまらせ、周りに騒音を撒き散らしながら完成した機体が導通する危険いっぱい という、塩ビ板では考えられない苦労をするだけの価値がアルミ製の機体にあったかどうかは 今でも疑問である。 　当初は重心や振動を考えて、低く車体を抑えて設計したが、作業がしにくいというソフトや エレキの要望（苦情）に妥協し、日に日に車体は高くなっていった。振動はナットを強く締め ることによってISAラックの基盤に影響しないようにしたが、その分衝撃には弱くなった。バ ンパーに緩衝材を張りつけることによってポストへの衝突による衝撃は軽くなったが、MIRSが 不恰好になってしまったことは否めない。 　後半は主にソフトの要求を第一に微調整をしていった。特にセンサ用の穴は各階に空け、ど の位置が最もUSS/IRSにとって良いかという試行錯誤を繰り返すことになった。 　また、なぜかケーブルやコネクタによるトラブルが多かった。モーターがうまく動かないの は”ケーブルの張り具合”に問題があるという事実は衝撃的だった。見えない位置にテープを 張り巡らし、最適な”張り具合”を維持したが、その辺りも含めて、ソフト・エレキ・メカの 結合がしやすいMIRSを最初から作ることができれば良かったと思う。

エレキ:

今回から赤外線の番号認識や、白線による検知など、新しいことにチャレンジしたこともあり、 ドーターボードのPCB回路設計がとても大変でした。使用するセンサも増えて、 昨年からのドーターボードのサイズでは、おさまりきらない回路数になってしまい、ぎりぎりまで 詰めた結果、導通の問題が山のように出てきました。電源ボードもドキュメントが間違いだらけで、 設計通りのボードが完成するまでにかなりの時間を費やしました。 FPGAの回路では、LCDが最後まで、使用することができず、MIRSの情報を得るのに、ディスプレイに いちいち繋がないとならず、作業効率は悪かったです。基板や素子のリサイクルが結果として、 問題の原因になったこともあり、ハード面での問題は、ソフトの作業を遅らせる要因でもあるので、 ハードはもっと早くに完成させるべきだと思いました。ソフトと同時にエレキのハードの問題が 僕らのMIRSでも起きたので、改善させるべきことだと思います。一応優勝は出来たので良かったと思います。

ソフトウェアを担当するに当たって、RT-Linuxの知識がまったく無い僕にはどこからどう手をつけていいのかわからなかった。プログラムを組んでみようと思ってもRTの関数はさっぱりで、調べても言葉の意味が全然わからなかった。そのためソフトの開発に本格的に取り組めるようになったのは10月後半に入ってからだ。その頃はRT-Linuxがわかるようになったこともあって危機感などまったくなく、四方から聞こえる“このままじゃ動かないぞ”という声にもあまり実感がわかなかった。しかしプレ競技会を目前にしてピクリとも動かないMIRSを見ていると焦りの色が浮かんできた。 焦りの色は徐々に濃くなっていき、結局、MIRS競技会本番一週間前は学校に泊り込みで作業することとなった。この追い込みが成果あって、なんとか本番では最終的にポストを全部獲得することができ、めでたしめでたしで終わることができた。とはいえMIRSに重点をおいた結果、授業にあらゆる支障をきたしてしまったことは言うまでも無い…。 ソフトはたった数個のファイルをプログラムするだけの作業にみえて、実際はデバッグの作業にかなりの時間を費やすのだということを知った。ソフトのみではうまくいくことも、エレキとメカと結合するとうまくいかないのだということも何度かあった。この１年半MIRSを通して得た経験や知識はきっとこれから社会にでて必ず役立つだろうと思った。

　MIRS0105のみなさん。お疲れ様でした。
　２度にわたる競技では、順番は違えど三つ全てのポストを取ることに成功し、あまつさえエ キシビジョンでは満点の演技を披露することができました。
　思い起こせば一年半前。チームメンバーが発表されたとき、いったい誰が５班に期待したで しょう。
　「こいつがいれば大丈夫だ！」的なエースは居らず、手探りの作業を進めることになりまし た。
　不安の残るFPGA。導通だらけの機体構成。何度も削りなおしたドーターボード。原因が特定 できないセンサトラブル。つながらないネット。供給されない電源。ふっとばされたディス ク・オン・モジュール……
　数々のトラブルを克服し、改良を重ねたOUROBOROSは、しかし充分な結果を残してくれまし た。
　特にソフトの泊り込み一週間という驚異的な追い上げは、メカやエレキにも伝染し、勇気付 けられる思いでした。
　最後に。
　工作室の定期的な片付けや大掃除など、他の班に先駆け、率先して作業をしてくれた MIRS0105のメンバーに。
　ありがとうございました。