最終更新：2014.10.6

目次

1. はじめに
   
2. 試験項目
   
3. 試験方法及び合格基準
   
4. 試験結果
   

1. はじめに

本ドキュメントは、デモ競技会完了報告書である。
それぞれの記載場所については、目次の通りである。


2. 競技結果

競技結果はデモ競技会結果のようになった。
競技時の動作は、1,2,3回目共に、DBまでは進んだが、数値認識後に回転せず、そのままDBの方向に突っ込んでしまった。順位こそは3位となることができたが他の班のトラブルや準備不足などによるものである。

3. 開発プロセスの分析

標準機デモ競技用システム開発計画書より、システム開発が計画通りに進んだかをチーム開発面と技術面に分けて記述する。


1. チーム開発面

1. 役割分担

各メンバーの役割は、MIRS1403ドキュメント管理台帳の通りである。ただし、厳密に役割が決められていたわけではない。
競技会本番時、メカ及びエレキ部分での問題は発生しなかった。よって、役割上の問題点は、ソフト部分にあるといえる。しかし、「技術面」に後述するように、ソフト部分は極端にシステム開発時間が短かった為、ソフト担当のみに落ち度があったとは言えない。
また、「技術面」の後述の通り、システム開発が遅れた原因は、機能試験やシステム開発計画書の作成の遅れであるので、メカ、エレキ部分に過大な時間を割いたわけでもない。
よって、システム開発が遅れた主な原因は、個人や役割の部分というより、チーム全体の問題であると考えられる。
チーム全体の問題点は、一部個人の作業量の差が大きかった。そのことにより、チーム内に意識の差が生まれ、チーム本来の能力を失ってしまったことである。

2. 技術面

1. 機能

各機能において、時間の都合により機能の新規作成は行わずに標準プログラムmg3s_std_v2.1.1を流用した。ただし、システム詳細に示すパラメータは調整した。
また、機能番号5番については、実装することができなかった。ただし、機能番号5番については、競技に必ずしも必要ではない為、問題が生じることはなかった。
さらに、機能番号1,2については、競技に要求される精度を実現できなかった。具体的には、安定して直進せず、曲がることが多々あった。
最後に、機能番号3については、返り値が常に「0」になるバグが存在した為、正常に機能しなかった。

標準プログラムについては、MG3S 標準プログラムのバージョンアップ履歴を参照。


2. 開発日程

Table 1に計画での開発日程と実際の開発日程を記載する。


開発日程（計画、実際）

日付	作業内容（予定）	作業内容（実際）	備考
8/6	システム開発 各モジュールのデバッグ	標準機能試験報告書の作成 標準機デモ競技用システム開発計画書の作成
8/7	各モジュールのゲイン調整	標準機能試験報告書の作成 標準機デモ競技用システム開発計画書の作成
8/8	プログラムの最終確認	標準機デモ競技用システム開発計画書の作成 システム開発 各モジュールのデバッグ 各モジュールのゲイン調整	システム開発途中
8/9	最終調整	システム開発 各モジュールのデバッグ 各モジュールのゲイン調整 プログラムの最終確認 最終調整

Table 1より、本来前期末試験終了前に完了している筈であったドキュメントの作成が完了していないことが、システム開発が遅れたことの原因となっていることがわかる。

3. まとめ

開発計画について、達成点及び未達成点を以下にまとめる。


1. 達成点

・機能2, 4, 6
・main関数、ただし、正体補正分の移動を修正する部分を除く。


2. 未達成点

・開発方針
・戦略
・機能1, 3, 5
・main関数の正体補正分の移動を修正する部分を除く。
・開発日程


4. システム詳細

開発したシステムを以下に示す。
なお、機能はサブ関数としてすべて一つのソースファイルに格納した。ファイル名は「orifunc.c」である。また、ヘッダファイルも同様のファイル名である。
main関数
sub関数
ヘッダファイル
Makefile

標準プログラムから変更したパラメータのみを以下に記述する。
・hardware.h
// タイヤ半径 [cm]
#define TIRE_R 5.4

