2010年11月27日

苦戦中

STM32を使う為の環境構築に挑戦
現行のSHの環境を残さないと困るので 念のためにこの間まで使っていたノートPCを引っ張り出して来てそちらでテストをしてからと思ったのだが、、、、

やはり 簡単にはうまくいかない。

-----------------------------------------------------------------------------

全日本の大会の時に「勉強してください」と頂いたボードを使う為に昨日の夜からずっと。
時々 逃避したりしているけど 結構な時間を割いているのに 進展が今一。

JTAGで通信をする事が出来ない、CPUと話が出来なければ 文字通り 話が始まらない。
posted by momoco at 12:47| Comment(4) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月24日

新型構想_CPU

CPUは 最近マウスで使われることが多いSTM32系に挑戦したい。
環境が変わるのは荷が重いが大会中に聞いた事、ちょっと調べた所では苦労する価値はありそう。
しばらくは情報収集にいそしむ。
posted by momoco at 23:21| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月23日

心機一転

今日からいつもの生活に復帰。
トラブルの原因も判明(壁を作った原因は予測でしかないけど)して結構すっきり。
新しい機体も作らず地味な活動の結果、勝負にこだわって無残な戦績。ちょっとへこんだけど、、。

今日からはマウスの2011年度スタート。
今年は好きなように楽しむことにした。作りたい物を作るために勉強して、作ること自体を楽しむ。
勝負に関わらないと言うつもりもないけど 新しい機体を作ろうと考えるとわくわくしてくるのでやっぱり ものつくりの方が興味の対象だなぁと実感しているところ。

まずはコンセプトを考えよう。
posted by momoco at 22:54| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月22日

大会終了

2010年の大会スケジュールが終了。
せっかくシードを貰ったのに最短走行できず。相変わらず全日本では消化不良感。
自分はともかく 久しぶりに日本勢がクラシックを制したり新たな風が感じられる良い大会でした。
大勢の方の尽力に感謝感謝です。 本当にありがとうございました。

-----------------------------------------------------------------------

帰宅、明日は休みでないが、今日は休みを取ってあるのでゆっくり。

今年は結果と言うか勝負にこだわりすぎた。それで結果が無いとがっかり。ハードを継続した分、小改造とチューニングなのでベクトルが過程でなくて結果の方に比重が行ってしまった。
マウス本体としてはすでに時代遅れなのを再確認したので この後はしっかりと代替わりを考えよう。 やること覚えることが多いと過程が楽しめるので そちらの方が精神衛生上もベターだろう。STM32を搭載したボードを頂いたし、勉強しないとなぁ。

-------------------------------------------------------------------------

原因判明
最短走行が出来なかった理由が判明した。
いくつかの複合みたいだ。
・無い壁を作っていた。ゴール区画の中に1枚壁がなぜかある。ただし、最短経路は残っている。
・袋小路をふさぐ処理をする。本来はゴールの中は空なので袋小路ではない。しかし、壁が1枚あるので袋小路が出来る。そこから順に塞いでいくとゴールに入れなくなる、、、。
1か所の誤検知がゴール区画内だったために起きた事らしい。
うーーーーん、参った。


posted by momoco at 08:46| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月21日

大会当日

大会当日の朝。
昨日までの観戦で周りの進化を感じる。マイナーチェンジが通じるのも今年まで、電気系のフルモデルチェンジをしないことには先はないなぁ。
思いっきりプレッシャーをかけられ続けたけど、結果はもうすぐ判明する。
そろそろ出かけよう。
posted by momoco at 08:03| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月18日

今週の本職は終了

明日は予定通りお休み。 
マウスモードに切り替え。
昼前に出れば良い時間にホテルに到着できる。 まず立体駐車場を確保してから会場入りの予定。
長めの斜めの調整だけはやっておきたい。
参加するみなさん 会場でお会いしましょう。
posted by momoco at 23:03| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月17日

最短経路続き

最短経路の比較
2008年決勝の迷路の例
通常使う予定の「最適経路」上位のマウスが選んだ経路
2008BEST2.bmp
タイム的に一番最速になる「最速経路」momocoが選んだ経路、ちょっと難しかったみたい
2008FAST.bmp
昨日作った「直線優先経路」
2008STRAIGHT.bmp

