東海大学 2005年度 卒業研究2

UMLを用いたライントレースシステムの開発

指導教員 清水尚彦 教授

2ADT1233 屋敷 和宏東海大学 電子情報学部 コミュニケーション工学科

1

目 次

1 はじめに 6

2 ETソフトウエアデザイン

ロボットコンテスト 72.1 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 タイムトライアル部門 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 モデリング部門 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 開発手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 走行体の基礎知識収集及び組立て . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 LEGO Mindstorms™ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 RCX (Robotics Command System) . . . . . . . . . . . . . . . . . . . . . . 82.3.3 センサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.4 モータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.5 IRタワー (赤外線転送装置) . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.6 走行体の組立て . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 開発環境構築 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.1 構築手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.2 開発環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 基礎実験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.1 モータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.2 光センサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.3 主な I/O命令の実行時間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.4 電池について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.5 スカートの装着について . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6 要求分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6.1 基本走行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6.2 コースポジション別走行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6.3 光センサ値の演算処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.7 内部設計 (ソフトウェア開発) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.7.1 ユースケース図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.7.2 ステートマシン図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.7.3 タイミング図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.7.4 クラス図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.8 実装 (プログラミング・テスト・運用・保守) . . . . . . . . . . . . . . . . . . . . . 282.8.1 センサー部分 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.8.2 ステアリング部分 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.8.3 ステート遷移部分 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.9 結果と考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.9.1 コンテスト結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.9.2 実装コードについての考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.9.3 モデリングについての考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2

2.9.4 プロセスモデルについての考察 . . . . . . . . . . . . . . . . . . . . . . . . 302.10 再検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.10.1 マルチタスク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.10.2 ヒープ領域 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.10.3 光センサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.10.4 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 まとめ 39

4 謝辞 40

3

図 目 次

1 ウォーターフォール・モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 RCX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 H8マイコンのメモリ構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 ファームウエア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 数字の表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 アルファベット表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 パワーが 8の場合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 パワーが 4の場合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 パワーが 1の場合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310 光センサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1411 タッチセンサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1412 モータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514 シリアル接続用 IRタワー (外観) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1513 RCXと IRタワーの変調方式 (ASK方式) . . . . . . . . . . . . . . . . . . . . . . . 1615 シリアル接続用 IRタワー (背面) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616 USB接続用 IRタワー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617 転送範囲 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1718 走行体 (PathFinder) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1719 プログラムのダウンロード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1820 光センサのセンシングイメージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2021 コースポジションの分け方 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2122 走行システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2323 走行体に行なう設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2324 メインシステム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2325 コースポジションシステム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2428 方向ステートマシン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2426 走行システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2527 走行ステートマシン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2629 コースポジションステートマシン . . . . . . . . . . . . . . . . . . . . . . . . . . . 2730 タイミング図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2931 クラス図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2932 スパイラルモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3033 シングルタスク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3537 光センサ値データ (黒線) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3538 光センサ値データ (白) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3639 光センサ値データ (境界) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3634 マルチタスク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3735 異なる優先度の実行動作実験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3736 等しい優先度の実行動作環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4

表 目 次

1 各開発工程における目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 セグメント表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 角度とステアリング用モータ駆動時間の関係 . . . . . . . . . . . . . . . . . . . . . 184 光センサ値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5

1 はじめに

近年、システムの開発を円滑に進めるために

UML(Unified Modeling Language)というモデリング言語が、多くの技術者に使われ始めてい

る。モデリング言語とはオブジェクト指向のソ

フトウェア開発における、プログラム設計図の

統一表記法である。設計図の表記が統一される

ことによる利点とは、開発するシステムを開発

エンジニア間で情報の共有が行ないやすく、ま

た個人で開発する際も考えたアルゴリズムを整

理しやすいなど、様々な利点がある。

この一年間を通じ、実践で UMLを用いて組込みソフトウェアの開発を行なった。参加した

企画は「ETソフトウェアデザインロボットコンテスト」である。

本稿は、第 II部は「ETソフトウェアデザインコンテスト」開発の詳細について説明する。

第 III部は「まとめ」研究を通じてのまとめをする。第 IV部は「謝辞」と構成される。

6

2 ETソフトウエアデザイン

ロボットコンテスト

2.1 概要

ETソフトウェアデザインロボットコンテストとは、昨年までに開催されていた UMLロボットコンテストを継承発展させたロボコンである。

コンテスト開催の目的は組込みソフトウェア

開発分野における若年層および初級エンジニア

への分析・設計モデリングの教育機会を提供す

ることとなっている。よってコンテスト参加者

は技術研修でモデリング基礎教育を 2回実施し、コンテスト前には、本番コースによる試走会機

会を提供している。さらには、参加者がコンテ

スト終了後の教育に生かすことのできる素材と

して提出したモデルに対して審査員による評価

コメントや、全出場チームのモデル図を収めた

CD-ROMがコンテスト後に全出場チームに配布される。

コンテストの審査部門としては、「タイムト

ライアル部門」と「モデリング部門」の 2つから構成させる。

2.1.1 タイムトライアル部門

スタート後トラック内に書かれたコースを追

尾しながら中間ゲートを通過、ゴールゲートを

通過するまでの時間を競う。

走行体は必ずしもコースに沿って走行しなく

ても、中間ゲートを規定の方向から通過、ゴー

ルゲートを通過すれば 1周したものとみなす。IN・OUTの 2コースがあり、2周ずつ走行

しタイムを測定を行なう。どちらかの早いタイ

ムが記録となる。トラックは 364cmx546cmの白い発砲スチロールに IN・OUTともに 1周約20mの黒色のビニールテープでコースが作られている。

平坦なコースだけではなく「上り坂」、「下り

坂」、コースが発砲スチロールと等間隔に作ら

れている「点線」や、鉛筆ほどの丸太がコース

の左右に数本敷かれている「オフロード」など

がコースの各所にある。

2.1.2 モデリング部門

モデリングは設計を中心に審査基準を決めた

うえで行なう。審査の対象としては、モデルの

見易さやアルゴリズムのユニークさなど、外観

と中身の両方を審査の対象としている。

また、審査員はコンテストの実行委員から選

出される。

2.2 開発手順

UMLによって定義されているのは、モデルの表記法だけであり、システム開発のための方

法論 (開発の手順など)は含まれていない。そのため実際の開発では、UMLとは別に開発方法論が必要になる。

そこで開発手順には「ウォーターフォール・

モデル」(図 1) を用いた。「ウォーターフォール・モデル」とはソフトウェア開発の過程をス

テップに分けて、各工程終了時に、その工程の

生産物を作成して次の段階へ引き渡していく。

この形態がまるで「滝」が流れる様にみえる

ので「ウォーターフォール・モデル」と呼ばれ

ている。各開発工程とその目的を表 2.2に示す。

要求分析

外部設計

内部設計

プログラミング

テスト

開発工程

運用・保守

図 1: ウォーターフォール・モデル

コンテストの競技規約には「コンテストでは

ソフトウェアの優劣をつける為走行体は規定の

物を用いる」となっている。つまりハードウェ

アとなる走行体は規定されているため、組立て

るだけなのでウォーターフォール・モデルの外

7

表 1: 各開発工程における目的開発工程 目的・内容

要求分析 システムの機能や要求を明確にする

外部設計 ユーザからみた外部インターフェースの設計

内部設計 システムの内部 (詳細機能)を設計

プログラミング 実際にプログラミング・コードの単体テスト

テスト 開発したシステムの結合テスト

運用・保守 運用後に判明した不具合の改修や細かい改良

部設計工程は省略する。

そして、要求分析の前段階として走行体の基

礎実験を行ない、特性を考慮した上で要求分析

を行なう。よって、要求分析の前に走行体を組

み立て、開発環境を構築をしなければいけない。

以上を踏まえてコンテストにおけるシステム