//右タイヤを１とした場合の左タイヤの走行距離補正値
#define TIRE_DIST_RATIO 0.9879
// モータとエンコーダの回転比率 = モータ軸直径/エンコーダプーリ直径
#define M_E_RATIO 0.62500

・motor.h
//不感帯PWM値 L:左、R:右、F:順方向、B:逆方向
#define R_SHIFT_F 95
#define L_SHIFT_F 95
#define R_SHIFT_B 95
#define L_SHIFT_B 95

速度制御(vel_ctrl.c)のパラメータ
// PID 速度制御のゲイン
static float Kp = 2.60 ;
static float Ki = 0.42 ;
static float Kd = 11.0 ;

走行制御(run_ctrl.c)のパラメータ
// PID 速度制御のゲイン
static float Kp_s = 5.0 ;
static float Kd_s = 500.0 ;
static float Kp_r = 2.4;
static float Kf_r = 1.4;
static float Kf_r_org = 0.4;
static float diff_prev = 3.7;
float dist_vel_down = 52;
float angle_vel_down = 30;

数字認識に関するパラメータ
width_min = 50*mag; width_max =80*mag;
height_min = 90*mag; height_max =120*mag;

上記以外は全て標準プログラムの通りである。


5. システム上の問題点及び改善方法

システムに生じていた問題及び改善方法を記述する。

1. シーケンス制御

・問題点
ルール上２つのゴール両方に入ると失格になる為、数値認識に失敗した際のシーケンス制御が正常に行われると失格になる点。

・問題原因
競技ルールの確認不足。
・改善方法
１回ゴールに入った段階でシーケンスを終えるようプログラムを変更した。
この問題は、デモ競技会開始時には修正を終えていた。

・問題点
システム開発計画書のフローチャートの�@の最初の部分の制御である「正体補正での移動を戻す」を実装できなかった点。
・問題原因
システム開発の時間不足。
・改善方法
正体補正時に機体の角度しか変化しないようにパラメータを変更した。

この問題は、再評価会開始時には修正を終えていた。


2. 直進走行制御

・問題点
直進時に左右どちらかに曲がった点。
・問題原因
左右のタイヤの回転速度の誤差をプログラムで調整できていなかったこと。
・改善方法
タイヤの回転比及びゲインを調整した。

この問題は、デモ競技会開始時には修正を終えていた。

・問題点
直進開始時及び直進中に、左右両方のタイヤが振動する点。また、振動時に機体が一回止まる点。
・問題原因
微分ゲインが大きすぎる。
・改善方法
微分ゲインを減少させる。

この問題は、修正を終えていない。
・問題点
上記の問題点により、ロータリーエンコーダの測定値と実際の直進距離に誤差が生じる点。
・問題原因
微分ゲインが大きすぎる。
・改善方法
微分ゲインを減少させる。

この問題は、修正を終えていない。


3. 回転走行制御

・問題点
ロータリーエンコーダの測定値と実際の直進距離に誤差が生じることにより指定距離分の回転走行が行われない点。
・問題原因
微分ゲインが大きすぎる為、走行制御時に過度なフィードバックがかかり、ロータリーエンコーダの測定値に誤差が生じること。
・改善方法
微分ゲインを減少させる。

この問題は、修正を終えていない。


4. 数値認識

・問題点
関数の返り値がどのように数値認識させた場合でも「0」に固定される。
・問題原因
機能関数内における数値認識の成功判定に使用していた関数「number_detect(int dist)」は、数値認識自体の成功判定をしているのではなく、カメラによる撮影の成功判定をしていることに気がつかなかった点。また、MG3S 標準プログラム 関数レファレンスより、この場合の返り値は、「１」となる筈である。これは、標準プログラム自体のバグである。
・改善方法
認識した数値を格納する関数「number_get(int nums[2])」は数値を認識できなかった時、「-1」を返す。それを数値認識の成功判定に使用した。

この問題は、再評価会開始時には修正を終えていた。


5. 正体補正