最速と最適は一致する事が多い。違う場合でもタイムはそんなに違わない。なのでコマンドを増やさないため 競技用に準備をするのは 「最適」と「直線優先」の2つに。
改めて決勝の迷路は経路の選択幅があって面白い、、なんて余裕言っていて大丈夫か?
posted by momoco at 23:45| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月16日

直線優先

今更ながら 直線優先の経路を選べるようにしてみた。
トライの回数が十分に取れる時でもないと使用しないだろうが もしもの時にあっても良いかと思って。 もともと重みを変えて等高線MAPを作り経路を数種類(ダブりもあり)作り 斜めを含んだルートに翻訳してから ターンの種類や直線の長さなどを考慮して「最適」経路を選んでいる。最後の評価の時の配点を変えると別の個性を持った経路が選べる。 なのでノーマル直線に配点を小さく(点の少ない方を選ぶので)すると 直線優先が選べる。
重みを変えた等高線MAPがベースなので最短の歩数では無いルートも候補に上がる。
「最適」を選ぶと 過去の迷路でほぼ優勝マウスの選んだ経路を選択できる。
今回用意した「直線優先」を選ぶと結構遠回りでも直線をつないだ経路を選ぶ。保険としては使えるかな。
去年は探索の後、経路の算出に異常に時間がかかりトライが出来なかった(予選)。しらみつぶしに経路を作って評価していたので案別経路が多いと時間がかかった。普通はそんなに候補がないはずだが去年の予選は相性が悪かった、、、。 今年は 重み付けの種類しか案別がないので たしか10種類だけ評価。これなら見た目には待ち時間なしで終了する。
実は今年の進歩はこれが一番だったりするかも。 
posted by momoco at 23:52| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

去年の迷路

例によって各所を拝見させてもらっていると サイエンス・チャンネルで去年の大会が見れるととの情報。 さっそく見てみると 去年の決勝はあんな迷路だったか、、、。 斜めの長いのが連続で。
あの斜めは自宅サイズでは試せない。 全日本になると斜めを嫌がる様ではだめなんだと改めて実感。金曜日に試すしかあるまい。 それでまともに走れれば良し、ダメなら、やばいかもしれない。
不安の種は尽きない。
posted by momoco at 00:06| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月14日

まだまだ見つかる

重ね探索の変更を確認するためにセミクォーター迷路を広げた。
変更は 今までは重ねの時も最初は足立でゴールを目指した。それをゴールが出ていれば全面探査にすぐ入る様に変更。全面は一番歩数が少なく見に行ける未探索区画に向かう仕様。なのでゴールに向かうと全面探査終了までには時間がかかる可能性がある。 とりあえずゴールに向かう方は別のゴールまでの経路が早く出ると言う事。失敗の可能性が高い時には少しでもゴールに向かう経路を増やしたいのでそれも悪くないのだが、、、。
選択できるようにしても競技中は冷静に考えられない可能性が大なのでまぁ決め打ちで。1回の探索で決められれば必要のないことなんだけど。

探索の確認は 問題なく機能したのでOKだったのだが、、 
もう弄るのはやめと思っていたけどせっかく迷路をひろげたし と思って最短走行を試すと 失敗。大して難しくも無いのに。速度を下げてもゴールはするものの壁に接触したり。
やばいので真面目にログを取って見てみると 斜め直線で 横センサーでのエッジが読めていない。ターンに入る前に内側のエッジ検出MUSTがあだになりそのまま直線走行を続けてします。待ちの距離に制限を設けてあるので永遠に直線ではないけど遅れてターンに入るので失敗したり、接触をしたり。
原因は斜め直線で横センサーのエッジを見ようとした時に やはり柱の手前、後ろ、両側に壁がある時で反応の仕方が大きく違う。 エッジを見る時は後ろに壁のあるなしが影響大。
斜めセンサーだと角度が点いている分後ろ側の壁はほとんど影響がない。(斜めセンサーの場合は手前の壁が影響大だけど) その結果 後ろに壁がありそれを検出している間にエッジの判定範囲を超えてしまった(らしい)。 今までなぜ気付かなかったのかは不明だけど 出やすいパターンとかあるのかもしれない。
対応は 斜めの直線では横センサーでの距離の補正はしない。斜めセンサーのみ。もともと斜めは走行路が狭くズレによる誤差が出にくいのでOKだろう。 また斜めだと最後の区画で検出せずにターンに入る事があるので MUSTの検出も斜めの直線ではOFFにする。 
これで今回問題になった経路はちゃんと走れるようになった。やはり簡単で短いからエラーが無ければ危なげなくゴール。
調子に乗ってMAXを試すと別のルートを選んだ、、
確かに速度パラメータも考慮して経路を選ぶようにしているけど 今までは速度によって実際に選ぶ経路が違う例はなかった気がする。 後でシミュレータで所要時間を比べてみるかな。

