問題のなさそうな 東北の時と トラブルが出る中部のコードの比較。 自宅迷路でも結果としてトラブルが出る可能性がある(いつもではないが)のは中部のコード。 比較をしても 探索時に使うところには変更がない様に見える。 それはそうで主に最短走行を修正していたのだから当然。少しいじった探索も具合が悪いので元に戻したのだから。 戻し忘れか 戻しをする時に間違えたか、、と考えていたけど そのような所は見つからない。
仕方がないので 探索時のどの部分でトラぶっているのかログを取るように 処理毎にログを入れてみるとなぜか ほとんどトラぶらなくなった 10回位探索をして 2回ほど探索終了から戻りになる所で同様に停止してしまったが走行中はなし。 ログを取るコードを足しただけなのに。念のためオリジナルの中部の時に戻すと やはり高確率でトラブル発生。
症状が何についてくるのか全く判らない。 何かちょっとでも変えると自宅での発生率はぐっと減るけど それがフル迷路でもそうなのかはわからない。
上の分析が当たっていればハードが原因と言う事はなさそうだけど、本当にどうなっているんだ?
------------------------------------------------------------------------------
迷路を組み替えてとにかく袋小路ばっかりにした。これで不具合の発生率を上げることができた(みたい) 中部のコードだと探索が終了する前にほぼどこかで停止する症状が現れる。
この状態で 1か所 「変える」「戻す」でトラブルをコントロール出来ることを発見。ただし、トラブルが出ない方は確率が低くなっているだけかもしれないのだが。
探索直線で 「現在の位置からそのまま区画のセンターまで走って中央で止まる」の命令をセット。あとはすべて割り込みの中で処理される。停止してタイヤ固定を0.1secするとmcont_modeと言う変数が0になる。 そこでメインでは 0になるのを待っているわけだが、、、
while(mcont_mode!=0);だと トラブルが発生する時がある
while(mcont_mode!=0){puts("A")} とすると今のところトラブルが発生しない。
Aと出力するのは停止した状態で出力を見てAが出てれば個々のルーチン内でトラぶっている のが判るかと思って同様のルーチン内にBやCなど マークを入れただけ。
もちろん東北用でもここは同じ。 よって本当の原因ではないがここを弄ると状態が変わりトラブルが非常に出にくくなるだけなのだろう。
このままほっておけば実用上問題が出ないのかもしれない(?)が かなり不安。
こう言った不得意分野に入りたくないので割り込みも1本だけとシンプルにしているのに。メインで少し時間のかかることをやると何か状態が変わるのだろうか?そもそも東北用ではなんで問題が出ないんだ。
このデバック作業でいつになく探索を走らせているので苦手な(ずれやすい)パターンが見えてきた。 それはそれで収穫。パラメータの修正で改善は出来るだろう(と思う)。