ドキュメント情報
名称 |
システム基本設計書MIRS0501-DSGN-0005 |
番号 |
|
版 数 |
最終更新日 |
作 成 |
承 認 |
改 訂 記 事 |
|
A01 |
2006.02.06 |
大村・伊沢・山田・後藤 |
伊沢 |
初版 |
Ø
CONTENTS
1. はじめに
2.
開発計画と実際の開発過程
3. 作業工数分析
4.
問題点と解決策
5.
競技結果
6.
総括
1.
はじめに
はじめに これはMIRS0501 の開発完了を示し、これまでの作業過程、作業時間を分析したものである。
2.
開発計画と実際の開発過程
|
開発項目 |
開始(計画) |
開始(作業) |
|
終了(計画) |
終了(作業) |
|
詳細設計書(メカ) |
2005/07/20 |
2005/10/01 |
|
2005/09/10 |
2005/10/28 |
|
詳細設計書(エレキ) |
2005/07/20 |
2005/10/01 |
|
2005/09/10 |
2005/10/28 |
|
詳細設計書(ソフト) |
2005/07/20 |
2005/10/01 |
|
2005/09/10 |
2005/10/28 |
|
製造仕様書 |
2005/09/12 |
2005/11/01 |
|
2005/09/26 |
2005/11/14 |
|
製造(メカ) |
2005/10/01 |
2005/11/14 |
|
2005/11/14 |
2005/12/12 |
|
製造(エレキ) |
2005/10/01 |
2005/10/22 |
|
2005/11/14 |
2005/12/12 |
|
製造(ソフト) |
2005/10/01 |
2005/10/22 |
|
2005/12/13 |
2005/01/09 |
|
改善設計,改善(メカ) |
2005/12/10 |
-- |
|
2006/02/03 |
-- |
|
改善設計,改善(エレキ) |
2005/12/10 |
-- |
|
2006/02/03 |
-- |
|
改善設計,改善(ソフト) |
2005/12/13 |
2005/01/09 |
|
2006/02/03 |
2006/02/03 |
以上が開発計画と実際の開発状況である。予定と計画に大きな差が出た理由は標準MIRSのパラメータ設定とセンサーの修理に非常に時間がかかってしまったからである。最終的には形にすることはできたが細かい修正をしている時間はなかった。
3.
作業工数分析
|
|
伊沢 |
大村 |
木村 |
栗田 |
後藤 |
杉山 |
八木 |
山田 |
項目別合計（合計） |
|
技術調査 |
70.25 |
74.5 |
113.5 |
74.75 |
69.25 |
118 |
100.75 |
118 |
739 |
|
システム提案、開発計画立案 |
0 |
18 |
0 |
9.5 |
9.5 |
3 |
0 |
0 |
40 |
|
基本設計 |
0 |
3 |
7 |
26.5 |
29.5 |
0 |
0 |
0 |
66 |
|
M 詳細設計 |
0 |
2.5 |
0 |
25 |
30.5 |
0 |
0 |
0 |
58 |
|
E 詳細設計 |
0 |
7.5 |
0 |
0 |
0 |
0 |
51 |
22.7 |
81.2 |
|
S 詳細設計 |
32.3 |
0 |
11 |
0 |
0 |
9.5 |
0 |
0 |
52.8 |
|
製造 |
0 |
3.5 |
0 |
0 |
0 |
0 |
0 |
0 |
3.5 |
|
M 製造 |
0 |
18.5 |
0 |
97.5 |
104.25 |
0 |
0 |
0 |
220.25 |
|
E 製造 |
0 |
19.5 |
0 |
0 |
0 |
0 |
34 |
81.5 |
135 |
|
S 製造 |
223.5 |
0 |
160.5 |
0 |
0 |
141 |
0 |
0 |
525 |
|
M サブシステム試験 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
|
E サブシステム試験 |
0 |
35 |
0 |
0 |
0 |
0 |
25 |
0 |
60 |
|
S サブシステム試験 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
|
システム試験 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
16 |
16 |
|
改善設計 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
|
ドキュメント整備 |
54 |
76.5 |
0 |
21 |
6 |
3.5 |
32.5 |
3 |
196.5 |
|
ミーティング |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
|
その他 |
14 |
117.5 |
0 |
41 |
42.5 |
59.5 |
88.5 |
64.5 |
427.5 |
|
工数合計（時間） |
394.05 |
376 |
292 |
295.25 |
291.5 |
334.5 |
331.75 |
305.7 |
2620.75 |
4.
問題点と解決策
エレクトロニクス
|
問題点 |
原因 |
解決策 |
|
ドーターボードのGNDと電源との導通 |
ドーターボードの彫りが浅かった。 |
カッターなどを使って溝を深くなるように削った。 |
|
ホワイトセンサの不良 |
ホワイトセンサの数が標準MIRSより4つ多く、過去のものを使ったが故障していた。 |
センサを取り替えた。 |
|
超音波センサの不良。 |
超音波センサが動作しなかった。 |
はんだの付け直し。 回路の迂回。 |
|
アームが伸びない。 |
アームの駆動用モータと電源間の回路の接触不良。 アームに取り付けておいたタッチセンサからの導線がMIRSの各部に引っかかっていた。 |
コネクタの付け直し。 電池ボックス部における導線とのはんだの付け直し。 |
メカニクス
|
問題点 |
原因 |
解決策 |
|
標準機作成に時間がかかってしまった。 |
解体したMIRSが古いタイプのであったため解体時間が無駄になった上、新しく作るのに時間がかかった。 |
特になし。 |
|
ポスト識別機構のタッチセンサがポストに当たってもセンサが反応しないことがあった。 |
タッチセンサの動作部の動きが硬く、MIRSのモータの力では反応しなかった。 |
タッチセンサを交換し、バンパーとタッチセンサの接触部を大きくした。 |
|
コンタマシンで部品をカットする際、直線を切ることが難しかった。 |
コンタマシンの性能に限界があるため。 |
ヤスリで削り、出来るだけ直線に近づけた。 |
|
設計の時に、製造の限界を超える精度の寸法が出てきた。 |
ギアの有効噛み合い径の値が小さすぎた。 |
穴を大きくして上下可動式にした。 |
|
ポスト識別機構が超音波センサに干渉してしまった。 |
超音波センサの位置が超音波センサの付近にあった。 |
ポスト識別機構を設計当初の位置から変更した。 |
|
アーム機構が動かなくなる。 |
アームが動くことで、タッチセンサのコードが絡まったり、引っかかったりしてコードが切れたため。 |
コードをアームの一部の角中空パイプの中にいれた。 |
|
機体が前面に傾いた。 |
ポスト識別機構、前部白線センサなど新規に作成したものが前面に集中したため。 |
機体の後部の空いているスペースにアルミ板を何枚もつけた。 |
|
質量が重くなりすぎた。 |
重さやMIRS本体のモーメントなどを考えずに設計してしまったため。 |
機体の後部の空いているスペースにアルミ板を何枚もつけた。 |
|
タイヤの片側が空転することがあった。 |
タイヤの径が左右で違っていたため。 |
タイヤを交換した。 |
|
機体が前後で安定しなかった。 |
ボールキャスタとタイヤの高さが違うため。 |
ボールキャスタと下段シャーシの間に何枚かワッシャーを入れ高さを合わせた。 |
|
センサコードと機体が導通してしまうことがあった。 |
機体の主な材質がアルミ板であったため。 |
コード付近のアルミ板に絶縁体をつけた。 |
ソフトウェア
|
問題点 |
原因 |
解決策 |
|
アームが勝手に戻ってしまった。 |
正回転から逆回転までの間に間隔がなかったのが原因 |
時間稼ぎを正回転と逆回転の間に入れた。 |
|
MIRSが時々かってに暴走した。 |
lqr制御プログラムの連続使用が原因 |
lqr制御が終了するたびに、エンコーダーの値の読み取りを止めるようにした。 |
|
超音波センサ読み取りができなかった。 |
超音波読み取りスレッドを立てていないのが原因 |
超音波読み取りスレッドを立てたら問題は解決した。 |
|
MIRSがまっすぐ走らなかった。 |
パラメータが原因 |
パラメータを修正することで解決した。 |
|
読み取ったセンサの値が常に'１'になってしまった。 |
ドーターボードとセンサのコネクタの接触/コネクタのつなぎ忘れでFPGADATAのダウンロードの失敗 |
コネクタとセンサの接触を直した。/コネクタをつなぎダウンロードがしっかりできるようにした。 |
|
/dev/rtf3が開けないことがあった。 |
プログラム内でFIFOを閉じて終了しなかったのが原因 |
OSの再インストールをした。 |
|
アーム制御でIOポートの書き込みがうまくいかなかった。 |
書き込み許可を獲らなかったのが原因 |
プログラム内に書き込み許可をとるようにした。 |
|
ライントレースにおいて白線を検知してもすぐにMIRSが停止しなかった。 |
白線を検知する間隔が長すぎたのが原因 |
プログラム内でチェック間隔を短くした。 |
|
コンパイルができないことがあった。 |
usr_mountを忘れたり、LANケーブルをさしていなかったのが原因 |
usr_mountができる環境を整えた。 |
|
lqr制御において、補正が大きすぎた。 |
drshift,dlshiftの値が大きすぎるのが問題だった。 |
それらの値を小さいものに変えた。 |
|
MIRSが直進しなくなった。 |
パラメータ、駆動系の関数をコンパイルしすぎたのが原因 |
それらのプログラムを、標準的なものに変更した。 |
|
白線センサで正しい値が読めなかった。 |
光の反射の関係で確実に正確な値が取れるわけではなかったのが原因 |
読み取る回数を増やし、そのなかで一番多い値を正確な値とした。 |
|
ポストを発見するのが早すぎて、ポストのかなり手前で停止してしまった。 |
超音波センサの感度がよすぎるのが問題。 |
ポストを発見したら、少し進んでから停止するようにした。 |
|
赤外線を発見するのが早すぎて、赤外線のかなり手前で停止してしまった。 |
赤外線センサの問題。 |
赤外線を発見したら、少し進んでから停止するようにした。 |
|
単体試験プログラムが動作しなかった。 |
初期動作モードを省いていたのが原因 |
初期動作モードをテストプログラム内に追加した。 |
5.
競技結果
|
試技 |
競技一回目 |
競技二回目 |
|
0点 |
0点 |
3点 |
6.
総括
1..各担当毎の総括
エレクトロニクス(山田裕介)
当初は扱うセンサ類の数が多かったためにFPGAボードへの入力数を減らすための専用処理ボードを作成する予定だったがプロジェクトが進行するにつれて扱うセンサ類の数自体が減っていき、お蔵入りになった。アームの回路自体は単純な回路だったためか回路自体は問題なく動いた。FPGA部の回路もMPC部の流用で十分稼動が可能であったためにFPGA部に多くの修正が必要にならなかった。ただ回路の設置スペースの問題やアームの先端にタッチセンサが必要になる構造であったため、長い導線が必要になりこの導線が絡んでしまうことがあり整理することが必要になってしまった。もうすこし速い段階で導線に配慮した構造にするようにメカニクスと話し合う必要があったと思った。 全体としてセンサ類の不良が多かったことと他のソフトウェアのグループとメカニクスのグループとの足並みがあまり良くなかったために無駄な作業が多かったように思える。
メカニクス（後藤俊介）
MIRS0501班の特色として、ポストを獲得するためのアーム機構と、今年から新しくルールに追加された
ポスト表面上の黒い線を読み取るためのポスト番号識別機構を取り付けたということがあげられます。 両方とも前例がないので何もかもが手探りでした。新しく何かを作ろうとするのはとても大変なことだ
ということを学びました。アーム機構を作る上でもっとも大変だったのが設計でした。「どのような機構でアームを出すか」とい う問題に始まり、MIRSの狭いスペースに収めなくてはいけなく、アームを25cmは出してほしいという注
文など設計はとても時間がかかりました。こんな設計で自分が本当に作れるのかと何度も設計をやり直 したりもしました。たくさん悩んだり、時には先生に相談をしたりして、アーム機構は作ることが出来
ました。製造で難しかったのが、ステンレスのピニオンギヤにねじ山をほるところでした。ステンレス はとても硬く、また丸くて安定せず加工が困難でした。アーム機構が出来てからはコードの処理に苦労しました。アーム機構は出たり入ったりと大きく動くの
でコードが絡まったり、引っかかってコードが切れたりしました。これにはメカニクス以外の班の人に もアイディアをもらって解決をすることができました。ポスト識別機構は最後まで調整が遅れ、最終的にチーム全体に迷惑をかけてしまった。
ソフトウェア（伊沢）
本番に何が起こるか分からないことを改めて実感する結果となった。工作室内で何回も試して失敗がなかった部分が、本番でミスが起こった。原因を調べたが、処理を行う関数はきちんと動作した証拠であるログを残していたので、原因はわからない。自分の班のＭＩＲＳはセンサを大量に搭載していたのですべてのセンサがきちんと動作するまで時間がかかり、ソフトとエレキの連携がとれるのが時間がかかってしまったことが残念だった。また、プログラムも標準プログラムの解析する時期が夏休みが終わってからだったことも、ＭＩＲＳの製作時間の遅れにつながってしまった。ただ、本番前の練習ではきちんと動作してくれたので、本番ではアピールできなかったが、満足している。
ソフトウェア（木村）
ポスト獲得という競技は、もうマンネリ化していると思われる。新しい競技ルールなどを考えて毎年違うことを行ったほうが、発表会に向けてのマシン製作意欲も湧き、今年もよろしくお願いします。
2.
全体の総括(M 大村啓明)
今年は自由にメンバーを決めることができたのでメカ、エレキ、ソフトそれぞれ得意な人を選べたので良かった。前期は標準MIRSを作成したが、センサ類やロータリーエンコーダの調子が悪く作業時間外にも作業を行うことが多かった。後期も機能を増やしすぎたため思うように動かずバグの多い状態で本番をむかえることになってしまった。一番の問題点はセンサ類を多く取り付けすぎたため、いつでも何かしらのセンサの修理をしていたので思うようにプログラムを作ることができなかったことだ。かなり大変な仕事を任せることも多かったが、班員全員が仕事をしっかりと行ってくれたので非常にやりやすかった。本番で思うような成果は出なかったが、メンバー全員が知識を身につけることができたので良かった。