・問題点
明らかに数値認識に失敗している場合でも、正体補正が始まらない点。
・問題原因
数値認識の成功判定にバグがあり、数値認識結果がどのような場合でも認識成功と判定されるので、数値認識失敗時の分岐直下にある正体補正を行う関数が実行されることはない。
・改善方法
数値認識の成功判定のバグを修正する。

この問題は、再評価会開始時には修正を終えていた。


6. 機体停止

・問題点
機能実装が完了しなかった点。
・問題原因
システム開発の時間が不足していたこと。
・改善方法
システム開発の時間が多くなるようにする。あるいは、優先度の低い機能のため、実装を見送る。

この問題は、再評価会開始時には修正を終えていた。


6. その他の問題点及び改善方法

その他の問題及び改善方法を記述する。

1. エレキ

・問題点
バッテリー使用時に機体が再起動を繰り返す。特に、機体が移動しているときは、再起動の頻度が高い。また、起動自体も正常に行われる確率が数十回に1回程度と非常に低い。
・問題原因
バッテリーの接続端子の金属部分が緩んでいた。その結果、接触が甘くなり、接触不良を引き起こした結果、再起動を繰り返した。また、起動も正常に行われにくかった。
・改善方法
バッテリーの接続端子の金属部分を閉め直した。

この問題は、デモ競技会開始時には修正を終えていた。

・問題点
制御系の電源端子にヒューズ付きボードを接続した際、起動が正常に行われる確率が数回に１回程度になる。また、ヒューズ付きボードは、電源から流れる電流を分流し、CPUボードと超音波センサ（親機）に流す機能もある。その為、必ず接続する必要がある。
・問題原因
CPUボードと超音波センサ（親機）の両方に直接接続できるケーブルが不足していたこと。
・改善方法
牛丸教授に必要使用を満たすケーブルを譲っていただいた。

この問題は、デモ競技会開始時には修正を終えていた。

・問題点
前期末試験の終了後、超音波センサの子機が動作しなくなった。
・問題原因
子機のPICが破損していた。原因は、長期間熱のこもった密室に放置していたことによる劣化の為だと考えられる。
・改善方法
部品置き場にあった超音波センサから、同型番のPICを移植した。
PICの型番は、MG3S 標準プログラムのバージョンアップ履歴を参照。

この問題は、デモ競技会開始時には修正を終えていた。


7. 競技時に発生した問題点及び改善方法

競技時に発生した問題点及び改善方法を記述する。
競技時に発生した問題点は、DBの数値認識をした後、そのままDBの方向に直進走行してしまう点である。
プログラムより、通常、直進走行動作が2回連続で行われることはありえない。
問題原因として考えられることは、数値認識機能にバグがあり必ず1回目で認識終了することと、機体の直進速度が60[cm/s]と比較的速かったことから、数値認識から回転走行に移行する際、直進走行時のトルクが減衰仕切れておらず、それにより回転走行が打ち消されたと考えられる。
この問題点の解決方法は、第一に数値計算のバグを修正することである。ただし、正常に数値計算を行った場合でも1回目の認識で成功する可能性は多々ある。よって、第二に直進走行後に、一定時間駆動系に影響が無い処理を加えることも必要な方法である。

8. 再評価会

再評価会について記述する。

1. 概要

再評価会は、9月26日16時30分〜17時30分に行われた、エントリー式の、デモ競技会と同様の競技会である。デモ競技会との相違点は、「競技形式でなく、１チームが続けて、左右のコースを１回づつ走行する」ことである。また、DBの数字は、教員がその都度選択する。

2. 参加者

再評価会は任意参加かつ多忙な時期で開催する為、準備を含めて時間に余裕がある者のみで行った。
参加者は、野澤、伊藤、新谷の3名である。


3. 開発日程

Table 2に再評価会に向けた開発日程を記載する。


開発日程（再評価会）

日付	作業内容	備考
9/24	システムの再確認 システムの修正 各モジュールのデバッグ 各モジュールのゲイン調整
9/26	システムの修正 各モジュールのデバッグ 各モジュールのゲイン調整

