2006年度 マイクロマウスPJふりかえり 2006/12/30 冨山 隆志.

Slides:



Advertisements
Similar presentations
1 情報基礎 A 第 9 週 プログラミング入門 VBA の基本文法 1 準備・変数・データの入出力 徳山 豪・全 眞嬉 東北大学情報科学研究科 システム情報科学専攻 情報システム評価学分野.
Advertisements

実践ロボットプログラミング LEGO Mindstorms NXT で目指せロボコン! WEB : 著者:藤吉弘亘,藤井隆司,鈴木裕利,石井成郎 :
マイクロマウス ソフトウェア要求仕様書 第2.2版 2006年12月17日 冨山 隆志
Linuxを組み込んだマイコンによる 遠隔監視システムの開発
RoboCarTM カーロボティクス・プラットフォーム 電気自動車 充実した環境認識プラットフォーム スケールモデル ユーザアプリ
本日のスケジュール 14:45~15:30 テキストの講義 15:30~16:15 設計レビュー 16:15~16:30 休憩
プログラマのレベルアップ.
Chapter11-4(前半) 加藤健.
OJT研修 「テスト実施、テスト設計の技術習得」 日時: 8月22日(月)  場所: 本社5階.
USB2.0対応PICマイコンによる データ取得システムの開発
第6回 Flashによるゲームの作成 04A2029           古賀慎也.
e-nuvo BMS リチウムオン電池実験キット 特徴 用途 仕様 価格(税別)
基板切削 CNC切削チェックリスト 切削前準備 切削開始直前、切削中 緊急停止時 対象基板名: メモ: 機械原点 (Ref home)
FPGAを用いたMG3用 インターフェース回路の解説
CHAPTER1 UMLとオブジェクト指向の基本概念(2)
第5回 CPUの役割と仕組み3 割り込み、パイプライン、並列処理
CSP記述によるモデル設計と ツールによる検証
PIC制御による赤外線障害物 自動回避走行車
オープンソフトウェア利用促進事業 第3回OSSモデルカリキュラム導入実証
リファクタリングのための 変更波及解析を利用した テスト支援ツールの提案
   電気回路について学習する。        (センサを使用した電気回路) 〇 めあて トランジスタを使った、電気回路を つくろう。