開発の手順を以下に示す。

1. 走行体の基礎知識収集及び組立て

2. 開発環境構築

3. 基礎実験

4. 要求分析

5. 内部設計

6. プログラミング

7. テスト

8. 運用・保守

2.3 走行体の基礎知識収集及び組立て

コンテストにおける走行体は LEGO Mind-storms™というキットを大会の指定する走行体に組立てます。

2.3.1 LEGO Mindstorms™

LEGO Mindstorms™とはブロック玩具としても有名な Lego社が Mindstormsと呼ばれるロボットキットを提供しています。このキット

の一番の特徴は RCXと呼ばれる大きな黄色のブロック (縦 95mm x 横 65mm x 高さ 40mm)にマイコンが内蔵している点である。

他にもセンサやモータなども含まれているの

で、様々なブロックを組立てることによって自

由に動くロボットが作れるキットとなっている。

ロボットを動かすプログラムを作るには、C言語や Visual Basic、Java 言語など様々なプログラミング言語を使うことができる。さらに

「ROBOLAB」という専用のソフトウェアを使用することでプログラミングされたパーツを

つなぎ合わせてロボットを動かすことも可能で

ある。

作成したプログラムはキットに付属している

IRタワー (赤外線転送装置)で RCX へ転送することができる。

2.3.2 RCX (Robotics Command Sys-tem)

• マイコンRCXは 8ビットのマイコン (日立製H8/3292)を内蔵し、ロボットの頭脳の役割をして

いる。さらにはこのマイコンを動作させ

るための電源として RCXのブロックの下半分に 6本の単 3乾電池が収納されていて、9Vで動作する。

H8マイコンには、16KバイトのROM(ReadOnly Memory)と 32KバイトのRAM(RandomAccess Memory)を搭載している。

16Kバイトの ROMには、RCXのメインオペレーティングシステムであるファー

ムウェアをダウンロードするために初期

プログラムが入っている。この初期プロ

グラムは電圧が低くなっても消えること

はない。RCXにファームウェアがダウンロードされていない場合にはこのプログ

ラムが起動し、ファームウェアのダウン

ロードが行われる。

32Kバイトの RAMには一部 ROMプログラム実行のために予約されている。残り

の RAM空間を使って、RCX用のファームウェア、あるいは OSとユーザプログラムが動作する。RAMは揮発性メモリなので ROMとは異なり、十分な電圧がなく

8

図 2: RCX

なると内容が消えてしまう。

• ファームウェアファームウェアとは、ハードウェアの基

本的な制御を行なうために機器に組込ま

れたソフトウェアのことである。機器に

固定的に搭載され、あまり変更が加えら

れないことから、ハードウェアとソフト

ウェアの中間的な存在としてファームウェ

アと呼ばれている。

RCXには brickOSというRCXモジュール用のフリーの OSを実装する。ソースコードは C言語であり、独自の APIが提供されている。

• A/D変換器

H8マイコンには 10ビットのA/D変換器も搭載している。入力ポートからアナロ

グ信号を 10ビットの分解能でデジタル信号に変換する。

• 必要電圧RCXを動かすために必要な電圧は、9v～6.7vである。RCXは 6.3v以下になると

RAM 32Kbyte

ROM 16Kbyte

User Program

Firmware

Initial Program

図 3: H8マイコンのメモリ構成

Software

Firmware

Hardware

図 4: ファームウエア

音を鳴らしてユーザーに警告をする。

• A/Cアダプタ

RCXには赤外線ポートの反対側の面にA/Cアダプタを接続するすると約 9.9vの電圧供給する。

• サウンドRCXには内蔵のスピーカがある。音を鳴らすことはもちろんのこと、音楽なども

作成可能である。

• ボタンLCDの左右合わせて 4つのボタンがある。赤色の On・Offボタンは電源のスイッチである。一度押すと音が鳴り、電源が入

る。もう一度押すと再び音が鳴り、電源が

切れる。緑色の Runボタンはプログラムを実行するボタンである。プログラムを

9

実行すると、プログラム通りに走行体が

動き始める。黒色の Viewボタンと灰色の Prgm(プログラム)ボタンは brickOSでは機能が割り当てられていない。よっ

て Viewボタンや Prgmボタン押しても何も brickOSから命令が実行されないので、走行体に変化はない。

また、LEGO Mindstorms™の標準のファームウェアでは Viewボタンは入出力における現在の値を表示する。Viewボタンを押すごとに入出力ポート用のセグメ

ントが変わり、選択されたポートの値を

表示する。Prgmボタンは、プログラムを複数 RCXに記憶させた時にどのプログラムを実行するのか選択する場合に用い

る。プログラムは 5つ記憶させることが可能であり、実行する前にボタンを押し

て決定する。、一番右の数字が 1番から 5番まで変化して、また 1番に戻る。

• LCD(liquid crystal display)

RCXの LCDには、様々な情報が表示することが可能である。例えばプログラム

の転送状況や実行するプログラムの番号、

プログラムが実行中かどうか、バッテリ

の状況、入出力ポートの値、モータの回

転方向などが表示できる。

ただし、brickOSでは LCDについてユーザーがプログラムを記述しない場合は人

形の絵と一番右に数字の 1が表示されるだけである。言い換えると、ユーザーが

欲しい情報をプログラムに記述すると表

示することができると言える。

数字やアルファベットを表示する場合に

LCDで 5桁まで表示を可能である。ただし、数字や文字を構成するセグメントが

1桁表示するのに 8つしかないので注意が必要である。表 2に同じセグメント表示を列挙する。

表 2: セグメント表示same display

0-O

1-i-I

2-z-Z

5-s-S

7-T

a-A

b-B

d-D

e-E

f-F

g-G

H-x-X-k-K

j-J

l-L

m-n

M-N

p-P

q-Q

r-R

u-v-w

U-V-W

y-Y

10

LCDNumber

0

1

2

3

4

5

6

7

8

9

図 5: 数字の表示

11

LCDAlphabet

a

b

c

d

e

f

g

h

i

j

k

l

m

A

B

C

D

E

F

G

H

I

J

K

L

M

LCDAlphabet LCDAlphabet

n

o

p

q

r

s

t

u

v

w

x

y

z

N

O

P

Q

R

S

T

U

V

W

X

Y

Z

LCDAlphabet

図 6: アルファベット表示

12

• 入力ポートRCXには灰色の入力ポート (入力端子 1、2、3)が 3つあります。ここには周りの状況を判断するためのセンサを接続します。

取得する値は 0v～5vの範囲である。

• 出力ポート黒色の出力ポート (出力端子A、B、C)も3つあり、ここには RCXのコンピュータが制御するモータやランプを接続します。

出力ポートに接続されたモータのスピー

ドやランプの明るさは、約 9vの電圧を何秒間出力するのかで変化します。

出力のパワーは 8段階に設定できますが、パワー 8の場合には 9vの電圧を 8ms出力した後に 0vを 1ms出力します。(図 7)パワー 4の場合には 9vの電圧を 4ms出力した後に 0vを 5ms出力します。(図 8)パワー 1の場合には 9vの電圧を 1ms出力した後に 0vを 8ms出力します。(図 9)出力ポートには、制御デバイス 6つまで接続できますが、追加した制御デバイス

の分だけ電池の消耗が早くなります。

電圧(v)

時間(ms)

10

5

0 5 10

v

ms

図 7: パワーが 8の場合

2.3.3 センサ

LEGO Mindstorms™にはセンサが組込まれてブラックボックス化したブロックがいくつかあ

る。これらを入力ポートに接続することでRCXに現在の状況を知らせることができる。センサ

をうまく使いこなすことで複雑な制御ができる

ことになる。

電圧(v)

時間(ms)

10

5

0 5 10

v

ms

図 8: パワーが 4の場合

電圧(v)

時間(ms)

10

5

0 5 10

v

