1　開発過程分析
2　開発工数分析
3　現システムの問題点
4　総括

予定していた開発スケジュールと実際の開発スケジュールを比較する。

製造仕様書などの考慮を忘れていて、仕様書の開発時間が延びている。また、ソフトウェアも1月後半まで完了せず、ギリギリである。
ドットマトリクス補助回路などは、計画書以降の設計で消滅しているため、時間がかかれていない。
この計画と実際との違いを見ると、まず仕様書を書く時間が十分にとれていないことがわかる。計画段階では、製造仕様書などをどの程度書けばいいか理解していなかったことが問題である。この段階でミスに気がつかないのは仕方がない面もあるが、計画書と大きくズレている10月あたりにもう一度きちんと計画をすべきだった。
また、十二分にデバッグに時間をかけたかったが、結局年明けになってしまっている点も反省すべきである。技能五輪に多少振り回されているが、一月もズレてしまっている。メカの開発も順調とはいえず、部品発注したものが予想や計画より遅れてしまったということもあり、統合の終了が年末になっている。
今回の開発計画では大きい反省点が２つある。ひとつは、計画表を更新しなかったことだ。プロジェクトというものは様子が変わっていくものであり、計画が乱れるのは当然である。
そのことによって生まれるズレには対応しなければならなかった。
ふたつめは、計画書自体があまり練られて作られていないことである。計画を立てる際にこれはこのくらいかかりそうという予想で組み立てたが、本来は競技会からの逆算をすべきであったと思われる。

2　開発工数分析

作業報告をもとに集計したものを以下に示す。

現時点で発覚している問題点を以下に示す。

・ 現システムの問題点
ポストの獲得をミスする可能性がある。
　−何度もテストをして、確実にポストが獲得可能なゲットアクションを作成する

ポストのスイッチに引っかかってしまう。
　−タッチセンサの部分一部だけを延長し、物理的にひっかかることがないようにする。

ズレが大きくなりすぎて仮想マップでも補正できないことがある。
　−ある意味仕様だが、例外処理を充実させるしかない

ソフトウェアの関数が多すぎる
　−引数によって微妙に行動を変えるようにすればよいが、コーディングに時間がかかる欠点もある。

ドットマトリクスが実装できていない
　−時間的に不可能と判断したので、新年最初の授業で開発の凍結を決定した。

非常に重たい
　−ソフトウェア二人だけでは腕がもたない。肉抜きなどをすれば多少は改善するか？また、このせいで微小回転動作などの深刻な影響がでている。

サーチ動作終了後停止せずに、ガクガク動き続ける。
　−詳細不明。DrshiftやDlshiftを下げてやることで軽減することはするが、完全になくすことはできなかった。

動作中のLinuxのフリーズ(カーネルパニック)
　−詳細不明。いまでもまれに起こることはあるが、頻度はそんなに高くない。

超音波センサの値が異常になる。
　−スレッドを開かずに超音波センサを使おうとすると、異常な値が返ってくる。また、それ以外にも超音波センサ使用中に強制終了(Ctl+C)すると起こる可能性があるが、それはhalt以外では直らないようだ。

中心までの移動の際にまっすぐ進まない。
　−問題ないので放置してあるが、パラメータをもう一度とるべきである。

最後のポスト位置予想プログラムで、予定外の向きを向いてしまうことがある。
　−たぶんm[2](ミルスの現在角度)の異常であるが、フィードバックのミスは見つからなかった。また、それほど頻発するわけでもないのでデバッグも難しい。

ギアが破損する。
　−ギアボックスを買い集めた。結局９のギアボックスが昇天した。生き残りは１つである。

バンパーのゴムを付けられるのが一人だけ
　−指の力が一定以上でないとバンパーのゴムが取り付けできない。

繰り返し使用しているとナットが緩んでしまう。
　−こまめに調べるしかない

一度分解してしまうと組み立て直すのに時間がかかる。
　−早めにメカを完成させよう。

すべてアルミで作ったので重い。
　−アクリル板で作ればよい(強度の問題もあるが)

・ 解決してきた問題点
ロータリーエンコーダの値が異常
　−パラメータによる回避は不可能であるという結論が降りた。ソフトウェアで360度回転を373度回転にするなど、直接補正を加えてやる。