ソフトウェア工学 第五回 知能情報学部 新田直也.
ステッピングモータを用いた 移動ロボットの制御
第6回 よく使われる組合せ回路 瀬戸 重要な組合せ回路を理解し、設計できるようにする 7セグディスプレイ用デコーダ 加算回路・減算回路
・コンピュータのアナログデータの 扱いについて ・制御
Cartサブシステム仕様.
LEGO MINDSTORMの車両の PCによる遠隔操縦
マイコンによるLEDの点灯制御 T22R003 川原 岳斗.
XP Extreme Programming.
マイクロマウス ソフトウェア要求仕様書 初版 2006年10月28日 冨山 隆志
理化学研究所 重イオン核物理研究室 馬場 秀忠
Ibaraki Univ. Dept of Electrical & Electronic Eng.
2010年度 春季成果発表会 岡本 拓也 2010年5月14日 デジタルビジョンソリューション株式会社 新横浜支店 技術部.
ソフトウェア設計検証 研究室の紹介 知能情報学部 准教授 新田直也.
オープンソース開発支援のための ソースコード及びメールの履歴対応表示システム
SiTCP-VME変換モジュールの開発 KEK 物構研:中性子 佐藤節夫.
ロボットの協調動作の研究: マップ作成とマップ情報を利用した行動計画
Design Wave Magazine 2008年5月号附録基板を使った お手軽加速度センサプログラミング
バイトコードを単位とするJavaスライスシステムの試作
Ibaraki Univ. Dept of Electrical & Electronic Eng.
電動3輪車製作実習装置 2軸駆動電動車両の製作実習装置 KENTAC 5310B 概要 製品構成 仕 様 ■概要 ①電動3輪車 車体本体
軽量な仮想マシンを用いたIoT機器の安全な監視
2003/04/14(Mon) 15:00- 早稲田大学マイクロマウスクラブ(WMMC) 4年 原 耕司
先週の復習: CPU が働く仕組み コンピュータの構造 pp 制御装置+演算装置+レジスタ 制御装置がなければ電卓と同様
移動ロボットの速度制御 桐蔭横浜大学 箱木研究室 T20R001 あべ松雄太.
VMが利用可能なCPU数の変化に対応した 並列アプリケーション実行の最適化
UMLの概要とオブジェクト指向の基本概念
Ibaraki Univ. Dept of Electrical & Electronic Eng.
本時の目標 電気機器の構造と回路図を用いた表し方を理解する。
平成22年度 機械創成工学実習III 最終競技会 25班
明星大学 情報学科 2012年度前期     情報技術Ⅰ   第1回
第1章 いよいよプログラミング!! ~文章の表示 printf~
★C++/オブジェクト指向実践企画★ Othelloゲーム作成
マイグレーションを支援する分散集合オブジェクト
Handel-Cを用いた パックマンの設計
第4回 メモリ管理 主記憶(メインメモリ)の管理 固定区画方式と可変区画方式 空き領域の管理 スワッピング.
創造実習 (自由課題成果発表会) 障害物回避ロボット 10S6001 青森 太郎 10S6002 弘前 弘子.
クローン検出ツールを用いた ソフトウェアシステムの類似度調査
マイクロマウス ソフトウェア要求仕様書 第2版 2006年11月8日 冨山 隆志
システム玩具を 応用した環境計測システムの構築
設計工学 内容 目的 ★もの作りのための設計 ★実際の現場で役立つ設計 ★機械設計や機械作りの楽しさを知る。 ★工学的な理屈を考える。
RoBoCoN2000のアイデア Copyright (C) 1999 Yosai Software Institute
線沿走車 (ライントレーサー).
平成22年度 機械創成工学実習III 最終競技会 25班
プログラムの一時停止時に 将来の実行情報を提供するデバッガ
知識ベースの試作計画 ●●●研究所 ●●●技術部 稲本□□ 1997年1月.
桐蔭横浜大学工学部ロボット工学科 T20R022 山下 晃
圧電素子を用いた 高エネルギー素粒子実験用小型電源の開発
明星大学 情報学科 2014年度前期     情報技術Ⅰ   第1回
Ibaraki Univ. Dept of Electrical & Electronic Eng.
Presentation transcript:

2006年度 マイクロマウスPJふりかえり 2006/12/30 冨山 隆志

「ふりかえり」について PF(プロジェクト・ファシリテーション)の実践(プラクティス)の一つで、自己改善活動。 ふりかえりの目的 行動可能な改善策を探し、試す勇気を得る。 これまでの行動を思い返し、そこから新たな気づきを得る。 やってみてうまく行った行動を定着させる。 参考URL: http://www.objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf

進め方 目的を決める 思い返す うまく行った行動を確認する 問題を洗い出す 問題の原因を検討する 改善策を考える 試したいことを考える 試したいことを絞り込む

ふりかえりの目的 今回の失敗を次回に活かす。 設計情報の再利用性を高める。 悪かったところを洗い出す。 次のマウスで不具合発生を未然に防ぐ。 マネジメント、HW設計、SW設計 次のマウスで不具合発生を未然に防ぐ。 大会までに開発が間に合うようになる。 設計情報の再利用性を高める。

「○○を××したことで△△になった」というスタイルで書く。 Keep(うまく行った行動)1 「○○を××したことで△△になった」というスタイルで書く。 マネジメント 新品組み電池を準備したことで、試走や本番でバッテリが十分持つようになった。 安定化電源を入手したことで自動車用バッテリが不要になり、充電用機材が軽くなった。 早期に大会参加申し込みを行うことで参加申し込みを忘れずに済んだ。 早期に宿を手配することで、出場を諦めようとする心を防いだ。 SW要求仕様書を作成することで、実現しようとする機能や仕様が明確になった。 N区画前進コマンドの精度をカイゼンすることで、マウスが確実に迷路を走行できるようになった。 試走用迷路を使ってデバッグすることで、制御プログラムが正しく動作していることを確認できるようになった。 mixiコミュニティで情報交換することにより、モチベーションをキープすることができた。