ms

図 9: パワーが 1の場合

• 光センサ光センサ (青色のブロック)には、発光ダイオードと受光素子がブロックの先端に

ついている。発光ダイオードから光が出

力し、その反射光を受光素子が検出する。

そして反射光を受けた受光素子は、光の

強さに応じた電圧を発生させる。さらに、

光センサの内部にある電圧増幅回路が受

光素子で発生した電圧を増幅する。RCXはこの電圧の変化を読み取り、明るさを

検出する仕組みになっている。

測定値としては 0～100まで値を検出するが、実際には 20～70程度の値が検出される。明るい所では 100に値が近く、暗い所では 0に近い値となる。

• タッチセンサタッチセンサ (灰色のブロック)はブロック先端に黄色部分があり、ここで状態を

検出しています。タッチセンサのの内部

は金属端子 2つと導電ゴム 1つで構成さ

13

図 10: 光センサ

れている。タッチセンサが押されていな

いときは、金属端子は接触していないた

めに抵抗値は無限大となる。一方タッチ

センサが押されているときは、導電ゴム

が押されて、2つの金属端子が接触して抵抗値は約 500Ωになる。このような抵抗値の変化を RCXが読み取りタッチセンサが押されているか、押されていない

かを判断しています。

検出される値は、タッチセンサが押され

ているとき (On)に「1」押されていないときに (Off)「0」を検出する。

図 11: タッチセンサ

• 温度センサ温度センサ (黄色のブロック)は温度を測定するセンサである。先端の金属部分で測

定を行なっている。測定範囲は-20℃～50℃である。ちなみに温度センサは耐水性が

ないために水中での測定は避けたほうがよ

い。(温度センサは LEGO Mindstorms™の基本セットには含まれていない)

• 角度センサ角度センサ (青色のブロック)はブロックの長い辺に穴があいている。そこにキッ

トの中「シャフト」と呼ばれる棒状の部

品を穴に通して、この回転した角度を検

出するセンサである。シャフトを 1回転すると値が「16」変化する。つまり 360度回転して 16変化するいうことは、言い換えると 1回転が 16段階になっている。

360(度)÷ 16(段階) = 22.5度/段階 (1)

数式 (1)の計算より 1段階で 22.5度回転したことがわかり、検出された値を参照

して「シャフト」が何度回転したのかが計

測できる。(角度センサもタッチセンサと同様に LEGO Mindstorms™の基本セットには含まれていない。)

2.3.4 モータ

モータ (灰色のブロック)はLEGO Mindstorms™のキットの中にある様々な「ギア」を用いて、

出力ポートに接続することで駆動することがで

きる。モータのスピードは 0～255まで設定できる。さらに、回転する方向は順回転と逆回転

があり、その他惰性回転とブレーキの 4つの動きを設定できる。

14

図 12: モータ

2.3.5 IRタワー (赤外線転送装置)

• 変調方式送信する情報を搬送波という電波に乗せ

て通信しやすい電波に変換することを変

調と呼ぶ。変調方式には大きく分けて 2種類ある。1つはアナログの情報を変調するための「アナログ変調方式」、もう一方

はデジタルの情報を変調するための「デ

ジタル変調方式」である。

アナログ変調方式には、振幅変調 (AM)、周波数変調 (FM)、位相変調 (PM)などがある。振幅変調 (AM)は搬送波の振幅の変化で変調を行ない、周波数変調 (FM)は搬送波の周波数の変化で変調を行ない

ます。また、位相変調 (PM)は搬送波の位相の変化で変調を行なう。

デジタル変調方式には ASK 方式、FSK方式、PSK 方式があり、それぞれ AM、FM、PM方式を利用してデジタル情報を変調します。

• 通信方法IRタワーとはコンピュータに接続し、赤外線を使ってコンピュータで作成したプロ

グラムをRCXに送信する装置である。IRとは「Infrared Radiation」の略で、赤外線のことをを指す。RCXと IRタワーは、2400ビット/sの通信速度を持ちスタート

ビットが 1、データが 8ビット、パリティビットが 1、ストップビット 1のデータを、38KHzに変調した赤外線で通信を行なっている。

• シリアル接続シリアル接続用の IRタワーには背面に電池を入れる場所がある。シリアル接続

用の IRタワーには 9vの積層電池で動作している。そして付属のケーブルでコン

ピュータとシリアル接続用の IRタワーを接続して赤外線通信を行なうことがで

きる。

シリアル接続用の IRタワーの下にスイッチがある。これは赤外線の強さを変更す

るためのスイッチで、右と左の 2段階に設定できる。左のスイッチが「弱」で右の

スイッチが「強」となる。ただし、スイッ

チを「強」で使用する場合には付近にあ

る他の RCXにプログラムをとばしてしまうことがあるので注意が必要である。

図 14: シリアル接続用 IRタワー (外観)

15

変調データ

変調信号

ASK方式

スタートビット データ パリティビット ストップビット

1 1 1 1 1 10 0 0 0 0

図 13: RCXと IRタワーの変調方式 (ASK方式)

図 15: シリアル接続用 IRタワー (背面)

• USB接続

シリアル接続用の IRタワーの他に USB接続の IRタワーがある。このタワーもシリアル接続同様にコンピュータに接続

して RCXにプログラムを赤外線通信できる。

USB接続用の IRタワーにはシリアル接続用のようにスイッチはついていなく、デ

バイスドライバで赤外線の「強」「弱」を

変更できる。

• 転送範囲RCXと IRタワーの距離は 50cm以内で、角度は約 35度以内である。

図 16: USB接続用 IRタワー

2.3.6 走行体の組立て

走行体はコンテストの委員会から規定され

ている。コンテスト仕様 (PathFinderと呼ばれている)の走行体を、「MLcad」という LEGOMindstorms™専用のソフトを使用して組立てる。

完成した大会仕様の走行体を図 18に示す。

16

35°

IR Tower

RCX

50cm

図 17: 転送範囲

2.4 開発環境構築

2.4.1 構築手順

RCXにプログラムをダウンロードするまでの開発環境構築手順を以下に示す。

• Cygwinインストール

• Cygwinの PATH環境変数の設定

• クロスコンパイル環境設定

• brickOSのインストール

• RCXに brickOSをダウンロード

• RCXにデモプログラムをダウンロード(テスト)

クロスコンパイラとは、プログラマが高等言

語で作成したソースコードを解釈し、開発に使

用しているのとは異なる機種で実行可能な機械

語のプログラムを生成するソフトウェアのこと

を指す。つまり、パソコン上で H8用のソフトウェアをコンパイルし、出来た実行ファイルを

H8マイコンに書き込むことをクロスコンパイルと呼ぶ。

図 18: 走行体 (PathFinder)

2.4.2 開発環境

構築した開発環境を以下に示す。

• プログラミング環境

– OS

WindowsXP

– 開発環境ソフトウェア

Cygwin

• 実行環境

– LEGO Mindstorms™上の実行OS brickOS

• コンパイル環境H8コンパイラ

2.5 基礎実験

実際にコンテストで用いるコースと同様の大

きさのコースを作り、分析工程の前段階として

走行体の基礎データ収集を行った。

2.5.1 モータ

• トップスピードコース中で最もスピードの出るOUTコースのスタート地点から始まるストレート

のタイムを測定した。この際のモータス

ピードの設定値は「0」から「255」まで

17

図 19: プログラムのダウンロード

設定可能となっていて、モータのスピー

ドは駆動用モータを 255(最大)、ステアリング用モータを 0(最小)とした。

実験から得られたトップスピードの秒速

を以下に述べる。

– 秒速 約 96cm/s

– 1cmあたり 10’42ms/cm

• ステアリングを駆動しながらの速度ステアリングを左右に振りながらでは走行

体の速度は振っていない時に比べて変化す

るのか実験を行なった。実験の条件は「ト

ップスピード」と比較するため駆動用モー

