リファクタリング中 その２
やー、モチベーションを保ってコツコツと進めるのはしんどいですね。本業の研究もしたいし。
現状のソースで、よくないのが、
- センサから来たデータを「○○データ列」というメンバ変数で保持しているのだが、データが増えてきてメンバ変数の数が増えてきた。また、データを増やすたびにメンバ変数が増えると言うのは増やす手間も大きい。
- 元々、ログの再生モードと、走行モードではソースは一元化されていた。そしてすべてのセンサからのデータはメモリ上に保持していた。が、長距離を走らせる試験をしたところメモリ不足でスワップが発生しため、ログ再生モードではすべてのデータをメモリに保持、走行モードではカレントデータのみを保持して過去は破棄に修正した。それによりログ再生モードと走行モードで処理が別になってしまった。
特に、2.は大きい。開発中に実機で動かす時間は少なく、ほとんどがデスクトップPC上での開発になっている。処理が2重化されてしまったため、ログ再生モードでのデバッグと走行モードでのデバッグの2重のデバッグが必要になり、プログラムの処理も複雑化している。元々、一元化されていたころのように戻したい。そこで走行モードでは、カレントのみではなく、データ列をDequeにして過去を捨てるように修正することにした。すべてのデータ列をDequeに変えるついでに、メンバデータの肥大化もあわせて修正するため、TimeLineクラスを新設した。これは、すべてのデータを１つの列に追加してゆく形。ログ再生モードでタイムラインバー（スクロールバー）のGUIがあるので、LRF（Top-URG）のデータをメジャーポイントとして、それ以外のデータをマイナーポイントとして、GUI上のスライダーバーは、メジャーポイントで表示するようにした（その他計算が楽になるので、GUI上の１ステップはメジャーポイントごととした）。
今回の修正で、25Mbyte（10分程度）の走行ログの再生が、メモリ100Mぐらい使用していたのが、40Mぐらいに減った。ログ再生モードと走行モードでソースが一元化されたので実機でのデバッグ負荷が減った。新しい統合オドメトリをいくつか作ることになっても、新しいセンサデータが追加されても修正が最小限で済む。という感じで快適になったはず。
ふー、環境地図の作成はいつになるのやら。