Keep(うまく行った行動)2 H/W 全長を短くすることにより、旋回の安全性を向上させた。 アナログ壁面センサおよびモータドライブ回路の部品点数を削減することにより、基板上のスペースが広くなり、実装の手間も少なくなった。 電池本数を減らしたことにより、軽量化を実現でき、さらに機体の小型化が可能になった。 ROM/RAM容量の大きいCPUを選定したことにより、ITRONの搭載が可能になり、プログラムサイズを気にせずコードを書けるようになった。 ドットマトリクスLEDを搭載したことにより、制御プログラムの実行状態が見えるようになった。 サウンダーを搭載したことにより、制御プログラム実行状態の表現方法が増えた。 電圧表示用LEDを搭載したことにより、バッテリ電圧の低下がすぐに分かるようになった。

Keep(うまく行った行動)3 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月は何もしていなかった。 短期の計画は立てていないし、スケジュールのコントロールも行っていない。 大会前にゲームで遊んでいるなど、現実逃避に無駄な時間を使ってしまった。 ちょっとした技術的な壁があったり、意思決定を必要とするときに、そこから逃げてしまっている。迷っていて決められない。 壁や問題点を、他人に説明できるほど明確に定義できていない。 「まだ大丈夫だろう」という甘えがあるのか? 「いつまでに」「どこまでやるのか」が一口サイズにまで落とせていない。

問題点の原因を分析する(2) H/W ログを取るにはRAMの容量が少なかった。RAMの容量が少なく、リモートデバッグできなかった。 設計時にモータに流れる電流を計算していなかった。モータドライバに電流制限抵抗を付け忘れたため、電流が足らずガクガクしてしまった。 実験基板で取り付けなかった電流制限抵抗やenable/disableスイッチが、本番用の基板設計で漏れてしまった。 モータに流れる電流を見積もっておらず、積んでいる電池でその電流を賄えるかどうかも分からなかった。

問題点の原因を分析する(3) ステッピングモータ制御の仕方が下手。パルス数で回転量を制御できるはず。 十分なテストができていない。 S/W ステッピングモータをパルス数で管理したことが無かった。 速度テーブルで管理してもそれなりの精度が出ると思っていた。(実際出ていることは出ている。) 設計時、モータクラスを一般化しすぎている。DCモータとステッパでは使い方が異なる。 十分なテストができていない。 大会当日まで実装をしていたので、テストケースを作る余裕が無かった。 CPUにプログラムを書き込んだ状態で、どのようにテストを行うか決まっていない。 ドメイン単位の外部仕様が明確にならなかったため、ドメイン単位でのテストができなかった。

改善策(1) マネジメント リスク回避策、バックアップ策を含めた中期計画を立てる。 支部定例会をマイルストーンとして、支部定例会でフルサイズ迷路を走れることを目指す。 問題点や壁にぶつかったら、何が問題かを文章に起こす。Blogなどに書いてしまう。 作業開始前に、ゲームやTVのリモコンを封印する。

改善策(2) H/W S/W 十分な容量の外部RAMを使用する。 設計時に消費電力を見積もる。 実験用基板でステッパをパルス数で駆動する制御を実験する。 テスト方法をどうするか?

Try(試したいこと) マネジメント H/W S/W 開発プロセスの安定化 外部RAM(SRAM/DRAM)を使用する RTOSを外す H8/3069F(内蔵SRAM16KB+拡張2MB) S/W RTOSを外す デバッガで追いづらいから C++によるオブジェクト指向設計 GCC/G++への乗り換え 開発環境乗り換え Eclipse CDT ソースコード静的解析ツールを用いたリファクタリング Splintなど

付録 ソフトウェアメトリクス分析

ソフトウェアメトリクス分析 ソースコードの論理行数(論理LOC) ヘッダファイルは平均30LOC ソースファイルは平均150LOC

ソフトウェアメトリクス分析 ヘッダファイルもソースファイルも、半分近くはLOCが小さいファイル。

ROM/RAM使用量 ROM使用量 約67KB RAM使用量 オーバー?