タ、ステアリング用モータを 255(MAX)にし 40msごとに左右交互にステアリング用モータを反転させた。

– ステアリング用モータスピード 0

秒速 105.2cm/s

– ステアリング用モータスピード 255

秒速 82.5cm/s

• ステアリング制御 (ステアリング用モータ)

ステアリング用モータと角度の関係を実

験し、ステアリング制御の目安の例とし

てデータを取る。ステアリング用モータ

を駆動して、角度をごとに必要な駆動時

間を調べる。角度とステアリングの関係

を示した実験結果を表 3に示す。

表 3: 角度とステアリング用モータ駆動時間の関係

角度 駆動時間

5 1210 2615 4220 5225 7030 8435 9640 11245 13050 148

• 坂道を上る最低スピード大会コースの坂道の勾配は、上りが約 4パーセント、下りが約 2パーセントとコースのデータがコンテスト実行委員会より

公開されている。

どんなに安定した走行であっても坂を上

れなければならない。そこで駆動用モー

タスピードを 255(最大)に設定して坂を上ることに必要なスピードを実験した。

– 坂を上る最低スピードは駆動用モー

タスピード 210

実験結果からは駆動用モータスピード 210が最低値となったが坂を上る様子はギリギ

リ止まらずに前進している程度のスピー

ドであった。

• 駆動用モータとブレーキの関係

18

一定時間走行させてブレーキをかけて、慣

性力で進んだ距離を測定する。ブレーキ

の強さはどの程度なのか調べた。つまり

平地と下り坂での慣性力によりどれだけ

進むのか、実験を行った。実験方法とし

ては「走行体の速度」と同様なモータス

ピードを設定して行なう。

実験から得られたブレーキの制動力を以

下に述べる。

– 平地 約 10～15cm慣性力で進む

– 坂道 慣性で坂の下まで進む

2.5.2 光センサ

自作のコースや試走会などで光センサの値を

調べた。コースは色で分けると黒、漆黒、白、

緑と 4色に分けることができ、それぞれの色がどこに存在するのかを以下に示す。

• 黒（コース上-通常）

• 漆黒（コース上-ショートカット前後・坂道の前に設置）

• 白（コース外-黒線の周り）

• 緑 [芝生]（コース外-白のさらに外側）

光センサがコースでどのような値を取得してき

ているのかを表 4に示す。　

表 4: 光センサ値

最小 最大 平均

黒線 26 32 30.00漆黒線 25 27 26.08白 42 44 43.67緑 30 31 30.33

2.5.3 主な I/O命令の実行時間

光センサやモータの関数を呼び、値が返って

くるまでの時間を測定した。実験結果を以下に

述べる。

• 光センサの値取得にかかる時間　12.20μ s/回

• 1つのモータを制御を行なうのにかかる時間

　69.60μ s/回

• 2つのモータを制御を行なうにかかる時間

　132.00μ s/回

• 光センサと２つのモータの値を取得及び制御にかかる時間

　43.90μ s/回

2.5.4 電池について

2.5.5 スカートの装着について

スカートとは光センサに装着する遮光材を指

す。スカートの装着は強制ではないが運営委員

会が推奨している。理由はスカートを装着する

ことで外部からの光の影響を受けにくくなるか

らである。

実験すると、スカート装着した状態での光セ

ンサの値は約「1」減少する。スカートを装着することで外光からの影響を軽減することができ

るためにスカートを使用することに決定した。

2.6 要求分析

基礎実験から得られたデータをもとに走行に

必要な要素技術の分析をする。コースを早く走

るためには常に同じではなく、状況に応じた走

行方法に切り替えた方が早く走ることができる。

よってコースを完走する為の走行方法と状況別

の走行方法を考えた。

19

2.6.1 基本走行

まず基本的な走り方をどのような動きにする

かを検討した。常に蛇行しながら走る方法（以

下 　エッジ走行）は、提供されたサンプルプロ

グラムや試走会などでもこの走行方法を使用し

ているチームが多かった。そこで我々は新規性

の高い走行方法で他のチームとの差別化を図る

為に「黒線ではステアリングを切らずに白を検

知したらステアリングを切り黒線に復帰する」

という走行方法を基本走行とした。

基本走行とエッジ走行の違いを光センサのセ

ンシングイメージとして図 20に示す。

図 20: 光センサのセンシングイメージ

2.6.2 コースポジション別走行

コースポジション別走行とは基本走行のオプ

ションとして付加する走行方法である。コース

ポジションにあった最適なモータ制御を付加す

ることを目的とする。そしてコースポジション

別の走行方法の共通部分を抽出しこれを基本走

行とする。コースを直線、カーブ、坂（上り、下

り）、点線、オフロードという６つをコースポ

ジションとして分ける。コース上のポジション

分けを図 21示す。そしてコースポジションごとに最適な走行方

法や状態が遷移する条件を考える。

• ストレートストレートは基本走行を行なう。

コースポジション別走行でストレートに

遷移するには、遷移する条件を時間で制

御を行なう方法（以下 　タイマ制御）を

用いる。ストレート以外の状態に遷移し

ている時（上り坂・下り坂を除く）一定

時間以上黒線の値を光センサが、連続取

得してきた場合にストレートに状態遷移

する。

　

• カーブ駆動用モータスピードを減速する。

カーブではコースアウトする可能性が高

い。なぜならば、基本走行は白を検知す

るまでステアリングを切らないためその

間の駆動用モータはによって黒線から遠

ざかってしまうからである。よってカーブ

で白を検知して黒線を探している間（以

下 　サーチ動作）は駆動用モータスピー

ドを減速することが最適であると考えた。

減速するパラメータについては、実験を

重ねていきフィードバックして決定する。

• 坂（上り）駆動用モータをフルスピード (255)で回転させる。

上り坂は駆動用モータスピードが 210以上でないと上ることができない。しかし、

駆動用モータスピードが 210では非常に遅いので上り坂はフルスピードが要求さ

れる。カーブとは異なり走行体は直線と

坂の区別がつかない。「上り坂」だという

ことを走行体に教えるには 2つ方法の方法を用いて実現できる。

– 漆黒線による状態遷移方法

坂の前に漆黒線があるのでセンサ値

の変化で状態遷移を行なう。

– タイマ制御方法

実験から漆黒線を通過する時間を計

測した上で設定をした時間に状態遷

移を行なうというものである。

漆黒線による状態遷移方法は、黒線上で

光センサが取得してくる値にはばらつき

20

図 21: コースポジションの分け方

21

があり、基礎実験から黒線上でも漆黒線

上にいるような値を取得してしまうこと

がわかっている。そして、タイマ制御方

法はコースアウトした場合にサーチ動作

の時間が一定でないため信頼性に欠ける。

各単体での上り坂の遷移は難しいが、こ

の 2つの方法を合わせることで状態遷移が可能になる。

タイマ制御で想定する漆黒線を通過する

時間に、ある程度幅を持たせる。その時

間内に漆黒線と思われる値を光センサか

ら取得してきた時のみ状態遷移を行なう。

漆黒線の値は黒線と必ず判別できないこ

とから、上記の 2つの方法を用いて上り坂のコースポジション別走行とする。

• 坂（下り）タイマ制御によって駆動用モータスピー

ドを減速する。

下り坂については上り坂の状態遷移をが

行われたと同時にタイマ制御をし始める。

実験によって上り坂が終わり、下り坂の途

中にくるおおよその時間を計測する。そ

して、この時間になったら駆動用モータ

スピードを減速する。なぜならば、上り

坂を駆動用モータスピード 255で駆け上がると、下りの勾配でさらにスピードが

増してしまうからである。この場合、下り

坂直後のカーブで走行体には駆動用モー

タが 255以上のスピードで走行しているのでコースアウトした場合コースに復帰

できないからである。

• 点線基本走行で点線も黒線同様に走行できる