正対補正がうまくいかない
　−まわりにあるものの干渉をなくす。ポスト判別機構や、地面の影響が考えられたので、高い位置に設置し、ポスト判別機構を裏にまわした。また、パラメータのdrshiftとdlshiftを少し高めに設定している(けれど可能な限り低く設定)。また、これでもうまくいかないので、激突した際必ず正対するようにメカ的に補正をかけている。

アームの電圧によって、タッチセンサをひきづり停止してしまう。
　−タッチセンサが床に刺さらないようにし、おろしたあとあげる命令を出した。このとき、電圧にとても依存するので、ちょくちょく時間を変更する必要がある。

アームが片方だけ速い
　−理論的に同じ電圧がかかるようにしたが、制御不能だった。こまめにモータをはずしギアをあわせてやっている。また、タッチセンサを増やして片方の腕づつ制御すれば片方だけ速くとも制御可能である。

移動中に目標のポストにぶつかってしまうことがある。
　−mirs0604のロータリーエンコーダ監視プログラムを拝借した。停止する可能性があるすべての移動に搭載したため、ロータリーエンコーダによる強制停止はプログラム中ほぼおこらない。

ポスト判別機構で読み取りができない。
　−動作をゆっくり行うようにした。このとき、新たな関数を作成したのだが、これは標準機の周回動作中のタッチセンサが押すまで前進するプログラムのアレンジである。

セグメンテーションフォウルトで終了することが多い
　−確実に配列のミスである。初期化など関数で2〜3回悩まされた。また、複合コンパイルのため、関数の引数が正常でなくとも(voidに引数を渡せる)コンパイルができてしまい、そこでこれが起こっていた。

駆動系およびシステム系の電池の接触不良による意味不明な動作
　−原因がとてもわかりづらかった。一瞬でも駆動系の電圧がとぶと、そこからすべてが狂いだすので、システム・駆動系ともに良い電池及びコネクタを使用するようにしている。

夜になると(長時間運用後)完全にシステムが停止する。
　−CPUボード・メモリ・DOMなどの複合的な異常だと思われる。すべてを交換してもらったあとはなくなっている。

FPGAやモジュールの変更が適用されない。
　−スタートアップが書き換えられていたようだ。詳しいことはわからなかったが、牛丸先生に相談したところ、直して貰えた。

ポストを2個発見してしまう。
　−仮想マップ適用時に同じマスおよび隣接するマスにあるポストを削除するようにした。ちなみにポストスイッチに位置によって、低い位置でポスト探索するMIRSならどこでも起こりえる。

ロータリーエンコーダが急に反応しなくなった。
　−ケーブルの内部で断線していた。とても稀、レアケース。導通しているのに反応がなかったら、コレの可能性もあるが、たいていはケーブルの方向のミスである。必ず方向はチェックすること。

ケーブルがすぐに断線してしまう。
　−正しいケーブルのつけ方が徹底していなかった。ターミナルの爪が2個あるが、一つ目(手前)がしっかり皮膜を噛むようにし、2つ目(奥が)線を噛むようにすること。また、余分な導線は切っておくといい。圧着端子にとりつけた際、オス端子に入りにくくなる。

センサの精度がまちまち
　−可変抵抗の値を変えてみる。しかし、超音波に限っては計測可能距離が伸びるわけではないので、1つ以上規定距離(2000くらい)測れるのをつくり、それをサーチ用にした。

Map_move実行時、0,0の位置に移動してしまう。
　−移動先データの初期値のミス。１番目からデータを参照する配列と0番目からデータを参照する配列がごっちゃごちゃになっていたので、そこを修正した。プログラム作成の際に統一しておくほうがいい(というか0番目から使ったほうがいい)。

仮想マップが一次元配列で構成されていたので活用が難しかった。
　−仮想マップを二次元配列に直した。この際いくつかのプログラムが失われている。

バネが強すぎてアームとの連携がとれなかった。
　−後ろにポスト獲得機構を移した。

ポストの角度によって、ポスト番号を識別できないときがある。
　−ソフトウェア的に改善をし、さらに正対補正の制度を高めた。

ポスト識別機構のタッチセンサがうまく押されないことがある。
　−ソフトウェアで動きを調整した。

4.1　チーム全体

