２００４年 　６輪マウスのハードウェアは完成した。 　今年はソフトウェアの完成させて、改めて井谷さんとの６輪マウスのワンツーフィニッシュを目指す。 　また、今のハードで走りこむ事によって得られる経験を元に、2005年に向けての新規ハードウェアの検討も開始する。 1/1〜3/31　4/1〜6/30　7/1〜8/31　10/1〜11/21　最新へ→ １月１日 好きとか嫌いとか最初に言い出したのは誰なのかしら？ 　あけましておめでとうございます 　更新は遅めですが、本年もどうぞよろしくお付き合いください。 　で、元旦ということで、初詣に行っておみくじをひいてみた。 　　争事（あらそい）：勝てども後に恨まれる 　……なんか、先行き不安だ(--; ２月７日 　 　マウス活動を再開。 　とりあえず、空気にさらされてカサカサになっていた、瑠璃のタイヤのスポンジの張替え。 後はバッテリのリフレッシュをして、ぼちぼちやっていこう。 　で、今年こそはPC98からWindowsに開発環境を移そうと思い、とりあえずノートPCにTurbo Assemblerをインストールしようと、 以前買っておいたC++ SuiteのCD-ROMを探したが……発見できず。 ずっと放ったらかしだったから、ゲームのCDの山に埋もれてしまったようだ。 先ずはCD-ROMの整理からやらないといけないなぁ……(と、2002年の7月から言っているのに、全然片付いてない(苦笑)） ３月７日 マーフィの法則 　約３ヶ月ぶりに迷路を走行。 　年度末が近いせいか、仕事が忙しくてなかなかマウスまで気力が回らないのだが、来週１４日に名古屋工学院専門学校で開催される熱田の森ロボット大会でマウスのデモ走行を依頼されているので、その準備を始めた。 　先月、張り替えようとしたタイヤは、在庫のスポンジが古かったせいか、短冊状に切ったスポンジの繋ぎ目を瞬間接着剤で接着して、環状にする際に失敗してしまったので、 改めて新しいスポンジを購入して、張り直した。 　で、早速NEWタイヤで軽く迷路を走らせてみて、問題がないことを確認。２年前(2002年大会)から、ハードもソフトも殆ど変更してないけど、 当時かなり集中して作ったおかげか、局地走行での探索に関しては安定性抜群だと思う。 　本当は、今年の目標の一つであるノンストップ探索のソフトを組み込んで、格好良いデモ走行をしようかと思っていたけど、 こっちの方が「第１走行は遅く、第２走行は速い」っていうマウスらしさが説明しやすいだろう…ということで、今回はこのままにしておこう（と、言い訳しておく(笑)） 　ということで、ボチボチ本命の６輪の方のソフトを弄り始める事にする。 　先月から探しまくっていたC++ Suiteは、CDの山の中からは発見されず、仕方がないのであきらめて、資料とかを入れている机の引出しを漁っていたら……今年こそは使おうと思っているLibrettoと一緒に出てきた(苦笑)　所詮、探し物はこんなものだ……って、よく考えたら、年始のおみくじにこう書いてあったのを思い出した。 　　失物（うせもの）：物の間にあり 　……当たってるじゃん(T_T) ３月１４日 反省するなら猿でも出来る 　熱田の森ロボット大会にてマウス(瑠璃)のデモ走行を行なってきた。 　大会自体は、相撲とライントレーサーがメインなので、マウスは競技前の前座だった。 しかし、非常に沢山の参加者の前でのデモだったので、ちょっと緊張。 格好良くデモ走行をキメようと思っていたのに、タイヤ交換後に微調整を行なっていないせいか、やはりパラメータがずれていて全開の第２走行は出来ず。 　こんなのじゃダメだ。やはり、６輪(翡翠)の制御部分は１から作り直そう。 ３月２７日 　ふと思い立って、探索ルーチンを再検討してみる。 　基本路線はそのままで、もう少し賢くならないかと、 未探索地区での進行方向を決める評価値計算を弄ってみたが、 探索済み区間が多くなってくると、逆に効率が悪くなってしまった。二晩ほど時間を費やしたけどボツ。がっかり……。 　しかし、その検討中に最短ルーチンのバグを見つけてしまった。 大きな問題ではないが、コーナーでの重み計算がちゃんと出来ていないところがあったのだ。 でも、この問題を修正すると、2003年の決勝迷路で、自分では理想だと思っていた最短コースが出ない。 具体的に言うと、井谷さんや森永さんが選択した、迷路左上部分で櫛を通るコース。バグありバージョンだとここを選択していたが、 修正後はシンガポール勢と同じく、櫛の部分を通らずに、その上の斜め４５度が連続するブロックを通過するようになってしまった。 うーん、どうするべきか……。 ３月２８日 　探索ルーチンを再検討...の続き。 　気になったので、現在のソースをPC上でシミュレーションでチェックしてみたんだけど…… 　　昔のシミュレーション用プログラムより、明らかに動作が遅い(--; 　何かがおかしい。実機では、こんな動きは絶対していない。 　大体、オールBASICで書いたシミュレーションソフトより遅いというのがヘンだ(苦笑) 　うーん、何かワークエリアをクリアするの忘れてるかなぁ…… ３月２９日 　探索ルーチンを再検討...の続き(2)。 　昨日のバグは、やはり、変数の操作ミスだった。 シミュレータ側から探索ルーチンを呼び、仮想マウスを走行させた後に、その時の歩数をクリアしてなかったので、１歩の移動でも最短ルーチンがコールされていたのだ。 実は、このミスにHPを更新した後に直ぐに気づいたので、チョイチョイっと修正し、今までの実績通り、ちゃんと動作することを確認した。 　今日はその続きで、最短ルーチンで作成されるマップの確認をしたのだが…… 　　シミュレータと等高線の引き方が逆だよ(--; 　アルゴリズムにもよるけど、Ａ地点からＢ地点までの最短を出す時に、「Ａ地点をスタート、Ｂ地点をゴール」とした場合と、 「Ｂ地点をスタート、Ａ地点をゴール」とした場合では、結果が違うことがある。 特に、直進優先でコーナーに重みを付けると、その結果が変わることが多いようだ。 　当時、どうして逆にしたのかは忘れたが、生成されたマップを見ると、やはり、重み付けのミスが発生しているようなので、 先ずはその修正を試して、それから、正順の引き方でも試してみようと思う。 ３月３１日 　探索ルーチンを再検討...の続き(3)。 　ということで、先ずは最短ルーチンの重み付け間違いをFIXした。 単に余計な処理をしていたところをコメントアウトするだけで済んだので、あっという間に修正完了。 ついでに、マップ初期化等を無駄なループで行なっていた部分があったので、ストリング命令に書き換えたところ、大幅にスピードアップ。 うーん、もっと早く修正しておくべきだった……。 　ところで、現在使用中の最短ルーチンにおいて、目的地を起点としていた理由を、ソースを眺めていて思い出した。 それは、等高線を書き終えたあと、出発地から順に低いところへと辿っていけば、目的地までの道順がそのまま求められるので、プログラムが楽だし、単純なので処理が軽いのだ。 しかし、シミュレータで試してみると、最短を求める時の起点を出発地とするか目的地とするかは、小さな違いだが、出発地を起点とする方が直進＆斜め優先をかけやすいような気がする。 今日書いた斜め優先部分のバグがとれたら、起点を逆にするルーチンに変更してみよう。 Back