実録、MDDツールを“使わない”アプローチ：3つの設計アプローチで見るETロボコン参戦記録（3）（2/2 ページ）

[細田健人／監修：土樋祐希（富士ゼロックス），＠IT MONOist]

※本記事はアフィリエイトプログラムによる収益を得ています

モデルからコードへ

　モデル提出の後、モデルに即したコードの作成に取り掛かりました。

　今回使用した言語は「C言語」です。オブジェクト指向で設計したので、C++で実装した方が素直に作れたと思いますが、それまで走行特性をつかむために使用していたサンプルプログラムがC言語版で、使い慣れていたことと、C++で作成した場合にROM・RAM・処理量などがどれくらい増えるかが分からなかったので、C言語を使用しました。

　ここでは、どのようにオブジェクト指向で設計したクラス図をC言語で実装したのかを説明します。

　基本的に1つのクラスは、ヘッダファイルとソースファイルの1対のファイルから構成しました。クラスのメンバーは構造体で表現し、インスタンスメソッドはプレフィックスにクラス名を付け、第1引数にそのインスタンスのポインタを渡すようにしています（図5）。

図5　クラスをC言語で実装する例

　また、設計クラス図で使用したStrategyパターンでは、インタフェースの呼び出し時にどのインスタンスに対して呼び出しを行っているかによって処理を変えなくてはなりません。C++では継承の仕組みを使うのが普通なのですが、C言語では図6のように関数ポインタを使って呼び出しを変えるようにしました。

図6　関数ポインタによるStrategyパターンの実装
※クリックで画像拡大表示

　このようにコードを記述することで、ループを回すなどの共通処理をフレームワークとして用意し、走行方法や検知方法を追加した場合でも、フレームワーク側を変更する必要がないような作りにしました。上記の呼び出しサンプルでは、getDriveControl()で返すDriveControlを切り替えることで、走行のメインルーチン（Sample_run()）を変更せずに走りを切り替えることができます。

　提出したモデルでは「どのようにコースを走行するか」という走行戦略はリンク形式で記述する形になっていましたが、コードを書く段階で記述のしやすさなどから配列を使ったテーブル形式で記述することにしました。事象の検知が行われるたびにインデックスをインクリメントし、走行方法を切り替えていく形になります。

　走行戦略ごとにこうしたテーブルを定義したファイルをそれぞれ用意して、NXTの実行ファイルを作る際にそのうちの1つを選択して結合させることによって、インコース・アウトコースなどの走行戦略の切り替えを行いました。

　今回、私たちが取り組んだモデルを手書きによって実装する方法によって、前回紹介した各ドメインがどのように作られているかを図7に示します。

図7　F＆Fチームによる各ドメインの実現手段

今回のやり方の特徴

　ここで、今回私たちF＆Fチームが取った“手書きでモデルをコードにする”というやり方のメリット・デメリットについて考察したいと思います。

手書きでモデルをコードにする：メリット

　メリットとしては、まず「導入コストの安さ」があります。モデルの作成には、モデリングツールを使いましたが、基本的にはテキストエディタなどを使ってコードを書くだけですので、ツール購入のコストや新たな教育を行うといったコストが不要でした。そのため、モデル提出後1週間程度でモデルに即したコードを作り上げることができました。もちろん、これは事前にモデルをきちんと作り上げ、モデルの段階で自分たちのやりたいことができるかどうかを確認してきたから成し得ることができたといえます。動作するコードができたので、残りの期間を走行戦略やパラメータ、アルゴリズムの調整に使用することができ、走りに対して注力できる体勢が取れました。

手書きでモデルをコードにする：デメリット

