Cansatプログラミングを一通りしてみた

プログラミングなど書いてますが、要約するとコードばかり書いて自己満足してなくてちゃんと書類書こう、そうしないと後で自分が見返しても理解が出来ないものになって問題の修正ができないよってことです。

　・そもそもCansatランバック部門って何？
　・当初の開発方針(とEtEまでの進捗)
　・進捗の遅れと増改築が繰り返されたコード
　・保守性ゼロの完成品
　・これらを踏まえた反省点や改善点

・そもそもCansatランバック部門って何？

 　Cansatランバック部門とは、100mぐらいの高さからロボットを落として空中及び陸上で制御して目標地点に向かわせるっていう競技です。
(下は実機の画像)

15人くらいいる大所帯だったので、運営とその下の回収と機体と電装(詳しくは下記参照)に役割分担して上の機体を作ってました。

未経験者がほとんど、関連分野に関わったことがある人が少数名(把握してない)で、電装班は主力のメンバーのうち五人中三人が未経験者でした。

・当初の開発方針

　4月始めから開発を開始し、終了目標は7月でした。
未経験者がほとんどだったので、初期は進捗を勉強会形式で全体で共有して同じことをできるようにしようとしてました。ただ、いざ作業を始めたら自分もわからないことだらけだったので、基板とソフトウェアに分割して、ソフトウェア三名、基板二名に分かれました。
活動日は休日(土日)とし、毎週末に進捗を持ち寄る＋テストで作業を進めていきました。

設計コンセプト(4月版)とシステム図(7月版)(設計コンセプトをもとにプログラムの作成をし、システム図をもとにピン割当などを決めて基板班にお願いして基板を作ってもらっていました。)

　ソフトウェアは計測部のセンサーとコンピューター(Raspberry Pi Zero WH)を一つずつ対応させて、センサーごとに目的のデータ(GPSであれば位置座標)を”一回”取得できるプログラムを作っていき、それをメイン(BOSSというらしい)プログラムで統合して制御する方針で開発していました。
(上図は当初方針)

4月終了時点でGPSデータ取得及びGPSデータを使った誘導プログラムを書き終えました。(上図)この時点で想定されてなかった構造が追加されてることが分かります。(座標データのストック✕２)

(※ここから計画に無かったものを破線で表しています。)
　５月はGW休暇(~5/10)と緊急事態発令(5/15)が連続し、後半から活動をし、4月に作成したプログラムのテストをリモートで配信しながら行いました。このテストでプログラムからの値が時々おかしくなることが判明したので修正に時間を使いました。
また、他のプロジェクトからお借りした(？)気温気圧データ取得プログラムを用いて、競技開始と落下が始まったタイミングを検知し、地上についた時点で機体を保護する箱から脱出するプログラムを作りました。

　6月前半は通信実験(GPSダウンリンク試験と長距離通信実験)の計画書の作成に時間を割きました。GPSダウンリンクというのはローバーを見失ったとき通信機からGPSで取得した座標を頼りに捜索するため、それが送られてくるかどうかの試験で、長距離通信実験というのはそれがより長距離でも可能かを調べる試験です。
　6月後半は九軸センサーからのデータ取得プログラムを作成しました。また、この頃から全く初心者だったプログラムのメンバーの一人が活躍してくれるようになり、ToFセンサーとカメラの画像認識を任せました。ToFセンサーはセンサーのデータシートが非公開で、拾ってきたプログラムで動作を試みたものの既存の環境と干渉してi2cで動作させているプログラムが不安定になり、クリーンインストールをすることになり諦めました。またこの頃から各種ライブラリ(モジュール)をインストールする手順が複雑になってきたため、ラズパイのheadless環境構築と自動インストールについて整理し、それらの手順をまとめた書類を作りました。
　また、週末に2、3時間集中的に開発する方式では間に合わなくなってきたため平日を使い始めたのもこの頃です。

　7月に入り九軸センサーOpenCVとraspi-cameraを用いた赤コーンと背景の境界を認識するプログラムをメンバーに作成してもらい、BBMを用いた全センサーの稼働試験を完了させ、プログラムの開発を完了させたつもりでいました。

・進捗の遅れと増改築が繰り返されたコード

7/18-8/19までのEtE期間について

