Donkeycar V4.1.0 のデータセット構成を調べる

 Donkeycar の github 上の master ブランチが 4.1.0 になった。

V4はでていたが、masterブランチは3.1.xのままだったので、V4についてはとくに調べることをせずに放置していたのだが..ひさしぶりにインストールしようとしたら..エラー乱発..それでmasterブランチがV4にマージされたことを知った。

Discordにもはいっていたが、やたらPCから音が出るのでアンインストールしていたので、アナウンスが多分あったのだとは思うが、知らなかった。

 V4で何が変わったかというと、一番がTubデータの構造だ。

V3までのTubデータはトップディレクトリdataの下にtub_<1からの連番＞_YY-MM-DDというサブディレクトリが運転を実行するたびに作成されこの下に１レコードにつきJSONファイル1つとJPEGファイルが1つ作成されるという構成だった。

V3の構造で最も問題になっていたのが、トレーニング処理がレコード件数に比例して時間がかかるというもの。

１レコード２ファイルのI/O処理がはいるこの構造は、正直機械学習向きではない。とはいえDonkeycarの機械学習モデルはせいぜいが５層で深層学習と言えるほど深くない。ためしていないが数理最適化アルゴリズムのほうがよいかもな..とも思えるくらいの小規模モデルだ。なのでトレーニング時間はそれほど長くはないので、これでも問題なく利用されていた。

また、手動走行中にミスが有りデータを削除する場合、連番に飛びが発生するが、そのままではトレーニング処理でエラーが出てしまうという問題もあった。どうしてもクラッシュしたデータレコードを削除したくなると、歯抜けのTubデータになってしまい、連番をつけなおすスクリプトを作って対処していた。

どうもこれらの問題を解決するためにV4ではdatastore自体を見直したようだ。

で、ソースコードをよんだり、実際にデータを出力させてみた結果、以下の構造をしていることがわかってきた。

 

V3でJSONファイルになっていた数値データは、Catalogファイルに格納される。Catalogファイルは、デフォルト1000レコードごとに切り出されており、Catalogファイルとしての連番がつくようになっている（1000件未満の場合は１ファイルになる）。

 Catalogファイルが複数になる場合があるため、各Catalogファイルに対応したマニフェストファイルが作られている。この中にはCatalogファイルの先頭レコードがレコード連番の南蛮から始まるかや、１行のバイト長リストなどがはいっている。いわばCatalogファイルごとのメタ情報が入っているファイルだ。バイト帳リストは、コード内でランダムアクセス操作をするために使われている（詳細はSeekableクラスを参照してもらえばわかる）。 Catalogマニフェストファイルといえばいいのかな。

そして複数のCatalogファイルをまたいだメタ情報をまとめたのがmanifest.jsonというファイル。ここに入力データのラベルリストや型リストが入っている。また削除対象のインデックス番号リストを格納できるようになっており、ここに削除したいレコードのインデックスをリスト形式で書いておけば削除したものとみなして処理してくれる仕様だ。

 上記のファイルのI/O操作はdatastore_v2.pyにかかれている。Seekableクラスもここに格納されている。

 V3のデータをコンバートするツールも提供されているので、これまでの学習データが無駄になることはないが、ひと手間確実に面倒になることに注意。

 また、Donkeycar上で、python manage.py drive を複数回実行すると、V3の頃はdataの下にサブディレクトリができるが、V4ではインデックス番号はつづきからふられるため、分離できないことも注意が必要だ。dataディレクトリを削除してしまうか移動させておかないと各レコードの_created_atで調整しなくてはならなくなる。

 

 

p.s.

運転する際は、Tubデータを書き込むだけなので、ここまでの内容を理解していれば問題はない。

しかしもし機械学習モデルの入力データ項目にIMU情報はその他の情報をくわえたり、出力データ項目を増やしてモータ数を増やそうとしている場合は、機械学習モデルにデータセットとして渡す処理donkey.parts.pipelineパッケージ以下のコードを理解する必要がある。