何にしてもさらに 問題が見つかったのは収穫。
メモ代わりにMOVIEを貼り付けて 今後の調整のパターンの1ケースとして記録。

速度は中部大会と同じ
こちらが修正前のトラブルケース 斜めの直線からターンに入るのが遅れているのがよくわかる。



posted by momoco at 12:06| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月13日

まだ見つかる

大会前の最後の週末
大きな作業テーマは無し。
タイヤも結構ぼろぼろになっているがここでの変更はパラメータへの影響が不明なのでこのままとする。 バッテリーは新しいもので問題がないと思われるので この週末に新しいのをパックする予定。
スカートも少し擦り切れてきているがこちらも変更のリスクの方が大きいのでそのまま。思ったより耐久性があったので夏に作ったまま。

作業は昼過ぎから ぼちぼちと 斜めの調整から。 中部前に柱の手前に壁がある場合と裏側に壁がある場合の 場合分け姿勢制御をあわてて実装した。 その再調整。 壁が裏=柱のみ なのでこちらは再調整の必要はなさそう。 手前に壁がある場合は 急いで決めた定数はベストではなさそう。
ところが 変な補正が入る時がある。 ログをチェックすると、、、
斜めの直線では柱が左右交互にやってくる。 なのに柱のない側にエッジのフラグが立っている。フラグが立つとその時に柱によるセンサー出力のピークを計算する。 もちろん本当は柱がないのでピークと言っても全然低い。 結果柱から離れすぎと判断してそちらによってしまう。 最大制御量にリミットがあるので とんでもなく飛んでは行かないけれど変なズレによりその後の軌道が乱れる。
エッジが立つのは 柱の判定の閾値が低すぎるので 斜め用に閾値を新設定して 少し高めにした。

さらに、エッジフラッグの2度だしが発生。2度目のエッジではピークが一度リセットされているので本来のピークよりずっと低い値(柱を過ぎているのでバックグラウンドレベル)になる。なのでこの場合も変な補正になる。 こちらはフラッグをクリアするタイミングが変だったために起きた事が判明。 無駄に色々な変数をログしていると不意に起きた事象でも解明できる時がある。

単純ミスじゃないバグも残っている。 本当の所 あとどの位眠っているのか。 ソフトは怖いなぁ。

-------------------------------------------------------------------------------
斜めの調整を終了
壁が手前にある時の閾値が低かったのを少し上げ。真ん中を通っている時に補正量があまり発生しない様にしただけ。 中部の動画ではちょこちょこ機体を振っているのでこれで少し収まるはず。

各所を見に回っていて思い出させられた(良かった)。
決勝は5分だった。 決勝の経験が少ないので5分のイメージが今一。7分あれば トラブルさえなければ全面探索+4回トライは 難しくない。 が5分だとかなり短い。 唯一まっとうな競技が出来たおととしも4本の最短は出来ていない。 とは言っても 今更探索早くも無いので トラブルがあった時にどうするかを準備しよう。
@基本の探索:(変則)足立でゴール→全面探査、タイマー210秒
A重ね探索:タイマー120秒
B重ね探索:タイマー60秒
と言ったところか。 重ねはゴールまでのMAPが無いと足立から、あれば全面 を自動選択にして。

最短走行は 無駄に段階が一杯用意してあるので どこら辺を使うか 
@東北大会A中部大会BMAXの順で 失敗をしたらそこから少し下げるとすると、やはり最低で3本は最短をしたい。 やっぱり探索が1発で成功するか、、がポイントだなぁ。






posted by momoco at 14:05| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月10日

またバグ発覚

