連日ご指導くださっているまつぞのさんに、新設したUMLモデル検討用BBSで具体的なクラス図のまとめ方を示していただいたので、それを参考にして分析クラス図をまとめなおしてみた。
壁検知部を新しく追加したのに伴い、基本機能テストに「壁パターン検知テスト」を追加した。なので、基本機能テストの状態遷移図も更新。
とりあえずここまでで分析は終わりにして設計クラスに落とし込み、基本機能テスト関連の下層のクラスから実装、テストに入っていくつもり。
いつものことだが、「9月中に基本機能テストの実装まで片付けたい」といっておきながら、実際にはコーディングにすら入っていないのが現状。こんな調子じゃ、中部地区大会に間に合わなくなりそう。
体のあちこちが筋肉痛になりながら、お昼頃から夕方まで、まったりと半日FFモード。おそれていたことが始まっている感じ。ゲームが始まってしまうと「自主規制で＊＊時まで」とかいうのが意味をなさなくなってしまう。ここはひとつ、マイクロマウスがある程度の形になるまで、PS2に封印のお札でも張るしかない。
先月〜今月と間食規制を一時撤廃していたせいか、体重（と体脂肪率）が危険ゾーンに突入。ストレスがかかる時期は忙しくて運動もしなくなるし、ストレス開放に間食をすることもあるので、どうしても肥える傾向がある。やっとストレスのほとんど無い時期に差し掛かったので、間食制限、食事のバランス見直し、定期的な運動を組み合わせて、ちっと締めよう。
久しぶりの心安らかな休日。午前中にマウスのモデリングを少しだけやってからFF-XIの世界に突入。午後は3時くらいから、今日お誘いをもらった剣道の稽古会の場所を確認するために、ドライブがてら下見に。
夜は若手が集まった稽古会。中学生、高校生とも稽古してみて、いろいろと気づかされた。稽古会の後は飲み会。半分は東レ剣道部の方なのかな？ロボットばかり作ってないで、剣道の試合に出たり、四段を目指したりするのもいいかなぁと思った。
ロボットのことはほとんど進まなかったが、充実した一日だった。
先週末の連休から今日までに作成した分析クラス図を公開。
最速走行の分析をあまりやっていないので、最速走行関連のクラス図はまだスカスカ。クラス図はあまり厳密さを追求せず、ザックリ描くのがコツだということを感じた。
国連総会で日本と北朝鮮が真っ向からやり合っているらしい。水面下の駆け引きではなく、各国の代表の面前で堂々と述べるのは、国際社会で通用しないような主張は相手にされないので、大いに評価できるところ。
本日は給料日。諸引去り額と時間外手当（残業代）がほぼ同じ。引去り額のトップ５は、厚生年金保険料、生命保険、所得税、健康保険料、住民税の順。トップ５はいずれも１万円を超えている。年金制度、どうなるのか心配だ。
いつもはあさ８：００に起きようと思って８：３０ごろ起きているのに、今日は出張なので6：30起床。帰ってからは剣道。足の裏に肉刺ができた。素人じゃあるまいし。
剣道から帰って一風呂浴びて、「UC１：基本機能テスト」の分析モデル作りを始めたのだが、もー眠くなっているのに気づいて、今日はこれでおしまい。
4連休最終日。シミュレータにて、第1回〜21回の迷路（エキスパートクラス決勝）を走破できた。これで、リスクがひとつ解決。
今日は何を思ったか、昨年12月末に封印していたPlay Station 2 のFF-XI に手を出してしまった。その結果、最初は3時間だけのつもりが、6時間弱のプレイになってしまった。私をFF-XIの世界に誘った人々は未だ健在。パーティも組めたし、そこそこ楽しかった。でも、ゲーム中の4割はチャット大会だったような（笑）
それにしても、FF-XIはロボットを作る時間を大量に奪ってしまう、ひじょーに危険な香がする。再び封印するかどうかしないと、また昨年のように、何の生産性も無い時間の過ごし方をしてしまいそうで怖い。
てことで。午後からはFF-XIに興じたせいでソフト開発進展なし。明日は朝から出張なので、深夜の作業は厳禁。
台風が通り過ぎてから肌寒い。裸足に半ズボンはやめて、靴下と長ズボンになった。
シェアウエアの送金を済ませて機能制限の解除キーをもらったので、先日作った探索アルゴリズムで16×16区画に挑戦した。その結果、まだアルゴリズムの詰めが甘いことがわかった。
機能制限を解除したシミュレータは、フルサイズで過去の大会の迷路を走行することができて、探索ロジックの確認にはとっても便利。先日5×5区画のサンプル迷路をクリアした探索アルゴリズムで16×16区画に挑戦してみたら、進行方向の選択を間違えて同じ場所を行ったり来たりしていたり、全然壁じゃないところを壁だと認識していたり。ちょちょいと手直ししたところ、いくつかの迷路はクリアできるが、いくつかの迷路はクリアできない、という状況になっている。クリアできない原因は、察しはついているのだが、対策がまだ。
今日改めて思ったこと。シミュレータによるアルゴリズムの検証は必須の作業。｢実機を走らせながらデバッグすればいいぢゃん？」なんてことをすると、アルゴリズムが悪いのか、走行制御部分にミスがあるのか、スリップ等の物理的な要因によるものなのか、上手く走らない原因の特定が難しくなる。シミュレータを活用して、探索アルゴリズムを固めるべし。
朝から連休中の詳細スケジュールを作成して、マウスのソフト開発に勤しむ。午後8時の段階ではおおむねスケジュールどおり。現在、「UC1：基本機能をテストする」のユースケース分析で、分析クラス図を作りながら、1ヶ月くらい前に悩んでいたこと（8月27日の日報参照）に再度でくわして、作業停止中。
システムコントローラの構造をどうするか？ 各モードをStateパターンであらわすか、集約であらわすか。とりあえず、両方とも図にしてみた。
先月と同じことの繰り返しになるが、「コントローラ」＝「ユースケースを駆動する責務を負うもの」と考えれば、各モードにコントローラを用意するのが妥当なような。でも、なんかボタンSWとメニューとLCDのあり方が、これでいいのか？って感じ。一方、同じボタン操作でも状態が違えばマウスの振る舞いが変わるわけで、その意味ではStateパターンなような。
先月同じことを日報に書いたときにBBSでアドバイスをいただいた。それをもとに考えを整理すると、
ということで、この日報を書きながらStateパターンがいいかな、というほうに傾きつつあります。
台風が近づいているらしい。近くの小学校では朝から運動会だったが、お昼前から雨が降り始めて運動会は途中で打ち切りになったようだ。
今日の作業。スケジュールの詳細化と、BasicMouseのI/Oポートと関連レジスタの資料整理。今月中に、距離センサ動作テスト、モータ動作テスト、姿勢制御テストまで片付けてしまいたい。来週末もあるけれど、連休3日間でどこまでできるかが勝負の分かれ目。
仕事のほうはなんとか今期の成果を確保できた。特許のノルマはまだクリアしてないけど。おかげで、今日は22：00前には退社できて、明日から23日まで4連休。 なんか、夏休みがもう一度きたような気分。 余計な残業・休出はもはや不要。 ＜ 年休消化しなきゃ
この連休を利用してマウスプロジェクトを推し進めてしまおうと画策中。今日は大会までのマイルストーンや詳細スケジュールを検討。欲張りになっているせいなのか、作業量から考えるとどう見積もっても間に合わない計算。そんなときこそ、どうしたら間に合うか、作業手順や中間成果物の見直しを行う時期かもしれない。
調整用迷路の問い合わせに対する返答は今日もなし。しゃーない、自作するか？
昨日、仕事のほうは順調と思っていたら、今日はBIG TROUBLE！ その対処に一日使ってしまって、いまだに原因不明。この手の原因不明なトラブルって、人前でデモするときに限って再発したりするので、すごーく怖い。残業時間の上限のことをプロジェクトリーダに話したら、＋20時間の増枠申請をしてもらっちゃって・・・いや、そういうつもりじゃなかったんだけどなぁ（汗） ＜ これで今月は80時間まで残業OK
シミュレータ上で行っている、マイクロマウスの迷路探索アルゴリズムの検証。 今日の段階で、もう５×５区画のサンプル迷路をクリアできた。アルゴリズム自体はろくに設計もせず、行き当たりばったりで書いたわけだが、大して複雑なものではないので簡単にできてしまった。
簡単に、とは言ったけれど、引っかかったところが何箇所かあるので、反省がてら振り返っておく。
まだ16×16区画では試していないので、シェアウエア料金をはらって挑戦してみる予定。
調整用迷路の問い合わせに対する返答は、今日もなし。フォローしてみようかな？
オブジェクト指向開発関連の話は、新しいことを沢山一度にやろうとしているせいで、お腹いっぱいの消化不良状態。全部一度にはできないのは当たり前。初歩的なことから、一つ一つ順番に片付けていきましょ〜。
土曜日と月曜日と休出した甲斐あってか、今日は仕事のほうはバッチリいいところまでいった。この調子なら、今週中に今期の成果が確保できそう。そういうわけで、今日は気分良く22：15退社。おお、いつもより早い♪
帰ってからは、何も作業しないと不安になるので、それを紛らわすために迷路の探索アルゴリズムをシミュレータに組み込んでみた。もちろん、これまで行ってきた分析の結果を注ぎ込んで。午前3：00を回ったので作業を中断したが、あと３〜４時間あれば、探索アルゴリズムができちゃいそうな感じ。
調整用迷路の件は、マイクロマウス委員会に先週末メールを出して問い合わせをしているが、今日はまだ返答なし。
今月の残業時間がすでに上限の8割以上いっているので、今月はもう休出不可。場合によっては、平日深夜の残業も不可かも？ 年休消化もしなきゃならないところだし、月末にまとめて休みを取って、マイクロマウスのプログラム書こうかな。
気ばかりあせって、何も進んでいないような気がする。中間成果物として何がいつまでに上がるべきなのかが良く分かっていないため、詳細スケジュールも立っていない。あまり成果物にこだわらず、大まかな設計だけでコーディングに入ってしまおうという考えも無きにしも非ず。でも、それだと今までと何も変わらないのかなぁ。なんかもう、禁断症状というか、シミュレータ上でのアルゴリズム検証だけでもやってしまいたい気分。
日報には今年のマイクロマウスのソフト開発がスタートしていることをすでに書いているが、それらをまとめたものが無かったので、ちょっとだけまとめてみた。 どのプロジェクトも、完成に至らず中途半端な状態でとまっているのが、すご〜〜〜〜く心苦しい。 今は目の前のマウスに集中して、完成まで持っていくしか道は無い。 ＜ 過去のをざっくり切り捨てるという手はある？
先日の日報では作業見積もりとスケジューリングの甘さを痛感したことについて述べた。その日から、要求仕様書の作り直しを始め、今日は概略スケジュールとマイルストーンの設定のところまでたどり着いた。そして、また新たなるリスクに気が付いた。それは、「試走するための（十分な広さを持った）迷路が（私の手元に）無い」ということだ。
探索アルゴリズムのロジックだけなら、シミュレータで検証すればいい。しかし、センサの値に基づく制御の確認や、探索の実走行は、実物の迷路がないと検証できない。森永さんのマイクロマウス初心者講座で作った3×3の迷路はあるが、姿勢制御の確認はできても、迷路の探索をするには狭すぎる。
リスク対策として思いついたのは、（１）調整用迷路を購入する。（２）自作する。（３）迷路を持っている人のところに行って練習させてもらう。の3通り。できれば（１）の案がベストだが、どこかのBBSでなかなか手に入らないようなうわさを聞いた覚えがあるのでちょっと心配。マイクロマウス委員会に納期の確認が必要。 （２）の案は、自作は可能だが、たとえ４×６区画でもおよそたたみ１畳分くらいにはなるわけで、置き場の問題がある。（これは（１）案とて同じこと。）（１）案が駄目なときのバックアップ案ということで。（３）案はいろいろアドバイスをもらえるという意味では、調整とは別に採用してもいいかもしれない。
てことで。まずはマイクロマウス委員会に問い合わせ、だめなら迷路を自作。肩こり実感、明日も土曜出勤予定。
今日は残業時間中に、あくびが出るときに耳に感じるような、あんな間隔が頻繁に訪れた。それで、これはもしかして体が疲れているのかもしれないと思い、22時ちょっとには残業を終わりにして、帰ってさっさと寝た。
ここのところ、22時前に帰るのは水曜日だけだし土曜日出勤はあたりまえという日が続いているのに、帰ってからもマウスとかロボット作りの作業をしているものだから、ちと体が警告を発するようになったのかもしれない。先日の健康診断ではな〜〜〜んとも無かったけど。スケジュールを立てるときは、体力回復もスケジュールに入れたほうがいいかもしれない。
定時退社日。剣道サボって、昨日作成した作業計画の中で最もリスクが高い部類に入る探索走行の対策として、マイクロマウスシミュレータで迷路探索アルゴリズムを検証することにした。
DLしたファイルを展開して、VC版のサンプルソースを見て、使い方を把握。早速探索アルゴリズムをコーディング・・・するのは悪い癖なので、「UC２ マウスは迷路を探索走行する」というユースケースの分析とアクティビティの検討、関連するクラスの洗い出し、コラボレーションなどを考えてみた。
| SCD2 | 探索走行の状態遷移図（システムの振る舞い）：既出 |
| ACD2 | 探索走行のアクティビティ図 |
| CD2 | 探索走行に関わる分析クラス図 |
| CLD2-1 | 等高線マップ法による探索走行のコラボレーション図 |
モデリングのポイントは以下のとおり。
探索アルゴリズムには、等高線マップ法を採用することにした。UC1から分析に着手するといっておきながら、シミュレータで探索アルゴリズムを検証する必要性から、UC2の探索走行を先に分析することになった。
あとは、耳が痛い話。昨日、今後の作業見積もりとスケジューリングを行ったつもりでいた。しかし、これじゃ全然スケジュールになっていないことが判明。ここ（http://village.infoweb.ne.jp/~fwgf2942/process/Proc.Schedul.html）を読んで愕然としてしまった。スケジューリングやりなおしです。実戦を通した継続的なトレーニングによって見積もり能力、スケジュール管理能力の向上を図りましょう。
連日BBSでご指導いただいているのを加速剤として、マウス制御ソフトの設計や来年2月のROBO-ONEまでのスケジュール作成を進めている。
で、スケジュール。作業見積もりと来年2月までのスケジュールをざっくり立ててみたのだが、あらま、これじゃあ9月中は寝る時間がなくなっちゃうぢゃあないですか。 作業計画の中で重要度、リスクともに高いものをあげてみると、マウスでは「探索走行の分析、設計、実装」、要素技術実験では「マルチCPU間通信」、ヒューマノイドでは「歩行制御方法検討」と「ヒューマノイドシステムの分析、設計、実装」となっている。 マウスの全国大会（11月２２，２３）が終わってからROBO-ONEまで2ヶ月（予想）というのがつらい。
スケジュールを立ててもスケジュールどおりに行かない、というのはみんなが思っていること。夏休みの宿題でも、仕事でも。見積もり能力を養うにはどうしたら良いか？ ということで、XP (eXtream Programing) の本で紹介されていた、タスクカードを使ってみるのも、面白いかなと思った。 （仕事ではプロジェクトチーム内でXPのプラクティスの導入をよびかけたけど、さらっと流された（泣））
そんなわけで、仕事の質と体調を保つための睡眠時間の確保と、ロボット製作の作業時間のバランスを取るのが目下の課題か。
PS： モデリングの議論をするのに画像を貼り付けられるBBSがあると便利だということで、導入を検討中です。
PICを使って通信しながらRCサーボを制御する件。ようやく決着がついた。日報の題名にある「割り込みではフラグを立てるだけ」という設計方針を重視してプログラムを改良した結果、PC上のVBプログラムからボーレート19200bpsで4ch分の角度データを送り、PICで受信して4つのモータを同時に制御することに成功した。ビビリとかは一切無し。満足、満足。 これならきっと、ノンオーバーラップで6〜8ｃｈまで同時制御ができるはず。
プログラムをいろいろいじったせいで、他人に見せるのには忍びない汚さになっている。スケジューラの部分を設計しなおして、見せられる形になったら公開する予定。
とりあえず。
日報の題名にマイクロマウスと書いておきながらPICの話題。4月ごろからずっと取れなかったプログラムのバグ。PIC16F876AでRCサーボを制御するプログラムで、特定の出力角度の範囲で割り込みのタイミングがずれてサーボの出力がビビッてしまうというもの。ついに原因発見かもしれません。確かにそれじゃあほんのちょっとだけ割り込みのタイミングがずれる可能性があります。
この問題となっていたプログラムの基本構造は以下のとおり。
問題となっている「特定の出力角度」は、サーボの制御周期を20msに設定した場合はおよそ43〜46°くらいの範囲。制御信号を High にする時間でいえば、ニュートラルポジションを1500usにした場合でおよそ 1890〜1920us。シミュレータで動作の確認をしてみたところ、timer1の割り込みタイミングは設定値より9usほど遅れている模様。 timer1のオーバーフロー割り込みのタイミングとtimer0の割り込みのタイミングが近くなるほど割り込みのタイミングがずれやすくなり、それが出力信号幅の変動につながる、というのが私の推測。
そこで、スケジューラとして使用しているtimer0割り込みの処理内容をmain関数の無限ループ内に移動して、timer0割り込みの中ではフラグを立てるだけに変更。その結果、サーボが出力可能な全範囲でビビりが発生しないことを確認した。モータが4つでの話。ただし、通信割り込みの部分ではまだ割り込みハンドラの中に処理を書いているので、PCから連続データを送るとモータがビビる。これを片付けて問題解決となる予定。
確かに会社の先輩には、「割り込みはフラグを立てるだけ。中で処理はしない。」と言われている。一方で、（目にしているソースコードの数はごく少数だが）割り込みの中で軽く処理をいれているプログラムの例はそこそこあるような気がする。今回は先輩の言にしたがったら上手くいったわけだが、な〜んか釈然としないというか、なんというか。
で、ちょっとイイワケ。いつものことですが、日報は自分で理解、発見、学習したことを覚え書きのために書いているので、あまり他人に説明するような書き方をしていません。同じような問題で悩んでいる方から質問があれば他人が理解できるように説明を書くかもしれませんが、そうでない限りは単なる殴り書きで済ませます。わかりづらかったらごめんなさい。
先日、そろそろクラス図作成に移るとかいっておきながら、まだユースケース分析をしている。とりあえず、ユースケース図はこれでFix。ユースケースには書かないシステムの内部動作のうち、基本機能テストと探索走行についてを状態遷移図で表現してみた。
クラス図は、複雑になってしまって巧く描けていない。どうやったらシンプルにまとまるのだろうか？ やぱ、経験？
睡眠時間の確保も大切だとか言っておきながら、今日も会社から帰ってきたらシコシコPICのプログラミング。
昨日思いついた、timer0の割り込み周期を2msにする案も実験してみたら結局ダメだった。なぜ駄目なのかがわからない、というのが一番困る。原因さえはっきりすれば、対策方法だって思いつくだろうに。しかし、世の中には1個のPICで制御信号のON時間のオーバーラップ無しで４〜６個、オーバーラップありで16個のRCサーボを同時に制御している人もいるので、できないのは私の技量が足りないからとしか言いようが無い。自分の技量でできないのなら、他人のやり方を真似てみるってのも手かな。
明日はH8/3664Fで試しみよ〜っと。＜回路作らなきゃね
仕事の上では、そろそろ期末なので特許のノルマがあったり、いつ頃統合デバッグ終わるの？って聞かれたり。プロジェクト解散の危機かとおもえば、社外から声がかかってデモってるので、まだ先はあるのかなぁと思ったり。
そんなこんなで、今は仕事のほうにパワーを100％注ぎ込まなきゃいけない状態なわけで。なのに、会社から帰ってきたらPICのプログラミングとか、マウスの分析・設計とか、メカ設計とかやってて睡眠時間削ってていいんでしょうか？少なくとも仕事に影響が出ないよう、睡眠時間の確保と体調管理はしっかりしましょう。
そういいながらも。ちょっと気になっているPICによるRCサーボ制御。昨日、これまでとやり方を変えて、RCサーボの信号線につながっている複数のポートを15ms周期で同時にHighにして、各サーボの信号のHigh時間をソートして差分でLowに落としていくやり方をためした。しかし、特定の範囲でtimer1のオーバーフロー割り込みがかかる時間がずれており、以前のやり方と同じようにサーボが振動してしまう現象が発生。原因はいまだ不明。原因を突き止めないまま違うやり方をしても、結局は同じ不具合が発生するっていう見本になってしまった。
試してみたいことはいろいろあるけど、睡眠時間の確保も大切なので、今日はこれまで。 といいながら。う〜ん、timer0の割り込み周期を2msにしてみるか？ H8/3664で同じことやらせたらどうなるかな？ 計算の負荷を減らすために、掛け算や割り算を削って、テーブル参照方式にしようか・・・
今週は会社の健康診断があって、今日は私のいる部署の健診日。でも、今日はすっぽかしてしまった。明日やればいいや、と。
ここのところBBSでオブジェクト指向関連の話でコメントをいただいているので、この話題がホットなうちにマウスの分析・設計を進めるべく、22：30帰宅後から非機能的要求仕様の抜き出しとマイクロマウスのユースケース図とクラス図を作成。
| CPU | AKI-H8/3664F | 16MHz | ROM 32KByte | RAM 2048Byte |
| ユーザI/F | ボタンSW 3個 | |||
| LCD 16文字×2列 | ||||
| 通信 | シリアル通信 １ｃｈ | |||
| モータ | 最高速度未計測 | |||
| センサ | 測距可能範囲未計測 | |||
| OS | なし （自作スケジューラで対応） | |||
| Cコンパイラ | YCH8 | 統合環境あり C言語レベルのデバッグ可 |
||
| デバッガ | イエロースコープ | |||
| 番号 | BM03の要件 | 機能 | 性能 | 構造 | ハード |
| 1 | 自律走行により迷路を探索し、ゴールまで到達すること。 | ○ | |||
| 2 | 迷路の条件は、全日本マイクロマウス大会の迷路に準拠すること。 | ○ | |||
| 3 | 迷路の最大サイズは１６ｘ１６区画とし、最小サイズは３ｘ３区画とする。 | ○ | |||
| 4 | マウスのハードウェアは、森永さんの「マイクロマウス初心者講座」で紹介されたBasicMouseを使用する。 | ○ | |||
| 5 | マウスのユーザインターフェースには、ボタンが4個、LCDが1個使用できる。 | ○ | |||
| 6 | 距離センサ用LEDを用いてマウスの内部状態を表示してもよい。 | ○ | ○ | ||
| 7 | 斜め走行とスラローム走行は（今のところは）行わない。 | ○ | |||
| 8 | 迷路探索走行（第1走行）とタイムアタック（第2走行）以外にも、センサの動作テスト機能と、モータの動作テスト機能を備えること。また、姿勢制御テスト機能を備えることが望ましい。 | ○ | |||
| 9 | 迷路探索のアルゴリズムは、等高線マップ法を使用する。 | ○ | |||
| 10 | 迷路探索のデバッグを支援するために、シリアル通信でマウスからPCに迷路情報を転送できること。 | ○ | ○ | ||
| 11 | OSは使用せず、自作のスケジューラでタスク管理を行うこと。 | ○ | |||
| 12 | 迷路探索アルゴリズムの差し替えが可能であること | ○ | |||
| 13 | 最速経路生成アルゴリズムの差し替えが可能であること | ○ | |||
| 14 | センサの自動チューニング機能を有することが望ましい。 | ○ |
ユースケースはできる限り粒度を揃えて、階層化してみた。クラス図は複雑になりすぎ。いろいろ書きたいことはあるけど、もう午前4時を過ぎたのでもう寝ます。