4. システム詳細

開発したシステムを以下に示す。
全てデモ競技会時と同様のファイル名である。
main関数
sub関数
ヘッダファイル
Makefile

標準プログラムから変更したパラメータのみを以下に記述する。
・hardware.h
// タイヤ半径 [cm]
#define TIRE_R 5.4

//右タイヤを１とした場合の左タイヤの走行距離補正値
#define TIRE_DIST_RATIO 0.9820
// モータとエンコーダの回転比率 = モータ軸直径/エンコーダプーリ直径
#define M_E_RATIO 0.62500

・motor.h
//不感帯PWM値 L:左、R:右、F:順方向、B:逆方向
#define R_SHIFT_F 95
#define L_SHIFT_F 95
#define R_SHIFT_B 95
#define L_SHIFT_B 95

速度制御(vel_ctrl.c)のパラメータ
// PID 速度制御のゲイン
static float Kp = 26 ;
static float Ki = 0.42 ;
static float Kd = 100 ;

走行制御(run_ctrl.c)のパラメータ
// PID 速度制御のゲイン
static float Kp_s = 5.0 ;
static float Kd_s = 500.0 ;
static float Kp_r = 2.4;
static float Kf_r = 1.4;
static float Kf_r_org = 0.4;
static float diff_prev = 3.7;
float dist_vel_down = 52;
float angle_vel_down = 30;

正体補正(direction.c)のパラメータ
int c_count_max=1; // 正体補正を諦めるまでの回数
int uss_max = 70; //所定距離の最大値[cm]
float str_speed = 0; //距離補正時の速度[cm/s]
//正体補正したと判断する条件
abs(4)

数字認識に関するパラメータ
width_min = 50*mag; width_max =80*mag;
height_min = 90*mag; height_max =120*mag;

上記以外は全て標準プログラムの通りである。

5. システム変更点

1. パラメータ等

直進速度及び回転速度を低下させた。
具体的には、直進速度は60→35、回転速度30→20にして、期待の動作を安定させた。また、標準機デモ競技用システム開発計画書の戦略を無視してまで速度低下に踏み切った理由は、対戦形式ではない為、勝敗が無いからである。
また、速度制御の比例ゲインを10倍、微分ゲイン約100倍の値にした。
これら2点により、直進走行の安定性が大幅に増加した。しかし、過剰な微分ゲインにより、フィードバックが必要以上にかかり、機体に動作命令を出してから、実際に動作するまでの時間が大幅に増加した。


2. シーケンス制御

数値認識に失敗した時の部分の記述を変更した。
具体的には、goto文及びif-else文をswitch-case文に変更して、プログラムの可読性を高めた。


3. 数値認識

返り値が常に「0」になるバグを修正した。
その結果、機能の本来の仕様に加えて、数値認識に失敗した際に「-1」を返す機能を追加した。


6. システム上の問題点及び改善方法

システムに生じていた問題及び改善方法を記述する。

1. 直進走行制御

・問題点
直進開始時及び直進中に、左右両方のタイヤが高速振動する点。また、直進中にタイヤが振動した場合、機体が進まなくなる場合がある点。
・問題原因
微分ゲインが大きすぎる。
特に、速度制御の微分ゲインが過大である。
・改善方法
微分ゲインを減少させる。
特に、速度制御の微分ゲインを減少させる。

この問題は、修正を終えていない。


2. 回転走行制御

・問題点
ロータリーエンコーダの測定値と実際の直進距離に誤差が生じることにより指定距離分の回転走行が行われない点。
・問題原因
微分ゲインが大きすぎる為、走行制御時に過度なフィードバックがかかり、ロータリーエンコーダの測定値に誤差が生じること。
・改善方法
微分ゲインを減少させる。

この問題は、修正を終えていない。


3. 数値認識