斜めの姿勢制御の中で「センサーの値が閾値より大きい場合」
if(センサー値>閾値)が何故か if(センサー値+閾値)になっていた。
これだと いつも正になり 補正が入る→センターを通っていてもふらふら。
右側だけなので半分は正常に働く。
これが全てではないけど 一つの要因だったのだろう。

怖いのはこう言ったミスが他にも入り込んでいること。
「他には無い」と言うほどの自信は全く無い。
以前には if(A==B)のところが if(A=B)なんて言うのもあったし。
posted by momoco at 00:27| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月08日

帰りのルート

帰りのルートを算出できた。 と言っても単純に最短の経路の逆をたどらせるだけ。確実で簡単な方法だ。スマートじゃないけど。 シミュレーションでは問題ない。 動作の確認はまた週末。


去年のlogをチェックして少しがっかり。
今年 まぁ使えそうなパラメータは去年のTOPパラメータよりも低いのに気付いた。さらになぜだかターン入口のDUTYも飽和していないか、していても少しだけのようだ。 ターン前半の速度追従性がはるかによい。 今年は速度を上げて調整をトライしたけど実用的な所まで下がってきたら去年とあまり変わらなかったと言うおち。 安定度は上だと信じたいけど、、。
posted by momoco at 23:50| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月07日

------

若干 体調不調

東北、中部で起きていたターン進入位置のズレの原因はつかめていない。
可能性としては エッジの見落としが一番わかりやすいのだが、、、。
ターン前が壁なのでエッジを見落とす可能性は低い
進入位置の指示間違い これも突然一か所だけ、、は変。
ターン走行距離での補正が入っていなかったのが判ったのでターンが大きく乱れるとターン終了の位置がずれた時の補正がない。ターンが伸びた(方向が定まるのが遅れた場合)は次のターンの進入が遅れる。その場合はエッジで補正が入るのだが、、、。
最後のターン内側のエッジは必ず存在をするので検出MUSTとしている。そのため見落とすとずっと待って進んでしまう。横センサーのエッジが出るまでは進む。横センサーはセンサーが近いし角度もついていないので斜めより確実。とは言え高速のターンでは横センサーのエッジではすでに遅い。

などなどを考えて検出MUSTを外すことにした。一番早くターンを始める45度ターンでも斜めのエッジから20mmほどの余裕があるので その20mmの間にエッジが見えれば補正される。それ以上ずれた時は待ちきれずにターンを始めてしまうわけだが そもそも20mmもずれている時点でかなり無理な事になっているはず。 そこを捨ててでもエッジ見逃しによるターン開始の遅れを嫌ったわけ。 エッジ見逃し、20mm以上のズレ+45度ターン と言うレアなはずのケースの事なのでいずれにしても大勢に影響は出ないはずなのだが。

---------------------------------------------------------------------------
ログを見ていて気付いた左斜センサーの出力がおかしくなる時があるみたい。 そう見えてからだと全体的に怪しい。 時々ノイズがのるという時と横センサーの値に対して低すぎる時と。
例によってハードのトラブルか。左斜センサーの回路を再度半田ごてでなめてみる。結果、きれいになった気がする。エッジも正確に検出できているようで走りもベターになっている(みたい)。
と言う事で前言撤回、必須エッジ検出は残す。 

競技そのものには影響が少ないのだが最短走行からの帰りが出来なくなっている。 探索からはOK。どうも帰りの経路を求められていないみたい。 今年は最適経路の算出を完全新作したけどその際に帰りの経路算出に影響が出ていたのに気付かなかった。 競技ではゴールのマウスを取りに行くより自分で戻ってくる方が時間の節約になると思うので 再度ちゃんと整備しないと、、。もちろん戻ってくるマウスの方が知的で賢げに見える(本当に賢い)ので。 吸引マウスは帰りの為だけにターンをチューニングするので(ファン無のターンを一揃え持たないといけないので)つい億劫になってしまう。

----------------------------------------------------------------------------
帰りのルートの作成部はデスクワークで出来るのでファン無ターンの調整。900mm/sec程度のターンならファンがなくても安定。ここで少し早くても実用上メリットは少ないのでゆったりとした速度。
音も静かだし、迫力もない分気楽に調整できる。ハードが痛む心配も少ないし。


ミニモーターの軸も削りますか、、、。すごい
穴はもしかすると、、
posted by momoco at 13:17| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月06日

探索向上