点線走行は上り坂や下り坂とは違い、基

本走行では間違いなくコースアウトして

しまう。上り坂の遷移条件の様に 2つの方法を用いても必ず遷移できる保障はな

い。2つの方法で状態遷移の誤動作は回避できるが、遷移できるかは結局のとこ

ろ漆黒線である。

そこで、基本走行で点線も黒線と同様に

走行できるものにした。点線の間（白）は

1cmで基礎実験から 1cmを通過する時間は 10’42ms/cmである。ステアリングを切った瞬間などで設定した値より駆動用

モータスピードが減速していることも考

えられる。この遅れを補うために 30％の誤差を踏まえて通過時間を 15msとする。点線を黒線同様に走行するにはには白を

検知し続けても 15msはステアリングは固定し、サーチ動作を行わない。こうす

ることで点線も黒線同様に走行が実現で

きる。 　

• オフロードINコースについてはショートカットを行わない。

ステアリング用モータスピード「0」、駆動用モータをフルパワー「255」で走行実験を行った。結果は数回に 1回という安定しない結果が出てきた。理由としては

オフロードの丸太の前輪が固定され、身

動きが取れない状態になることが挙げら

れる。よってオフロードはリスクが高い

為に INコースにおけるショートカット行わないことにする。

2.6.3 光センサ値の演算処理

光センサは外部の光による影響や黒テープの

張り方によっていろいろな値が取得される。黒

線にいるにもかかわらず白のような値が取得す

ることもある。この例外的な値でステアリング

制御を行なうとコースアウトの可能性が非常に

高くなる。そこで個々の光センサの値をステア

リング制御しないで、いくつかの値をとり平均

値で制御する。

光センサが取得した値が黒か白かそれとも漆

黒であるのかを判断する境界として閾値という

値を定義する。

光センサの値が外光などの影響でコース上で

も場所によって異なるため、閾値も常に走行中

に調整していく必要がある。

22

2.7 内部設計 (ソフトウェア開発)

要求分析により実現するシステムをモデル化

する。

2.7.1 ユースケース図

実現する機能の分割及び洗い出しを行なう。

1. ユースケース図の作成

• 走行システムの主要な機能の洗い出し

走行システムにおいてコースを機能

分割しユースケースとする。機能を

動かすきっかけとなるものがアクター

である。ユースケースは走行体のコー

スポジションをトリガーとして動作

する。よってアクターは「コース上

におけるマシンポジション」とする。

(図 22)

コース上におけるマシンポジション

走行システム

ストレート

カーブ

右

左

上り

下り

点線

オフロード

坂

図 22: 走行システム

• 走行前に行なう走行体の設定項目の洗い出し

走行前には、「人」がアクターとして

走行体の設定を行なう。このユース

ケース図の目的は、コンテスト当日

に行なう走行体の設定項目が明確に

なる。(図 23)

2. ユースケース図の変更

(変更理由)

ユースケースの粒度が大きすぎる為、ど

のような機能を表しているかが表現でき

ていない。

ボタンを押す

走行体をセッテング

光センサのキャリブレーション

スタート(スタート地点に置く)

ゴール(回収する)

人間

図 23: 走行体に行なう設定

ユースケースを考える際に粒度が大きす

ぎると意味が漠然としてしまう。逆に小

さければ何を実現する機能なのかがわか

らなくなってしまう。

以上のことを念頭に入れ再度ユースケー

ス図を作成した。

• メインシステムまず全体のシステムをメインシステ

ムとし、トリガーとなるアクターは

光センサ、タイマ、タッチセンサを

定義した。さらにサブシステムとし

て我々の戦略などをユースケースと

した。(図 24)

タイマ

光センサ

タッチセンサ

方向

<<subsystem>>

コースポジション

<<subsystem>>

メインシステム

<<subsystem>>

走行

色判別

<<subsystem>>

図 24: メインシステム

• 色判別光センサから取得してくる値を黒、

漆黒、白のいずれかに判別する。判別

した色によってステアリング用モー

タの制御やコースポジション決める

要素となる。

• コースポジションコースをパーツ別に分ける。

光センサとタイマでパーツ別に最適

なモータ制御を行なう。(図 26)

23

• 走行基本走行を機能化した走行システム

である。駆動用モータは一定のスピー

ドで回転し、光センサの取得してき

た値でステアリング用モータは制御

されている。(図 25)

• 方向タッチセンサによってステアリング

の向きを判断する。

サブシステムについても同様にアク

ターとの関連を考えた。サブシステ

ムを用いることで入れ子状態になり

全体から詳細なユースケースまで表

現することができた。

2.7.2 ステートマシン図

要求分析をもとにステートマシン図を作成し

た。大きく分けて 4枚の図でそれぞれライントレースステートマシン図、コースポジションス

テートマシン図、方向ステートマシーン、走行

ステートマシンとした。

• ライントレースステートマシンこの図はスタートからゴールまでの全体

の状態遷移を記述した。ライントレース

ステートは RUNボタンを押されることでライントレースの状態に遷移し、方向、

走行、コースポジションのステートが並

列に動作する。(図 ??)

• コースポジションステートマシンマシンのコース上におけるポジションと

遷移の関係を表わしたものである。コー

<<actor>>

コースポジション

走行システム

<<actor>>

色判別

<<actor>>

向き

ステアリングを曲げる

右に曲げる

左に曲げる

駆動モータを動かす

図 25: コースポジションシステム

スポジションステートの主な遷移条件は

システムタイマーとなっており、タイマー

と走行ステートマシンのエラー処理を受

け状態が遷移する。また、コースポジショ

ンに合ったパラメーターを走行ステート

マシンに渡す。(図 29)

• 方向ステートマシーン方向ステートはタッチセンサと走行ステー

トマシンの状態を遷移条件とする。(図 28)

方向SM

前輪が左向き 前輪が右向き

図 28: 方向ステートマシン

• 走行ステートマシン走行ステートはコースポジションステー

トマシンと方向ステートマシンから送ら

れたパラメーターをもとに光センサの値

を処理する。その結果からモーターを駆

動させ、モーターの駆動方向を方向ステー

トマシンに渡し、遷移させる。(図 27)

24

コースポジションシステム

タイマ

戦略コース別

色判別

ストレート カーブ 坂 点線

<<extend>> <<extend>><<extend>><<extend>>

駆動スピード設定 ステアリング設定

光センサ

図 26: 走行システム

25

走行SM

ステアリングを切る

右に切る左に切る

白線

黒線

ステアリングエラー

ステアリングエラー

ステアリングを止める

方向が左向き

方向が左向き

モータ駆動

タイム制御

タイム制御

図 27: 走行ステートマシン

26

コースポジションSM

ストレート

駆動モータスピードを設定

ステアリングモータスピードを設定

通常の色判別

点線

点線の色判別

ステアリングモータスピードを設定

白線白黒

点線の色判別

坂

駆動モータスピードを設定

通常の色判別

カーブ

駆動モータスピードを設定

通常の色判別

ステアリングエラー

黒線

白線白黒

黒線

通常の色判別

[タイム制御] / カーブ

[タイム制御] / ストレート[漆黒線感知 or タイ厶制御 ==1] / 坂

[タイ厶制御] / カーブ

[漆黒線感知 and タイ厶制御 ==1] / 点線

[漆黒線感知 or タイ厶制御 ==1] / ストレート

図 29: コースポジションステートマシン

27

2.7.3 タイミング図

タイミング図はステアリングの制御の条件を

明確にするために用いた。今回、我々が実装し

ようとしたアルゴリズムは黒、白いずれとも一

方に動かすのではなく, 黒線上から外に出た場合の車体の向きと逆の方向にステアリングを切

らなければならない。よって、高速化を図る為

にはより黒線上に長く留まると同時に、できる

だけ左右交互にコースアウトすることが望まし

いと考え、複雑になったステアリングのアルゴ