・問題点
標準部品試験報告書のカメラの項目より、ほぼ確実に数値認識が可能である場所での数値認識が失敗する。また、同地点で、MG3S 標準プログラムを用いたい単体テストの「test_numebr」を行った結果正常に数値認識をした。
・問題原因
数値認識には、DBとの距離を引数として使用する。引数に、初期位置からDBまでの距離と直進距離の差分をとっている。ここで、前述の通り、不適切な微分ゲインにより、ロータリーエンコーダの測定値の誤差が大きいので、引数に正常な距離が入らず数値認識に失敗する。
・改善方法
直進走行を安定させ、ロータリーエンコーダの測定値の誤差を減少させる。

この問題は、修正を終えていない。


7. 競技結果

左右のコースごとに記述する。
・左コース
DBまで直進した後、数値認識を開始したが失敗した。その後、正体補正をし、再度数値認識を行ったが失敗し、無限ループに陥って終了した。
また、無限ループ時に少し動かしてみると、端末の画面にDBの数値が出力された。これは、数値認識に使用する引数の誤差が大きく、動かした際に適正な距離になり数値認識を行えたからだと考えられる。
・右コース
最初の直進で、1.5[m]程進んだ時に機体が進まなくなり、リスタートをした。しかし、同様の症状に陥り、終了した。
また、最初と期待が進まなくなった位置では左右両方のタイヤが小刻みに振動していた。


8. 競技時に発生した問題点及び改善方法

左右のコースごとに記述する。
・左コース
ここでの問題点は、無限ループである。
数値認識に失敗した原因は、前述の通りである。
無限ループに入った原因は、プログラムである。プログラムの最初のswitch-case文の部分において数値認識に失敗し、かつ正体補正に成功した場合を想定すると無限ループに陥ることがわかる。
この問題点の解決方法は、第一に数値認識を正常に行えるようにすること、第二にループ中にカウンタを設置にループを一定回数行ったら、ループを抜ける処理を追加することである。
・右コース
ここでの問題点は、機体が進まなくなったことである。
そもそも、最初に機体が進むようになるまでに時間がかかる原因は、速度制御の微分ゲインが過大であるからである。PID制御の微分項を離散的に考えてみると、微分項は、現在の周期における偏差と1個前の周期における偏差の差分に微分ゲインをかけた項である。よって、機体がほとんど動いていないときは、偏差も小さくなり、周期の変化による偏差の変動もほとんど無いので、微分項はほとんど働かない。しかし、微分ゲインが非常に大きいと、微分項の働きが強くなり、本来ほとんど作用しない箇所でも影響が生じる。その結果、左右のタイヤが小刻みに振動するような動作となる。フィードバックの結果、偏差が小さくなるので最終的には機体が進まなくなってしまう。
この問題点の解決方法は、速度制御の微分ゲインを小さくすることである。


9. 後期に向けた教訓

デモ競技会及び再評価会に向けたシステム開発での問題点の全てに共通していることは、制御対象に対する理解の不足である。
ゲインの調整ミスによりシステムが要求通りに動作しなかったことは上記の典型的な例であるし、機能関数の動作を把握、理解していれば、今回のような数値認識のバグの発生はありえない。
システム開発以外の問題点も物の特性を理解し適切に扱うことを怠ったという点では同意である。
後期では、制御対象を深く理解し、決して短絡的な制御を行わないよう強く心がける。


10. 各人の反省点、後期に向けた改善予定及び所感

1. 野澤

・反省点
リーダーとしての反省点は、不適切な行動及び班員への指示を幾度となくしてしまい、班に甚大な不利益を生じさせたことである。
ソフトウェア担当者としての反省点は、不適切な理解のままシステム開発をしてしまったことである。
・後期に向けた改善点
リーダーとして大きな行動する際は、必ずマネージャーを初めとした班員に意見、協力を仰ぎ、独断で判断を行わないようにする。
システム開発をする際は、制御対象を適切に理解した上で行う。また、開発結果をソフトウェア担当を初めとした班員に確認をしてもらう。
・所感
自分自身の能力の不足をあらゆる場面で痛感した。後期では、できる限り能力不足を補うようにする。


2. 大塚