午前中は通院などで 先ほど迷路を広げて探索テスト。袋小路っばかり(17回)を問題なくパス。袋小路を出る時の向きも補正されていて改善。横位置の修正がうまくなくて繰り返すとずれていく。もっとひどくなるとおしり当ての修正が入るのでまぁまぁってことか。バッテリーの充電を忘れていたので1回テストして一安心したところで充電中。

----------------------------------------------------------------------
午後に買い物に付き合ったりで 作業はごくわずか。 探索のずれも調整。 例のトラブルも再現をしない。 探索の見た目の安定感はアップ。 探索の心配は少し去ったかな。

----------------------------------------------------------------------
最短走行の弱点の洗い出しが出来ないかとトライ。 壁の後のターンでエッジを見逃すことがあるのかどうか。直角で壁有なので本来なら比較的楽な迷路なはず。 ところが 中部の速度でゴールが出来ない。 もちろんそれ以上も。 東北の速度はOK。 もう少しの上乗せも大丈夫みたい。だが中部の速度は数回トライしてもゴールはしても接触が多くとても走れたという感じではない。やはり中部は運が良かったのか?
東北の速度

中部の速度

まだどこでも使えていない準備した最高パラメータ


エッジの見逃しとかではなく 時々ターンが抜けることがあるのかもしれない。

-----------------------------------------------------------------------
90度ターンと135度などのターンでは約200mm/secの差をつけてあるのだがそれが少しバランス悪いのかもしれない。 弱気だけど45/90度のターン速度を少し下げる事にした。
posted by momoco at 15:18| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月05日

週末

帰宅→週末突入
今週は探索の確認の予定。ループ中の処理の追加で本当に不測の停止がなくなるのか?バグが残っていたとしても他に怪しい所は見つからないので手の打ちようがないのだが。
最短走行は中部の直前に修正をした斜めの姿勢制御をもう少し改良したい。もうちょっとセンター付近でちょこちょこ修正をしないでスーッと走り抜けてほしい。
中部最短の動画をアップしてしまいました。 被写体はうちのだけど撮影者は自分で無いのですが撮影者さんに連絡が取れていません。 不都合があればご連絡ください。

こちらは通常モード


こっちは同じ走行のハイスピード動画


斜めでちょこちょこしているのが判る。センターに居るときは無理に修正をする必要はなので ロスにはなるし不安定の原因にもなりそうなので もう少し改良をしたい。
前半の左90度ターンで大きく膨らんでいるのも気になる。もしかするとエッジを見逃しているのかもしれない。 90度ターンだから後が続いたけど斜め系のターンだと完全に失敗をしているはず。
うまくゴールしたけど完全ではなかったみたいだ。
ログは無いのでターンの改良は難しい、、、。
posted by momoco at 22:07| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月04日

慣性モーメント測定法

「実験とシミュレーションで学ぶ モーター制御」日刊工業新聞社
に2本釣り法と言う計測法が紹介されています(150頁)。
自分ではやったことがないですが。 大体の重量物で当たりをつけて後は計算結果と実際の結果、(DUTYから換算して)を照らし合わせて合わせ込みで決めてます。 あまりアカデミックな方法ではないけど。 慣性モーメント以外にも色々な外力が考えられるので それらも合うように定数を設定している、、。 
posted by momoco at 23:46| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年11月03日

ミスを発見

世間はお仕事だが うちは通常業務、とは言え少しだけ早く帰宅、実作業は無しでデスクワーク(?)のみ。

探索で微妙にずれる原因の一つが発覚。超信地の180度旋回で横壁を使って向きを修正する補正が無効になっていた。超信地の旋回そのものを調整すれば良くはなるけどちょっとずれていた分補正が働いていないのが見つけやすくなっていた。 ほかにも最短走行でターンの終了位置補正もOFFになっていた。中部ではそのままになっていた。そうなるとこの補正は使わない方が良いのだろうか?ちょっと不安になる。

-------------------------------------------------------------------
うちもこんなの去年までやってました。
今年はファンの影響などが大きくなり合わなくなっているので直接調整で進入位置を決めてますが、、。
ターンシミュレーション.bmp
基本原理はタイヤのスリップアングルが進行方向に対して横方向の力を発生させそれが進行方向を変える、これを繰り返すシミュレーション。
タイヤの左右の速度差→自転運動→タイヤが進行方向に対して角度を持つ→横力発生→進路が変わる
こんな繰り返し 進行方向が変わるのに合わせて自転速度をコントロールしてターンを継続する。
基本はスリップアングルに比例して横力が出ると言うモデル。