リズムのみを一枚の図に収めた。(図 30)

2.7.4 クラス図

本来、クラス図は実装を行なう前段階にカプ

セル化や適切なドメイン分割を行なうために作

られるものである。今回我々はコーディングを

先に行ない、コードの内容から図を記述すると

言う逆の手順を取ってしまった。そのため、ド

メイン分割が適切に行われておらず、構造化の

不充分な実装形式となってしまった。(図 ??)

2.8 実装 (プログラミング・テスト・運用・保守)

モデルからプログラミング言語でシステムの

実装を行なった。実装では機能別にコードの単

体テストを行なった上でシステム全体の結合し、

その後細かい改良を実施した。

機能別に「センサ部分」、「ステアリング部

分」、「ステート遷移部分」の 3構成である。

2.8.1 センサー部分

• 光センサが例外的な値を取得した場合はこの値を補正に加えず、閾値より高いか

低いかで黒線か白なのかを決定する。

• 仮に黒線と判断した場合は、はじめに設定した黒線の値×９＋センサの取得した

値×１ 　÷１０ 　（１０％の補正）を行

なう。

• そして再度、黒と白の平均を取ることで閾値を決定し、RUNボタンが offになるまで繰り返し行なう。

2.8.2 ステアリング部分

• 白を感知すると保存されたデータからラインがどちらにあるか判定する。

• 黒を感知するか、白が一定時間続いた場合データに逆方向に動くよう設定し「1」に戻る。

• 白を一定時間検知した場合には、同時にエラーの処理を行なう。

• 黒を感知したがステアリングが中央まで戻っていない場合には逆転は行なわない。

2.8.3 ステート遷移部分

• カーブ上の場合、タイマを監視し一定時間になると遷移させる。

• ストレート上の場合、タイマとステアリングのエラーから状態遷移する。

• 漆黒線を感知した場合、カーブであれば坂の状態へ遷移する。

2.9 結果と考察

2.9.1 コンテスト結果

コード実装はコンテスト当日になってもすべ

て終らず、その結果コンテストではコースを完

走することはできずに途中でコースアウトして

しまった。コースアウトしてしまった原因につ

いて以下に述べる。

• INコース

カーブに入った時にステアリングを左に

曲げて止まってしまった。これは黒線で

リカバリー処理に制御するタスクの遷移

が誤ったのか、黒線で閾値を超えて白と

みなした可能性が考えられる。

28

sd ステアリング制御

ON

OFF

前転(右に切る)

後転(左にきる)

右

中心

左

ON

OFF

SLEEP SLEEP

左

右

カウントとらないカウントとらない カウントとらない

スリープを入れる

右に切る

右に切る 左に切る

左に切る

スリープを入れる スリープを入れる

スリープを入れる

タッチ

センサ

ステアリング

モ－タ

スリ－プ

前輪の向き

図 30: タイミング図

Direction_st+direction : char = 1+Direction_check(in st_h : char , out Direction : char) : char

Running-turned_st_motor(in st_p : char , st_h : char) :-turned_fw_motor(fw_p : char)

motor_st+st_p : char+fw_p : char+st_h : char+sensor : char

sensor#sensor : int

+sensor(port : Port , makeActive : bool = false)+~sensor()+get() : unsigened int+mode(makeActive : bool) : void+passive() : void+active() : void+on() : void+off() : void+strobe() : void+strobe(ms : int) : void+sample(size : unsigend int=10 , wait : int=2) : unsigned int

TouchSensorLightSensor

+LightSensor(port : Sensor :: port)+get() : unsiged int+sample(size : unsigned int=10 , wait : int=2) : unsigned int

Slope+straight_fw_p : char = 255

+moving_out(out st_h : char , sensor : char) :+setting_fw_p(out fw_p : char)

Straight

+Straight_st_p : char = 255+Straight_fw_p : char = 255

+setting_st_p(out st_p : char)+setting_fw_p(out fw_p : char)+moving_out(out st_h : char , in sensor : char) :

Dotted_line+Dotted_st_p : char = 200+setting_fw_p(out fw_p : char)+moving_out_DOT(out st_h : char)

Curve+Curve_fw_p : char = 200+setting_fw_p : char = 200+moving_out(out st_h : char , in sensor : char) :

Course_Position+sensor : char+setting_st_p(out st_p : char)+setting_fw_p(out fw_p : char)+moving_out(out st_h : char , in sensor : char) :

1 1

図 31: クラス図

29

• OUTコース

チューニングの際、ステアリング用モー

タスピードを低くしすぎたために下り坂

で、ステアリングの振れ幅が変わった可

能性が考えられる。

2.9.2 実装コードについての考察

コード実装がすべて終らなかった主な要因と

して、設計段階において新規性やマシンの高速

化に固執したことがまず上げられる。さらに、

物理特性に対するデータをほとんど取らず、ま

たコーディング初心者であったが為に、実装す

る機能に対する難易度が把握し切れず、技術的

に無理な機能まで実装しようとしていた事が挙

げられる。

2.9.3 モデリングについての考察

モデルについてはモデル自体の設計を始める

前に考えておくべき項目や調べておく項目が

あり、それをきちんと行なわなければ効果的に

UMLを利用することは難しいことがわかった。例えば、基本的なアルゴリズムや物理的な特

性は入念に調べておかなければ、実際モデル通

りの実装を行なっても、ストレートを満足に走

らせることでさえ難しかった。また、ステアリン

グやセンサと言ったような重要な部分は実装を

改良していくにしたがって、元のモデルから遠

ざかり、結果として UMLのいくつかは実装したコードから新らたに書き起こす必要があった。

2.9.4 プロセスモデルについての考察

開発手法として使用した「ウォーターフォー

ル・モデル」の妥当性について考察する。

初めて学ぶ UMLやプログラミング経験が乏しいことから開発の各工程を各々実施していく

開発方法では、開発時間が大幅にかかってしまっ

た。さらにプログラミング経験が少ない場合に、

いきなり大きなプログラムを作成とするとなる

と、どこから手をつけてよいのかわからなくなっ

てしまった。

そこで他のプロセスモデルについて考えると、

「スパイラルモデル」というプロセスモデルが

ある。(図??)「スパイラルモデル」とはまず始めに必要最低限のプロトタイプを作り上げて、

徐々にそのプロトタイプから成長させていくモ

デルのことである。今回のコンテストにおいて

は、徐々に成長していくので、アルゴリズムの

変更などがあるときはリスクが最低限で済むこ

とが利点である。

要求分析 仕様分析

設計テストprototype

図 32: スパイラルモデル

今回の経験を踏まえると、組込みシステム開

発を初学者が行なう場合、「スパイラルモデル」

が最適ではないかと考えられる。

2.10 再検証

2.10.1 マルチタスク

• タスクとはタスクとは OSから見た処理の実行単位のことである。つまり作業がひとまとま

りになったものをタスクという。

• シングルタスクとはOSからみた時に行なう仕事 (タスク)が

30

ひとつだけの場合にそれを、順序どおり

処理を行なうことである。身近な例では

MS-DOSなどのように同時に 1つのアプリケーションソフトしか起動できないOSはシングルタスクOSと呼ばれる。

RCXで例えると図 (33)のような動作をシングルタスクと言う。この図 33は外枠をタスクの単位として、上から順番にプ

ログラムを実行している。5 秒前進するというプログラムを言い換えると、「5秒前進するタスク」であると言える。

• マルチタスクとは1台のコンピュータで同時に複数の処理を並行して行なう OSの機能。身近な例では UNIXやWindows、Mac OSなどがこれにあたる。CPUの処理時間を非常に短い単位に分割し、複数のアプリケーショ

ンに順番に割り当てることによって、複

数の処理を同時に行なっているようにみ

せているため、多くのアプリケーション

ソフトを同時に起動すれば、その分だけ

個々のアプリケーションソフトの動作は