MIRSの開発全体を通して―――
　　計画からだいぶ遅れたものの、最終的には私たちの班はMIRSを完成に近い状態に持って行けたと思う。
　　デバッグの時間を十分にとるつもりが、デバッグに必要な時間というのを軽視していたため、最終的に余りの時間をデバッグにまわすということになったのは残念だ。しかし、1月のほぼ全てをMIRSの改善に費やせたのはかなり大きいと思われる。この期間に行えた改善はとても大きなものであろう。メカの開発が完全に終了したのは、競技会の週の月曜日であとはひたすらソフトウェアのデバッグに打ち込めた。
　　また、アームなどの各要素も、統合試験予定日(12/24)までには実装可能なレベルまで出来上がっていたことも大きかった。特にポスト判別機構の完成度は高く、これが原因での大きな仕様変更行っていない。 　

マネージャーとして―――
　　マネージャーの仕事というのは、各人員に仕事が集中しないよう、かつ各人員にやることがなくならないようにし、開発計画を守っていくものだと思う。
　　12月の終わりまでに実装試験を行う計画は実際行えたので、この点は非常によかったと思う。MIRS0701のメンバーは、言われたことや、やらねばならないことを行う能力に関して、非常に高いレベルを元から持っていたものと思われる。時間ギリギリや、泊まりこみで開発を行ってくれた各人に感謝したい。
　　また、１月に入ってからはソフトウェアの開発で手一杯になってしまい、(といってもサブプログラマーであり、他の班よりは余裕があったはずだが)あまり指示をだせていなかったと思う。この段階で、ムービーなどにあまった力を入れてくれる人が出始め、マネージャーとしては非常にうれしかった。ソフトウェア補助についても、頼んでいないのに徹夜に付き合ってくれたり、土日の割り振りなどをしてくれたのはマネージャーをやっていてよかったと心から感じさせてくれた。
　　最後に、高専の目標である「人柄の良い技術者」になるために、この経験は生かせることを伝えたい。他の班員を気遣いつつ、自分の仕事を完遂することは非常に難しいが、身内の贔屓目かもしれないがMIRS0701のメンバーはできつつあることを私は保証する。この経験を生かし、企業で、学校で、社会で活躍してくれることを切に願う。

あと個人的なメッセージですが、
―池田へ
　口では指示されたことしかやらないといいながら、結局いつも気を回してもらっていた。ドキュメントマネージャーとしても自分の時間を割いて完成度の高いものを作ってくれた。特に仕事が早く、そのことに頼りっきりになっていたと思う。忙しい時間帯での半田付けもいやな顔せずにやってくれてありがとう。

―竜次へ
　MIRS0701のメインプログラマーとして非常に頑張ってくれた。自分ではあきらめそうなプログラムもちゃっちゃと作ってしまっていて、底力を思い知らされた。一番私に近いところで働いてくれて、一番私のストレスの被害にあったり、体調不良の被害にあってると思うが、愛想尽かさずに一緒にプログラムしてくれてありがとう。

―加藤へ
　ポスト獲得機構の完成度は非常に高いものだった。一番初めに徹夜に付き合ってくれたのも加藤だった。度重なる仕様変更で、作ったものが一日程度しかMIRSに使われていなかったこともあったり、時間的に厳しいこともいろいろ頼んだはずなのに、いつも常に対応してくてありがとう。

―佐々木へ
　はじめひね曲がってたアームをあそこまで獲得率の高いものにしてくれたのは非常に大きい功績だと思う。成績からあんまりまじめな人だと思っていなかったけど、実際は責任感が非常に強く親身に助けてくれる人だとよくわかった。バンパーも佐々木なしではありえなかったし、ギアボックスもそこら中回って回収してくれた。ありがとう。

―田中へ
　なんだかんだで一番つらい役回りになってしまったことはみんな理解している。面倒な仕事も今まで仕事と関係ないムービーの仕事も、さらにはいろいろな発注など雑務を全部おしつけていたのは承知している。結局勝手に副リーダー設定していて、一番頼りにしていた。あきらかに理不尽な役回りにも耐えてくれてありがとう。