posted by momoco at 21:53| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年10月31日

判らない

全く進展しない。 さすがに今週は根を詰めての作業はしていないがそれにしても進展がなさすぎ。

問題のなさそうな 東北の時と トラブルが出る中部のコードの比較。 自宅迷路でも結果としてトラブルが出る可能性がある(いつもではないが)のは中部のコード。 比較をしても 探索時に使うところには変更がない様に見える。 それはそうで主に最短走行を修正していたのだから当然。少しいじった探索も具合が悪いので元に戻したのだから。 戻し忘れか 戻しをする時に間違えたか、、と考えていたけど そのような所は見つからない。
仕方がないので 探索時のどの部分でトラぶっているのかログを取るように 処理毎にログを入れてみるとなぜか ほとんどトラぶらなくなった 10回位探索をして 2回ほど探索終了から戻りになる所で同様に停止してしまったが走行中はなし。 ログを取るコードを足しただけなのに。念のためオリジナルの中部の時に戻すと やはり高確率でトラブル発生。
症状が何についてくるのか全く判らない。 何かちょっとでも変えると自宅での発生率はぐっと減るけど それがフル迷路でもそうなのかはわからない。 
上の分析が当たっていればハードが原因と言う事はなさそうだけど、本当にどうなっているんだ?

------------------------------------------------------------------------------
迷路を組み替えてとにかく袋小路ばっかりにした。これで不具合の発生率を上げることができた(みたい) 中部のコードだと探索が終了する前にほぼどこかで停止する症状が現れる。
この状態で 1か所 「変える」「戻す」でトラブルをコントロール出来ることを発見。ただし、トラブルが出ない方は確率が低くなっているだけかもしれないのだが。
探索直線で 「現在の位置からそのまま区画のセンターまで走って中央で止まる」の命令をセット。あとはすべて割り込みの中で処理される。停止してタイヤ固定を0.1secするとmcont_modeと言う変数が0になる。 そこでメインでは 0になるのを待っているわけだが、、、
while(mcont_mode!=0);だと トラブルが発生する時がある
while(mcont_mode!=0){puts("A")} とすると今のところトラブルが発生しない。
Aと出力するのは停止した状態で出力を見てAが出てれば個々のルーチン内でトラぶっている のが判るかと思って同様のルーチン内にBやCなど マークを入れただけ。 
もちろん東北用でもここは同じ。 よって本当の原因ではないがここを弄ると状態が変わりトラブルが非常に出にくくなるだけなのだろう。
このままほっておけば実用上問題が出ないのかもしれない(?)が かなり不安。
こう言った不得意分野に入りたくないので割り込みも1本だけとシンプルにしているのに。メインで少し時間のかかることをやると何か状態が変わるのだろうか?そもそも東北用ではなんで問題が出ないんだ。

このデバック作業でいつになく探索を走らせているので苦手な(ずれやすい)パターンが見えてきた。 それはそれで収穫。パラメータの修正で改善は出来るだろう(と思う)。

posted by momoco at 16:06| Comment(5) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年10月30日

再現

さっそく朝に6x4迷路と9x4迷路をつないでゴール区画があるようにして探索のテスト。やはり180度回転の前で止まった。 あと少しで探索が完了するところ。探索中のログはごく一部の情報なのでそれはあてにならない。 そこで症状から。 止まった時にタイヤの状態がロックになっているのが確認できた。停止した状態のままロック、もしくは回転動作に入って回転できていないのか。
カウンターのLEDは点滅しているし Push SWでの解除も可能、探索中のマップの掃出しも問題がないのでCPUの暴走的なバグではない。 症状から見るとロジカルに見つけやすそうなのだが、、、
まだコードを見ても原因は思いつかない。

-------------------------------------------------------------------------------
判らない
中部で使ったコードだと自宅の迷路で2〜3回に1回程度でSTOPが再現。東北の時だと今のところ(7,8回)で再現は無。ここの間に差があるのだろうと推測。 でも、判らない。 もしかすると東北の本当はもだめなのか?
posted by momoco at 10:44| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。