見出し画像

ETロボコン2020年を終えて

hama-matcha

恵庭戦隊トシキングで参加したhama-matchaです．ここでは感想をぶらぶらと述べていきます．今年はオンライン開催だったETロボコンでどうなるのかなぁと感じていましたが，シミュレータになったおかげで，HSVの色判別モデルが組みやすく，カラーセンサの輝度値も素直だったので割と何とか開発できました．2020年は大きな転換点を迎えていて，初期メンバーを知る人がいなくなり完全な引継ぎになっていました．そのため，2015年から作られていたコードを見直しつつ継ぎ足していた秘伝のコードがいよいよ限界を迎え，一から作り直しを決意しました．なるべく既存のコード内でモジュール化をできないか考えていましたが，うまく分けられてそうで意外と依存関係の多い部分があり，UMLモデリングが致命的に解読できなかったので，ほとんど抽出はできなかったのが残念です．また，コードはGitHub管理なのにUMLは秘蔵のローカルフォルダーや研究室のサーバに置かれていたりと点在データの掘り起こしも諦めました．この経験から，新たに作ったコードとモデルは引継ぎ可能となるよう今年から2年かけてGitHubのみで管理できるようにしていきたいです．さて，そんなモデルですがQiitaのほうにちょっとまとめておきました．

全体の予定を大雑把に振り返っていても，

4~8月　トシキングのコードをモデル化しようと頑張ってた

9月~10月　トシキングのコード再利用をあきらめて新しく作り始めた

だったので，他人のコードを読み解くのがいかに難しいのかよく分かった前期でした．むしろ，自分で作り始めたときに，過去のコードをモジュール単位で移行できないけどコードレベルならちょっと参考になる！とか思って反映していたのは記憶に新しいです．なので，他人のコードを必死に読み解くのは別段無駄な時間ではないと言い切れます．そうでなければ，後期でこんなに爆速開発ができると思わないからです．実際コミット数見てても後半がやばかったなぁ・・・．

45 contributionって人生で初めてこんなにコミットしたかも・・・

この辺り，実はちょっとからくりがあって，モデル審査のために，やったことないモデリングを先にやってオレオレアーキテクチャを作った結果，実装で現実を見せつけられ，たくさんコードとクラス図の修正が入ったから異様にコミットが増えたというお話です．ですが，このあたりの開発が一番プログラムとUMLモデリングを紐づけた開発してたなぁ～と思います．理由として，コード直して，動作テスト（ロギング）して，OKならコードをcommit&pushして，図に反映してcommit&pushしてみたいなのが爆速で行われていたので・・・この時に意識したのは，機能・修正ごとにブランチを切ることです．せっかく，クラス図でパーケージごとに分けて開発できるようにしたのに実装レベルでちゃんと切ってなかったらもったいないと思わないですか？僕はそう思ったので，機能・修正ごとにブランチを切りました．あと，開発でありそうな時間との戦いで，どの機能を実装するかしないかを考えるときに，クラス図などがあるととても助かりました．システムへの一要求をあきらめると，EV3への要求で必要のない場所をすべて省くことができたので，とにかく何か作らなきゃというよりは，今回はこれで事足りるな・・・みたいな開発ができます．詳細設計まで一応詰められると，捨てる機能を選ぶことができるので，開発期間短縮に役立ちました．

また，ちょっと話題が変わってTOPPERS/EV3RTの中には，リアルタイムOSのμITRONが入ってるんです．なので，普段の開発と全く違う経験が多く得られました．ちょっとした技術的まとめはここで述べてます．

このあたり組み込みシステム屋さんなら常識かもしれないんですが，僕の大学だとまず縁のない領域となっています．ただ，仕様書とかを読み進めていくと，リアルタイムに対応すべく考えられたアーキテクチャだなぁと感じることができました．特にタスク・優先度・周期ハンドラを重点に活用しています．この仕様書を読んでいて，構造と振る舞いのUMLを見て何となくやりたいことが分かるようになっただけでもETロボコン本気でやってよかったと思います．

実装面でつらかったのは，C/C++で実装するとき，型とメモリの気持ちを理解することです．つらい経験の一つとしてバイト数を数えたことです．正直やりたくないです．これをする理由としてメモリのスタック領域とヒープ領域という概念を理解する必要があります．ただ，これは情報系なら常識だよってそっと耳打ちされるので説明は省きます．問題はこの領域の使い方です．個人的な見解ですが，普段は大域(グローバル)変数をとると処理が負えなくなるから止めてほしいといわれます．ですが，組み込みシステムだとスタック領域があふれて予期せぬ動作を生むほうが怖い（デバックですぐ見つからない）ので，状態を管理する変数やLRコースなど既知ならなるべく大域変数として，ヒープ領域に置きます．そして，スタック領域にはなるべく変数を作らないつまり，局所（ローカル）変数は意外と少ない感じがします．この辺りに関して，全部計算するのはつらすぎたので，僕は結構大きくスタック領域をとってます．

ファイルロギングをするときにもやらかしをしていて，周期ハンドラ(for, while文みたいなもの)があるタスクの中でファイルオープンした時は，やばかったです・・・はじめは，なんですぐに落ちるんだろうから始まって，ファイルロギングのfopen()が周期ハンドラ内で定義されてて，動作を理解していかれたことしたなと思いました．20msecに一回ファイルがオープンされてクローズされないそれは落ちます．もちろんクローズしても意味がなさそうなことは伝わると思います．ファイルロギングでもう一つ，僕の作ったアーキテクチャだと，動作・判定モデルを一つのパターンとして登録してその配列をキューで処理していくのですが，パターンが呼ばれるたびにファイルオープンされ，パターン終わりにファイルが閉じられる・・・こんな動作をしています．ここに，fopenのmodeで"w+"or"rw"とかを書いてるとロギング終了後のファイルは最後のパターンのみ記録されて悲しい目にあいました．

今回の経験で，おひとり開発の限界を大いに知ったのですが，得たものはとても大きかったです．まず，コードとモデルは一緒に残そうです．相手に説明するときもこれがあるか，ないかで大きく変わつてきます．次にノリでプログラミングしないほうがいいです．僕は普段，Pythonを使うんですが，型を意識したプログラムしたことがなかったので，コンパイルを通すのにとても苦労してました．型とメモリのお気持ちとても大事です．最後に設計と実装を両方やってるとアルゴリズムを気にし始めるです．これは，設計の段階で，動作・判別モデルのパターン格納にはキュー使おうとか考えたりしていて，ほんと単純なアルゴリズムでも実戦で適用できるんだなぁと知れました．人の作ったアルゴリズムをコード内で発見するのはとても苦手なのですが，わかると意外とその人の設計意図がわかるかも．

ただ，おひとりアドバンスド開発は，ほんとに死にそうなぐらい忙しかったので来年はプライマリーにしようかと・・・



サポートしていただいた想いは，僕の興味と経験を通し，文章として還元していきたいと思います！