―水上へ
　やはり、ポスト獲得機構の完成度は非常に高いことは書いておきたい。いろいろと改善案を話し合ったり、アイデアを出してくれ、さらにそれを実装してくれた。ドキュメントの更新もまめにしてくれ、お蔵入りになったドキュメントまで作らせてしまい、申し訳ない。家が遠いのにもかかわらず、ＭＩＲＳの仕事を優先してくれて、ありがとう。

―宮川へ
　流れで実行委員を半ば押し付けてしまったし、さらにその実行委員という立場から競技会のことに関して非常に頼ってしまった。実行委員になってからの仕事はみんなも認めるように非常に重要な役割だったと思う。また、一瞬しか流れないあのムービーロゴは個人的には大好きだ。ＦＰＧＡに関してもMIRS0701では理解しているのが一人だけだったと思い、FPGAの開発も一人でしてくれた。競技会自体が成功したのは宮川に依るところが大きいと思う、ありがとう。

4.2　メカニクス

アーム（KWG-01 アンテナ）のよかった点はとにかく目立つことである。0701は他のどのMIRSより大きく目に見えたメカの改造があったため観客の目を引けたと思う。直接競技に関係したメリットも獲得時の誤差の除去、獲得の時間短縮、獲得確率の向上とアームはよいことづくしだ。 しかし、はじめのころはアームが何よりも重く、ギヤボックスをいくつも壊しており、来年MIRSを行う方にはお勧めしない。 本番アームが動いてくれて本当によかった。 忘れられがちですが開閉式バンパーもなかなか優秀なやつなので、多少見ていただけたら幸いです。

ポスト番号識別装置を作るにあたって、一番苦労したのはどうやってバネを使って機能を実現するかということだった。 結局、バネに軸として長いねじを通すことで、バネを搭載することに成功した。 設置場所が当初と変わってしまったのは残念だったが、 バンパーを付けることで多少の正対補正の誤差も修正できる新しい機能を手に入れた。 最終的に予想以上に完成度の高いものを作れて良かった。

4.3　エレクトロニクス

エレキとしての仕事は、FPGA回路の改良と新規基盤の作成であった。 去年のドータボードを再利用することで、ある程度の作業量の軽減に繋げる事が出来たのは良かったと思う。 我が班のオリジナル機能である、ポスト獲得装置とポスト番号識別装置について、 ポスト番号識別装置の方で新規に作成する基盤はなく、ポスト獲得装置の方の基盤も既に回路図が出来ていたので容易であった。 しかし、FPGA回路の更新、基盤実装後の動作の際に起こる不具合など、ある程度下地が整っているにも関わらず、 予期せぬ状況へと陥る事があるという事を痛感した。

中でもICの破損による誤動作はアーム自身を痛める事になるので、責任をもって取り組まなければいけなかった。 アームの強度との兼ね合いを考え、基盤を二つ用いる案に切り替えるなど、当初の予定と比べると大幅な変更が起こってしまった。 基盤自体が悪いという事ではなかったのが幸いだったが、 あらかじめ複数の実現方法を考えて望むべきだと、MIRSを作るという事で学んだような気がする。

4.4　ソフトウェア　最終プログラム（取扱説明書つき）

ソフトの開発は半ばを過ぎたあたりから本格的な開発に移った。 残念ながら、当初予定していたドットマトリクスの実装は時間の都合上、断念せざる終えなかった。 ソフトウェアの大きな問題となっていたのは、マップを利用した移動と正対補正の二つである。 ソフト開発のほとんどの時間はこの二つのにとられてしまった。

アーム関係はアームの実装が遅れたため、アームの試験は最後のほうに行われたが、思っていたよりスムーズに動作した Mirs0701はハードウェアの仕様変更や故障のため、デバック作業ができない日も多かった。 プログラムの骨格は競技会の1週間ほど前から完成したため、それからはデバック作業が主になった。

Mirs0701のソフトは基本的なセンサ関係の関数以外はすべて改良または開発したものである。 しかし、見通しがあまかく仕様をたびたび変更したため、開発した関数の多くは開発開始当初には作る予定のないものがほとんどになってしまった。 また、ソフトが二人であったため、関数の使い方や変数が正しく使われているか、抜けている部分がないか確かめつつ作業した。 実際にハードウェアと合わせてみると、思っていた以上にエラーやバグが多く、デバック作業の大切さがわかった。