　感の良い方ならお気づきかもしれませんが、三ヶ月かけた開発において二つの問題がこの時点で発生していました。
　まず１つは本番環境を一切使用しなかったことです。7/17にその週に到着した基板の組み立てが終わり、やっと機体班が作った機体を動かして実環境での試験ができるようになりました。またセンサー値を取得してそれをBossプログラムから呼び出したことで満足しており、実際の環境を想定したプログラムの動作テストをしていませんでした。
　これらにより、誘導プログラムの挙動が不完全で修正に時間がかかったり、センサー値が動作に必要な精度が出ずカメラ以外に誘導に必要なデータが得られない状況が起こり、その度に試験の目標が達成できず再試験を繰り返したり、度重なる試験での破損が起こりスケジュールが遅延しました。以下詳細に説明します。
　EtEで発生したトラブルは時系列順に以下の通りになります。
・モーター動作プログラムを実行しようとしたらライブラリ(モジュール)同士の干渉が起こり、修正が大変だったためだったため新しく書くことになった
・Raspberry Pi Zero WHが投下後、発熱し起動しない状態になった、プログラムを書き込んだSD諸共破損した(通称焼きパイ)
・予備部品がなくて破損が起こった際に試験が次の日程まで遅延した
・センサー値が誘導プログラムが必要としていた精度が出ず、書き換えが必要になった。
・センサーが動作不良を起こした場合全体のプログラムが止まりミッション継続ができなくなるため、エラーが起こった際の例外処理が必要だったが書いてなかった
・動作不良を起こしたセンサーが多すぎたため誘導に使えるデータがカメラからのものしかなくなった。
　また電装班プログラムの問題以外にも他の班の改善点がEtE期間に洗い出されていったので、それらの改善のためにも複数回試験を前提にしたほうが良かったという感じはありました。

・保守性ゼロの完成品

　8/19、当初の予定から一ヶ月遅れで完全なEtEが成功したのですが、上記の諸問題解決するため、動作不良を起こしたセンサー値を補正するプログラム、他センサーからのデータを使い補正するプログラムをBossモジュールに直書きした結果プログラムの構造がめちゃくちゃになりあとから改良と修正を加えると別のところで不具合が起こるようになり、動作を検証するための範囲が大きくなりすぎて動作の確実性が損なわれました。
　具体的にいうと、下記画像がコードの一部で、上がEtE期間開始直後の7/23のもの、下がEtE試験が完了した時点のコードで、黄色の矢印のmain()関数の行数が3倍近くになっているのに全体の関数が増えておらず、機能分割等を心がけずただベタ書きしたことがわかります。

他にもどこで使われているのかわからない関数(wi_wiringpi_setup())や役割が被っている関数(m_moveとETM_enabletime_move、File_libとt_Writefile及びu_OPENfile)がありました。
　そして問題だったのが、EtE後ワクチン接種の関係で実家と大学をニ往復したことで、一ヶ月位プログラムを作ったまま放置した結果どういう糸デコプログラムを書いたか忘れてしまい、これらを統合したり削除する為にmain関数の記述を変更することができなくなっていました。

・これらを踏まえた反省点や改善点

　ソフトウェア設計(コンセプト)の時点で相互補正や、センサーからのデータの加工を想定しておらず、その設計の枠組みにこだわり続けたけこと、また、機能分割よりコーディングを優先して一つのモジュールを肥大化させ続けたことにより、メインプログラムがスパゲティコード化したことが原因だと思われます。
　また、後知恵なのですが、設計思想がプログラムベースではなくログベースであったほうが良かったと思っています。
　プログラムベースは必要なときに必要なデータを呼び出すものであり、ログベースは定期的にセンサーを呼び出しデータを蓄積した上でそれをプログラムで利用するものであり、
・データを呼び出して制御に必要な計算をしているときにエラーが出てもその原因をログから探れる
・ログの値が一制御周期ごとにしか出力されず少なくなりがちなデータ量を大幅に増やせる
・ログベースであるとデータ形式を定める段階が先に来やすいためそこを接点にして機能分割がしやすい
ことが利点としてあげられます。
そして、main関数をスパゲティコード化する前に分割できなかったこと、作成直後にどういう構造をしているかを文書化しなかったりコメントしなかったため不可侵の領域ができてしまい、依存先の他のモジュールの整理もできなくなったことが問題でした。

最後に、やっぱり最初に書いたとおり、コードばかり書いて自己満足してなくてちゃんと書類書こう、そうしないと後で自分が見返しても理解が出来ないものになって問題の修正ができないよってことですね。
　この記事自体ソフトウェア設計の考え方を知り始めた9/22から書き始めたものなのですが、モチベが続かなかったり大会を挟んだりして最後の時点で11/10、約二ヶ月の期間に渡り執筆しており途中から構造が変わったり書き方が変わっています。それでも書き終えられたのは最初の見出しがあってそこを柔軟に修正しながら、見出しー文章というふうにうまく情報の抽象度を下げていきながら、基本構造である見出しを修正していけたことが有ると思います。(あとプログラムと違ってエラーは出ないし読み手が勝手に補正してくれることもあります)
　詳細を詰めるコーディングも勿論大事ですが、時には手を休めて全体を見渡してみてはいかがでしょうか。そんな事を書いて最後の締めにさせていただきます。