Transcript 2006年度 マイクロマウスPJふりかえり

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使用量
オーバー？