MDDを用いた組込みシステム開発の実践

MDD を用いた組込みシステム開発の実践
指導清水尚彦教授
東海大学電子情報学部コミュニケーション工学科
2ADT1211 水野嘉久
平成 18 年 2 月 6 日
1
3.8.2
シナリオ . . . . . . . . . . . . .
19
3.8.3
シーケンス図 . . . . . . . . . .
21
3.8.4
ステートマシン図 . . . . . . . .
22
3.8.5
クラス図 . . . . . . . . . . . . .
22
. . . . . . . . . .
24
3.10 飛行情報の受信 . . . . . . . . . . . . .
24
3.10.1 方向:UDP 通信 . . . . . . . . .
24
3.10.2 位置:シリアル通信 . . . . . . .
27
3.11 プロジェクト管理の考察 . . . . . . . .
29
3.11.1 開発側の考察 . . . . . . . . . .
29
3.11.2 管理側の考察 . . . . . . . . . .
29
3.12 コンテスト結果を踏まえた考察 . . . .
29
目次
1
はじめに
4
2
MDA/MDD
4
2.1
MDA 概要 . . . . . . . . . . . . . . . .
4
2.1.1
モデルの区分け . . . . . . . . .
5
2.1.2
マッピング . . . . . . . . . . .
5
2.2
3
組込み MDD
. . . . . . . . . . . . . .
6
2.2.1
組込みシステム . . . . . . . . .
6
2.2.2
MDD での UML2.0 の活用 . . .
6
2.2.3
組込み MDD の問題 . . . . . .
6
3.9
提供システムの利用
MDD ロボットチャレンジ
7
3.12.1 モデル . . . . . . . . . . . . . .
29
3.1
チャレンジの概要 . . . . . . . . . . . .
7
3.12.2 飛行結果 . . . . . . . . . . . . .
30
3.1.1
飛行船制御システムの概要 . . .
8
3.13 ハードウェアの考察
. . . . . . . . . .
30
3.1.2
提供 API . . . . . . . . . . . .
8
3.14 MDD という開発手法についての考察 .
30
. . . . . . . . . . . . . . .
9
3.14.1 モデルの利用 . . . . . . . . . .
30
3.14.2 開発手法 . . . . . . . . . . . . .
30
3.15 スケジュール . . . . . . . . . . . . . .
31
まとめ
31
3.2
開発の前に
3.2.1
ロボットチャレンジ最終目標と
の比較 . . . . . . . . . . . . . .
9
開発システムの機能分割 . . . .
9
3.3
プロジェクト管理 . . . . . . . . . . . .
10
3.4
ハードウェアの設計と制御の戦略 . . .
11
3.4.1
ゴンドラの設計 . . . . . . . . .
11
A.1 超音波送信機 . . . . . . . . . . . . . .
33
3.4.2
飛行戦略 . . . . . . . . . . . . .
13
3.2.2
4
A 回路基礎:超音波送受信機
33
A.1.1 超音波センサの仕組み . . . . .
33
3.5
ソフトウェアモデル
. . . . . . . . . .
15
A.1.2 タイマー IC . . . . . . . . . . .
33
3.6
全体 . . . . . . . . . . . . . . . . . . .
15
A.1.3 Hex Invertar HD74LS04 . .
34
3.6.1
概念シナリオ . . . . . . . . . .
15
A.1.4 電圧レベルコンバータ . . . . .
35
3.6.2
概念図 . . . . . . . . . . . . . .
16
A.2 超音波受信機 . . . . . . . . . . . . . .
35
飛行船 . . . . . . . . . . . . . . . . . .
16
A.2.1 オペアンプ . . . . . . . . . . .
35
3.7.1
オブジェクト図 . . . . . . . . .
17
A.2.2 フォトカプラ . . . . . . . . . .
36
3.7.2
シナリオ . . . . . . . . . . . . .
17
A.3 距離の測定 . . . . . . . . . . . . . . .
37
3.7.3
クラス図 . . . . . . . . . . . . .
19
A.4 電源回路 . . . . . . . . . . . . . . . . .
37
3.7.4
シーケンス図 . . . . . . . . . .
19
A.4.1 3 端子レギュレータ . . . . . . .
37
3.7.5
ステートマシン図 . . . . . . . .
19
基地局 . . . . . . . . . . . . . . . . . .
19
3.8.1
19
3.7
3.8
オブジェクト図 . . . . . . . . .
2
B 回路基礎:赤外線送受信機
39
B.1 赤外線とは . . . . . . . . . . . . . . .
39
B.2 赤外線センサ回路 . . . . . . . . . . . .
39
B.2.1 赤外線受信モジュール . . . . .
39
B.2.2 2 段タイマー IC . . . . . . . . .
40
B.2.3 トランジスタ 2SC1815 . . . . .
41
B.2.4 赤外 LED . . . . . . . . . . . .
41
B.3 赤外線受信回路 . . . . . . . . . . . . .
42
B.4 LED での通信 . . . . . . . . . . . . . .
42
3
1
はじめに
F;
<+
719D:
近年ソフトウェア開発において、モデルを用いた開
発が注目されている。モデルを用いた開発でどのよう
719
A?C
なプロセスを踏めば効率が上がるか、現状の開発方法
58024,*6=E
から容易に転換できるか、現状のソフトウェア品質は
719
向上するのかなど議論されている。一部では、モデル
/*.-*3
を用いた開発事例の報告もあるが、少ないのが現状で
B+
>@
ある。組込みソフトウェア業界でもモデルを用いた開
発に事例が少なく、現在の開発システムからの移行を
図 1: 抽象度とプロセス
躊躇していることが多い。組込みシステムの開発は、
大規模化/複雑化し、システム全体から細かい要求まで
• UML
理解することは難しい。今こそ、研究による組込み開
モデルによって要求されたシステムを理解する。
発の事例を収集すること、これから組込み開発に携わ
ユースケース/クラス図/タイミング図/コンポジ
る者へのモデルを用いた開発教育が求められている。
ット図などの記述方法が定められている。近年
本稿は、この一年で学んだモデリング言語 UML2.0/
UML2.0 への進化で、モデル化できる対象が増え
プログラム/回路基礎、そして、これらを総合的に教
た。MDA では、CIM/ PIM/ PSM で用いる。
育題材とした「MDD ロボットチャレンジ」へ参加し
得た成果をまとめたものである。
• MOF
UML や各言語の相互運用性を確保するために、こ
2
MDA/MDD
2.1
れらを定義するために利用される。モデルのモデ
ルメタモデルを記述/拡張するための構成要素を
MDA 概要
定義し、管理するための規格である。
MDA(Model-Driven Architecture) はモデル駆動型
アーキテクチャーといい、OMG(Object Management
01.
Group) が標準化を推進しているモデル駆動開発であ
B>CA=B>C
る。OMG 標準は、オブジェクト指向モデリング言語
B>C
である UML(Unified Modeling Language)、メタモデ
7D<=D<
ル (UML で扱うモデル表現モデル) を管理するための
0- A=A=B>C
0, B>CFE
0* 20/
0+ 9@;8:?3>4=
65
仕様である MOF(Meta Object Facility)、データウェ
アハウス用のメタモデルを定義した技術仕様である
図 2: MOF 階層構造
CWM(Common Warehouse Meta-model)、MOF を
土台としたモデル情報を、ツール間でモデルを交換可
毎モデリングごとに、使うべきメタモデルが異なっ
能にするための技術仕様 XMI(XML Metadata Inter-
てくる。よって MOF では、要求仕様を、変換す
change) を持つ。
るのに都合に合わせなければならない。
4
• CWM
表 1: MDA モデル
データウェアハウス用のメタモデルを定義してい
る。CWM も UML で記述されているため、MOF
CIM
computinon independent model:
計算非依存モデル。システムの環
境や要件を表現したもの
PIM
platform independent model:プ
がベースとなっている。
• XMI
ラットフォーム非依存モデル。特
ツール間でのモデルの交換を行うために利用れる
定のプラットフォームに関する詳
これは、MDA を実現するうえで、XML を用いて
細を問わず、システムの運用を表
メタデータの交換を行うための仕様。
現したもの
MDA では、モデル作成からソースコード完成まで
PSM
platform specific model:プラット
フォーム依存モデル。特定のプラッ
トフォームに関する詳細を組み合
わせた表現したもの
PM
Platform Model:プラットフォーム
モデル。PIM と併用する、固有の
プラットフォームを構成する技術
概念、要素、サービスを定義した
もの
TM
Transformation Model:変換モデ
ル。特定の PIM から特定の PSM
への移行に必要な変換を定義・指
定したもの
の過程で、抽象度を明確にしたプロセスを踏むことが
大切である。
92
*+,
47
63
85
-+,
0/1
-.,
図 3: 開発プロセス
MDA では、要求定義→分析→設計→実装コード
といった開発の各工程に応じたモデルを規定してい
る (図 3)。関連するのは CIM(Computation Indepen-
dent Model)/ PIM(Platform Independent Model)/
MDA では、PIM と PSM を一つの設計過程モデル
PSM(Platform Specific Model)/実装 (ソースコード)
と考ず、抽象度の高い段階においては、要求や上位の
である。
ソフトウェアのフレームを決めればよい。そして、抽象
度の低い段階においては、実装する際のプラットフォー
2.1.1
モデルの区分け
ムに似合った、そして要求通りの性能や保守性が実現
MDA でのプラットフォームとは、OS(Windows/
することを踏まえなければならない。開発者側が設計
UNIX/ )/プログラム言語 (Java/ C/ )/製品 API な
の各段階で踏まえることを明確にすることで、作業ご
ど、様々な抽象度のものである。
とに必要な情報/ スキル/人的資源を効率よくを抑える
ことが出来るのだ。
抽象度の高い段階でモデルを用いることは、プラッ
トフォームフォームを想定した考えでなくてよい。抽
2.1.2
象度の低い段階では、既にプラットフォームに依存し
たモデルでなければならない。大きく分けて、この 2
マッピング
モデル間には、モデル変換仕様/ルールが必要にな
つの抽象度のモデルが定義される。
る。これをマッピングという。プラットフォームに依
前者を PIM：プラットフォーム非依存モデル、後者
存したマッピングルールを定義することにより、モデ
を PSM：プラットフォーム依存モデルと呼ぶ。
5
のため、制御したいハードウェアの仕様や性能がソフ
,*+
74680
トの組み方までも制約する。
9<.;:
2.2.2
,-+
74680
MDD での UML2.0 の活用
この現状を解決すべくモデルを活用した組込み開発
MDD の導入が提案された。MDD はモデルを活用す
る開発手法である。MDA も基本的な考えは同じであ
3/21/5
るが、MDD は抽象度が少し高いといえる。MDD は開
発にモデルを用いなければならないが、モデル言語は
図 4: マッピング
UML を使用しなければならないという制限や、明確
ル変換の自動化が可能になる。MDA はこのモデル変
な標準などがない。UML は 1∼2.0... へと進化し、モ
換の間のマッピングルールが重要であり、現在 MDA
デル言語 UML は要求分析の抽象度の高いレベルから、
を実現するためのモデル自動変換ツールが多く開発/
抽象度の低いレベルまで表現することが出来る。また、
利用されている。システム開発者は MDA ツールを利
ツールの仕様として UML が使われているため有効的
用した場合、PIM を UML で記述し、ツールが PIM
と考える。実際に市販されている変換ツールを作成/活
から PSM への変換する。自動/半自動生成によるモデ
用することも重要である。前提条件として、UML を
ル変換で、大幅な時間短縮につながる。PSM/ソース
使い慣れていることが必要である。
コード間にも変換仕様/ルールがあるが、PIM/PSM 間
:3>
同様、PSM/ソースコード間も自動/半自動生成が可能
である。ツールとマッピング定義のメリットは、一部
=5
仕様に変更があった場合は、PIM を修正することで対
8?
10*
/2+,-.
応したり、変更に従い設計図を修正、プラットフォー
ム一部に変更があった場合は、ソースコードを修正す
るのではなく、マッピングルールを変更することで、
変更を反映したソースコードが再度生成されることで
ある。
2.2
2.2.1
6<7
組込み MDD
49;@
図 5: 組込みシステムの現状
組込みシステム
表 2 に組込み MDD へのモデル適応例を示す。
組込みとは、家庭用電化製品、車載システム、携帯
電話など、コンピュータを組込んでいるシステムを指
2.2.3
す。とくに、組込みでは、普段使用する PC とは違い、
システムの制約がある。また、組込むものにより仕様
組込み MDD の問題
組込み MDD では考えなければならない課題が多い。
が異なり、動作プラットフォームが均一ではない。そ
例えば、日本の実装の多くが C 言語であるが、モデル
6
-+,
表 2: 組込みシステムでのモデリング効果
UNTI0P8O:2;1
S57FADH=
複雑なシステム
-.,
R43 * KL
↓
モデリングすることでし、携わる多くの開発者
@/>
の確実な理解が得られる。また、プラットフォー
VM6<EG?>9
ム依存/非依存性、デバイスに依存する仕様と、
B>C
そうでない仕様の分離出来る。
システムの流れの理解
JQ
↓
振る舞いや制約を付与することで、考えやすい
図 6: 組込み MDD プロセス
「動くモデル」を書く
確認
↓
装結果などの成果を発表する。本チャレンジの目的は
モデルの分割、プロセスの確認をすることで開
2 つあり、1 つは、組み込みソフトウェア技術者の育成
発の早期から動作の確認が出来る。
もう 1 つは、組込みソフトウェア開発でのモデルとの
制約の意識
関連を考察するための資料収集である。MDD ロボッ
↓
トチャレンジの総合飛行の最終的な目標は，砂漠を飛
プラットフォーム知識を外在することで要求分
行させ，野生動物などの生態をトレースすることであ
析の効率化につながる
る (図 7)。
ミスの多い手動作業、手順
↓
モデル変換過程の明確化、マッピング定義によ
*,./+,-
る自動化をする。モデリングツールによる自動
化で、手動プログラミングによる人為的ミスを
防ぐことができる。
02
をプログラム構造へうまく変換させる必要がある (図
6)。最終的にプログラムになればいいのだが、それだ
けでは組込み機器は品質の保障が付かない。MDD に
よってハード/ソフト両面での確実な品質が生まれ、現
13
状より高品質なものでなければならない。
3
MDD ロボットチャレンジ
3.1
図 7: 最終目標
チャレンジの概要
MDD ロボットチャレンジは、飛行船自律飛行シス
テムを MDD によって開発し、モデル・開発工程・実
7
3.1.1
飛行船制御システムの概要
RF 送受信または IR 受信/ US 送受センサお
よび回路/モーター/M16 マイコンを搭載し
飛行船制御システムの概要を図 8 に示す。無線通信
なければならない。
(RF 通信)/赤外線通信 (IR 通信)/超音波センサ (US セ
– ゴンドラの重さ
ンサ)/画像解析技術を使用したシステムである。飛行
船には、RF、US センサ、地上には US マトリクスが
敷かれ、上空にはカメラが設置してある。飛行船の現
ゴンドラとエンベローブがヘリウムガスの浮
在地、方向、高さデータを元に解析し RF 通信により、
力、またはヘリウムガスとモーターの力で飛
制御指令を送ることが出来る。
行船が浮くこと
飛行船の役割としては、以下の 2 つがあげられる。
>?@
– 高さ
/:71,
2-
飛行船は、高さを求めるために US センサの
跳ね返り時間を利用し、そのデータを基地局
へ送信する。
– 命令に従う
+9<=89;
飛行船は基地局から発せられる命令に従って
53
モーターを制御する。
2-
• カメラ・ImgPC
ImgPC は上空の 3 台のカメラから画像データを
受信し画像解析により推定角度を算出し、UDP 通
2-015
信でデータを送信する。UDP から送られてくる
データには推定角度の他に、検出の確度、カメラ
.21,
ID、マーカの位置なども含まれている (図 9)。
53015
53 0+42/6
• US マトリクス/USMPU
図 8: チャレンジ概要
飛行船から放たれた超音波は高さを算出するほか
にも、US マトリクスにも利用される。飛行船から
3.1.2
地面に向けて発せられた US 信号は，地上に網目
提供 API
状に配置された複数の US 受信モジュールによっ
• 飛行船
て受信される。複数の受信モジュールからの情報
競技で使用するエンベローブは指定されたものを
を集約するために専用の MPU が用意されており，
使用する。ゴンドラ部分については、各チームに
基地局 PC はこの MPU との通信によって各受信
よって異なるが、条件がある。
モジュールの検出時間間隔情報を得る。
シリアル通信で送られるデータは、直接 XY 座標
– 搭載ハードウェア
をデータとして送るのではなく、センサ ID とタ
8
145
-
+.-,*
.
3
0
,+
,,
,0
,
4
,/
1
,.
/
,9
+
2
:
;9 75:86<
0736/28;
図 10: US マトリクス
3.2
図 9: カメラの利用
3.2.1
イマー時間をデータとして送信する。US センサ
開発の前に
ロボットチャレンジ最終目標との比較
本開発システムを考えるため、砂漠を想定したモデ
ID は配置の仕方によって変わるため、大会当日
ルについて検討した。我々は始めに日本科学未来館と
に公開座標が渡される。表 3 が公開座標であり、
砂漠で飛行船を飛ばす際の違いを比較した (表 4)。そ
表中の X/Y はスタートからの位置を示している。
の結果、双方の相違点は自然現象だけであり、その点
基地局は ID と受信したタイミングから，飛行船
を考慮しなければ日本科学未来館は疑似砂漠として考
の位置を求める必要がある。飛行競技では，競技
えることができる。よって競技運営側から掲示された
エリアの全体に US 受信モジュールが配置されず、
競技仕様に対するモデリングを行うことで、本開発シ
競技エリアの一部に集中的に配置される (図 10)。
ステムは疑似砂漠を考慮したものとする。今後 MDD
したがって，US 信号が受信モジュールに届かな
ロボットチャレンジがより飛躍すれば、天候などの自
いエリアでは，US 信号を使った飛行船の位置検
然現象を考慮した開発システムが要求されるであろう。
出はできない。
• RF 通信、IR 通信
3.2.2
開発システムの機能分割
開発対象である自律飛行システムは様々な機能を持っ
RF 通信/IR 通信は基地局/飛行船をワイヤレス
ている。そのためモデリングを始める前に開発システ
で繋ぐ手段である。RF 通信は，飛行船と基地局
ムの機能分割を行い、ハードウェアとソフトウェアで
PC との間の双方向通信に利用される。飛行指令、
実現すべき機能の明確化を図った (表 5)。我々は本開
データの送信など、自由に使用できる。同じ役割
発を飛行船側と基地局側に分担し進めており、表 5 よ
を RF 通信も持っているため，チームはどちらか
りそれぞれの作業工程が明確化でき、開発を円滑に進
を選択して実装することになる．
める手助けとなった。
9
表 5: ハードウェアとソフトウェアの機能分割
飛行船
3.3
基地局
要求
H
S
要求
H
S
RF 送信
○
○
RF 送信
×
×
RF 受信
○
○
RF 受信
×
×
US 送信
○
○
US 送信
×
×
US 受信
○
○
US 受信
×
×
RFMPU とのコミュニケーション
×
×
RFMPU とのコミュニケーション
○
○
USMPU とのコミュニケーション
×
×
USMPU とのコミュニケーション
○
○
ImgPC とのコミュニケーション
×
×
ImgPC とのコミュニケーション
○
○
コマンド処理
×
○
モータ制御コマンド作成
×
○
モータ駆動
○
○
位置 (x、y) 算出
×
○
高度算出
×
○
向き算出
×
○
エラー処理
×
○
高度算出
×
×
-
-
-
画面出力
×
○
-
-
-
エラー処理
×
○
プロジェクト管理
戻りによりメンバのモチベーションの低下の可能性が
あるウォータフォール型の開発プロセス1 は不適切と判
どのような開発プロジェクトにおいても、限られた
断した。アジャイル型の開発プロセスは、動作した物
期間以内に成果物を納品することは必須である。プロ
を開発プロセスの判断材料としているため、開発プロ
ジェクトを期間以内に終えるためには、プロジェクト
セスを柔軟に変更することを前提としている。そのた
の目的が明確であり、作業項目を分ける必要がある。
め、要求仕様をできるだけ詳細化し、その詳細化した
よって、MDD ロボットチャレンジ 2005 を行うにあた
作業工程をクリアにし、その過程で発見した問題に対
り、プロジェクトの目的の明確化/作業項目の分担を行
して早期に対処することが可能になり、開発リスクを
うためのプロジェクトスケジュールの作成と修正/メ
軽減することが可能になる。また、開発プロセスの形
ンバ間のコミュニケーションの場を提供する役割とし
式化よりも開発者のモチベーションやアイディアを重
て、プロジェクトマネジメントを導入した。
視している。
プロジェクトスケジュールを作成するにあたり、開
以上のことを考慮した結果、アジャイル型の開発プロ
発を円滑に進めるために開発プロセスの検討を行った。
セスを用いることが MDD には適していると判断した。
MDD ロボットチャレンジ 2005 では、運営側から参加
アジャイルで開発を行っていくために、WBS 2 /PERT
者に競技仕様書を配布する。チャレンジャーは競技仕
3
様書から要求を読み取り開発を進めていく。しかし、
/PDCA サイクル (Plan Do Check Action)4 を用いた。
1 要求定義/外部設計/内部設計/プログラミング/システムテス
ト/運用テストと開発プロセスを明確に区別し、下位プロセスから
上位プロセスの戻りを行わなず開発を進めていくプロセス。
2 WBS は要求仕様を階層的に詳細化を行い、開発を行うために
必要な作業項目を挙げていく。
3 PERT は WBS で詳細化した作業項目のマイルストーンを設
定し開発終了までの最短スケジュールを作成する。
4 個々のマイルストーンを計画/実施/確認/実行の順でプロセス
参加を表明した時点で競技仕様が決定していなかった
ため、競技仕様の変更に柔軟に対応する必要があった。
要求の変更による作業の手戻りが発生し、期限以内
に開発を終えることができない可能性が高くなる/手
10
-1,/
表 3: US マトリクス座標
センサ ID
X[mm]
Y[mm]
0
8000
-250
1
6700
-1000
2
8000
2750
3
6700
3500
4
4100
500
5
6700
2000
6
5400
-1750
7
4100
-1000
8
8000
1250
9
6700
500
10
5400
2700
11
5400
1250
12
4100
2000
13
5400
-250
14
6700
2500
15
8000
-1750
53 0,42.6
AD@7 +0
E9;:?=;>;8
GCBF<H
3.4
ハードウェアの設計と制御の戦略
3.4.1
34,24
ゴンドラの設計
本チャレンジで提供されたエンベローブは、横
図 11: コンテスト
160cm/体積 400L であった (図 14)。チャレンジの概
要からもわかるように、参加者は提供されたエンベ
下/左/右)/本体/電池を 180g 以内に収める必要が
ローブ、決められたハードウェアを搭載するが、ゴン
あった。図 15 に我々が作成したゴンドラを示す。
ドラの形は決められていない。制作については、8 月
バルサ木材/プラスチック/スチロールなど用いて
上旬からハードウェアの設計/M16 の機能および C 言
軽量化を意識した。
語の学習/ 飛行船の飛行特性/流体力学空気抵抗/プロ
• ゴンドラの搭載ハードウェア
ペラの特性の調査および学習をした。以下に完成まで
図 16 に実際に搭載した M16/US 送受信/モータ
の経緯を示す。
ドライバの回路を示す。また、提供された API に
• ゴンドラ
参考に設計した回路を図 17 に示す。
エンベローブの浮力は 180g 前後であった。ゴンド
ハードウェアについては、US 送受信機の設計は
ラの総重量は RF モジュール/RF アンテナ/US 送
既に出来上がっていたため、回路基盤/ゴンドラ作
受信回路/US センサ/モータドライバ/モータ (上
成を主に行った。また、この時点で MDD ロボッ
トチャレンジ 2005 の詳しい仕様が決定していな
を行うこと。PDCA を行うことにより、断続的な改善を行うこと
が可能になる。
11
0,
*467345
0,
21
0,./2
図 13: 会場の様子
-0/+
表 4: 日本科学未来館と砂漠との比較
<:9;8=
類似点
相違点
気温の高い場所と低
障害物の位置が定かでない
い場所が存在する
図 12: コンパルソリー
位置や向きのデータ
雨や風などの自然現象によ
を取得できる
り飛行特性が変化する
かったが、委員会側が IR 通信を用いることを考
目的地が設定される
自然現象による情報障害
えていたため、IR 受信機を搭載することを考え
高度の求め方
昼は気温が非常に暑い
て作成した。この時点で設計した US 送受信機お
通信方法
夜は気温が非常に低い
よび、IR 送受信機回路を付録 A/付録 B に示す。
電源電力
-
飛行船の空気抵抗とプロペラの推力については、
流体力学の文献から調査したのだが、実験による
を ±3V する仕様に変更した。変更したことで、回
値の抽出が必要になるため、飛行実験に移ること
路配置の簡単化/消費電力の削減にもつながった。
にした。
しかし、上昇実験の際に問題を生じた。温度変化
当初、モータおよびプロペラは上下/左/右すべて
や、おもりの微小な変化により、ある程度の高さ
同じ推力/大きさの物を選択し、電池については
で上昇または、下降できなくなった。そのため、
ボタン電池 2 個と CR-2 電池、US センサについて
上昇下降用のモータおよびプロペラを変更した。
は、オペアンプに与える電圧を ±6V の回路を設
最終的に、RF モジュール/RF に使用するアンテ
計していた。次節で述べる実験を行うと電池が持
ナを装備し完成となった。結果、ゴンドラ総重量
たずに止まってしまった。原因は、設計した回路
は 160g 前後となった。
に対してボタン電池に高負荷がかかり電圧低下が
生じたある。その後、大容量で高付加に強い CR-2
電池を 2 個使用、また、オペアンプに与える電圧
12
1.>
+1G
E?B400
?@333 .-/X
NRK Y+
3G
2-5>
=A;0
GPR
,1G
=A;/
WUN
/-1>
.-/X
K/
/.> .-/X
00..T<
UVW
WO
SXW JRW
/>
=A;0
GPR
@8H010 3G
J/+ Y+
.-/X
J/, YJJ
J0+ Y,
.-/X
J0,
=A;0
WPR WSXW
WPR WSXW
@/4
52?D.2
:;:,EC,./9
1G
\[Z]
IRW
GJJ
PR
SXW
JSRWUSQ
+4G
3G
=A;0
4G
E8507/B
SXW/
SXW0
PR/
PR0
GULM
GJJ
GV
56.3
+1G
=A;/
,1G
MSU FD
+3G
1G
1G
1G
=A;0
=A;0
=A;0
図 17: 飛行船に搭載した回路
図 15: 飛行船ゴンドラ
図 14: エンベローブ
3.4.2
飛行戦略
にそれぞれの動作における飛行実験について述べる。
戦略を考える際には飛行船の飛行特性を知る必要が
• 前進/後退
ある。我々は飛行特性を飛行実験により導き出し、そ
前進動作は飛行船を長い距離前進させるのではな
のデータを基に戦略を考えた。飛行船の動作は、[前進/
く、静止→前進→静止→前進を繰り返したらどう
後退][上昇/下降][左旋回/右旋回] に分けられる。以下
かと考えた。モータ正回転時間を 1[秒]/2[秒]/3[秒]
13
図 18: 飛行船の直進-正回転時間と逆回転時間
度が高いため浮力が減り、十分に上昇できない状
態が生じた。よって、上昇/下降は室内温度に合わ
せて浮力を調節するおもりを変えることにした。
• 左旋回/右旋回
旋回するときは前進のようにモータを正回転させ
た後、逆回転させると旋回は止まったが、最後に
多少前進する現象が生じた。そのため、左右モー
タを対回転後その逆の回転を与え、最後にバック
図 16: 飛行船に搭載した回路
回転をかけて静止するようにした。実験から得た
間経過した後、逆回転時間を何秒間経過させ、静
旋回時間の 2[秒]/3[秒] 時の逆回転、バック回転、
止するかを測定した。得たデータを表 6 に示す。
開始からの旋回角度は表 7 の通りである。旋回の
動作の一例を図 19 の右部に示す。
前進の動作の一例を図 19 の左部に示す。また、特
表 7: 旋回時のモータ回転時間と角度
表 6: 前進後退時のモータ回転時間と距離
正回転
逆回転
平均総合
平均最終移動
時間 [s]
時間 [s]
時間 [s]
距離 [cm]
1
1.8
2.8
16.67
2
3.3
5.3
72.00
3
4.8
7.8
181.67
正回転
逆回転
バック逆回転
最終角度
時間 [s]
時間 [s]
時間 [s]
[ °]
2
1.69
1.60
23
3
1.98
1.63
48
飛行船自身の、前進/後退/上昇/下降/左旋回/右旋
性グラフを図 18 に示す。グラフにした結果良い
回の特性を明らかにすることで、精度の高い飛行が実
特性が得られたといえる。
現可能となる。また、精度の高い戦略を考えることが
可能になる。
• 上昇/下降
次に飛行実験で得たデータを基に考えた戦略を述べ
上昇/下降における問題は、室内温度の違いによ
る。図 20 はｘ軸/ｙ軸で考えたときの飛行船の軌跡で
る飛行船の浮力の変化である。実験では、天井温
ある。図 21 はｚ軸で考えたときの飛行船の軌跡である。
14
飛行船の動作は、[前進/後退][上昇/下降][左旋回/右
US
旋回] があり、基本的にこれらの動作が並列動作するこ
とはなく、必ず一つの動作を終えてから次の動作をす
ることにした。例外として、スタートから US マトリ
クスが最初の US を検知する状態になるまでは上昇と
前進を同時に行う。飛行船は静止した状態からスター
トする。基地局からスタートの合図を飛行船に RF で
送る。飛行船は合図を受信するとすべてのモータを正
回転させ、US マトリクスが US を検知するまで上昇
と前進を同時に行う。その間、飛行船は US を発信し
図 20: X-Y 軸制御戦略
続け、US マトリクスが US を検知したのをトリガに、
RF
RF
基地局は位置/高さ/方向データを基に制御コマンドを
作成し、それを RF で飛行船に送信する。飛行船は受
信した制御コマンドのみに従いモータを制御する。
US
2[sec]
US
US
US
RF
2[sec]
US
1.8[sec]
1.69[sec]
図 21: Z 軸制御戦略
3.6
1.60[sec]
全体
飛行船は基地局からの制御コマンドのみ従い、飛行
72[cm]
する。飛行船と基地局間の装置は、データを行き来さ
せるものであり基地局が必要とするデータは、現在の
23[sec]
飛行船自身の位置/高さ/方向データである。飛行船が
必要とするデータは、GrPC が送信した制御コマンド
図 19: 飛行船基本動作の一例
データである。これを上位階層と考え、徐々に具体化
していく。
3.5
ソフトウェアモデル
3.6.1
本競技で使用する開発モデルを説明する。全体モデ
概念シナリオ
ルについてはメンバ全員で話し合い、基地局/飛行船
RFMPU/USMPU/ImgPC オブジェクトは GrPC/
については、分担してモデリングを行った。それぞれ
Airship オブジェクトヘ接続されるタイミングが違う
のプロセスの進め方は異なるが、お互いのモデルを評
ため、それぞれの振る舞いをシナリオに表した。
価し合いまとめたモデルである。
• GrPC オブジェクト
15
• ImgPC オブジェクト
Direction
– Camera オブジェクトから送られてきた画像
Command
データを受信する。
Height
GrPC
– 画像データを基に算出した結果を送信する。
Airship
• Ground オブジェクト
Position
USMatrix オブジェクト
図 22: GrPC-Airship の関係
– Airship オブジェクトから US を受信する。
– USMatrix オブジェクトの信号を USMPU オ
– Position/Height/Direction データを算出す
ブジェクトに送信する。
る。
– Position/Height/Direction データを基に
Floor オブジェクト
Command データを算出する。
– Airship オブジェクトへ US の反射波を送信
– Command データを RFMPU オブジェクト
する。
へ送信する。
• Airship オブジェクト
3.6.2
概念図
全体概念図を図 23 に示す。GrPC/
– Ground オブジェクトに US を送信する。
Airship/
RFMPU/ USMPU/ ImgPC/ Ground/ Camera オブ
– Height データを算出する。
ジェクトを並べ、各オブジェクト内のシナリオから振
– Height データを RFMPU オブジェクトへ送
る舞いを抽出し配置した。また、関係線を結び、分り
信する。
やすい図を心掛けた。
• RFMPU オブジェクト
3.7
– Airship オブジェクトから Height データを受
信し、GrPC オブジェクトへ Height データ
飛行船
飛行船のモデルを作成する際、まず始めに正常な動
を送信する。
作のみを考慮したモデル (以下正常モデル) のオブジェ
– GrPC オブジェクトから Command データを
クト図/シナリオ/クラス図/シーケンス図/ステートマ
受信し、Airship オブジェクトへ Command
シン図を作成した。このモデルは概念モデルであり、
データを送信する。
システム構成やシステム設計を捉えやすくしたもので
ある。また運営側から提供されるシステムを基に考え
• USMPU オブジェクト
たものであるため、プラットフォームに依存したモデ
– USMatrix オブジェクトからの信号を受信す
ルである。C 言語をターゲットとする開発環境を考慮
る。
しながら、概念モデルから実装モデルを作成した。正
– 基に算出した結果を GrPC オブジェクトへ
常モデルの完成後に各エラー処理を付け加えることで、
送信する。
16
GrPC
ControlAirship
表 8: 飛行船モデルの作成プロセス
Camera
Monitor
Direction
ImgPC
Position
USMPU
Height
ステージ
内容
1st ステージ
正常動作のみを考慮した
(以下正常) 概念モデルを
作成する。
Command
RFMPU
Airship
2nd ステージ
AirshipControl
る。
TransmitAirshipCommand
3rd ステージ
ReceiveGrPCCommand
ControlMotor
DispatchPosition
MakeAirshipCommand
AnalysisCommand
正常実装モデルを作成す
正常概念モデルに異常状態
を考慮した概念モデルを作
Ground
成する。
USMatrix
Final ステージ
Floor
異常状態を考慮した実装モ
デルを作成する。
CalculateHeight
図 23: 全体概念図
3.7.2
シナリオ
各オブジェクトのシナリオを作成することにより、
モデルとしての詳細度を高めた。飛行船モデルの作成
各オブジェクトの内容を表現している。各オブジェク
プロセスを表 8 に示す。
トのシナリオは以下の通りである。
飛行船の開発言語は使用する MPU の関係上 C 言語
を用いている。C 言語は関数型の言語であり、UML
• ReceiveGrPCCommand –前提条件–
はオブジェクト指向型のモデリング言語である。その
1. RF を受信する。
ため、指向が異なる UML モデルから C 言語のソー
スコードに変換する際に、モデルと飛行船側プログラ
–正常シナリオ–
ムのソースコードが一対一になるよう、あるルールに
1. AirshipControl にデータを送る。
従ってコードマッピングを行った。このルールは、ク
–異常シナリオ–
ラス図から関数を作り、シーケンス図/ステートマシ
ン図からソースコードのフローチャートを抽出すると
1. 無し。
いったものである。
• AnalysisCommand –前提条件–
3.7.1
オブジェクト図
1. ReceiveGrPC オブジェクトからデータを受
け取る。
飛行船の各オブジェクトが意味しているのは、飛行
船に必要な機能である。各オブジェクトは競技仕様か
–正常シナリオ–
ら抽出している。抽出した結果のオブジェクトとその
1. CRC チェックを行なう。
関連を図 24 に示す。
2. TeamID チェックを行なう。
3. モータコマンドを抽出し ControlMotor に
モータコマンドを送る。
17
ControlMotor
1
CalculateHeight 1
1 MakeAirsipCommand
1 1 1
1 Airship
AnalysisCommand 1
1 1 1
ReceiveGrPCCommand 1
TransmitAirshipCommand
1
1
DispatchPosition
: AirshipObjectDiagram_10th
: 1
図 24: 飛行船のオブジェクト図
–異常シナリオ–
–異常シナリオ–
1. CRC エラーの場合、ControlMotor にストッ
1. US がある一定の時間が経過しても US を受
プコマンドを送る。
信しない。
2. TeamID エラーの場合、ControlMotor にス
2. US 受信不可データを CalculateHeight に送
トップコマンドを送る。
る。
• ControlMotor –前提条件–
• CalculateHeight –前提条件–
1. AnalysisCommand からデータを受け取る。
1. DispatchPosition のタスクが終了した。
–正常シナリオ–
–正常シナリオ–
1. モータを回す。
1. 高さ計算をする。
2. 計算結果を MakeAirshipCommand に送る。
–異常シナリオ–
–異常シナリオ–
1. 無し。
1. US 受信不可データを受け取る。
• DispatchPosition –前提条件–
2. US 受信不可データを MakeAirshipCom-
1. ControlMotor タスクが終了した。
mand に送る。
–正常シナリオ–
• MakeAirshipCommand –前提条件–
1. US を出す。
1. CalculateHeight のタスクが終了した。
2. タイマーを開始する。
–正常シナリオ–
3. US を受け取る。
1. CRC 計算をする。
4. タイマーの時間を CalculateHeight に送る。
18
3.7.5
2. AirshipCommand を作成する。
3. AirshipCommand を TransmitAirshipCom-
ステートマシン図
ステートマシンで表現していることは、各クラスの
mand に送る。
内部状態である。また、ステートマシンはコードに変
換する際に、関数の内部状態の遷移を表現している。
–異常シナリオ–
今回、モデルを作成するにあたり、Linux 上で動作する
1. 無し。
「umbrello」というツールを仕様した。ツールの仕様上、
状態の分岐やコンポジット状態が表現できなかったた
• TransmitAirshipCommand –前提条件–
め、通常の UML の記述方法と異なったステートマシン
1. MakeAirshipCommand のタスクが終了し
を作成しなければならなかった。図 27 に「Umbrello」
た。
と通常の書き方の違いを示す。また、作成したステー
トマシンを図 28 に示す。
–正常シナリオ–
1. AirshipCommand を送信する。
3.8
基地局
–異常シナリオ–
基地局側飛行船システムについては、できるだけ状
1. 無し。
態遷移が少なく、シンプルな構成を心がけモデル設計
を行った。作成には、オブジェクト図→シナリオ→シー
3.7.3
クラス図
ケンス図→詳細ステートマシン図→詳細クラス図の順
番で具体化した。
各クラスの属性は全て AirshipControl クラスに集め、
AirshipControl クラスから属性を読み取る形式とした。
3.8.1
クラス間の関係を疎にすることで、飛行船シーケンス
オブジェクト図
の変更に強いモデルとなった。また、AirshipControl
シナリオ作成時に抽出した基地局内の各オブジェク
クラスが各クラスの操作のトリガとなるため、Airship-
トを関連で結び作成したオブジェクト図を図 29 に示
Control クラスと直接作用する全ての操作は、
「Public」
す。GrPC オブジェクトが高さ、方向、位置オブジェ
とした。各クラスの「Private」な操作は、
「Public」な
クトからデータを受け取り、制御コマンドとモニタ表
操作の内部関数を表現している。図 25 に実装クラス
示オブジェクトにその結果を渡して飛行船の制御と現
図を示す。
在の状態の表示を基本動作とする。GrPC オブジェク
ト以外のオブジェクト間の関係を疎し、後々オブジェ
3.7.4
シーケンス図
クトの実装に変更が生じても影響が小さくなるように
した。
チーム戦略より、飛行船は基地局のコマンド通りの
動作だけを行うため、異常シーケンスを考慮する必要
3.8.2
がなく、飛行船シーケンスは１パターンの正常シーケ
ンスのみを考えた。図 26 にシーケンス図を示す。
シナリオ
基地局側シナリオを下に示す。基地局が持つ GrPC/
Position/ Height/ Direction/ Command/ Monitor オ
ブジェクトの振る舞いを明確にした。
19
AirshipControl
- airship_status : status
+ Control(airship_status : status) : status
1 1 1 1 1 1 1
1
ReceiveGrPCCommand
+ ReceiveRF() : RF
DispatchPosition
1
+ SelfEcho() : RTIME
- TransmitUS()
- ReceiveUS()
- CountTimer() : RTIME
- MakeErrorData() : RTIME
TransmitAirshipCommand
1
+ TransmitRF(airship_command : RF)
ControlMotor
1
+ DriveMotor(motor_command : MOTOR)
CalculateHeight
1
+ CalculationHeight(reflection_time : RTIME) : HEIGHT
MakeAirshipCommand
1
+ MakeAirshipComannd(height_data : HEIGHT) : RF
AnalysisCommand
1
+ AnalysisGrPCCommand(grps_command : RF) : MOTOR
- CheckCRC(grpc_command : RF) : RF
- CheckTeamID(grpc_command : RF) : RF
- MakeErrorComannd() : MOTOR
- MakeMotorCommand(grpc_command : RF) : RF
図 25: 飛行船の実装クラス図
• GrPC オブジェクト
取得する。
– Monitor オブジェクトに Position/ Height/
– Position オブジェクトから Position データ
Direction/ Command データを渡す。
を取得する。
• Position オブジェクト
– Height オブジェクトから Height データを取
得する。
– USMPU オブジェクトから Matrix データを
– Direction オブジェクトから Direction デー
受信する。
タを取得する。
– Command
オブジェクトに
– Matrix データを解析し、Position データを
Position/
算出する。
Height/ Direction データを渡す。
• Height オブジェクト
– Command オブジェクトから Command を
20
: Receive
GrPC
Command
: Airship
Control
: Analysis
Command
: Control
Motor
: Dispatch
Position
: Calculate
Height
: Make
Airship
Command
: Transmit
Airship
Command
+ Control(airship_status : status) : status
+ AnalysisGrPCCommand(grps_command : RF) : MOTOR
+ DriveMotor(motor_command : MOTOR)
+ SelfEcho() : RTIME
+ CalculationHeight(reflection_time : RTIME) : HEIGHT
+ MakeAirshipComannd(height_data : HEIGHT) : RF
+ TransmitRF(airship_command : RF)
図 26: 飛行船のシーケンス図
A normal way of writing
A normal way of writing
A way of writing in Umbllero
YES
Composite :
Composite
Is Valid CRC?
A way of writing in Umbllero
ValidCRC
CheckCRC
Composite :
state
State
InvalidCRC
NO
State
With Junction
With Composite
図 27: Umbrello での書き方
– Position/ Height/ Direction データを基に
– RFMPU オブジェクトから Height データを
Command データを作成する。
受信する。
– RFMPU オブジェクトへ Command データ
• Direction オブジェクト
を送信する。
– ImgPC オブジェクトより方向に関するデー
• Monitor オブジェクト
タを受信する。
– Position/ Height/ Direction/ Command
– 方向に関するデータから Direction データを
データをモニタに表示する。
算出する。
• Command オブジェクト
3.8.3
シーケンス図
– GrPC オブジェクトから Position/ Height/
シナリオから分るように、Position/ Height/ Direc-
Direction データを取得する。
tion/ データについては、基地局外である RFMPU/
21
Airship
ReceiveGrPCCommand
PowerON
OccurIntrumpt
PowerOFF
AirshipControl
ControlMotor
FinishTask
ReceiveRF
CalculateHeight
FinishTask
FinishAnalysisCommand
FinishDispatchPosition
DriveMotor
DispatchPosition
CalculationHeight
FinishTask
TransmitAirshipCommand
FinishControlMotor
SelfEcho :
FinishTask
FinishMakeAirshipCommnad
AnalysisCommand
TransmitRF
FnishTask
MakeAirshipCommand
FinishReceiveCommand
AnalysisGrPCCommand :
FinishTask
FinishReciveCommand
MakeAirshipCommand
FinishTask
Composite :
AnalysisGrPCCommand
InvalidCRC
FinishTask
MakeErrorCommnad
InvalidTeamID
CheckCRC
ValidCRC
Composite :
SelfEcho
CountRegistorOverFlow
TransmitUS
ReceiveInterrupt
: AirshipStateDiagram_10th
ValidTeamID
CheckTeamID
FinishTask
ReceiveUS
MakeMotorCommand
MakeErrorData
FinishTask
FinishTask
FinishTask
CountTimer
FinishTask
: 1
図 28: 飛行船のステートマシン図
USMPU/ ImgPC オブジェクトから不定期にデータが
安に内部の状態遷移を示した。
送られてくる。そのため、シーケンス図は、GrPC オブ
注意として、図の中で”Junction”という状態を用い
ジェクトと GrPC オブジェクト内の個々のオブジェク
ているが、これは状態ではなく”選択点”として用いて
トの非同期シーケンス、GrPC オブジェクト内の Mon-
いる。我々がモデリングで用いたツールに選択点の要
itor オブジェクトが実行されるまでの同期シーケンス
素がなかったため、苦肉の策として”Junction”をチー
というように、2 つのシーケンス図で基地局側の流れ
ム内の選択点の要素とした。
を表した (図 30、図 31)。
3.8.5
3.8.4
ステートマシン図
クラス図
Position/Height/Direction クラスが独立独行 (SelfReliance) に I/O アクセスし、自身を更新することを心
図 32 と図 33 に GrPC 側のステートマシン図を示
す。それぞれのステートマシン図は電源が入ると同時
がけて作成した。基地局実装クラス図を図 34 に示す。
に遷移し、終了状態は存在しない。コンポジット状態
Position/ Height/ Direction クラスのデータ更新用
になっている図に対しては内部の状態を詳しく示した。
メソッド (update メソッド) は GrPC から操作するこ
このときどれほどの粒度でステートマシン図を描くべ
とはできず、更新のタイミングも隠蔽した。実装は
きか迷ったが、中のシーケンスが分かる程度までを目
static private な update メソッドを POSIX(Portable
22
<GrPC>
: GrPC
: ControlAirship()
: Update()
<Height>
: Height
<Position>
: Position
<Direction>
: Direction
: Update()
: Update()
<Cmmand>
: Command
: GrPC
: Send(position : position , height : height , direction : direction)
<Monitor>
: Montor
: Display(position : position , height : height ,
direction : direction , command : command)
図 30: 基地局の非同期シーケンス
*((height_ *)height) = rand();
return (void *)NULL;
Monitor
}
public:
Height_(){
pthread_t pt;
pthread_create(&pt, NULL
, Height_::update, (void *)(&height));
}
1
1
GrPC 1
1 1
1
Position
1
1
Direction
: GrPC_Object
1 Command
height_ get() const{
return height;
}
1
};
Height
これにより GrPC が任意のタイミングでデータ
: 1
取得用メソッド (get メソッド) をコールしても最新
の Position/Height/Direction データを取得可能にし
た。結果として各クラスの関係が疎になり、RFMPU/
USMPU/ ImgPC の非同期なデータ到着タイミングと
独立したコマンド発行とモニタ出力が実現できた。
図 29: 基地局オブジェクト図
Operating System Interface for UNIX) Thread(以下
class GrPC_{
Position_
Height_
Direction_
Command_
Monitor_
pthread) でスレッド化して実現した。
class Height_{
height_ height;
static void *update(void * height){
while(1)
Position;
Height;
Direction;
Command;
Monitor;
void ControlAirship(){
while(1){
23
: GrPC
: Position
: Height
: Direction
: Command
: Monitor
+ Get() : position
+ Get() : height
+ Get() : direction
+ Send(position : position , height : height , direction : direction)
+ Get() : command
+ Display(position : position , height : height , direction : direction , command : command)
図 31: 基地局の同期シーケンス
タイマ IC(LM555) を接続し、M16 マイコンの出力信
Command.Send(Position.get()
, Height.get(), Direction.get());
Monitor.Display(Position.get()
, Height.get(), Direction.get(), Command.get());
}
};
号が H(5V) のときに 40KHz の US が発振する。
public:
GrPC_(){
ControlAirship();
}
};
3.10
飛行情報の受信
3.10.1
方向:UDP 通信
ImgPC/ 基地局間の UDP 通信パケット長は 64 バイ
トである。64 バイト中には GrPC が方向を知るため
の角度推定値だけでなく、画像解析によるマーカ検出
3.9
確度/ 高度推定値/ 位置推定値など含まれていた。各
提供システムの利用
バイトの内容の一部を表 10 に示す。
開発にあたりアーキテクチャ委員から提供された API
および回路図を利用した。利用状況を表 9 に示す。
方向 =
表 9 が示すとおり基地局プログラムは独自の設計で
256
角度推定値
360
(1)
開発を行った。USMPU システムと ImgPC システムは
直接に角度値が送られるのではなく、開発者側が角
競技場に設置されたシステムを利用した。RFMPU シ
度推定値を元に算出する。通信設定では、配送先アドレ
ステムではプログラムは全て提供物を利用し、ハード
ス 255.255.255.255、配送先ポート 2005 が定められた。
ウェアは提供された回路図を参考に開発した。AirMPU
我々は、方向値を得たいため、角度推定値/ マーカ
システムのプログラムは RF 通信用 API を利用し、全
検出確度を利用した。(角度推定値はマーカ検出確度と
体制御と US 通信については独自に設計した。また、
併用しなければならない) また、方向の算出の例は図
AirMPU システムのハードウェアは提供された回路図
を参考に、US 送信部の一部改変を加えて開発した (図
36 のように与えられた。UDP 受信では、次の作業が
必要である。
35)。改変した回路はプログラムによって 40KHz の周
波数を作るのではなく、M16 マイコン/US 送信機間に
• ソケットを作る
• bind する IP アドレスとポートを設定する
24
GrPC
Position
PowerOn
PowerOn
ControlAirship
SavingPositionForSelfishReasons
PowerOn
WatingData
GetData
InvalidData
CheckCRC
Monitor
ValidData
PowerOn
WatingCall
AbnormalValue
CalculatingPosition
CatchCall
FinishOutput
NormalValue
OutputOnDisplay
Direction
Height
PowerOn
PowerOn
PowerOn
SavingDirectionForSelfishReasons
PowerOn
WatingData
CheckCRC
GetData
InvalidData
CheckCRC
ValidData
CalculatingDirection
SavingData
InvalidData
ValidData
AbnormalValue
CheckLimit
NormalValue
#Composite
SavingHeightForSelfishReasons
WatingData
GetData
:
FinishSaving
SavingData
#Composite
AbnormalValue
NormalValue
FinishSaving
_GrPC_Monitor_Direction_Position_Height
#Composite
SavingData
FinishSaving
: 1
図 32: GrPC、Monitor、Height、Direction、Position のステートマシン図
• ソケットに名前をつける
struct sockaddr_in addr;
• データを受け取る
unsigned char buf[64];
Imgsock = socket(PF_INET, SOCK_DGRAM, 0);
#include <sys/types.h>
#include <sys/socket.h>
ddr.sin_family = PF_INET;
addr.sin_port = htons(SV_UDP_PORT);
#include <netinet/in.h>
#include <string.h>
addr.sin_addr.s_addr = INADDR_ANY;
#define ANGLE 8
・
・
・
・
・
・
bind(sock, (struct sockaddr *)
&addr, sizeof(addr));
・
・
・
memset(buf, 0, sizeof(buf));
int main(){
while(1){
int Imgsock , direction;
25
Command
PowerOn
GetAnOrder
WatingAnOrder
FinishSending
FinishMakingCommand
SendingCommand
PowerOn
WatingAnOder
GetAnOrder
MakingCommand
Junction
StartState
NormalState
Junction
ValidData
MakingStartingCommand
InvalidData
FinishMaking
CompareCurrentPositionAndGoal
FinishComparison
MakingBackCommand
FinishMaking
FinishSending
FinishMaking
SendingCommand
MakingNormalCommand
#composite
:
_Command
: 1
図 33: Command のステートマシン図
表 9: 自律飛行システム中の提供物利用状況
提供物の利用
GrPC
USMPU
HW SW
RFMPU
HW SW
ImgPC
AirMPU
HW SW
×
⃝
△
⃝
△
⃝
⃝
△
× 不利用 △ 一部利用 ⃝ 全部利用
if(recv(Imgsock, buf,
sizeof(buf), 0)<0){
• ソケットを作る
• 宛先を指定して送信する
}else{
direction = 256 / 360 * Imgsock[ANGLE];
printf("%d",direction);
・
・
・
・
・
下に UDP 送受信/送信例を示す。
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#define SENDW "DATA123\n"
・
・
・
}
#define LEN 5
int main(){
int Imgsock;
}
close(Imgsock);
}
struct sockaddr_in addr;
Imgsock = socket(PF_INET, SOCK_DGRAM, 0);
UDP 送信では、特定の IP アドレス＋ UDP ポート
addr.sin_family = PF_INET;
番号で待っているサーバに対してパケットを送信する。
26
GrPC
- Position : Position
- Direction : Direction
- Height : Height
- Command : Command
- Monitor : Monitor
+ ControlAirship()
1 1 1 1 1
Height
- height : height
1 - Calculate()
- Update()
+ Get() : height
Position
- position : position
1
- Calculate()
- Update()
+ Get() : position
Direction
1 1- direction : direction
- Update()
+ Get() : direction
Monitor
1
+ Display(position : position , height : height ,
direction : direction , command : command)
Command
- command : command
1 - goalposition : position = GOALPOSITION
- goalheight : height = GOALHEIGHT
- state : state = START
+ Send(position : position , height : height , direction : direction)
+ Get() : command
図 34: 基地局実装クラス図
addr.sin_port = htons(2005);
addr.sin_addr.s_addr =
inet_addr("255.255.255.255");
・
・
・
・
・
・
・
・
sendto(Imgsock, SENDW, LEN, 0,
3.10.2
位置:シリアル通信
USMPU/基地局間のシリアル通信では、US マトリ
クスで反応した US センサの ID とタイミングが送信
されてくる。通信設定は、ボーレート 9600bps/8bit/
ノンパリティである。また、送られてくるデータ構成
を図 37/シリアル受信の例を下に示す。
(struct sockaddr *)
&addr, sizeof(addr));
・
・
・
・
#include <stdio.h>
#include <fcntl.h>
・
・
・
・
#include <termio.h>
close(Imgsock);
}
int main(){
int USfd;
27
Timer IC LM555
40KHz
timer ic on
GND V+
0.1u
+5v
Vin
MAX232
1.3K
V+
C1- Vcc
C2+ VC2C1+
Trg Di
M16
0.1u
10k
Vin
0.1u
Rst Th
74LS04
1K
O
Cnt
2200pF
0.1u
0.1u
Tin Tout
Tin Tout
UStransmiter
M16
L
H
H
L
L
L
図 35: 超音波送信回路
2503
バイト位置
1
2-6
内容
78068
未使用
赤マーカ検出確度
8
青マーカ検出確度
9
角度推定値
+-.
04231 ; ,.* : <=
図 36: 角度
未使用
...
...
...
...
17
赤マーカ位置 X 座標上位バイト
20
赤マーカ位置 Y 座標下位バイト
22
青マーカ位置 X 座標下位バイト
23
青マーカ位置 Y 座標上位バイト
29-32
<=9,** =
カメラ ID
7
10-16
<=9* =
<=9/* =
表 10: ImgPC からの受信データ
struct termios tio;
char usmsg[9];
・
・
・
・
・
・
・
・
if( (USfd = open("/dev/ttyS1"
,O_RDONLY)) < 0 );
未使用
33
高度推定値上位バイト
34
高度推定値下位バイト
37-48
未使用
61-64
未使用
printf("/dev/ttyS1 open failed.\n");
bzero(&tio, sizeof(tio));
tio.c_cflag = B9600| CS8| CLOCAL| CREAD;
tio.c_cc[VMIN] = 9;
tcsetattr(fd, TCSANOW, &tio);
while(1){
tcflush(USfd,TCIOFLUSH);
read(fd, usmsg, 9);
28
1. メンバの開発スキル
-12
2. メンバのモチベーション
,+204
/2.35
*
3. 作業項目の難易度
4. 作業に当てられる時間
また、これらの項目を把握できなければ、プロジェク
図 37: USMPU からの受信データ
トを円滑に進めることが困難になり開発が遅れる可能
・
・
・
・
性が高まる。そのため、プロジェクトマネージャは開
・
・
・
・
発の遅れを回避するために、把握できる限りのリスク
を予測し対応策を作成する必要がある。
}
プロジェクトマネージャは上記のことを心がけマイ
}
ルストーンの設定/リスクの対応策の作成を行いプロ
ジェクトを進めた。リスクの対応策として、マイルス
3.11
3.11.1
プロジェクト管理の考察
トーンの設定時に修正期間を考慮する/作業の進捗を
定期的にメンバで報告する場を設けるなどを行った。
開発側の考察
しかし、幾度か開発の遅れが生じ、マイルストーンの
WBS により要求仕様の詳細化が図られたことで、作
業の把握がしやすくスムーズに開発に着手することが
できた。しかし開発途上において、PERT の作業進行予
定と実作業進行状況にズレが生じ、再三に渡り PERT
の変更が生じた。
その原因は、メンバの開発スキル不足を要因とする
作業の遅れ/飛行船の物理モデルの不確定さを要因と
する実験項目の抽出の困難さ/マネージャの開発管理
経験の少なさを要因とする作業期間の見積りの困難さ
の三つが挙げられる。
以上より、プロジェクトマネージャから与えられた
WBS は作業工程を把握するのに役立ち、開発を進め
る際の有効な管理方法の一つであった。しかし PERT
においては、その作業日程に沿った実作業は困難で、
作業目安にはなったものの WBS に比べると有用では
なかった。PERT を有効な手段とするには開発管理者
再設定を行った。
開発の遅れが生じた原因として考えられることは、
メンバの開発スキルを調査せずマイルストーンの設定
をマネージャの判断で行ったこと/リスクの対応策が
不十分であり、(1) から (4) の項目が把握できていな
かったからだと考える。以上のことから、より良いマ
ネジメントを行うためには以下の項目が大切であると
考える。
• リスク対処法
• メンバの開発スキルの把握
3.12
コンテスト結果を踏まえた考察
大会の審査対象である、モデルと飛行競技の結果に
ついて考察を行う。
の作業期間の正確な見積りと開発者の開発スキルの向
上が必要であると考える。
3.12.1
3.11.2
モデル
モデル審査員の評価は、
「飛行船の飛ばし方について
管理側の考察
のモデルは記述してあるが、コースを攻略するための
プロジェクトマネージャはプロジェクトを円滑に進
モデルが記述されていない」であった。図 19、図 20、
め、開発期間以内に終えるために、WBS による作業
図 21 は飛行船の戦略であり、これらの図から飛行方
項目の詳細化/PERT によるプロジェクト終了までの
法を読み取ることができる。モデル審査員の評価通り、
マイルストーンの設定を行い、適切なマイルストーン
図 19、図 20、図 21 から飛行船の状態/エラー処理につ
を設定するために以下の項目を把握する必要がある。
いて読み取ることが困難である。しかし、コースの攻
29
3.13
略方法を考慮しなかったわけではない。メンバ全員で
戦略についての話し合いを行ったため、図 19、図 20、
ハードウェアに関しては、デバックの環境が非常に
図 21 から戦略を十分理解でき、これ以上、戦略の詳
悪かった。配線が切れる/取れる。マイコンのフラッ
細化を行わなかった。この評価を受け、次回のチャレ
シュROM に焼く際の手間ガかかる/ 軽量化を意識し
ンジにおいてはメンバ間のみでなく作成したモデルを
強度の弱いゴンドラでの実験、非常に効率が悪かった。
誰が読んでも理解できるモデルを作成することを心が
あらかじめ、デバックの環境の整備をする必要があっ
ける。
3.12.2
ハードウェアの考察
たと考える。
飛行結果
3.14
MDD という開発手法についての考察
コンパルソリーでは、飛行船が離陸した後、目標の
3.14.1
高さまで上昇せずタイムアップとなり得点が 1[点] で
モデルの利用
あった。飛行船が目標の高さまで上昇しなかった原因
はじめにチーム内で、シンプルなシステムを構築す
は、飛行船の浮力を調節するためのおもりが重すぎた
るように心がけたが、逆にモデルを使用することで、
ためである。このような人為的ミスを起こした原因は、
抽象度を分けることができ、シンプルなシステムを構
以下のことが重なったためだと考える。
築できたとも言える。また、メンバ全員が理解した上
で次の抽象度のモデルへ変換したため、抽象度にあっ
• それぞれの競技は 1 度ずつのチャレンジ、という
精神的プレッシャー
た良い話し合いが出来た。この結果からシステム理解
面で非常に役立ったと考える。
• 競技時間の制約
• 温度差の把握
3.14.2
上記の原因などによる人為的ミスの発生率を下げるた
開発手法
• 抽象度と分離
めに、飛行船の準備シーケンスの作成を行い、それに基
づくシミュレーション/テストを行うべきだと考える。
開発を終えて AIP を用いたモデルの位置づけが
総合飛行では、飛行船-基地局間の通信は確立され
難しかったと感じた。コンセプトしては、API 仕
ていたが、飛行船の高さ検出ができなかった。そのた
様の面から、要求分析→ PSM →ソースコードと
め、基地局側のソフトウェアが緊急モード5 に切り替
いう流れを定義した。全体概念図をモデリングし
わり、仮想バーを越えた後に飛行不可能と判断され競
た後、基地局/飛行船の異なるプラットフォーム
技終了となり得点が 9[点] であった。US の単体テスト
へモデル変換させた。その後は PSM としてモデ
の環境では、飛行船の高さを検出することができた。
リングを行った。しかし、モデリングを終えてか
しかし、ハードウェア環境を変える/RF と US の機能
らだら、全体概要図異種のプラットフォームに適
統合を行うと高さ検出ができず、この状態で大会本番
応できることから結果として唯一の PIM であっ
を迎えた。このような結果になった原因は、開発の遅
たと考える。高抽象度なりに変換定義を具体的に
れによる個々のデバイスの性質調査が不十分であった
する必要があったと考える。
こと/ 開発の遅れによる統合テストがほとんど行えな
• PSM →ソースコードマッピング
かったことだと考える。よって、次回のチャレンジで
は開発の早期にデバイスの性質調査を行い、十分な統
プログラム言語は基地局では C++言語を、飛行
合テストを行うこと/ユーザに対する準備シーケンス
船では C 言語を用いている。
の作成とテストを行うことを心がけたい。
– 飛行船
今回使用した M16 マイコンは C 言語と機能
5 緊急モードは、基地局に高さ/位置/方向のいずれかのデータが
値域外の場合に作動する。高さ/位置/方向のデータを取得するため
に、飛行船を上昇/下降/前進/後退させる。
を利用可能にするための非言語が含まれてい
30
た。手動によるマッピングでは、C 言語は各
表 12: 開発スケジュール
オブジェクトを関数で表現することでマッピ
ングを行った。はじめに非言語を考える必要
8 月上旬
M16 および C 言語の学習/
ハードウェアの作製/WBS
8 月下旬
講習会参加/飛行船の空気
があった。
– 基地局
C++言語はオブジェクト指向型の言語であ
り、クラスを用いることでモデルからコード
へのマッピングが定式的かつ明確に行うこと
ができた。
抵抗の調査/M16 の仕様確
認/WBS の変更
9 月上旬
飛行船の物理特性実験/
ハードウェア作製/WBS の
変更
3.15
9 月下旬
スケジュール
本チャレンジの進行スケジュールを表 11 に示す。ま
10 月上旬
た、本チームの開発経過を表 12 に示す。WBS を早期
6 日間の休暇/モデリング
/WBS の変更/ハードウェ
アの作製
プログラム作成/ハードウ
ェア修正
に決定し、物理特性や一部のハードウェア作製に着手
10 月中旬
することができた。しかし、飛行船側の通信 AIP の理
解に時間がかかり RF 通信モジュール/US モジュール
RF 通信確立/MDD ロボッ
トチャレンジ本番
などすべての機能を搭載したゴンドラの完成は本番の
直前であった。
4
表 11: 提供 API の結果スケジュール
8月8日9日
講習会
8 月 23 日
MDD 講習会
8 月 31 日
RF プログラム配布
9月3日
RF モジュール、赤外線モ
ジュール届く
9 月 25 日
カメラによる方向検出のプ
まとめ
• 組込み MDD
今回実践した、モデリング/組込みシステム開発/
開発手法は初めての経験であった。UML を用い
た開発は、個人でなくチームという複数人数での
開発では非常に有効的である。
MDD ロボットチャレンジ 2005 は、10 数チームが
参加し競技や意見交換を行った。各チーム、モデ
リングコンセプト/マッピング方法/MDD という
開発手法の定義は異なった。前回 MDD ロボット
チャレンジ 2004/2005 を比べても考え方が変化が
あった。また、自分の意見ではあるが、もう一度
ロトコル仕様公表
9月
US マトリクス情報仕様変
更
10 月 4 日
競技仕様書最終版
10 月 10 日
モデル提出
このチャレンジに参加するとしたら、経験の面か
10 月 11 日
ImgPC データ出力サンプ
ルプログラム
これは、組込みシステムへの MDD 適応には、ま
10 月 15 日
日本科学未来館にてテスト
ら考えても違う MDD 手法を選択するであろう。
だ多くの考えがあることを意味している。研究と
教育面から考えても、さらに MDD を利用した組
飛行
10 月 17 日
MDD ロボットチャレンジ
本番
10 月 18 日
ワークショップ、表彰
込みシステムの事象を増やす必要がある。
• 開発プロセス/プロジェクト管理
WBS/PERT を有用に用いることができれば、プ
ロジェクトを円滑に進めることができる。しかし、
WBS/PERT を有用に用いるにはそれを作成する
31
管理者側およびそれを用いる開発者側の双方に開
発経験/開発スキルが必要である。
• ハードウェア
基礎回路の計算知識を得ることができた。また、
感光基盤での作製/ ハードウェアの軽量化/物理
特性の考慮が求められたことから、デバイスの選
定方/半田付けの技術/制御工学の知識を身につけ
ることができた。
32
A
回路基礎:超音波送受信機
センサのマイナス側に入力する電圧の位相が 180 度ず
る。そのため電位差が 2 倍になる。よって、より強い
波を出力することが出来る。
以下に、使用した各デバイスについて説明する。
A.1.1
超音波センサの仕組み
Transmit
Receive
図 38: 超音波送信機
+
図 40: 超音波センサ振動子の運動
A.1
超音波送信機
今回使用する 40KHz 超音波センサは空中用開口型
の送受信が別々のセンサである。送信用超音波センサ
+5v
0.1u
の振動子に信号電圧を加えると、振動子が屈曲運動を
起こし, 機械的共振周波数と入力した高周波信号の周
1K
波数と一致したときに超音波を放射する。
10k
また、受信用超音波センサは、受信した超音波振動が
LN
555CN
1K
振動子に屈曲運動を生じさせ、電気出力が発生する。
2200pF
電圧が高くなるほど、出力が大きくなる。
0.1uF
+5v
HD
74LS
04P
0.1uF
+5v
A.1.2
ADM
3202AN
(MAX)
(232)
タイマー IC
タイマー IC とは、抵抗やコンデンサによりクロッ
クを制御する IC である。今回は、40KHz の超音波発
0.1uF
振用として使う。
0.1uF
0.1uF
f = 40 × 103 =
1
T
T = 25 × 10−6
(2)
タイマー IC の無安定動作
図 39: 超音波送信回路
何 Hz の周波数を発振させるかは、抵抗とコンデンサ
の値によって決まる。コンデンサ C は、Ra を通じて
超音波送信機の回路を図 39 に示す。マイコンからの
充電され、Rb を通じて放電される。デューティーサイ
信号により、タイマー IC によって 40KHz の周波数を
クルに関しては Ra 、Rb 抵抗の比で設定することがで
発振される。その信号の一方を Hex Inverter に入力、
きる。
もう一方を電圧レベルコンバータへ入力した。
一方を Hex Inverter に入力することによって、超音波
33
Low_X[S]
40 × 103
=
Rb
=
(1.3 ×
103
1.44
(7)
+ 2Rb ) × 2200 × 10−12
7.5 × 103 (10K 半固定抵抗)
(8)
OneCycle_Y[S]
次にデューティーサイクルを確かめる。
図 41: デューティー比
D
7.5 × 103
(1.3 × 103 + 2 × 7.5 × 103 )
= 0.46
=
(9)
(10)
計算値と出力波形は多少の違いがるため、半固定抵抗
で周期を調整する必要がある。Vcc 5V で、周期 25 µ s、
± 2.5V の交流が出力される。
図 42: 無安定動作回路
40KHz で発振するための計算式を以下に示す。
f=
1
1.44
=
T
(Ra + 2Rb ) × C
(3)
D:デューティーサイクル (Duty cycle)
D
=
X
Y
(4)
=
Rb
Ra + 2Rb
(5)
図 43: 抵抗とコンデンサの関係
(6)
Ra ,Rb :抵抗 C:コンデンサ
仕様書の無安定動作 f-C グラフより大まかに抵抗の値
A.1.3
を決めておく必要がある。
Hex Invertar HD74LS04
Ra
= 1.3K Ω
この IC は論理回路の NOT 回路であり、DC 特性と
AC 特性で動作が異なる。Hex inverter の DC 特性は、
Rb
= 10KΩ(半固定抵抗)
入力電圧が Low のとき出力 High、出力電圧が High の
= 2200pF
とき出力 Low という動作をする。
C
今回 Hex Invertar を使用した目的は、インバーター
の交流特性を生かすためである。インバーター IC の
可変抵抗 Rb の値
AC 特性とは、入力電圧が 180 度位相がずれ出力され
ることである。交流の電圧を反転させ、180 度位相を
34
表 13: Inverter DC 特性
in out
L
H
H
L
ずらす事により、超音波発信機に入る電位差を上げて
いる。オシロスコープで見た波形を以下に示す。
図 46: ADM3202 出力電圧特性
される電圧は 10V であるはずであるが、IC の仕様電
図 44: Hex invertor In-Out 特性
圧は下図通りであり、実際も電位差が 9V 近くである。
A.2
超音波受信機
受信した超音波は、電位がとても小さい。超音波受
信センサから生じた電圧をオペアンプで約 4500 倍に
増幅させる。その後フォトカプラで交流を絶縁させ、
出力反応を得る。出力はアクティブ・ロウである。
A.2.1
オペアンプ
今回使用するオペアンプは、電圧利得が標準で 110dB
と高い NJM4580 を使用した。１段目を Ra =10KΩ、
図 45: 波形の比較
Rb =1MΩ に設定し、-40dB の電圧に増幅, さらに 2 段
目を Ra =22KΩ、Rb =1MΩ に設定し、-33dB の電圧に
増幅するように設計した。
A.1.4
これで計 73dB（4500 倍）の出力電圧が得られる事に
電圧レベルコンバータ
なる。ピーク電位は± 6V である。しかし、この± 6V
ADM3202 コンバータは、パソコン、端末間の電圧
レベル変換によく使われる。今回は、電圧レベルアッ
の電位を与えた回路の実際の出力電位は、± 4.25V 程
度である。これは、オペアンプの仕様である。(図を参
プの特性を利用した。入力電源＋ 3.3V 時電荷を保存
考)
しているコンデンサ (C1) を使用して、＋ 3.3V 入力電
例えば、± 1mV の電圧が超音波センサに生じたとす
源を倍の＋ 6.6 V にし、この＋ 6.6 V レベルを C2 を使
る。増幅が 4500 倍より、± 4.5V の電圧に増幅される
用して− 6.6 V に反転する。C3 は図では V ＋と VCC
が、最大電圧が± 4.25V より、± 4V ほどの交流が出
の間に接続される。また、コンデンサ C3 と C4 は、出
力される。
力リップルを低減するために使用している。今回の回
路では、Vcc を+ 5V で動作させている。このとき出力
35
4.7k
1000K
100
TLP
620
+5v
+6v
22k
2k
図 49: オペアンプの出力電圧特性
フォトカプラ
• フォトカプラ TLP620
2k
30k
10k
1000k
-6v
0.001u
NJM
4580D
A.2.2
図 50: AC フォトカプラ
図 47: 超音波受信会回路
H
H
L
L
H
H
L
L
Rb
図 51: AC フォトカプラの特性
+6V
Ra
-
交流電流を流すため、図のように赤外 LED が逆
+
並列接続されているフォトカプラ TLP620 を使用
した。
-6V
• フォトカプラと電流
図 48: 反転増幅回路
36
– フォトカプラ発光部 (赤外 LED)
このフォトカプラの発光部である赤外 LED
へ流したい電流は、最大定格が 60mA であ
ることを考慮し、最大 4.25V の電圧が入った
ときのために、30mA に設定した。この場合
の赤外 LED にかかる電圧は 1.25V である。
Airship
343m/s
h
以上のことから、発光部への入力電流を変え
40KHz
るための抵抗値は、
この電圧 − LED にかかる電圧
LED に流したい電流
GND
図 52: 飛行船の地面からの高さ
= 使う抵抗
(11)
る。この一通りの時間を計測することにより、距
離 (高さ) を算出できる。
4.25 − 1.25
30 × 10−3
=
100[Ω]
(12)
• 計算方法
今回、
「超音波を発射してから物体に反射して戻っ
てくる迄の時間 T」は 1/2 倍することにより超
音波送受波器から地面 (床) までの距離を知ること
ができる。
例えば、反射波が検出されるまでの時間を T [μ
s] とすると、図中の高 h は、となる。
– フォトカプラ受光部 (フォトトランジスタ)
一方、フォトカプラの受光部である、フォト
トランジスタの最大定格電流が 50mA、推奨
条件 1mA∼10mA である、10mA 時のコレ
クタエミッタ間飽和電圧が 0.3V ほどである。
h=
電源電圧 − コレクタにかかる電圧
コレクタエミッタ間に流したい電流
1
T × 343 × 10−3 = 0.17T [mm]
2
(15)
= 使う抵抗
A.4
(13)
5 − 0.3
30 × 10−3
A.4.1
=
4.7 × 103 [Ω]
電源回路
3 端子レギュレータ
(14)
今回電源回路を作製したのは、乾電池を電源にする
ためである。
A.3
距離の測定
上の図が電源回路の基本接続である。今回使用した
3 端子レギュレータの番号は「7805」である。
• 考え方
超音波は音波であり、速度は常温で音速 343m/s で
ある。1 秒間に 343m 進み、1cm を進むのに 29µS
• レギュレータ
出力したい電圧より高い入力電圧値を放熱という
かかる。マイコン信号とともに、超音波送信機か
形で、一定の電圧に安定化する。5V 安定レギュ
ら超音波信号が送信され、地面 (床) によって反
射した信号を受信機キャッチしマイコンが検出す
37
7805
6V
5V
0.1u
47u
0.1u
図 53: 3 端子レギュレータの基本回路
レータに 10V 、1A の入力電圧をくわえた場合
V × A = W (電力)[ワット]
(16)
(10 − 5) × 1 = 5[W ]
(17)
の熱が放出される。高ければ良い訳ではなく、余
分な電圧は全て放熱されるが、効率の良い放熱を
しなければならない。
• 「7805」
左の 2 つの数字で 7800 シリーズを示す。7800 シ
リーズはプラス (+) 電源の安定化に使用し、一方
マイナス (-) 電圧の安定化は、7900 シリーズであ
る。
「05」は 5V の電圧に安定化するもので、ここの
数字が直接安定化の電圧である。
• 回路説明
図中入力側の 47µ 電解コンデンサと 0.1µ 積層セ
ラミックコンデンサは発振防止用としてつけてい
る。出力側のセラミックコンデンサは、電圧の安
定を図っている。通常入力側のコンデンサには数
10 μ F 程度をつけることが望ましい。
38
B
回路基礎:赤外線送受信機
B.1
赤外線とは
図 56: 赤外線送信機
図 54: カメラから見た赤外線
カメラから見た赤外線 LED が光を放っている写真であ
る。人間の可視光線が、380nm から 780nm に対して、
近赤外線の波長範囲は、780nm から 1.5µm である。
B.2
赤外線センサ回路
今回使用する赤外線の波長は 26µS、38KHz である。
38KHz
最終的には、マイコン制御によりパルス信号と、38KHz
のを組み合わせて赤外線を送信するが、今回は、どの
くらいの距離まで赤外線センサ回路の信号が受信でき
833Hz
るかを確かめる回路として、作製した。今回使用する
赤外線受信モジュールは連続した信号を受信しない構
造のため、タイマー IC を 2 段に使いバースト波信号
600uS
を発生させている。
そして、赤外 LED を 2 つ並列に付けて指向性と感度
833Hz
を大きくした。
600uS
B.2.1
赤外線受信モジュール
図 57: 赤外線送信時のバースト波形
赤外線受信モジュールは連続した信号を受信せず、
バースト波を入力したときに反応するモジュールであ
る。推奨するバースト波の動作は、下の図の通りであ
る。
39
+5v
0.1u
1K
10k
LN
555CN
1.3K
0.1uF
0.1u
1K
10k
+5v
LN
555CN
1.3K
2200pF
図 55: 赤外線送信回路
このときの波は T=1200 μ S(833Hz) に 38KHz(26
μ S ) を組み合わせたバースト波である。また、Vcc
が 5V で出力動作は 5V のアクティブ・ロウ電圧が発
生する。
B.2.2
2 段タイマー IC
図 58: タイマー IC833Hz と 26KHz
バースト波を発生させるために、超音波送信機同様
タイマー IC「LM555」を使用し、発生させた 1200 μ
S(833Hz) の波で 26 μ S(38KHz) の波制御する形にし
た。その際の出力波形は下図の通りである。
38KHz の波が発生しているところと、していないとこ
ろがあることが分かる。
図 59: タイマー IC の出力波形
40
B.2.3
トランジスタ 2SC1815
コレクタ電流の最大定格が 150mA より 140mA 程
表 14: 光の単位
記号, 単位
放射量
物理量
単位
度の電流が流れるようにした。よって赤外 LED ひと
光束
lm(ルーメン)
放射束
W
つにかける電流は 140 / 2 = 70mA となる。140mA で
光度
cd(カンデラ)
放射強度
W/sr
のベースエミッタ間飽和電圧は約 0.9V である。
輝度
放射輝度
W/sr/m
放射照度
W/m2
cd/m
lx(ルクス)
照度
B.2.4
2
2
赤外 LED
• 光の単位
表 15: LED 一覧
最大電流 (mA) 放射強度
型番
– 照度
照度とは。光源から離れた位置にある面に対
する光の単位面先あたりの光束。1m2 あたり
にどれだけの光束が入っているかを表す値。
光源から離れれば離れるほど光束の量が少な
くなる。
半値角
TLN110
100
15
8
TLN105B
100
12
26.5
TLN115A
100
15
21
TLN201
100
20
7
TLN231
100
60
16
今回の赤外線センサは、最大 10m ほどの通
信を要する可能性がある。10m 付近で通信
– 放射束 (Radiant Flux)
単位時間ないにある面を通過する放射エネル
ギー。このエネルギーが高くてもどれだけ明
るいか、どれだけの範囲を照らすかには、直
接関係しない。
すると仮定すると、センサの向きが安定しな
い、赤外線が届いていないなど不都合が生じ
るかもしれない。よって、半値角が大きく、
放射強度の (受信効率の) 高いものにしなけ
ればならない。今回は、TLN231(上表参考)
– 光度
光度は発光体が大きいほど、強くなる。単
位面積あたりの光度を輝度といい、発光体
や反射体の輝きを表します。カンデラは発光
する強さを表す、光度の単位である。
１本のろうそくの光の強さを１キャンドルで
ある。すなわち、ロウソクの光の強さが約１
カンデラ (cd) となる。
を使用することにした。
– 赤外 LED の計算
Vcc=5V
R
– 輝度
輝度は１平方メートルあたりのカンデラで表
38KHz
IR_LED
about 1mA
す。まぶしさのにつながるものである。
• 赤外 LED(TLN231)
図 60: LED とトランジスタ
– 赤外 LED の選定
赤外 LED の選定で重視することは、上で述
べた LED の放射強度と、半値角 ( 21 θ) であ
る。下に、入手できる赤外 LED を示す。
TLN231 に掛かる電流の最大定格は 100mA、
今回 LED に流す順電流は 70mA での LED
へ掛かる電圧は約 2V である。以上のことか
41
ら、Vcc は 5V より、
ボタンを押す。するとリモコンからは、ある決められ
たコマンドの赤外線がテレビに放たれる。そして、テ
レビは、受け取ったコマンドを認識して局をかえる。
(供給電圧 − CE 間電圧 − LED 電圧)
流したい電流
このしくみを、模型飛行船と基地局の間の通信に応用
させる。
=R
5 − 0.9 − 2
=
140 × 10−3
= 14[Ω]
(18)
(19)
Airship
LED 一つに対して 14[Ω] の抵抗をつける。
B.3
赤外線受信回路
図 63: テレビと飛行船
例えば、基地局が送信する場合指定したコマンドを送
りそれを飛行船が受信し、コマンドと一致した動作 (上
昇、直進など)、逆に飛行船から計算した値をコマンド
で送り、基地局でコマンドから得ることもできる。
1 1 1 1 0 1 0 1
command1
図 61: 赤外線受信機
command1
Vcc_5V
図 64: コマンドの送信
R
out
47uf
GND
図 62: 赤外線受信回路
B.4
LED での通信
リモコンのボタンを押すと、テレビの局が変わるの
は、赤外線通信をしているからである。例えば、電源
42
Airship
図目次
1
2
3
4
5
6
7
8
9
10
11
12
13
17
14
15
16
18
19
20
21
22
23
24
25
26
27
28
30
29
31
抽象度とプロセス . . . . . . . . . . . .
MOF 階層構造 . . . .
開発プロセス . . . . .
マッピング . . . . . .
組込みシステムの現状
組込み MDD プロセス
最終目標 . . . . . . . .
チャレンジ概要 . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
カメラの利用 . . . . . . . . . . . . . .
US マトリクス . . . . . . . . . . . . .
コンテスト . . . . . . . . . . . . . . .
コンパルソリー . . . . . . . . . . . . .
会場の様子 . . . . . . . . . . . . . . .
飛行船に搭載した回路 . . . . . . . . .
エンベローブ . . . . . . . . . . . . . .
飛行船ゴンドラ . . . . . . . . . . . . .
飛行船に搭載した回路 . . . . . . . . .
飛行船の直進-正回転時間と逆回転時間
飛行船基本動作の一例 . . . . . . . . .
X-Y 軸制御戦略 . . . . . . . . . . . .
Z 軸制御戦略 . . . . . . . . . . . . . .
GrPC-Airship の関係 . . . . . . . . . .
全体概念図 . . . . . . . . . . . . . . .
9
9
11
12
12
13
13
13
14
14
15
15
15
16
17
.
.
.
.
.
18
20
21
21
22
23
23
24
GrPC、Monitor、Height、Direction、
Position のステートマシン図 . . . . . .
25
33
34
Command のステートマシン図 . . . .
基地局実装クラス図 . . . . . . . . . .
26
27
35
36
超音波送信回路 . . . . . . . . . . . . .
角度 . . . . . . . . . . . . . . . . . . .
28
28
37
38
USMPU からの受信データ . . . . . . .
超音波送信機 . . . . . . . . . . . . . .
29
33
39
40
超音波送信回路 . . . . . . . . . . . . .
33
33
32
飛行船のオブジェクト図 . . . . . . . .
4
4
5
6
6
7
7
8
飛行船の実装クラス図 . . . . . . . . .
飛行船のシーケンス図 . . . . . . . . .
Umbrello での書き方 . . .
飛行船のステートマシン図
基地局の非同期シーケンス
基地局オブジェクト図 . .
基地局の同期シーケンス .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
超音波センサ振動子の運動 . . . . . . .
41
42
43
デューティー比 . . . . . . . . . . . . .
抵抗とコンデンサの関係 . . . . . . . .
34
34
34
44
45
46
47
48
49
50
51
52
53
54
56
Hex invertor In-Out 特性 . . .
波形の比較 . . . . . . . . . .
ADM3202 出力電圧特性 . . .
超音波受信会回路 . . . . . . .
反転増幅回路 . . . . . . . . .
オペアンプの出力電圧特性 . .
AC フォトカプラ . . . . . . .
AC フォトカプラの特性 . . .
飛行船の地面からの高さ . . .
3 端子レギュレータの基本回路
カメラから見た赤外線 . . . .
赤外線送信機 . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
35
35
35
36
36
36
36
36
37
38
39
39
57
55
58
59
60
61
62
63
64
赤外線送信時のバースト波形 . . . . . .
39
40
40
40
41
42
42
42
42
無安定動作回路 . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
赤外線送信回路 . . . . . . . . . . . . .
タイマー IC833Hz と 26KHz . . . . . .
タイマー IC の出力波形
LED とトランジスタ
赤外線受信機 . . . .
赤外線受信回路 . . .
テレビと飛行船 . . .
コマンドの送信 . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
表目次
43
1
2
5
3
4
6
MDA モデル . . . . . . . . . . . . . . .
組込みシステムでのモデリング効果 . .
ハードウェアとソフトウェアの機能分割
US マトリクス座標 . . . . . . . . . . .
日本科学未来館と砂漠との比較 . . . .
前進後退時のモータ回転時間と距離 . .
5
7
10
11
12
14
7
8
旋回時のモータ回転時間と角度 . . . .
14
17
9
10
自律飛行システム中の提供物利用状況 .
飛行船モデルの作成プロセス . . . . . .
ImgPC からの受信データ . . . . . . .
26
28
11
12
提供 API の結果スケジュール . . . . .
開発スケジュール . . . . . . . . . . . .
31
31
13
14
Inverter DC 特性 . . . . . . . . . . . .
光の単位 . . . . . . . . . . . . . . . . .
35
41
15
LED 一覧 . . . . . . . . . . . . . . . .
41
参考文献
[1] 社団法人情報処理学会ソフトウェア工学研究会
”MDD ロボットチャレンジ 2004 産学連携による
組込みソフトウェア開発実践”
社団法人情報処理学会,2005
[2] Leon Starr,”Executable UML 実践入門”
CQ 出版株式会社 2004
[3] Linux オンラインマニュアル
http://www.linux.or.jp/JM/INDEX/ldp.html
[4] 独習 UML
株式会社テクノロジックアート著長瀬嘉秀/橋本
大輔監修株式会社翔泳社 2005
[5] MDD ロボットチャレンジ競技仕様書
MDD ロボットチャレンジ 2005 推進委員会/審査
委員会
[6] 組み込み UML-eUML によるオブジェクト指向組
み込みシステム開発
著渡辺博之/堀松和人/渡辺政彦/渡守武和記翔
泳社 2002 年
[7] MDA(モデル駆動アーキテクチャ) と MDD(モデ
ル駆動開発)
著沢田篤史京都大学学術情報メディアセンター
[8] Executable UML 実践入門クラス・モデルをいか
に作成するか
著レオン・スター監訳長瀬嘉秀/二上貴夫 CQ 出
版株式会社
44

Download Report