†まず、要求・リスク分析の結果を図に示す。ユースケース図を採用した。ユースケース図(UML2.0)とは、システムがどのような機能を提供するかを示す図で、今回提供する機能を具体化するのに適切だと判断したため、ユースケース図を利用した。今回のユースケース図はUML2.0に準拠し記述する。それに加えて、ミスユースケースというものも記述した。これはシステムに対する脅威を示したもので、今回は赤色のものがミスユースケースとなっている。右側のアクターがその脅威の原因を示したものである。Languageの略称。2.0はそのバージョン。いうユースケース(機能)があると考えた。ここから細分化していき、実装すべき機能はなにかを探っていく。「紙コップを運ぶ」という3つのユースケースから成り立っていると考えた。「走行する」ユースケースから見ていきたい。「走行する」と言っても、様々な手段がある。次に、「ライン無視走行」これは、NXCで提供されているOnFwd(),Off()などのみで走行するものである。これにはモーターには個体差があり、指定したとおりに動作できないことがある。左右モータを同期して走行することも求められるので、拡張機能とした。次に紙コップを運ぶことについて見ていく。「紙コップを置く」「紙コップをつかむ」「紙コップを検知する」「どの紙コップか判断する」のユースケースで構成されている。これらは、すべて紙コップの位置がずれたりすると、課題の成功にかなり影響するので、それの解決策としてバンパーを設置した。これにより、機体の衝突などにより紙コップの位置がなくなるだろうと考えたからだ。時間帯によって、窓から差し込む光が時間によって変化していくと考えた。それにより、手動で値を設定していてはそれの時間もかかり、不安定なので、光センサ値・閾値キャリブレーションによりそれを防ぐことを考えた。今回キャリブレーションを実装するに至った。図に、番号が振ってあるのは後の説明とユースケースと実現方法のトレーサビリティを確立するためである。光センサで判断するために、紙コップにデザインを施した。光センサは反射してきた明るさを計測するので、青や緑などの色を使っても判断がしづらいと思ったので、白と黒のみでデザインを施すことにした。デザインに求められるのは美しさではなく、光センサで測定した値それぞれに差があるかどうかが一番大切である。デザインによっても検知の性能が左右されるので、手を抜いてはいけないと感じた。光センサで測定したところ、値は約37。光センサで測定したところ、値は約65。†3個目に一番迷ったが、結局この形になった。本来は灰色でやろうと思ったが、黒ペン一本では限界があった。黒線と白を混ぜれば灰色として認識するのではないかという仮説のもと、このデザインにした。光センサで測定したところ、値は約47。この値の差ならば、どの紙コップかを判断するかもスムーズに行えるのではないかと結論づけた。†まず、モータで歯車を動かす(1)。これにより、アームが閉じる(2)続いて、更にモータに力を加え、紙コップをつかむ。力を加えると、閉じる方向に力は行かず、真上にいくので持ち上がるという仕組みだ。これがコップの位置ずれを防ぐために設置されたバンパーである(ユースケース図�参照)。機体は一度ダイエットをし、非常に軽量化された。ダイエットを行ったかというと、重心が機体上部にあり、カーブすると転倒してしまうことが多々あったからである。今回私は独自にプログラムの作成を行っていた。関数を作り、できるだけ操作を部品化しようと試みた。作戦変更により、使わなくなったので、このプログラムは実際には利用しなかった。他のメンバーのページを見ていただければ、実際に使ったプログラムについての説明を閲覧することが出来る。†m_がついてるものはグローバル変数とした。それ以外はローカル変数とするようにした。することにより、値の代入ミスなどを防ぐことが出来ると考えたからだ。//境界値(閾値)は黒値と白値の平均値とするまず、タッチセンサが押されてる間,その場所の光センサの値を蓄積する。蓄積している間、何度蓄積したかをカウントする。その蓄積した値を蓄積した回数で割る。それがその場所の光センサの値となる。これを、白の場所、黒ラインの場所両方で行う。その後、m_borderにその平均値を代入する。これがライン閾値となる。これによりキャリブレーションを実現した。speed;}OnFwd(OUT_B,speedL);OnFwd(OUT_C,speedR);まず、この関数はPD制御によって動いている。I制御を入れると、さらに綺麗にライントレース出来るのだが、PDだけでも綺麗にライントレース出来るので、今回はこれで行った。簡単に説明をすると、P制御とは、目標の値に近づけるために、制御量に応じて操作量を増やすような制御のこと。D制御とは、その操作を行う反応速度のことである。SENSOR_3){OnFwd(OUT_B,speed);Off(OUT_C);}else{OnFwd(OUT_C,speed);Off(OUT_B);}Wait(2);ON/OFF制御によって実現されている。センサの値のほうが閾値よりも大きかったら右、そうでなかったら、左というように実装されている。OnFwdSync(port,speed,0~100);//�左右モータを同期させるなどの元から提供されているAPIを利用して走行をする。直にモーターに命令して走行する。†OnRev(OUT_A,75);Wait(1000);モータ逆回転で一定の時間回す必要がある。この値は適宜調整が必要なので、成功率にばらつきが出てしまうことが考えられる。それも今後の課題としておきたい。OnFwd(OUT_A,75);Wait(1000);置くのと同様である。置くのとは逆回転で実装されている。true;}検知したいコップの明るさ数値を関数に渡して、それが検知されたらtrueを返すといったもの。値を入力して渡す必要があるので、使用する際非常に面倒なのが欠点。関数内でキャストをすべきだとのちになって感じた。検知の感度が悪かった。これは、前回の交差点検知と同様に、なんど検知したかをカウントして、その値をもとに検知するという方が精度が高くなっただろうとのちになって感じた。2;}それぞれの値に応じて1,2,3の値を返して判断を行う。これも先ほどのコップ検知ど同様に、精度が低かった。何度検知したかをカウントし、それに応じて判断するといった仕組みのほうが精度は高くなった可能性がある。今回、私はプログラムをより組みやすいように心がけた。作戦変更により使われなく鳴ってしまったのは残念だった。機体が変更にあっても作戦が変更されてもプログラムが使えるようにする必要があると感じた。部品化したのはいいが、サブルーチンを一切作らず組んでしまったので、main()内のプログラムが非常に煩雑になり、わかりにくくなってしまった。部品化するだけではなく、見やすいようにするのも大切だと感じた。今回、期末試験と時間がかぶり、集まれる時間が取れなかった。実家に帰らなければいけない予定があったため、最終調整に行くことが出来ず、非常に残念であった。調整が出来ないことも多々あったし、自分の作業が雑になってしまったというのも多々見られた。今後はこのようなことが無いように、計画を立て、十分が時間をとれるようにすべきだと感じた。