早くなる。

RCXで例えると、図 34のような動作をマルチタスクと言う。実際に RCXでこのプログラムを実行すると 5秒前進しながら、光センサが取得した値を表示した。

つまり、「5秒前進する」、「光センサの取得した値を表示する」という 2つのタスクが同時に実行されている。ただし「同

時に実行されている」というのは厳密に

は間違いであり、正確に述べると「タス

クの実行時間を非常に短くして、さも 2つのタスクを同時に動かしているように

処理を行なう」という言い方が正しい。

brickOSのタスクには第 5引数まで持たせることができ、さらに優先度やメモリ

容量を設定できる。

• タイムスライスタイムスライス (time slice)とはマルチタスクを制御するとき、各タスクに割り

当てる時間配分。上記でマルチタスクで

は非常に短い単位に時間を分割すること

を述べた。この時間をタイムスライスと

言い、brickOSでは独自の APIが提供されておりカーネルの部分がこれを管理し

ている。APIを用いて可変も可能であり、初期設定は 20msとなっている。タイムスライスは可変範囲は 6～255msである。

• 優先度優先度とはマルチタスクの実行順序を決

定する値である。マルチタスクでタスク

を複数実行する場合にどのタスクから実

行するかはユーザーに決定権がある。APIによるとタスクの優先度には 0～255までの値が登録でき、優先度 0が最小で 255が最大となっている。

• アイドルタスク (tm idle task)

アイドルタスクとは優先度 0(最小)のタスクで、他に実行条件を満たすタスクが

存在しない場合に実行権が与えられ、無

駄な電力を消費しないようにするタスク

である。

APIに「sleep()」という関数がありこれはシングルタスクでは引数に unsigned int型をいれるとその時間 (引数の単位は「秒」)だけ次の処理を待つ関数である。この「sleep()」をマルチタスクで使用すると、タスクの

実行権の放棄となり、タイムスライスが

余っていても直ちにタスクスケジューラ

が起動される。そして実行するタスクの

選定が行なわれる。

• 動作検証マルチタスクの APIを使用して、動作検証を行なう。

– 異なる優先度の実行動作実験

タスクを 3つ用意して、それぞれにタスクを生成するAPI「execi()」を使用。tid t型 (プロセス ID)でプロセス構造体へのポインタを返し、失

敗した場合は-1を返す。第 1引数は

31

実行関数へのポインタ、第 2引数は実行関数への引数の数、第 3引数は実行関数への引数としての文字列へ

のポインタ第 4引数は実行プロセスの優先度、第 5引数は実行プロセスのスタックサイズを示す。

3つのタスク (task1、task2、task3)にはいずれも第 1 引数が実行関数の先頭アドレス、第 2引数が 0、第3引数が NULL、第 5引数が「DE-FAULT STACK SIZE」(APIで 512バイトに置換されている)とした。

そして第 4引数を task1に 10、task2に 20、task3に 30を持たせる。各タスクには LCDに task1なら「task1」とタスクの名前が表示するようにプ

ログラムを記述して異なる優先度の

動作実験を行なった。もちろんプロ

グラムで表示を 1 回するだけならば一瞬で表示し終わりタクススケジ

ューラが 1タイムスライスごとに起動し実行権の評価を行なうので、for文を用いて 1つのタスクで数千回表示を実行するように記述した。

実験結果は LCDが「task3」「task2」「task1」と表示した。よってbrickOSではエントリーしたタスクの中から

優先度が高い順に起動することわか

る。

– 等しい優先度の実行動作実験

次に優先度が等しい場合の実行動作

を実験。task1、task2、task3すべてに同じ優先度 (10)で実行した。実験結果は「task1」、「task2」、「task3」を繰り返し表示した。これは 1 タイムスライス (20ms)で数千回表示し終えずにタイムスケジューラが優

先度がどれも等しいでプログラムの

main 文に記述したタスクの登録順にタスクのスイッチが行なわれたこ

とが判明。

brickOSでは優先度の等しい場合 1

つのタスクに CPUを一定時間利用させ時間が過ぎたら待っている次の

タスクの処理に CPUを利用するという「ラウンドロビン方式」を用い

ている。つまり同じ優先度のタスク

であれば、1タイムスライスごとに実行タスクが遷移する。

– マルチタスクプログラム実行回数

タスクが 1タイムスライスごとに毎回、同じ回数プログラムを実行して

いるのか実験。優先度の同じ 2つのタスク (task1、task2)を生成する。task1から起動してwhileの無限ループでカウンターを作り、while文を 1回実行したらカウントアップする。

task2 に実行タスクが遷移したら、task1のカウントを表示するプログラムを作成した。

結果は RCXが常に同じ回数実行されない。おおよその値の検討はつく

が、タスクが生成データを他のタス

クが使用される際には十分注意が必

要である。

– シングルタスクプログラム実行回数

マルチタスクと同様にシングルタス

クで駆動用、ステアリングモータ、

光センサ、LCD 表示などさまざまなAPIを用いて無限の while文でカウントをとった。マルチタスクの実

験結果と同様におおよその値は検討

がつくが、プログラムに APIを 1つ追加しただけで回数が変わってしま

うため、回数で制御を行なうには厳

しい。

– 親/子タスク

タスクどうしが木構造を構成してい

る時に、木構造の親子関係から親タ

スク、子タスクとタスクの関係でこ

う呼ばれる。子タスクは親タスクよ

り後に呼ばれることが保証されてい

て、brickOSでは親タスクが子タスクを呼んだ後に消滅した場合、子タ

32

スクは消滅しない。さらにタスク自

身が自分を消滅されることも可能で

ある。

2.10.2 ヒープ領域

• ヒープ領域とはOSやアプリケーションソフトが使用するメモリ領域の一種。用途に関係なく自由

に確保することができる。OSからはピープメモリを確保した位置のアドレスが渡

され、アプリケーションソフトはこの値

を元にして確保したヒープ領域を使用す

る。ヒープメモリはアプリケーション側

での自由度が高い反面、確保したヒープ

をすべて手作業で解放しなければならな

いため、誤解放や解放漏れなどのミスが

起こりやすいので注意する必要がある。

• brickOSのヒープ領域

APIの「malloc()」を用いてヒープ領域のサイズを測定する。結果は 12868～13275バイトの幅で領域が確保できた。よって

大きな配列などをスタック領域で用意で

きない場合は、ヒープ領域に確保するも

1つの手となりえる。

2.10.3 光センサ

RCXの入力データである光センサの特性を再検証する。実験には走行体を停止した状態

で 100個の連続した値を保存し参照する方法をとった。

• 黒線大半が連続して同じ値を取得しているが、

ごく希に+1した値が取得されていた。しかし、実行した直後の約 12個目くらいまでは非常に高い値や、大半の値よりも-1した値が取得されていた。

実験データを図 37に示す。

• 白

白とはライン外の場所を指す。「黒線」の

実験同様にライン外では全体的に黒線よ

り高い値が取得されていた。さらに、実

行直後も黒線のように安定した値が取得

できていなかった。「黒線」の実験と異な

り、値が常に不安定であり+1、-1程度を繰り返し取得されていた。

実験データを図 38に示す。

• 境界境界とはラインの黒テープと発砲スチロー

ルに、光センサの光を合わせた場所のこ

とを指す。この境界では黒線よりは高く、

白よりは低い値を取得していた。白と同

様に常に不安定であった。

実験データを図 39に示す。

2.10.4 まとめ

再検証を踏まえてライントレースシステム開

発における改善点や問題点などについて以下に

まとめる。

• プロセスモデルについて「2.9.3プロセスモデルについての考察」で、スパイラルモデルを提案した。ライ

ントレースにおけるプロトタイプは「直

線をライントレース」できるプログラム

となる。そしてプロトタイプのオプショ

ンを以下に列挙する。

1. 坂道を上り、下りともに走行