・反省点
ソフト担当という肩書きですが、まったくもって力になれませんでした。 努力が足りなかった所があると思われます。
又、作業もダラダラやってしまい、無駄に作業時間を延ばしてしまったのは大きな反省点であります。
・後期に向けた改善点
がんばります ・所感
ソフトという肩書きではありますが、エレキ、メカ関係の作業を行っているのが多かった気がします。個人的な適正としてもエレキのほうが向いていると感じました。

3. 五十棲

前期の活動は主に標準機の組み立てだったので、新たに作るものは少なかったですが、バンパーや、数種類のケーブルを作る必要があったので、そちらの方には力を入れました。全体的にあまり効率的でなく、ダラダラとした時間が多かったように思うので、後期の作業は集中して、また自分の仕事を明確にして取り組むようにしたいです。


4. 古儀

・反省点
前期、私は機械班だった。しかし、機会班の役割はバンパーしかなく、結果的に半田付けをやっていたのはいいが、作業の受け渡しなどで少し遅れた。後、作業時間がほかより短い。
・後期に向けた改善点
後期は本試合に向けてルールも決まりオリジナルの期待を作る。後期こそ機械の本領を生かしてユニークでアイデアがあふれる機体を設計したい。とりあえず、あの使いにくい上、重いシャーシを再設計したい。後、タイヤも作り直す。
・所感
ハンダ付け大変だった。後、夜遅くまで作業していた。プログラム班に申し訳ないと思った。


5. 新谷

・反省点
単体機能試験までは班に貢献することができていたが、デモ競技会に向けてのプログラムの作成は任せてしまい作業の手伝いしかできていなかったのが心残りである。
・後期に向けた改善点
前期はサポートをしていく場面が多かったが、後期は自分で何をどうしたいのかを考え積極的に活動していきたい。またそれに関する知識を身につけて班に貢献していきたい。
・所感
　テスト明け最初のMIRSの起動が何度やっても失敗したときには、FPGAボードを壊してしまった時のようなドキドキするような感覚が蘇り3班のデモ競技会は終わってしまうかと本気で思った。そのことのい原因は大したことではなかったがこれにとられていた時間は直前ということもあり本当にもったいなかったと思う。
　競技会前日は気づけば3班のほとんどが学校で夜を明かしていた。これはこれでいい思い出になるのかもしれない。
　デモ競技会当日には中学生にMIRSの説明をしたり、競技会を見てもらうように案内する仕事などがあったが中学生に話しかける勇気がなく全然うまくいかなかった。また競技会中にMIRSの3班のMIRSの説明を突然振られてうまく説明できたのかはわからないが、コミュニケーション能力は大事であるというのも感じた。


6. 伊藤

・反省点
ソフト担当であったが、MIRSのソフトの理解を深めることができなかった。
・後期に向けた改善点
前期はなれないのもあって作業に時間がかかってしまったし、ミスもした。後期は効率よく的確に作業を進めたい。
・所感
後期はソフトも各班いろいろアレンジが加わっていくので、自分でやりたいことができるように理解を深めたい。


7. 部谷

・反省点
計画通りにあまり進めることができなかった。 それは、ミーティングの際にこの先起きそうな問題についての対策というか、 その場合の対処法などが話されていなかったためであると思う。
・後期に向けた改善点
ミーティングでの意見交換を重視すること。 話し合いや意見交換をすること
・所感
後期からはオリジナル製作を行っていくので、まず基本をしっかりしてから、 徐々に自分たちのオリジナル要素を加えていきたい。


8. 掘水

・反省点
ソフトやメカを手伝うことが少なかった。エレキとしてケーブルや基盤作成を中心に行っていたが、もう少しほかの分野にも関わったほうが良かった。機能試験も無駄に時間がかかった。
・後期に向けた改善点
ソフト、メカの担当と休み時間などに仕事や進行具合を聞いておく。また、あらかじめ試験内容を詳しく決めておく。
・所感
基盤やケーブルなど、接触ミス、配線ミス、でMIRSが止まらないよう留意して作業します。


---

MIRS1403ドキュメント管理台帳