|
沼津高専 電子制御工学科 |
||||
|
|
||||
|
改訂記録 |
||||
|
版数 |
作成日 |
作成者 |
承認 |
改訂内容 |
|
A01 |
2007.02.09 |
星野 |
星野 |
初版 |
開発過程分析
開発予定と実際の開発の対比
|
メカニクス |
|
|
|
期間 |
開発予定 |
実際の開発 |
|
９月 第２週 |
詳細設計書・開発計画書・技術調査書の作成 |
詳細設計所作成 |
|
９月 第３週 |
基本設計レビュー |
詳細設計所作成 |
|
９月 第４週 |
タイヤ探し・白線センサ(ポスト認識用）を取り付ける金具の作成 |
詳細設計所作成 |
|
９月 第５週 |
期末テスト |
|
|
１０月 第１週 |
白線センサ(ポスト認識用）を取り付ける金具の作成 |
詳細設計所作成 |
|
１０月 第２週 |
白線センサ(ポスト認識用）を取り付ける金具の作成 |
製造仕様書作成 |
|
１０月 第３週 |
白線センサなどの取り付け |
部品作成 |
|
１０月 第４週 |
白線センサなどの取り付け |
部品作成 |
|
１０月 第５週＋１１月 第１週 |
やることがないのなら、他の所を補助 |
部品作成／制作室清掃 |
|
１１月 第２週 |
やることがないのなら、他の所を補助 |
部品作成 |
|
１１月 第３週 |
やることがないのなら、他の所を補助 |
部品作成 |
|
１１月 第４週 |
やることがないのなら、他の所を補助 |
部品作成 |
|
１１月 第５週＋１２ 第１週 |
統合試験チェック及び、改良 |
統合試験 |
|
１２月 第２週 |
統合試験チェック及び、改良 |
|
|
１２月 第３週 |
|
トラブルシュート |
|
１２月 第４週 |
冬休み |
|
|
1２月
第５週＋１月 第１週 |
冬休み |
|
|
１月 第２週 |
|
プレ競技会 |
|
１月 第３週 |
|
トラブルシュート |
|
１月 第４週 |
|
トラブルシュート |
|
１月 第５週＋ ２月 第１週 |
|
トラブルシュート／リハーサル／競技会 |
|
エレクトロニクス |
|
|
|
期間 |
開発予定 |
実際の開発 |
|
９月 第２週 |
詳細設計書・開発計画書・技術調査書の作成 |
詳細設計所作成 |
|
９月 第３週 |
基本設計レビュー |
詳細設計所作成 |
|
９月 第４週 |
各センサ類の動作確認 |
詳細設計所作成 |
|
９月 第５週 |
期末テスト |
|
|
１０月 第１週 |
ドーターボードの改良など |
詳細設計所作成／センサボードの設計・製作 |
|
１０月 第２週 |
ドーターボードの改良など |
製造仕様書作成／センサボードの設計・製作／トラブルシュート |
|
１０月 第３週 |
ドーターボードの改良など |
ドータボードの製作 |
|
１０月 第４週 |
ドーターボードの改良など |
ドータボードの製作 |
|
１０月 第５週＋１１月 第１週 |
ドーターボードの改良など |
ドータボードの製作 |
|
１１月 第２週 |
ドーターボードの改良など |
ドータボードの製作 |
|
１１月 第３週 |
ドーターボードの改良など |
ドータボードの製作 |
|
１１月 第４週 |
ドーターボードの改良など |
ドータボードの製作 |
|
１１月 第５週＋１２ 第１週 |
統合試験チェック及び、改良 |
ドータボードの製作／トラブルシュート／統合試験 |
|
１２月 第２週 |
統合試験チェック及び、改良 |
トラブルシュート |
|
１２月 第３週 |
|
トラブルシュート |
|
１２月 第４週 |
冬休み |
|
|
1２月
第５週＋１月 第１週 |
冬休み |
|
|
１月 第２週 |
|
電源ボードの設計・製作／プレ競技会 |
|
１月 第３週 |
|
トラブルシュート |
|
１月 第４週 |
|
トラブルシュート |
|
１月 第５週＋ ２月 第１週 |
|
トラブルシュート／リハーサル／競技会 |
|
ソフトウェア |
|
|
|
期間 |
開発予定 |
実際の開発 |
|
９月 第２週 |
詳細設計書・開発計画書・技術調査書の作成 |
詳細設計所作成 |
|
９月 第３週 |
基本設計レビュー |
詳細設計所作成 |
|
９月 第４週 |
メインプログラムの作成 |
詳細設計所作成 |
|
９月 第５週 |
期末テスト |
|
|
１０月 第１週 |
メインプログラムの作成 |
詳細設計所作成 |
|
１０月 第２週 |
メインプログラムの作成 |
詳細設計所作成 |
|
１０月 第３週 |
メインプログラムの作成 |
プログラム作成 |
|
１０月 第４週 |
メインプログラムの作成 |
プログラム作成 |
|
１０月 第５週＋１１月 第１週 |
メインプログラムの作成 |
プログラム作成 |
|
１１月 第２週 |
ドライバ・関数のデバック |
プログラム作成 |
|
１１月 第３週 |
ドライバ・関数のデバック |
プログラム作成 |
|
１１月 第４週 |
ドライバ・関数のデバック |
プログラム作成／統合試験 |
|
１１月 第５週＋１２ 第１週 |
統合試験チェック及び、改良 |
トラブルシュート |
|
１２月 第２週 |
統合試験チェック及び、改良 |
トラブルシュート |
|
１２月 第３週 |
|
トラブルシュート |
|
１２月 第４週 |
冬休み |
|
|
1２月
第５週＋１月 第１週 |
冬休み |
|
|
１月 第２週 |
|
トラブルシュート／プレ競技会 |
|
１月 第３週 |
|
トラブルシュート |
|
１月 第４週 |
|
トラブルシュート |
|
１月 第５週＋ ２月 第１週 |
|
トラブルシュート／リハーサル／競技会 |
基本的には開発予定よりも作業は常に遅れていました。余裕を見て、前に前にと予定を組んだこともありますが、実際に作業をする時間が予想していたものよりも非常に長かったということが原因に挙げられます。
作業工数分析
作業工数は、その作業に従事した時間のもっとも多い個人のものを代表して記載する。
メカニクス
|
部品作成 |
32時間 |
|
トラブルシュート |
78.5時間 |
エレクトロニクス
|
センサボードの設計・製作 |
17.5時間 |
|
ドータボードの設計・製作 |
55時間 |
|
電源ボードの設計・製作 |
35時間 |
|
トラブルシュート |
139時間 |
ソフトウェア
|
プログラム作成 |
32時間 |
|
トラブルシュート／プログラム改善 |
100時間 |
|
駆動系パラメータ再測定 |
10時間 |
FPGAボードの改良後のデータ→■
開発終了したソフトウェアのデータ→■
現システムの問題点
・ 駆動系のパラメータがおかしい
・ 走行速度が遅い（精度を上げるために速度を落とさざるを得なかった）
総括
メカニクス
MIRS0605のメカの特徴は、エレキが新しく作ったドーターボードなどの取り付けや、MIRS前面部のポスト番号認識部の作成、取り付けを行いました。ドーターボードの取り付けは最初の段階と比べ、位置がずれるなどの問題がありましたが最終的にはうまく取り付けることができました。ポスト番号認識部は概ね良好に動作しましたが、うまく番号を認識できないときがあったのでタッチセンサと白線センサの取り付け方に少し不備あったようです。そのせいで競技会中、時間をとられてしまったのが残念です。
エレクトロニクス
MIRS0605のエレクトロニクス班では、ほとんどの回路基盤の再設計を行った。再設計を行った回路はMIRS0605独自の改造・改良をし、いくらか標準部品より便利・高機能な回路を使用した。
機能性よりも開発、デバッグのし易さに重点を置き、例えばドータボードでは各所にセンサの値を表示するLEDを設置しエレクトロニクス担当者でなくてもセンサの故障や不具合などが一目で分かるようにし、MIRS起動中のセンサコネクタの抜き差しもできるように（途中で抜き差しが起こったときにディジタル論理が不安定にならないように）したところも大きな改良点のひとつであろう。
改造、改良したほとんどの部品に（部品単体として）満足な結果を出すことができた。
ソフトウェア
ソフト班の意見が、メカ、エレキに正確に伝わっていなかったことで、後々になって問題が表面化することがあり、全体的な連絡不足が問題となった。ソフト班内部で
も、仕様が全体に理解されておらず、例外的な処理に対する認識の甘さが見えたように思える。
開発初期の段階においては、メカ、エレキによってMIRS本体の使用が出来ない為、コンソールによって確認できる程度のプログラムを書いていた。開発中期にMIRS実機
で動作させた時、問題が複数発生したため、コーディングを全面的に見直すこととなり、ソフト全体としては、プログラム理解が進んだ以上の成果は無くなってしまった
とも言える。また、メカ、エレキとの意見の相違が発生するなど、問題点が表面化し、その対応に多くの時間をさくことになってしまった。開発後期になると、理解度に
よってプログラムに参加できる人数が限られてしまい、進行負担の格差が大きくなってしまった。
全体的な進行においては、複数人での開発用に、ある程度統括されたヘッダファイルを使うことで、ある程度の負担を分散することが出来たように思う。ことあるごと
に共通のマクロ定義を行うことで、後半における変更の煩雑さをカバーできたと考えている。ディレクトリ構造については、もう少しMakefileを駆使した作りにすればよ
かったように思う。このあたりは改善できるはずである。
また、工作室と競技場での環境の違いを想定した値の設定、タスクの設定が出来なかったのは、想定範囲の狭さを実感させられたように思う。
全体
メカ・エレキ・ソフトのそれぞれが単体としては纏まってよく機能していたと思える。
ただし、お互いに連携しあうときに、メカの考え、エレキの考え、ソフトの考えという3つのそれぞれの考えを上手く伝え合うことができずに、違う担当同士での連携というものの難しさを実感させられた。
互いに班内ではわかっているけれど、外にそれを伝えるときの考えの違いが、作成した結果という形で本来考えていたものとは若干違うものとしてできあがってくるということもあったように思える。
しかし、その点も調整を行っていくことによって解消でき、開発全体としてはよくできていたのではないかと思えた。