例えどんなに安定な走行をしていて

も坂道が上り、下りできないと周回

できないという理由である。

2. オーバル走行

最小半径 30cmのカーブ走行を含む。

3. リカバリー処理付加

コースアウトした時に、黒線を探す

プログラム。

33

4. 点線走行

OUTコースにある点線をリカバリー処理に頼らずに走行できるプログラ

ム

以上のオプションをサイクルを回しなが

らプロトタイプに付加してゆくのが一番

効率がよいと考えた。

• 光センサの実行直後の挙動黒線上の走行体にプログラム開始時ステ

アリングが大きく動く問題を解決した。

取得し始めの値 10数個を無視した後に、モータ制御を開始すれば走行開始時の挙

動を防ぐことができる。原因はセンサを

アクティブ (能動)にした直後は値が安定するまでに 10数回かかることである。

• 実験方法

– センサデータ参照プログラム

走行開始時から終了時までのセンサ

データを参照するプログラムである。

主要な入力データは光センサであり、

すべての走行実験を行なう際にセン

サのデータを参照できるなプログラ

ムを作成した。入力データに対して

モータを制御しているので、例えば

コースアウトした時に光センサの演

算が問題なのか、ステアリングに問

題があるのかなど、すべての入力デー

タを吸い出すことで検証が行なうこ

とができる。

– RCX通信プログラム

RCX 同士でデータを送受信できるプログラムである。

RCXに送信側と受信側のプログラムを作成した。RCX 同士で通信する方法は赤外線ポートを互いに向き

合わせて、赤外線で通信を行ない、

LCDのセグメントの関係で数字と文字のみの送信となる。

センサデータのある RCXをもう一方の RCXへデータ送信をして、走行体の再現なども可能になる。

• 電池の消耗に対する対策実物大コースを 5周程度走らせると、目でモータスピードの違いがわかるほど RCXでは電池の消耗がとても早い。実験で走

行体が安定した走りをしても、同じ電池

で常に安定することはない。

対策としては実験を行なう際に電池の電

圧とのデータを取り、ここから関係性や

法則のようなものを見つける。そしてそ

の関係性をプログラムで関数化すること

を対策として提案する。

34

駆動用モータスピードを200に設定

駆動用モータを順回転

駆動用モータをブレーキ

5秒待つ

RCX

図 33: シングルタスク

[HAIRETU] sensor_value [HAIRETU] sensor_value0 28 50 281 28 51 282 28 52 283 28 53 284 29 54 285 28 55 286 28 56 287 28 57 288 28 58 289 28 59 28

10 28 60 2811 28 61 2812 28 62 2813 28 63 2814 28 64 2815 28 65 2816 28 66 2817 28 67 2818 28 68 2819 28 69 2820 28 70 2821 28 71 2822 28 72 2823 28 73 2824 28 74 2825 28 75 2826 28 76 2827 28 77 2828 28 78 2829 28 79 2830 28 80 2831 28 81 2832 28 82 2833 28 83 2834 28 84 2835 28 85 2836 28 86 2837 28 87 2738 28 88 2739 28 89 2740 28 90 2741 28 91 2742 28 92 2743 28 93 2744 28 94 2745 28 95 2746 28 96 2947 28 97 3648 28 98 4449 28 99 56

average-> 28.02 average-> 28.88

all average= 28.45

図 37: 光センサ値データ (黒線)

35

[HAIRETU] sensor_value [HAIRETU] sensor_value0 42 50 421 42 51 422 42 52 423 42 53 424 42 54 425 42 55 426 42 56 427 42 57 428 42 58 429 42 59 42

10 42 60 4211 42 61 4212 42 62 4213 42 63 4214 42 64 4215 42 65 4216 42 66 4217 42 67 4218 42 68 4219 42 69 4220 42 70 4221 41 71 4222 42 72 4123 42 73 4224 42 74 4225 42 75 4226 42 76 4227 42 77 4228 42 78 4229 42 79 4230 41 80 4231 42 81 4232 42 82 4233 42 83 4234 42 84 4135 42 85 4136 42 86 4237 42 87 4238 41 88 4139 42 89 4140 42 90 4141 42 91 4142 42 92 4143 42 93 4144 42 94 4145 43 95 4046 42 96 4047 42 97 4148 42 98 4749 42 99 47

average-> 41.96 average-> 41.9

all average= 41.93

図 38: 光センサ値データ (白)

[HAIRETU] sensor_value [HAIRETU] sensor_value0 33 50 341 33 51 332 33 52 333 34 53 344 33 54 345 34 55 346 34 56 347 34 57 348 33 58 349 33 59 34

10 33 60 3311 33 61 3312 34 62 3313 34 63 3414 34 64 3315 33 65 3416 33 66 3417 33 67 3418 33 68 3319 33 69 3320 34 70 3321 33 71 3422 33 72 3323 34 73 3424 34 74 3425 33 75 3426 33 76 3427 33 77 3328 33 78 3329 34 79 3430 34 80 3431 34 81 3432 34 82 3433 33 83 3434 33 84 3435 33 85 3436 33 86 3337 33 87 3438 33 88 3439 33 89 3340 34 90 3341 34 91 3342 33 92 3343 33 93 3344 33 94 3345 33 95 3246 33 96 3447 33 97 4048 34 98 4849 33 99 58

average-> 33.34 average-> 34.46

all average= 33.9

図 39: 光センサ値データ (境界)

36

光センサをアクティブにする駆動用モータスピードを200に設定

駆動用モータを順回転

駆動用モータをブレーキ

5秒待つ

RCX

取得したセンサ値をLCDに表示する

2秒待つ

光センサをパッシブにする

図 34: マルチタスク

task1(10)

task2(20)

task3(30)

1 time slice

task_name(priority)

start

start

start

end

end

end

waiting

executing

図 35: 異なる優先度の実行動作実験

37

task1(10)

task2(10)

task3(10)

1 time slice

task_name(priority)

start

start

start

end

end

end

waiting

executing

end

end

endstart

start

start

図 36: 等しい優先度の実行動作環境

38

3 まとめ

組込みソフトウェア開発にあたり UMLやプロセスモデル、マルチタスクOSなど様々な知識を得ることができた。コンテストにおいては

不本意な結果となってしまったが、実際に現場

の開発手法を用いて、全工程を通して開発する

ことは非常に貴重な経験であった。多くの知識

を必要とする組込みソフトウェア開発をするこ

とは、高い教育的効果があると考えられる。

39

4 謝辞

本研究を進める上で私にご指導下さった、東

海大学電子情報学部コミュニケーション工学科

清水尚彦教授に感謝いたします。また、技術的な

らびに精神的に支援をいただいた、Khamphong氏、飯田氏、名野氏、大山氏、田中氏、近藤氏、

御村氏をはじめとする研究室諸学生に感謝をい

たします。

最後までお忙しい時間のなか、本研究の進行

の為にご指導をいただいたことをこの場お借り

して、心より厚く御礼申し上げます。

40

参考文献

[1] ETソフトウェアデザインロボットコンテスト

http://www.etrobo.jp/

[2] Mint(経営情報研究会) 著,”構造化手法からオブジェクト指向まで 図解でわかる ソ

フトウェア開発のすべて”,2004年

[3] 株式会社テクノロジックアート 著,”独習UML 　第 3版”,2005年

[4] 株式会社永和システムマネジメント 著,”実習 ロボットと情報技術 REALシリーズC言語編 テクニカルガイド”

[5] 小泉寿男 辻秀一 吉田幸二 中島毅 著,”ITText ソフトウェア開発”株式会社オーム社,2004年

[6] brickOS C Documentation v0.2.6.10.6http://brickos.sourceforge.net/docs/APIs/html-c/

[7] brickOS Kernel Developer Documenta-tion v0.2.6.10.6http://brickos.sourceforge.net/docs/APIs/html-kern/

41