能代を終えて(反省会資料より)

以下サークル内部の反省会資料として書いたものです。このまま書きっぱなしなのもあれなので上げておきます。

大会、及び準備期間を通して
・良かった点
・開発段階からの反省点
・能代当日の反省点
を順に列挙していきます。

良かった点は
先代から引き継いだ機体構成や思想を再現できて、ロステクを回避できたと言えること
(能代後にまたロステクがあってはいけないので引き継ぎちゃんとやります)
プロジェクトを完遂できる可能性があると言えるくらいまでプロジェクトを継続できたことです。

開発段階からの反省点は
1、モジュール等の品質評価をしていなかったこと
２、プログラムベース制御
３、インタプリタ型言語の採用
４、コード保守にかかるコストがかなり上昇していた
５、個人PCとスマホの通信系統への採用、運用者が属人化していて単一障害点になっていたこと
上記の五点の弱点を抱えたまま能代に出場してた

能代当日の反省点は
投下毎に(カッコ内は対応する反省点)
・一回目はドローンの上下動に気圧センサの閾値が足りず開放ー自由落下。着地後防水、保護処理がされてない基盤が引きずられ破壊(1)
・二回目通信遮断から、テレメトリから原因不明、ログを常に取らないことで、キャリア開放時の電圧降下により再起動がかかったものと判断し修正(2)
・三回目、エラー発生後の退避先でエラー発生(3､4)

今後の展望(すぐに加えられる改良点)は
IME920等の通信モジュールの追加
キャリア開放判定をフォトレジスタによる判定に
です。

それぞれについて詳しく解説していくと、
モジュール等の品質評価とは、
センサーがどれくらいの精度と頻度でデータを取る必要があるか決定せずに、取れただけで動作確認をして、投下判定や移動時の方向の判定の基準(閾値)をプログラム担当(高橋)の当日の匙加減で決めていたこと。
動作確認をしてもあとから制御にデータを使用しようとした時に、センサーが満足の行く精度(品質)のデータを出してくれなかったため、センサー自体を搭載はするが使わないという判断をして、開発段階から冗長性を消費していったこと。
より、必要な精度と頻度(実行時間)を文書化して、またチューニング(精度補正に必要な一連の動作)もできれば自動化しておくと、運用者毎に閾値が変わるとか開発が進みすぎて戻れなくなったあとにセンサーをオフにしてデッドウェイトにするって判断をしなくて済むと思います。

プログラムベースド制御とは、
プログラムが必要に応じてセンサーのデータを取得する方式で、センサーのデータを取得して処理中に異常が起きた場合何のデータにより異常が起きたか分からず、実験の意義が薄れることから、
ログベース制御、タイマ割り込みによる定期的なデータ取得とログ化をした上でそこからプログラムがデータを取得し処理する形式に変更する必要があるってことです。

インタプリタ型言語の採用とは、
プログラムの実行と同時にコンパイルする方式だと遅くなること、プログラムベース制御と組み合わさると文法エラーの検出(動作試験)にシステム全体の”実環境での実行＝EtE”が必要になるので、コンパイル型言語(CPythonとかもあり)にする必要があることです。コード資源が使えなくて開発が大変になると思いますがやっておいたほうがより良いです。

あと、コード保守のコストの増大ですが、制御プログラムにEtEでの改善点、改良点を全て盛り込んだ結果、自分でもプログラムが何書いてあるのか読むのが困難になって、上記の動作試験を繰り返さないようにするために敢えて複雑なままプログラムを放置しておくことがありました(3のエラーの遠因)。
定期的にプログラムを俯瞰的な視点から見て、分割したり共有できるプログラムは積極的に分割し、補正や計算に必要なプログラムは可能な限り別の関数として分割すべきです。
一つのプログラムからあまりに多くのプログラムを呼び出すべきではなく、ある程度のところでまとめておく、こういったコード保守を考慮したソフトウェア設計(機能分割)をしていかないと、改良をすすめるにつれコードの大きさと改良の影響範囲が増大し、それに起因する不具合の発生が起こり、進捗が加速度的に遅延していくってことが起こります。

最後に、運用者が単一障害点になってた点ですが、PC、スマホ、自分のどれかが故障していたら能代のプロジェクトは終わっていました。当日目に見えた問題は起こりませんでしたが、属人化した開発環境、プログラムのソースコードにより、開発段階で参加できる人数が限られてしまい、特に実験直前直後に投入できたリソースが結果的に少なくなったことが問題解決の障害(具体例、一日目夜の改良が個人的な判断によったものであったこと)になっていたと思われます。PCやスマホは部のものにして代替品を用意するか、ラズパイ単体のスイッチを入れれば動作するようにしておくほうが良かったです。あと、充電が切れかけるというヒヤリハットがあったので機体本体含めスタンバイ(待機状態)が一日出来るかの考慮はしたほうが良さそうです。

あと今後の展望の難しい方ですが、ウォッチドッグタイマー(マイコンのプログラムが暴走・停止していないかを監視するタイマ)の機能を担えるサブマイコン(Arduino等)の搭載が必要かと考えます(できれば電源独立)
ラズパイとArduinoで相互に異常が起きてないか監視するのと、Arduinoにモーターやサーボの制御を担わせたほうが故障リスク面でも開発難度面でも良いと思われます。