　デメリットとしては、手書きの実装の際によくいわれることですが、「モデルと実装が乖離（かいり）する」ということが私たちの場合でもありました。フレームワーク部分に関しては大きく変更はなかったのですが、走りに注力するあまり、走っては直しの繰り返しを通じて、新たな走行方法や知らないパラメータがいつの間にか追加されていました。もちろん、こうした追加をきちんとモデルに反映させて、他のメンバーも見られるようにすればよいのですが、難所攻略に没頭するあまりそうした作業は行われず、担当者にしか理解できないちょっとずつ違うモジュールが生み出されることになりました（表2）。ETロボコンで作成したコードは、それほど大きくないので何とかなりましたが、規模が大きくなった場合には問題になると思います。

　別のデメリットとして、先に説明した「走行戦略の配列定義（以下、戦略リスト）のメンテナンスに掛かる工数が大きい」ことも挙げられます。戦略リストには、走行方法と検知方法のペアが時系列順に、つまりロボットに走行させたい順番に記述されています。まさに“戦略の核”となる情報で、ミスは許されません。われわれのチームでは、この戦略リストの作成・編集を手動で行っていたため、戦略リストが意図通りになっているか？ 変更箇所は正しいか？ など、ミスがないことの確認に大きな工数を費やさざるを得ませんでした。また、戦略リストは時系列順に記述されているため、ある箇所の変更がそれ以降の走行に影響を与えることもあり、戦略リスト変更後の動作確認にも大きな工数が掛かりました。このデメリットは、今回取り組んだ手書き実装の課題の1つといえると思います。

linetrace_dev.c	PID制御を用いないライントレース走行
linetrace_limit.c	PID制御を用いず左右の舵に制限を付けたライントレース走行
linetrace.c	PID制御を用いたライントレース走行
pid_other.c	過去チームのパラメータを用いたPID制御走行
表2　モデルに反映されなかった走行方法

生成物と大会の結果

　さて、実際に大会に出場した結果ですが、残念ながらモデル部門での優勝・入賞ともになりませんでしたが（ただし、評価としては“A−”と上位の方でした）、走行に関しては全ての難所をクリアするという戦略で臨み、インコースはミステリーサークルをクリアできました。アウトコースではシーソーはうまくいったものの、階段で転んでしまいこちらは残念ながらリタイアとなりました。総合結果は7位となり、チャンピオンシップには出場できませんでしたが、モデル・走行ともにある程度のレベルに達することができたのではないかと思っています。

その他の取り組み

　最後に、モデルと実装以外で行った私たちの取り組みについて紹介します。

　今回、私たちはなじみのある組み込み開発の視点だけでなく、一般的なソフトウェア開発でどのような技術があるのかを知るため、社外の技術者に話を聞くという機会を設けることにしました。以前から面識のあった日本マイクロソフトのエバンジェリストである太田寛氏がこの取り組みに快く協力してくださり、マイクロソフトの技術を含めた技術動向などのお話を伺う機会を得ました。

　その会では、太田氏の他、著名な萩原正義氏と長沢智治氏からもお話を伺うことができ、現在どんな技術やソフトウェアの開発プロセスがあるのかということを分かりやすく教えていただきました。普段、社内で組み込み開発しかやっていない私たちにとって大変刺激的な貴重な機会となりました（この場を借りてお礼を申し上げたいと思います）。

　太田氏からは、「Microsoft Visual Studio」を使用した組み込み開発の方法を伺ったので、私たちも開発の後半では「Microsoft Visual Studio 2010」を使用し、nxtOSEK環境のクロスコンパイル、ターゲットへの転送など、ETロボコン開発環境を整えました。また、太田氏から「Visual Studio 2010でUMLを使った開発ができる」ということを伺いましたが、残念ながら今回は時間の関係で活用することができませんでした（今後、試してみたいと思います）。

---

　今回は、私たちF＆Fチームが行った活動について紹介しました。お届けした内容以外にもチーム運営やプロジェクトを計画的に進める難しさということを実感することができました。こうした多くの経験は、今後の業務でも役に立つのではないかと考えています。

　さて、次回は「DSL（Domain-Specific Language：ドメイン特化言語）」による開発を行った「みんなとみらい1」チームの活動を、リーダーの上江洲が紹介する予定です。お楽しみに！ （次回に続く）