2006年度マイクロマウスPJふりかえり 2006/12/30 冨山隆志「ふりかえり」について PF(プロジェクト・ファシリテーション）の実践（プラクティス）の一つで、自己改善活動。ふりかえりの目的    行動可能な改善策を探し、試す勇気を得る。これまでの行動を思い返し、そこから新たな気づきを得る。やってみてうまく行った行動を定着させる。参考URL：  http://www.objectclub.jp/download/files/pf/Retros pectiveMeetingGuide.pdf 進め方 1. 2. 3. 4. 5. 6. 7. 8. 目的を決める思い返すうまく行った行動を確認する問題を洗い出す問題の原因を検討する改善策を考える試したいことを考える試したいことを絞り込むふりかえりの目的今回の失敗を次回に活かす。  悪かったところを洗い出す。  マネジメント、HW設計、SW設計   次のマウスで不具合発生を未然に防ぐ。大会までに開発が間に合うようになる。設計情報の再利用性を高める。 Keep（うまく行った行動）１マネジメント         「○○を××したことで△△になった」というスタイルで書く。新品組み電池を準備したことで、試走や本番でバッテリが十分持つようになった。安定化電源を入手したことで自動車用バッテリが不要になり、充電用機材が軽くなった。早期に大会参加申し込みを行うことで参加申し込みを忘れずに済んだ。早期に宿を手配することで、出場を諦めようとする心を防いだ。 SW要求仕様書を作成することで、実現しようとする機能や仕様が明確になった。 N区画前進コマンドの精度をカイゼンすることで、マウスが確実に迷路を走行できるようになった。試走用迷路を使ってデバッグすることで、制御プログラムが正しく動作していることを確認できるようになった。 mixiコミュニティで情報交換することにより、モチベーションをキープすることができた。 Keep(うまく行った行動）２ H/W        全長を短くすることにより、旋回の安全性を向上させた。アナログ壁面センサおよびモータドライブ回路の部品点数を削減することにより、基板上のスペースが広くなり、実装の手間も少なくなった。電池本数を減らしたことにより、軽量化を実現でき、さらに機体の小型化が可能になった。 ROM/RAM容量の大きいCPUを選定したことにより、ITRONの搭載が可能になり、プログラムサイズを気にせずコードを書けるようになった。ドットマトリクスLEDを搭載したことにより、制御プログラムの実行状態が見えるようになった。サウンダーを搭載したことにより、制御プログラム実行状態の表現方法が増えた。電圧表示用LEDを搭載したことにより、バッテリ電圧の低下がすぐに分かるようになった。 Keep(うまく行った行動）３ S/W          RTOSを導入したことにより、タスク内での時間管理が簡単になった。エラーログ収集を導入したことにより、不具合追跡が容易になった。確実な姿勢制御により安定してコース中央を走れるようになった。シミュレータを用いて経路計画アルゴリズムを検証することにより、実機への移植後も安心して経路計画アルゴリズムを使えるようになった。ナビゲーション部とカート部のアーキテクチャを確立できたことにより、経路情報からコマンド列を作れるようになり、走行コマンドの連続実行が可能になり、走行結果を地図に反映しやすくなった。壁発見時に減速停止を行うことにより、走行コマンドを連続実行しても壁に衝突しなくなった。半区画をつかった加減速を行うことにより、加減速制御の距離管理が簡単になった。メロディ制御、ドットマトリクスLED制御を追加したことにより、制御プログラムの内部状態表示が容易になった。重要な部分はアルゴリズムの設計を行ってから実装した。 Problem（問題点）マネジメント     開発スケジュールの遅れがコントロールを外れてしまった。大会までに余裕を持った開発ができていない。 SW要求仕様書を書き始めるのが遅かった。大会前にゲームで遊んでいるなど、現実逃避に無駄な時間を使ってしまった。 Problem（問題点） H/W               ログを取るにはRAMの容量が少なかった。 RAMの容量が少なく、リモートデバッグできなかった。モータ駆動電流をOFFする仕組みを盛り込み忘れた。電源ON時にはモータ駆動電流OFFになるべきであった。設計時にモータに流れる電流を計算していなかった。モータドライバに電流制限抵抗を付け忘れたため、電流が足らずガクガクしてしまった。ドットマトリクスLEDの駆動電流が足りない。板金の曲げ精度がうまく出ていない。電池を固定する仕組みが設計に入っていない。アナログ壁面センサの近距離特性が出ていない。直進性が悪く若干右に流れて走行してしまう。タクトスイッチの数が足らず、後で追加することになった。ドットマトリクスLEDで配線を長い距離引き回した。軸への締め付けが強いため、ホイールの取り外しができない。 Problem（問題点） S/W                ステッピングモータ制御の仕方が下手。パルス数で回転量を制御できはず。 RAM不足により、stackサイズをオーバーしてしまう。 RTOSのスタック設定をスタック消費量の見積もりがいい加減なまま変更してしまった。メロディを作る手間が大変。使いまわしの利く汎用的なアーキテクチャを構築できなかった。デバイスの制御がOSに依存しているので、移植しずらい。コマンド入力を諦めて、メニュー操作にせざるを得なかった。ソースコードに十分なコメント文が付いていない。大会までに要求仕様書にある仕様を実装できなかった。設計に関するドキュメントがまとまっていない。十分なテストができていない。シミュレーションデバッガがほとんど役に立たない。エラーログの収集し忘れがあり、エラー発生場所の特定が遅れた。エラーログにエラー捕捉場所（コード行番号）と関数名が入るのであれば、ドメインごとにエラーコードを分ける必要は無い。シリアル送信タスクにprintf系のものを追い出すつもりが、結局追い出さなかった。問題点の原因を分析するマネジメント  開発スケジュールがコントロールを外れた原因  PCからコマンドを送る方式に固執して、メニュー方式に切り替えるのが遅れた。  5/30にはハードウェアがほぼ出来上がっていたのに、6,7,8月は何もしていなかった。  短期の計画は立てていないし、スケジュールのコントロールも行っていない。  大会前にゲームで遊んでいるなど、現実逃避に無駄な時間を使ってしまった。  ちょっとした技術的な壁があったり、意思決定を必要とするときに、そこから逃げてしまっている。迷っていて決められない。  壁や問題点を、他人に説明できるほど明確に定義できていない。  「まだ大丈夫だろう」という甘えがあるのか？  「いつまでに」「どこまでやるのか」が一口サイズにまで落とせていない。問題点の原因を分析する（２） H/W  ログを取るにはRAMの容量が少なかった。RAMの容量が少なく、リモートデバッグできなかった。  H/W仕様を決める段階では、ログやリモートデバッグにどれだけのRAM容量が必要なのか考慮していなかった。  設計時にモータに流れる電流を計算していなかった。モータドライバに電流制限抵抗を付け忘れたため、電流が足らずガクガクしてしまった。  実験基板で取り付けなかった電流制限抵抗や enable/disableスイッチが、本番用の基板設計で漏れてしまった。  モータに流れる電流を見積もっておらず、積んでいる電池でその電流を賄えるかどうかも分からなかった。問題点の原因を分析する（３） S/W  ステッピングモータ制御の仕方が下手。パルス数で回転量を制御できるはず。  ステッピングモータをパルス数で管理したことが無かった。  速度テーブルで管理してもそれなりの精度が出ると思っていた。（実際出ていることは出ている。）  設計時、モータクラスを一般化しすぎている。DCモータとステッパでは使い方が異なる。  十分なテストができていない。  大会当日まで実装をしていたので、テストケースを作る余裕が無かった。  CPUにプログラムを書き込んだ状態で、どのようにテストを行うか決まっていない。  ドメイン単位の外部仕様が明確にならなかったため、ドメイン単位でのテストができなかった。改善策（１）マネジメント     リスク回避策、バックアップ策を含めた中期計画を立てる。支部定例会をマイルストーンとして、支部定例会でフルサイズ迷路を走れることを目指す。問題点や壁にぶつかったら、何が問題かを文章に起こす。Blogなどに書いてしまう。作業開始前に、ゲームやTVのリモコンを封印する。改善策（２） H/W   十分な容量の外部RAMを使用する。設計時に消費電力を見積もる。 S/W  実験用基板でステッパをパルス数で駆動する制御を実験する。テスト方法をどうするか？ Try（試したいこと）マネジメント  開発プロセスの安定化 H/W  外部RAM（SRAM/DRAM）を使用する  H8/3069F(内蔵SRAM16KB+拡張2MB) S/W  RTOSを外す  デバッガで追いづらいから  C++によるオブジェクト指向設計  GCC/G++への乗り換え  開発環境乗り換え  Eclipse CDT  ソースコード静的解析ツールを用いたリファクタリング  Splintなど付録ソフトウェアメトリクス分析ソフトウェアメトリクス分析ソースコードの論理行数（論理LOC）ヘッダファイルソースファイル合計ファイル数 22 20 42 LOC 687 3064 3751 LOC/ファイルの最大、平均、最小最大平均ヘッダファイル 92 31 ソースファイル 468 153 （参考）Basic MouseのLOC ファイル数ヘッダファイル 15 ソースファイル 15 合計 30 LOC 444 1807 2251 LOC/ファイルの最大、平均、最小最大平均ヘッダファイル 57 30 ソースファイル 315 120 LOC/ファイル 31 153 89 最小 3 27 LOC/ファイル 30 120 75 最小 10 13 ヘッダファイルは平均30LOC ソースファイルは平均150LOC ソフトウェアメトリクス分析ソースファイルLOCの度数分布と累積度数 12 120.0% 10 120.0% 10 100.0% 8 100.0% 8 80.0% 6 60.0% 頻度頻度ヘッダファイルLOCの度数分布と累積度数 80.0% 6 60.0% 4 4 40.0% 2 20.0% 2 20.0% 0 .0% 0 .0% 20 40 60 LOC 100 40.0% 100 200 300 LOC 500 ヘッダファイルもソースファイルも、半分近くはLOCが小さいファイル。 400 ROM/RAM使用量 ROM使用量約６７KB RAM使用量オーバー？