公立はこだて未来大学 2012 年度 システム情報科学実習
グループ報告書
Future University Hakodate 2012 System Information Science Practice
Group Report
プロジェクト名
知能機械技術による施設内案内
Project Name
Intelligent Machines as Institutional Guides
グループ名
ナビシステム班/ハード班/ADK 班
Group Name
Location Information/Mechanics
プロジェクト番号/Project No.
04-A/B/C
プロジェクトリーダ/Project Leader
1010026
泉拓哉
Takuya Izumi
グループリーダ/Group Leader
1010027/1010151
小野修都/岩山拓哉
Shuto Ono/Takuya Iwayama
グループメンバ/Group Member
1010026
泉拓哉
Takauya Izumi
1010027
小野修都
Shuto Ono
1010035
仲田健太郎
Kentaro Nakata
1010087
伊東翔
Sho Ito
1010088
犬塚悠人
Yuto Inuduka
1010095
高橋克弥
Katsuya Takahashi
1010101
町田浩平
Kohei Machida
1010102
三上力也
Rikiya Mikami
1010113
黒坂愛
Megumi Kurosaka
1010125
八島奎之介
Keinosuke Yashima
1010127
浅野翔太
Shota Asano
1010151
岩山拓哉
Takuya Iwayama
1010178
佐々木康祐
Kousuke Sasaki
1010205
畠山大樹
Taiki Hatakeyama
指導教員
三上貞芳 高橋信行
竹之内高志
鈴木昭二
新美礼彦
椿本弥生
Advisor
Sadayoshi Mikami Nobuyuki Takahashi Takashi Takenouchi Shoji Suzuki
Ayahiko Niimi Mio Tsubakimoto
提出日
2013 年 1 月 16 日
Date of Submission
January 16, 2013
-2-
概要
本プロジェクトの目的は，知能を持った機械とナビゲーションアプリを組み合わせた知能機械
技術を用いて，人が行う案内に近づけることである．ナビゲーションとは，人が目的地までた
どり着けるような案内を行うものであり，その形態は大きく分けて二つある．一方はカーナビ
ゲーションや地図アプリケーションのようなナビゲーションアプリによる案内，他方は人によ
る案内である．ナビゲーションアプリは目的地までのルートを音声や文字を用いて案内を行
う．一方，人によるナビゲーションはナビゲーションアプリとは違い，目的地までのルートを
伝えるだけでなく，目的地まで先導して案内を行うことができる．本プロジェクトでは，人間
を究極の知能機械と考え，既存のナビゲーションアプリとは異なる，人のような知能を持った
機械とナビゲーションアプリを融合させたシステムを構築し，知能機械技術による施設内案
内を目標とする．そのため，今年度は人が先導して目的地まで案内する「連れていく」という
要素を持った知能機械と，目的地まで「連れていく」ためのルートを伝えるナビゲーションア
プリを組み合わせたシステムである「ALEFUN」の構築を行う．
「ALEFUN」の構築に向け，
知能機械技術の開発のために Selfi と呼ばれる倒立二輪電動スクータの拡張を行うハード班と，
ナビゲーションアプリを開発する位置情報班の二つに分かれて活動を行う．ハード班は Selfi
が施設内を安全に走行できるよう，機能の拡張を目指す．位置情報班は，ナビゲーションアプ
リ開発のために，施設内の位置情報を取得し，屋外，屋内をシームレスに案内できるナビゲー
ションシステムの構築を目指す．「ALEFUN」が構築することができれば，施設内において知
能機械がシームレスに，かつ安全に目的地までの案内を行うことができる．
キーワード
知能機械，ナビゲーション，ALEFUN，Selfi，シームレス
（※文責: 町田浩平）
-i-
Abstract
Our purpose is to guide like a way human do by using intelligent machines which is
combined machines having intelligence with navigation applications. Purpose of navigation is to guide people to their destinations and there are two types of approach. One
is by navigation applications like automotive navigation systems and map applications.
The other is guidance by human. Navigation applications just inform people of the way
to their destinations by display on a screen or sound, while human directly takes them
to their goal. We consider that human is an ultimate model of intelligent machines
and aim to develop “Intelligent Machines as Institutional Guides”. In this project, we
will construct a novel system “ALEFUN” which unifies the intelligent machine and
navigation applications. The ALEFUN consists of two: one is the intelligent machine
which has an element to guide like human. The other is navigation applications which
tell the way for destinations. We organize two groups to build the ALEFUN. One is a
mechanics group, and the other is an information location group. The mechanics group
improves “Selfi” which is a kind of two-wheeled scooter to safely operate the Selfi
in facilities. The location information group constructs the navigations system which
can seamlessly gain location information and can present the way for the destination
in order to develop navigation applications. When the ALEFUN have been built, that
will enable to guide for destinations seamlessly and safely in facilities.
Keyword
Intelligent Machines, Navigations, ALEFUN, Selfi, Seamless
（※文責: 町田浩平）
- ii -
目次
- iii -
Intelligent Machines as Institutional Guides
第1章
はじめに
この章ではプロジェクトの背景となる事柄や目的について述べる．
1.1
背景
今日，私たちはナビゲーションシステムを利用する時，GPS 衛星を利用し屋外で位置情報を取
得している．しかし，私たちは屋外だけでなく屋内でも行動する．現在では，屋内で GPS 衛星を
使って位置取得するには電波受信の環境が悪く，位置情報取得するには不向きである．
屋外で使っているナビゲーションシステムを高い精度のままにデパートやターミナル駅，空港な
ど複雑で迷いやすい場所で利用できれば便利である．
そこで最近は，屋内 MAP というものが注目されている．例えば，Google Maps が屋外だけで
なく屋内の地図として「Google.Indoor.Map」という地図情報を取得できるサービスをリリースし
た．これは、屋内ナビゲーションに利用可能であり、屋内マップは最近注目されているツールの 1
つである．
屋内位置情報取得に関しては，IMES というものも注目されている．IMES とは宇宙航空研究開
発機構（JAXA）と測位衛星株式会社が共同で開発し，株式会社日立産機システムが本体の製作を
行っている屋内の位置情報を取得できるシステムである．これを利用して，本プロジェクトでは，
ナビゲーションにおける屋内と屋外のシームレス化を行う．
また，本プロジェクトの目標である「人が連れて行くような」ナビゲーションを目指すにあたっ
て，人を目的地に連れていってくれる乗り物が必要である．この目標を満たす乗り物は，室内のよ
うな狭い空間で使用でき，搭乗者はもちろん周囲の人に対しても安全なものである必要がある．し
かし，現在乗り物にはこれら条件を満たせるものは存在しないため，新たな乗り物の開発もしくは
別製品の改造が必要となる．そこで，「Selfi」と呼ばれる乗り物を採用し，改造を施すことでこれ
ら条件を満たす乗り物とすることとした．Selfi とは株式会社エフ・アイ・ティが設計製作した倒立
電動スクータである．Selfi は小型であり，小回りが利き小さなスペースで動くことができるため
室内での利用に向いている．更に，Selfi はカスタマイズすることが可能であるだけでなく，ゼロか
ら本体を組み立てることが可能であるため，本体の構造を理解し，本体を改造することに適してい
る．この Selfi とこれらを利用した屋内と屋外のシームレスなナビゲーションシステムを用いて本
プロジェクトの目標を達成する．
図 1.2 IMES 送信機
図 1.1 Selfi
Group Report of 2012 SISP
-1-
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
（※文責: 泉拓哉）
1.2
本プロジェクトの目的
私達は生活をしている限り移動という行為は不可欠な存在である．行きつけのお店や知人友人の
家，取引先の企業など目的地は様々である．それらの目的地には日常的に向かう場所が多く，自分
自身で把握している道である．では，雑誌で紹介されていた店や新しくできた友人の家，今度から
新しく取引することになった企業の場合はどうだろうか．おそらくそのような場合には，私たちは
移動する前に地図等で予め道順などを確認するだろう．最近では地図帳を広げるのではなく WEB
上やスマートフォンのナビゲーションアプリを使うかもしれない．慣れぬ土地なこともあり小さな
道のミスや体に疲れがたまりやすくもなるだろう．また，それらのルート検索では施設の内部に対
応しているものは少なく利用しづらいものになっており，目的地に着くのに困難なものになるだろ
う．
実際にナビゲーションソフトを利用していると物足りない部分が出てくることもある．例えば地
図自体の読み込みが遅いことや GPS の正確な取得ができずにナビゲーションソフト上に自分の位
置が反映されないことがある．そのようなナビゲーションソフトを屋内に転用することで満足して
使えるだろうか．さらには屋内は屋外での利用の問題点に加え，道によっては極度に狭い所や歩き
づらい場所等があり，移動が困難である．そのために既存のナビゲーションソフトにはない，屋内
情報に対応したソフトが新たに必要である．
また，駅や空港などの広く，かつ複雑な施設では徒歩による移動が大変である．しかしその代わ
りに乗り物を用意した場合，自転車やキックボードなどでは速度のコントロールや小回りが難し
く，周囲の安全性の確保ができないので施設内移動には適していない．
この２つの課題を解消出来るような乗り物が必要である．これを実現させることを本プロジェ
クトの目標とする．また，就職後に行われるプロジェクトの疑似体験を学生である間にに行うこと
で，プロジェクトとして個人の作業でなく協力しあう意義などを見出す．
（※文責: 畠山大樹）
1.3
知能機械技術とは
一般的に知能機械技術と言うと SONY の AIBO や本田技研工業の ASIMO 等のロボットを思
い浮かべるだろう．この技術はセンサ等から外部の情報を取り込み，その情報を内部で処理し，処
理結果を外部に出力する．例えば，ロボットが速度センサを用いて自身の歩行速度を調整すること
やカメラを用いて障害物回避を行うことなどが挙げられる．この一連の動作はタイムラグが大きく
発生せず，あたかも人が思考し，判断するのと同じように見える．施設内案内をする上でこのよう
な臨機応変な結果を出せるものは，安全性やより良いナビゲーションをする上で必要であるそれを
踏まえた上で本プロジェクトでの知能機械技術は， Selfi と Android 間での通信を行い利用者の補
助を行うものと定義する．例えば Selfi に取り付けたセンサーから速度を Android に出力し，利用
者に注意を促すことや，それとは逆に Android から送信した指示を Selfi で受け取り動作すること
である．
（※文責: 畠山大樹）
Group Report of 2012 SISP
-2-
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
1.4
該当分野の現状と従来例
この節では，本プロジェクトと関連のある例について述べる．
1.4.1
SmartFUN プロジェクト
昨年度のプロジェクトの一つ「Smart FUN」の活動において位置情報の取得や Bluetooth 通信
機能を用いたシステムがある．
位置情報取得には， Wi-Fi による Mac アドレス, SSID, BSSID, 電波強度といった情報から位
置を測定するという方法で位置を取得し， iOS 環境では Private Framework の中の MobileWiFi
という Framework を用いる方法で位置を取得するシステムがある． Bluetooth 通信には，常に
周囲の端末を探している状態から，端末が見つかると接続を試み，反対に接続依頼を受信すると無
条件で接続するというシステムがある．
（※文責: 仲田健太郎）
1.4.2
網走監獄
後述する「IMES」と「準天頂衛星みちびき」を利用した実証実験を北海道網走にある博物館網
走監獄で 10 月 14∼17 日に行なわれた [?]．実験はソフトバンクモバイル，衛星測位利用推進セン
ター（SPAC），宇宙航空研究開発機構（JAXA）が主導し，市内の小中学生の児童とその保護者の
40 組，東京農大オホーツクキャンパスの大学生 40 人が参加した．実験内容としては IMES を用
いた位置情報取得による網走監獄内でのスタンプラリーである．その中で用いられた内容で本プロ
ジェクトが注目した内容は「敷地内での正確な位置情報取得」，
「屋内でも正確に受信できるか」の
2 点である．この実証実験で，IMES が GPS よりも正確かつ，屋内でも階層情報も含めた正確な
位置情報習得ができることが示された．この結果より，本プロジェクトで目標とした「知能機械技
術による施設内案内」において，階層情報を含めた正確な位置取得を GPS よりも高精度に取得で
きるため，本プロジェクでりようすできるか検討するきっかけにもなった．
（※文責: 畠山大樹）
1.4.3
G 空間 EXPO
2012 年 6 月 21 日，22 日，23 日の 3 日間，G 空間 EXPO というイベントがパシフィコ横浜に
て開催された [?]．G 空間情報が更に高度に実現される社会を実現するために G 空間社会に関わる
産・学・官の様々な分野の技術，製品，サービスが一堂に会する．既存の技術やサービスの発展や，
これまで接点が無かった異分野が融合して，新技術や新サービスが産出されることが期待されてい
る．中でも G 空間 EXPO では，IMES に関する各種のデモンストレーションの実施や宇宙航空研
究開発機構の宇宙オープンラボ公募に位置情報連動広告配信事業の検討が採択された．多くの企業
や技術が出展している中で，本プロジェクトではセンシング技術 IMES(IndoorMEssagingSystem)
に着目した．IMES を用いることで，屋内で位置情報を取得できるので，これを，屋内に設置し，
位置情報を取得することで，屋内ナビアプリケーションを作るのに最適であると考えたからだ．ま
た，屋内ナビアプリケーションを階層変化にも対応させるにあたって，IMES を用いれば，それも
Group Report of 2012 SISP
-3-
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
可能であると考えたからだ．
図 1.3 G 空間 EXPO ポスター
（※文責: 伊東翔）
1.4.4
名古屋大学でのセグウェイの利用
今年 2012 年 1 月から 2 月末にかけて, 名古屋大学でキャンパス内の移動に倒立二輪電動スクー
ター「セグウェイ」を利用した実験が行われた [?]．実験には大学院生や教職員など約 50 名が参加
し，内容としては 3 ヶ所に配置したセグウェイで書類の配達や買い物などに使うというものであっ
た. この実験は，次世代型電動自動車の導入可能性を研究している同大大学院環境学研究科の森川
高行教授の研究室が，経済産業省所管の団体から委託研究を受け，走行経路や速度などはスマート
フォンで管理し，利用情報を蓄積して安全性や利用目的などの研究に役立てるとのことである．
（※文責: 仲田健太郎）
1.4.5
神戸自律移動支援プロジェクト
IMES を利用したナビゲーションの有効性を検証するための実験が，平成 21 年 2 月 6 日∼2 月
26 日の間に兵庫県神戸市中央区三宮地区と神戸空港の 2 地点で行われた [?]．この実験の目的は神
戸地区の特性を踏まえ，利用者の属性に応じて地下から地上までシームレスな経路案内サービス
を提供し，定常的なサービス提供に向けて官民連携による総合的な検証を行うというものである．
特に三宮駅は公共交通機関が集中し，相互の乗り換えを行う利用客が多い．また，三宮地区は地下
空間を含む交通結節点であり，地下から地上へのスムーズなナビゲーションが求められる．その中
で，本プロジェクトが注目した内容は「ナビゲーション対象者を車いす使用者，ベビーカー使用者，
健常者とする」，「 IMES 信号を携帯電話で受信する」の 2 点である．これは，ある程度行動範囲
が制限される車いすなどを対象としたナビゲーションを行うという点が， Selfi を用いてナビゲー
ションを行うという本プロジェクトの内容と関連性が高いと思われるからである．また， IMES
Group Report of 2012 SISP
-4-
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
信号を携帯電話で受信するという点が，本プロジェクトで行う IMES 信号をスマートフォンで受
信するという点が類似しているため参考になると判断した．
図 1.4 JR 三ノ宮地区の IMES 配置図
（※文責: 佐々木康祐）
1.5
現状における問題点
この節では従来のナビゲーションアプリと Selfi を元に ALEFUN の問題点を述べる．
• 従来の屋外で用いるナビゲーションアプリケーションでは GPS で位置情報を取得している
が，この方法で取得する位置情報の精度では現在どの建物にいるかがわかる程度のものであ
り，施設内を案内できるほどの精度はない．
• 本アプリでは屋内での取得に適した RSSI 方式と呼ばれる方法を導入している. これは
Wi-Fi の電波強度を元に計測する手法である．しかし元々電波自体が不安定な物のためこの
方法でも非常に安定しない．また障害物の有無などにより算出できる値が変化するため誤差
が大きい．
• IMES と呼ばれる GPS の電波を用いた新しい測位技術がある．しかし，これはスイッチの
ようなものであり，電波を受信している限り指定の座標を受信するという仕組みである．そ
のため多くの送信機を用意する必要がある．また屋内外で取得が違うため切り替えに難点が
ある．
• Selfi 自体が施設内向けに開発されたものではないため利用者とその周りの安全の確保がう
まくされていない．
• これまでにない操作体型のため利用時における操作面が難しい部分があり，Selfi に初めて
乗る方等で時折危ないシーンが見られる．
• 残量バッテリや速度メータなど具体的なパラメーター表示がないため利用時における Selfi
の状態の把握が難しい．
• 位置情報，ハードともに基本的な機能を無事作成することができている．しかし現状ではそ
れぞれ違う端末なため情報を相互通信する仕組みがない．そこで何らかの手段を用いて連携
を可能にするシステムを確立する必要がある．
Group Report of 2012 SISP
-5-
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
（※文責: 浅野翔太）
1.6
今年度の課題の概要
この節ではナビアプリケーションと知能機械を用いて，施設内を案内することにより発生する課
題について述べる．従来のナビアプリケーションは行きたい所を検索し目的地までのルート案内を
するものであるが，屋内では GPS という位置取得の方式が使えず現在地の取得が困難である為，
施設内を案内するアプリケーションを作るためには探索アルゴリズムや位置を取得する方法を自
分たちで構築しなければならない．また本プロジェクトのひとつの目的，知能機械を用いて，目
的地まで連れて行くという人間の案内に一歩近づく為，今回 Selfi という乗り物と携帯やタブレッ
ト端末で使用することができるナビアプリケーションを作る．次に人間が行うような知能を持っ
た案内を目指す為，目的地までの案内時の周囲の情報も利用者に伝える必要がある. Selfi と端末
を連携させ，施設の使用状況やバッテリー残量などの Selfi と端末間で情報を交換する機能の追加
や，施設内で利用者を選ばず，歩行者にもとっても Selfi が安全でなければならない為，速度制御
などの事故防止装置や Selfi に安全に乗れるよう発着点の作成やタイヤカバーの取り付けが必要と
なる．そこで私たちは selfi の速度制御などをナビアプリケーションと連携して行うために， ADK
（Accessory Development Kit）を用いる．ADK で Selfi と携帯端末間の情報交換をどの程度でき
るのか，どのような機能があれば安全かつ便利に目的地まで向かうことができるのかを検証し，必
要な機能や便利な機能を模索しなければならない．そのほかにもより安全に Selfi を利用してもら
えるように，歩行者に自分の存在を教えるためにライトや音楽を流せる装置，タイヤに物を巻き込
まないようにするカバーなどハード面の追加構築もしなければならない．
（※文責: 三上力也）
Group Report of 2012 SISP
-6-
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
第2章
到達目標
この章では，本プロジェクトの目標の設定について述べる．
2.1
目標
本プロジェクトは，知能機械技術の最終的な目標である人間が行うような知能をもった案内に近
づけるため，前期では位置情報班，ハード班でそれぞれの目標を立てて活動した．まず，位置情報
班は屋内，屋外どちらでも使用できるシームレスなナビアプリケーション開発のために，屋内での
位置情報取得と屋外ナビアプリケーションの実装を目標とした．次に，ハード班は Selfi を組み立
て，完成したものに試乗して現状の Selfi の問題点の洗い出しとその改善案を議論し決定すること
が前期の目標であった．
後期では，前期同様に位置情報班，ハード班でそれぞれ目標をたてて活動した．まず，位置情
報班は，前期に達成することができなかった屋内ナビアプリケーションの構築である．加えて，
IMES を用いて屋内での位置情報取得をより精度の高いものにすることである．ハード班の目標
は，前期に洗い出した Selfi の問題点に対する改善を実際に行い，Selfi を屋内で安全に乗ることの
できる乗り物にすることである．また，プロジェクト全体として，Android 端末と Selfi 間を連携
させる ADK の実装をおこない，屋内で使える乗り物とナビを組み合わせた安全なシステムを構築
することが後期の目標である．
（※文責: 伊東翔）
2.2
組織形態
前期では，ナビゲーションの開発として位置情報班，Selfi の開発としてハード班を置き，各自の
環境を整え開発を始めた．また必要に応じて班内でも担当分けを行った．
プロジェクトリーダー
泉拓哉
位置情報班
グループリーダー
位置班
小野修都
5人
小野修都
伊東翔
町田浩平
八島奎之介
佐々木康祐
UI 班 3 人
畠山大樹
Group Report of 2012 SISP
-7-
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
犬塚悠人
三上力也
ハード班
グループリーダー
組立班
岩山拓哉
2人
岩山拓哉
浅野翔太
組込班
4人
泉拓哉
仲田健太郎
高橋克弥
黒坂愛
後期では，前期での活動で必要だと思われる点やさらに拡張すべき点を実装するためにプロジェ
クト内でのグループを再編成し，3 班に分けた．
独自のナビゲーション技術実装のためのナビゲーション班，Selfi と Android 間通信実装の ADK
班，Selfi 安全確保実装の Selfi 拡張班の 3 班で前期の問題となった部分に取り組んだ．
プロジェクトリーダー
泉拓哉
ナビシステム班
グループリーダー
メンバ
佐々木康祐
5人
佐々木康祐
伊東翔
町田浩平
三上力也
八島奎之介
ADK 班
グループリーダー
メンバ
犬塚悠人
4人
犬塚悠人
小野修都
高橋克弥
畠山大樹
ハード拡張班
グループリーダー
メンバ
岩山拓哉
5人
岩山拓哉
Group Report of 2012 SISP
-8-
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
浅野翔太
泉拓哉
黒坂愛
仲田健太郎
（※文責: 畠山大樹）
2.2.1
教員の役割
このプロジェクトでは，3 人の担当教員と 3 人のアドバイザが参加している．教員は，プロジェ
クト活動において話し合いや技術面での問題が発生した場合のサポート，知識指導，Android 端末
やその参考書等の機材提供を行った．さらに，成果を外部に発表するオープンキャンパスの機会の
提供，スケジュール管理についてのアドバイス，発表スライドや報告書のの添削などを行った．
（※文責: 畠山大樹）
2.2.2
プロジェクトリーダーとグループリーダーの役割
本プロジェクトでは，プロジェクトリーダが，各グループリーダと連携・協力し，活動を行なっ
た．主な活動内容としては，プロジェクト全体のスケジュール管理や，全活動に対する進捗状況の
確認を行うことである．グループとしては，大きく位置情報班とハード班の 2 つの班に分かれて活
動を行い，それぞれの班に 1 名ずつグループリーダを設けた．グループリーダは，各々の班の活動
計画の管理，活動内容の進捗報告を行なった．
（※文責: 仲田健太郎）
2.2.3
支援団体
本プロジェクトでは新技術開発サロンより，プロジェクトの進行促進のために Selfi や錆止めス
プレなどの物品の提供や Selfi 組立における技術的な指導を受けた．また，日立産機システムより，
屋内位置情報取得のために期間限定で IMES を１機を貸し出された．Selfi 開発時には，活動初期
に函館市開発協会理事の大嶋富康様に指導を受けた．
後期では前期の成果を評価され，宇宙航空研究開発機構の JAXA より IMESI を 2 機貸し出さ
れ，IMES の実証実験を行うことになった．
（※文責: 畠山大樹）
2.3
前期の課題設定と到達レベル
ここでは，このプロジェクトの目標を果たすために前期に行った課題と目標について述べる．
1. IMES
屋内用位置情報取得のために，IMES(Indoor MEssaging System) を用いて屋内案内に利用
できるようにする．
Group Report of 2012 SISP
-9-
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
2. Wi-Fi
IMES を利用しない場合の屋内用位置情報取得のために，WiFi 情報から RSSI 方式を用い
て屋内案内に利用できるようにする．
3. GPS
屋外位置情報の取得のために，GPS を用いて屋外案内に利用できるようにする．
4. Google.Maps.API
位置情報の取得やルート取得，地図への情報の追加といった機能を持つ，Google.Maps.API
を利用しナビゲーションシステムの基礎を実装する．
5. 地図作成
屋内用の地図として位置情報のみならず，図形や文字を含めた施設内用の地図を作成し，そ
れを屋内案内に利用できるようにする．
6. データベース
場所名や緯度・経度といった屋内案内に必要となるデータベースを構築するとともに，参照
できるようにする．
7. ダイクストラ法
屋内案内に利用可能な最短のルート検索アルゴリズムを実装する
8. Selfi 組立
Selfi の構造・仕組み等の理解を深めながら Selfi を組み立て完成させる
9. 倒立振子
倒立振子の仕組みを学び，構造を理解することで Selfi の拡張の目処を付ける
10. 外部実装
Selfi を施設内で安全に走行するために必要な拡張機能を議論する．決定した拡張機能を
Selfi 本体に実装する
11. 安全装置
Selfi を施設内で安全に走行するためや，Selfi の接近を他者へ伝えるための安全装置を Selfi
に取り付ける
（※文責: 仲田健太郎）
前期の課題の概要
2.4
この節では?? 節で設定された課題の概要を述べる．各班の構成については?? 節の記述され
いる．
2.4.1
位置情報取得
この小節では位置情報取得における課題について記述する．
IMES
IMES(Indoor MEssaging System) を使用するにあたり， IMES というものがどのよう
に位置情報などを設定しているのか．またどのようにスマートフォンで IMES から送られ
てくる位置情報を取得するのかを調査することを課題とした．
（※文責: 佐々木康祐）
Group Report of 2012 SISP
- 10 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
Wi-Fi
従来の位置情報取得では室内の正確な位置を取得することができない．そのため位置情報
を取得する際に新しい位置取得システムが必要である．手法としては，無線 LAN と IMES
を用いたものがある．前期では，インフラストラクチャが整った未来大ならば機材を導入す
ることなく実装できる無線 LAN を採用し実装することとした．無線 LAN からの位置取得
方法は応答時間から位置を算出する TODA 方式，電波強度から位置を算出する RSSI 方式
と様々な種類があるが，細かい内部設計を必要としない RSSI 方式を本プロジェクトでは使
うこととした．
（※文責: 小野修都）
GPS
一般的に位置情報を取得する場合，GPS（Global Positioning System，全地球測位シス
テム）を用いることが多い．しかし GPS を用いて位置情報を取得すると実際の位置と出力
される位置情報の間には誤差が 30?50 ｍある．また GPS を用いた屋内での位置情報の取得
は階層情報が取得できないなどの問題から困難である．この二つの理由から今回学内の位置
情報を取得する手段として利用するのは難しいと考えた．GPS をどのように利用するか，
また，GPS の問題点に対して, どのような対策を行うかを位置情報班で議論した．
（※文責: 犬塚悠人）
2.4.2
ナビゲーション
この小節ではナビゲーション実装における課題について記述する．
Google.Maps.API
屋 外 の ナ ビ ゲ ー シ ョ ン シ ス テ ム に Google が 公 開 し て い る API の 一 種 で あ る
Google.Maps.API を用いた．Google.Maps.API には位置情報取得やルート取得，地図上に
情報を載せるといったナビゲーションシステムに欠かせない機能がある．また Google Map
が IndoorMap に対応していることを考え GoogleMap が採用された．前期では，施設内屋
外ナビゲーションシステムの基礎を実装することを目標とした．後期では，GoogleMap を
屋内 に対応させることを視野に入れていたが，Google の対応が間に合いそうにないので施
設内屋外ナビゲーションに留まることになった．
（※文責: 八島奎之介）
地図作成
地図作成にあたって，位置班として地図の入手方法・地図形式の決定を課題とした．学内
で案内を行う際，どのような地図を使用するか議論し，地図の形式に関しては， UI 班と議
論して決定した．
（※文責: 佐々木康祐）
データベース
屋内用のデータベースを構成する要素として，学内に散在している無線 LAN のアクセス
ポイントの設置場所と割り振られている MAC アドレスをメンバ全員で目視確認により調査
Group Report of 2012 SISP
- 11 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
し集計した．また屋外用のデータベースを構成する要素として幾つか選出した函館市内の名
所を名称と緯度と経度を Google の機能を用いて調査し集計した．これらの要素から成る屋
内用と屋外用２つのデータベースの位置情報班 4 名で構築した．
（※文責: 畠山大樹）
ダイクストラ法
Android 端末の屋内用ナビアプリケーションの開発を行うにあたって，屋内では GPS に
よる位置情報取得ができず，Google.Directions.API を使ったルート検索ができないため最
短ルート検索アルゴリズムを独自で開発し実装する必要があった．そこで，カーナビの経路
探索や鉄道の経路案内などに用いられるダイクストラ法を用いることにした．なので，前期
は，ダイクストラ法に関して勉強し，屋内のルート探索アルゴリズムとして，どのようにす
ればいいかを検討し，実装することが目標である．
（※文責: 伊東翔）
2.4.3
Selfi 拡張
この小節では Selfi 拡張の方法について記述する．
Selfi 組立
人を目的地まで連れて行く手段として株式会社エフ・アイ・ティが設計製作を行なってい
る Selfi という電動２輪スクータを採用した．部品の状態で購入し，内部の仕組みを確認し
ながら組み立てを行った．部品が届いた当初は，メンバ全員でパーツの確認，採寸，ドライ
ブユニットの組立，ハンドルユニットの組立といった課題を行なっていたが，正式に班分け
をした後ハード班 6 名により，その後の組立作業を割り当てた．
（※文責: 仲田健太郎）
倒立振子
Selfi の倒立制御プログラムのソースコードが公開されておらず自作する予定であったた
めにまず Selfi に代表される倒立振子という振り子を倒立させた形状で支点の移動により
倒立状態を維持する機械のフィードバック制御方法について学習した．組み込み班が学習
した．
（※文責: 高橋克弥）
外部実装
Selfi を使用する上でどのような問題点があり，どのような機能を追加したいかについて
のハード班全員で議論した．そこで外部実装で解決できる点や拡張機能として，物理的なブ
レーキ，タイヤカバー，Android 端末取り付け用スタンド，ハンドル，Selfi の 3 輪化など
があがり，それぞれの素材や形状などの検討を主に組立班が行った．また，タイヤカバー
と Android 端末取り付け用スタンドについてはモデルを製作することに決定し，組立班が
行った．
（※文責: 浅野翔太）
Group Report of 2012 SISP
- 12 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
安全装置
Selfi の稼働実験では，部屋中に稼働音が非常に大きく学内走行に移行したとき講義の妨
害になるのではないかと危ぶまれた．しかし実際に Selfi 完成後に試乗してみると稼動音は
小さく，むしろ屋内で走行する時周囲の人間が Selfi の接近に気付かないことの方がより危
険視された．実際にどのような解決法をとるのかハード班で議論し，方向指示器やクラク
ションなどの周囲に接近や動作の変更を知らせるための安全装置を実装することに決定し
た．Selfi に導入，実装は組立班が行っている．
（※文責: 岩山拓哉）
2.5
後期の課題設定と到達レベル
ここでは，このプロジェクトの目標を果たすために後期に行った課題と目標について述べる．
1. IMES(Indoor MEssaging System)
ここでは，このプロジェクトの目標を果たすために後期に行った課題と目標について述べる．
2. Google.Maps.API
位置情報の取得やルート取得，地図への情報の追加といった機能を持つ，Google.Maps.API
を利用し施設内と施設外のナビゲーションシステムの基礎を実装する．
3. 地図作成
屋内用の地図として位置情報のみならず，図形や文字を用い施設の説明を含めた屋内用の地
図を作成し，アプリケーション上で屋内案内地図として利用する．
4. データベース
場所名や緯度経度といった屋内を案内するために必要となるデータベースを構築するととも
に，アプリケーション上で検索などの機能に関連付ける．
5. ダイクストラ法
屋内案内に利用可能な最短のルート検索アルゴリズムを実装する．
6. Selfi の組み立て
Selfi の構造仕組み等の理解を深めながら Selfi を組み立てる．
7. Selfi の拡張
Selfi を施設内で安全に走行させるために必要な拡張機能を議論する．決定した拡張機能を
Selfi 本体に実装しモニターをとり，検証・改変を行う．
8. 安全装置
Selfi を施設内で安全に走行するためや，Selfi の接近を他者へ伝えるための安全装置を Selfi
に取り付ける．
9. ADK(Accessory Development Kit)
Selfi と携帯端末をつなげて，速度などの情報交換をする環境を整える．
10. ナビゲーションアプリ
IMES や Google.Maps.API などを用いて屋内で使用できる施設内案内のアプリケーション
を作る．
（※文責: 三上力也）
Group Report of 2012 SISP
- 13 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
後期の課題の概要
2.6
この節では?? 節で設定された課題の概要を述べる．各班の構成については?? 節の記述され
いる．
2.6.1
屋外ナビゲーション
Google.Maps.API
屋 外 の ナ ビ ゲ ー シ ョ ン シ ス テ ム に Google が 公 開 し て い る API の 一 種 で あ る
Google.Maps.API を用いた．Google Maps にはさまざまな API が用意されており，
Google マップの安定した機能や毎日の生活に欠かせない使いやすさをウェブサイトやアプ
リケーションに組み込んだり，地図上に独自の情報を表示することができる．Google Maps
API には Maps JavaScript API ， Maps API for Flash ， Google Earth API ， Static
Maps API ，Web サービス， Maps Data API の様なものが含まれる．Google Maps を用
いた背景には公立はこだて未来大学が IndoorMap へ対応することを考え Google Maps が
採用された．施設内の屋外ナビゲーションの基礎を実装することを目指し，前期では，施設
内の屋外ナビゲーションシステムの基礎を実装することを目標とした．後期では， Google
Maps を屋内に対応させることを視野に入れていたが， Google の対応が間に合いそうにな
いので施設内屋外ナビゲーションに留まることになった．
（※文責: 八島奎之介）
Direction API
Google Directions API は， Google から提供されている HTTP リクエストを使用
して 2 地点間のルートを計算するサービスである．ルートは，出発地や目的地，中間地
点を，テキスト文字列（例: 「東京都港区」，
「公立はこだて未来大学」
）または緯度・経
度の座標で指定する．Google Directions API では，複数の中間地点を分割されたルー
トを返すことで一連のルートを示すことができ，使用者からのルートリクエスト回数や
中間ウェイポイントの個数が制限されているので，考慮すべき点もある． ルート検索は勿論の事，交通手段や，ルートにある程度制限をかけられることが特徴で
ある．
（※文責: 八島奎之介）
Elevation API
Google Elevation API は，地球上のさまざまな場所の高度データをクエリするため
のシンプルなインターフェースを提供する．また，パスに沿って進むと高度がどう変化
するかを計算するため，パス沿いでサンプリングした高度データをリクエストすること
もできる．地球上のすべての場所の高度データと，海底までの水深データ（マイナス値）
を提供する．指定された場所の高度が， Google が所有するデータでは正確にわから
ない場合は，そこから最も近い 4 地点のデータを補間した平均値が返される．Google
Directions API と同様の使用制限があるため，こちらも考慮する必要がある．
（※文責: 八島奎之介）
ルート検索
Group Report of 2012 SISP
- 14 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
音声
前期では施設利用する上で，例えばメールや電話でのやり取りを行ってから初めてそ
こに訪れるような正確な目的地の名称がわからない人を対象とする機能が必要だという
意見があった． それにはどのような方式を取ればいいかをメンバと議論し，リストでの入力とは全く違
う音声入力を Android で実装することにした．
（※文責: 畠山大樹）
リスト
屋内と屋外のナビゲーションに対応させたデータベースを利用時に効率的に利用でき
るようアプリケーションの UI を作成するようにした．
そのために全体の UI を見直し，どのようにすれば使いやすくなるのかを議論し，実
装することにした．
（※文責: 畠山大樹）
テキスト
例えば，現在世の中に普及しているカーナビゲーションである目的地まで行きたい時，
その目的地の指定する方法として電話番号や住所などを打ち込んで検索するという方法
がある．この検索方法は最もオーソドックスであり，ナビゲーションアプリでルート探
索で行き先を指定する際に必ず実装しなければならない項目である．本項目では，私た
ちのプロジェクトで製作を行ったナビゲーションアプリのテキスト入力による検索方法
について説明する．
まず，想定されるルートの表示方法の技術について説明をする．屋外ナビゲーショ
ンは， Google.Maps.API と呼ばれる Google が提供している技術を利用する．こ
の Google.Maps.API に目的地の名称や緯度経度などの情報を受け渡すことにより
GoogleMap にルートが表示される仕組みである．次に目的地を指定するためのテキ
スト入力についてだが，私達が任意の場所に XML を用いてテキストの入力フォー
ムを表示させる．このテキストの入力フォームに目的地の名前を入力するとルート
が表示されるといった仕組みである．この一連の仕組みがどのような過程で進んでい
るかというと，入力フォームに入力されたテキストを Enter ボタンが押されたと同
時にそのテキストが Javascript に送られる． Javascript に送られたテキストはさら
に Google.Maps.API に送られ Google.Maps.API から受け取った情報を GoogleMap
に反映させる．このようにすることにより，アプリケーション上で表示している
GoogleMap にルートが表示されるのである．
私たちは以上のように説明したの仕組みを利用し実現させ，屋外ナビゲーションでテ
キスト入力によるルート検索が可能となることを目指した．
（※文責: 犬塚悠人）
UI
ナビゲーションとして最も重要であると考えられるユーザインターフェースである．そ
れが Selfi と呼ばれる電動立ち乗り 2 輪で使用されるナビゲーションであるならより慎重
にユーザインターフェースを考えなければならない． 本項目では，プロジェクトで製作を
行ったナビゲーションアプリの屋外ナビゲーションのモードのユーザインターフェースにつ
いてその概要について説明する．
私達が前期の間に製作したアプリケーションの屋外ナビゲーションのモードでは，1 つの
Group Report of 2012 SISP
- 15 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
画面上で様々な検索方法を利用できるということを目指して製作を進めていった．そしてリ
スト検索によるルート表示，音声検索によるルート表示，テキスト検索によるルート表示を
実現させた．その中でリスト検索のを除く，音声検索，テキスト検索は 1 つの画面上で検
索が行うことが可能なプロトタイプとなった．当初は、画面の下の部分にリストというボタ
ンを配置していたのだが GoogleMap の表示が小さくなってしまい，地図もルートも見難く
なってしまうという問題点が挙がってきたため，リストのボタンは View 表示からなくした
であった．具体的に屋外ナビゲーションの画面の説明をするのであれば，屋外ナビゲーショ
ンの画面上では基本的に現在地を画面の中心とし GoogleMap が表示されている状態であ
る．その画面上部にテキスト入力フォームをテキスト削除ボタン，音声検索ボタンを配置さ
れている．リスト検索は前述した問題があったためメニューバーの中に表示しそこから画面
を遷移させるといったレイアウトとなった。
しかしながら，屋外ナビゲーションに関して言えば，屋外，屋内のどちらかを選ぶときの
アプリ起動時のスタート画面にすでに GoogleMap が表示されている仕様で，また屋外ナビ
ゲーションの画面にも GoogleMap が表示されている仕様であった．この両者の違いは屋
外ナビゲーションの画面で前述した通り，上の部分に表示されている音声検索ボタンとテキ
ストクリアボタンとテキスト入力フォームがあるかないかの違いのみであった．さらに，ア
プリケーション起動時のスタート画面で，地図をよりユーザに見やすくするために使用した
メニューバーを使用したが，画面上にソフトウェアボタンなどの配置が一切されておらずス
タート画面は GoogleMap のみが表示されているという状態であった．
このままではユーザがこのアプリケーションを使用する際に非常にわかりにくく操作方法
も理解できない可能性があるため，画面が遷移しても似たような画面が出てこないようなア
プリケーションに変更する必要があった．そのため，私たちは XML や Javascript を利用
して，わかりにくい画面遷移をなくすことを第一の目標とし活動を行なって行った．
（※文責: 犬塚悠人）
XML
ナビゲーションアプリを開発していく上でユーザインターフェースは非常に大変重
要なものの一つである．それも，本プロジェクトの場合では， Selfi 乗車中の場合も操
作をする可能性もあった．そのため，ユーザインターフェースは非常にシンプルかつわ
かりやすくする必要があった．そのようなユーザインターフェースを実現させるため
に，プログラミングで XML は必ず必要になる項目である．本項目では，その XML に
ついて，屋外ナビゲーションという視点から概要を説明する．
屋外ナビゲーションのユーザインターフェースは当初，ある１つの画面上で用意した
検索方法を行えるようなものを考えていた．前期の活動ではそのようなユーザインター
フェースを目指して活動した．その活動の際，プロジェクトメンバーが Java のプログ
ラミングの経験が多いわけではなかったため，画面のレイアウトを XML を利用して
いる者もいれば，直接 Java のファイルにプログラムを書き込むものも出てきた．これ
は，プロジェクト序盤に XML に統一するようにしていたのだが，中間発表近くで急
きょメニューバーを用いたユーザインターフェースを実装することとなり，結果として
前期終了時時点でレイアウトが XML で行われている部分と直接 Java のファイルにプ
ログラムが書き込まれた部分が混在したプロトタイプとなってしまった．そのため，ま
ず再度は全体のユーザインターフェースのレイアウトの意識の統一し取り組んでいく必
Group Report of 2012 SISP
- 16 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
要があった．また，アプリケーションのレイアウト担当など役職を決めてしまうとその
担当者以外のメンバーがレイアウトに全く手が出せなくなってしまう恐れがあったた
め，意識を統一すると共に XML を用いたレイアウトのプログラミングを行えるように
する必要もあった．
以上のような，意識統一を再度しっかりと行う事，レイアウトの調整を行えるメン
バーを増やすための XML のプログラミングを学習しできるようになる事の２点を目
標とし活動を行なっていった．
（※文責: 犬塚悠人）
2.6.2
屋内ナビゲーション
位置情報取得
従来技術の GPS について説明すると，地球の周りには 30 基近くの GPS 衛星が飛んでい
る．その GPS 衛星からは時刻を知らせる無線信号が送信されているのだが，その無線信号
を地上の GPS 受信機で受信すると，送信された時刻と到達時刻に差が生じる．この差から
GPS 衛星との距離が計算できる．この計算を少なくとも 4 機の GPS 衛星に対して行い，そ
の情報を基に地上での位置を特定するという仕組みだ．そのため外部要因によるラグが生じ
る屋内などでは正確な位置を計測できない．そこで屋内ナビゲーションを実現するには代替
手段となる新たな位置情報システムが必要となる．
この節では近年注目を浴びている GPS 衛星と同じ電波形式を用いる IMES 方式と無線
LAN の電波強度を元に計測を行う RSSI 方式について記述する．
（※文責: 小野修都）
IMES
この技術は最近になって開発された技術であるため詳しい運用方法などが一般には公
開されていなかった．そこで IMES(Indoor MEssaging System) を使用するにあたり，
IMES というものがどのように位置情報などを設定しているのか．またどのようにス
マートフォンで IMES から送られてくる位置情報を取得するのかを前期に課題とし調
査を行った．GPS 技術は地球の周りの GPS 衛星から送信された時刻と受信機への到
達時刻の差から，複数の GPS 衛星との距離を計算し，その情報を基に受信機の地上で
の位置を特定している．それに対し IMES は，GPS 衛星と同じ電波形式を用いた屋内
GPS 送信機（モジュール）を設置し，送信機からは時刻情報の代わりに送信機の「位置
情報」を送信する．これにより受信機側では屋外で行われる時差の計算を行わず，屋内
GPS 送信機の位置情報を受信機の位置としてそのまま受け取り，受信機の屋内外での
シームレスな利用を可能にしたものであることがわかった．そのためナビゲーションシ
ステムとして利用するには多くの設置台数を確保する必要が有る．また IMES 送信機
から送信される信号は，GPS や準天頂衛星と周波数や変調方式で互換性がある無線信
号であり，そもそも GPS や準天頂衛星などの衛星測位システムとは全く異なる測位方
式であること，航法メッセージのフォーマットが IMES の独自であることから，GPS
受信機のファームウェアに若干の機能追加が必要であることがわかっている．既存の
GPS 受信機と同一のハードウェアで，屋外と屋内をシームレスに測位できるという特
徴を持つため，屋内測位技術の一つとして注目を浴びている. しかし現状ではライセン
Group Report of 2012 SISP
- 17 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
スの都合上，システムを利用するには最初から準天頂衛星システム（初号機 みちびき）
に対応しているチップが必要なのだが搭載された端末は少ない. そのため本プロジェク
トの実現に向けこれらの要件を満たす必要がある．
（※文責: 小野修都）
RSSI
従来の位置情報取得では室内の正確な位置を取得することができない．そのため位置
情報を取得する際に新しい位置取得システムが必要となった．そこで前期ではインフラ
ストラクチャが整った未来大ならば機材を導入することなく実装できる無線 LAN から
の位置情報取得を採用し実装を行った．無線 LAN からの位置取得方法は応答時間から
位置を算出す TODA 方式，電波強度から位置を算出する RSSI 方式と様々な種類があ
るが，細かい内部設計を必要としない RSSI 方式を本プロジェクトでは使っている．こ
の方式は無線の送信機の場所がわかっている場合にのみ使用することができ，最寄りの
アクセスポイントから来る電波の強度を元に電波が交わっている点を計測し現在地の取
得を行う．障害物のない見通しの良い屋外では TDOA，RSSI どちらの位置検出方式
も，精度± 1m 程度で位置検出可能である．しかし施設内では，マルチパスフェージン
グ（遅延波による電界強度の変動の影響）を大きく受けるため，位置精度は非常に低下
してしまう．また計測に使用しているアクセスポイントは学校の送信機を使用している
ため配置が変更されたり場所が把握できず大体の位置で検出しているものもあるため現
在地との誤差も大きいためその分計算がずれてしまう．そこで後期ではこの位置情報取
得の精度改善に取り組むことにした．改善策として各フロアごとの電波の変動する値を
事前に計測しておき誤差の修正と本プロジェクト側でアクセスポイントを用意し電波が
届いていない場所への設置などを行う．
（※文責: 小野修都）
ルート表示
ナビゲーションを行うために，必要なことが 2 つある．一つ目は，位置情報の取得．二つ
目は，目的地までのルートの表示．そして，そのルートをもとにユーザを目的地まで案内を
することである．屋外ナビゲーションのアプリを開発するためには，前述の３つを行うこと
が出来る Google.Maps.API がある．しかし，屋内においてそれを行うための API は存在
しない．そのため，この３つの機能を備えていて，かつ屋内ナビゲーションが可能であるア
プリの開発をすることとなった．これらのうち，屋内における目的地までの最短ルートを表
示するために 2 つの方法を考えた．一方は，最短ルートを探索するためのアルゴリズムを構
築し，そのアルゴリズムを用いてアプリ上でルート表示を行うもの．もう一方は，あらかじ
め検索される可能性が高いルートを画像として作成しておき，ユーザが選択した条件にある
ルートを画像として表示するものである．この両方の方法で実装し，実際にアプリを使った
テストを行った後，どちらの方法が屋内のルート表示に最適であるか検討した．
（※文責: 町田浩平）
アルゴリズム
ユーザの現在地から目的地までの最短経路を探索するアルゴリズム構築を行い，その
アルゴリズムを用いてルートを探索し，アプリ上でそのルート表示を行った．構築する
アルゴリズムは，ダイクストラ法を選択した． ダイクストラ法とは，グラフの 2 点間の最短経路を求めるアルゴリズムで，最短経路
Group Report of 2012 SISP
- 18 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
問題に用いられる．現在では，カーナビのルート探索や電車の路線検索に応用されて
いる．
（※文責: 町田浩平）
パターンを用いたルート表示
屋内でナビゲーションを行うにあたって，公立はこだて未来大学に対応した屋内用の
ナビゲーションアプリを作成する必要がある．そのためには，現在地から目的地までの
最適なルートを算出し，表示しなければならない．しかし，屋外ナビゲーションで用い
た地図上に目的地までの最短ルートを表示する Google.Maps.API は屋内には対応して
いない．また，屋内では GPS 衛星からの信号を取得することができないので， GPS
を用いた現在位置を取得することができない．また，屋内のナビアプリケーションは
Selfi に搭乗している際に使用するという点を考慮し，利用者が使いやすく，わかりやす
い UI を設計しなければならない．わかりやすい UI を作るために TOP 画面にアプリ
ケーションで行うことが出来る動作を明確に示したボタンを用意する必要があると考え
た．また，より便利にする為スマートフォンやタブレット端末などを使用したことがあ
る人とない人で仕様をボタンで変えられるようにすることで利用者に合わせられる UI
を構築する．
UI
私たちのプロジェクトのテーマにもなっている施設内案内をする上で Selfi に乗車してい
る状態で事故があってはならない．しかし，現在カーナビゲーションの脇見運転による追突
事故も多数発生していて，この事例も施設内案内で起こりうる可能性のあるものである．こ
のような事例が施設内案内で起きないようにするするためにはナビアプリケーションのユー
ザインターフェースの工夫をしなければならない．本項目では，製作を行ったナビアプリ
ケーションの屋内ナビゲーションのユーザインターフェースについて，その概要を説明す
る． 屋内ナビゲーションのユーザインターフェースを開発するにあたって，屋外ナビゲーション
のユーザインターフェースと整合性がなければならない点を意識しなければいけなかった．
しかしながら，前期終了時点で屋外ナビゲーションのユーザインターフェースは 1 つの画面
上で様々な検索方法を利用できるということを目指して製作を行なってきていたものテスト
運用が可能であるレベルであったため，後期ではある程度プロトタイプはできていたものの
屋外ナビゲーションと屋内ナビゲーションを一緒に開発しなければならない状態にあった．
しかしながら，この両者は View の表示に幾つか大きな違いがありユーザインターフェー
スに整合性を持たせることが単純な作業ではないことが予想された．例えば，屋外ナビゲー
ションでは WebView を使用しているのに対し屋内ナビゲーションでは，プロジェクト内
で作成した学内の地図の画像の表示であるという違いや，ルート表示に関しても，屋外ナビ
ゲーションの場合は Google.Maps.API と呼ばれる技術を用いたルート表示を行なっている
のに対し，屋内ナビゲーションの場合では図形描写でルートを表示させなければならないと
いった違いなどがあった． また， View の表示の問題以外にも屋外ナビゲーションには，テキスト検索，音声検索，リ
スト検索の 3 種類の検索方法があるが，屋内ナビゲーションの検索方法にはリスト検索の 1
種類であるためそのような違いも考慮し，整合性のとれたユーザインターフェースを考えな
ければならなかった． このような問題を解決し，屋内ナビゲーションのユーザインターフェースを完成させること
Group Report of 2012 SISP
- 19 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
を目標とした．
（※文責: 犬塚悠人）
2.6.3
ADK
ここでは 3 つに分けた班の内の一つの名前にも使われている ADK という単語についての詳細
とその導入の背景を記述する． 先に Android Open Accessory (以下 AOA ) というものについて記述する．AOA は Android 端
末に接続できるハードウェアを作成するために Google が作成した規格である．AOA では回路
図やプロトコルの内容などの全てがオープンに提供されており誰もが自由に利用することができ
る．つまりこの規格に従えば様々な Android 端末で使用できるデバイスを作ることができるとい
うものである．今回はこの中の Android 端末からデバイスを制御したり，逆にデバイスからの情
報を Android 端末で受信して利用するといった点に着目した．このような AOA の開発環境を
Android Open Accessory Development Kit (以下 ADK ) と呼び，今回これを利用して開発を
行ったため ADK 班という班を作成した． 今回 ADK を利用した背景を前期での成果物である Selfi とナビアプリケーションだけではそれぞ
れ独立したシステムであるため，一つのまとまったシステムとは言いがたいものがあった．また，
Selfi とナビアプリケーションの 2 つを情報共有することができれば将来的にできることの幅が広
がると考えた．例題として 2 つ挙げる．Selfi の車輪の回転数を求めてナビアプリケーションの方
で利用することができれば，現在のナビアプリケーションのように現在位置だけではなく方向を表
示することができるかもしれない．ナビアプリケーションの方であらかじめ危険箇所や混雑のし
やすい場所，時刻を登録しておけば，そういった場所だけ Selfi の走行速度に制限を持たせたりア
ラート音などで警告することにより，更に安全を追求することができるかもしれない．この様な将
来的にできるかもしれないこと，やれるかもしれないことを増やす意味でまず最初に ADK を導入
する必要があった．
環境導入
本項目では， Selfi とナビアプリケーションを相互通信させ一つのシステムとするための
環境導入や設定に関する概要について説明する．
前期の活動において，ハード拡張班は Selfi の組立，問題点の洗い出し，位置情報班はナ
ビゲーションアプリの開発をそれぞれ取り組んできた. 前期終了時点でハード拡張班は Selfi
を完成させた．その他にも， Selfi 自体の問題点や Selfi に乗車する人視点での問題点， Selfi
の近くにいる第 3 者視点での問題点などの洗い出しを行い成果とした．また前期終了時点
で位置情報班では音声認識によるルート表示，リスト検索によるルート表示，テキスト検索
によるルート表示が実装された屋外ナビゲーションモードのシステムの完成や私たちのプロ
ジェクト内で独自に学内の地図を作成し屋内ナビゲーションでその学内地図の表示およびそ
の地図上に Wi-Fi を利用しその学内地図に現在の位置情報の取得させるこどが可能となっ
たプロトタイプの開発し成果とした．
しかしながら，ここで問題として挙がってきたは，製作した Selfi とナビゲーションアプ
リの連携についてであった．前期活動中，Selfi とナビゲーションアプリを別々で製作した
ため知能機械として成り立っていないのであった．私たちのプロジェクトの目標を達成する
ためには，この 2 つの成果物を連携，相互通信させて 1 つのシステムとし，知能機械技術を
Group Report of 2012 SISP
- 20 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
実現させなければならなかった．そのため， ADK と呼ばれる外部の USB ハードウェアと
Android 端末が双方向でやり取りが可能となるキッドを使用して相互通信ができるように
開発を進めていった．
しかし，ここでも問題が挙がってきたそれは．Selfi 自体に直接書き込みが技術的に非常に
困難であるという点であった．現状のままでは相互通信が行えず連携不可能となってしまう
ことが推測されたため，知能機械技術を実現するために Selfi と Android 端末のアプリケー
ションを相互通信するためのマイコンボードを Selfi もう 1 つ追加し連携を可能とさせた．
以上のような経緯から Selfi と Android 端末のアプリケーションを相互通信するために
Eclipce に ADK を利用するための設定，環境導入とマイコンボードにプログラムを書き込
むための新たなソフトウェアの導入，設定が必要であった．
（※文責: 犬塚悠人）
基盤作成
ここでは ADK を導入するために必要な課題のうち，基盤を利用しての信号線や電力供給線
の確保における課題について述べる．
ADK を導入した時， Android と接続するマイコンと ADK を利用して Selfi に付け足
す機能に応じた装置とその電力供給や信号線の確保が必要になる．よってその作業に適した
マイコンの選択と電子回路の初歩からの知識の獲得が課題である．（※文責: 高橋克弥）
（※文責: 高橋克弥）
バッテリー表示
Selfi 完成時にメンバ全員で試乗し，何が不足や不便と感じるか議論した．議論の結果の
一つに Selfi の機能でのバッテリー残量の告知が曖昧というという問題点が挙げられた．そ
こで Selfi のバッテリー残量の表示を Android で実装するようにした．
（※文責: 畠山大樹）
音声操作
本プロジェクトでは Selfi と呼ばれる乗り物を採用し使用している．これは倒立振子と呼
ばれる仕組みを応用した自動二輪スクーターである．この Selfi はこれまでにない操作体型
のため利用時における操作面が難しい部分があり，初めて乗る方には特にその傾向が強い．
そのため複雑な操作を運転中に行っている余裕はない．そこでシステムを簡単な操作で利用
するという点を元に本プロジェクトではハンズフリー操作の代表である音声認識による操作
の実現を目指した．音声を認識する仕組み，操作を受け付けてからの処理を実装すると共
に Selfi 側にも回路を新しく設ける必要がある．そこで今期では Android Open Accessory
Development Kit(ADK) を用いることでハード・ソフトの連携を実現し，音声認識には
Android 側で提供されている RecognizerIntent や SpeechRecognizer と呼ばれる音声認識
API を用いることで試験的に音声認識操作による Selfi のライト点灯を実装してみた．
（※文責: 小野修都）
Group Report of 2012 SISP
- 21 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
2.6.4
Selfi 拡張
上位マイコン
ここでは Selfi のプログラム面での拡張における課題について述べる．
現状では Selfi の駆動プログラムのソースコードは公開されておらず自分たちでソース
コードの改変を行うことができない．そのため Selfi の車体の駆動制御を思い通りに変更さ
せようとする時，ソースコードを書き換えることによって駆動プログラムを変更することが
できないため駆動プログラムを別の方法で変更しなければならないという課題がある．すぐ
に手に入れられる情報は各種センサから送られてくる信号の数値のみでありこの情報を生か
して課題を達成する必要があった．
（※文責: 高橋克弥）
Selfi 2 台目
ここでは，後期での Selfi 本体についての課題概要を記す． Selfi 制作会社の株式会社エフ・アイ・ティから Selfi の 2 台目 (以下 2 台目と表記) が届い
たので，組み立てる必要があった．前期で Selfi の 1 台目 (以下 1 台目と表記) の組み立て
作業を終了させ，組み立てのノウハウを得たので，前期より早く組み立てることが可能であ
る．なお，2 台目にハード的な拡張・改造を施していった． Selfi についての大きな課題としては，安全性の向上が第一である．1 台目で組み立てを終
え，試乗会や，各メンバが乗っていったので，何が実際に危ないのか，危険だと感じるのか
が分かった．よって，その危険だと感じる部分を改善していく必要がある．なお，2 台目を
組み立てながら必要な改造を施していった．その細かい内容としては，暗い場や，視界確保
のためにライトの追加．靴ひもなどの巻き込み防止のためにタイヤカバーの設置． Selfi の
発進時の車体のぐらつきを解消するための機構などが必要である． 第二に必要な課題としては，ナビアプリとの連携するための仕組みである．前期終了時点
では， Selfi とナビアプリがそれぞれ単独なものとしてあった．なので，お互いを一つのも
のとして動かす必要がある．その細かい内容としては，ナビアプリとの連携を図るために
Arduino を設置する． Arduino から端末に配線をつなげるために Selfi の車体に配線を通
す穴を開ける．ナビアプリの端末を置くための土台の設置．などの作業を行った． なお，各活動の詳細については，プロセスの詳細を参照．
（※文責: 岩山拓哉）
タイヤカバー
前期の時点で， Selfi はタイヤが外部に露出している為，靴紐や足等を巻き込む危険性が
あることや視覚的に恐怖心を煽るのではないかという問題が挙げられており，これらの問題
点は，搭乗者の安全を守るという観点から解決する必要があった．一方，同じ倒立自動二輪
車であるセグウェイには本体とタイヤの間にカバーもしくはそれに準ずる物が用意されてい
る．これらのことから， Selfi にタイヤカバーを取り付けるべきであると考え製作を決定し，
前期の段階で試作モデルをダンボールで製作した．後期の活動では，タイヤカバーの完成を
目指すものである．その課題として以下のことが考えられた． 1 つ目として，タイヤカバーに用いる素材の検討である．この素材は足をぶつけても壊れな
い程度の強度を持つものである必要があると考えた．このとき，自転車のフェンダーを参考
Group Report of 2012 SISP
- 22 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
に素材の検討を行ったが，タイヤカバーにより適した素材の判断をつける事が難しかった．
そのため，新技術開発サロン様にタイヤカバーの製造の依頼とともに素材の検討を依頼する
ことで問題の解決を図った． 2 つ目は，タイヤカバーの形状の問題である．まず初めに前期でモデルを製作したが，今回
の目的である「タイヤに靴紐や足等を巻き込むことを防ぐこと」を満たすためにより適した
形状を模索した．このとき，「タイヤに靴紐や足等を巻き込むこと」だけでなく「視覚的な
恐怖心」を防ぐことが可能である事を重視した．その結果として前期で制作したモデルの形
状で制作することとした． 3 つ目は，加工の方法である．前期に行ったタイヤカバーのモデルはダンボールを用いたた
め鋸で容易に成形できたが，試作品に用いる素材はダンボールより加工が困難なことは容易
に予想できた．さらに，試作品のタイヤカバーは Selfi の外観に関わるためできる限り綺麗
に加工する必要があった．しかし，プロジェクト内で想定した素材を加工することができな
いと判断したため，新技術開発サロン様に製作を依頼することとした． 4 つ目は，タイヤカバーを素材から加工するために図面を描く必要があることである．これ
は，当初新技術開発サロンにタイヤカバーの製作を依頼するために必要であった． CAD に
よる製図と手書きによる製図を考えたが， CAD の製図技術の取得に時間がかかることから
手書きによる製図を行うことにした．手書きによって完成した図面はコンピュータに取り込
み，新技術開発サロン様への依頼に用いた． 以上の 4 つの課題を解決し，タイヤカバーを完成させることがタイヤカバー製作の課題で
あった．しかし，新技術開発サロン様にタイヤカバーの製作を依頼することが困難となって
しまった．そのため，プロジェクト内でタイヤカバーを完成させることが必要となった．以
下にその後の活動の課題について記述する． 1 つ目の課題は加工方法の検討である．素材をタイヤカバーに加工できなくなってしまっ
たため新たに加工方法を探す必要があった．加工方法として未来大学内に導入されたレー
ザーカッターを用いた加工は，比較的容易でありプロジェクト内でも使用可能であると判
断したためレーザーカッターの使用を決定した．しかし，レーザーカッターを用いるため
CAD を導入する必要が出てきた． 2 つ目に素材の検討である．素材の検討は，プロジェクト内で加工できるような加工のしや
すさであり，入手のしやすい素材が必要であると考えた．また，用いる加工方法がレーザー
カッターとなったため，レーザーカッターで加工できるものである必要も出てきた．これら
の点を考慮し，加工がしやすくレーザーカッターで加工が可能であるアクリル板を用いるこ
とに決定した． 3 つ目に新たな形状の検討である．レーザーカッターで加工を行うこととなったため，容易
に加工できる形状が求められた．タイヤカバーの目的を満たすことに加え，レーザーカッ
ターで加工が可能な形状として新たに 2 つのモデルを考えた．この 2 つから製作するタイ
ヤカバーを決めることとした． 4 つ目として，新たにタイヤに靴紐が巻き込まれるか実験を行う必要があることである．こ
れは靴紐の巻き込み事故はどの程度の頻度で起こりえるかを調べることで，タイヤカバーの
目的として重視すべき点を決めることや，タイヤカバーの形状を決めることに役立てるため
である． 最後に図面製作である．図面製作は，手書きで行うこととしていたがレーザーカッターを使
用するに当たり， CAD を導入する必要が出てきた．そのため CAD を用いた製図方法の取
Group Report of 2012 SISP
- 23 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
得を行うこととした． 以上が本プロジェクトにおけるタイヤカバーの課題の概要である．なお，各活動の詳細につ
いては，プロセスの詳細に記載する．
（※文責: 浅野翔太）
発着場
本プロジェクトにおいて施設内案内に使用する乗り物 Selfi ，この 1 台目の組立が前期に
完成した．その Selfi に我々プロジェクトメンバや担当教員，その他本大学の学生らが試乗
した結果， Selfi に乗るときに乗りづらさや恐怖を感じるという声がよく挙がった．また，
10 月に市立函館高等学校の生徒に Selfi の試乗をしてもらい，その後アンケート調査を行っ
た．アンケートの結果としては，我々と同じ様に， Selfi に乗り降りするときに恐怖を感じ
るという意見が目立っていた．．
これらをふまえ，原因となる Selfi 本体のぐらつきや乗り場の高さ，安定性を改善すべく，
Selfi に乗るときのために足場となる発着場の作成を行った．発着場の完成後のテストから，
完全とまではいかないが， Selfi へ乗るときの恐怖感を解消することができ，更なる改善案
として Selfi から降りるときの恐怖感を失くし， Selfi 本体の不安定な部分，ぐらつき感を
失くすという課題が得られた．発着場を作成した結果として， Selfi へ乗りやすくなった，
乗ったときのぐらつく動作による後退することがなくなったという２つの結果が得られた．
また，発着場を作成することで解決できた乗りづらさの問題から，そこからさらに安全にか
つ乗り降りしやすくするにはどうしたらいいかという問題の発見と解決への道筋が見えて
きた．
（※文責: 仲田健太郎）
ハンドル固定
Selfi が施設内で走行するにあたり，我々はまず Selfi に乗り降りする点での危険性に着
目した．現段階では， Selfi に乗り降りするとき， Selfi 本体の不安定さからくる恐怖により
車体がぐらついたり，転倒してしまう危険性がある．そこで，我々はこの危険性に関し原因
と解決策を考えた．まず，原因として挙げられたのが， Selfi に乗ったときに本体が固定さ
れていないという点と，乗り降りするときに何か支えとなるものがないという点であった．
特に， Selfi が発進時のときに固定されていないという点に関しては，乗った人のバランス
感覚に委ねられる為，初めて乗る人には誰かが近くで支える必要があるということがよく見
られた．ハンドル固定の作成に至る前に， Selfi への乗りやすさと Selfi 本体の不安定さを
解消するために発着場の作成を行ったが，発着場では Selfi 本体を倒立したまま固定し支え
るということに至らず，完全に Selfi へ乗るときの恐怖感を解消することはできなかった．
そこで， Selfi を倒立したまま支えるためにも，バランスが大きく影響する Selfi のハンド
ル部分を固定するものを作る必要があると考えた． 今年度の活動では，ハンドル固定のモデルとしてハンドルを外側から支えるものと， Selfi
自体に搭載してハンドルを支えるいくつかのパターンのモデルを考案し，その中でも作成，
テストまでの期間を長く必要としないものを選び設計に至った所で今年度の活動は終わり，
今後試作モデルをいくつか作成し，課題を解決していく必要がある．
（※文責: 仲田健太郎）
Group Report of 2012 SISP
- 24 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
走行時の警告音
Selfi を学校内で走行させるには, 歩行者との接触といったようなことが起きてはいけない.
そこでそれを防止するような安全面の機能が必要であると考えた, そこで, 私たちは接近報
知音をで導入し, その必要性を確かめるための実験, 接近報知音を鳴らすための仕組み, 音の
種類, 音量といった項目についてどのようなものが学校でいうシチュエーションで鳴らすの
に適しているかについて検討した. 詳細は以下の課題解決のプロセスで説明する.
（※文責: 泉拓哉）
足型
前期に Selfi の１台目が完成した後，プロジェクトメンバや担当行員，市立函館高等学校の
生徒，本学内の学生で試乗を行い施設内で使う上での問題点を洗い出した．そのときに出た
問題点として，初めて乗る際に立ち位置が前になりすぎている人であったり，足が左右でば
らばらになって正確な立ち位置に足を置くことができない人が何人かおり，正確に圧力セン
サを感知できないという問題があがった．そこでその問題点を解決するため， Selfi の立ち
位置に目印の作成を行った．詳しくは課題解決のプロセス詳細にて説明する．
（※文責: 黒坂愛）
Group Report of 2012 SISP
- 25 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
第 3 章 前期の課題解決のプロセスの詳細
この章では， プロジェクトで行った様々な課題解決のプロセスについて述べる．
位置情報取得
3.1
この節では位置情報を取得するための技術について記述する．
IMES
既存のスマートフォンで IMES 送信機から送られてくる電波を取得することができるか
評価実験を行った．送信機は株式会社日立産機システムの屋内 GPS 送信機評価セットを使
用した．具体的に調査した内容とその結果は以下のとおりである．
IMES 送信機の設定方法
IMES 送信機の接続は PC とシリアルケーブルで接続する ( IMES 送信機は PC に
シリアルケーブルで接続して利用する)．シリアルケーブル ( D - sub9pin ) を USB に
変換して使用を試みた．しかし COM ポートを開くことができず IMES 送信機の設定
を変更することができなかった．そこでシリアルケーブルを直接接続できる PC を使
用した所， IMES 送信機の設定を変更することができた．IMES 送信機の設定は付属
していたソフトを利用することによって設定を変更した．IMES 送信機に書き込む情報
は IMES 信号出力状態， PRN 番号，航法メッセージタイプ，航法メッセージ内容，送
信出力レベル，中心周波数である．航法メッセージ内容は緯度，経度，フロア，高度，
ID 形式である．実験を行うために設定は IMES 信号出力状態は ON ， PRN 番号は
173，送信出力レベルは 10，中心周波数は 1575．42 MHz，航法メッセージ内容は北緯
30°，東経 40°，フロアは 3，形式は JAXA 位置情報形式 2 に固定し，必要に応じで
変更をした．
IMES 送信機から送信される電波を受信することのできる距離
IMES を使用するにあたって，学内に IMES 送信機を配置する必要がある．そのた
めに IMES 送信機が送信する電波の到達距離を調査することによって，効果的に IMES
送信機を配置することができる．調査した結果， IMES 送信機の送信出力レベルを最
小の 10 に設定した際の到達距離はアンテナの向きによらず約 8.5 ｍであった．また，
IMES 送信機の送信信号レベルを最大の 5 に設定した際の到達距離はアンテナの向き
によらず約 12m であった．IMES 送信機から送信される電波の最小到達距離は約 8.5m
であったが，さらに電波の届く範囲を狭めたい場合は IMES 送信機の電波を遮るもの
で覆う事によって解決する．
スマートフォンで IMES の電波を取得方法
本プロジェクトでは Android を搭載したスマートフォンまたはタブレット端末でナ
ビゲーションを行うことを想定している．そのためスマートフォンで IMES の電波を
Group Report of 2012 SISP
- 26 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
受信し地図上に反映できるか調査した．調査した結果 IMES 送信機から送られてくる
電波をスマートフォン単体で受信することはできなかった．これはスマートフォンに搭
載されている GPS チップが IMES を認識することができないからであった．
図 3.2
評価用 IMES 受信機
図 3.1 IMES 送信機
（※文責: 佐々木康祐）
Wi-Fi
Wi-Fi を用いて現在位置情報を取得するために，室内で無線 LAN を用いて位置情報を
取得するものを担当教員が昨年度受け持っていた SmartFUN が開発していたため，その開
発データを流用させてもらった．位置算出に使用するアクセスポイント (以下 AP) は学内
に設置してある無線 LAN である fun-wlan を用いた．この方式では端末が受信した電波強
度が高い AP3 つの座標と電波強度から，端末の位置を算出している．また AP は電波強度
を元に調査を行い配置場所を学内のある一点を原点として考え校舎全体を座標系に設置して
いる．求めた AP データは SQLite を使いデータベースに格納した．端末が受信したアクセ
スポイントの電波を電波強度の強い順でソートし，上位 3 つのアクセスポイントの BSSID
を利用してデータベースから座標を引き出している．次に電波強度を用いて，それぞれのア
クセスポイントと端末との距離の求め方を式を使って記述する．求める現在地の座標を X ，
Y ，Z とし，アクセスポイントのそれぞれの座標を x1 ，y1 ，z1 ，x2 ，y2 ，z2 ，x3 ，y3 ，z3
とする．また，それぞれのアクセスポイントからの電波強度を D1 ，D2 ，D3 ，距離を m1 ，
m2 ，m3 とする．電波の減衰量を R とした場合，未来大では R=18 であった
m1 = 10
m2 = 10
m3 = 10
D1 −20 log10 2400+(28−R)
20
(3.1)
D2 −20 log10 2400+(28−R)
20
(3.2)
D3 −20 log10 2400+(28−R)
20
(3.3)
この方式は屋内伝播モデルにあわせて電波強度を AP からの距離に換算する公式である.
そして 3 点のアクセスポイントの位置と，各 AP からの距離がわかれば，球の方程式をつ
かった連立 3 元 2 次方程式を解くことで位置を算出することができる．
(X − x1 )2 + (Y − y1 )2 + (Z − z1 )2 = m21
(3.4)
(X − x2 ) + (Y − y2 ) + (Z − z2 ) =
(3.5)
2
2
2
(X − x3 ) + (Y − y3 ) + (Z − z3 ) =
2
2
2
m22
m23
(3.6)
また，解が全て虚数解だった場合は，電波強度の一番強いアクセスポイントを現在地とし
た．しかしそれでも解が出ない場合がある．そこで，新しい補助の計算方法として，3 点の
重心を求めることにした．アクセスポイントの座標をベクトルとして，電波強度を重みとし
て用いて，3 点の重心を求めている.
X=
Group Report of 2012 SISP
D1 x1 + D2 x2 + D3 x3
D1 + D2 + D3
- 27 -
(3.7)
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
D1 y1 + D2 y2 + D3 y3
D1 + D2 + D3
D1 z1 + D2 z2 + D3 z3
Z=
D1 + D2 + D3
Y =
(3.8)
(3.9)
この式によって現在地の座標 X ，Y ，Z が求められる．三点計測とこの方法を組み合わせ
ることで，アクセスポイント 3 点から電波を受信できれば，必ず解となる座標が求めること
ができる．
（※文責: 小野修都）
GPS
本プロジェクトでは，屋内の位置情報取得に GPS の導入が困難であること，また誤差が
30?50 ｍあり学内の位置情報（取得）の手段としては利用できるほどのものではなかったこ
とが判明したため，位置情報班で GPS をどのように利用するかについて議論を行った．議
論の結果，学内の案内のための位置情報取得に IMES を用いることとなった．本プロジェ
クトで開発しているナビゲーションアプリに屋内，屋外の両方を案内出来る機能を実装し
た．そのために，ナビアプリケーションの屋外ナビゲーションの機能に GPS を用いた位置
情報の取得の手段を実装した．具体的には，GPS を用いて位置情報を取得している Google
Map を使用して屋外ナビゲーションを実装した．
（※文責: 犬塚悠人）
3.2
ナビゲーション
この節ではナビゲーションに必要な現在地の情報を示す地図や目的地までのルート取得方法につ
いて記述する．
Google.Maps.API
GoogleMap のサービスは Android でも配信されているが，GoogleMap を使ったソ
フトウェアの開発はパソコンに配信されているものを使用しなければならなかった．
GoogleMap は Web 上でのサービスなので，GoogleMap の機能を利用する為に JavaScript
と HTML5 で開発した．
・開発準備
Android アプリケーションは Java で開発するため，JavaScript と連携するプログラム
の作成から始めた．Java から JavaScript を呼び出すサンプルプログラムが動いたことを確
認し，屋外ナビゲーションシステムの本格的な開発に進んだ．
・地図取得
Android 上に GoogleMap を表示することは Web 上のサンプルプログラムから必要な部
分を抜き出すことで解決した．現在地を地図に表示させるために，GPS から現在地情報を
得るプログラミングを参考にして現在地を地図のセンターにして表示することができた．現
在地取得ができたのかを確かめるために，地図ピンを現在地に置くことも実装できた．
・ルート取得
屋外ナビゲーションシステムの重要な要素であるルート取得の基礎プログラミングは図書
を参考に実装した．Google から既に Google.Directions.API という２地点間のルート取得
Group Report of 2012 SISP
- 28 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
をする API が公開されており，今回はこの方法を採用した．
・ルート検索
二地点間のルート取得には出発地と目的地を設定する必要がある．出発地は現在地を軸と
し，目的地は多様な方法で決定できるようにした．
先ず地図自体から目的地を決めることができるように「マップをクリックした地点」を目
的地に定める方法をとった．イベント処理で，クリックした地点の緯度経度を取得する方法
を模索し，現在地からのルート取得を実装した．
次に目的地検索の他の方法として「文字入力検索」を実装した．JavaScript では document
オブジェクトを使用してテキストボックスやボタンを配置できる．テキストボックスに入力
された地名・建造物等の緯度経度を取得することで目的地に定めることができた．
目的地の指定方法に音声入力を加えた．音声入力に必要な Recognizer.Intent.API は
Java に対応しているが，JavaScript に対応していなかった．そこで，Java と JavaScript
の値の受け渡しができるようにしなければならなかった．音声入力とレイアウトを考え，文
字入力検索も Java から指定する方法に変更になった．
いくつかのリストから目的地を選択し，検索する方法に取り掛かった．SQLite によって
つくられたリストである．文字入力，音声入力によるルート検索に比べ，画面遷移が絡むこ
とで実装は困難だった．一度は実装できたが，拡張機能実装の際，バグが発生したため現在
実装できていない状態である．
・現在地・ルート更新処理
ナビゲーションシステムの一つとして，現在地とルートを更新することを実装した．GPS
による位置取得を繰り返す処理を行うと，ルートが何重にもなることが分かった．現状で
は，ルートを更新するためにルート表示をしては消すという処理を行なっている．ルート更
新する際，ルートが点滅するので処理方法に改善が必要である．
・ログ（足跡）表示
ルートを通った後の軌跡を描くものである．ルート表示に用いられてるラインの色を変え
ることを試みたが，断念した．次に，ルートを Polyline で表示することで色を指定すること
ができた．
（※文責: 八島奎之介）
地図作成
学内の地図作成するにおいて以下のプロセスを踏んだ．
地図の入手方法
学生便覧の地図をトレースして使用した．これは，学生便覧の地図が手に入りやす
く，位置を表示する上で現在地をわかりやすく表示できると考えたためである．またト
レースすることによって線や文字が荒れることなく地図を拡大・縮小することができる
ようになった．しかし，学生便覧の地図と実際の建物の縮尺が異なることがわかり，現
在地を地図上に表示する際に実際とは異なる位置に表示される恐れがあったので新たに
地図を作成することとなった．地図を作成する上で誤差を限りなく減らす必要があっ
た．そこで，学内の部屋の大きさを測る上で，学内にあるコンクリートの支柱と床のタ
イルを基準とした．これは，コンクリートの支柱はすべて同じ大きさで，等間隔に置か
れているため地図作成の基準とするには最適であったからである．また，床のタイルを
Group Report of 2012 SISP
- 29 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
基準とした理由は，学内に敷かれているタイルの大きさは一辺が 50cm の正方形で，均
等に学内に配置されていたため地図を作成する上でグリッドの役割を果たすことができ
ると考えたからである．しかし階層が変わるとタイルの位置は異なるので，3 階北側の
モールに敷かれているタイルが学内全域に敷かれているものと仮定して地図作成にあ
たった．
デザインの設計
地図といえば利用者に合わせた様々な形式の地図がある。たとえば、ある地点から
ある地点までの道筋を示す地図であれば、その目的地までの道筋をわかりやすく示すた
めに曲がり角などに特徴的な目印を印す。また、周囲との建物や施設などとどれぐらい
離れているかを示したいときは、地図上において建物を正確な場所に印すことより、距
離を印すような地図を描く。さらに、パリの路線図を印した文字や施設などの正しい位
置を印すことなく視覚的に情報を伝える地図などもある。これは、路線の分別に焦点を
当てて、情報を伝えようとした地図である。つまり、地図とは利用者にどのような情報
を伝えるのかということで、地図のデザインを変えなければならないということであ
る。私たちのアプリケーションは幅広い年齢の人々の利用を想像している。そもそも私
たちのプロジェクトは、巨大ショッピングセンターや空港などの広くて道がわかりづら
い場所を歩いて移動するのは疲れるし、迷ってしまうという方々に、 Selfi という屋内
で使用できる移動手段と屋内で使用できるナビゲーションを組み合わせたものを解決と
して提供しようと考えている。巨大ショッピングセンターや空港などの広い場所を歩い
て疲れてしまう人というのは多かれ少なかれ、ご年配の方々も含まれる。ご年配の方々
は携帯電話やスマートフォンなどに慣れていない方や、 Google Maps などに代表され
る電子地図を利用したことが少ない方が多い。そのような方々でも使いやすい地図を作
成することを目標とした。また、 Selfi にのっている際に地図を見ることを考えると、
文字などの読まなければならない情報をなるべく少なくし、視覚的な情報をより多く含
むべきだと考えた。そこで、色彩的な情報を重視したデザインを設計した。色彩の違い
は人間がすぐに認識できるもので、異なる言葉を話す者同士でもわかりあえることがで
きる。これより、地図の色を重視したわけだが、時に、部屋の分類を色彩を用いて表現
した。学内は部屋の分類は大きく分けて教員室、講義室の 2 つ分けられる。これはその
部屋を主に利用する者が教員、事務局の方か学生がということで分けた。これは来客が
主に部屋を訪ねる相手が、学生または教員の方々を訪問するかのどちらかであると考え
たからである。それより、学生が主に使う講義室などを青、教員の方々が使用する部屋
を黄色に統一した。また、壁など通行することができない場所は灰色で一段と暗い色で
表した。これにより、通行できない場所と色彩から認識できると考えた。また、地図上
にエレベーターや、トイレなどにアイコンを用いて、誰でもわかりやすく認識していた
だく工夫を行った。つぎに、本プロジェクトで地図を利用する目的は屋内でナビゲー
ションを行うために地図を利用する。ナビゲーションを行う際に、地図が正しくない
と、正しい位置情報を取得しても地図を照らし合せた際に地図上に間違った位置が表示
されてしまう。そのため、ナビゲーションを行うことができる距離や通路の幅などの情
報が詳細である必要がある。そこで、測量した詳細な学内の情報をもとに、厳密に通路
や部屋の地図を作製した。
地図データ形式の決定
Group Report of 2012 SISP
- 30 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 3.4
図 3.3
イラスト のみで表したパリ の路線図
羽田空港 からの距離 を表した地図
地図形式は UI 班と話し合った結果，ファイル形式は昨年のプロジェクト学習の
Smart-FUN で使用していたものと同じ PNG 形式を使用することになった．これに
よって画像を差し替えるだけで地図を変更することができた．また，ナビゲーションを
行うにあたって昨年の SmartFUN で使用していた画像サイズでは小さいので，720 ×
907px に変更した．
図 3.5 実際に作成した学内 3 階の地図
（※文責: 佐々木康祐）
データベース
屋内の位置情報取得について前述した RSSI 方式で用いるアクセスポイントの情報を収集
する必要性が出てきた．そこで今回は前プロジェクトの SmartFUN プロジェクトを参考に
し，アクセスポイントの BSSID と x 座標，y 座標，z 座標，電波強度をデータベースに格納
した．データの中身はアクセスポイント集計での BSSID と此方側で新しく学内マップに対
応した座標を割り当てて格納した．用いた端末は Android 端末であったので SQLite でテー
ブルの定義などを行った．BSSID は TEXT 型，各座標と電波強度については DOUBLE 型
で宣言した．アプリケーションでは既に登録されている BSSID と各座標に対応したアクセ
スポイントの電波強度を一定期間で更新し，強度の高い順にソートを行い，RSSI 方式の計
算に提供した．
Group Report of 2012 SISP
- 31 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
屋外での実装では予め調べた位置名とそれに対応した緯度と経度を登録した．その登録し
た情報を Google.Map.API を用いるプログラムの方に渡すようにした．
現段階では屋内の位置情報取得では RSSI を用いていたが後期からは IMES を主軸に用
いるのでそのサポートで使用する予定である．屋外のものはサンプルとして残しておき今後
で必要となった時に今回のノウハウを生かし，使用したいと考えている．
以下の画像が屋内でのデータベースで用いたものである（図??）．実際のアプリケーショ
ンでは別の方法で表示するが，確認のため今回はこのようなものを例に表示する．
図 3.6
データベース使用サンプル例
（※文責: 畠山大樹）
ダイクストラ法
屋内用の最短ルート検索アルゴリズムを実装するにあたって，どういったアルゴリズムを
用いて，それを開発するアプリケーションに適応させるかを知る必要があった．そのため，
最初に参考書などを調べていって試行錯誤した結果，カーナビの経路検索や鉄道の経路案内
などでよく用いられる，ダイクストラ法を用いた最短ルート検索アルゴリズムを実装するこ
とになった．まず，ダイクストラ法をどのように屋内に対応させるかを，考える必要があっ
た．その結果，学内に予めいくつかの位置情報をもったノードを配置し，ルート検索を行う
際，現在地からもっとも近いノードをまず算出してそこを現在地とおく．そして，そこから
目的地までのルートをダイクストラ法を用いて検索する方式を考えた．前期では，この方式
の考案と，Java でダイクストラ法のプログラムを構築するとこまではだきた．しかし，実
際に屋内ナビアプリケーションに組み込むには至れなかった．なので，後期にはこの方式に
対応した，屋内ナビアプリケーションを実装するのが目標である．
（※文責: 伊東翔）
3.3
Selfi 拡張
この節では Selfi 拡張の解決プロセスについて記述する．
Selfi 組立
本プロジェクトでは施設内案内に Selfi を用いることに関して考えられる様々な問題の割
り出しをプロジェクトメンバ全員で行なった．実際に乗った上での問題提起も行う必要があ
るため，Selfi の組立を優先して行なった．
まず始めに，届いたキットからパーツの確認と採寸を行なった．採寸はパーツごとに写真
Group Report of 2012 SISP
- 32 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
を撮り，それぞれの寸法データをその写真に書き起こした．データの書き起こし後は，ドラ
イブユニットの組立，ハンドルユニットの組立，基盤の作成の 3 つの担当に分かれ別々に組
立作業を行なった．ドライブユニットの組立時には，パーツの不具合が見つかり，その修復
作業も行なった．
それぞれのユニット完成後はメインフレームの組立，バッテリホルダの組立，配線の調
整，最終組立の順で作業を行なった．最終組立後，加速度センサ，ジャイロセンサ，ステア
リングの調整を行い，Selfi の組立が終了した．しかし，第一回目の試乗実験後，モータ部分
に取り付けていたチェーンが外れ，モータの一部が損傷するという問題が発生し，一度 Selfi
を分解し，修復作業を行なった．
修復作業後，センサ等のパラメータの微調整を行い，Selfi の第二回目の試乗を行なった．
このとき左折ができないというハンドル操作での問題が見つかり，再度センサの調整と試乗
を繰り返した後，Selfi の組立が完成した．
（※文責: 仲田健太郎）
倒立振子
倒立振子の学習にはヴィストン株式会社より発売されている倒立振子制御学習教材
BeautoBalancer Duo を利用した．倒立振子では角度センサ，角速度センサから得た上体の
傾きを元にどれくらい前進もしくは後退することで倒立状態を維持できるかを計算しモータ
へ出力している．そこでこの商品では既に完成品として倒立振子のアルゴリズムが C 言語
で組まれたプログラムソースコードが配布されていたためそれを利用し，どのコードで上体
の傾きからモータへの出力を計算しているのか実機を使って検証しながら学習した．
（※文責: 高橋克弥）
外部実装
Selfi にどのようなものを外部的に実装するべきか議論を行い，タイヤカバーの追加，ハ
ンドルの操作方法及び素材の変更，物理的ブレーキ，Selfi の 3 輪化，Selfi に Android 端末
を取り付けるためのスタンドなどを考えた．物理的なブレーキは使用時に Selfi 自体が前方
向に転倒してしまう危険性があると判断したため実装しないことを決定した．また，Selfi の
3 輪化についてはブレーキによる転倒防止のために実装する予定であったが，制御が難しい
こととブレーキの不採用が決定したため実装しないこととなった．タイヤカバーは素材の検
討を行いダンボールでモデルを製作した．ハンドルの操作方法の変更はセンサの位置を変更
することで解決することに決定し，ハンドルの素材については検討を行った．Android 端末
取り付けのスタンドについては検討を行い，モデルを購入し取り付け部分を自作した．
（※文責: 浅野翔太）
安全装置
Selfi の静音性が高いので，進路に居る人間に注意を促し，周囲に存在を認知させるとい
う目的のために音を鳴らす機器を実装しようと考えた．具体的には車のクラクション，自転
車のベルなどの警告音を発するものである. 他にも，Selfi の方向転換を行うときに突然進
路変更を行うので，告知するために方向指示器を実装しなければならないと考えた．具体的
には車のウィンカなどである．前期では検討段階にとどめ，本格的な実装は後期に予定して
いる．
Group Report of 2012 SISP
- 33 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
（※文責: 岩山拓哉）
グループでの活動
3.4
この節ではプロジェクトの班毎での活動内容を記述する．
3.4.1
位置情報班
ここでは施設内案内を行うためのナビゲーションシステムに対して位置情報班が行なった作業内
容を記す． 位置情報班はナビゲーションシステムを構築する上で必要となる位置を用いた機能実
装をする位置班と画面遷移や成果を組み合わせる UI 班の二つの班に別れて活動を行なった． 活動
内容については以下の通りである．
5月
プロジェクト開始が 5 月だったことや異文化交流会の方々が来られるとのことだったのでプ
ロジェクトメンバ全員での全体活動が主だった．
• プロジェクトメンバと初顔合わせを行い， 具体的に何を目指すのか，そのためにどう
やって行くかなどの意見を出し合い，方向性の指針を決めた．
• 作業に伴い班を作成した．それぞれが所属したい班の希望にあわせ，各人員の所属す
る班を決定した．その後にプロジェクトリーダー，ハード班リーダー，位置情報班リー
ダーを仮決定し，暫定で活動を開始した．
• 最優先事項として交流会の方々来られ発表会があるとのことだったので Selfi を展示す
るためメンバ総出で組立作業を行った．Selfi の組立作業を行う際に，今後に備えパー
ツの仕分けと寸法を調べて記入も行った．
• 組立作業と並行して開発環境の構築を各自で行い，作成したプログラムを実行するため
には Android 端末が必要なため持っていないメンバのため担当教員からタブレットを
3 台借りた．
6月
位置班
• 本プロジェクトが想定していた IMES は規格制定中のため購入ができず貸し出しのみ，
納品も６月後半になるとの事だった．そのため前期では評価実験に留めることにした．
• 従来の GPS などといった位置情報取得方法では室内での運用上問題がある．そこで
IMES に変わり昨年度，室内位置取得に成功した SmartFUN の開発データを元に開発
を行い RSSI 方式を用いて去年の方式に拡張という形で実装を行った．
• 計算にはアクセスポイント (以下 AP) の座標が必要だが去年のリストはあるものの配
置が大幅に変わっているため再度，学内の AP の集計を行った．
• 実装を進めていくうちに公開されている地図の縮尺が間違っていることが発覚このまま
では計算にずれが生じるため cm 単位で正確な地図を作成した．
• Google が IndoorMap に対応し始めたことや Direction や Elevation API などを考慮
し Google API を用いたナビゲーションの実装決定．それに伴い Direction API によ
る目的地までのルート表示を実装した．
• 室内に対応した目的地までの探索がないためカーナビなどに搭載されている探索アルゴ
リズム，ダイクストラ法を作成した．
UI 班
• サンプルを元に画面遷移や Activity の組み合わせ方などを習得した．
Group Report of 2012 SISP
- 34 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
• 探索データを格納する必要があったため SQLite を用いたデータベースの構築を行った．
• データベースを利用することで目的地のデータを取得しリスト検索の仕組みを作成
した．
• Google が提供する Recognizer Intent API を用いることで音声入力による検索の仕組
みを作成した．
• アプリが出来上がるにつれ体裁を整えるためアプリアイコンなど UI 部品を作成，組み
込んだ．
• プロジェクトとしてロゴと T シャツを作ることになったためメンバーで Inkscape や
7月
Gimp を使ってデザインについて提案し合った．
• 中間発表が近くなったこともあり，機能拡張と UI 調整の人員を残し中間発表で発表す
るスライドとポスター製作に人員を分け活動した．
• タブレットだと落ちるなど軽いバグを抱えながらも音声認識，リスト検索とナビゲー
ションの組み合わせを実現，去年の位置算出方式の修正が完了し中間発表成果物として
提出した．
• 成果物と話し合いの内容に合わせポスター，スライド製作，中間発表を行った．
（※文責: 小野修都）
3.4.2
ハード班
ここでは施設内案内に使用するための乗り物の Selfi に対してハード班が行なった作業内容を記
す. ハード班は Selfi の仕組みなどを理解するために組立作業を行なった組立班と Selfi を制御する
ために倒立振子とプログラムを勉強する組込班の二つの班に別れて活動を行なった. 活動内容につ
いては以下の通りである．また，組込班の 5 月と 7 月の活動では組立班と一体になり活動したので
割愛する．
組立班は以下のように活動を行った．
5月
5 月はプロジェクトが発足した月だったので，プロジェクトメンバ全員での全体活動が主な
ものだった．
• プロジェクトメンバの初顔合わせをし, 具体的にどういう機能を実装したいかの意見を
出し合い，どういう方向性に進めるのかの指針を決めた.
• 必要となる班を作り，それぞれが所属したい班の希望を取り，各人員の所属する班を決
めた．その後にプロジェクトリーダー，ハード班リーダー，位置情報班リーダーを仮決
めし，暫定で活動を開始した.
• 最優先事項として Selfi の組立作業を行い始めた．Selfi の組立作業を行う際に，改造，
改良するためには Selfi の詳しい構造を組立を行いつつ把握することに努めた．
• パーツの仕分けと寸法を調べて記入し，各ユニットごとに A，B，C と名称分けをし，
各ユニットごとに製作開始した．
6月
• 5 月では Selfi の組立作業が終わらなかったので，Selfi の組立作業を引き続きで行なっ
ていた．
• Selfi のモーター回転制御確認，傾き確認など姿勢制御系の調整を行なった．
• Selfi の部品の不備で，タイヤと車軸の太さが合わないことが判明したので，うまくは
Group Report of 2012 SISP
- 35 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
まるようにするため，車軸を削り始めた．Selfi の車軸とタイヤをはめ込めるようにし，
バッテリー取り付けを行い初期完成した．
• Selfi の試乗を行なったが Selfi のモーター部分及びチェーンが破損．破損部分の復旧作
業及び，破損した原因究明のため Selfi を解体し点検作業を行なった．
• 組立班及び組込み班の 2 つに分かれる．
• Selfi のボディ部分に錆が目立ち始めたの錆止めを吹き付け，塗装した．
• Selfi の故障部分の復旧作業を終え，試乗したが，右にしか旋回できないという問題が発
見されたので，パラメータの微調整を行い，その後特に問題がなかっので，Selfi 完成と
判断した．
• Selfi の問題点洗い出し及び改良案及び解決案をまとめた．そのうちで，一番最初に取
り組む問題として剥き出しのタイヤを覆うタイヤ部分のカバーモデル作成することに決
定した．
7月
7 月は中間発表に向けての準備ということで主にプロジェクトメンバ全員で活動をを行
なった．
• タイヤ部分のカバーモデルの作成が 6 月中に終わらなかったので 7 月に作成の続きを
行いモデルを完成させた．
• 中間発表に向けて前期成果物や，前期に行なった活動などのポスター製作やスライドの
製作を開始した．中間発表に向けての発表練習を行なった．・中間発表を終えた後に各
自の報告書での担当を終えた．
組込班は以下のように活動を行った．
6月
• 組立班及び組込み班の 2 つに分かれる．
• Selfi の姿勢制御のアルゴリズムを把握するためにミニチュアを利用して HEW の勉強
と倒立振子のアルゴリズムの勉強を開始した．
• 組立班で Selfi 復旧作業が終了したので，全体で試乗を行なった．・Selfi の問題点洗い
出し及び改良案及び解決案をまとめた
（※文責: 岩山拓哉）
Group Report of 2012 SISP
- 36 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
第4章
前期結果
この章では, プロジェクトを通じて得た成果とその評価について記述する．
4.1
4.1.1
成果
位置情報班
位置情報班は基本的なナビゲーションシステムの構築を行った．
成果としては開発環境の構築， 開発する上での UI， 未来大学の構内図 FUN map と Google
map を用いた地図，GPS などによる従来方式による位置取得，RSSI 方式による室内位置取得，
IMES の評価実験，Google Direction API によるルート表示，目的地までをつなぐ探索アルゴリズ
ムの構築 (ダイクストラ法)，SQLite を用いたデータベースの構築，リスト検索や音声検索といっ
た検索システムなどがあげられる．
・開発環境整備
本プロジェクトの Android 開発は各自の所有パソコンで行った．Eclipse に JDK や ADK の
セットアップを行い開発環境を整えた．
・UI
アプリのプロトタイプが完成したためそれに伴いシステムのボタンやアプリアイコンを設定
した．
図 4.1 アイコン
図 4.2
スクリーンショット
・GPS などによる従来方式による位置取得
端末側が提供している Location Manager や Geolocation API を用いて GPS や 3G，Wi-Fi か
ら位置を取得している．ただし屋外を想定した手法のため誤差が大きい．
・RSSI 方式による室内位置取得
アクセスポイントの座標と電波強度を元に位置情報を算出し取得している．室内位置情報を取得
することは可能であるが電波というものはとても変動しやすいため案内システムの主軸とするには
精度が心もとない．
・IMES の評価実験
本プロジェクトが想定していた技術である IMES が 6 月末に到着したためどのくらいの精度が
必要なのか，設置にはどのくらい必要なのかなど評価実験を行った．この結果，精度は問題ないが
スマートフォンのチップの都合上そのままでは受信できないことが判明した．そのため現在，対応
Group Report of 2012 SISP
- 37 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
に向け製作会社との協力し活動を行なっている．
・ダイクストラ法
一般的なカーナビなどに使われている探索アルゴリズム．A*を基本としたアルゴリズムで web
や書籍を参考にすることで実装した．ただし，学内の探索ノードなどの都合上中，間発表成果物に
は組み込んでいない．
・SQLite を用いたデータベース (DB) の構築
RSSI 方式の実装やリスト検索の実装には探索用のデータを格納しておく必要がある．そのため
データベース構築に SQLite を用いて実装した．
・検索システム
Textview を使用することで文字入力による検索を実装している．また Google が提供する
Recognizer Intent API を用いることで音声入力による検索も実装した．SQLite を使い用意した
データベースを利用することで目的地を選択するだけですむリスト検索も可能にしている．
・FUN map と Google map
今回位置取得を実装していく上で公開されている未来大学の地図に縮尺がおかしいことが発覚し
た．このままでは計算式と矛盾し正確な値を返すことができないため cm 単位で正確な地図を作成
した．また他の場所の情報を取る必要もあることや Google が IndoorMap に対応したことを考え
全体地図として Google map を採用した．
・Google Direction API によるルート表示
Google から既に Google Directions API という２地点間のルート取得をする API が提供さ
れている．これを用いることで屋外での目的地までのルート表示を実装している．また，Google
Directions API は web を用いてるため javascript で記述する必要がある．そのため端末の機能を
使っている検索システムと連動するため Java と javascript を連携する仕組みも実装している．
（※文責: 小野修都）
4.1.2
ハード班
ハード班は前期バラバラの部品で届いた Selfi の組み立てかつ仕組みの確認，組みあがった Selfi
に実際に試乗してこのまま乗るには危険だと思う点を中心に問題点の洗い出し，Beauto Balancer
Duo を用いた倒立振子の倒立制御アルゴリズムのソースコードの書き方の学習を行った．
成果としては 5 分程度練習をした運転手が通常に運行できる Selfi の完成，いくつかの問題点の
抽出，倒立振子のアルゴリズムを今年度中に自作するには他の作業も鑑みるに現実的でなく他の方
法を考える必要があることがわかったことなどがあげられる．
・Selfi の組み立て
部品が全てバラバラの状態で塗装もはんだ付けもなしの状態で届いたためまずは部品の確認を
行った．Selfi のホームページのマニュアルを頼りにハンドル部，土台部，モータ駆動部の大まかに
3 つに別れて全ての部品を数え，見つけた部品から縦横奥行き弧の半径など採寸を行った．採寸が
終わると全てデータ化しメンバで共有した．同時に電子部品の確認も行った．全ての部品の確認が
終わると組み立てに入った．採寸したデータとマニュアルを整合しながら一つずつ組み立てていっ
た．どうしても欲しい大きさの電圧が入力されないことがあったが届いた時点で接続されていた部
品の絶縁がなされていないことが原因であった．完成後試乗会を開いたがメンバの一人が乗ったと
ころ制御が全くできず，ついにはモータの駆動をタイヤに伝えるチェーンが外れてしまい故障し
た．チェーンのたるみと取り付けたタイヤの向きを間違えていたことなどが原因であった．ここで
Group Report of 2012 SISP
- 38 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ハード班のメンバを 2 つにわけ，一つを Selfi の修繕，一つを倒立振子の学習を活動内容として平
行作業した．
・Selfi の問題点の洗い出し
たるみなどの問題を解決し完成した Selfi に試乗した．最初はハンドルを右に切れない問題が新
たに見つかったがハンドル部の可変抵抗器の固定忘れが原因で翌日には解決できた．解決後メンバ
で特に問題なく試乗できることを確認し，安全を確認した上で走行した．新たな問題が浮上してき
た．それは，Selfi の機能についての問題ではなく Selfi に乗った状態でどう感じるかなどの心象的
な問題であった．乗り始めは非常に怖く，目線が高くなるので上手く制動できないなどの問題であ
る．これらの問題は乗る前にメンバが乗り方を懇切丁寧に説明したうえで最初は支えるなどして運
転練習時間を設けることで対応することに決定した．
・現状の Selfi の問題点
タイヤがむき出しであり巻き込みの危険性があるということ，ハンドルが自転車やバイクと同じ
ような形状をしているにもかかわらず操作方法がこの二点と異なっており特に初心者が乗る際に戸
惑うであろうということ，モータ駆動なので走行音が非常に静かであり歩行者が Selfi に背後から
近寄られた場合など認知が遅れるケースが想定されるということ，より速度を落としたほうが安全
であるということ，バッテリーの残量がわかりにくいということ，Selfi は全体的に重く堅い素材で
できているので，特にハンドルの部分など万が一ぶつかったときに非常に危険であることなどが挙
げられた．
・倒立振子
姿勢制御アルゴリズムを自作して Selfi に書き込む予定であったため，そのソースコードの変更
の仕方をミニチュアモデルの倒立振子を利用して学習した．統合開発環境は RENESAS の HEW
であった．どのソースコードでモータを動かしているかなど大まかには理解できたが，ライブラリ
関数を自作する必要があることがわかった．そのため今年度で全て行うには時間がないこと，また
組みあがった Selfi に試乗しながらパラメータを調整するのが危険であることなどを理由に姿勢制
御アルゴリズムの自作は断念した．
（※文責: 高橋克弥）
4.2
各人の課題の概要とプロジェクト内における位置づけ
この節ではプロジェクトメンバ各人の役割と活動内容を記述する．組織形態のメンバの順番から
紹介していく．
位置情報班
小野修都
位置情報班グループリーダー小野修都の担当課題と活動は以下のとおりである．前期
では位置情報班グループリーダーとして，スケジュール管理を行いながら室内ナビの開
発担当として室内位置取得の実装に取り組んだ．
5 月 プロジェクトメンバとの初顔合わせし，プロジェクトの方針を話し合い目標をき
めた．その上で必要となる班を作り，それぞれが所属する班を決めた．また，プ
ロジェクトリーダー，ハード班リーダー，位置情報班リーダーを仮決定した． 私
は位置情報班グループリーダーとなった． 異業種交流会の方々が来られるとの事
だったのでプレゼンに間に合わせるため，位置情報班も合同で selfi の製作に取り
Group Report of 2012 SISP
- 39 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
掛かった． 私はハンドルユニットの製作に関わった． 発表後，位置情報班とハー
ド班に別れ，各班でのグループワークを開始した．私もまた MapView といった位
置の基本から勉強を始めた． ナビゲーションの実装については沢山の方式がある
ため後期に向けいくつかの有用なパターンを選択し各自，担当を決定した． 私は
室内ナビの作成に取り組んだ．
6 月 本プロジェクトが想定していた IMES は規格制定中のため購入ができず貸し出
しのみ，納品も６月後半になるとの事だった．そのため前期では評価実験に留め，
取得には他の手段を取る必要があった．しかし，従来の GPS などといった位置情
報取得方法では室内での運用上問題がある．そこで昨年度，室内位置取得に成功し
た SmartFUN の開発データを元に開発を行った．受領の際，計算式が間違ってい
るとのことだったので電波強度を元に位置取得を行う RSSI 方式を用いて去年の
方式に修正，拡張という形で実装を行った．位置算出にはアクセスポイント (以下
AP) の座標が必要となる．しかし去年の AP は配置が大きく変わりそのままでは
使用することができない．そのため再度計測を行った．
7 月 AP 集計の方は壁に埋まった個体や天井から吊るされたものもあり作業は難航し
た．またメンバーが先行して開発していたナビゲーションの探索アルゴリズムの実
装にも取り組んだ．しかしこちらもルートが分岐したりと中間までに実装すること
ができなかった．急遽ロゴと T シャツを作ることになったためインクスケープを
用いて描いたロゴを一例として提案．中間発表が近くなったこともあり，機能拡張
と UI 調整の人員を残し中間発表で発表するスライドとポスター製作に人員を分け
活動した．また発表にあたりプロジェクトの方向性を完全に固めるために話し合い
を行った．その結果，プロジェクトの最終目標と今年の目標を決めることが出来，
全体の目標を見出すことができた．終盤，私は体を壊してしまったためメンバーの
厚意に支えられながら負担の少ない添削役として活動した．
（※文責: 小野修都）
伊藤翔
位置情報班メンバ伊東翔の担当課題と活動は以下のとおりである．前期では位置情報
班でのナビゲーションにおける探索方法の実装などを主に取り組んだ．
5 月 第 1 回のプロジェクト学習では，プロジェクトメンバーの顔合わせを行い，ハー
ド班と位置情報班の２つのグループに分けた．自分は位置情報班に入った．その
後，異業種交流会との顔合わせのための準備をした．準備として，Sefi の部品を 3
つのグループに仕分けし，全部品の寸法をとった．また，Selfi のねじと銅線や抵抗
などの個数点検と仕分け行い，Selfi の組み立てを行った．Selfi の組み立ての合間
に Android アプリの開発環境を整えた．開発環境としては eclipse をインストー
ルした．その後，Android アプリ開発の一環として Android 実機での位置情報取
得アプリの開発を行った．実際に，Google Maps API と Google.Directions API
を用いておこなった．また，アプリの UI の提案などを行い，開発の方針を固めた．
6 月 屋内ナビアプリケーションを開発するにあたって，階層変化にどのように対応す
るかを検討した．その結果，Google Elevation API を使えるのではないか，とい
う案がでたので調べることとなった．しかし，屋内ではつかえなかった．次に，屋
内ナビゲーションアプリの開発のため，ルート検索アルゴリズムの実装を行った．
まず，ダイクストラ法や A*アルゴリズムなどのカーナビなどにも用いられている
Group Report of 2012 SISP
- 40 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
アルゴリズムの勉強を行い，屋内でどのように使えるかを検討した．その結果，屋
内でも使うことができそうだったので Java で実装した．
7 月 中間発表にむけて，プロジェクトのロゴ製作やポスター内での私が前期に担当し
た探索アルゴリズムの紹介の欄を書いた．また，中間報告書作成のために各項目の
担当者の割り振りをし，文章を書いてもらったものに添削や編集などを行った．加
えて，中間発表のアンケート用紙の作成とグループ報告書の添削作業も行った．
8 月 オープンキャンパスでのプロジェクトの紹介があったので，その準備と当日，
ブースで，訪問してきた方々にプロジェクトの紹介を行ったり，アンケートの記入
をしてもらった．その中で，初めて Selfi を見たひとが屋内でこのような乗り物に
対して，どのような印象をもつのかを，生の声で聞くことができた．
（※文責: 伊東翔）
町田浩平
位置情報班メンバ町田浩平の担当課題と活動は以下のとおりである．前期では主に全
体での相互の連携を整えたアプリの調整を行った．
5 月 プロジェクトメンバとの初顔合わせを行い，Selfi にどのような機能を実装する
か，どのような施設での活躍が望めるかなどの意見を出し合った．その後，ハー
ド班と位置情報班の編成を行った．また，グループリーダーと各々の班リーダー
を決定し，私は位置情報班に所属することとなった. プロジェクトメンバ全員で
Selfi を組み立て作業に取り組み,Selfi のパーツを分類ごとに選別，寸法の計測を
行った．パーツの分類別に組立作業を開始．Selfi が組み上がったところで，ハー
ド班と位置情報班に分かれ，グループワークを開始した. 私の所属する位置情報班
では,Android のナビゲーションアプリケーションの開発を開始した．位置情報班
をナビゲーションシステムを構築する位置班とアプリケーションの画面を作成する
UI 班に分けた．私は位置班に所属することとなった. また，Android のアプリケー
ションの開発環境を整え，Java の勉強を開始した.
6 月 位置情報班では屋外と屋内のナビゲーションに分けて開発することにした．ま
ず, 屋外のナビゲーションを開発するために，WebVIew と Google.Maps.API を
用いることとなった．GoogleMap 上でルート検索, ルート表示をできるようにす
るため，Google.Maps.API の DirectionAPI，HTML5 と JavaScript，XML の勉
強を開始した．Java，JavaScript の間で相互に連携が取ることが出来るようにな
り, ルート検索, ルート表示を行うことが可能となった．また，Java と XML の間
でも連携を取ることができ，UI 班の作成したアプリ画面にルートを表示すること
を可能にした．続いて屋内ナビゲーションの開発に取り掛かった．屋内ナビゲー
ションは，昨年度プロジェクト”SmartFUN”で作成したプログラムをベースに開
発を行うこととなった．SmartFUN で作成したプログラムを位置情報班で作製し
た屋外ナビゲーションのプログラムを統合し, 同じアプリケーションで表示される
ことが可能にするための作業に取り掛かった．また，屋内ナビゲーションを開発す
るにあたり，屋内の位置情報の取得と，ルートを表示するための探索アルゴリズム
を構築する必要が有ることがわかった. 昨年度プロジェクトでは位置情報の取得に
無線 LAN を用いた RSSI 方式を使用おり，まずはその方法で位置情報の取得を行
うことにした．プロジェクトのロゴマーク、Selfi と位置情報を合わせたシステム
名の考案を行った.
Group Report of 2012 SISP
- 41 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
7 月 アプリケーション画面のボタンの配置，操作性を考え，端末のメニューボタンよ
りアプリケーションの操作を行うことを可能とした．昨年度プロジェクトで作製し
た学内のアップを今年度作製したものに差し替えた．また，昨年とはアクセスポイ
ントの位置が違っており，プログラム上のアクセスポイントのデータが昨年のもの
であったため，その修正を行った. 中間発表に向けて，メインポスターの作製に取
り掛かった．メインポスターはバイリンガル指定であるため，英訳を行った．ま
た，中間発表の発表者となり，発表スライドを作製した.
（※文責: 町田浩平）
八島奎之介
位置情報班メンバ八島奎之介の担当課題と活動は以下のとおりである．前期では，
Web の開発担当として屋外ナビの実装に取り組んだ．
5 月 プロジェクトメンバーとの初顔合わせし，プロジェクトの方針を話し合って目標
をきめた． その上で必要となる班を作り，それぞれが所属する班を決めた．また，
プロジェクトリーダー，ハード班リーダー，位置情報班リーダーを仮決めした． 私
は位置情報班に入った． 異業種交流会に間に合わせるため，位置情報班も Selfi の
製作に取り掛かった． 私はモーター部の製作に関わった． 位置情報班とハード班
に別れ，各班でのグループワークを開始した．
6 月 プロジェクト GeoLocation をつかい MAPView の勉強から始めた． 位置情報
の取得方法について話し合いをし，後期に実装しやすいよういくつかのパターンを
考えて担当を決めた． GoogleMAP による屋外探索を担当することになり，その
ために JavaScript と HTML5 の勉強を始めた． Java と JavaScript の連携をとれ
るようにし，GoogleMAP を表示できるようにした． 課題として，UI のイメージ
を提案し全体で意見をまとめた． さらに，現在地をセンターとした地図表示をす
るため GPS による現在地位置取得を実装した． その時，マーカー表示をできるよ
うにした． 次に，地図上をクリックすると，現在地とクリックした地点のルートが
検索されるように実装した． HTML の検索バーと実行ボタン，ルートを削除する
ボタンを配置し，検索からのルート表示を行えるようにした． 地図からルート検
索した時とルート検索が同時に表示される状態だったので，ルートを一本しか表示
できないように仕様変更． 現在地が更新されるように実装したが，線が何重にも
なったので，秒速を測り動いた時に更新されるようにした． さらに，更新された
時にルートが一回消えるバグがあった． その改善をしようと試みていたが中断し，
音声入力を実装するために xml と JavaScript の連携をとれるようにすることを優
先した． 実装が完璧ではないため，更新処理と Polyline の絵画のプログラムを組
み込むことは出来なかった．
7 月 インクスケープを用いて描いたロゴを一例として提案．プロジェクトの方向性を
完全に固めるために話し合った．その結果，プロジェクトの最終目標と今年の目標
を決めることが出来，全体の目標を見出すことができた． 屋外ナビの改善として
xml からの文字入力検索を実装した．その後，メンバーが音声入力を実装． リス
トからのルート表示がうまくいかない状態である．原因を特定するために試行錯誤
し，画面遷移の問題であることが判明した． その点を他の面からカバーして，ルー
ト表示しようとしている．ポスター，スライドの製作に関わる．中間発表では、屋
外・屋内ナビゲーションのデモを担当した．
Group Report of 2012 SISP
- 42 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
（※文責: 八島奎之介）
佐々木康祐
位置情報班メンバ佐々木康祐の担当課題と活動は以下のとおりである．前期の活動で
は，学内地図作成を行った． また，IMES の評価実験の責任者も担当した．
5 月 第 1 回のプロジェクト学習ではプロジェクトメンバと顔合わせをし，プロジェク
トメンバをハード班と位置情報班にわけ，プロジェクトリーダとグループリーダを
決めた．ブレインストーミングを行なって Selfi と位置情報を用いてできることの
アイデアを出し合った．
Selfi を異業種交流会の方々にお見せするためにプロジェクトメンバ全員で Selfi
を組み立てることになった．私はハンドルユニット作成班に所属しハンドルユニッ
トを作成した．ハンドルユニットと駆動部ユニットが完成したのち，位置情報班は
Android アプリ作成を開始した．
Android アプリ開発にあたって，まず位置班と UI 班にグループメンバを分け
た．私は位置班に所属することになった．また Android アプリを開発するために
開発環境を整えた．Android の参考書を借り，Android の基本的なプログラムを
学んだ後，位置情報を取得し GoogleMaps に反映，表示するアプリを開発した．
6 月 ナビゲーションアプリのユーザーインターフェイスをどのようにするのかを，位
置情報班のメンバそれぞれがプレゼンテーションを行い，ユーザーインターフェイ
スを決定した．
ナビゲーションを行うために Google の API を使おうとしたが，Android 用の
API が存在しないということがわかったので，ナビゲーションを行うために別の方
法を考えた．
室内ナビゲーションにおいて階層変化を知るために，GoogleElevetionAPI を使
うことができないということがわかったので，無線 LAN の電波強度から階層を調
べるために無線 LAN の電波強度のデータをサンプリングした．
業者から IMES が届いてからは IMES の評価実験を行った． IMES の設定
を変更して考えられる全ての RPN 番号と中心周波数の組み合わせを変更して，
Android 端末 (Xperia acro HD SO-03D) にインストールした”U-center Android”
で受信を試みた． 昨年の SmartFUN で用いていた位置取得計算方式の精度を上
げるための勉強をした． RSSI 方式を用いて無線 LAN から位置情報を取得した際
に，事前に登録しておいたアクセスポイントの位置を間違った位置に登録した際の
誤差を調べた．学生便覧に乗っている学内地図では縮尺が地図内で違うので位置取
得するために使うことができないので，新しく地図を作成した．
7 月 グループ T シャツのデザインとロゴのアイデアを出した．作成した地図を
Android アプリで表示できるようにサイズを 907 × 720px に変更した．中間発表
に向けてポスターとスライドの作成に入り，IMES の部分を担当した．また中間発
表で何を話すのかを決めた．
（※文責: 佐々木康祐）
畠山大樹
位置情報班メンバ畠山大樹の担当課題と活動は以下のとおりである．前期では，SQL
の開発と報告書の作成を主に取り組んだ．
5 月 プロジェクトメンバとの顔合わせを行い，プロジェクトの方針や目標などについ
Group Report of 2012 SISP
- 43 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
て話し合い，各自の共通の認識にした．その上で必要と思われる位置情報班とハー
ド班の２班を定め，プロジェクトリーダーと各班のグループリーダーを仮決めし
た．そこで私は位置情報班に所属した．
５月中に第１回の異業種交流会があるのでプロジェクトメンバ全員で Selfi の組
立てに取り組んだ．組み立て時には作成ユニット毎にメンバを割り当てユニットの
各部品の採寸後に組立てを行った．組立てがある程度完成した後に本格的に位置情
報班とハード版に分かれ活動をし始めた．私はその時に主に UI 部分での担当をし
始めた．
6 月 どのような UI を作成するか位置情報班で話し合い決定した．その中で UI 部分
を主に開発するメンバを決めた．私はそのメンバとなり，Android 開発環境の導入
と同時に担当部分の実装を行った．担当部分実装後には昨年プロジェクトの成果物
のソースを読み，理解することに努めた．その時に Android に適応している SQL
の使用をしなくてはならないことが発覚し，主にその部分を主軸とした学習を開始
した．ある程度の習得ができた頃には，昨年のプロジェクトでの使用用途と方法が
理解でき，本プロジェクトで開発するアプリにも転用できるようにした．また，同
時期に音声認識 API を用いた検索方法も実装した．
7 月 中間発表が近くになったことで，位置情報班で実装した部分の調整を別の担当者
に任せ，グループ報告書の担当者として各自に書く項目の割り当てや取りまとめと
作成に力を入れることにした．また，全体として改めてプロジェクトの認識のすり
合わせ等を行った．
8 月 オープンキャンパスでのプロジェクトの紹介する機会があり，その準備のために
中間発表のアンケート等からえた得た意見を参考にし，オープンキャンパスで最も
興味のある高校生を対象とした構成に作りなおした．当日では，訪問してきた方々
にスライドやポスター，ALEFUN をを利用したプロジェクトの紹介を行い，アン
ケートの記入を協力してもらった．アンケートの内容は，初めて Selfi を見たひと
が屋内でこのような乗り物に対して，どのような印象をもつのか，というものであ
り，本プロジェクトを行う風景を見ていた未来大学関係者ではなく，本プロジェク
トの利用者になりうる人の意見を聞いた．
（※文責: 畠山大樹）
犬塚悠人
位置情報班メンバ犬塚悠人の担当課題と活動は以下のとおりである．前期では位置情
報班で各自が作成したプログラムをまとめることに大きく貢献した．
5 月 プロジェクトのメンバーと顔合わせとその際に仮のリーダーを決定した．同時に
ハード班，位置情報班の２つのグループに分け各グループリーダーを決定した．私
はそこで位置情報班に所属した．プロジェクトメンバーが各班に別れた後，本プロ
ジェクトの方針を決定するために話し合いを行った．話し合いで本プロジェクトの
将来的な目標と今年度のプロジェクト学習の目標を決定した後，５月中に予定され
ていた異業種交流会に Selfi を見せるためメンバ全員で Selfi のキット組み立てに尽
力した．私は，ここで主にハンドルユニットの組立に取り組んだ．異業種交流会終
了後は各グループに別れグループ単位で活動を行った．さらに位置情報班のなかで
UI(ユーザーインターフェース) 班，位置取得班に別れ活動を行った．私は UI 班と
してナビゲーションアプリのフローチャートなどに取り組んだ．
Group Report of 2012 SISP
- 44 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
6 月 ５月中に決定していたフローチャートを元にナビゲーションアプリの開発を
行った．私は行き先リストから目的地を表示させる部分を担当した．使用言語が
AndroidJava のため，その勉強から始まった．担当していた部分の開発が終了し
た後は各自が受け持ち作ってきたソースコードを合わせ，プロトタイプを製作する
役目を担当した．各個人で製作したため統一性がなかった．そのため，レイアウト
調整は XML で行うことを共通の意識とした．Javascript を用いた Google Maps
の表示がかなり困難であったがインターネットや様々な参考書で調べプロトタイプ
実装することができた．Google Maps が表示されたあとは昨年のプロジェクト学
習の成果物である FUN MAP の実装・組み込みを行った．プロジェクト学習で１
年かけて製作されたソースなだけに Activity の数が多く，またソースコードの解
析から始まった．ソースコードの解析後はプロトタイプに FUN MAP の実装を開
始した．FUN MAP の実装完了後，独自で製作した屋内，屋外の行き先の名前/緯
度/経度が格納されているデータベースからリストを表示する機能をプロトタイプ
に実装した．中間発表まで時間があったため音声入力機能もプロトタイプに実装し
た．また，文字入力で目的地までのルート検索ができるようにするために検索エン
ジンの実装も行った．６月下旬となったあたりから中間発表でプロトタイプを発表
するため UI の微調整に入った．具体的には横画面固定やアイコンの配置などがあ
る．プロジェクト全体の活動としてはシステムの名前と T シャツのデザインと本
プロジェクトのロゴの作成を行った．
7 月 中間発表が近くなったこともあり，６月までに製作していたアプリケーションの
UI を引き続き微調整を行った．スマートフォンなどの携帯端末では問題ないのに
タブレット端末ではエラーが出るという予期せぬエラーがあったため，そのバグの
処理に取り組んだ．６月下旬から７月上旬に決まったプロジェクトのロゴとシステ
ムの名前をウィジェットのアイコンにする作業も行った．さらに，中間発表で発表
するスライドとポスター製作にも取り組んだ．スライドでは位置情報班の技術説明
の部分とスライド全体の添削を行った．またポスターではメインポスターの位置情
報班の前期の活動の大きな枠組みとそれに対応した文章を考え，サブポスターのほ
うではナビアプリケーションの屋外のトピックを考えた．
（※文責: 犬塚悠人）
三上力也
位置情報班メンバ三上力也の担当課題と活動は以下のとおりである．前期では主に
UI でのデザイン作成などを行った.
5 月 プロジェクトメンバーと顔合わせし，グループリーダー決め，プロジェクトの目
標や方針，どういったものにしていくかなど話し合った．プロジェクトを進める上
で，ハード（Selfi の組み立て）班と位置情報（Android のナビアプリを作成）班に
分かれることになり，位置情報班はさらに UI（画面遷移を担当する）班と位置（地
図やナビを実装する）班の２つに分かれたそして，私は UI 班に所属することにな
り，主にボタンのデザイン作成を行った．５月には異業種交流会があるためそれに
間に合わせるためにハード班，位置情報班関係なく Selfi の作成に取組んだ．Selfi
作成にあたっては，ハンドルユニット組み立てを行った．
6 月 それぞれの担当に分かれて作業．文字で部屋名を検索する部分とボタンのデザイ
ン作成と導入を担当．Android でプログラムを作るには Java を使用する．まずこ
Group Report of 2012 SISP
- 45 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
の Java の勉強が始まる．そして，サンプルソースコードを見ながら自分の担当の
部分の作成．ボタンのデザインについては Inkscape と GIMP 2 というソフトを使
い作成した．検索のほうは，ボタンを押し検索バーを出して文字入力するところま
では実装できたが，実際に入力した文字に該当する部屋名を出すことはできなかっ
た．プロジェクトの T シャツとロゴのデザイン，システム名を作成．システム名
は ALEFUN となった．
7 月 中間発表にむけてポスターや発表スライドを作成するために，プロジェクトの最
終目標や今年度私たちはどのように進めていくか，それぞれ担当した部分で導入し
た機能やシステムの説明など話し合った．Android アプリのウィジェットアイコ
ンの作成．
（※文責: 三上力也）
ハード班
岩山拓哉
ハード班グループリーダー岩山拓哉の担当課題と活動は以下のとおりである．前期で
はハード班グループリーダーとして，Selfi の組立等を率先して行った．
5 月 プロジェクトメンバとの初顔合わせし，具体的に Selfi にどういう機能を実装し
たいかの意見の出し合った．その上で必要となる班を作り，それぞれが所属する班
を決めた．また，プロジェクトリーダー，ハード班リーダー，位置情報班リーダー
を仮決めした．私はハード班に入り，グループリーダーとなった．最優先事項とし
て，Selfi を組み立てるためパーツの選別作業と寸法を調べ記入した．ユニットご
とに A，B，C とパーツを分類分けし，分類ごとに組立作業開始．ある程度組み上
がったところで，位置情報班とハード班に別れ，各班でのグループワークを開始
した．
6 月 Selfi のモーター回転制御確認，傾き確認など姿勢制御系の調整を主に行なった．
Selfi にタイヤをはめ込み, バッテリー取り付けを行い初期完成した．Selfi の試乗を
行なった．が，selfi のモーター部分及びチェーンが破損し，解体． タイヤにも問題
が発見されたのでタイヤ部の検討及び Selfi の故障部分の復旧作業に入った．Selfi
のボディ部分に錆が目立ち始めたので，解体したパーツから錆止めを吹き付けた．
Selfi の故障部分の復旧作業を終え，試乗を行い問題なく動いたので，Selfi 完成と判
断した．学内で問題無く移動出来るのか，Selfi に乗って学内移動の実験した． 試
乗してみての問題点，改善しなければならない点の洗い出しをした．問題点の一つ
に，Selfi にタイヤカバーがついていないと靴紐が巻き込まれる危険性があるため，
タイヤカバーモデルの作成を開始した．
7 月 ハード班とシステム班を合流させ，中間発表に向けてのポスター，スライド及び
チーム T シャツなどを共同製作開始．Selfi に付ける Android 端末のスタンドのモ
デルを製作した．発表練習などの予行練習を行った．中間発表ではハード班の発表
補助を担当した．
（※文責: 岩山拓哉）
浅野翔太
ハード班メンバ浅野翔太の担当課題と活動は以下のとおりである．
5 月 プロジェクトメンバとの顔合わせをし，Selfi で実装する具体的な機能とサービス
を話し合い，本プロジェクトの方針を決定．その後，ハード班，位置情報班の配属
Group Report of 2012 SISP
- 46 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
を決定し，プロジェクトリーダー，ハード班リーダー，位置情報班リーダーの仮決
めを行った．私はハード班となった．当初 Selfi の組み立てが最優先事項とされた
ためメンバ全員で Selfi の組み立て作業を行った．ここではまず組み立てる前に，
Selfi のパーツを選別と採寸を行い，各ユニット毎に組み立て作業を開始．組み立
てがある程度進んだところでハード班と位置情報班に別れ，各班毎の活動を開始
した．
6 月 Selfi のモータードライバと加速度センサ，ジャイロセンサ，ステアリングのパ
ラメータの調整とタイヤのはめ込み，バッテリーの組み込みを行い Selfi が組みあ
がった．Selfi の試乗を行ったところ，Selfi のモーターの一部とチェーンが破損し
てしまったため修理のために解体を行った．解体時にタイヤの軸の問題も発見した
ため，そこも含めて故障部分の修理を行った．修理の完了と同時に Selfi の塗装も
行った．その後の試乗に問題がなかったため Selfi 本体が完成．学内での試乗を行
い，室内で Selfi を使用するにあたってどのような問題があるかを洗い出し，改善案
を検討．問題点の一つとして，Selfi にタイヤカバーがなく靴紐等が巻き込まれる危
険性があるということが分かったため，タイヤカバーのモデルの製作を開始した．
7 月 プロジェクトの方向性を確認するために全体で会議を行った．中間発表に向け
て，各班合同でポスターとスライドを製作を開始．発表練習とその確認を行った．
Selfi に Android 端末を取り付けるスタンドのイメージモデルの製作，取り付けを
行った．中間発表においてはハード班組立班の担当箇所の質問に対する回答を担当
した．
（※文責: 浅野翔太）
泉拓哉
プロジェクトリーダー泉拓哉の担当課題と活動は以下のとおりである．プロジェクト
リーダーとしてサイボウズのサイトを利用して，主に全体にかかわる活動予定や全体課
題の連絡をおこなった．
5 月 Selfi を製作にあたって, 電子回路の基盤の部分を担当した. 基盤は, ボードの状態
にはんだづけして電気回路を組むといった，Selfi を制御するのにきわめて重要な
部分の製作にあたった．基盤には，コネクタ，抵抗，コンデンサ，ブザー, などの
様々な部品のはんだづけによる取り付けを行った．また出来上がったら, 他のメン
バーとの協力で回路の点検や調整を行った．
6 月 プロジェクトにあたり，プロジェクト名とは別に自分たちが本プロジェクトで実
現していくシステムの名前についてのとりまとめを行った．案とその理由というも
のをメンバに考えてもらい，それをアンケート式で投票してもらう方法で行った．
最終的に票数の多い「ALE FUN」に決まった．また，その決まった「ALE FUN」
というシステム名のロゴ製作も行い，一般の人が見て，不快でないもの，自分たち
のプロジェクト内容がそのロゴを見ることで伝わるなどといった基準を設けた．
レクチャーモードの製作を行った．イラストレーターを使用し，なるべく文字情
報を少なくして，意図を伝えることを考えイラストで製作した．
7 月 ポスターのレイアウトの取りまとめを行った．ポスター内容については技術的な
部分が多いので，掲載内容については担当したメンバーに記事の内容を割り振っ
た．各記事ができ次第，ポスターに当てはめていく作業を行った．掲載内容につい
て，変更点があれば，随時レイアウトに反映させながらポスター製作を行った．
Group Report of 2012 SISP
- 47 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
（※文責: 泉拓哉）
仲田健太郎
ハード班メンバ仲田健太郎の担当課題と活動は以下のとおりである．
5 月 プロジェクトメンバーとの顔合わせ後，本プロジェクトのコンセプト，最終目標，
Selfi に実装したい機能やサービスを具体的に考え，話し合いを行なった．今後活
動を行うにあたり，ハード班と位置情報班の 2 つの班に分かれ，同時期にプロジェ
クトリーダー，グループリーダーを決めた．話し合い後はまず， Selfi の組み立て
作業に取り掛かった．パーツの確認・採寸，仮組，各ユニットごとの組み立ての順
で作業を行なった．
6 月 Selfi の最終組立が終了した．第 1 回目の試乗を行なったところ， Selfi のチェー
ンとモーターの一部が破損してしまったため，解体と修理作業を行なった．このと
き，タイヤが軸にはまらないという問題も生じたため，これら全てを含めて修理
後，再び最終組立を行い， Selfi の組み立てが完成した．Selfi の完成後は，試乗し
た感想をまとめ，これからどのように改良していくかの話し合いを行なった．ま
た， Selfi のミニチュア版を用いて，倒立振子のしくみについての勉強，マイコン
開発の勉強を行なった．
7 月 Selfi 試乗からのフィードバックも含めて Selfi の拡張機能について話し合い，
Selfi に今後導入していく拡張機能の話し合いを行い，どのように実装するかを随
時確認した．
他からのフィードバックも含めて Selfi の拡張機能について話し合い， Selfi に
今後導入していく拡張機能の話し合いを行い，また，それをどのように実装するか
を随時確認した．その他，中間発表会に向けて，ポスター，スライド等の制作・準
備を行なった．
（※文責: 仲田健太郎）
高橋克弥
ハード班メンバ高橋克弥の担当課題と活動は以下のとおりである．前期ではハード班
メンバとして Selfi 組立に尽力した．
5 月 函館市内の企業が集まった新技術開発サロンの方々に今回のプロジェクトの概要
を説明するために全員で話し合いをした．5 月 16 日にサロンの方々が来校された
のでまとめた内容を発表した．全部品が間違いなくあるかどうかの確認と採寸を行
い，中旬頃から組み立てを始めた．その中で電子部品のはんだ付けの部分を担当
した．
6 月 6 月 6 日に Selfi 完成に伴い試乗を行った．試乗した直後にチェーンが外れてし
まい故障してしまい，修理は他の班員に任せ，自分は HEW を利用して倒立振子
の勉強に入る．倒立振子のプログラムは大まかに把握したがそれは Selfi に一から
プログラミングするためであった．そのため倒立振子の勉強は班員に任せ自分は
Selfi に組み込まれているマイコンの mbed のプログラミングを先行して始めた．
しかし実際には一からプログラミングをすることは現実的ではないことから方針
を変更し，mbed マイコンをもう一台導入してそこに制御プログラムを書き込むこ
とによりもともとのプログラムを書き換えることなく制御するという方針に変更
した．
7 月 ポスター・スライドの作成に入る．ポスターの原案出したのち添削を班員に任せ
Group Report of 2012 SISP
- 48 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
た．同時期スライドの作成．添削してもらい編集．発表準備にあたり最終目標等々
の確立ができていないことが発覚したためそれを決める話し合いで司会進行を行っ
た．中間発表では発表者を担当した．
（※文責: 高橋克弥）
黒坂愛
ハード班メンバ黒坂愛の担当課題と活動は以下のとおりである．前期ではハード班メ
ンバとして倒立振子について主に取り組んだ．
5 月 プロジェクトメンバーとの初顔合わせし，本プロジェクトの目標について意見を
出し合った．その上で必要となる班を作り，それぞれが所属する班を決めた．ま
た，プロジェクトリーダー，ハード班リーダー，位置情報班リーダーを仮決めした．
私はハード班に入った．最優先事項として，Selfi の組み立て，各パーツの選別作業
と寸法を調べ，記入，部品の撮影を行った．ユニットごとに，組み立て作業を開始
した．私は撮影係として各班の活動の撮影を行った．また，異業者交流会を行い，
今後 Selfi を使いどのような事を行っていくのかをプレゼンテーションし，交流会
の方々と意見の交換を行った．ある程度，Selfi が組みあがったところで，位置情報
班とハード班にわかれ，各班でグループワークを行った．
6 月 引き続き Selfi の組み立てを行った．Selfi の組み立てが終わったところでグルー
プ全体で Selfi の試乗を行った．1 回目の試乗でモータ部分及びチェーンが破損し
たため復旧作業を行った．ある程度作業手順がわかってきたところでハード班の中
で更に組立班と組込班に分かれ，私は組込班に入った．組込班では，HEW を使い
倒立振子のアルゴリズムの勉強を行った．再び，Selfi が組みあがったところでグ
ループ全体で試乗を行い，問題なく動いたので Selfi を完成とした．完成した Selfi
に乗ってみた後に，乗ってみての問題点や施設内で使う上での問題点，解決案を話
し合った．
7 月 組み込み班では mbed の勉強を行った．それと同時にハード班とシステム班を合
流させ，中間発表に向けてポスター・スライドなどの共同作成を開始した．私は
ハード班のポスターの作成及び，ロゴ，T シャツの作成を行った．中間発表では，
Selfi のデモンストレーションを行った．中間発表後は，グループ報告書の準備，個
人報告書をまとめた．
（※文責: 黒坂愛）
4.3
中間発表の評価
中間発表では発表スペースに来場し，発表を聞いて頂いた人を対象にアンケート調査を行った．
アンケート項目としては，まず評価者について，学生・教員・職員・一般の中からまるで囲んで
選んでもらい，学生の場合は学年と学生番号と氏名，その他の場合は所属と氏名を記入していただ
いた．発表技術については，プロジェクトの内容を伝えるために，効果的な発表が行われているか
を 1（非常に悪い）から 10（非常に優秀）の 10 段階で評価してもらい，評価の理由やアドバイス
などを，項目に分けて記載して頂いた．発表内容については，プロジェクトの目標設定と計画は十
分なものであるかを 1（非常に悪い）から 10（非常に優秀）の 10 段階で評価してもらい，評価の
理由やアドバイスなどを，項目に分けて記載して頂いた．
アンケートの集計結果として，学生 53 名，教員 6 名，職員 0 名，一般 3 名の合計 62 名の来場者
Group Report of 2012 SISP
- 49 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
にアンケートを回答してもらうことができた．アンケートの集計結果では，発表技術についての評
価の平均は 7.66 点，発表内容についての評価の平均は 7.31 点であった．
発表技術に対するコメントには，大まかに 3 つの項目について書かれていた．声の大きさについ
て，スライドについて，発表形式についての 3 つである．まず声の大きさについて，「声がもう少
し大きいともっといいと思いました」「声が周りに負けている」などといったコメントが多く書か
れていた．中間発表は本大学の 3 階ホールで行われた．多くのプロジェクトが同じ空間で発表を
行ったため，普段以上に声の通りが悪くなり結果として声が聞こえなかったという意見が多く書か
かれていた．次にスライドについて，「スライドに図やアニメーションを用いていて，分かりやす
かった．
」
「話がスムーズで聞きやすかった．」となどといった内容のコメントが多く書かれていた．
今回はスライドが分かりやすくなるように図やアニメーションを多く取り入れた．結果として流れ
のよいスライドが完成し，高評価な意見を多くいただくことができた．しかし「スライド一枚の文
字量が時々多い」，「必ず伝えたい部分を強調したほうがもっとよいスライドになると思う．」「解決
技術の独自性にもう一工夫ほしい」といった，アドバイスも書かれていたため，スライドが完璧で
あったというわけではなかった．最後に発表形式について「スライドだけでなく Selfi の実機を見
せたりと物理的に聴衆をあきさせない工夫をしていてよかった」「実演があって単純に面白かった」
といった高評価をいただくことができた．中間発表では，前期に実際にできた成果をデモンスト
レーションという形で発表した．その結果このような高評価をもらうことができた．しかし「もっ
と Selfi を見せて発表してもよいと思う．」という発表形式に対するアドバイスも書かれていた．
発表内容に対するコメントには，大まかに 3 つの項目について書かれていた．問題点とその解決
法について，今後の展望について，またプロジェクトの目標についての 3 つである．はじめに問題
点とその解決法について「今後の展望、現状の問題点に対する計画等しっかりしているように感じ
た」「問題点や目標がはっきりしている」といったように現状の問題点を洗い出し、またその解決
策についての案がしっかり出されていることに対して高評価な意見が多く書かれていた．次に今後
の展望について「問題点が解決し，それが実際に運用された時のビジョンも提示してほしかった」
「今後の計画に具体性があればいいと思う」といった今ある問題点を解決したその後，実際に運用
するときどのようにするのかの具体性がないという意見も多く書かれていた．最後にプロジェクト
の目標について「開発プロセスがわからない．」「機械に乗る必要性がわからない．」などという意
見も多く書かれており，プロジェクトの目的とそのプランをしっかりと伝えることができていな
かったことが分かった．
中間発表の評価を受け，プロジェクト全体で反省会を行った．その結果，発表技術に対するアド
バイス，発表内容に対するアドバイスの両方をしっかりと生かし，かつ中間発表で高評価だったも
のは継続して行っていこうと考えた．今後はハード班では Selfi の安全性の向上，位置情報班では
シームレスなナビゲーションアプリを構築しこれらを連携させることにより本プロジェクトの目的
である『知能機械技術による施設内案内』を実現するため ALEFUN という一つのシステム構築を
目指していく．
（※文責: 黒坂愛）
Group Report of 2012 SISP
- 50 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
第5章
5.1
後期の課題解決のプロセスの詳細
屋外ナビゲーション
Android アプリケーションの屋内ナビゲーションの製作を行うにあたり，2 通りの手法を考え
た．1 つは，Android ネイティブアプリケーションへの Maps API サイトの読み込みを行う方法．
もう 1 つは， Map View を使い Google Maps の機能を使う方法である．前者は Google Maps
API や YAHOO! JavaScript マップ API のように Google Maps や YAHOO! ロコと同様のサー
ビスを扱うことができる特徴がある．また，後者は Google Maps の表示機能を提供してくれる
が，他のナビゲーションサービスとの関連を持てないことが挙げられる．今回は， Google Maps
の機能が使え，なおかつオプションの細かな設定のできる前者の方法を選んだ．
Android アプリケーション製作の基礎と屋外ナビゲーションの基礎を学ぶために先ず，モバイ
ル端末の位置情報アプリケーションについての書籍から， GeoLocation API を用いたアプリケー
ションを実装した．GeoLocation API はユーザーの位置情報を取り扱う API であり，各種端末で
無線 LAN・WiFi・携帯電話基地局・GPS・IP アドレスなどから位置情報を取得できる．緯度経
度といった位置情報の取得， Map View を用いた地図の表示，自己の位置情報をピンとして地図
上に載せるといった経緯を踏み順に基礎を学んだ．
グループ作業に分けられた後，どういった手法で屋外ナビゲーションを行うかを議論した．地
図描写方法，地図上への図形の描画，ルート情報の構築方法を考えた結果，前述した通り Google
Maps API を用いたアプリケーションを作成することにした．
屋外ナビゲーションを制作していく過程で， Google Earth API に移行するといった話もでて
いた．その理由は， Google Earth ではこだて未来大学の 3D モデルが対応しているからである．
Google Earth API には kml 拡張子の自分で経路を増やせるので，屋内のナビゲーションと屋外
の敷地内の探索に向いているのではないかということである．開発にかけれる期間が短いことやそ
れまで開発した内容が生かされないので Google Earth が使われることはなかった．
（※文責: 八島奎之介）
Google.Maps.API
開発環境
Android アプリケーションで Google Maps API のようなサービスを利用するとき，
Web ページを読み込むといったことをする．そのために， Web View を使用し，アプ
リケーションにブラウザを埋め込む形にする．Android で Web ページを利用する為に
以下の手順を踏んだ．
1. xml を編集し，レイアウトを整える
2. 端末でインターネットや現在地サービスを仕様するための許可設定を管理する
Android マニフェストファイル
3. WebViewactivity. を作成および管理するための Java クラス
4. アプリケーションで読み込む地図（Google Maps）
以上からも分かるように， Android アプリケーションは Java で制作されるため，
Group Report of 2012 SISP
- 51 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
Google から提供されている Maps JavaScript API という Google Maps をウェブペー
ジに埋め込むことのできる API を使用し， Android 端末から Web ページを閲覧でき
るようにした．
位置情報の取得
LocationManager を用いた方法については，初期段階で学ぶ機会があった．Web
での位置情報取得方法も似通っていた． Yahoo! JavaScript マップ API やマピオン
API を使用することもできたが， Google Maps API を今回採用した理由は，普遍的
で慣れ親しんでいる人が多いことや，操作性の利便性，また開発書籍が他のものに比べ
多く出ているからである． 位置情報の取得方法は Google Maps API のサービスを用いた．Google Maps で位置
情報やルート情報，建物の情報を提示するために Web サービスに問い合わせクライア
ントアプリケーションからジオコーディング，ルート，高度，場所の情報を得られた．
地図の表示
地図は勿論 Google Maps を使用した．Google Maps を Android に表示するため
にいくつか設定しなければいけないことがある．先ず，地図のセンターを決める緯度・
経度，センターから地図の縮尺度を決める値，そして地図の種類である．緯度は北緯
はプラス，南緯はマイナスで表され，それぞれ +90，-90 が最大点となる．また経度は
東経がプラス，西経がマイナスで表される．それらを 緯度経度として取り扱うために
Google 独自の関数を使い，指定している．地図の縮尺度は 0∼17 の 18 段階で調整で
き，0 はズームアウトし地球が見られる状態まで解像度が下がる．そこから縮尺度が上
がるにつれズームインする．地図の種類であるが，現在 ROADMAP ， SATELLITE
， HYBRID ， TERRAIN の 4 種類がサポートされている．ROADMAP は Google
Maps の通常のデフォルトである 2D タイルを表示する．SATELLITE は写真タイル
を表示し， HYBRID は，写真タイルと主要な機能（道路，地名）のタイル レイヤを組
み合わせて表示する． TERRAIN は，物理的な起伏を示すタイルで，高度や水系（山，
河川など）を表示する． 今回は基礎を作るということもあり，通常の Google Maps で
ある ROADMAP で行うことにした． 地図の基本的な表示を行った後，地図のセンターの緯度経度に Android 端末の位置情
報を代入し，現在地をセンターに地図の表示をすることができた．通常状態では拡大
縮小，スクロール，ストリートビューの機能がデフォルトで動作していた．これらは，
Google Maps のオプションで設定することで動作を消すことができる．旧バージョン
では，それらを機能しなくしたものをトップ画面として扱っていた．
地図ピン（マーカー）の表示
出発地，目的地，現在地のような重要な点に目印をつける意味合いで地図ピンについ
て取り掛かった．地図ピンの表示は容易なものである．
1. position-マーカーの位置を決める．Google.maps.LatLng オブジェクトで指定する
2. map-マーカーを表示させる Map オブジェクトの指定をする
3. title-マーカーのタイトルを決める
現在，地図ピンは最初に現在地を示すために用いられている．ルートが表示された時
点で，地図ピンを消去する処理を行い，見やすくしている．後述するが，ルートの更新
処理が改善された暁には地図ピンを応用し，出発地，目的地，現在地をユーザーに示し，
ルート案内の向上が必要である．
Group Report of 2012 SISP
- 52 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
（※文責: 八島奎之介）
Direction API
ルート情報取得
Google から Google Directions API という 2 地点間のルート取得をする API
が公開されており，今回はこれを用いる方法を採用した．緯度経度，住所，建物名
をスタート地点とゴール地点に設定することで，その二点間のルート取得すること
ができた．
ルート表示
情報の視覚化のため，上述した方法で得たルート情報を地図に反映することを
目指した．ルート情報の視覚化は 2 通りの手段があった．先ず 1 つめは， Google
Directions API の機能の延長上で行うこと，もう 1 つは， Polyline を使用し，
Google の機能とは独立させるといった方法である．前者は，延長上で行うため，
実装が容易である．しかし， Google Directions API のオプション機能にルート
の色の変更を行うものが無かったりと，活用の幅が狭くなる．後述するが，事実移
動経路のログを表すことが難点であった．後者は， Google Directions API とは
ほぼ関わりが無くなってしまうので，ルートの消去など基本的な機能での実装面で
面倒が起こる．しかし，線の色を変更させやすかったりと，目に見えて違いが見え
やすくなる．本プロジェクトでは，両方の面から開発を行ったが， Polyline での実
装で特出した点が無かったため， Google Directions API の延長で表示を行った．
機能
Google Directions API でいくつかルートの指定をすることができる．リクエ
ストパラメーターといい以下のようなものになっている．
1. origin-計算するルートの出発地にする住所またはテキストで表された緯度経度
2. destination-計算するルートの目的地にする住所またはテキストで表された緯
度経度
3. mode-ルート計算に使用する交通手段を指定する
4. waypoints-ウェイポイントの配列を指定します．ウェイポイントを指定するこ
とで，それらの地点を通るルートに変更できます．ウェイポイントは，緯度/
経度の座標で指定するか，ジオコーディングできる住所で指定する
5. alternatives-true に設定すると，代替ルートがある場合は複数のルートが返さ
れる．なお，代替ルートを返すように指定すると，サーバーのレスポンス タ
イムが長くなる場合がある．
6. avoid-特定の対象物を使用せずにルートを計算したい場合に指定する．現時点
では，以下の 2 つの引数を指定できる
7. units-結果の表示に使用する単位系を指定する
8. region-ccTLD（「トップレベル ドメイン」）の 2 文字の値として指定した地域
コード
9. language-結果を返す言語．サポート対象の言語は頻繁にアップデートされ
るため，このリストがすべてのサポート言語を網羅しているとは限らない．
Language を省略すると，ブラウザのデフォルト言語が特定できる場合は常に
その言語が使用される
Group Report of 2012 SISP
- 53 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
10. sensor-ルートリクエストが，場所センサーでデバイスから取得したものかど
うかを示します．この値には， true か false のいずれかを設定する
以上のようなオプション機能が Google Directions API には追加されている．ルー
トリクエストに必須なものは， origin ， destination ， sensor である． 施設内の
屋外ナビゲーションシステムの構築ということで今回は，mode や avoid を使用す
るようなことはなく，基本的な機能の実装に終わった．
ルートの更新処理
更新処理は 2 つの種類がある．1 つは，ルート検索した後，もう一度ルート検索
したときの処理である．過去に，ルートの表示とそのルート削除のプログラムを実
装した．ルートが複数表示された時，最後に表示されたルートの削除しか出来な
かったため，フラグによる更新処理でルートを 1 本しか表示されないようにした．
その成果を利用し，ルート検索が続けて行われた際には，2 回目以降のときはルー
ト削除を行なってからルートの検索を行うようにし，ルート更新処理を実装した．
もう 1 つは，ルートが表示された時にルートをリアルタイムで更新する処理で
ある．移動した経路のログの表示，現在地のリアルタイム更新，道から外れた際の
再経路探索などを作ることができる． GPS による位置取得を繰り返す処理を行う
と，ルートが何重にもなることが分かった．なので，ルートを消去し新たなルート
を制作するといった方法をとったのだが，ルート更新処理はするが，ルートが点滅
する．それを解消するために，新たなルートを作成し，古いルートを消すというア
ルゴリズムを組まなければならない．このような改善を試みたが，作成出来ず，現
在点滅するような状況になっている．これは今後の課題である．
通過ルートのログ
出発点と目的地の間を移動している間にも，現在地の場所を更新し，自分がどの
ルートを通るか分かれば，ユーザーの補助に繋がると考えた．Google Directions
API によるルート表示を実装し，それでルートのログを表示しようとしたが，色
の変化など見た目に違いが表れないので，通過予定のルートと通過したルートの判
別がしにくい問題がある．そこで， Polyline によるルート表示を考えた． これは
地図上に図形を書くといった方式である．地図をキャンパスに見立てて，緯度経度
を 2 点指定し，その間に線を書くといったものである．ルート情報を Polyline で
表す場合は少し特殊で，ルート取得した結果を Polyline でそのまま表すことがで
きる．また， Polyline はキャンパス等で扱うように，色の指定や線の太さを設定
できるので，通過予定のルートと通過したルートを分けるといったことが視覚的に
わかりやすい．Polyline によるルートの描画は上手くいったが，次の問題点が出て
きた．それはルート描画はできるが，それを消去する処理がうまく行かず，更新処
理ができないということである．ユーザーに配慮した内容にする為に，ログの描画
は課題として挙げられる．
（※文責: 八島奎之介）
Elevation API
高度情報取得
Google Elevation API は 1 地点のリクエストに対しては非常に正確な値を返す
ように設計されている．これを屋内ナビゲーションシステムに転用し，屋内ナビ
Group Report of 2012 SISP
- 54 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 5.1 Direction API 使用図 1
図 5.2 Direction API 使用図 2
ゲーションの階層変化に応用できないかと用いられたものである． リクエストして返ってきたパラメータの値は，対象が分散した場所か，または順
序付けられたパスかどうかで異なる．分散した場所の場合は，リクエストで渡した
それぞれの値が返る．パスの場合は，指定されたパスに沿ってサンプリングされた
結果が返される．高度情報を取得するリクエストは以下の通りだ．先ず，位置リク
エストを示す．
• locations-高度データを返す地球上の場所を定義する．このパラメータは，1
つの場所を表すカンマ区切りの緯度・経度（例「40.5324,-72.998672」），複数
の緯度・経度ペアの配列，またはエンコード済みポリラインで指定できる．
次に，サンプリングされたパスのリクエストを示す．
• path-高度データを返す地球上のパスを定義する．このパラメータには，パス
を定義する 2 つ以上の順序付けた緯度・経度を指定する．
• samples-高度データを返すパスに s ってサンプリングする地点の数を示す．
sample パラメータに従い，指定した path が等間隔に分割されて各地点が順序
付けられる．
Google Elevation API を用いて，現在地の高度を取得し， Android アプリケー
ションに返された高度を表示することができた．それを利用し，学内で正確な値を
取得できるかの実験を行った．単純に学内を散策するものであったが，端末の高度
を取得するものでなく，その指定した緯度経度の地点の高度を取得するため階層の
高度の値を取得できなかった．よって，屋内の階層変化は他の方法を用いることに
なった．
（※文責: 八島奎之介）
ルート検索
音声
リスト表示の他の方法を実装する上で考慮するべき点が 2 つあることが議論してわかっ
た．まずはリスト表示は利用者が表示されている中からの選択するので直感性の欠ける
操作性になってしまうこと．次にリスト表示では極力見やすいような配慮をしたが利用
者によってはテキストでは見にくい可能性があるので，視覚に頼らない入力が望ましい
と思われる． この問題点を解決する方法を Android で可能な実装方法から考え， Google から提供
されている音声認識の API である Recognizer Intent API で実装することにした．具
体的にはルート検索の方式を選ぶ画面を実装し，そこに音声入力ボタンを配置した．そ
Group Report of 2012 SISP
- 55 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
のボタンを押すと音声入力に対応したダイアログが表示されるようにした．利用者は音
声ボタンを押し，目的地を入力すると，出力された結果から選ぶ簡単な操作になってい
る．内部では入力された音声データを RecognizerIntent で Google へ送り，処理結果
の中で音声データと近似した文字列を一致する可能性の高い順序を出力するものになっ
ている．音声認識 API を用いることで上記の問題点を解決できた．その他に，慣れた
利用者であれば手間をかけないようになることで利便性の向上ができ，また機器に喋り
かけて受け答えが行われる知能をも持っているかのように見せることで，本プロジェク
トの目的にも沿うことに実装できた．以下の画像が実装した音声入力である．（図??）
図 5.3 音声入力ダイアログ
図 5.4
出力結果ダイアログ
（※文責: 畠山大樹）
リスト
屋内と屋外のナビゲーションに対応させたデータベースの利用方法の実装を全体の UI
を参考にしてどのようにするか検討した．利用者の立場になり考えると乗る前の安全が
確保された状態であるので，ある程度の操作の手間を要しても問題にならない．次に，
どのように表記すればナビゲーションのスタート地点とゴール地点を簡単に理解させ，
簡単に入力できるかを考えなければならない．また利用者視点とは別に Android の処
理にあまり負荷をかけないようにしなければならない． これらの問題点から考えた結果，スタート地点選択時は画面上部に「スタート地点選
択」をテキストで表記し，データベースから呼び出したデータから名前だけをリストに
羅列させ選ばれたデータのみを次の画面に送る．ゴール地点でスタート地点選択時の
データを受け取った後に，スタート地点選択時と同様な画面表示と処理を行う．そして
ナビゲーションを処理する部分へスタート地点とゴール地点のデータを送るというフ
ローにすることにした．
図 5.5 リスト表示
Group Report of 2012 SISP
- 56 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
（※文責: 畠山大樹）
テキスト
本項目では，ナビゲーションアプリの屋外ナビゲーションのモードのテキスト検索に
よるルートの表示について概要で掲げた目標を達成するためのプロセスの説明をする．
テキスト検索機能の実現に向け，まずテキスト入力フォーム，入力されたテキストで検
索を開始するボタン，テキスト入力フォームに入力されているテキストの削除のボタ
ン，前回の画面遷移へ戻るボタンを XML を用いて View の表示を行った．次にそれぞ
れの View のイベント処理のためのクラスを作成し，その中に処理を書くという作業を
行った．テキスト入力フォームの処理としては画面を遷移させる際に，テキストの情報
String 型にし，そのままの値を画面の遷移先へと受け渡す準備をさせる処理をさせた．
次に，入力されたテキストで検索を開始するボタンのイベント処理としては，そのボタ
ンが押されたと同時に遷移先のクラスに String 型となっているテキストの値を受け渡
すという処理をさせた，テキスト入力フォームに入力されているテキストの削除のボタ
ンのイベント処理としては，ボタンが押されたと同時に入力フォームに書き込んだテキ
スト情報が削除される処理である．以上のような機能を持ったプログラムを完成させた
後，実際のプロトタイプに組み込む作業を行った． 実際のプロトタイプでは入力フォームのイベント処理とテキスト削除ボタンの処理はそ
のままの形でソースコードを書き込みテキスト検索ボタンはボタンに表示される名前の
変更と画面の遷移先を変更させた．概要の部分で説明していた”入力フォームに入力さ
れたテキストを Enter ボタンが押されたと同時にそのテキストが Javascript に送られ
る”という部分については音声認識以外のルートの検索方法で使用される処理であり，
これは前期の段階でプログラムを完成させたあったためテキストの値を受け渡しの処理
をする作業だけでルート検索のテキスト検索機能の実装が実現した．
（※文責: 犬塚悠人）
UI
本項目では，プロジェクトの活動として製作を行なってきたナビゲーションアプリの屋外
ナビゲーションのモードについて，全体的なユーザインターフェースについて概要で挙げた
課題に対しての解決策とそのために行った活動について説明をする． まず，アプリケーション起動時のスタート画面の改善から行った．概要で説明した通り，ア
プリケーション起動時のスタート画面に GoogleMap が表示されている仕様となっている
ため，屋外ナビゲーションの画面とアプリ起動時のスタート画面の違いが屋外ナビゲーショ
ンの画面の上に表示されている音声検索ボタンとテキスト入力フォームの有無の違いのみで
あるという問題点について取り組んだ．この問題点の改善案として，アプリケーション起動
時のスタート画面を Android のデフォルトのボタンのみを配置する画面にしようと考えた．
このようにすることによって，屋外ナビゲーション，アプリケーション起動時のスタート画
面との大きな差別化になるためであり，そのようにユーザインターフェースの開発を行っ
た． 次に屋外ナビゲーションのユーザインターフェースの製作に取り組んだ．まず，前期終了時
点でのプロトタイプでは 1 つの画面にテキスト入力フォーム，テキストクリアボタン，音声
検索ボタンが表示されていて，メニューバーにはリスト検索機能，戻る機能を実装してある
という状態であった．しかしながら，そのようなユーザインターフェースでは，わかりにく
Group Report of 2012 SISP
- 57 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
いだけでなく一貫性もない．そのため，テキスト入力フォーム，テキストクリアボタン，音
声検索ボタンの View を削除した．さらに，メニューバーに配置したリスト検索も削除し
た．その後，”検索”という項目をメニューバーに表示させ，この項目が選ばれた時画面上
にダイアログを表示させるようにプログラミングを行った．そのダイアログにはテキスト，
リスト，音声と書かれたボタンを配置し各ボタンが押されたときは各処理を行うというユー
ザインターフェースに変更した．テキストというボタンが押されたときは，画面が遷移しテ
キスト入力フォーム， Reseach ボタン，戻るボタンが配置されている画面に遷移するよう
になっている．この画面上のテキスト入力フォームに行き先を入力し Reseach ボタンを押
すと屋外ナビゲーションの画面上に現在地から目的地までのルートが表示される仕組みであ
る．リストというボタンが押されたときは，画面が遷移し私達で用意した行き先のリストが
表示される．この行き先リストはもともと緯度経度などの情報が保管されているデータベー
スがあり，このデータベース内より GoogleMap にルートを反映させる．音声というボタン
が押されたときは，ユーザインターフェース改変前の音声検索ボタンが押された時のイベン
ト処理と同じである．屋外ナビゲーションのメニューバーにもともと配置されていた戻るボ
タンはそのまま残した．また，私達が製作したナビアプリケーションでは Selfi と連携した
ことを考えてルートが表示された時に接近報知音が鳴るという仕様となっていた．その接近
報知音を各モードで止めるためのボタン処理が必要であり，屋外ナビゲーションのモードで
止めるための Stop ボタンをメニューバーの中に配置した．
（※文責: 三上力也）
XML
本項目では，プロジェクトにて，製作を行ったナビアプリケーションのユーザイン
ターフェースの特に XML について取り組んできたプロセスについて説明を行う． プロジェクト学習当初は，概要でも説明した通りプログラミングによるアプリケーショ
ンにおいて統一した意識がなかったためボタンや入力フォームをそれぞれのメンバーが
開発する際に， ユーザインターフェースの開発を行う際に XML を用いて開発する人
もいれば，直接 Java のクラスの中に表示のためのソースコードを書き込む人がいる状
態であった．このようにバラバラにプログラミングを行なっていた．このままではボタ
ンやテキスト入力フォームなどの View の大きさ，色，フォントの大きさ，配置などが
手間になってしまうというデメリットだけでなく各メンバーの開発したソースコードを
組み込む際にもさらに手間になってしまうというような状態になってしまう恐れがあっ
たため，全員に XML を用いた開発をするように再度意識を統一する必要があった．具
体的には，ソースコードでユーザインターフェースの開発を行なっていたメンバーに
XML をを用いて開発を進めるようにし，また，開発を行なうメンバーに XML による
ユーザインターフェース開発の一定以上の知識がつくようにプロトタイプに応用ができ
るような課題を課した．この取り組みによって，レイアウトの調整などの作業が担当者
以外も行うことが可能となり，作業が行き詰まった際に，サポートのメンバーを派遣す
ることも可能となり，円滑に作業を行うことができた． このような形でユーザインターフェースの開発を進めていった結果， View の配置や
フォントの大きさなどの微調整は XML で行い，その View のイベント処理は Java の
クラスの中に書くという方式でユーザインターフェースの開発を行っていった．
（※文責: 犬塚悠人）
Group Report of 2012 SISP
- 58 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
Java と Javascript 連携
Android ネイティブアプリケーションへの Maps API サイトの読み込みを行う方
法を本プロジェクトでは選んだ．Android アプリケーションは Java で開発が行われ，
JavaScript で作成された Google Maps と連携を取る． 旧バージョンの屋外ナビゲーションの UI では，屋外の地図の上方にテキスト検索をで
きるスペースを空けていた．しかし，Java で使うことができる音声入力を用いた検索
と既に候補が幾つか挙がっているリスト検索を実装する為に，Java から JavaScript に
情報を渡し，ルート検索を行えるようにする．テキストビューを Java で構築し，テキ
ストビュー内の文字列からルート検索を行えるようになった．音声検索やリスト検索は
文字列をテキストビューに渡し，屋外ルートの探索を行えるようにした．リスト検索
は，一端他のビューに移るため， JavaScript に値を渡した時に Google Maps がまだ
読み込まれていない状態だったために，ルート検索を行えないといった不具合もでた
が，読み込みの時間をずらすことで解決した．Google Maps でルートが 2 重にならな
いために，フラグ処理を行うこともした．
（※文責: 八島奎之介）
5.2
屋内ナビゲーション
前述の最短経路探索アルゴリズムであるダイクストラ法を用いた方法と，検索された条件に合っ
たルートを画像として表示する方法の２つを実装した．以下がそのプロセスである．
位置情報取得
RSSI
精度向上として公式と使用するノードの修正を行った．計算に使用する AP は電波強
度を元に調査を行い配置場所を学内のある一点を原点として考え校舎全体を座標系に設
置している．この方式では端末が受信した電波強度が最も高い AP3 つの座標と電波強
度から，端末の位置を算出する．端末が受信したアクセスポイントの電波を電波強度の
強い順でソートし，上位 3 つのアクセスポイントの BSSID を利用してデータベースか
ら座標を引き出している．次に電波強度を用いて，それぞれのアクセスポイントと端末
との距離の求め方を式を使って記述する．求める現在地の座標を X ，Y ，Z とし，アク
セスポイントのそれぞれの座標を x1 ，y1 ，z1 ，x2 ，y2 ，z2 ，x3 ，y3 ，z3 とする．また，
それぞれのアクセスポイントからの電波強度を D1 ，D2 ，D3 ，距離を m1 ，m2 ，m3 ，
電波の減衰量を R としている．
m1 = 10
m2 = 10
m3 = 10
D1 −20 log10 2400+(28−R)
20
D2 −20 log10 2400+(28−R)
20
D3 −20 log10 2400+(28−R)
20
(5.1)
(5.2)
(5.3)
この方式は屋内伝播モデルにあわせて電波強度を AP からの距離に換算する公式で
ある. この計算に使用する電波の減衰量というものが場所によって異なる．未来大では
平均減衰量は 18 であった．これまではこの平均量を用いていたが今回精度向上のため
アクセス場所に応じた値になるよう事前に計測し求めた AP データのデータベースに
Group Report of 2012 SISP
- 59 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
格納することで変化するようにした．そして 3 点のアクセスポイントの位置と，各 AP
からの距離がわかれば，球の交点を求める方程式をつかった連立 3 元 2 次方程式を解
くことで位置を算出することができる．
(X − x1 )2 + (Y − y1 )2 + (Z − z1 )2 = m21
(5.4)
(X − x2 ) + (Y − y2 ) + (Z − z2 ) =
(5.5)
2
2
2
(X − x3 ) + (Y − y3 ) + (Z − z3 ) =
2
2
2
m22
m23
(5.6)
また，解が全て虚数解となる場合がある. その場合はアクセスポイントのとても近く
にいる場合が多かったため，電波強度の一番強いアクセスポイントを現在地とするこ
ととした．しかしそれでも解が出ない場合がある．そこで，新しい補助の計算方法とし
て，アクセスポイント 3 点間の重心を求めることにしている．アクセスポイントの座標
をベクトルとして，電波強度を重みとして用いて，3 点の重心を求めている.
D1 x1 + D2 x2 + D3 x3
D1 + D2 + D3
D1 y1 + D2 y2 + D3 y3
Y =
D1 + D2 + D3
D1 z1 + D2 z2 + D3 z3
Z=
D1 + D2 + D3
(5.7)
X=
(5.8)
(5.9)
この式によって現在地の座標 X ，Y ，Z が求められる．三点計測とこの方法を組み
合わせることで，アクセスポイント 3 点から電波を受信できれば，必ず解となる座標が
求めることができる．値を算出するプログラムを構築することはできた．しかし肝心の
計算に用いるアクセスポイントは学校側のインフラネットを使っている．そのため完璧
に所在を把握しているわけではなく大体の位置で座標を設置している物も多い．これに
よってどうしても誤差が大きくなってしまう．他にも設置配置換えなどが起こることで
全く機能しなくなってしまうというリスクがあるだけでなくシャワー室など電波が届か
ないところが多々あり計測できないといった問題がある．これらの問題を補助するため
にも本プロジェクトでは無線 LAN の送信機を導入した．同一の送信機を自分たちが設
置することで計測地点が正確なだけでなく電波の特性が近くなるため誤差はあるものの
より正しい位置を求めることを可能にしている．
（※文責: 小野修都）
IMES
本プロジェクトでは Android を搭載したスマートフォンまたはタブレット端末でナ
ビゲーションを行うことを想定している．そのためスマートフォンで IMES の電波を
受信し地図上に反映可能か前期に調査した．送信機は株式会社日立産機システムの屋内
GPS 送信機評価セットを使用した．調査の結果 IMES 送信機から送られてくる電波を
スマートフォン単体で受信することはできなかった．これはスマートフォンに搭載され
ている GPS チップが IMES が使用している準天頂衛星システム（初号機 みちびき）な
どの電波を認識することができないからであった．しかし後期には IMES が新規格へ
と移行したため今度は測位衛星技術株式会社 (QNSS) から借りることとなった．その
ため再び調査を行うことにした．調査の結果，新機能として以下の変更が行われたこと
が判明した．
• IMES 受信機の方で位置情報を Bluetooth で Android に送ることができる．
• 送信機の設定が赤外線となっており設定できる項目が多くなっただけでなく設定方
法も変化した．
Group Report of 2012 SISP
- 60 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
IMES 送信機の設定方法
前期に借りた端末では IMES 送信機の接続は PC とシリアルケーブルで行う．しか
し後期に借りた端末では COM 赤外線エミッタを用いて IMES 送信機の設定を変更す
る．IMES 送信機の設定は付属していたソフトを利用することによって設定を変更し
た．IMES 送信機に書き込む情報は IMES 信号出力状態，PRN 番号，航法メッセージ
タイプ，航法メッセージ内容，送信出力レベル，中心周波数である．航法メッセージ内
容は緯度，経度，フロア，高度，ID 形式である．実験を行うために設定は IMES 信号
出力状態は ON，PRN 番号は 173，送信出力レベルは 10，中心周波数は 1575.42MHz，
航法メッセージ内容は北緯 30°，東経 40°，フロアは 3，形式は JAXA 位置情報形式
2 に固定し，必要に応じで変更をした．・IMES 送信機から送信される電波を受信する
ことのできる距離 IMES を使用するにあたって，学内に IMES 送信機を配置する必要
がある．そのために IMES 送信機が送信する電波の到達距離を調査することによって，
効果的に IMES 送信機を配置することができる．調査した結果，IMES 送信機の送信
出力レベルを最小の 10 に設定した際の到達距離はアンテナの向きによらず約 6.5 ｍで
あった．また，IMES 送信機の送信信号レベルを最大の 5 に設定した際の到達距離は
アンテナの向きによらず約 12m であった．IMES 送信機から送信される電波の最小到
達距離は約 6.5m であったが，さらに電波の届く範囲を狭めたい場合は IMES 送信機
を電波を遮るもので覆う事によって解決する．本来そのフロアの天井などに設置するの
が好ましいが未来大の特性上，設置が困難なため試算した値を掲載する．（図??） マ
図 5.6 IMES 信号における信号規定に基づく送受信距離の目安
ニュアルによると専用の受信機が Bluetooth で Android と接続できるため，IMES の
情報を Android 側で受信可能だということが判明した. そこで評価実験を行ったのだが
その際一つ問題が発覚した．利用するには端末側ではなくナビゲーションアプリ側の方
で Bluetooth に対応している必要があった. またそのまま接続すれば位置取得できると
いうわけではなくよりアプリなどとして使うには以下の様なコマンドを用いることで
Android で API を開発しなくてはならないとのことがわかった．
Group Report of 2012 SISP
- 61 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
@SOM400 1000 3001<LF>//
#SIF 1<LF>// IMES 信号サーチ周波数オフセット割り当て
#SIC 4<LF>//IMES 信号受信チャンネル数割り当て
#SIS 2<LF>//IMES サーチモードの設定
#NM GPGGA<LF> IMIMP//GPS や IMES の受信結果を情報を出力
@SR<LF>//IMES 受信機をホットスタート
もう一つの方法としてそのまま IMES 電波を受信するという方法がある．丁度，並行
して開発していた UI と ADK に合わせ NEXUS7 と呼ばれる Google が提供している
タブレットを導入していたのだが準天頂衛星システムに対応した GPS チップを搭載し
ていたためがそちらでの場合も確認することができた．こちらの方式ではアプリ，ハー
ド特に設定をすることなく受信を Google マップで確認することができた．しかし中に
は対応していないアプリもありこれはアプリ側に実装されている位置取得方法の違いに
よるものだと考えられた．
（※文責: 小野修都）
ルート表示
アルゴリズム
開発準備
アプリは Android 上で作成するため，まずは Java を用いた基本的なアルゴリ
ズムについて学んだ．そして，アルゴリズムについて理解した後，ダイクストラ法
の構築を開始した．
ダイクストラ法
ダイクストラ法とは，グラフ問題における最短経路問題に最適なアルゴリズム
で，スタートからゴールの最短距離と最短ルートを求めることができる．以下は，
ダイクストラ法の例である． 以上のグラフ問題における最短経路問題で，円で描
図 5.7 ダイクストラ法 1
かれているものがノード，線分で描かれているものが経路である．スタートノード
を A，ゴールノードを F とする．各辺は，その辺を通るために必要なコスト（距
離・時間）である．また，ダイクストラ法では，有向グラフ・無向グラフは区別す
る必要はない．ダイクストラ法は，動的計画法の一種であり，未到達のノードと最
小値を探索し，それが見つかれば値を更新していく方法で最短経路を求めることが
できる． スタートノード A からゴールノード F まで最短経路を探索するとき，
Group Report of 2012 SISP
- 62 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 5.8
ダイクストラ法 2
まずは値の初期化を行う．初期化とは，スタートノードを 0 にし，それ以外のすべ
てのノードを未到達なのでいつでも値を更新できるよう∞として設定する．この場
合，ノード A からノード A はそれ自身へのコストなので 0 である．それ以外のす
べてのノードは∞とする． 次に，スタートノードから到達することが出来るノー
図 5.9
ダイクストラ法 3
ドに移る．この場合，そのノードは B，C，D の３個存在する．各ノードをそのコ
ストごとに更新する．３個のノードはそれぞれ，5，4，3 に更新される．今，到達
したノードは 3 個であるので，ノード C のコスト 3 より低いコストである経路は
見つからない，そのため，スタートノード A からノード C への最短経路はコスト
3 として確定することが出来る． 次に，ノード C から最短経路を探索する．ここ
図 5.10 ダイクストラ法 4
から到達することが出来るノードは 3 個あるが，スタートノード A までの最短経
路は 0 として確定しているので，その経路は省く．よってここでは，ノード D，E
Group Report of 2012 SISP
- 63 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
への経路を考える．
ノード D へ到達した場合，コストは 6 である．しかし，すでにノード D はすで
にスタートノード A から到達しており，コストは 4 としているので，ここでは値
の更新を行わない． 残ったノード E への経路は，まだ未到達なので最短経路は
図 5.11
ダイクストラ法 5
コスト 9 とする． 次に，ノード D から探索を行う．ノード D はノード C 同様に
図 5.12
ダイクストラ法 6
スタートノード A からの最短経路はコスト 4 として確定することが出来る．
ノード D から到達することができるノードは，ノード B，E である B までの経
路を通った場合コストは 7 となる．しかし，B はすでにスタートノード A から到
達しており，最短経路はコスト 5 としてあるため，値の更新は行わない．ノード E
図 5.13
ダイクストラ法 7
への経路は，最短経路のコストが 9 であったが，ノード D から E の経路を通った
場合コスト 6 となり，これが最短経路となるため値の更新を行う． 次に，ノード
Group Report of 2012 SISP
- 64 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 5.14 ダイクストラ法 8
B から探索を行う．ノード B はノード C，D 同様にスタートノード A からの最短
経路はコスト 5 として確定することが出来る．ノード B から到達することができ
るノードは，スタートノード A とゴールノード F の 2 個である．しかし，A への
値の更新はノード C，D の場合と同様に行わない．よってここでは，ゴールノード
F への経路のみに注目する．ゴールノード F へのまでのコストは 6 であるから，F
までの最短経路はコスト 11 とする．
最後にノード E から探索を行う．ノード E から到達することが出来るノードは
ノード C，D，F の 3 個存在するが，C，D は戻る経路となってしまうので，最短
経路となり得ないため省く．よってゴールノード F への経路を選択する．
ゴールノード F へのまでの最短経路のコストは 11 であったが，この場合は，F
までのコストは 4 であるから総コスト 10 となる．よってこれを最短経路となり，
コスト 10 として値の最終更新を行う． これですべての経路のコストが確定し，
図 5.15 ダイクストラ法 9
スタートノード A からゴールノード F までの最短経路が求められた．
以上のように，値の初期化を行い，未到達点を探して，さらに最小値が見つか
れば値の更新を行うことで最短経路を求めることができるのがダイクストラ法で
ある．
実装
まずは２つの機能別に分けて行った．一方は，最短経路を求めるダイクストラ法
を構築．他方は，求めた最短経路をアプリ上で描写する，つまりルートを視覚化す
る機能の作成．そして，その両方が出来上がったあとで一つのものとした．実装は
Java で行った．
Group Report of 2012 SISP
- 65 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ダイクストラ法を用いたアルゴリズム
目標は学内すべてのルートを出すことだったが，まずは学内３階でルート表
示を可能にすることを目的とした．そのため，３階の各部屋にノードを置き，
それをもとに探索するアルゴリズムの構築を行った．
ダイクストラ法の例で用いたグラフのコストを表にすると以下のようにな
る．この表をプログラムで表現するため，以下の様な隣接行列に書き換えた．
図 5.16 コスト表
このように隣接行列を用いて，学内の各部屋にノードを，各経路にコストを
図 5.17 隣接行列
設定した．次に，経路探索を行うアルゴリズム部を作成した．これが完成した
ことにより，学内３階の部屋でスタートとゴールを設定することで最短経路探
索が可能となった．
ルート表示
アルゴリズムは完成したが，これだけではアプリ上で操作することはできな
かった．そのため，探索した経路をアプリ上で表示することが必要であった．
ルート表示は，２つの方法が考えられた．ひとつは，まずは学内地図をビット
マップ形式にし，それをアプリ上で表示する．そして，ルート探索が行われた
と同時に，地図画像のビットマップを黒色に反転させ，あたかもルートが描写
されているようにする方法．もうひとつは，同様に学内地図を表示し，その上
に探索したルートを上書きしていくという方法である．当初は手探りで進んで
いたため，この２つの方法で実装を進めていたが，前者の方法では，プログラ
ム上の記述が膨大になった上，アプリ上での動作が不安定だったため，結果的
には動作が安定していた後者で実装した．
（※文責: 町田浩平）
パターン用いたルート表示
公立はこだて未来大学に対応した屋内用のナビゲーションアプリを作成するために以
下のプロセスを踏んだ．
Group Report of 2012 SISP
- 66 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
学内の施設の分類分け，特長抽出
目的地までのルートを計算する方法を検討するために，学内の特徴的な構造に着
目した．本学の校舎は，スタジオと呼ばれる１階から５階までの吹き抜けがある南
側の空間と，モールと呼ばれる 3 階から 5 階までの吹き抜けがある北側の空間の 2
つに大きく分けることができると考えた．北側の空間には教員室，売店，食堂，ア
トリエ，講堂などの施設がある．対して，南側の空間には講義室，事務室，図書館，
体育館などの施設がある．これらの本学を初めて訪れた人が訪れる可能性のある施
設を 3 階に限定して抽出したところ 27 の施設があった．また，隣あっているなど
互いの距離が近い施設をまとめたところ，10 の場所に絞ることができた．具体的
な分類としては以下のとおりである．
1. 正面玄関，ミュージアム付近
2. 共同研究センター，コンピューター教室 363 付近
3. エレクトロニクス工房，コンピューター教室 364 付近
4. 工房，コンピューター教室 365 付近
5. 大講義室，体育館付近
6. 教員室 322，教員室 323，教員室 324 付近
7. 教員室 325，教員室 326，教員室 327 付近
8. 教員室 328，前期院性室 329，後期院生室 330 付近
9. 教員室 331，教員室 332，教員室 333 付近
10. 教員室 334，教員室 335 付近
また，南側と北側の空間をつなぐ通路は 3，4，5 階にそれぞれ 2 本ずつある．正
面玄関側の通路を通路 1，研究棟の通路を通路 2 と名付けた．南側から北側へ，北
側から南側へ移動する際には通路１または通路 2 のどちらかを通らなければならな
いという特徴を発見した．
（※文責: 佐々木康祐）
ルート検討
学内の施設の分類と特徴を抽出した結果，3 階だけで移動を行うと仮定すると目
的地の場所は計 10 地点である．つまり，現在地からこれら 10 の地点までのルー
ト表示を行えばよいということになる．しかし，現在，学内で正確な位置情報を
取得することはできない．よって，現在地もその 10 の地点のどこかにいると制限
し，ナビゲーションを行うものとした．現在地と目的地を 10 地点に制限すること
によって，考えられるルートは 72 通りとなる．これより 72 通りのルートパターン
を検討した．まず， Selfi という乗り物に乗るという点から，可能な限り人通りが
少ない通り，または道幅の広い通りを通行することを優先したほうがいいと判断し
た．また，学内の北側から南側へ，南側から北側へ移動する際には，通路 1 か通路
2 を通らなければならないという点から，その中でも人通りが少ない通路 2 を優先
して通行するのがよいと判断した．また，利用者の現在地から目的地まで最短で行
けるという点も考慮した．以上のことを総合的に考えた 72 通りのルートパターン
を考えた．
（※文責: 佐々木康祐）
ルート画像作成
ルート画像の作成に入る前に，どのようなフォーマットでルート画像を作成すれ
Group Report of 2012 SISP
- 67 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ばよいのか検討した．前期で作成した屋内用の地図にどのように矢印を出すのかと
いうところに着目した．ルートの画像が地図の縮尺と異なると，違う場所にルート
矢印が出てしまう．そこで，前期に作った屋内用の地図と同じ位置に表示すると
いう方法で解決することにした．つぎに，利用者が見やすいデザインを目指した．
ユーザーはパソコンや，スマートフォンなどの情報機器に精通しているものとは限
らないので，誰もが見やすいデザインにしなければならない．また，屋内用の地図
と色が類似していると見にくいという問題点も懸念された．そこで，屋内用の地図
に使われていない色で，かつ病院などでも使われ人が不快に思わず，安心を感じる
緑色を矢印の色に採用した．さらに，利用者が見やすいように矢印の太さも通路よ
り大きくならないようにした．その後，実際に画像を PNG 形式の 702 × 907px
の画像にした．
図 5.18 ルートの画像
（※文責: 佐々木康祐）
前期で作成したナビアプリケーションに組み込む
Team B で作成したパターンを用いたナビアプリケーションを，前期で作成し
たアプリケーションに追加するという作業を行った．まず，私たちのナビアプリ
ケーションは Android OS 2.3.3 で作成していた．対して，前期で作成したナビア
プリケーションは後期に Android OS を 2.3.3 から 4.0.3 にアップグレードを行っ
た．このため，私たちが作成したナビアプリケーションを前期で作成したナビアプ
リケーションに追加した場合，不具合などが出てくる恐れがあった．そこで，まず
は私たちのナビアプリケーションの Android OS のバージョンを 4.0.3 にアップグ
レードを行った．しかし，その際にナビアプリケーションを作成する際に使用して
いる 統合開発環境 ( Eclipse ) の不具合が Team B 全体で発生してしまった．原因
は我々の学校で推奨しているパソコンにもとからインストールされている Eclipse
のバージョンアップの際に Android SDK の更新がうまくいかなかったからだと思
われる．その解決方法としては，一度 Eclipse および Android SDK Manager を
アンインストールし，再度インストールしなおすという方法で解決することができ
た．このような問題点を乗り越え， Team B が作成しているナビアプリケーショ
ンの Android OS を 4.0.3 にアップグレードすることができた．その後実際に，前
期で作成したアプリケーションに Team B のナビアプリケーションを組み込むと
いう作業を行った．これは画面遷移を行うことで組み込み作業を終了とした．しか
し，画面遷移の際にインスタンスを受け渡すことにより情報をやり取りするのだ
が，どうしてもインスタンスを受け渡すことができなかった．これは，受け取る先
のインスタンスと，さらにその先の画面遷移を行うためのインスタンスが重複して
Group Report of 2012 SISP
- 68 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
しまうというものであった．なので，受け取る先のインスタンスを別の形に変更す
るという方法でこの問題は解決した．これにより前期で作成したアプリケーション
に Team B で作成した屋内ナビアプリケーションを追加することができた．
（※文責: 佐々木康祐）
ルートをデータベースに格納
ルートをデータベースに格納するにあたって， SQLite を用いた．SQLite を用
いることで後に拡張するときに拡張しやすいという点と文字検索を導入する際に
簡略化できる，そしてデータが増えたときにデータを分別しやすいと判断したから
だ．まず，教室の情報を 10 個のカテゴリーごとにデータベースに格納した．そう
することで，ルートの画像を格データベースに格納したものを呼び出しやすいと
思ったからだ，次に，屋内ナビアプリケーションのトップ画面で出発地点と目的地
を選べるようにし，そこに，テキストデータとして，データベースから呼び出せる
ようにした．現在地も入力方式にしたのは，RSSI 方式の精度があまり高くないの
で，入力方式をとった．また，さらに便利にするために文字検索機能も導入した．
文字検索機能を導入したのは，アプリケーションを使う人が部屋番号や部屋名など
知っていたときに，スムーズに検索できると判断したからである．先で述べたよう
に 3 階だけ移動すると仮定すると，72 パターンにルートは絞られる．なので，72
枚のルートの画像データをデータベースに格納しておき，地図上に重ねて表示する
ことで，出発地点と目的地の組み合わせに応じてルートをデータベースから呼び出
し，表示されるという方法を考えた．力任せで，本学のように特徴的な施設でなく
ては使えない方法ではあるが，そうすることで単純かつ明快なソースコードになる
と判断した．
図 5.20
細かな分類
図 5.19 カテゴリー分類
（※文責: 伊東翔）
UI
屋内のナビゲーションアプリを作るにあたって，ナビアプリケーションを使って
もらう対象者を，身近な複雑で広い空間ということで，公立はこだて未来大学（図
??）に初めて来た人と設定した．そこで，誰でもアプリを操作できるよう UI では
わかりやすさに重点を置いた．画面を見ただけでルート検索やナビゲーションを利
用者が自分の思うように操作でき，目的地まで安全にたどり着けるアプリケーショ
ンを作ることとした．わかりやすい UI を作るためにトップ画面にアプリケーショ
ンで行うことが出来る動作を明確に示したボタンを用意する必要があると考えた．
Group Report of 2012 SISP
- 69 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
また，より便利にする為スマートフォンやタブレット端末などを使用したことがあ
る人とない人で仕様をボタンで変えれるようにすることで利用者に合わせられる
UI を構築した．実際に用意したボタンは，目的地を検索する方法として講義室事
務関係教員室など大まかに部屋を計 6 種類に分類し，部屋名がわからない人にも
用途で検索できるようにした．そして，画面にボタンを表示するほうが使いづらい
と考える人のために，メニューバーに検索方法のリスト検索文字による入力検索な
どを設けた．屋内のナビゲーションアプリを作るにあたって，ナビアプリケーショ
ンを使ってもらう対象者を，身近な複雑で広い空間ということで，公立はこだて未
来大学（図１）に初めて来た人と設定した．そこで，誰でもアプリを操作できるよ
う UI ではわかりやすさに重点を置いた．画面を見ただけでルート検索やナビゲー
ションを利用者が自分の思うように操作でき，目的地まで安全にたどり着けるアプ
リケーションを作ることとした．わかりやすい UI を作るためにトップ画面にアプ
リケーションで行うことが出来る動作を明確に示したボタンを用意する必要がある
と考えた．また，より便利にする為スマートフォンやタブレット端末などを使用し
たことがある人とない人で仕様をボタンで変えれるようにすることで利用者に合わ
せられる UI を構築した．実際に用意したボタンは，目的地を検索する方法として
講義室事務関係教員室など大まかに部屋を計 6 種類に分類し，部屋名がわからない
人にも用途で検索できるようにした．そして，画面にボタンを表示するほうが使い
づらいと考える人のために，メニューバーに検索方法のリスト検索文字による入力
検索などを設けた．
図 5.21
公立はこだて未来大学
（※文責: 三上力也）
5.3
ADK
ここでは 3 つに分かれた班の内 ADK 班の後期における成果について記述する．
前期に作成した Selfi とナビアプリケーションはそれぞれ別々のシステムで動いており，二つの
間に何の繋がりもなかった．そこで Android Open Accessory Development Kit (ADK) と呼ば
れる Android 端末を利用してマイコンなどのハードウェアを動かすアプリケーションを用いて二
つのシステムを連携させることを目的に活動を始めた．プロジェクト後期において始めたこの活動
は規模が大きいため今までの 2 つの班の内，ハード拡張班から 1 人，ナビシステム班から 3 人を動
Group Report of 2012 SISP
- 70 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
員して ADK 班を作成した．
ADK 班の主な活動は二つのシステムを連携させることであったが，連携の初歩としてまず始め
に達成しなければならないことは Selfi から Android 端末への情報送信，Android 端末から Selfi
への情報送信の 2 つである．最低限これら 2 つの機能を実装しなければシステムを連携させたと
はいえない．そこで今回は連携の初歩として 2 つの目標を立てた． 1 つは Selfi の電力源である鉛
蓄電池の残存電力を Android 端末側で確認できるようにすることと，もう 1 つは Android 端末に
音声で『暗い』や『終了』などと発話することで今回 Selfi の本体に追加する USB ライトを点灯
や消灯することができるようにすることである．
屋内で運行するシステムであるため他の歩行者や狭い道など様々な危険があるなかで安全に運行
しなければならない．そこで連携するシステムを開発するのであれば，より安全性を高められるよ
うな機能を追加できればいいと考えた．安全性を高めるという目標を定めた上で現状の Selfi とナ
ビアプリケーションに足りない機能を議論した．その結果，組み立てたばかりの Selfi では鉛蓄電
池の全容が不透明でありあとどれくらい走れるのかがわからないという問題があった．この状態で
あるとまだ走れると思い込んでいるなか電力がなくなり倒れこんでしまうということがあるかもし
れないと考えた．そこで手元にある Android 端末で鉛蓄電池の電力残量を常に確認できれば電力
残量的に無理のない運行ができるであろうと考え，このような目標を立てた．また屋内を運行する
ということは暗い道を走ることも考えられる．その様な場所で通常通りの速度で運行するのは非常
に危険であると考えた．この危険というものは 2 種類あると考えられた．1 つは周りが暗いため障
害物に気付かず衝突や転倒の危険が増すということ．もう 1 つは他の歩行者が Selfi の存在に気付
かず接近や接触してしまう危険がある．そこでこれらの危険を解消すべく私たちがとった手法は単
純にライトをつけるということである．ここで取り付けるライトの条件として挙げられるのが，運
転手が障害物の存在に気付ける程度の光量であることや他者がどの方位から近づいても Selfi の存
在に気付ける光量であること，電力は Selfi の駆動と同じ電源であるため必要以上の電力を消費し
ないことの 3 点である．光量については，運転手にとっては自動車のような速いスピードで動いて
いるわけではないため障害物の存在に気付けるようなもので十分であり，自動車のライトのよう
な強い光は必要ない．歩行者にとっても接近がわかる程度のもので十分であり，自転車のライトく
らいの光量で問題ないと思われる．また消費電力量についてであるが，電球に対して消費の少ない
LED の照明がよいという議論の結果になった．そこで LED を点灯させる回路を作成しようとし
ていたのだが，この時点で既に残り一ヶ月をきっており開発期間の猶予が残り少ないことを考え市
販の USB ライトを購入してきて，USB の電源供給の回路だけ作成することとなった．いずれに
しろ Android 端末によるプログラミングの作業の量は変わらないがこれで電子回路の開発の方は
作業が短縮されたため最終発表に向けた Selfi の最終調整の時間的余裕を作ることができた．
ここまで ADK を用いて実装する目標やその目標を立てた理由を記述してきたが，ここでは最終
発表時点での開発結果を記述する．まずは鉛蓄電池の残存電力の計測のほうから記述する．このタ
スクの目標達成の条件は Selfi に内蔵されている鉛蓄電池の残存電力を Android 端末側の画面で
確認できるようにすることである．結果から記述すると目標を達成することができた．現在のナビ
アプリケーションにおけるこの部分の挙動は以下である．ナビアプリケーションを起動した最初の
画面にある 4 つのソフトウェアボタンの中に『音声読み取り機能』と書かれた物があり，それを押
下すると，別の画面に遷移する．その画面の上部には電池を模した容器のアイコンがあり，容器内
部は 5 等分されていて緑色に満たされた部分と空の部分がある．このアイコンは Selfi 内部の鉛蓄
電池の電力残量と 5 秒単位で同期している．鉛蓄電池が満ちている時は電池のアイコン内部も緑色
で満ち，逆に鉛蓄電池の電力残量が減少した時はその量に従って電池のアイコン内部もプラス端子
Group Report of 2012 SISP
- 71 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
側から順に空になっていく．ではもう一方を記述する．こちらの目標達成の条件は Android 端末
からの音声入力で USB ライトを点灯させることである．こちらも最終発表の時点で目標を達成す
ることができた．アプリケーションの挙動は以下である．まず前述の鉛蓄電池の残存電力の確認と
同じように『音声読み取り機能』の画面に遷移する．この画面は残存電力を確認もできるが画面の
名前にもあるように音声読み取りを行う画面でもある．この画面にいるとき，端末に向かってキー
ワードを話すと Selfi の方に信号が送られて USB ライトが点灯するという仕組みになっている．
今回はキーワードを『暗い』と『終了』という言葉に設定してある．音声で暗いと入力すると Selfi
のライトが点灯し，終了と入力するとライトが消灯する．
この様に二つの目標を達成できた．しかしいくつか至らない点もある．それらをここに記述して
ADK のタスクにおける反省点とする．先に鉛蓄電池の方のタスクについて反省点を記述する．ま
ず計測の方法について記述するが，鉛蓄電池には電力が減少するにつれて出力する電圧が降下する
という特性をもっているのだが，今回はこの特性を利用して現在の電圧の大きさから残存電力量を
演算するという仕組みになっている．この電力の消費に伴い電圧が降下するという特性だがこの時
の電圧の降下量は一定ではなくグラフにすると非線形の曲線になる．そのため電圧の降下量から電
力の消費量を求める式は多少複雑になるのだが，今回調査が不足して演算式を割り出すことができ
なかった．そのためこの電圧の時には大体これくらいの残存電力という大まかな値しか求めること
ができなかった．また Android 端末側でも，残存電力量を確認するのに専用の画面に遷移しなけ
ればならないという問題が生じている．理想としてはどの画面に遷移しても同じ箇所に同じマーク
があることで確認できるとよいと考えている．次に音声読み取り機能についての反省を記述する．
こちらもいくつか改良すべき点があり，一つ目の改良すべき点は市販の USB ライトを使用したた
めライト自体が非常に大きく Selfi の操縦に邪魔になり得ることである．またケーブルも非常に長
いため Selfi 本体の内部にケーブルを格納するスペースが必要になってしまうことも問題である．
更に固定が甘いため無理な走行をすれば USB ライトが外れてしまい事故の原因になりえるかもし
れない．これらの問題は市販のライトを利用したことで起きた問題であるのでユニバーサル基盤を
用いてサイズの縮小とケーブルの短縮化を図り，固定に関しても機体にねじ穴を開通してねじ止め
などすれば解決できるのではないかと考えている．もう一つの改良すべき点は，アプリケーション
による音声認識の精度が低く結果が反映されるまでにタイムラグが生じることである．これは市
販の音声認識アプリケーションに比べるとはるかに遅く，結果の反映まで 2，3 秒の遅れが生じる
ことがある．またそれほど遅れた認識が間違っていることも多々ある．しかし今回作成したアプリ
ケーションの内ナビゲーション機能の内に含まれている音声認識機能はこれに比べ素早く正確な結
果の反映を行えているため，同様なアルゴリズムで作成することができればこの問題も解決できる
と考えている．
このように実装に至るまでには未だ数多くの問題点や使いにくい点があり，改良すべき余地は大
幅にあるということがわかった．
以上で ADK 班の後期の活動の成果とする．
環境導入
本項目では， ADK を用いて Selfi と Android 端末を相互通信させるにあたってどのよ
うなプロセスで活動を追っこなってきたかを説明する．
まず， Selfi に取り付けるためのマイコンボードを選定する必要があった．そこで，まず
最初に名前が挙がってきたのは mbed マイコンであった．mbed マイコンは製品開発用の
プログラミングによく使用されているマイコンボードであり， Selfi で用いられているマ
イコンにも利用されているマイコンであった．当初は，上位 マイコンにも mbed マイコン
Group Report of 2012 SISP
- 72 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
を用いて開発を行なっていく予定となっていた．しかし， Android の ADK のプログラ
ミングで試験的に mbed マイコンを動作させようとしたがうまく行かず動作させることが
できなかった．また， mbed マイコンのプログラミングの参考書は出版されているものの
Android ADK を用いた mbed マイコンを動かすための参考書はほとんど出版されていな
いというのが現状であったため， mbed マイコンの代わりとなる別のマイコンボードを探
さなければならなかった．
次に名前が挙がってきたのは PIC と呼ばれるマイコンボードであった．PIC マイコンは
Peripheral Interface Controller の略称であり，回路の構成が容易であるだけでなくマイコ
ン自体の価格の安く参考書も mbed より多く出版されていた． これを用いて開発を行うこ
とが決定された．しかしながら，このマイコンボードもうまく動作させることができず，さ
らに違ったマイコンボードを探す必要性が出てきた．
次に名前が挙げられたのが， Arduino と呼ばれるマイコンボードである．この Arduino
のメリットとしては ADK 自体が Arduino マイコンをベースとして開発が進められてい
たため，他のマイコンと比べてプログラミングによる動作確認が容易に行えるという点で
あった．実際に Arduino にソースコードを書き込むためのソフトウェアをインストールし，
マイコンに参考書のサンプルコード書き込むのも容易であった．また，私達の活動の中で
Android 端末のアプリケーションから直接 Arduino のマイコンを操作できた唯一のマイコ
ンであったため， Arduino の採用が決まった．
続いて， Eclipse の ADK を用いるための環境設定についてだが，今までの Android の
アプリケーションはターゲットとしてプラットフォームを 2.3.3 を選択して開発を行なって
いた．しかし， ADK を用いるということでプラットフォームを 4.0.3 の GoogleAPI とい
う名前のターゲットで開発を行なっていった．
（※文責: 犬塚悠人）
基盤作成
ここでは ADK 導入のために選出したマイコンとその周りの電子回路の開発についての課
題とその解決のプロセスを解説する．
9 月当初の予定では mbed マイコンボード (以下 mbed ) を利用して ADK を導入する予
定であった． Selfi 内部に組み込まれているマイコンが mbed であったことが主な理由であ
る．しかし ADK の推奨開発環境であるマイコンボードは Arduino マイコンボード (以下
Arduino ) であり mbed による開発は推奨されていない．そのため Arduino を利用したも
のに比べて mbed を利用したものの方が資料となる文献の絶対数が少ない．ADK を導入す
るためにはいくつかのライブラリをプログラムに書き込む必要があるのだが mbed は文献
が少なく作業が難航し，開発期間が残り 3 ヶ月を切っていることも鑑みて mbed による開発
を諦めた．そして代替案として考えられたのが先述の Arduino である．このマイコンボー
ドは ADK の推奨開発環境であり文献も豊富であることが功を奏し，マイコンと Android
端末間の情報通信の土台をプログラム面で素早く完成させることができた．ここまでが 10
月の終わりまでの出来事である．
情報通信が可能なことを確認できたため次は何の情報をやり取りさせるかを具体化させ
るという課題が生まれた．ここではまず Selfi の走行における安全性に重きを置いて議論し
た．その結果，今回 ADK を利用して行うのは大きく分けて Selfi のバッテリーを Android
端末側で確認することと， Android 端末からの音声入力により Selfi に取り付けたライトを
Group Report of 2012 SISP
- 73 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
点灯させることの二点に決定した．前者は Selfi に内蔵されている鉛蓄電池と Arduino を
接続して A/D コンバータを利用して電圧のアナログ値を計測する必要があり，後者は今回
市販の USB ライトを採用したため USB 機器を実行するための信号線と電源供給線をつな
げる必要がある．そのほか Arudino を稼動させるために電源供給も必要である．ここまで
で必要な電子部品が少しずつわかってきたが 10 月当初は電子回路に対する知識がほぼない
状態だったため Arduino のどの番号のピンにどこから電源入力すればいいのかもわからず
作業が難航した．それでもいくつかの文献を利用し電子回路の基礎をブレッドボードの使い
方から学んだ．その結果 10 月時点では Selfi に同封されている回路図を理解できなかった
にも拘らず 11 月下旬にはその意味を理解でき，何かエラーがあった時に回路図を読んで信
号を追うことで欠陥のある場所の当たりをつけられるようになった．ここで習得した知識は
特に電子回路を作成するために回路図を自作する時に役立った．11 月中旬頃には作成した
基盤を取り付ける場所や取り付け方がわからないという問題が浮上したが寸法を計り，ドリ
ルを用いてねじ穴を設けることで解決した．11 月下旬頃には取り付けを含めた電子回路の
作成は完了し，同時期に完成した Android 側のプログラムとの動作実験を行った．電子回
路側は特に問題は見受けられず無事プロセスを終了した．（※文責: 高橋克弥）
（※文責: 高橋克弥）
バッテリー表示
Selfi の既存の機能にバッテリー枯渇時に LED を光らせる機能がある．しかし，この機
能は LED が小さく運転中には気にかけれるのは困難であり，枯渇時のみにしか分からない
ので今のバッテリー状態がわからない等の問題点が挙げられる．そこで Selfi よりも利用者
に近い Android 端末であればアプリケーション操作時にも携帯電話の使用時と同じように
気にかけれると思い実装することにした．
Selfi のバッテリーは Selfi のマイコンと接続してあるので上記の基板作成で述べた
Arduino 基盤を用いて ADK の技術を利用可能となった．Android に表示されるまでの流
れはバッテリーに接続されているマイコンから電圧データを取得し，それを Arduino 側で
受け取り 0∼100 の範囲に処理し， Android に送る．Android ではその受け取った値をど
う処理するかで話し合いをした．シークバーやテキストによる表示など様々な案が挙げられ
たが，私達が普段見慣れている電池の画像による段階表示で行うと最も利用者が把握しや
すいと考えたため画像表示を採用した．段階表示を行うために Arduino からデータを受け
取った時にその値を 20 毎に区切り，対応した画像を表示させるようにした．これにより一
般的な携帯電話での表示と同じなので理解がしやすく，また画像切り替えの表示なので色や
大きさへのフィードバックの対応が即座に行われやすくなった．最終発表で作成したアプリ
ケーションではそれを実装した画面のみの表示となった．以下の画像がその画面である（図
??）．今後は一般的な端末と同様の表示になるように Fragment を用いた表示方法を実装し
たい．Fragment とはアクティビティの振る舞いをする UI 部品のことであり，これを組み
合わせることでスマートフォンやタブレット端末等の機種に応じたアクティビティを生成可
能であり，一般的なアプリケーションの殆どに実装されている機能である．
（※文責: 畠山大樹）
音声操作
Android は非常に高機能な OS でその多彩な機能のなかに Android Open Accessory
Group Report of 2012 SISP
- 74 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 5.22 Selfi のバッテリー
DevelopmentKit(ADK) と音声認識機能がある．ADK とは Android とハードウェアを簡
単に連携可能にする技術のことだ．そこで今回音声認識操作操作実装に向けこれらの機能を
利用して行った．まず ADK を利用するには Android Open Acessory protocol(AOA) と呼
ばれる通信プロトコルを Android，マイコン両方に記述しておく必要がある．受信処理，出
力コマンドごとのデータ仕様，送信処理を作成したい回路にあわせて記述し無くてはならな
い．今回は音声入力によって Selfi に設置した LED ライトを音声認識で動作させることを
目的としたため機材に流す電流の規格は汎用性が高い USB を採用し暗いと言われたら 5V
の電圧の電流を流すように記述している．参考として簡略な回路図を挙げておく（図??）．
そもそも音声認識処理は音声を解析し，保持している辞書と照らし合わせて該当する言葉
図 5.23
簡易回路図
を探すという複雑な処理を行うため低機能なマイコンではソフトウェア処理をするのは難し
く専用のハードを必要とする．しかし，Android の機能を使うことで簡単に解決することが
できた．音声認識には Android 側で提供されている RecognizerIntent，SpeechRecognizer
と呼ばれる音声認識 API がある．RecognizerIntent の方が実装が簡単であるがこちらはそ
の代わりカスタマイズすることがで Group Report of 2011 SISPGroup Number プロジェ
クト番号 (1，2，..) - グループ名 (A，B，C，...) 英語で記述した短いプロジェクト名きな
い．そのため常時処理を受け付けるようにしたかったため， SpeechRecognizer を使用する
ことにした．使い方として例を元に説明する．
public void onResults(Bundle results) {
Group Report of 2012 SISP
- 75 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
if(strings.contain(“暗い”)){mArduinoprotocol.degitalWrite(0，true);}}
例えばこのように記述すると暗いと言われたらプロトコル上オンにしていた場所に電力を通
すといったことが可能である．これらの技術を用いることで無事音声認識による操作を実現
することができた．
（※文責: 小野修都）
5.4
Selfi 拡張
上位マイコン
ここでは Selfi の駆動プログラムの改変における課題解決に向けたプロセスと成果を述べ
る． 前期では Selfi を作成して実際に試乗してみることで現状での問題点を洗い出した．
タイヤがむき出しで何かを巻き込む危険性があることや，ハンドルの操作方法が慣れるまで
の間は難しいなどの問題があった．その中でも室内で運行するには Selfi の移動スピードは
速すぎるという問題点に注目して，ある一定以上はスピードが出ないように制限速度を設け
ることを目指した．この目標を達成するには Selfi 内部に搭載されている mbed マイコンに
書き込まれているファームウェアに，ある程度以上のモータの回転速度になったときモータ
の回転速度を制限値まで落とす意味を持つソースコードを追記する必要があると考えた．し
かし，Selfi のファームウェアはコンパイル済みのバイナリデータの形でしか販売されてお
らず，私たちの技術力で解読と追記を行うことができなかった．そこで代替案として考えら
れたのがマイコンの階層化である．
マイコンの階層化とは，ソースコードの追記や改変を行わずにプログラムを私たちの思
うとおりに動かすことを目的に，現在搭載されているマイコンの他にもう一台マイコンを追
加して二台のマイコンの間に上位，下位の関係性を持たせることである．ではその仕組みに
ついて解説する．現在 Selfi に搭載されているマイコンは加速度センサ，角速度センサなど
の各種センサ類からの信号を検地して自身の傾きや速度などを取得することで，どの方向に
どれだけ進めば倒立状態を維持できるかを演算し出力している．ソースコードの追記や改変
による方法は最後の演算部分を変えることで出力を変えようとしたものであったが，マイコ
ンの階層化ははマイコンに間違った信号を知らせることで出力を変えようとする方法であ
る．具体的にはセンサ類からマイコンに流れている信号を止め追加したもう一つのマイコン
に流し，その出力を元のマイコンの入力に当てるのである．追加したマイコンには通常時は
センサからの信号をそのまま元のマイコンに流すが，制限速度を越えた時だけモータの出力
が落ちるような演算結果になる信号を流すプログラムを書き込んでおけば元のマイコンのプ
ログラムには一切手をつけずにモータの出力を変えることができる．新しく追加したマイコ
ンから流された信号を利用して元のマイコンは演算しているため，便宜上追加したマイコン
を上位マイコン，元のマイコンを下位マイコンと呼ぶ．マイコンを階層化するメリットは他
にもあり，別項で述べているような Android 端末との連携を考えた時プログラムを書き換
えられるようなマイコンでなければ ADK を導入できないが階層化をすればすべて上位マ
イコンで処理することができるため，より ADK の実装に近づく．マイコンの階層化の実
現に向けてまずは各種センサからの信号のアナログ値を計測する必要があった．幸いにも
Selfi のファームウェアと一緒に信号を検地するソフトウェアが Selfi の製作会社から配布さ
れていたためそれを活用して信号のアナログ値を調べることができた．
Group Report of 2012 SISP
- 76 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
最初はマイコンの階層化と ADK の実装の両方を実装する予定であったが，ここまで
進めた結果開発期間が残り 2 ヶ月をきっていたため両方共実装するのは現実的でないこと
がわかった．そのためどちらか一方を開発することになったが今回のプロジェクトの概要を
考慮した時， Selfi とナビアプリケーションを連携させる仕組みの方を優先させるべきだと
いう結論に達し今年度のプロジェクトではマイコンの階層化の実装を目指さないことに決定
した．実装こそしないことにはなったがマイコンをもう一つ追加するというアイディアは
ADK の導入に引き継がれ結果的にプロジェクトの進行速度を加速させた．
（※文責: 高橋克弥）
Selfi2 台目
Selfi の 2 台目 (以下 2 台目と表記) を組み立てるために， Selfi の 1 台目 (以下 1 台目と
表記) 組み立ての際に行なったことと同様に部品，ネジ等の仕分けを行なった．仕分けた際
にほとんどの部品が 1 台目と違うことに気づいた．大部分において，仕様変更が行われたの
か 2 台目と 1 台目との部品が違うので，前期に得た組み立てのノウハウが通じなくなった．
よって，組み立て作業が考えていたよりも順調に進まなくなった．夏期休暇中に，モータと
ハンドル部分の途中までの組み立て作業を終えた．しかし，ジャイロセンサや各速度センサ
等の電子部品を全て紛失してしまったので， Selfi の制作会社である株式会社エフ・アイ・
ティへと紛失部品を注文した．そのため，注文部品が届くまでは組み立て作業の一切を行う
ことが出来なくなった．注文部品が届いた後，制作作業を続行した．ジャイロセンサの仕様
変更がなされたために，1，2 台目で使用していた部品を使用してないらしく，同じ部品が
もう無いと通達される．そのため，ジャイロセンサの回路図を下に自作した．自作したセン
サを 1 台目に組み込み，正常に動作することを確認した．よって，自作したセンサを使用す
ることに決定した．部品問題について解決したので，組み立て作業再開．しかし，1 台目と
の部品の相違によって，組み立てては，不具合が発生し，分解して確認するという作業を繰
り返し行うことになり作業が難航した．モーターを車体に組み込み，問題無く動作するかを
外部電源とつなげて，試運転を行った．しかし，モーターから異常な音が鳴り始めた．原因
究明のために解体整備を行なった．その解体作業は，モーターまで分解し，組み立て作業の
最初の状態に戻した．しかし，モーターから異音が発生する原因が分からずじまいだった．
その後，ハード拡張班で原因究明のために活動したのち，担当教員に相談した．結果，担当
教員より問題なしだと判断され，組み立て作業を再開した．そして，組み立て作業をバッテ
リー組み込み，基盤積み込みだけを残したところで，基盤の最終チェックを行ったところ動
作しなかった．原因を探るために基盤の回路図を下に確認作業を行ったところ，電子部品の
一つをはんだ付けしてないことが発覚した．取り付けを行い，改めて動作確認を行ったとこ
ろ正常に動作したので，バッテリーと基盤の組み込み作業を行った．タイヤを Selfi のタイ
ヤ軸にはめ込む際に軸とタイヤのはめ込み穴のサイズがあわずにうまくはまらなくなってい
た．よって，タイヤの軸とはめ込み穴のサイズを合わせるために軸とタイヤのはめ込み穴を
削り出す作業を行った．最終的には，潤滑油を使用してはめ込み，はずれないよう固定して
タイヤのはめ込み作業を終えた．バッテリー組み込み作業中に圧力センサの保護処理が十分
ではなく，損傷させてしまった．その整備のために解体を行った．しかし，圧力センサの損
傷具合が自分たちだけでは判断できない問題となったので，担当教員に確認をとったとこ
ろ，圧力センサの仕様上では軽度の損傷であり，問題なく動くと判断された．よって，組み
立作て業を続行した．改めてバッテリーを組み込んだのちにパラメータを調整したのだが，
Group Report of 2012 SISP
- 77 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
1 台目から仕様変更が行われたのか，基盤から常にバッテリー容量が足りないと鳴る設定に
してある警告音が鳴り止まなくなっていた．当初はバグか，パラメータが正常値ではないと
判断し，調整していたのだが原因は最後までわからなかった．最終的に，発表には 2 台目を
使用するので 1 台目の基盤と総取替えを行い，2 台目を異常なく動かすようにした．そのの
ち，正常に動作することを確認し，2 台目の組み立てを完了とした．
2 台目の組み立てが完了したのち，1 台目での試乗会や，アンケート等で発覚した問題点
を解決するためにハード的な拡張を 2 台目に直接施していった．
まず初めに出た問題としては，発進時に車体がぐらつき安定性が無く，危険に感じてしま
うこと．制作するにあたり，10/5(金) に公立函館高等学校の学生が見学学習に訪れたので，
その際に Selfi の試乗会を行った．それと同時に Selfi の乗りやすさのアンケートを行い，
どのような時に恐怖感を感じるのか，また，どういうものがあれば恐怖感は払拭されるのか
のアンケートをとったところ Selfi に乗り込むために何か補助するものがあれば良いという
結果が得られた．この結果から， Selfi に乗り込む際に補助する器具を制作することを決定
した．そして， Selfi に乗り込むために不安感を軽減するために制作するものとして 3 つの
案が出た．乗り込む際に体を支える手すりを作る案．ハンドルを押さえ込み，固定する案．
車体を押さえ込む土台・発着場を作る案．今回は Selfi に乗り込むための土台・発着場を制
作することとなった．まず，アンケートの結果や，技術的・素材的問題から取り掛かるのは
発着場制作となった．制作する際， Selfi を押さえ込むために車体の高さや，土台にどの程
度の重量が必要なのかなど考慮しなければならない点は多いが，イメージを固めるためにモ
デルとしての実物を制作することを優先した．そのモデルを制作するために加工のしやすさ
という点からダンボールでの制作となった．他にも，発着場内部に重しを入れる案や，木材
で制作する案もあった．発着場のモデルが完成したのち，下面に摩擦力を増やすため，ゴム
シートを接着した．その後， Selfi の試乗会を開き，発着場がある場合，無い場合の差を比
較してもらい，アンケートを取った．その結果，発着場があったほうが乗りやすいという結
果が得られた．それと同時に，乗る際の恐怖感は払拭できたが，今度は降りる際に恐怖感を
感じるという結果も得られた．これからさきでは，降りる際の安全性向上が課題になるだろ
う．次に行ったのは，ナビアプリを載せるための土台である．当初は，自分たちで何か制作
できないかと活動を行っていたのだが，既製品を仕様したほうが安定するという結論に達し
たので制作を断念した．よって，既製品で自転車に固定するための器具があるので，それを
購入し仮設置した．しかしながら，本採用はせずに自分たちで制作するのは次回に回すこと
とした．次に制作を行ったのはタイヤカバーである．なぜなら， Selfi のタイヤが露出して
いるので，くつひも等が巻き込まれてしまうという問題があるからである．これに対応する
ために，タイヤカバーを設置した．工作機械にはレ‐ザーカッターを用いた．レーザーカッ
ターで加工できる素材はアクリル板とのことであったので，素材はアクリル板を使用するこ
とになった．タイヤカバーを制作するにあたって，図面を画像ファイルに書き起こさなくて
はいけないのだが，制作の詳細についてはタイヤカバーの欄にて参照すること．次に取り掛
かったのは arduino 端末を設置する作業である．設置する場所としては，基盤設置部分に
余裕があるので，そこにスペースを取り，設置することとした．設置するために基盤を載せ
た土台にネジ穴を通すための穴をあけ，絶縁処理を施して設置した．絶縁処理を施したの
は，通電してしまうと基盤自体が損傷してしまうので，それを避けるためである．そして，
arduino 端末とナビアプリを有線でつなぐ必要があったので，配線を通すために Selfi の車
体に配線が通るほどの穴をあける必要があった．そのために， Selfi の車体に直径 3cm ほ
Group Report of 2012 SISP
- 78 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
どの穴をあけた．その部分から配線を通し，ナビアプリと接続し， Selfi とナビアプリの連
携を可能とした．最後に，暗がりでも前方を見通すためにライトを設置することになった．
ライトを制作するのは時間的余裕から厳しいものがあったので，自分たちでの制作はしない
こととした．ライトには LED ライトを採用した．ライトも既製品で十分使用できるものが
あったので，それを採用した．そして， Selfi のハンドルの下部部分に設置し，ライトの設
置作業は終了した．以上が，今回，我々ハード拡張班が Selfi に行なってきた安全面の向上
のための改造・改良作業である．
（※文責: 岩山拓哉）
タイヤカバー
本項は，タイヤカバーの製作を新技術開発サロン様に依頼した前とその後の活動が異なる
ことから，大きく 2 つに分けて記述する．
新技術開発サロン様にタイヤカバーの製作を依頼する前のプロセスを以下に示す．
素材
タイヤカバーの素材の検討についてのプロセスの詳細を記述する．タイヤカバーに用
いる素材の検討を行うためにハード拡張班内で話し合いを行った．このときタイヤカ
バーに適した素材の条件として，足をぶつけても壊れない程度の強度を持つこと，プロ
ジェクト内で加工が可能であることが挙げられた．また，実際にタイヤカバー等に用い
られる素材はどのようなものであるか調べた．特に，同じ倒立自動二輪車であるセグ
ウェイに取り付けられているタイヤカバーの素材を参考にしたいと考えていたが，カ
バーの素材について詳細に書かれているものがなく断念した．次に，自転車の泥除けで
ある自転車フェンダーを参考にすることを考えた．自転車フェンダーに用いられる素材
はアルミニウムやステンレス鋼や強化プラスチックなどである．それぞれの特性には，
軽量であることや比強度が大きい，耐食性があるなどタイヤカバーに用いることができ
れば利点となる特性を持っていた．また，これらの素材は比較加工しやすい素材であっ
た．しかし，比較的加工しやすくはあるが，本プロジェクト内で加工することはできな
い点やタイヤカバーにより適した素材を判断することが難しかった．そこで，本プロ
ジェクトに協力して頂いている新技術開発サロン様に，製作とともに素材の検討につい
ても依頼を行うことで解決することとした．
形状
形状についてのプロセスの詳細を記述する．タイヤカバーの形状は目的である「タイ
ヤに靴紐や足等を巻き込むこと」と「視覚的な恐怖心」を防ぐことを満たすものである
とした．初期の案として 2 つの形状が上がった．1 つ目は半円状のもの，2 つ目は半円
状のものの弧の上部を覆ったものである．
2 つとも靴紐や足をタイヤから遮れるため条件を満たせるのではないかと考えた．し
かし，1 つ目ではタイヤの上部を覆っていないため視覚的に恐怖心を煽らないかという
意見が挙がった．さらにセグウェイに用いられるタイヤカバーはタイヤ上部の一部を
覆っている．これらの点から，製作するタイヤカバーの形状を 2 つ目の案に決定し，前
期ではこれのモデルを製作した．(図??)
加工方法
加工方法について示す．素材からタイヤカバーに加工するに当たって，綺麗に成形す
Group Report of 2012 SISP
- 79 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 5.24 カバーモデル
る必要があった．モデルを製作した際は，素材がダンボールであったため加工は容易で
あり，モデルであることから綺麗に成形することはあまり重視されなかった．しかし，
試作品は Selfi の外観に関わるため可能な限り綺麗に成形する必要がある．また，本プ
ロジェクト内では上記に示したタイヤカバーに用いる素材を綺麗に成形することは困難
であった．そこで，新技術開発サロン様への製作を依頼することとなった．製作を依頼
するに当たりタイヤカバーの図面が必要になった．これは，タイヤカバーのモデルが中
間発表会に合わせ急遽作られたため大まかな図面しかなく新技術開発サロン様に依頼で
きる程の正確なものではなかったためである．
図面製作
図面の製作についてのプロセスを示す．タイヤカバーの図面を書くために製図の知識
の取得を行った．製図の方法は手書きと CAD を用いる 2 つの方法を考えた． CAD を
扱うための技術を取得することは時間がかかることから手書きでタイヤカバーの図面を
製作することとなった．製図の知識の取得は「精密板金 wiz 図面作成・書き方・記号
例、製図用紙」様を参考に行った．[?]
知識の取得後，実際に図面を製作した．（図??）製作した図面を取り込み， PDF ファ
イルとし，モデルの写真とともに新技術開発サロン様に製作の依頼を行った．
図 5.25
タイヤカバー図面
以上が，新技術開発サロン様に依頼をする前の活動である．しかし，依頼後にタイヤカ
バーを製作していただくことが難しくなったため，依頼したものとは別個にプロジェクト内
Group Report of 2012 SISP
- 80 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
で製作することを決定した．プロジェクト内でタイヤカバーを製作することを決めた後のプ
ロセスを以下に示す．
加工方法の再検討
加工方法の再検討について記述する．制作方法の変更後，初めに加工方法の再検討を
行った．レーザーカッターが未来大学の工房内に導入されたことからこれを用いて加工
することが可能となった．レーザーカッターは，加工方法の問題であった外観を損なわ
ないような成形が可能である．よって，タイヤカバーの加工にレーザーカッターを用い
ることとした．しかし，レーザーカッターを用いるための課題として， Illustrator ま
たは CAD の図面が必要となった．
素材の再検討
素材の再検討について記述する．この素材は，プロジェクト内で加工可能なものであ
る必要性があると考えた．このとき，加工方法として未来大学内に導入されたレーザー
カッターを用いることでタイヤカバーの加工が可能であったため，レーザーカッターで
加工しやすいアクリル板に素材を決定した．レーザーカッターを用いた経緯や過程は後
の加工方法の項目で示す．アクリル板の厚さは 3mm のものを使用することとした．ア
クリル板の色は Selfi 本体に合わせて白色のもととした．
形状の再検討
形状の再検討について記述する．依頼を行った形状では上部の弧を覆っているが，ア
クリルではこの部分を製作することは難しいと考えた．そのため，新たに形状を模索
し，2 つの案が挙がった．1 つ目は以前にも挙がっていた半円状のみにしたもの，2 つ
目はタイヤの軸と軸の間に埋め込める三角形の角を丸めたようなもののである．1 つ目
に関しては，タイヤカバーの先端がタイヤに接触しカバーが割れてしまうことやタイヤ
を傷つけパンクさせてしまうのではないかといった懸念があった．そのため，1 つ目の
半径はタイヤの半径よりやや余裕を持たせる程度の大きさとした．また，以前考慮して
いた上部を覆っていないことによる視覚的に恐怖心については， Selfi は接地している
ときにタイヤの回転が穏やかであることがわかったため，重要視する必要はないと判断
した．その後，2 つのモデルから 1 つに絞るに当たり，タイヤに靴紐を巻き込む危険性
はどの程度あるのか実験を行った．
靴紐の巻き込み実験
靴紐の巻き込み実験について記述する．巻き込み実験は， Selfi の足場に靴を置き，
タイヤの軸と軸の間に靴紐を垂らした状態でタイヤを前進方向や後進方向に回転させる
ことで靴紐が巻き込まれるか調査することとした．試行は 10 回程度行い，靴紐の位置
は巻き込まれやすいと考える軸と軸の間や他の隙間の周りを重点的に調べた．実験の結
果として，靴紐をさまざまな形で垂らしたが，巻き込まれることはなかった．この結果
から，靴紐の巻き込みを防止することを重要視するべきではないと考えた．
この結果を踏まえてタイヤカバーの形状を決定した．2 つ目のものでは，重要視され
ていない靴紐の巻き込みを防止できるが足が触れてしまう危険性を排除できないため，
1 つ目のものの形状で試作品を製作することを決めた．
取り付け方の検討
タイヤカバーの形状を決定するとともに， Selfi 本体への取り付け方も決定した．
Selfi には元々タイヤカバーが実装されていないため，タイヤカバーを取り付けるため
に何らかの加工を Selfi 本体に施す必要があると考えた．しかし， Selfi にはモー
Group Report of 2012 SISP
- 81 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ターユニット上部に取り付けられる弧状の部品があり，均等に 5 つの穴が開いていた．
（部品の写真 図??）この穴に合わせてネジ穴をタイヤカバーに開け，ネジとボルトを
用い取り付けることを考えた．モーターユニットの位置はタイヤの内側の横であるた
め，その上部に取り付けられるカバーの位置にあり，この位置はタイヤカバーを取り付
ける絶好の位置であった．以上のことから，モーターユニットの上部のカバーの穴を利
用することで試作品のタイヤカバーを Selfi 本体に取り付けることとした．
図 5.26
部品の写真
CAD による図面製作
CAD を用いた図面製作について記述する．タイヤカバーの試作品の製作を開始す
るに当たって CAD による製図を開始した．始めに使用する CAD を検討した．当初，
Jw cad を使用することを考えていた．しかし， Jw cad は建築向けの CAD である
と指摘されたため，再度検討をした．そこで DraftSight が挙がった．DraftSight は
Auto Cad によく似たフリーソフトの CAD であり，扱いやすいという特徴があった．
そのため， DraftSight の使用を決定し，操作方法及び製図技術の取得を進めた．まず，
DraftSight の操作方法の取得を web ページを用いて行った．
取得した操作方法として，直線や構築線，ポリライン，円などの基本的な製図方法と
フィレットや分割，ミラーなどの修正方法，そして寸法方法がある．
操作方法の取得後，製図の設定を行った．実際の製図に用いた設定を以下に示す．用
いたテンプレートは standard.dwt ，図面のサイズ A4，寸法スタイル ISO-25 である．
線に関しては，外形線を線種を実線とし線幅をデフォルト，中心線を一点鎖線とし線幅
0.13mm，文字寸法を実線とし線幅 0.13mm，隠れ線を破線とし線幅デフォルト，構築
線を実線とし線幅デフォルトとした．
図面の設定後，練習用の図面を用い製図を行うことで製図技術の取得に努めた．まず
始めに A4 用図枠の製作を行った．図枠は，完成した図面を用紙の枠に収めるときに必
要となるため汎用性が高く今後の活動にも役立てられることや簡単な操作で製図できる
ことから最初の練習にこれを製作することとした．図枠の完成後は練習用の図面を用い
て製図の練習をした．用いた図面は V プーリーの図面である．V プーリーの製図では，
ミラーの位置が僅かにずれてしまい正確に製図できていなかったため修正を行いこれを
完成させた．この図面完成後にタイヤカバーの図面を完成させるために必要な技術を取
得できたと考え，試作品タイヤカバーの製図に取り掛かった．これはタイヤカバーが V
プーリーよりも単純な構造をしているからである．また，タイヤカバーの製図に取り掛
Group Report of 2012 SISP
- 82 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
かる前に以前採寸したデータが正しいかどうかもう一度確認するため， Selfi のタイヤ
周囲の採寸を行った．完成したタイヤカバーの試作品の図面を図??に示す．
図 5.27 DraftSight で制作した図面
試作品の加工
図面完成後，レーザーカッターを使用するに当たり，レーザーカッター講習会にて
「レーザーカッター講習修了証」を取得する必要があったため，取得のために講習会に
出席した． レーザーカッター講習修了証取得後，実際に完成した図面を用いてレーザー
カッターによる加工を行った．まずは，使わないアクリル板の廃材を用い加工の練習を
行った．しかし，このとき焦点をマニュアルフォーカスを用いて合わせる事を忘れてい
たため失敗してしまった．その後，アクリル板や木材の廃材を用い練習を重ねた後，試
作品の加工を行った．レーザーカッターによる加工後は，図面にミスがなく Selfi 本体
に取り付け可能であるか確認を行った．取り付け可能であることが確認した後，電動ド
リルを用いて取り付け部分のねじ穴を開けることとした．取り付け部分のねじ穴をレー
ザーカッターで開けず手動であけることとした理由は，取り付けに用いる部品の穴がそ
れぞれの部品によって多少バラけていたためである．ねじ穴の位置は図 3 の部品を元に
マーカーとセンター・ポンチで印を付けた．
アクリル板は比較的に割れやすい素材であることから，割れないよう慎重に穴を開
けた．ドリルは 4mm のものを用いた．その後，加工が終わった試作品を Selfi 本体に
4mm のネジとボルトを用いて取り付けた．試作品としてはタイヤカバーはこの段階で
完成となる予定であったが，問題点が指摘された．
試作品の問題点と解決手法
1 つ目に試作品のタイヤカバーにプロジェクトのロゴとメンバの名簿を彫刻した方が
よいのではないかと指摘された．これらはタイヤカバーの目的に直接的に関係はなかっ
たが，プロジェクト内の成果物であることを明示するために彫刻することとした．彫刻
に用いるロゴは以前グループ内で製作したプロジェクトのロゴを流用しタイヤカバーに
彫刻するものと，色のついたアクリルを文字やロゴの形にカットしタイヤカバーに貼り
付けるものの 2 つが考えられた．前者のものは加工が容易であるが用いれるアクリル
板が白色と透明色であり目立ちにくいと考えられた．後者のものは色を調整することで
目立ちやすくできるが，新たにロゴを考えなければならない点や加工に時間がかかると
いった問題点があった．プロジェクト内での話し合いの結果，プロジェクトのロゴが目
立つ必要はないということから前者のものを製作することと決定した． 3mm のアクリ
Group Report of 2012 SISP
- 83 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ル板 2 枚重ねのタイヤカバーには 1 層目に彫刻を施し，5mm のタイヤカバーにはその
まま彫刻を施した．
2 つ目に試作品の問題点として，アクリル板を用いたため強度に不安があると指摘を
受けた．特に，取り付け部分は，ネジ穴からアクリル板の端まで距離が短く割れてしま
う可能性があると指摘された．この問題を解決するため，素材の変更を考えた．木材の
使用を考えたがアクリル板の厚さを変更するまたは複数のアクリル板を重ねることで課
題の解決を図ることとなった．試作品に新たに厚さ 3mm のアクリル板 1 枚を重ねる，
または厚さ 5mm のアクリル板 1 枚を用いることで試作品の補強，または新たなタイヤ
カバーの製作を行った．ここで用いるアクリル板は新技術開発サロン様の大竹商店様よ
り頂いた透明なアクリル板を用いた．5mm 板のタイヤカバーは試作品とまったく同じ
工程にロゴと名簿の彫刻を加えたのみであったため問題なく完成した．しかし，厚さ
3mm のアクリル板 2 枚重ねのタイヤカバーはネジ穴の位置を正確に一致させる必要が
あったため，試作品や 5mm 板の製作より困難となった．ネジ穴を開けた後は，1 層目
と 2 層目のアクリル板で穴が一致していることを確認し，ネジとボルトで本体に取り付
けられることを確認し完成とした．
その後，2 つのタイヤカバーのどちらをタイヤカバーを使用するか話し合い，3mm
板を 2 枚重ねたものを使用することと決定し，正式に Selfi 2 台目に取り付け，タイヤ
カバーは完成となった．
（※文責: 浅野翔太）
発着場
Selfi の安全面向上のために，ハード拡張班では乗り降り時の恐怖感の抑制やスピード制
限を設ける，緊急停止のできるブレーキを備えるなど， Selfi を施設内で走行させるにあた
り，問題点をいくつか挙げ，その解決策を考えた．その結果，まずは Selfi に乗るときの不安
定さや危険性を考慮し，外部実装を優先的に取り付ける必要があると考えた．そこで，概要
で述べた市立函館高等学校の生徒に対して， Selfi に乗るときに足場があるかないかによっ
て，乗りやすさは変わるのかを調べるため，試乗実験とアンケート調査を行った．
アンケートの内容は，5 つの質問で構成してあり，1 つ目に足場があるときとないときの
写真を載せ，足場があるとき、ないときで Selfi に乗りやすさはどうかを 5 段階で調べた．
項目には，乗りづらい・やや乗りづらい・普通・やや乗りやすい・乗りやすいの 5 種類であ
る．2 つ目が Selfi に乗るときに恐怖を感じたかというもので，3 つ目に 2 つ目の質問で恐
怖を感じた人に対し，その原因を調べるものとなっている．原因の選択肢には，足場が不安
定でふらつく，ハンドルが不安定，足場の高さ，その他というものである．4 つ目，5 つ目の
構成は 2 つ目，3 つ目のものと同様の構成であり， Selfi に降りるときに関する内容である．
被験者は 13 名おり，全員足場がある場合とない場合で Selfi に試乗してもらい，今回足場
としては，ほぼ Selfi の足場と同じ高さの階段を利用した．また，被験者は全員初めて Selfi
に乗るという条件の下に行った．アンケートは担当教員の意見を参考に，取り付ける外部実
装の形を決定した上でそこから得られる効果や必要性の確証を図るものとした．実際に作成
したアンケートを以下に表す．（図??）
アンケートの結果として，乗るときに怖いと感じた人は 7 名で，降りるときに怖いと感じた
人は 2 名であった．また，乗るときに怖いと感じた人 7 名のその理由は，足場が不安定でふ
らつくというものが 6 名，その他に，ハンドルが押せないというものが 1 名という結果だっ
Group Report of 2012 SISP
- 84 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 5.28
作成したアンケート
た．ここにあるハンドルが押せないというのは， Selfi の操作上ハンドルを前に倒しても前
に進まないという意である．次に，降りるときに怖いと感じた人 2 名のその理由は，足場
が不安定でふらつくというもの 1 名，未回答 1 名という結果であった． Selfi への乗りづら
さを感じたのは足場がない場合のみであり，多くが足場がある方が乗りやすいという結果に
なった．全体的には，足場がある方が圧倒的に乗りやすい，乗り降り時に恐怖を感じるとい
うデータが得られた．また，恐怖を感じるというものは， Selfi 本体が不安定でぐらつくか
らという理由によるものであった（図?? 図??）．
前期の活動の中で， Selfi の拡張について議論した際，スピード制限や緊急停止をするため
にブレーキを設ける方針もあったが，アンケート調査を通し，改めて我々ハード拡張班は
Selfi に拡張するものについて議論をし，その結果 Selfi への乗り降り時のぐらつき， Selfi
本体の不安定さを改善する方針で決定した．まずは，アンケート調査で目立った足場がある
方が乗りやすいという意見をもとに， Selfi に乗る際の補助として足場を作成することにし
た．
Group Report of 2012 SISP
- 85 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 5.29 アンケート結果 足場なし
図 5.30
アンケート結果 足場あり
発着場という名の Selfi に乗る際の補助となる足場は，今回持ち運び可能ということを考
慮に入れて，サイズ・重量・形を設計・作成したが，これはあくまで Selfi が固定的に設置さ
れる場が施設内に用意されていないという現状からこの形態となった．この他にも Selfi の
発着場が地図上に表示され，常に Selfi はその発着場に設置されるという案があったが Selfi
の台数や場所を取らず，自由度の高いということからも持ち運び可能なものを採用した．
発着場の作成にあたって，まず試作モデルとしての材料にはダンボール素材の板を使用
し，地面から Selfi の足場の高さまで重ね， Selfi の底面と重なるものを作成した．作成手
順としては，まず発着場のモデルのデザインを考案し， Selfi の寸法を測定した．モデルの
デザインが決定した後は，手書きと CAD による設計図の作成を行った．設計図の完成後
は作成作業に移り，ダンボール板の切断・組立を経て形が出来上がった．その後サイズの微
調整，テープによる保護，そして Selfi を支えるために重量にやや心配があったため，滑り
止めの役割として発着場の底面に厚さ 1mm のゴムシートを取り付けた．これらの手順を経
て，発着場が完成した（図??）．
図 5.31
発着場
発着場のデザインを考える段階で，今回は底面を埋めてその下にゴムシートを取り付ける形
をとったが，発着場の底に錘を取り付けることができるような空間を用意し，重量を調節で
Group Report of 2012 SISP
- 86 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
きるデザインも検討していた．また，今後新たに改善・作成する案の一つとして Selfi の後
退を予想し，押す力を支えることができる力を考慮に入れた重量のモデルも用意した．そし
て，素材についてだが，試作段階としては作業時間を考え，ダンボール板とゴムシートを使
用したが，木材も検討する一つとして考えていた．
発着場の試作モデルが完成後，プロジェクトメンバのみならず，本大学の学生に使用して
もらったうえで Selfi に試乗テストを行った．試乗した感想として，初めて Selfi に乗った
人，すでに乗ったことのある人問わず，乗りやすさが増したという声が圧倒的に増え，乗り
やすさを向上させるという目的がひとつ達成させることができた．その他にも，発着場の形
が Selfi のタイヤを除いた本体部分のみ支える形（図??）のため， Selfi に乗った直後に後
退してしまうという問題点を解決することができた．しかし，未だ Selfi 本体の不安定さを
完全に解決することはできておらず，これを解決するためにも， Selfi を倒立したまま支え
るものが必要であるということがわかった．今回作成したモデルでは， Seifi の底面のみを
支えることしかできず， Selfi のハンドル自体を固定しないためバランスが保てず倒立した
まま支えることはできなかった．試乗後の感想・意見の中には乗るときの恐怖感を解消する
ことはできたが，降りるときの恐怖が目立ったというものもあり，降りるときの恐怖感を解
消させるものを作るという新たな課題が発生した．これについては，降りるときに恐怖を感
じ，その理由が足場の不安定さというアンケート結果にもあったので，今後優先的に取り組
む必要性があると考えられた．また，この問題に関しては，本体の不安定さを解消させるた
めのハンドルを固定し， Selfi を倒立したまま支えるものを用意することで解決できると考
えられるため，今後ハンドル固定として拡張を進めることの必要性が高まった．
図 5.32
発着場使用
発着場を作成するにあたり，本来の目的である Selfi に乗るときの恐怖感をなくすというも
のを達成することができた．しかし， Selfi に乗ったときの本体のぐらつき感を解消するこ
とには届かず， Selfi 本体を倒立のまま支え固定するという課題に加え， Selfi から降りる
ときの恐怖感を失くすという課題が得られた．
今回作成したモデルでは，完全に Selfi へ乗る際の恐怖感を解消することができなかった．
さらに，持ち運び可能な置き型のものには，移動が容易で自由度の高いものではあったが施
設内のどこにでも設置することができるという前提なしでは効果を発揮できるものではない
ため，Selfi 自体に搭載し，発着場の場所を必要としないタイプのものを作る必要もあると考
えた．しかし，これを満たすモデルの考案は今年度の活動では届かなかったため，次年度以
降にモデルの考案から試作品の作成，テスト，修正改善まで活動を広げ，発着場を拡張して
いきたい．
Group Report of 2012 SISP
- 87 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
（※文責: 仲田健太郎）
ハンドル固定
発着場の完成後，テストした結果 Selfi に乗るときだけに限らず降りるときにも恐怖を感じ
るという声が多く挙がった．そしてその原因は Selfi に乗ったときに感じる不安定さ，ぐら
つきからくるものであった．それをふまえハード班では， Selfi に新たな拡張として Selfi
を倒立したまま支えるものを作る必要があるという結論に至った．
今回施設内を案内する乗り物として， Selfi を採用した． Selfi には倒立振子の制御が組
み込まれているが，これは Selfi の電源を入れてから，制御を始めるスイッチを押しながら
片足を乗せ， Selfi を水平状態にして初めて動作が行われる仕組みである．そのため， Selfi
に乗る前からハンドルが立ち上がって固定されているわけではなく，電源を入れた状態では
ハンドルが前方に下がり，乗るときに自分の手で起こさなければならない．また， Selfi の
足元には圧力センサが埋め込まれており，重量の変化で速度，前後のみだが進行方向が決ま
るため，初めて Selfi に乗る人にはその操作が難しく，乗った瞬間に前後にぐらつくことが
よく見られた．さらに，これも発着場の試乗のときによく見られたことであるが， Selfi か
ら降りるときの問題として， Selfi からの降り方をよく聞かれたということが挙げられる．
これは Selfi の倒立振子の制御が両足が離れることで止まるため，降りるときに片足だけ降
ろし，その状態のまま Selfi が後退しもう片足がひかれる，という問題が予測される仕組み
からきている．
これらの問題をふまえ，ハード拡張班では原因となっている Selfi のハンドル部分の固定
を進めるという案が強まった．これに関しては発着場の作成時にもいくつか対策のモデルが
挙げられていた．まず発着場の様な台座となるものとは異なり， Selfi の横に手すりのよう
な支えを用意するモデルである．（図??）
図 5.33
手すりがある場合
これは， Selfi に乗り降りするどちらの場合にも支えとして扱うことができ，さらに Selfi が
発進するときや走行時には直接的な障害にならないという利点があった．しかし，人の体重
以上の力を支えることが必要があると予想されるためそれに応じた強度のものにしなければ
ならないという点があった．また，走行時の障害としての危険性は少なくとも，乗り降りす
るどちらの場合でも片手で Selfi を操る必要があるため危険が伴うことが十分に予想された．
さらに，この支えを利用した試乗の結果として， Selfi に乗って発進するまでは恐怖を感じ
Group Report of 2012 SISP
- 88 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ることもなく乗りやすいという点はあったが，発進する瞬間に支えにおいた手を離すため結
果的に乗る瞬間に感じられていた， Selfi 本体のぐらつきやそこからくる恐怖が感じられて
しまった．発着場を優先し，この手すりのような支えの作成を見送った理由としては，一つ
目に大きさ，強度という点からも Selfi に搭載することは難しいというものであった．これ
を実装するには大きさから，ある場所に設置しなければならないため発着場と同じ外付け型
の支えでも，持ち運びが困難であるものになってしまうということである．つまり， Selfi
自体に取り付けられる形として，強度やバランス，何より本来の目的である Selfi 本体のぐ
らつきからくる恐怖を抑えることができるという点全てを考慮したものを製作するには，時
間・技術が十分に必要であると考え，発着場作成時点では見送る形となった．二つ目に，試
乗結果からこの形の支えでは Selfi が走行する瞬間に，これまで乗り降りするときに感じら
れていた Selfi 本体のぐらつきや恐怖が生じてしまうため，問題の解決としてふさわしくは
ないと判断したからであった．このほかにも，下図にあるようなハンドルの下部分を固定す
るモデルが挙げられていた．（図??）
図 5.34
正面からハンドルを抑えた場合
これは Selfi が発進する直前まで進行方向とは逆向きに力を加え人が支えてくれるような支
えを用意するモデルである．こちらは実際にこの支えを利用して試乗した結果として，乗る
ときのぐらつきを抑えることに関しては最も効果の高いものであった．しかし乗った瞬間の
重心の傾きによって前後に動いてしまったり，走行するにあたり支えが障害となってしまう
という欠点がみられた．しかし，乗りやすさの点ではこのモデルのものを取り付けることに
より解決できると考え，そのほかの欠点を改善するということで，このモデルをもとにハン
ドル固定の製作へと移行した．
そのほかにも，下図の足場がある場合と称した Selfi のタイヤを除いた下位部分を固定す
るモデルも考えた．（図??）この形は発着場として製作を行ったが， Selfi 本体に取り付けら
れる形としてのモデルも考案していた．このモデルにおいて必要な要素としては，乗り降り
する前の状態からすでに Selfi を固定し支えられるというもの．さらに，発進時には足で踏
む程度の簡単な操作で固定状態から自由に走行できる状態へと変化することができるという
ものであった．これはハンドルを固定する役割を備えた自転車のスタンドのようなもので，
Selfi に取り付けられる拡張品を考えた際に最も技術や時間を考慮にいれた上で可能である
と考えたものである．このモデルには，特に降りるときに Selfi が停止してから降りるまで
にスタンドを出し固定することで，これまで後退しないように気をつけながら Selfi から降
Group Report of 2012 SISP
- 89 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
りなければならない点を改善することができるというメリットがある．しかしこのモデルで
は，スタンドを引きずりながら前後に進むことが大いに予想されるので床を傷つけず，かつ
Selfi のみの重さではなく走行時に加わる重みも考慮した上での形や大きさ，素材までを十
分に検討しなければならない．これらのモデルを考える際に Selfi 走行時に起きると予想さ
れる障害をいくつかプロジェクトメンバで考えた．その中にあった，急に人や物が進行方向
上に現れ急停止しなければならないという点，エレベーター内で完全に固定しなければなら
ない点，目的地が変わり一度止まって操作を行いたい時に停止しなければならない点におい
て， Selfi を初めて乗る人には停止という操作が簡単に行えないことを考慮し問題であると
捉えた．これ以外のモデルは，走行時よりも乗り降りする際に固定さえできていればよいと
いうものであったが，それでは走行時の障害を考えたとき危険であると判断した．そこで，
障害が生じた際でも簡単な操作であり，かつ停止したときに利用者の危険が伴わないことを
モデルを考える上での注意点とした．まとめると，このモデルには乗り降り時には足場のよ
うな本体ごと固定し，かつ自転車のスタンドのように取り付けられるものであること．また
その固定を行うスタンドは操作が簡単でかつ急に利用してもスタンドや床を傷つけない形・
大きさ・素材であるもの．これに考えの近いモデルであった発着場を制作する段階では，置
き型を製作する方向に決定していたため足場とハンドル両方を固定したモデルは，ハンドル
固定の製作時の案の一つとして挙げられた．
図 5.35 タイヤを除き Selfi 本体を抑えた場合
今年度の活動では，試作品モデルの考案のみしか行えておらず，詳しい設計図の作成からモ
デルの作成，テストまでの段階に進めることができていないため，今後の活動の一つとして
加える必要がある．試作品モデルの案を考案するにあたり注目したのが， Selfi に取り付け
るものなのか，発着場のように外側に置く形のものなのかということと， Selfi が走行する
上で邪魔な存在にならないかということである．前者は発着場作成時にも気にかけていたこ
とであるが，ハード拡張物を置き型にするか Selfi に直接取り付ける形をとるかということ
で，この 2 つにはそれぞれ大きな特徴がある．まず置き型の方だが，こちらは Selfi に取り
付ける必要がないため，サイズや形の自由度が大きく，今回のようなハンドルを支えるとい
う点で大きな力を出せるものが作りやすいというメリットがあるが，その分場所を必要とし
たり， Selfi の置く場所が限定されてしまうというデメリットがある．それに対し Selfi に
Group Report of 2012 SISP
- 90 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
直接取り付ける形の方は，直接取り付けられる分置く場所を考える必要もなく一見便利な
点しか見られないが， Selfi のような既製品に新たに付属品として拡張するには重量，サイ
ズ，バランスといった走行だけに限らず Selfi そのものの構造の仕組みを意識して製作して
いかなければいけなく，またそれに応じた技術も必要とされる．そして後者にあった Selfi
の走行する上で邪魔にならないもの．こちらは， Selfi に乗らないときに固定しておくもの
で，かつ発信時にはそれが走行上全く問題にならないという役割を果たせるものという意味
である．今回は発進時のみではなく， Selfi から降りるときにもハンドルが固定され，安全
に Selfi から降りることができるようなものを想定しているため試作品の段階でも非常に困
難なものになるであろうとモデルの考案作業が難航していた．しかし，いくつか試作品の作
成へと進む段階のものが挙げられた．その中の一つとして， Selfi のハンドル支柱の下層部
分を左右から挟み込む様にハンドルを固定する仕組みのものが挙げられる．これは Selfi に
直接取り付ける形のものであり，発進時到着時には Selfi に乗っている人の足で操作するこ
とが考えられていた．しかし挟み込む構造，それを成し遂げられる材質となるのは鉄のよう
な金属であるということから作業工程，時間の都合上今年度で作成に至ることができなかっ
た．その他にも手すりの役割とハンドルを固定する役割を備えた置き型のものを考案した
が，これも先程のものと同様に作業へ移行することができなかった．これは，大きく場所を
必要とするがその分発着場としての役割も担う可能性があるため有用なモデルとして取り上
げられた．
今年度の活動の中でこの課題は試作品の作成へと移行できなかったという大きな反省点が
ある．しかし，その分この Selfi への乗り降り時のぐらつきの改善，不安感を失くすという
課題の重要性は大きく，ハード拡張としても大きな必要性を感じられるものであった．特に
乗り物を扱う初めと終わりの段階を補助する拡張なため，次年度の活動時には優先的に取り
掛かる必要性があると考えられる．
（※文責: 仲田健太郎）
走行時の警告音
Selfi を学校内で走行させると，Selfi 本体からの小さい音量の駆動モーター音がわずかに
聞こえ，これが人に Self の接近を感じさせる不安があった．人が Selfi の接近に気づかない
と，衝突などの恐れがある．そこで，人が Selfi の接近に気づいてもらえるような仕組みが
必要と考えた．
検討
室内空間において走行する乗り物についてインターネットを使用し調べていくと，空
港で使用されている人荷物運搬用モーターカート（図 1）があることが分かった．この
乗り物は，空港という屋内で人がたくさん歩いている空間で走行する．そして，自分の
存在を「報知音」を鳴らしながら走行することよって，周囲の人々に自分の存在を知ら
せる仕組みを搭載している．そこで，前例の人荷物運搬用モーターカートと同様に室内
空間で，また，たくさんの人がいる中で走行する Selfi にも，Selfi の接近を周囲の人に
気づいてもらえるような接近報知音の搭載を検討した．
接近報知音の有用性の実験
搭載の検討にあたり，本当に，動いている乗り物から発せられる音が周囲の人への Selfi
の接近を知らせるものであるかについて，接近報知音の有用性の実験を実際に行った．
本実験は，2012 年 10 月 26 日の 14:50 15:50 の間に行われた．用意したものは，ビデ
Group Report of 2012 SISP
- 91 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
オカメラ，三脚，Selfi，メモ帳，音楽を鳴らす媒体，音楽データ（今回はロンドン橋）で
あった．実験にあたって参加した人は，まず被験者は１人，次に実験者は Selfi 搭乗者
1 名，記録用ビデオを撮影者 1 名，Selfi と被験者との距離を測る者 1 名の 3 名であっ
た．また，これらの被験者および実験補助者は，当プロジェクト学習ハード班所属メン
バーで交代しながら行った．実際に行った手順を以下に箇条書きで示した．
1. 6 人のそれぞれが Selfi に乗り１メートルを何秒で走行するか計測した．
2. 走行するのにあたり最も平均的に走行する人を被験者とするのが適当と考え，6 人
の 1 メートルを走行するのにかかった走行時間の平均を出し，平均の値に最も近い
人が今回は Selfi に乗る人とした．
3. Selfi に乗る人は固定し，被験者は残りの５人を交代しながら行った．
4. 被験者は Selfi に背を向けて立つ姿勢をとり，Selfi が遠くから近づいてきて，危険
と感じたときに手を挙げるよう指示した．Selfi は被験者の手が挙げられたことを
確認しだいすぐに Selfi を停止させた．
5. Selfi から被験者のかかとまでの距離を測った．
6. これを被験者 5 人分繰り返して行った．
7. 1 回目は Selfi の走行音のみで被験者に接近し，2 回目は Selfi の走行音に Apple
社の iPhone に音楽データを入れて，その媒体から音楽（オルゴール）を鳴らして
実験を行った．
．
実験結果
実験結果は，上の表 1 のようになった．メロディーを鳴らすと，鳴っていない時より
被験者
Selfi のみ
Selfi ＋接近報知音 距離の増減
1
250
400
150
2
550
700
150
3
450
450
0
4
225
600
375
5
300
550
250
表 5.1
実験結果の詳細
も，被験者全員が 0∼+375 メートルの範囲で距離が伸びた．
考察
本実験によりメロディを鳴らしながら人に接近するほうが Selfi の存在を周囲に示すこ
とが出来ることがわかった．よって，接近報知音について有意性を確かめることが出
来た．
その他
本実験を通して感じたこととして，音楽が常に鳴っているメロディのようなものでは，
常に音楽が鳴っているため音に順応し，無意識に注意を引くものではなくなりそうと
いった意見が実験参加者の中から出た．
本プロジェクトで取り組んだ内容
音といってもたくさんの要素があるが，本プロジェクトで取り組める範囲には限りがあ
るため，どんな仕組みで音を鳴らすか，鳴らすタイミングはどうするか，どんな種類の
Group Report of 2012 SISP
- 92 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
音を鳴らすか，どのくらいの音の大きさで鳴らすか，の 4 つの観点に絞って接近報知音
の検討を行った．
音を鳴らす仕組み
まず，音を製作する前に，音を鳴らす仕組みづくりが必要であった．私たちは，2
つの音を鳴らす仕組みを検討した．1 つ目は，Selfi 本体の制御を行っている基盤に
は，小さなスピーカー（図 2）が付けられている．このスピーカーを使用して音を
鳴らす仕組みを検討した．2 つ目は，Selfi 本体とナビゲーションを行う Android
端末との連携を行う ADK （詳しくは項目 ADK 参照）を使用し，Android 端末
（図 3）側で音を鳴らす仕組みを検討した．検討にあたり，前者後者のメリットデメ
リットについて考えた．まず前者のメリットは，新たなハード装置を追加しなくて
も良いという点があったが，デメリットとして，スピーカーが小型であり，また基
盤に付けれられているもので鳴動できる音の自由度が低いことが想定された．鳴ら
すための新規のプログラム既存の Selfi 制御をするためのプログラムに介入するこ
ともきわめて難しいことが考えられた．次に後者では，メリットとして Android
端末を使用することによって様々な音の形式に対応でき，鳴らす音の自由度が高く
することができることが予想された．また，Android 端末の音量についても自由
に調整可能であり，また音量が不足する場合も外部出力端子を使用し Android 端
末本体に別のスピーカーを繋げ，対応できそうであった．デメリットは，大きな障
壁になるようなものは特になかった．それぞれのメリットデメリットについて検討
した結果，後者の採用することに決めた．また，具体的な Android 端末から音を
鳴らすしくみについては，製作中のナビゲーションアプリの ALEFUN の一部の
機能として盛り込むことにした．
鳴らすタイミング
2 つ目として，音を鳴らすタイミングについて検討した．常に接近報知音を鳴ら
し続けるか，適宜必要時に鳴らすかについて検討した．まず走行時に常に接近報知
音を鳴らすことは，常に周囲に Selfi の存在を知らせることができる．しかし，音
の大きさや種類方向などによっては，ただの騒音にもなりかねないため，注意も必
要である．適宜鳴らす場合は，常には Selfi の存在を知らせることができないため
万が一接近報知音がなっていない際に Selfi が人に近づくことがあれば，Selfi の存
在に周囲の人が気づかずに事故が起こる可能性が，常に鳴らす場合に比べ高いと考
えた．そこで，常に接近報知音を鳴らす方針に決定した．
種類
3 つ目として，音の種類について検討した．接近報知音は，さまざまな騒音にか
き消されることなく，聞こえる必要がある．ただし音量を大きくすればいいかとい
うとそうでもない．音量が大きいと騒音源になる可能性があり，学校内で使用する
ため配慮が必要である．つまり，必要最小限の音量で不快にならず聞こえる音 を
提供するといったことが大切になってくる．音量については別の項で記すことと
し，ここでは音の種類について記す．
音の種類を検討していく中で特に「周りの注意を引くが，不快ではない音」とい
うものを目標として，この接近報知音の音の検討行った．周りの注意を引くが，不
快ではない音というのは単に音を大きくすれば達成されるものではなく，人間が音
をどう感じているかについての心的な部分が深く関わっており，実験の経験などを
Group Report of 2012 SISP
- 93 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
参考に製作を行った．
まず，周りの注意を引く音として主に，拍間隔と音の高さの 2 つの観点から検討
した．まず，音というのは上記に示した【接近報知音の有用性の実験】の問題点と
して人は同じ調で同じような音には耳が順応し注意力があまり向かなくなるといっ
た経験を実験によって実際に体感した．そこでまず，メロディのようにずっと鳴っ
ているものではなく，アラーム音のような「ピピピ」となる音とし，また同じ間隔
で「ピピピ，ピピピ，ピピピ」となるようなものではなく，「ピ ピピピ ピ ピ
ピ ピピピピ ピ」のようにランダムで鳴ることによって，同じ調で同じような音
で耳が順応し注意力があまり向かなくなるといったことを防ぐように工夫した．ま
た，音の高さについても低い音は安心や穏やかなイメージを感じることがある．今
回は接近を警告するために音を鳴らすことが目的のため，高めの音を採用すること
とした．また，学校内で接近報知音を鳴らすため，低い音は窓を突き抜けやすく講
義室の講義の妨げになる可能性がある．また高い音は遠くへ伝わりやすいため同じ
音量でも遠くへ注意を促すことが出来るという点からも，音の高さについて比較的
高めのホイッスルの音を採用することとした．次に，不快でない音とはどのような
ものなのか考えた．調べると，和音であるほうが不快でないといったデータが見つ
かった．しかし，不快であるかないかについても抽象的なものであり個々の感じ方
のため数値に表すのは難しい．そこでこの接近報知音について不快と感じるかにつ
いてのアンケートを今期のプロジェクトでは評価できなかったため，次期に実施し
ていきたい．
音量
4 つ目として，音の大きさについて検討した．Selfi は学校内を走行する乗り物
として使用するため，余りにも大きく周囲に迷惑をかける音量や小さすぎて周囲に
気づかれにくい音量であっても意義が薄くなるため音量に関して特にそのような
点に注意し検討した．実際に学校内を走行しどのくらいの音であれば良いか検討し
た．結果モールのような広い空間では 80dB 程度，講義室前の通路では 60dB 程度
の音がよいのではないかという結果に至ったが，これは音量の計測器がスマート
フォンのアプリケーションを Apple 社の iPhone のスピーカに近づけ測った値で
あり，あまり正確な値でないと想定されるため参考値として使うことにした．学校
内で使用するにあたり，講義室前の廊下で以上の参考値である 60dB を超える音は
講義室内に迷惑がかかることが予想される．よって，次の段階として鳴らせる音量
の最大音量をこの 60dB 程度とするような仕組みを製作，実現したい．それの次の
段階としては，位置情報や周りの情報を判断の上に自動的に接近報知音を制御でき
るようにしたい．
結果
本プロジェクトで製作した接近報知音についての有用性を確かめる正確な実験は行えな
かったので，詳しいデータなどは得ることが出来なかった．しかし，接近報知音によっ
て周囲の人に Selfi の存在を知らせるためには，何もない状態に比べて有用であるとい
う結果については【接近報知音の有用性の実験】で述べたような結果により有用性が確
かめられたので，この製作した接近報知音もなにも搭載しない状態と比較し Selfi の存
在を知らせるために有用なものを製作できたと考える．
（※文責: 泉拓哉）
Group Report of 2012 SISP
- 94 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
足型
前期に Selfi の 1 台目の組み立てが完了した後に，プロジェクトメンバ，担当教員で Selfi の
試乗を行った．そこで Selfi を室内で使用する上での問題点をハード拡張班で話し合った．
その後，ハード拡張班は全員 Selfi に乗りなれてしまい，初めて乗るときの問題点をこれ以
上自分たちで見出すのが難しくなった．そこで本学内の学生何人かに Selfi の試乗に協力し
てもらい意見をもらった．学生何人かに試乗してもらった後，再び問題点について話し合っ
た結果，人によって立ち位置がばらばらであるという結果が分かった．立ち位置がばらばら
であると Selfi の圧力センサを適確に感知させることが難しくなり危険になってしまう，ま
たヒールの靴をはいた女性が Selfi に乗る場合，正しく圧力センサを感知させることが難し
いという新しい問題点があがり，その問題点を解決しようと考えた．
問題点の解決プロセスの前に Selfi の運転の仕方と圧力センサについて少し説明する．
Selfi は片足をステップに乗せながらハンドルについているボタンを押し，ランプが点灯す
る位置になるようにハンドルを前後に傾ける．ランプが点灯したら，車体はバランス制御中
に入るためもう片足を乗せ自分でバランスをとる． Selfi は重心移動で前後に動く．つま先
に力を入れる感じで少し前に重心を移動すると前に前進し，かかとに力が入るように後ろに
重心を移動すると， Selfi は止まる．そのまま重心を後ろにすると Selfi は後退する．車体
ステップには 4 つの圧力センサがあり片足に 2 つずつ縦についている圧力センサの上には
黒いゴムシートがのっているため，圧力センサの位置を直接目で見ることはできない．以下
が実際の Selfi の圧力センサの写真である（図??）．
図 5.36 圧力センサー
この圧力センサで人が乗っているか乗っていないか判断を行っている．すべての圧力セン
サがオフになり，誰も乗っていない状態になれば Selfi は 2 秒後にバランス制御を停止する
仕組みになっている．
圧力センサをうまく感知できないという問題に対しての解決策として，はじめに 4 つある
圧力センサの位置が明確に分かれば正しい立ち位置が分かるのではないかと考え，黒いゴム
シートの上にテープで目印をつけた．圧力センサは足の踵と中足骨のところにあたるように
できている．しかし，乗る体制になった時に，手前についている圧力センサに合わせて足を
置けば問題はないのだが，奥のほうについている圧力センサにつま先などを合わせて足を置
こうとすると足が Selfi のステップからはみ出してしまう．すべての人が手前の踵側から足
を合わせて乗るかどうかは分からないため圧力センサの場所を直接指す方法はとらないこと
にし，足型を表示して立つ場所が分かるようにしようと考えた．
足型で表す場合，足型の大きさをどうしようかと考えた．大きさが大きすぎても小さすぎ
Group Report of 2012 SISP
- 95 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ても合わせにくく足型を表示した意味がなくなってしまう．日本人の 20∼24 歳の男性の平
均の足の長さは 25.4 cm ，女性の平均の足の長さは 23.2 cm である．今回は，このデータ
を利用し，足型のサイズを男性の平均に近い 25 cm に設定した．
その後，足型の形のサンプルを 2 つ作成した．1 つめは 25 cm の靴の形に合わせて作成
したもの，2 つめは本大学の医務室にある身長計の足の形を参考に作成したものである．今
回は 2 つめの身長計の足の形を参考にしたほうを採用した．
足の形が決まったあと，どのように制作するかについて考えた．でた案としては，黒いゴ
ムシートの上にスプレーで吹きかけるか，黒いゴムシートの上にテープを張り付けるかの 2
つの案がだされた．黒いゴムシートは，でこぼこしていて滑りにくいような形状になってい
る．そのため，スプレーを吹きかけるとなるとでこぼこしているためうまくスプレーを吹き
かけるのは難しいと考えた．またテープであれば何回もやり直しがききやすいという点から
今回は黒いゴムシートの上にテープで足型を作成することにした．
ゴムシートが黒色である為今回は見やすいよう反対色の白で足型を作成した．そして作成
後 1 台目 Selfi に試験的に足型のシールを張り付けた（図??）．
図 5.37
足型シール貼り付け後
その後，学生数名に協力してもらい足型について使いやすいか使いにくいか実験を行い
確かめた．実験は本大学の学生 3 名に協力してもらった．実験の方法としては，被験者に
Selfi の乗り方の説明を行う．その後，被験者には補助などはせずに自分で Selfi に乗っても
らい，自由に走行してもらう．走行後に，質問形式で足型について，乗る前に足型を確認し
たか．足型があったほうがいいか．について質問を行う．という方法で行った．結果として
被験者の 3 名全員が乗る前に足型を確認してから搭乗し，足型があったほうが目印があって
よいという回答を得ることができた．また，足型を作成後は，足がばらばらになることがな
く全員上手に圧力センサを感知させることができていた（図??）．
この結果から足型の作成は成功したが，実験の人数，被験者などの条件を変えて改めて実
験を行う必要がある．しかしこれは次年度の活動へ持ち越しとした．また，その後ゴムシー
トの上に足型のテープを張ると，その部分が滑りやすくなるのではないかという問題点も浮
かんできた．そこで，テープの素材をはじめに使っていた素材よりも滑りにくいものを選
び，改めて足型の完成とした．その後は 2 台目 Selfi にも足型のテープを張り，すべての項
目を終了とさせた．
（※文責: 黒坂愛）
Group Report of 2012 SISP
- 96 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 5.38 足型シール貼り付け Selfi 使用
グループでの活動
5.5
5.5.1
ナビシステム班
ここでは施設内案内を行うためのナビゲーションシステムに対してナビシステム班が行なった作
業内容を記す．ナビシステム班はナビゲーションシステムを構築する上で必要となる探索機能をダ
イクストラ法と呼ばれるアルゴリズムを元に機能実装をするルート teamA とルートの全パターン
を学内の特性に合わせて構築するルート teamB の二つに別れて活動を行なった． 活動内容につい
ては以下の通りである．
9 月 休み明けの初顔合わせ後期で前期活動の反省会を行い，前期プロジェクトにおける
問題点や中間発表で指摘された問題について話し合った．そして，その改善案を話し合い，
各自のタスクの進行具合を確認後，後期の活動に反映できるよう後期活動内容を修正した．
ハード拡張班から夏季休業中に部品を紛失してしまい他の作業が送れるとのことや連携する
手法として取り組んでいた Android Open Accessory Development Kit(ADK) の進行が思
わしくないとの報告をうけ，先生からは IMES の規格が変わったため再び貸出依頼をして
いるが到着が 10 月程になるとの連絡をうける．そこで後期には並行して IMES の作業を行
う予定だった人員をルート構築に回し，また作業が遅れていた ADK にも人員を回す事とし
た．構築の手法として手動で全ルートパターンを計算して用意するかカーナビなどのように
アルゴリズムを用いるのが望ましい．そこで開発手法に合わせそれぞれが所属したい班の
希望にあわせ，各人員の所属する班を決定した．アルゴリズムで構築を試みるのがルート
teamA，手動で予め探索して手法をとるのがルート teamB となった．前期で構築した機能
の改善は担当したものが各自が行うことにした．
10 月 本プロジェクトが想定している IMES は再規格制定中のため納品が 11 月後半になると
の事だった．そのため IMES は評価実験に留めルートの完成と他の作業を優先することに
決定した．10/5(金) に市立函館高等学校より学生が訪問があるとのことなので市立函館高
等学校の学生への発表にむけての資料や，アンケート等の作成を開始した．そして訪問して
くれた学生に対し，プロジェクトの概要説明， Selfi の試乗，ナビアプリの体験などを行っ
た．その後，プロジェクトに対するアンケートをとった．その結果非常にわかりにくいイン
ターフェースだったということだったので改変することに決定．UI 担当のタスクを調整し
改善してもらうことにした．
Group Report of 2012 SISP
- 97 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ルート teamA
室内に対応した目的地までの探索がないためカーナビなどに搭載されて
いる探索アルゴリズム，ダイクストラ法を研究．ネット上などにある PC 上のサンプル
などを元に Android 側への移植を試みる．
ルート teamB
学内における探索ノードの計測およびルートの計算．そして探索後の画
像などの素材の準備．
11 月 各自ができた機能をでき次第全体のアプリとして組み込んだ．11 月中旬には，新技術開発
サロンに対し成果報告会を行うので，発表資料等の制作を開始した．同時に，最終報告に向
けてのポスターや発表資料等の制作も開始した．なお，11 月下旬から，12 月度の活動は最
終報告に向けた発表準備や報告書作成作業に入ったので，機能拡張と UI 調整の人員を残し
最終発表で発表するスライドとポスター製作に人員を分け活動した．
12 月 ルート teamB の方は全パターンの素材が間に合わなかったためルート teamB のダイクス
トラ法によるルート案内を採用した．成果としては音声認識，音声認識，リスト検索を用い
た屋外ナビゲーション，位置情報と紐づけは間に合わなかったもののダイクストラを元にし
た屋内ナビゲーション，そして RSSI 方式による位置算出，及び IMES による位置取得方法
を最終発表成果物として提出した．その後，成果物と話し合いの内容に合わせポスター，ス
ライド製作，最終発表を行った．
（※文責: 小野修都）
5.5.2
ADK 班
ここではハードとソフトの連携を実現に向け ADK 班が行なった作業内容を記す．ADK 班は
Android Open Accessory Development Kit(ADK) を用いてハードとソフトの連携の仕組みを実
現すべく活動を行なった．
活動内容については以下の通りである．
10 月
ADK 班としての活動での目標は前期の段階で制作を進めてきたナビアプリケーションと
Selfi の相互通信を可能とし，連携させることである．
今期の目標としては， Selfi のバッテリー残量を Android 端末で受け取りその情報を可視
化すること， Android 端末で音声認識を行いハード側でアクションを起こさせることを目
指した．これらのことを実現させるために，まず， Eclipse のプラットフォームやターゲッ
トなどの環境をグループ内で統一し， Selfi の上位マイコンとする Arduino にグループメン
バー全員が書き込みができるような環境構築を行った．しかしながら，この環境導入は難航
した．環境を統一させるメンバーは全員で 4 人いるのだが，プロジェクト学習当初に導入を
行った Eclipse のバージョンの違いや インストールされた Arduino のソースコードを書き
込むソフトウェアのバージョンの違いなどの問題で統一までに時間がかかった．
11 月
環境導入後はプログラミングの役割を，システム構築，プロトタイプ組み込み，マイコン
組み込み， Arduino のプログラミングのように分担し，担当の各メンバーが取り組んだ．
システムの構築では，各 Android 環境で ADK を用いた音声認識や Selfi のバッテリー
残量を受け取りなどのプログラミングを行った．
次にプロトタイプ組み込みでは，システム構築で完成した機能のソースコードをプロジェ
Group Report of 2012 SISP
- 98 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
クト学習当初から開発を続けていたプロトタイプへの組み込みを担当した．ここで気をつけ
なければならない点として機能をどのタイミング，どの画面でイベント処理を行うかを考え
組み込みを行わなければならない点であった．
次に，マイコン組み込みでは， Selfi 自体にマイコンを追加し Android 端末から Selfi に
操作ができるように作業を行った．この部門では，回路図を理解し、作成しなければならな
いため専門的な知識が必要不可欠であった。
最後に Arduino のプログラミングでは， Selfi 自体に追加したマイコンにプログラミング
を行った．使用言語これまで使用していなかったが C++ であり，新たに学習しなければな
らなかった． C++ を学習し Arduino にプログラミングを行い Android 端末と Selfi との
相互通信の一端を担う作業であった．このような活動によって Selfi のバッテリー残量の情
報を可視化，音声認識による LED の点灯の機能を持たせることに成功した．
また，11 月中旬ごろから ADK 班として活動をしてきたメンバーを最終発表で展示をす
るポスターを作成するグループや最終発表で説明するためのスライドの作成のグループに配
属し，それぞれで活動を行った．
12 月
11 月の時点で、10 月に目標として掲げていた Android 端末と Selfi の相互通信による連携
を Selfi のバッテリー残量の情報を可視化，音声認識による LED の点灯の機能を持たせる
ことに成功した事によって概ね達成できたため，11 月中旬より作成を行なってきた最終発
表用のポスター，スライドの作成に取り組んだ．後期に新たに出てきた項目であったため，
どのような位置づけなのかや概要などを話し合う必要があったが，各メンバーがの成果をま
とめてきたこともあり，円滑に最終発表用のポスター，スライドの作成が行われた．
（※文責: 犬塚悠人）
5.5.3
Selfi 拡張班
ここでは施設案内に使用するための乗り物の Selfi に対しての Selfi 拡張班が行なった作業内容
を記す．
Selfi 拡張班は Selfi の安全性を向上させるために， Selfi 自体への改造や外付けでの拡張を主に
行なった．活動内容については以下の通りである．
Selfi 拡張班は以下のように活動を行なった．
9月
後期最初の活動で前期活動の反省会を行い，前期プロジェクトにおける問題点や中間発表で
指摘された問題について話し合った．そして，その改善案を話し合い，後期の活動に反映で
きるよう後期活動内容を修正し，それとともに班分けを一新した．なお，班分けを一新した
さいに各活動計画の詳細についても改めて振り分けした．この前期反省会の場において，夏
季休業期間中に行った活動内容などの報告も行った．この時に，Sslfi の電子部品を夏季休業
期間中に紛失してしまったので，その部品を株式会社エフ・アイ・ティーへと発注した．な
お，改めて班分けをしたハード拡張班において， Selfi の安全性の向上のためには，どのよ
うな外部的拡張が必要かの案出しを行い，どの案が実現可能かの検討会を行った．10/5(金)
に，市立函館高等学校より学生が校内見学の一貫としてプロジェクトの見学に来るので，そ
の際の学生に向けた発表人員の選定を行い，同時に発表資料の制作人員の振り分けも行っ
た．Selfi の安全性向上のために，タイヤカバーを作成することを前期で決定していた．そ
Group Report of 2012 SISP
- 99 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
の制作のためにタイヤカバーの図面を夏季休業期間中から作成しており，手書きでのタイヤ
カバーの設計図を完成させた．その完成した設計図を新技術開発サロン様へと送り，制作を
依頼した．
10 月 市立函館高等学校の学生への発表にむけての資料や，アンケート等の作成を開始した．9
月度時点では，タイヤカバーは新技術開発サロン様へと制作を依頼していたが，制作が厳し
いとのことなので，プロジェクト内で制作することとなった．制作道具に工房に新しく設置
されたレーザーカッターを使用することとなった．レーザーカッターの使用のために，設計
図を画像ファイルで制作しなければならない．そのために cad ソフトを使用し，設計図を
作成することとなった． Selfi の接近を知らせるための報知音を搭載することに決定し，人
間の不快にならないような音はどういうものかの勉強を開始した．仮音源を決定し，学内で
使用できるかどうか報知音を出しながらの走行実験を行った．10/5(金) 市立函館高等学校
より学生が訪問．学生に対し，プロジェクトの概要説明， Selfi の試乗，ナビアプリの体験
などを行った．その後，プロジェクトに対するアンケートをとった．そのアンケートから，
Selfi に乗る際に発進時のぐらつきが怖いとの意見が得られたので，その問題解決に向けて
の案出しを行った．その案の中から発着場 ( Selfi に乗るための土台) を制作することを決
定した．モデルの制作を開始し，加工のしやすさからダンボールでモデルを作成し，試作品
を完成させた．試作品が完成したのち，実際に制作するさいには素材などをどうするかの検
討を行った．さらに，アンケート結果からハンドルのぐらつきも危険だという案もあったの
で，その問題解決のための検討を行った． Selfi に報知音を搭載するために報知音なしの場
合，どの程度接近するまで気づかないかの実験を行った．さらに，その実験結果から分析を
行い，音量を決定した． Selfi に乗り込む際，足を乗せる場所がわからないとの意見が出た
ので，足乗せる場所の目印として，足型の検討や制作を開始した．
11 月 10 月に引き続き，タイヤカバーの設計図を cad ソフトによって制作．設計図が完成したの
ち，レーザーカッターによって試作品の制作開始した．試作品が完成したのちに実際に靴紐
が巻き込まれるのかどうかの実験を行った．発着場が 10 月時点で完成していたので，試作
品を利用して実際に制作する際の設計図の制作を開始した．それと同時に，発着場モデルを
使用し， Selfi に乗りやすいかどうかの実験を行った．その際に行ったアンケート結果から
新たな問題も得られたので，その問題解決に向けた活動を行った．報知音の制作が終了した
ので，改めて報知音を鳴らしての学内走行実験を行った．株式会社エフ・アイ・ティーへと
発注していた Selfi の紛失部品が届いたので，作成中断していた 2 台目の Selfi の組立作業
を続行した．12 月中旬に，新技術開発サロン様に対し成果報告会を行うので，発表資料等の
制作を開始した．同時に，最終報告に向けてのポスターや発表資料等の制作も開始した．
なお，11 月下旬から，12 月度の活動は最終報告に向けた発表準備や，報告書作成作業に
はいったので，班関係無く活動を行った．
12 月 2 台目 Selfi が完成した．しかし，不具合が多分に見つかったので，調整作業を開始した．
調整中に 2 台目の基盤と 1 台目の基盤を付け替えた．のちに，改めて 1，2 台目の Selfi のパ
ラメータを調整した．発表前日に Selfi 2 台とも完成した．12/9(水) 最終報告回．12/9 以
降は最終報告書作成活動行った．
（※文責: 岩山拓哉）
Group Report of 2012 SISP
- 100 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
第6章
後期結果
成果
6.1
6.1.1
ナビシステム班
IMES
Android 側で IMES のシステムを使用可能なことを確認しアプリ上に反映する方法を発見
した．Bluetooth を使用しアプリ側が以下のようにコマンドを送ることで準天頂衛星シス
テム（初号機 みちびき）に対応していないチップが載っていても IMES 受信機が受信した
データを Android に送ることができる．
@SOM400 1000 3001<LF>//
#SIF 1<LF>// IMES 信号サーチ周波数オフセット割り当て
#SIC 4<LF>//IMES 信号受信チャンネル数割り当て
#SIS 2<LF>//IMES サーチモードの設定
#NM GPGGA<LF> IMIMP//GPS や IMES の受信結果を情報を出力
@SR<LF>//IMES 受信機をホットスタート
もう一つとの方法では NEXUS7 などのように最初から対応している端末を使用することで
ある．こちらの方式ではアプリ，ハード特に設定をすることなく受信を Google マップで確
認することができた．しかし中には対応していないアプリもありこれはアプリ側に実装され
ている位置取得方法の違いによるものだと考えられた．
（※文責: 小野修都）
ルート teamA
ルート A 班では，最短経路探索を行うアルゴリズムであるダイクストラ法の構築を行い，
そのアルゴリズムを用いることによりアプリ上でルート表示を可能にした．
ダイクストラ法
屋内ナビゲーションをする上で必要な最短経路探索を行うアルゴリズムである．アプ
リ上でナビゲーションを行うとき，スタートとゴールを設定することで，このアルゴリ
ズムを介し画面上に最短経路が表示される．
ルート表示
アルゴリズムとは別に，探索した結果を反映したルート表示を行うプログラムを作成
した．学内地図の上に，アルゴリズムで最短経路を探索した結果を描写することを可能
とした．当初の目標は， Wi-Fi や IMES から取得した位置情報を現在地とし，その現
在地をスタートに設定．さらに，ゴールを複数の部屋から選択することにより，その最
短経路を求めるものであった．しかし， Wi-Fi からの位置情報の取得は不安定であり，
約 30 メートルの誤差があった．そのため，アプリに実装することは困難であった．ま
た， IMES は導入が最短で 11 月となったことを受け，評価実験するに留まり，こちら
もアプリに組み込むことは困難となった．代替案として上げられたのが，スタートと
Group Report of 2012 SISP
- 101 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ゴールをリストから選択してルート表示を行う方法であった．この方法で実装したこと
により，最短経路探索を視覚化することが可能になった．
（※文責: 町田浩平）
ルート teamB
成果としては，本学の特徴的な構造から限られたルートしかないことを発見し，アルゴリ
ズムを構築，そこから屋内ナビアプリケーションを実装，屋内ナビアプリケーションの UI
の設計と実装，SQLite によるデータベース構築，地図上に表示するルートの画像の作成な
どを行った．
アルゴリズムの構築
今回は，3 階のみのナビアプリケーションを作成することにした．その理由としては，
階層変 化に対応するのが困難であったからだ．本学の特徴的な構造から 3 階を 10 個
のエリアに分割すると，ルートが限られた形にしかならないことに気がついた．また，
Selfi という乗り物が通れる通路でなくてはならないという点からルートを検討する際
に，人通りが少なく，道幅が広い道に限定した．なので，出発地点と目的地の組み合わ
せから全部で 72 パターンしか存在しないことがわかった．よって，力任せな方法では
あるが，72 枚のルートの画像を用意して出発地点と目的地の組み合わせからルートの
画像を地図上に表示するという方法をとった．
屋内ナビアプリケーションの実装
今回は，Android 端末対応の屋内ナビアプリケーションを実装した．開発は各自の所
有のパソコンに eclipse をインストールして，各自分業で行い，最後に結合し，干渉し
ている箇所を修正した．Android 端末を Selfi に最終的には搭載するので，アプリケー
ションの画面は横向きで固定した．そのほうが，Selfi の運転中でも見やすいと判断し
たからである．
UI
今回の屋内ナビアプリケーションの UI は，本学に初めてきた人，加えて，誰しもが
パソコンやスマートフォンといった情報機器に慣れているとは限らないので，誰にでも
扱いやすいように利用者を選ばないゆような UI を設計をした．具体的には，ボタンを
大きめに設置したり，部屋を講義室，教員室，事務など大まかな 6 つのカテゴリーに
分類した．これによって，本学に初めてきた人は，この複雑な設計に戸惑う人が多いの
で部屋名でも検索することができる．探しやすいようにした．また，文字検索機能をメ
ニューバーから開いて使えるようにしたので，部屋名がわかる人でも快適に扱うことが
できるように配慮した．
SQLite によるデータベース構築
データベースは SQLite を用いて作成した．今回は 3 階のみに対応したナビアプリ
ケーションだったので，3 階にある部屋の情報を格納した．SQLite を用いたのは，後
に，3 階以外の階層の情報に対応させる際，拡張しやすいと考えたからだ．格納した情
報は階層情報，カテゴリー情報などである．また，SQLite を用いたことによって，文
字検索機能も導入することができた．文字検索機能は，部屋番号や部屋名など，ある程
度の文字が似ていれば，検索にひっかかるようにした．
地図上に表示するルートの画像作成
ルートの画像を作成するにあたっては，Adobe Illustrator CS6 を用いた．前期に作
Group Report of 2012 SISP
- 102 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 6.1 データベース使用済
成した地図も同様に Adobe Illustrator CS6 を用いていたからである．その地図の上
にグラデーションを使ってルートの画像を重ねて表示した．全部で 72 枚のルートの画
像を作った．画像を作るにあたっては，前期に作った地図と色がかぶらないことと，誰
にでも見やすい大きさで，わかりやすいものを作るように重点を置いた．最後に私達，
teamB が作った屋内ナビアプリケーションはアルゴリズムの関係上，本学にしか使用
できず，応用性に乏しいため，teamA が作ったダイクストラ法を用いた屋内ナビアプ
リケーションのナビゲーション部分に私達が作った UI 部分とデータベース部分を組み
合わせることで，屋内ナビアプリケーションの完成に至った．前述のように，本学の 3
階限定なので，階層変化には対応することができていない．また，現在地も自動的に取
得するのではなく，利用者の入力方式となっている．
図 6.2
ルート生成図
最後に我々，teamB が作った屋内ナビアプリケーションは本学にしか使用できず，応用
性に乏しいため，teamA が作ったダイクストラ法を用いた屋内ナビアプリケーションのナ
ビゲーション部分に我々が作った UI 部分とデータベース部分を使って屋内ナビアプリケー
ションの完成に至った．前述のように，本学の 3 階限定で，かつ階層変化には対応していな
い．また，現在地も利用者の入力方式となっている．
（※文責: 伊東翔）
6.1.2
ADK 班
ADK 班では，本プロジェクトが作成しているナビゲーションアプリと Selfi を連動させるシステ
ムの構築を行った．使用している技術は Android Open Accessory Development Kit(ADK) で試
験的に音声認識によるライト点灯，Selfi のバッテリー表示を実装している．使用している基盤は
Arduino である．まず Selfi の鉛蓄電池の残存電力量を Android 端末側で確認できるようにするに
Group Report of 2012 SISP
- 103 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
は鉛蓄電池から Arduino に電圧をかけて A/D コンバータを用いてアナログ値を計測する必要が
ある．そのまま電圧をかけては過剰な電圧であるため Arduino に深刻なダメージを与えてしまう
ことになる．そこで適切な値まで降圧する回路を作成した．その後，鉛蓄電池の残存電圧を計測す
るための回路を完成させた次に Android 端末に音声入力により USB ライトを点灯させることが
新たに目標として設定し，機能実装に向け取り組んだ．Android Open Acessory protocol(AOA)
と呼ばれる通信プロトコルを Android，マイコン両方に受信処理，出力コマンドごとのデータ仕
様，送信処理を作成したい回路にあわせて記述し，暗いと言われたら 5V の電圧の電流を流すよう
に記述している．それに応じて電子回路を対応させ更に拡張させ，完成後ナビシステム班のアプリ
と組み込みを行った．Arduino は Selfi に取り付ける方法がなかったためドリルで鉄板にねじアナ
を開けケーブル接続後プレートに固定した．
6.1.3
Selfi 拡張班
本プロジェクトでは施設内案内を行う乗り物に Selfi を採用した．前期の活動の中で Selfi の組
立が完了し，そこから試乗を行い，組み立て前に予測していた危険性と組み立て後に新たに発見さ
れた危険性をまとめ，それに対する解決策をハード拡張班で考えた．
安全性に関しては， Selfi が施設内で走行するという状況のみならず， Selfi に乗ること自体の
こともふまえた安全性を向上させるための Selfi 拡張を考えた．拡張を行う際に，まずプロジェク
トメンバ内で試乗から得られた Selfi の特徴や施設内で走行するにあたる危険性を考えた．そこか
ら得られた問題を解決するための拡張を考え，またその拡張の必要性とそれが本当に解決へつなが
るかどうかの検証実験やアンケート調査を行った．必要性の確証が取れてからは，プロジェクトと
して課題の設定，タスクの設定を行い製作作業へと移行した．そして後期の活動の中でハード拡張
班は， Selfi の 2 台目の組立をはじめ，発着場の製作，タイヤカバーの製作と取り付け， Selfi の足
場を示すものの製作や Selfi のハンドルを固定するものを製作，そして Selfi に接近音をとりつけ
るといった拡張活動を行った．それぞれに関して，後期活動の成果を以下に記す．
Selfi 2 台目組立
前期で組立が完成した 1 台目の Selfi に続き，後期では 2 台目の組立作業に取り掛かっ
た．しかし，夏期休暇中にジャイロセンサや角速度センサといった電子部品が紛失し，後期
活動の始めに作業が止まってしまう事態となった．その後，新たに不足分の部品を株式会社
エフ・アイ・ティへ注文，また仕様の変更したジャイロセンサの回路を自作して製作を進め
ていった．
紛失した部品に関する問題が解決後は，組立作業を再開したが，その作業の中で圧力セン
サを 1 つ損傷させてしまった．しかし，圧力センサは片足に 2 つずつ，計 4 つから成ってお
り，走行上問題ないであろうと判断し，組立作業を進め Selfi 2 台目が完成した．
完成後に試乗を行ったが，走行上問題は発生しなかった．また，暗がりの中走行すること
をふまえ， Selfi に既製品の LED ライトを取り付けた．
発着場
1 台目 Selfi の組立完成後，ハード拡張班では Selfi を施設内で走行させるにあたる危険
性について議論した．そこで，まず安全に走ることに関し優先度を考え， Selfi に乗り降り
するところに注目した． Selfi は乗り降りするとき，足場となる場所が Selfi に設けられい
ないため，バランスを保ちながら乗り降りを行わなければならない．そのため，初めて Selfi
に乗るという人にとっては補助として近くで支える人が必要となる程，危険性が含まれる仕
Group Report of 2012 SISP
- 104 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
組みであった．これに関しては，実際に後期の活動の中で市立函館高等学校の生徒にアン
ケート調査を実施し， Selfi に乗り降りするときに恐怖を感じるという結果が得られた．
これらをふまえ，今回は Selfi に乗るときに補助となる発着場という足場になる台座を作
成した．これは試験段階のものということで素材もダンボール素材の板を重ね組み合わせた
ものとなっている．そして底面には厚さ 1mm のゴムシートを取り付け，滑り止めとして効
果を高めるものとした．完成後，発着場を用いた試乗を行った結果として， Selfi への乗り
やすさが増しただけでなく，タイヤに接触せず本体のみに接する作りのため，乗った直後に
バランスを崩したりして後退するのを防ぐ役割を果たしていた．Selfi への乗りやすさの向
上と後退を防ぐ Selfi 本体の固定の 2 点が発着場の主な成果であった．そのほかに，発着場
の製作を通して行ったアンケート調査だが，この調査から Selfi から降りるときの支えとな
る拡張，改善すべき問題が得られた．今回のアンケート調査では検証が十分であるとはいえ
ないため，さらに細かな条件や環境別に調査を行う必要があるという結果となった．そして
発着場の製作全体を通して Selfi の固定に関してさらなる課題が得られた．
ハンドル固定
1 台目 Selfi の組立完成，発着場の完成と試乗テストを経て，未だ完全に解決できていな
い問題が明らかとなった．それが Selfi の乗り降りするときに感じる不安定さやぐらつき感
であった．この原因となるのが，乗り降りする前に Selfi のハンドル部分が倒立したまま固
定されていないという状況にあった．そのため安全性を高めるためにも，ハンドル部分を固
定するものを製作することにした．
後期の活動では， Selfi に乗り降りするときにハンドルを固定し，なおかつ発進・到着時
にはその障害とならないものを製作することを目指した．形態としては外側からハンドルを
支える形と Selfi 自体に搭載する形問わずにモデルの考案をし，その結果簡易であるが設計
図の作成までで後期の活動が終了した．
走行時の警告音
Selfi 1 台目の試乗後， Selfi は電気モーターで走行するため走行音が非常に静かであるこ
とが判明した．このことから，施設内で Selfi が安全に走行するためには， Selfi の存在を
周囲の人に知らせる必要があるという結論に至った．後期の活動の中で，実際に警告音の必
要性を確かめるため，音を発しながらとそうでない場合での走行実験を行った．結果として
音を発しながら走行した方が周囲に存在を知らせやすいということがわかり， Selfi に警告
音を取り付けることが決定した．しかし，実験した場所や音の種類，音量など，これに関し
ては様々な環境における実験をさらに行う必要性もあるため，今後の活動では警告音の必要
性とどんな音を警告音として扱うかなど再検証していく必要が十分にあるという結果になっ
た．採用する音やタイミングに関しては多くの課題があったが後期の活動段階で決定した警
告音を Selfi に取り付けることができた．これは Android 上で音を鳴らす仕組みで，鳴らす
タイミングは走行中常に鳴らすものとした．
今回警告音となる音とタイミングの決定をするにあたり， Selfi に乗った人の存在を周り
の人に伝えられるかどうかを課題として活動を進めてきた．その中で今回決定した，走行す
る環境からは発生しにくい音で，かつ短く連続性のあるものは周囲の人へ警告することがで
きたという成果が得られた．しかし，警告音に気づくかどうかの実験には多くの課題が残っ
ているため今の段階の音とタイミングでは，完全に警告することができているとはいえな
かった．この問題に関しては，この音とタイミングによるテストをふまえた上でさらなる研
究が必要であるという結果となった． Group Report of 2012 SISP
- 105 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
タイヤカバー
Selfi へ新たに拡張を進めるにあたり，ハード拡張班では Selfi のタイヤがむき出しの状
態で，かつ乗ったときすぐ足の横に位置していることを問題視した．そこで，果たしてこの
タイヤが足に接触する危険性はないか，靴紐が走行中のタイヤに巻き込まれる危険性はない
か確かめるため，巻き込み確認の実験を行った．実験内容は，タイヤを回転させた状態の側
で靴紐が垂れた靴を置いたり，靴紐をタイヤと Selfi 本体の間の隙間に垂らしたりと，実際
にタイヤと靴紐が絡み合う危険性はあるのか確かめるというものであった．実験の結果とし
ては，靴紐が巻き込まれることはなく，タイヤと絡み合うこともなかった．しかし，この結
果から危険性が全くないということにはならず，万が一の可能性，そして Selfi のタイヤと
乗った人の足が接触する可能性を危惧し，タイヤカバーを取り付けることが決定した．製作
の過程としてはタイヤの寸法測定， CAD による設計図作成，材料の検討・調達，レーザー
カッターによりアクリル板の切断，組立という流れであった．タイヤカバーの材質としては
アクリル板を用いた．形状は半月型で足場とタイヤの間に仕切りを入れる形をとった．この
作成したタイヤカバーにより足とタイヤが接触する危険性も低くなり，より安全性の向上へ
とつながった．
足型
前期で完了した Selfi 1 台目の組立後の試乗を通して， Selfi の足場の位置を正しく捉え
ず，圧力センサが正確に反応しないことが見られた．構造上圧力センサは， Selfi の足場の
下に 2 箇所ずつ，計 4 箇所に設置されている．しかし， Selfi に乗るとき足場には黒色の
シートが敷いてあり，圧力センサの位置を確認することはできない．また，初めて Selfi に
乗る人にとっては足を乗せるこだけに意識がいき，多少なりともずれた位置に足を乗せるこ
とが多々見られた．走行が始まってからの状態において，圧力センサは片足のみ捉えていれ
ば走行上問題なく停止することもないが，我々は例えば走行中に Selfi の圧力センサが何ら
かの形で正確に感知せず，急停止する場合もあるであろうと考えた．そこで，正確な圧力セ
ンサの位置を乗る人へ伝えるためにも，足場に目印を設けることにした．結果，足型の印を
設けてからは Selfi に乗るときにどこに足を乗せたらよいのかを考える必要もなく，初めて
Selfi に乗る人でも自然と正しい位置に足を乗せることができたという結果が得られた．
この結果から，課題にあった圧力センサが正しく感知できる位置に足を乗せるための拡張
が完成し，乗るときに足の位置に迷うことをなくすという成果が得られた．
（※文責: 仲田健太郎）
6.2
各人の課題の概要とプロジェクト内における位置づけ
ナビシステム班
佐々木康祐
後期では主に屋内ナビのアプリケーション作成と最終発表会の発表者担当した．
10 月 10 月に入り前期で予定していた IMES の到着が遅れるといったことや，物品
の管理などに問題が発生したために本プロジェクトの概要や決まりなどを新たに考
え直すためのミーティングを行った．その後中間発表会の反省会を行った．中間発
表会と 8 月に行った公立はこだて未来大学オープンキャンパスの際に観客の方々
に書いて頂いたアンケートを集計し，どのような意見が出ているのかまとめた．そ
Group Report of 2012 SISP
- 106 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
の後その意見をもとに後期で改善しなければならない点を全員で検討した．また，
後期に残された時間内で完成させることができる目標に設定しなおした．Google
Indoor Maps が本学に対応しなかったので，本プロジェクトでナビゲーションシ
ステムの基礎を作らなければならなくなった．そこで位置情報班で議論を重ね，ダ
イクストラ法を用いた方法とパターンを用いた 2 つの方法で屋内ナビゲーションシ
ステムを構築することになった．私は屋内でのナビゲーションアプリケーションを
作成するためのチームの 1 つ， Team B のグループリーダを担当することになっ
た．このグループを担当するにあたり，まずはどのように現在地から目的地までの
最短経路出すか議論した．さらに，誰を対象にした最短経路を考えればよいのかと
いうことも同時に考えた．その後，ルートを検討するために，学内の構造の特徴を
抽出する作業を行った．この作業を行うことにより，学内の人通りや道の狭さなど
を客観的に知ることができ，最短経路を決定する際の参考材料になると判断したた
めである．
11 月 11 月には 10 月に整理した学内の構造の情報をもとにルート検討に入った．ま
ずは対象者，時間帯による人通りの量，その通路を通る場所の人の目的などを考慮
に入れてルートを決定した．ルートが決定したのち，チームの中でルート画像作成
者，ルート画像を学内の地図に重ねて表示する者，データベース作成者， UI 担当
者，既存のアプリケーションとの連携を担当する者と仕事を分担した．私はルート
画像を作成し，既存なアプリケーションとの連携を担当することになった．ルート
の画像は前期に私が作成した学内の地図を参考に通路の幅などを考慮して矢印を引
いた．この際地図の色と矢印の色がかぶらないようにし，利用者が見やすいように
工夫をした．72 枚分のルート画像が完成したのち，その画像を既存の屋内ナビの
アプリケーションで表示されている学内地図に重ねて表示できるようにした．これ
は利用者に現在地と目的地を入力してもらい，データベースからそのルート画像を
引用し表示できるような基礎を作った．また，既存のナビアプリケーションに悪影
響を出さないようにも気を付けた．その後，データベースと UI が完成したのちそ
れらを組み込むという作業を行った．この際にいくつか問題が発生し，その問題の
解決に時間がかかってしまった．そのせいで納期に間に合わせることができなかっ
たので．最終的には本プロジェクトの最終的な屋内ナビゲーションは Team A が
作成したアプリケーションを組み込むこということをナビシステム班で議論した．
これが終了したのち最終発表会の準備班とポスター作成班と報告書担当班を決め
る会議を行った．この会議で私は最終発表会の準備班に配属されリーダーを務める
ことになった．また，後半の発表者を担当することになった．まずは，何を発表す
るのかということをグループで話し合った．特に，前期の中間発表会の発表は観客
に与える情報量が多すぎてわからなかったという意見が多かったので，情報量を削
り，ポイントをまとめて内容を作成することにした．また，発表全体でストーリー
を持たせ観客が記憶にとどめやすいようにする工夫も行った．ストーリーを考えた
のち，先生などから意見をいただき校正を行った．その後実際にスライドを作るた
めに最終発表会の準備班を 2 つに分け，発表の前半と後半を担当するようにグルー
プ分けした．これにより後々互いのグループの発表を確認，批評しあうことができ
ると判断したからだ．その後実際に発表の際に使うスライドの批評を行った．ま
た，同時に発表の練習も行った．発表する際には相手が聞き取り，記憶に留めやす
Group Report of 2012 SISP
- 107 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
いようにゆっくり話，ジェスチャーを交えて発表することを心掛けた．
12 月 12 月は最終発表会の発表練習の最後の詰めを主に行った．特にポスター作成班
や報告書担当班のメンバに見てもらい，内容から発表技術まで総合的に発表内容を
見てもらった．実際に発表の際にはレーザーポインターと指し棒を使い観客にわか
りやすい発表に努めた．
（※文責: 佐々木康祐）
伊東翔
9 月 屋内ナビアプリケーションを作成するため，後期の今後のスケジュールを決めた
り，最終的にどこまで到達するかを話し合った．私が所属する，位置情報班では，
屋内ナビアプリケーションの構築と Selfi と Android 端末との連携が目標となっ
た．私は，屋内ナビアプリケーションの実装を担当することとなった．実際に前期
で作った屋内ルート探索アルゴリズムはそのままの状態では組み込みできなかった
ので，違うアルゴリズムがないかなどを検討した．
10 月 屋内ルート探索アルゴリズムを構築するにあたって，未来大の特徴的な構造に
着目した．階層変化に対応するのは難しいという判断にいたったので，今回はナビ
を行う場所を 3 階に限定した．3 階を 10 個のエリアに分割すると，出発点と目的
地の組み合わせから，ルートが 72 パターンしかないことがわかったからだ．なの
で，72 枚のルートの画像を用意し，地図上に表示する方法をとることとした．
11 月 アプリケーション作成で，私は未来大の 3 階の部屋情報を格納する，データベー
スを作成することとなった．データベースの作成にあたって，今回は，SQLite を
用いることにした．SQLite を用いたのは，今後に 3 階以外の階層にも対応するこ
ととなったときに，拡張しやすいという点と，検索機能も実装したのだが，そのと
きに検索機能の実装において比較的簡単に実装することができると思ったからであ
る．データベースには，階層情報，部屋を教室や事務，教員室などといったカテゴ
リーごとに分割したのだが，その情報を格納した．また，私は，出発地点と目的地
を選ぶ画面の作成もおこなった．この月の終わりに，新技術開発サロンへの成果発
表会があったので，その準備もおこなった．
12 月 最終発表に向けて，アプリケーションの作成と発表練習をおこなった．アプリ
ケーションの作成は，今まで，グループ内で分担して作業を行っていたので，その
組み込み作業を行う際に，私は，私が作ったソースコードの説明などを組み込む人
におこなった．また，私は，最終発表の発表者となったので，スライドを見ながら，
発表でなにを話すのか決め，発表練習を行った．私は，報告書の作成班になったの
で，報告書のトピックの作成や，トピックの割り振り方などの報告書の企画などを
行った．
1 月 グループ報告書，個人報告書の作成，フィードバックシートの作成を行った．
グループ報告書の作成では，班の人の書いた文章の添削などを行った．
（※文責: 伊東翔）
町田浩平
9 月 前期で，昨年度プロジェクトの Wi-Fi を使った位置情報取得をするプログラム
を今年度の屋内ナビゲーションに対応させるために改変した．その後，改変したプ
ログラムを ALEFUN に組み込んだが，いくつかの問題点が浮上した． Wi-Fi を
使った位置情報の取得は，RSSI 方式を用いた．しかし，学内の無線 LAN ルーター
Group Report of 2012 SISP
- 108 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
の位置が特定できなかったことや，無線 LAN ルーターから出ている電波が壁やガ
ラスなどを通るために，電波の強度が減衰して一定の強度で確実な電波を受信する
ことはできなかった．そのため，取得した位置情報の精度が悪かった．また，ナビ
ゲーションで最重要といえるルート表示の機能が実装されていなかった．ルート表
示をするためには，ルートの探索アルゴリズムの構築が必要であることはわかって
いたが，前期の段階では実装するに至ってなかった．位置情報の取得を行っただけ
では，カーナビゲーションや Google Navigation のようなナビゲーションシステ
ムが構築できたとは言えないし，ルート表示をしただけでもそうとは言えない．ま
た，単に位置情報取得の技術とルート表示の機能を合わせただけでは，ナビゲー
ションシステムを構築できたことにはならない．例えば，ナビゲーションシステム
の構築には，カーナビのような最短ルートの探索やルート表示，さらに，ルート表
示した後，音声や画像などの情報を用いた案内は実装が必要である．このような問
題を解決するため，位置情報取得の精度改善とルート表示をするためのアルゴリズ
ム構築をすることとなった．私は，ルート表示の方法の構築をすることとなった．
10 月 この時期から，具体的に屋内のルート表示の実装を行った．前期の時点で，ア
ルゴリズムを屋内ナビゲーションに導入することが決まっていたが，それには理由
がある．ナビゲーションをするにあたり，まずはカーナビに用いられている技術に
ついて調べた．そこで，カーナビには，ダイクストラ法と呼ばれるアルゴリズムが
導入されていることがわかった．その後，ダイクストラ法の仕組みについて勉強
し，そのアルゴリズムを用いて屋内の最短ルート探索を行うこととなった．位置情
報班の 5 名で実装を行う予定であったが，一からのアルゴリズム構築は，完成する
時期に全く予想がつかず，12 月の最終発表までに完成する保証はなかった．その
ため，アルゴリズム構築以外で，確実に最終発表まで完成する方法を考案した．そ
こでひとつの案が浮上した．それは，パターンによるルート表示である．確実に屋
内ナビゲーションを完成させることができるよう，このパターンによるルート表示
の実装を行うグループと，アルゴリズム構築の方法でルート表示を行うグループの
2 つに分かれて活動することとなった．私は，アルゴリズム構築にあたった．アル
ゴリズム構築と言ってもいきなりプログラムを作成するのではなく，ダイクストラ
法について解説している参考図書やウェブサイトを参考にしながら，まずはサンプ
ルプログラムを動かした．そのサンプルプログラムで，実際のダイクストラ法の動
作の方法や，ルート探索の方法などを学んだ．ダイクストラ法の動作の大部分を理
解したところで，実際に未来大学 3 階のルート探索のプログラムを作成すること
になった．それと同時に，探索アルゴリズムが完成した後，どのように探索結果を
ルートとして地図上に表示させるかの議論とアイディア出しを行った．その中で上
がった複数の候補の中から実際にプログラムに落とし込み，数回テストした後，地
図画像上にアルゴリズムで探索した結果を描写している方法が最適であると考え，
その方法で実装することを決定した．
11 月 屋内のルート探索を行うにあたり，サンプルプログラムに致命的な欠点が見つ
かった．そのため，サンプルプログラムを改善して未来大学のルート探索に応用さ
せたいところだったが，そのプログラムを破棄し，全く別の新しい方法でダイクス
トラ法のアルゴリズムを構築することになった．そのプログラムが完成し，ルート
探索は予想どおりにうまく行ったが，ルート表示はうまく行かなかった．探索アル
Group Report of 2012 SISP
- 109 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ゴリズム構築に関しては，あまり時間はかからなかったが，ルート表示のプログラ
ムは，最も時間がかかった部分である．幾度と無く，ルート表示のプログラムを書
き換えてテストしたものの，アルゴリズムで探索した最短経路とは別のルートが表
示されるなどのバグが次から次へと発生した．改善とテストを繰り返し，ついに
11 月下旬になり完璧ではないが，実装することができた．それぞれのグループ活
動とは別に，最終発表の準備も始めた．私は，前期と同様，スライド制作班として
活動を行うこととなった．また，11 月下旬には，新技術開発サロンの最終プレゼ
ンがあり，最終発表同様の準備を行った．
12 月 最終発表が間近に迫る中，スライド作成班として活動を行った．前期の反省か
ら，多くの図や動画をスライドに埋め込むことにより，これまでの活動プロセスを
聴衆に理解してもらえるよう心がけた．
（※文責: 町田浩平）
三上力也
位置情報班メンバ三上力也の担当課題と活動は以下のとおりである．後期では主にア
プリケーションの UI 作成とルート表示の部分を担当した．
10 月 原点に戻りプロジェクトの目的の「連れていく」という認識を再確認した．前
期でアプリケーションに導入することが出来たものを書き出し，目的を達成するた
めに後期で追加する必要がある機能などについて話し合った. 前期で実装すること
が出来なかった機能である IMES や Selfi と携帯端末を連携させる ADK を今後
どのように追加していくかや，中間発表とオープンキャンパスの際に集めたアン
ケートの集計結果から，プロジェクトの目指すものや今年度の完成予想など，タス
クを確認しながら再設定しアプリケーションの開発に望んだ．
11 月 10 月に話し合った結果から，ナビアプリケーションを利用してもらう対象者は
公立はこだて未来大学に来た方となり，屋内地図にはトイレや細く暗い道などには
目印をつけてより快適かつ安全に利用してもらえるよう，自分たちで作成した学内
の地図をグループ内で見ながら危険箇所や狭い道を検討した．そして検討結果から
安全に使用できる道を決定し，ナビゲーションアプリの目的地までのルート案内に
参照した．また，私たちはルート検索の機能を実装するにあたって 2 つのグループ
に分かれた．一つはダイクストラ法といって目的地までの最短距離でルート案内を
する方，もうひとつは私が担当したパターン法だ．パターン法を実装するために，
目的地までの最短ルートを検索する方法ではなく人の混みやすい場所など Slefi が
安全に走行できる場所を各目的地分パターンを用意した．また，前期作成したアプ
リケーションに実装するため目的地表示のパターン法とアプリケーションをつなぐ
UI の部分を作成した． UI を作成するにあたりアプリケーションを利用する対象
者である初めて本校に来た方のことを考え，わかりやすさを重視し検索画面の目的
地現在地指定をするところでは，講義室事務関係教員室など大まかに部屋を計 6 種
類に分類し，部屋名がわからない人にも用途で検索できるようにした．そして，画
面にボタンを表示する方が使いづらいと考える人のために，メニューバーに検索方
法のリスト検索文字による入力検索などを設けた．11 月の後半では，新技術開発
サロンの方々への成果発表があったため，これまでやってきたことをスライドにま
とめ，実際に体験してもらうためにデモを多く取り入れた．成果発表の際には発表
を担当した．12 月 最終発表に向けて後期作成したアプリケーションのルート表
Group Report of 2012 SISP
- 110 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
示部分を前期に作成したアプリケーションに実装した. また，発表用スライドを作
成した．スライドでは 11 月の発表を元に反省点や指摘さてた意見を参考にし機能
説明を詳しくするのではなく，プロジェクトの目的を明確にしたり，作るうえでの
課題課題を解決するプロセスを重視し実装した各機能ごとにまとめた.
12 月 最終発表に向けて後期作成したアプリケーションのルート表示部分を前期に作
成したアプリケーションに実装した. また，発表用スライドを作成した．スライド
では 11 月の発表を元に反省点や指摘さてた意見を参考にし機能説明を詳しくする
のではなく，プロジェクトの目的を明確にしたり，作るうえでの課題課題を解決す
るプロセスを重視し実装した各機能ごとにまとめた.
（※文責: 三上力也）
八島奎之介
10 月 プロジェクトで前期の活動反省会を行い，学ぶ所があった．前期で残っていた
リスト検索から屋外案内を起動させた時にルートが表示されない不具合を直し，
はこだて未来大学の見学にきた高校生向けに，発表することになったので，発表
練習を行ったりした．大学見学の当日はスライド発表を行った後，高校生に向け
ALEFUN のシステム説明を行うなどした．次の活動日からは，後期の本格的な活
動が始まり，私は屋内ルートの構築に励んだ．初めは，屋内地図に線を引く所から
はじめ，屋内地図をキャンパスとして，その上に線を描く方法や，屋内地図画像を
Bitmap 形式で保存し，その画像情報をかきかえるということ目指した．
11 月 様々な方法で屋内の最短経路を求める方法を模索する．前期でメンバが取り組
んでいたダイクストラ法をベースに考え，思案していた．C++ で作成されたダイ
クストラアルゴリズムから Java に移植することや，他の経路探索アルゴリズムか
ら開発をしようとしたが完成せず，メンバが完成させたダイクストラアルゴリズム
を元に，屋内地図への反映を試みた．ダイクストラアルゴリズムのをルートに反映
させると，予想外のルートが表示される等，うまくルートが表示されないので他の
方法を視野に入れて開発をした．ダイクストラアルゴリズムを活かした方式ではな
いが，ある程度ルート表示は改善されることになった．最終発表に向けたポスター
制作を行い，誰が見てもプロジェクトの内容が把握できる様に目指しプロジェクト
目標などを詳しく載せた．サブポスターではハードと位置情報，それと ADK の重
要箇所を抜き出したスライドの製作を行った．また，新技術開発サロンの皆様に向
け，1 年間の成果を発表し評価を頂いた．
12 月 ダイクストラアルゴリズムの地図への反映に不具合が多いので，さらに簡略化
し，ルート表示の改善を行った．最終発表では発表の際に，位置情報アプリケー
ションのデモンストレーションを行った．その次の週からはグループ報告書の作成
を行い始めた．
（※文責: 八島奎之介）
ADK 班
犬塚悠人
10 月 まず， Android 端末でもスマートフォンでは問題なく動作するがタブレット
PC で強制終了してしまうというバグがあった．そのため，まずはそのバグを修正
するところから始まった．このバグの修正が完了した後，前期に製作を行ったナビ
ゲーションアプリと Selfi の相互通信を可能とし連携させ双方の通信を実現させる
Group Report of 2012 SISP
- 111 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
べく Eclipse の開発のターゲットやプラットフォームなど ADK を利用するための
環境導入をするという作業を行った．また，環境導入終了後は， ADK を実際に動
作が可能かどうかを検証するという活動を行った．同時並行で、 ADK を用いてど
のような形で連携を実現させるかといった話し合いも行った．この話し合いの中で
は， Selfi の速度を計測し Android 端末で表示をし，ある一定の速度を超えた時，
自動で速度を制限する案や階段や壁など危険なエリアに侵入しそうになった場合に
自動で停止するというような案が挙がった．話し合いを続けた結果，今期で実現が
可能な範囲で成果を挙げようという方針になり，実際に Selfi のバッテリー残量を
表示する， Android 端末で LED ライトなどハード面への操作が可能になること
を目指す事となった．このような，前提条件で 私は ADK をの動作確認の検証を
行い実際にプロトタイプに組み込みを行うという作業を担当する予定となった．
11 月 Eclipse の環境導入は終了していたが ADK を動作させるためのマイコンを選
定しなければならなかった．当初の予定であった mbed マイコンは ADK の動作
がうまく行かず，難航した．そこで，ADK の担当のメンバーと mbed の代わりと
なるマイコンを選定した．その結果として，Ardiuno と呼ばれるマイコンを選択
した．その後で追加することが決定した Arduino マイコンにプログラミングを行
えるような環境導入に取り組んだ．環境導入後の Ardiuno マイコンの基盤を使っ
て ADK を実際に動作させてみた．動作の内容としては Ardiuno マイコンの参考
書で最も基礎であると言われていた LED のライトを光らせるというプログラミ
ングを行うというものであった．Ardiuno マイコンに書き込むソースコードの内
容は利用した参考書のサンプルプログラムを利用し， Android 側のプログラムは
Android ADK の公式ホームページで配布しているサンプルプログラムを利用し
て動作の確認を行った．この動作確認の結果，マイコンボードの LED のを点灯さ
せることが可能であることが確認された．次に前期に製作を行ったプロトタイプの
ナビゲーションアプリ上で基盤の LED を点灯させることを目指した．その作業が
終了した後，以前より話題に上がっていた接近報知音を Android 端末で流せるよ
うに作業を行った．その作業が終了した後，プロトタイプの主に屋外ナビゲーショ
ンのユーザインターフェースについて考えた，相談し，開発を行った．スタート画
面と屋外ナビゲーションのモードが酷似していた点を修正し，また，メニューバー
に検索方法の選択を集め，画面上には地図のみ表示という状況にした．ユーザイン
ターフェースが一段落ついたところで，接近報知音の鳴り出すタイミングと LED
ライトを光らせるボタンの配置の話し合いを行い，接近報知音は地図上にルートが
表示された時に鳴らしまた，LED ライトを光らせるボタンはメニューバーの中に
入れるという形となった．それらの作業が終了した後，最終発表の準備に取り組ん
だ．ここで私は最終発表で出展するポスター作成に取り組んだ．
12 月 最終発表用のポスターで私は ADK についての文章を考えた．ADK での大き
な成果としては，Selfi のバッテリー残量をを表示できるようになった点，Android
端末の音声認識で LED ライトの点灯が可能となった点である．この 2 点がいかに
重要な役割を担っているかを初めて私たちのプロジェクトを知る人達に伝わるかを
念頭に置いて文章を考えた．その他にも最終発表用のポスター作成の活動として他
のメンバーが書いた文章の添削なども行った．文章を担当教員に添削してもらった
後，ポスターのレイアウトを考え，完成したものを印刷し，最終発表に出展した．
Group Report of 2012 SISP
- 112 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
（※文責: 犬塚悠人）
小野修都 後期では主に新型 IMES と Android との接続方法，及び Android Open
Accessory Development Kit(ADK) を用いた音声認識によるライト点灯の実装を担当
した．
9 月 9 月に入り前期で予定していた IMES の到着が遅れるといったことや，物品の管
理などに問題が発生したために本プロジェクトの概要や決まりなどを新たに考え直
しミーティングを行った．その後中間発表会の反省会を行い，中間発表会と 8 月に
行った公立はこだて未来大学オープンキャンパスの際に観客の方々に書いて頂いた
アンケートを集計し，どのような意見が出ているのかまとめた．その後その意見を
もとに後期で改善しなければならない点を全員で検討した．また後期に残された時
間内で完成させることができる目標へと設定し直した．ADK については夏季休業
中にも取り組んできたのだが進行が思わしくなく Selfi に搭載されている mbed 基
盤では困難なことがわかった，ちょうど IMES の規格が変わったため再び貸出依
頼をしているが到着が 10 月程になるとの事だったので後期には並行して IMES の
作業を行う予定だったナビシステム班の人員が作業が遅れていた ADK にヘルプで
入ることとなった．RSSI は個人で引き続き改修し IMES 到着までは ADK のヘル
プとして入り音声認識操作に取り組んだ．
10 月 前期から課題としてあげていた ADK の開発に取り掛かる．接続回路は別の
メンバが担当になりソフトの構築を主軸に担当した．まず ADK を利用するには
Android Open Acessory protocol(AOA) と呼ばれる通信プロトコルを Android，
マイコン両方に記述しておく必要がある．受信処理，出力コマンドごとのデータ仕
様，送信処理を作成したい回路にあわせて記述し無くてはならない．今回は音声入
力によって Selfi に設置した LED ライトを音声認識で動作させることを目的とし
たため機材に流す電流の規格は汎用性が高い USB を採用し暗いと言われたら 5V
の電圧の電流を流すように記述することにした．
そもそも音声認識処理は音声を解析し，保持している辞書と照らし合わせて
該当する言葉を探すという複雑な処理を行うため低機能なマイコンではソフト
ウェア処理をするのは難しく専用のハードを必要とする．しかし，Android の機
能を使うことで簡単に解決することができた．音声認識には Android 側で提供
されている RecognizerIntent，SpeechRecognizer と呼ばれる音声認識 API があ
る．RecognizerIntent の方が実装が簡単であるがこちらはその代わりカスタマイ
ズすることができない．そのため常時処理を受け付けるようにしたかったため，
SpeechRecognizer を使用することにした．
11 月 IMES が到着したため準天頂衛星システム（初号機 みちびき）に対応した GPS
チップを搭載している NEXUS7 と合わせて接続実験を行った．この結果工夫が必
要であるものの受信することが判明した． また鉛蓄電池の残存電圧を計測するた
めの回路が完成したため，Android 端末に音声入力により USB ライトを点灯させ
るための AOA と呼ばれるプロトコルに従って，電子回路を更に拡張してもらいア
プリとの連動実験を行った．完成後ナビシステム班のアプリと組み込みを開始し
た．Arduino と Android を Selfi に取り付ける方法がなかったためドリルで鉄板に
ねじアナを開けケーブル接続後プレートに固定する装置を作成してもらえるよう依
頼した．
Group Report of 2012 SISP
- 113 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
12 月 最終発表準備に入った．ポスター制作を主に携わり，それ以外の時間は 11 月
に完成しなかった部分を引き続き開発していた．発表では実機によるデモを担当し
た．また質疑応答でも答えられる範囲のものは回答した.
（※文責: 小野修都）
高橋克弥
10 月 前期から課題としてあげていた ADK の開発に取り掛かる．まずは環境構築か
ら始めた．mbed マイコンを用いて開発を始めた．このマイコンを選んだ理由は
Selfi の内部に搭載されているマイコンも同じものであり開発を続けていく上で都
合が良くなるであろうと予見されたからである．このまま一週間程開発を進めてい
たが資料となるものがほぼ見つからずこのままでは 12 月の最終発表の納期に間に
合わないため，急遽資料が豊富であることを条件別の開発環境を探した．その結果
選択したのが Arduino である．Arduino は ADK の開発において公式で使われて
いるマイコンボードでありその理由から資料は mbed より豊富である．マイコン
を変更してから ADK の導入は留まることなく進みマイコン側の導入は中旬には
終了したため Android 端末側の導入を待つのみとなった．ADK を利用して行う
ことが決定した．Selfi の鉛蓄電池の残存電力量を Android 端末側で確認できるよ
うにすることである．この目標を達成するためには鉛蓄電池から Arduino に電圧
をかけて A/D コンバータを用いてアナログ値を計測する必要がある．そのまま電
圧をかけては過剰な電圧であるため Arduino に深刻なダメージを与えてしまうこ
とになる．そこで適切な値まで降圧する回路を作る必要が出てきた．当初は電気の
知識はほとんどなかった為，学習する期間を含めて以降 11 月上旬までは回路作成
に費やすことになった．
11 月 鉛蓄電池の残存電圧を計測するための回路を完成させたあと，Android 端末に
音声入力により USB ライトを点灯させることが新たに目標として設定し，それ
に応じて電子回路を更に拡張させた．そのほかこの二つの目標を達成するために
Arduino のプログラミングを行った．ここまで進んだ時点で Arduino を Selfi に
取り付ける方法を考えていないことに気付き急遽ドリルで鉄板にねじアナとケーブ
ルを通す穴を開けた．
12 月 最終発表準備に入った．スライドの作成を主に携わり，そのほかの時間は 11 月
に完成しなかった部分を引き続き開発していた．発表では実機によるデモを担当し
た．また質疑応答でも答えられる範囲のものは答えた．（※文責: 高橋克弥）
（※文責: 高橋克弥）
畠山大樹
9 月 Android と Selfi 間での通信を行うために前期から課題となっていた ADK の
技術についての基礎知識を身につけることから始めた．この時にはまだ使う基盤
は明確に定まっていなかったので，マイコンボードの主流である mbed を用いた
ADK の参考書を読み始めた．私が担当するのは主に Android 側でのプログラム
部分とあらかじめ役割を決めておいたのでソース部分を集中的に学んだ．そこで
Android 側での実装ではアプリケーションの実装と同じく Java を基本とした実装
方法であることがわかり，作業に見通しを持つことが出来た．
10 月 Eclipse に SDK 開発環境の更新と ADK の開発環境導入を行った．上旬では
ADK の mbed 側の基盤を完成待ちだったので基盤無しで動くサンプルソースを動
Group Report of 2012 SISP
- 114 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
かし，環境導入が行われているか確認し，基盤完成時にすぐに Android 側でも実
装できるように準備を行った．しかし， mbed 基盤を用いた ADK 開発の情報が
少なく，新たに Arduino というマイコンを用いることになった．そのため今まで
の mbed を用いたものとはどのように違うのかを知るために参考書等で理解する
ことにした．下旬では Arduino 側のソースと基盤が出来上がり，それをどのよう
に Android と通信するのかを基盤担当のメンバと話し合い，仕様を決めた．
11 月 先月には決めた仕様通りのアプリケーションを Android で実装し始めた．
ADK は最近になって公開された技術であり， mbed はおろか Arduino での情報
も少なく実装は難航した．そこで新たな Arduino の参考書を用いて学習すること
にした．mbed での参考書とは別の使い方があり，基盤による特徴の差異等も学ぶ
ことが出来た．学習の成果もあり， Android で Selfi のバッテリー残量表示の実装
をできた．また，実装と並行してメンバそれぞれが実装してきた機能をまとめあげ
エラーを出さないようにする作業を始めた．
12 月 最終発表日前日までにアプリケーションが完成させなければならないので先月
から引き続きまとめあげの作業を行った．そのために実装を行った各メンバと実装
部分についての解説を聞くことで全体への理解と作業の促進を図った．そして最終
発表前日には使っても問題ないと思われる範囲までにアプリケーションを完成させ
ることが出来た．しかし，当初予定してた形のバッテリー残量表示が難しく，実装
できなかったが違和感がないように実装できた．最終発表後には報告書の担当にな
り，各人のトピックをまとめあげて TeX に打ち込む事を行った．今回の報告書で
は前回の問題点となった提出方法や各人の作業状況などを分かりやすくするために
プロジェクトメンバ全員でドキュメントを共有した．
1 月 12 月から報告書の情報共有を行いながら個人報告書の作成，フィーバック
シートの作成をした．グループ報告書では，私が主体となってに各メンバが書き，
添削が終わったファイルを全体のグループ報告書に編集し，追加するようにした．
（※文責: 畠山大樹）
Selfi 拡張班
岩山拓哉 後期活動において行なってきた活動は届いた 2 台目の Selfi の組み立て作業
と Selfi の安全性の向上である．前期活動において 1 台目を組み立てたので，組み立て
のノウハウを得られたので，1 台目よりは短い時間でなおかつスムーズに組み立てられ
るはずである． Selfi の安全性向上に関しては，2 台目を組み立てた後に行った．その
安全性向上のための改造としては，技術的な問題と時間的な問題から外部的に実装して
いった．私の担当した部分としては， Selfi の発進時の車体のぐらつきを解消するため
の機構として発着場 (土台) の制作を行った．さらに，ハンドル部分の不安定さを解消
するための固定具の制作である．
9 月 後期最初の活動で前期活動の反省会を行い，前期プロジェクトにおける問題点や
中間発表で指摘された問題について話し合った．そして，その改善案を話し合い，
後期の活動に反映できるよう後期活動内容を修正し，それとともに班分けを一新し
た．なお，班分けを一新したさいに各活動計画の詳細についても改めて振り分けし
た．この前期反省会の場において，夏季休業期間中に行った活動内容などの報告も
行った． Selfi 2 台目の組み立て作業を開始した．部品やネジ等の仕分けの際に，1
台目と大部分において部品が違うことに気いた．結果，1 台目と同じように組み立
Group Report of 2012 SISP
- 115 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
てることが出来ないので，組み立て作業が難航することが予想された．なお，改め
て班分けをしたハード拡張班において， Selfi の安全性の向上のためには，どのよ
うな外部的拡張が必要かの案出しを行い，どの案が実現可能かの検討会を行った．
10/5(金) に，市立函館高等学校より学生が校内見学の一環としてプロジェクトの
見学に来るので，発表人員の選定を行った．
10 月 市立函館高等学校の学生への発表にむけての資料や，アンケート等の作成を開
始した．10/5(金) 市立函館高等学校より学生が訪問．学生に対し，プロジェクトの
概要説明， Selfi の試乗，ナビアプリの体験などを行った．その後，プロジェクト
に対するアンケートをとった．そのアンケートから， Selfi に乗る際に発進時のぐ
らつきが怖いとの意見が得られたので，その問題解決に向けての案出しを行った．
その案の中から発着場 ( Selfi に乗るための土台) を制作することを決定した．モデ
ルの制作を開始し，加工のしやすさからダンボールでモデルを作成し，試作品を完
成させた．試作品が完成したのち，実際に制作するさいには素材などをどうするか
の検討を行った．さらに，アンケート結果からハンドルのぐらつきも危険だという
案もあったので，その問題解決のための検討を行った．
11 月 発着場が 10 月時点で完成していたので，試作品を利用して実際に制作する際の
設計図の制作を開始した．それと同時に，発着場モデルを使用し， Selfi に乗りや
すいかどうかの実験を行った．その際に行ったアンケート結果から新たな問題も得
られたので，その問題解決に向けた活動を行った．株式会社エフ・アイ・ティーへ
と発注していた Selfi の紛失部品が届いたので，作成中断していた 2 台目の Selfi
の組立作業を続行した．12 月中旬に，新技術開発サロン様に対し成果報告会を行
うので，発表資料等の制作を開始した．同時に，最終報告に向けてのポスターや発
表資料等の制作も開始した．
なお，11 月下旬から，12 月度の活動は最終報告に向けた発表準備や，報告書作
成作業にはいったので，班関係無く活動．
12 月 2 台目 Selfi が完成した．しかし，不具合が多分に見つかったので，調整作業を
開始した．調整中に 2 台目の基盤と 1 台目の基盤を付け替えた．のちに，改めて
1，2 台目の Selfi のパラメータを調整した．発表前日に Selfi 2 台とも完成した．
12/9(水) 最終報告回．12/9 以降は最終報告書作成活動行った．
（※文責: 岩山拓哉）
浅野翔太 ハード班メンバ浅野翔太の担当課題と活動は以下のとおりである．
9 月 後期始めに前期反省会を行い，前期プロジェクトにおける問題点や中間発表で指
摘された問題点について話し合った．そして，その改善案を話し合い後期の活動に
反映できるよう後期活動内容を修正し，それとともに班分けを一新した．各班毎の
活動に移行した後は，前期に引き続きタイヤカバー製作を担当した．タイヤカバー
に用いる素材を加工しやすいアクリルに決定し，図面製作に必要な知識を取得し
た．その後，前期のモデルを元に手書きの図面を完成させた．この図面を用い，新
技術開発サロン様に製作を依頼した．
10 月 依頼したタイヤカバーの製作が難しくなったため，依頼したものとは別にプロ
ジェクト内でレーザーカッターを用い，タイヤカバーを製作することとなった．そ
のため，新たに CAD を用い加工が容易なモデルの製作を開始した．用いる CAD
は DraftSight とし，モデル製作とともに操作方法，図面製作の方法を取得した．
Group Report of 2012 SISP
- 116 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
DraftSight を使用するに当たってモデルシートの作図が別シートに反映されない
不具合が発生したため，その改善に努めた．しかし，別のコンピュータの同設定の
DraftSight では同じ症状は起きなかった．また，不具合の起きている状況で製図し
たファイルにも不具合は見られなかった．そのため，この問題を保留とし，操作方
法の取得に努めた．操作方法の取得後は図面の設定を行い，練習用の図面を用いて
製図技術の取得を行った．また，レーザーカッターを加工に用いることとなったた
め，新たにタイヤカバーのモデルの製作を開始した．モデル案が 2 つ完成した後，
タイヤカバーの目的である靴紐や足等を巻き込んでしまう危険性がどの程度あるの
か実証実験を行った．その結果から，モデルを選び図面製作を行った．また，レー
ザーカッターを使うにあたってレーザーカッター講習会を受けた．
11 月 図面を本体の取り付け部分に合わせて微調整を行った．調整後，実際にアクリ
ル板をレーザーカッターとドリルでタイヤカバーに加工しタイヤカバー第一号が
完成した．完成したタイヤカバーから耐久性などの問題点が浮上したためアクリル
を 2 枚重ねることとでその改善を図った．新たにタイヤカバーを製作するに当た
り，アクリル板を入手する必要があった．新技術開発サロン様の大竹商店様からア
クリル板を頂けるとのことであったため，アクリル板を頂いた．その後，タイヤカ
バーを製作し，さらに 1 層目のアクリル板には本プロジェクトのロゴと名前を彫
刻した．タイヤカバー完成後は，部品の紛失により難航していた 2 台目 Selfi の組
み立てに加わった．私が加わったときはモーターを逆に取り付けてしまいタイヤが
逆回転してしまう不具合が起こっていたため左右の付け替えを行った．2 台目の組
み立て完了後は 2 台目 Selfi のパラメータ調整を行った．調整後も挙動に不具合が
あったためその都度調整を行った．この作業に平行して発表用のポスター製作を開
始した．
12 月 1 台目と 2 台目の Selfi の最終調整を行い，ライトやタイヤカバー，足型の取り
付けを行い， Selfi の改修は完了となった．その後，最終発表に向けてポスターの
確認を行った．最終発表では，アンケート用紙の配布やポスターの説明を行った．
最終発表後は最終報告書の製作に取り掛かった．
（※文責: 浅野翔太）
泉拓哉プロジェクトリーダー泉拓哉の担当課題と活動は以下のとおりである．プロジェ
クトリーダーとしてサイボウズのサイトを利用して，主に全体にかかわる活動予定や全
体課題の連絡をおこなった．
9 月 夏季休業期間については， mbed を使用しメンバーとブレッドボードで回路を組
みながら，「バッテリ残量取得」について取り組んだ. 結果, 電圧の値を PC 上に受
け取ることができた．
10 月 後期活動が始まり，後期に行う仕事の確認を行った．その後，自分は「接近報
知音」の開発を進めていくこととなり作業を進めた．
11 月 このころには，実際に音を鳴らし学内を走行する実験も行った．
12 月 接近報知音について暫定ではあるが出来上がり，実際に Android 端末で鳴らす
など行った．また最終発表会準備も始まり自分は，ポスター製作班としての活動も
行った．
（※文責: 泉拓哉）
Group Report of 2012 SISP
- 117 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
黒坂愛
Selfi 拡張班メンバ黒坂愛の担当課題と活動は以下のとおりである．後期は Selfi 拡
張班として Selfi の安全面の向上をめざし取り組んだ．
9 月 ブレッドボードが届いたので本格的に mbed の勉強を始めた． mbed を使用し
て，電源からの電圧をパソコン上に表示することができるように，回路の作成や
mbed の勉強を本を使用しながら勉強した．夏季休業期間中の活動内容を各自報告
しあい，夏季休業期間中に紛失した Selfi の部品の確認を一から行った．また，後
期活動にて改めて班分けを行い，私はハード拡張班に入った．班分けを行った後，
ハード拡張班のメンバで安全面の追及のために，どのような拡張が必要かを洗い出
し検討を行った．そして優先順位を考え，発着場を作成する班，タイヤカバーを作
成する班， ADK 班の三つに分かれて活動することになった．私はタイヤカバー
班に入った．その後 10 月 5 日に市立函館高等学校の生徒が構内見学の一環として
プロジェクトの見学に来るということでプロジェクトの全体で発表者などの決定を
行った．また，見学に来る生徒にアンケート調査を行うここと決定し，アンケート
の内容についてハード拡張班全体で話し合いを行った．
10 月 市立函館高等学校の生徒にアンケートを行うために，アンケートの内容を引き
続き話し合い，作成のための撮影などを行った．そして 10 月 5 日に市立函館高等
学校の生徒に Selfi に試乗してもらいアンケートを書いてもらった．その後，アン
ケートを集計し結果について話し合いを行った．話し合いを行った結果立つ位置に
目印が必要という結果になり，足型の検討と作成を行った．また，タイヤカバーを
作成する前に，タイヤカバーが必要であることを証明するために靴紐の巻き込み
実験を行った．2 台目の部品が紛失し角速度センサと加速度センサがなくなったた
め，それの代用品の検討と決定を行った． CAD の勉強も行った．10 月後半には
Selfi にどれくらい接近すれば気がつくかの実験を行い，さらに音の実験の結果の
分析も行った．
11 月 発着場モデルを使用した Selfi に乗りやすくなるかどうかの試乗実験の撮影を
行った．また接近報知音の音の大きさの実験．足型作成後にあったほうがいいのか
どうかの実験を行った．また，接近報知音の音の編集，作成も行った．紛失した
Selfi の電子部品が到着した後は Selfi 2 台目の製作を行った．12 月中旬に新技術
開発サロン様に成果報告会を行うことになったので，発表資料の作成を開始した．
それと同時に最終発表に向けての班分けを行い，私はスライド作成班としてスライ
ドの作成を行った．
12 月 最終発表のスライドの作成を継続して行った．そして最終発表の発表者になっ
たため，発表の練習を開始した．最終発表が終わった後は，最終報告書の分担，作
成を行った．
（※文責: 黒坂愛）
仲田健太郎
9 月 前期で行った拡張機能の話し合いについて再び話し合いを行い，優先的に拡張し
ていくものを決定した．また， Selfi の試乗やオープンキャンパス，中間発表会に
て得られた評価をもとに安全面の向上についても議論した．議論が進み，後期で行
う拡張に関して意見が固まった頃，その拡張の必要性の確証をとるためにも，10 月
に本学へ訪れる市立函館高等学校の生徒を対象とするアンケートの作成を行った．
Group Report of 2012 SISP
- 118 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
10 月 Selfi の安全性の確認と今後どんな機能が必要とされるかを図るため，高校生を
対象としたアンケートを実施した．アンケートの内容は，実際に Selfi に試乗して
もらった上で感想とともに，こちらが用意した今後製作しようと考えていた 3 つの
外部実装の中から必要と感じるものを選択してもらうものであった．これまでの話
し合いで優先的に必要なものを，アンケートの結果もふまえ話し合いを行った．そ
こから Selfi に乗る際の不安感， Selfi 本体のぐらつきを改善すべく発着場のモデ
ルを作成することが決定し，作業に移った．まずは，CAD を用いて発着場モデル
の設計図を作成し，材料の検討を行った．
11 月 Selfi 拡張のひとつである発着場のモデルが完成した．それを用いて，乗りやす
さの検証を行うべく実験を行い，評価をまとめた．発着場を用いての Selfi 試乗実
験では，プロジェクトメンバのみならず， Selfi に乗ったことのない人にも被験者
として参加してもらった．撮影を行いながらの実験後，そこから新たに Selfi への
乗りやすさを高めるための改善策を考えた．製作当初の予想以上に今回作成した発
着場の形での利点も発見でき，そこから今現在の Selfi への乗りやすさ，不安定さ
における問題点をまとめ，ハンドル固定の考案へと活動が移った．いくつかモデル
とその素材について議論を行い意見が固まり，まとめた後は Selfi に取り付ける報
知音の実験や Selfi 2 台目の組立，その他最終発表に向けてポスタの製作を行った．
12 月 最終発表会を前にポスター，スライドの製作を行なった．当日は，発表者とし
てスライドだけでなくポスターの内容を深く理解した上で発表を行った．最終発表
終了後は，これまで製作してきたものや道具の片付け，整理を行い，報告書の作成
に至った．
（※文責: 仲田健太郎）
6.3
発表準備
ポスター
中間発表会向けのポスタは全体の説明として 1 部，位置情報班ハード拡張班それぞれで 1 部
ずつの計 3 枚，最終発表会向けのものは同じく全体の説明として 1 部，そしてそれぞれの班
の内容を 1 部でまとめ計 2 部構成で製作した．ポスタ製作にあたり，まずスライド製作班と
発表形式について話し合いを行った．中間・最終のどちらの発表会のときもスライドを中心
に説明を行い，ポスタは発表会に訪れた人がプロジェクトに関する知識がなくても大方内容
を理解できる簡易的な説明の役割を担うものとした．
製作手順としてはまず各班ごとに分かれ，その中でも成果を書き起こす者，それらをまと
めレイアウトの調整を行う者に分かれ作業を行った．成果は箇条書きで書き起こし，できる
限り専門用語を避けた．それでもわかりにくいものは例を挙げながらまとめた．特に最終発
表会向けポスタでは，成果が目に見える形として残すことができたため，複数の写真を交え
ながら製作を行った．目標や到達レベル，今後の展望の項目は，スライド製作班との相違の
ズレを避けるため進捗報告も兼ねて随時話し合いを交えながら製作を進めた．そして出来上
がる度に班内だけに限らず，担当教員やプロジェクトメンバ全体で添削・評価を行った．こ
のような手順を経てポスタは完成した (下図??，??，3)．
最終発表会向けポスタを製作するにあたり，中間発表会向けのポスタの反省を行った結
果，見やすくわかりやすくを意識して製作を進めたため，全体的に端的過ぎでこのプロジェ
Group Report of 2012 SISP
- 119 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
クトに関わる人以外ではやや理解し難いポスタとなってしまった．また，中間発表向けポス
タの製作時点ではポスタの役割やターゲット，何を主に伝えていくかを十分に理解できてお
らず，それよりも我々のプロジェクトの目標や目的を説明することに比重が偏ってしまっ
た．その他，班ごとに分かれ製作していたため，班ごとにポスタの構成やレイアウトの違い
が生じる，A1 で印刷すると用紙が大きいため全体的にポスタ内容がスカスカに見えてしま
うという問題が起きた．
これらの反省点をふまえ，最終発表会向けポスタは前期に比べてプロジェクトの目的や内
容，そして今後の展望までを大まかに理解しやすいものとなった．さらに，レイアウトの
調整班を設けることで相違の異なるポスタにならないよう一貫性を持ったポスタとなった．
（下図 4，5）
スライド
スライドを作成するに当たって構成には 2 通りあり，プレゼンテーションの目的に合わせて
この 2 通りを使い分ける必要がある．たとえば，一つはプロジェクトの目標・背景を述べた
後，目標を達成するために必要な実装機能の仕組みを文章をメインに伝える構成の仕方と，
目標を達成するために行った過程をメインに説明し補足として機能の仕組みを説明するとい
う方法の 2 通りである．前期では中間発表，後期では新技術開発サロンの方々への成果発
表と最終発表と 3 回作成する機会があった．前期の中間発表の際には，一つ目の方法でス
ライドを作成した．内容としては，目標や課題設定をはじめに説明し，主にナビアプリケー
ションに必要な RSSI や IMES の装置の説明や位置取得方法などの，機能や仕組みの詳し
い説明を書いていた．その結果発表という 20 分の時間では収まらないような内容のスライ
ドが完成した．さらにあらかじめ位置取得方法などの多少の知識がないと説明されてもわか
らないなど反省点がいくつもあった．後期の新技術開発サロンへのスライド作成では，この
前期の反省点と中間発表のアンケート結果を活かして機能の説明重視ではなく，二つ目の方
法の活動内容をメインに作成した．実際に Selfi を作成している写真やナビアプリケーショ
ンの画面のキャプチャ・ Selfi の搭乗実験などの動画を多くし，プロジェクトの目標や課題
を達成するための過程を実際に見せながら，そのつど実装機能の説明を行うことにした．実
際に新技術開発サロンの方々にスライドを使用し発表をしたところ，わかりやすいやプレゼ
ンテーションの技術が高いなど好評をいただいた．そして，深い情報交換と今後の展開につ
いて新しい機能や改善点など，自分たちだけでは思いつかなかった意見をいただくなど貴重
な話し合いになった．最終発表では，今まで行った発表の反省点や改善点を出し，スライド
を作る前に説明の流れや構成について計画を立て，内容はよりシンプルに文章はできるだけ
減らし発表者が口頭で説明を追加するなど，自分たちの実装した機能を過程と関連付け相手
により活動内容が伝わる用に工夫した．
これまでスライドを作成してきて，一つ目の構成方法では，発表の際に提示し説明すると
いうよりは，発表を見てもらう人に参考資料として配る．もしくは発表後に発表内容を確認
するためのものとして使用することのほうが適しており，二つ目の方法は目標を達成するま
での過程や工夫がが私たちの行っている成果報告などのに適している．という結論が出た．
（※文責: 三上力也）
発表形態
ここでは，私達がこの 1 年間で発表活動と発表形態について書く．
Group Report of 2012 SISP
- 120 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 6.3
Group Report of 2012 SISP
中間発表メインポスター
- 121 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 6.4
Group Report of 2012 SISP
中間発表サブポスター 1
- 122 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 6.5
Group Report of 2012 SISP
中間発表サブポスター 2
- 123 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 6.6
Group Report of 2012 SISP
最終発表メインポスター
- 124 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 6.7
Group Report of 2012 SISP
最終発表サブポスター
- 125 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
新技術開発サロンの方々と顔合わせ
5 月に新技術開発サロンの方々との初めての顔合わせを行った．場所は 495 教室で
行った．主に，私たちが 1 年間でどういったことを行うのかや，目標などをスライドに
まとめて発表を行った．ここでは新技術開発サロンの方々との顔合わせのほかに意見交
換や Selfi のパーツを実際に見てもらったりすることができた．意見交換を行う中で，
いろいろなアイディアをいただくこともできた．
図 6.8
顔合わせ風景
中間発表
前期の中間発表では，ポスターの掲示，スライドによる発表，Selfi のデモンストレー
ション，Android 端末用のナビアプリケーションのデモンストレーション，質疑応答，
発表評価アンケートの記入を来場していただいた方々におこなってもらうことをおこ
なった．ポスターに関しては特になにもコメントはなかった．前期の中間発表では，発
表場所を体育館前のモールにした．ここを選んだ理由としては，Selfi のデモンストレー
ションを行うので，なるべく広い環境が向いていると考えたからである．その点を考慮
すると，体育館前のモールならば，ほかの発表場所に比べて，広くゆとりがあり，Selfi
のデモンストレーションを行うには最適であった．実際に，前期の中間発表の評価アン
ケートを見ても，Selfi のデモンストレーションがあって，初めて Selfi のような乗り物
を見た人でもイメージが沸いたのか，来場していただいた方々に高評価をいただいた．
中間発表のときには，まだ Selfi の安全性が不十分だったので，プロジェクトメンバし
か乗せられず，あまり見せることができなかったせいか，もっと Sslfi をもっと見せて
もいいという声や，Selfi に試乗したいという声が多かった．なので，後期の最終発表
には，Selfi の安全性を高め，来場していただいた方々に Selfi の試乗をできるようにし
たり，もっと，Selfi を押した発表をするということになった．スライドによる発表は，
文字をなるべく少なくし，図やスライドにアニメーションをつけたりするなど，聞いて
いる方々が飽きないように心がけた．その結果，評価アンケートの集計から，図やアニ
メーションがあってわかりやすかったという声が多く，高評価であったので後期もこ
こは継続して行いたい．しかし，発表場所が体育館前のモールだったため，日が差しこ
み，スライドをプロジェクターで投影していたのだが，後ろの方だと見ずらいという声
が多かった．なので，後期の最終発表には，場所を変えることとなった．Android 端
末用のナビアプリケーションには今回は，屋外ナビアプリケーションしかできてなかっ
Group Report of 2012 SISP
- 126 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
た．なので，音声認識によって目的地を入力し，現在地から，目的地までのルートを表
示するというデモンストレーションと，RSSI 方式をもちいた屋内での現在地の位置情
報取得を行うデモンストレーションをおこなった．今回は，テレビに HDMI 端子でア
プリケーションの画面を出力して行った．その理由としては，発表時間が限られていた
ので，実機をいくつか回して直接アプリケーションに触ってもらうより，大画面に映し
て，デモンストレーションをおこなった方が，伝わると思ったのと，Android 端末に
は，HDMI 端子がついているものがあるので，テレビに簡単に接続でき，かつ明るい場
所でも見やすいからである．やはり，実機に触ってもらって，ナビアプリケーションを
使った感想も聞きたかったので，発表時間の前や終わって時間が余ったときなどに，な
るべく多くの方々に触ってもって，感想を聞けるようお勧めした．質疑応答には，なる
べくどんな質問にも答えられるように，発表者を前後半に分けるときに，ハード班，位
置情報班のメンバがうまくわかれ，知識に穴がないようにした．その結果，大体の質問
には難なく答えることができたのだが，私達の予想していなかった質問もいくらかあっ
た．そこから，Selfi やナビアプリケーションの問題点として，私たちが思いつかなっか
た問題点が浮き彫りとなったので，今後のプロジェクト学習に生かしたいと思った．評
価アンケートは，発表形態と発表内容の評価に重点をおいた．発表技術について，プロ
ジェクトの内容を伝えるために効果的な発表がおこなわれていたかどうか，プロジェク
トの目標設定や計画が十分におこなわれていたかをそれぞれ 1（非常に悪い）から 10
（非常に優秀）の 10 段階で来場していただいた方々に評価していただくのと，コメント
やアドバイス，感想などを書く欄を設けた．これは，後期の最終発表にむけて，私たち
の目標設定や活動計画が十分に行われているのか，発表形態がわかりやすいかを，数値
化し，測るためである．そこから，発表技術については，私達の意図したとおりにスラ
イド，Selfi のデモンストレーション，ナビアプリケーションのデモンストレーションも
高評価であった．プロジェクトの内容を伝えるために効果的な発表をがおこなわれてい
たかについては，話がスムーズでよかったなど，高評価であった．ただ，一部文字が多
いスライドがあったり，必ず伝えたい箇所がわからないなどの指摘があったので，後期
の最終発表にいかしたい．プロジェクトの目標設定や計画が十分におこなわれていたか
については，目標や問題がはっきりしているなどの声が多かったのでこのまま継続して
いくこととなった．
オープンキャンパス
8 月に行われたオープンキャンパスでは主に，スライドによる発表，ポスターの掲
示，Selfi のデモンストレーション，Android 端末用のナビアプリケーションのデモン
ストレーション，そして，ブースに来場してきていただいた方にアンケートを書いても
らった．発表場所はエレクトロ工房前でおこなった．スライドは，来場する方々が高校
生が多いと判断したので，前期の中間発表に用いたスライドを一部簡略化した．また，
中間発表のときに指摘された箇所を改変し，スライドを用いて発表するのではなく，動
画などを流して，スライドは来場していただいた方々が質問していたときにお見せする
形をとった．その理由としては，プロジェクトが前期まで行ってきたことを全体的に説
明するよりは，私達のプロジェクトはハード班と位置情報班と全然やっている内容が違
う 2 つの班に分かれているので，来場していただいた方々とお話しながら，その方が知
りたいことや興味を持ったことを説明していったほうがよいと判断したからである．ポ
スターは，中間発表のときに一部指摘箇所があったので，一部改変して掲示した．Selfi
Group Report of 2012 SISP
- 127 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
のデモンストレーションは，このときも中間発表同様に，安全性が低かったので一般の
方々には乗せることができなかった．なので，プロジェクトメンバーが乗ってデモンス
トレーションをおこなった．今回，前期の中間発表で Selfi を見たことない人が初めて
みてみて，屋内でこのような乗り物が走ることに関してどう思うかを調べる必要がある
と指摘されたので，アンケートに載せることとした．それに関してアンケートの結果を
見ると，やはり乗りたいという声や，面白そうという声が多かった．Android 端末用ナ
ビアプリケーションのデモンストレーションに関しては，屋内で RSSI 方式を用いた位
置情報取得，屋外ナビアプリケーションでの音声検索機能でのルート表示のデモンスト
レーションをおこなった．屋内での位置情報取得に興味をいだいた方々が多く，IMES
についての質問や，RSSI 方式についての質問も多かった．
学校見学に来た高校生への発表
10 月に市立函館高等学校の生徒が学校見学にきたときに，30 分ほどプロジェクトに
ついて発表をおこなった．発表場所は 495 教室でおこなった．私達は普段，この教室で
活動しているのでここでの発表となった．今回は，スライドによる発表を行った後，全
後半に分かれてもらって，Selfi の試乗会と Android 端末用のナビアプリケーションの
実機を実際にまわして触ってもらった．スライドはオープンキャンパスで使ったものを
用いて発表形式でおこなった．Selfi の試乗会では，今回は Selfi の安全性が向上して，
一般の方々も乗れるようになっていたので，実際に試乗してもらって，どういったとこ
ろが乗りにくいかや，実際に乗ってみて，どう思ったかなど Selfi を初めてみて乗った
人の感想を聞くことができた．また，Android 端末用のナビアプリケーションを触っ
てもらったのは，アプリケーションが実際に誰にでもわかりやすいものなのかを判断す
るのに行った．
図 6.9
高校生への発表
新技術開発サロンへの成果発表
11 月に新技術開発サロンの方々へのプロジェクトの 1 年間の活動の成果発表会を
行った．場所は 495 教室でおこなった．発表はスライドによる発表，Android 端末用
のナビアプリケーションを実機で触ってもらうのと Selfi の試乗会をおこなった．スラ
イドは最終発表も近かったので，最終発表でも使うことを想定してつくったものを発表
に使った．Android 端末用ナビアプリケーションに関しては，実機で触ってもらって，
どういったアプリケーションかを確認してもらった．Selfi の試乗会は，新技術開発サ
Group Report of 2012 SISP
- 128 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ロンの方々一人一人が実際に Selfi に試乗してもらって感想を聞くことができた．発表
技術や発表内容について高評価をいただくことができた．
最終発表
後期の最終発表は，先に述べた前期の中間発表の成果と反省点を考慮して念入りにお
こなった．後期の最終発表も前期の中間発表同様， ポスターの掲示，スライドによる発
表，Selfi のデモンストレーション，Android 端末用のナビアプリケーションのデモン
ストレーション，質疑応答，発表評価アンケートの記入を来場していただいた方々にお
こなってもらうことをおこなった．今回，最終発表の前に，新技術開発サロンの方々の
前で成果発表会があった．新技術開発サロンの方々への発表で，発表内容やスライド等
の内容に関して高評価をいただいたので，一部のみ改良して最終発表にのぞんだ．今回
もポスターに関しては特にコメントはなかった．前期の中間発表では，体育館前のモー
ルを発表場所としたが，広くてゆとりがあり，Selfi のデモンストレーションには最適
であったが，プロジェクターで投影していたスライドが日差しで見ずらかったので，今
回は，工房前のモールを発表場所とした．なので，中間発表に比べて，スライドが見ず
らいという意見はなかった．また，後期は Selfi の開発が進み，安全性が向上したので，
試乗も行えることとなった．なので，前期の中間発表の反省点であった，Selfi をもっと
押した発表ができた．なかなか Selfi のような乗り物に載る機会はないので，来場者も
多く反応もよかった．スライドに関しては，中間発表同様，文字をなるべく少なくし，
図やアニメーションを多くして来場者が飽きないように工夫した．また，動画を入れた
りと工夫した．そして，中間発表の反省点をいかして私たちが強調したい箇所を強調す
るよう心がけた．しかし，スライドの順序がよくわからない，強調したい箇所がわから
ないなどといった声が多かった．Android 端末用のナビアプリケーションのデモンス
トレーションに関しては，今回も中間発表同様，テレビに HDMI 端子を用いて出力し
てデモンストレーションをおこない，時間が余ったら来場者の方々に触れてもらった．
今回は中間発表のときと違い，屋内ナビアプリケーションが本学の 3 階のみであるが完
成したので実際に現在地から目的地までのルートを表示するというデモンストレーショ
ンをおこなった．これに関しては，中間発表同様，見やすいという意見が多かった．質
疑応答に関しては，今回も中間発表同様，位置情報班，ハード班をうまくわけて，知識
に穴がないようにした．今回はあまり，予想外な質問がなかったので，スムーズに発表
が終わり，その分を来場していただいた方々が Selfi や Android 端末用のナビアプリ
ケーションの体験に当てることができた．評価アンケートは，発表形態と発表内容の評
価に重点をおいた．発表技術について，プロジェクトの内容を伝えるために効果的な発
表がおこなわれていたかどうか，プロジェクトの目標設定や計画が十分におこなわれて
いたかをそれぞれ 1（非常に悪い）から 5（非常に優秀）の 5 段階で来場していただい
た方々に評価していただき，また，コメントやアドバイス，感想を書く欄をもうけた．
これは，私たちの目標設定や活動計画が十分に行われているのか，発表形態がわかりや
すいかを調べ，来年への引継ぎにいかせるとおもったからである．発表技術について
は，スライドについては先にのべたとおりである．今回は，中間発表のときに比べて，
声が大きく聞き取りやすかったというコメントが多く，中間発表の反省をいかすことが
できた．Selfi や Android 端末用ナビアプリケーションのデモンストレーションに関し
ては，実際に実機がみれてよかった，成果物が明確でよかったなどの高評価を得ること
ができた．プロジェクトの内容を伝えるために効果的な発表が行われていたかについて
Group Report of 2012 SISP
- 129 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
は，問題点を自分たちでみつけ，しっかり一つ一つ解決している，という声が多かった．
プロジェクトの目標設定や活動計画が十分に行われていたかについては，目標がはっき
りしていて，活動計画が十分であるという意見が多かった．
図 6.10 最終発表
全体的に前期の中間発表に比べて，後期の最終発表の評価は全体的に上がっていた．ま
た，今後の活動に期待する声も多くいただいた．
（※文責: 伊東翔）
6.4
最終発表の評価
最終発表では発表スペースに来場し，発表を聞いて頂いた人を対象にアンケート調査を行った．
アンケート項目としては，まず評価者について，学生・教員・職員・一般の中からまるで囲んで
選んでもらい，学生の場合は学年と学生番号と氏名，その他の場合は所属と氏名を記入して頂い
た．発表技術については，プロジェクトの内容を伝えるために，効果的な発表が行われているかを
1（非常に悪い）から 5（非常に優秀）の 5 段階で評価してもらい，評価の理由やアドバイスなど
を，項目に分けて記載して頂いた．発表内容については，プロジェクトの目標設定と計画は十分な
ものであるかを 1（非常に悪い）から 5（非常に優秀）の 5 段階で評価してもらい，評価の理由や
アドバイスなどを，項目に分けて記載して頂いた．
アンケートの集計結果として，学生 57 名，教員 3 名，職員 0 名，一般 4 名，無記名 3 名の合計
67 名の来場者にアンケートを回答してもらうことができた．アンケートの集計結果では，発表技
術についての評価の平均は 3.85 点，発表内容についての評価の平均は 3.84 点となっており，この
結果を 10 点満点に直し中間発表の評価の平均と比べた際，発表技術は 7.69 点と +0.03 点，発表
内容は 7.68 点と +0.37 点とどちらも中間発表の時よりも評価が上がっていた??．
発表技術に対しては，大まかに 3 つのことについて書かれていた．発表形式について，スライド
の内容について，声の大きさについての 3 つである．まず，はじめに発表形式について，最終発表
では中間発表の時と同様にスライドとは別に成果物を用意し展示を行ったり実際にアプリを使用し
て見せたりした．これに対してのコメントでは，「実際に実機を見ることができてよかった。」「成
果物が明確でよかった」といった高評価な意見が多く書かれていた．次にスライドについて，スラ
イドに対しては中間発表では「「スライド一枚の文字量が時々多い」，「必ず伝えたい部分を強調し
Group Report of 2012 SISP
- 130 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
たほうがもっとよいスライドになると思う．」というアドバイスを頂いていた．最終発表ではその
アドバイスを生かして，写真や図などを多くし，必ず伝えたいところは，まとめとして二度提示す
るなどしてスライドの作成を行った．結果として「少し考えてみたくださいといってから説明に入
るのがいい」
「動画を使った説明が分かりやすかった」「図や写真が多くイメージがつかみやすかっ
た」といった高評価な意見が多く書かれていた．しかし「スライドの並び方、説明の順序が適切で
はなかった」「発表の仕方はいいがスライドの順序が少し分かりづらい」といった，スライドの構
成に対する指摘も頂いた．最後に声の大きさについて，中間発表では，声が小さいという意見が多
く書かれていた．だが最終発表では「大きい声でききやすかった」「声が通っていて内容が伝わり
やすかった」というように高評価な意見が多く書かれていた．
発表内容に対しては，「問題点を自分たちで見つけてしっかり解決しているところがすごかった」
「問題をひとつずつしっかり解決していったことが分かった．
」といった，実際に 1 年かけて行って
きたことに対して，十分に伝えることができたことがわかった．また、「目標の設定と計画は明確
で十分なもんだと思います．」「目標が分かりやすかった」という意見も多く書かれていた．中間発
表では，プロジェクトの目的とそのプランをしっかりと伝えることができていなかったが，最終発
表ではプロジェクトの目標や目的をしっかりと伝えることができたことがわかった．また，今回の
発表では，プロジェクトの最終的な目標と今年の目標，今年にできたことを主体的に発表を行った
ため，プロジェクトを通しての感想や学んだこと，また今後どうして行くかについては触れなかっ
たが「やったこと，やれなかったことについてわかったができなかったことについても知りたかっ
た」
「結果からの展望がなかったのが惜しいと思った」「もっと開発して得た経験や知識，感想など
を聞きたかった」という意見も多く書かれていた．
最終発表では，中間発表のときに比べて，全体的に評価が上がっていたと同時に中間発表でのア
ドバイスをしっかりと生かすことができていたと思う．「実物に乗ってみたいと思った」「今後の展
望として期待できるところが多いと思うものができていたと思う」というような今後の活動に対す
る期待の声も多く書かれており，全体的に高評価であった．
図 6.11
アンケート結果
（※文責: 黒坂愛）
Group Report of 2012 SISP
- 131 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
第 7 章 成果物説明 (ALEFUN)
7.1
目的
本プロジェクトの目的は，知能機械技術による施設内案内を実現する基礎を構築する為，知能機
械技術とナビゲーションアプリを連携させたシステムを ALEFUN と名付けそれを構築すること
である．今回目的を達成するために実験を行う公立はこだて未来大学は，正面玄関が 3 階にある
など特殊な構造をしている箇所がいくつかあり，道がわからず目的地に迷わず行くことが出来な
いという問題がある．実際に本校に来た企業の方や一般の方から研究室を聞かれることや，迷う道
がわかりづらいなどの話を聞くことがある. そこで，ALEFUN を作るにあたってシステムの対象
者を，本校に初めて来た人と設定し知能機械技術による施設内案内の基礎を構築しようと考えた．
ALEFUN が目指すのは，従来のナビアプリケーションでは考慮されていなかった「連れていく」
という要素を取り入れた知能機械技術による施設内案内を構築するということである．また，施設
内で使用する乗り物として Selfi を選択したのだが，屋内で使用するにあたり安全面が不安という
問題もあるのでそれを解決すること．この目標を実現するために「連れていく」とはどういったも
のなのか，どのような機能が必要なのかをグループ内で議論し，作成実験と何度も繰り返し，将来
ショッピングモールや空港など広く複雑な空間で，活躍できるようなシステムの構築を目指す．
（※文責: 三上力也）
7.2
システム概要
今年度私たちが目指すものは，知能機械技術による施設内案内である為， Selfi と呼ばれる倒立
二輪電動スクータとナビアプリケーションを連携させ目的を達成しようと考えた．私たちはこの
連携させたものを ALEFUN と名付けた． ALEFUN を構築するにあたり様々な課題が考えられ
る．施設内案内の課題としては以下があげられる．屋内を案内するためのシステムを作る必要があ
る．屋内では従来のカーナビゲーションや地図アプリケーションのように GPS を用いて位置情報
を取得することが出来ない．屋内の詳細が書かれている地図がない．これらの課題は，ナビアプリ
ケーションの基本である目的地検索ルート表示などのシステムの構築や，屋内で位置情報を取得す
る方法として， RSSI 方式や IMES を用いることで解決していく．次に知能機械技術である Selfi
の課題は，狭く複雑に入り組んでいて人が多いような施設でも安全に走行できるようにするという
こと，そのためにライトやタイヤカバーなどの機能の拡張を目指す．そして， Selfi とナビアプリ
ケーションを連携させる為に， ADK を用いて Selfi と 携帯端末間で速度やバッテリー残量などの
情報交換を行うシステムを実装し，より安全かつ快適にしようできることを目指す．ALEFUN が
構築することが出来れば，将来空港のカート（図??）やショッピングモールのカートのように広く
複雑な施設で活躍できる案内システムの基盤が出来る．
（※文責: 三上力也）
Group Report of 2012 SISP
- 132 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 7.1
7.3
羽田空港の電動カート
実装機能
この節では，今年度構築した ALEFUN の実装した機能について述べる．ALEFUN に実装
した機能は大きく分けて施設内案内の為のナビアプリケーションと，知能機械技術の Selfi ，
またこの二つを連携させるための ADK の 3 つである．一つ目のナビアプリケーションでは，
Google.Maps.API と WebView を用い GoogleMap 上でルート検索，ルート表示を可能にした屋
外ナビゲーション．自分たちで学内の地図を作成し， RSSI を用いた位置情報を取得する方法を構
築し，データベースに保存した各部屋の情報から目的地の検索を可能にした. ルーと表示には最短
ルートを選択するダイクストラ法と Selfi で安全に走行できる最適ルートを選択するパターンを用
いたルート表示の 2 種類の方法で表示する屋内ナビゲーションの２つの要素から構成だれている．
また，ナビアプリケーション全てに関わるユーザインターフェースは，対象者を初めて公立はこだ
て未来大学に来た方とし，スマートフォンの操作を知らない人にも使いやすいようにする為，ダイ
ヤログを用いて目的地の文字検索などが出来る欄や関連項目から目的地を探し出せるように，講義
室や教員室などで大きく用途別に分類したボタンを用意した．次に二つ目の Selfi については，利
用者に安全に安心して乗ってもらう為，タイヤに靴紐などを巻き込まないようにタイヤにカバー
を設置した．その他にも，乗りやすいように土台兼 Selfi を固定するための発着場（図１）や Selfi
の適切な立ち位置を示すための足を模った印（図??）．自分の存在を知らせる為のライトを設置し
た．3 つ目の連携部分である ADK では， Selfi 側に取り付けたライトを携帯端末から指示を出し
光らせることが可能になった（図??）. そして， Selfi 側から携帯端末にバッテリー残量を知らせ
る機能も実装した（図??）．
（※文責: 三上力也）
Group Report of 2012 SISP
- 133 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 7.2
発着場
図 7.3 USB ライトと足型
図 7.4 Selfi のバッテリー
7.4
実装予定機能案
ナビゲーションアプリ 今年度は屋内における Wi-Fi による位置情報の取得とルート表示
を可能とした．しかし，これらは未だ別の機能となっている．次年度以降は，これらの機能
を統合し，取得した現在地の位置情報をもとにルート表示を行う．
Wi-Fi を使用した RSSI 方式では，位置情報の精度が悪いため IMES を導入し，精度を
高める．また，現在は学内 3 階のみのルート表示であり，3 階から他の階へのルート表示を
行うことは不可能である．その対策として， IMES を導入することにより，高度取得が可
能となる．そのため，階の識別を行うことができ，3 階から他の階へのルート表示が実現で
きる．
また，現状のルート表示のみでは，ナビゲーションとは呼べないため，アプリにナビゲー
ションの要素を盛り込む．例えば，カーナビのような音声ガイダンスを搭載することによ
り，詳細なナビゲーションを行う．
（※文責: 町田浩平）
ADK 今年度 Selfi と Android の情報通信を ADK を利用することで実装したが，その通
信方法は USB を用いたシリアル通信である．そのため Selfi からはケーブルが垂れ下がっ
ており，それをまとめることで長さを調節しているが操作の邪魔になると思われる．また
運転中に何かの拍子で USB ケーブルが抜けるようなことがあれば，その先がタイヤに絡
まり想像もできないような大事故につながる可能性もある．そこで今後の展望として第一
Group Report of 2012 SISP
- 134 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
に，Selfi に搭載されたマイコンと Android 端末との情報通信を無線化することである．今
の Android には Bluetooth を利用できるものが多いため実現性も大いにある．これができ
れば Selfi に追加した機器を全て機体に格納できるため操作の障害や事故の危険性を軽減で
きる．
（※文責: 高橋克弥）
Selfi 拡張 今年度 Selfi の安全性を向上させるために車輪の側面にカバーを取り付けるこ
とで巻き込み防止を図ったが走行面は未だ剥き出しのままである．この状態のままだと万が
一転倒した時に何かによって圧力センサが入力されっぱなしになった場合，車輪は回転し続
けてしまう恐れがある．実際に試乗中に圧力センサの上に臀部を乗せる形で転倒したケース
があり，車輪の回転が止まらず危険な状態に陥ったことがある．幸いにも搭乗者に怪我はな
かったが車輪が剥き出しであるということの危険性を強く訴えかける事故であった．そのた
め今後は側面だけでなく車輪全体を覆うような形のカバーを至急考案する必要がある．これ
を目指すうえで当面で課題となるのは，体重をかけるなどして力がかかっても割れて搭乗者
に突き刺さることのないような素材や必要以上の負荷がかからないような取り付け方を発見
することである．
（※文責: 高橋克弥）
7.5
Selfi 組み立てマニュアル
ドライブユニット
ブシュ圧入
「アルミプレートに金属ブシュを挿入する．はめあいがきつい場合は，アルミプレート
の挿入部口元を紙ヤスリで，すこし削る．最後に，樹脂ハンマーで叩き，ブシュのツバ
がアルミプレートに密着していることを確認する．」と，説明されていますが，すでに
圧入されていますので特にやることはありません．この工程はスキップできる．
ノックピンの圧入
フランジを水平な台に置き，ノック品を 2 本打ち込む．ノックピンはテーパー (※先が
細くなってる部分) の側をしたに打ち込む．フランジからノックピンの頭は出ないよう
にする．
スプロケットの取り付け
スプロット (歯車上の部品) はレーザーカッターされた直後のままで送られてくる． バ
リをヤスリで取り除く．(紙ヤスリがやりやすい) できるだけ、滑らかにする．
しかし，この状態で送られてくるのは未塗装を注文した場合． 塗装済みを注文した
場合，バリが削り取られた状態で送られてくる．自分でバリをけずるのはかなり辛いの
で，塗装済みを購入すれば楽になる．
スプロケットをフランジに取り付け
フランジにスプロケットを六角ボルトで全て締める．しかし，締めすぎるとノックピ
ンが入りにくくなるので，仮止めする．ノックピンを打ち込んだあとに，本締めして
固定する．シャフトにへ行行ピンを挿入しましょう．左右の出代の部分は均等になる
ようにする．シャフトをフランジに挿入して，平行にする．一度入れると修正が困難
Group Report of 2012 SISP
- 135 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
なので，水平に入れるように十分注意して行う．カラー (輪状のパーツ) を挿入し，奥
まで入ってることを確認する．しかし，奥まで入りません．上からファイン U ナット
(M15(FUNT15) で締め込む時に押さえ込るので問題ありません．カラーの上から，専
用の工具を使いファイン U ナットで締め込みます．上記写真では，机の上でやってい
るように見えますが，万力で下部を固定してやりましょう．大きい穴の開いたアルミプ
レートにベアリングを挿入する． 穴に対して平行に入れましょう．無理に入れると破
損してしまうので，無理に入れるのはやめよう．組んだ軸をベアリングに挿入する．矢
印部が密着していることを確認する．ここがドライブユニットの心臓部といっても良い
です．はめ込みが甘いとすぐに抜けてしまい，故障のもとです．時間をかけてでもしっ
かりはめ込む．
モータブラケットの取り付け
赤い矢印部に締めてあるボルトを全て取り外す．外さないと，ブラケットを取り付け
た後のベアリング取り付けのさいにネジ頭が干渉してしまい，うまくはめれなくなりま
す．ブラケットを上記写真のように取り付ける．後でベアリングの位置調整を行うの
で，本締めしないで，角ワッシャーと六角穴ボルトを使って仮止めする．チェーンを外
れないようにするために，留め金をつける． しかし，軸のはめ方を失敗していると，留
め金分の高さでドライブユニット内で干渉してしまう． 上記写真では，表側に留め金
をつけている．しかし，難しいですが，裏側につけましょう．そうすれば，干渉するこ
とはありません．スペーサ (アルミプレートを繋ぐ支柱) をアルミプレートとベアリン
グ間に挟みこむ．この時，ベアリングと平行になるようにする．スペーサに六角穴付ボ
ルトを使い，仮締めする．その後，すべてのボルトを本締めする．
ドライブユニットの最終工程
中のチェーンのテンション (張り具合) を調整する．ネジを締めすぎる (きつくなる) と
チェーンが損傷します． ゆるめすぎる (ゆるい) と中で空回りを起こして，チェーンが
損傷する． 手で回る程度にネジを占めます．個人的感覚としては，少し締め具合が重
くなったと思ったらやめれば良い具合になるでしょう．
（※文責: 岩山拓哉）
メインフレーム
カバーフレームの組立
フロント，センター，リヤを組み合わせる． センターカバーの丸穴はフロント側にす
る．ひっくり返しボルトナットで締め付ける．充電ポートとメイン電源スイッチの取り
付けを行う．（スイッチに方向はない）
充電ポートケーブル 上段
バッテリーケーブル 中段
電源ケーブル 下段
スイッチ端子側から見て左列を赤，右列を黒に統一する．
半透明の端子側をシーソースイッチ側に差込む．
メインフレームの組立
モータユニットとフレームを取り付ける．L 側モータユニット端子番号 (M1A,M1B)
R 側モータユニット端子番号 (M2A,M2B) 中央が四角穴はフロント側，切り欠き穴は
リヤ側である．指示部密着させてボルト締めする．組立てた状態．上記写真手前がフロ
Group Report of 2012 SISP
- 136 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ント側である．先ほど組立てたカバーフレームを上からかぶせる．上面は低頭ボルトで
締め付ける．この段階では本締めせず，仮止め状態にしておく．側面をボルトで仮締め
する ．すべてのボルトが入ることを確認し上面から順に本締めする．奥の締めにくい
ボルトはカバースリットからレン チを入れて行う．
マットスイッチの取り付けハンダ付けしやすいように，予めセンサの端子にハンダ めっ
きを行う．※熱しすぎると、フィルムを溶かすのですばやく作業する．ケーブルに予め
収縮チューブを挿入し，ケーブル側も 同様にハンダを乗せてからセンサにケーブルを
ハンダ付けする．収縮チューブを奥まで被せ，軽くライター等であぶる．※熱しすぎに
注意する．端子のカシメ部をビニールテープで絶縁して準備完了．先に圧力センサの
マット張るとメインフレームの穴に通らないため注意する．一旦コネクタを精密ドライ
バ (-) ですべて外す．極性はないため，再度コネクタを接続する時は 1-2 3-4 のペアで
接続する．詳しくは回路図参照の事．フレーム中央にはバッテリが入るため，センサー
フィルムコード部に無理がかからないように折り返してセロハンテープで止める． 線
が板と板の間に挟まらないように配置する．六角支柱を 4 箇所に付け，制御ボードを載
せる．モータードライバ付属のネジは長いので，そのままだとバッテリーと干渉するた
め，ナット締め後，ペンチまたはサンダーで切断を行う．モータケーブル，電源ケーブ
ルを写真のように接続する．ここでドライバの DIP スイッチを設定しておく．
（※文責: 黒坂愛）
バッテリホルダ
バッテリホルダ組み立て
バッテリホルダーの 2 つの部品にバッテリを入れ，その後ネジとボルト，ワッシャー
を用い 4 箇所を固定する．
バッテリと配線の接続
バッテリの外側の端子にバッテリケーブルの端子を接続する．バッテリケーブルはメ
インスイッチ (シーソースイッチ) の中段端子へ接続したものである．接続する端子は
赤黒で極性を示しているため，これに合わせる．その後，絶縁テープで端子部分を覆
う．外側の端子にバッテリケーブルを接続した後，内側の端子に中継ケーブルを接続す
る．中継ケーブルを端子に接続すると電流が流れるため，作業には十分注意する．接続
後，先ほどと同様に端子部分を絶縁テープで覆う．バッテリケーブルと中継ケーブルを
接続した後，絶縁テープを用いて 2 本のケーブルが抜けてしまわないよう固定する．ま
た，公式サイトのマニュアルに「ヒューズホルダ」や「30A のヒューズを装着する」等
の説明があるが，これは以前のバージョンであり，現在この工程は必要ない．
バッテリ組み込み時の注意
バッテリを組み込む前に，本体内の配線を絶縁テープを用い干渉しないように固定す
る．干渉した場合，バッテリが入らないだけでなく配線が押しつぶされ断線してしまう
可能性があるため注意する．バッテリを組み込む際は，ガコンと音がするまでバッテリ
を押し込む．なお，この作業は床から出来るだけ高い位置で行うと作業しやすいため，
適当な高い箱などを用意しましょう．
（※文責: 浅野翔太）
ハンドルユニット
Group Report of 2012 SISP
- 137 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
ヒンジ部の組み立て
まず，1 つ目のフックに，六角穴付のボルト M5x20，カラー，シムリング (WSSB8-5-3)
，ナットをセットしてボルトを締め込み，最後にナットを締めロックする．2 つめの
フックに，六角穴付ボルト M5x20，シムリング (PCIMRS5-8-0.5) ，ナットをセット
して，ボルトを締め込み，最後にナットでロックする．締め込みを行う時，それぞ
れのボルトの頭の向きに注意する．ストッパーの取り付けについて，まずプレート
の皿モミ側から締め込む．プレートに六角穴付小径ボルト（SBB5-8）とシムリング
(PCIMRS5-8-0.5) をセットして、締め込む。フックと軸にグリスをたっぷり塗って，重
ねる．フランジを入れ，ファイン U ナット M15(FUNT15) でロックする．付属のワッ
シャー (WSSM25-15-2) を忘れずに入れる．締め具合は軸の回りが重いくらいにする．
軽く回る程度だと、ハンドルを付けたときのガタが大きくなるので注意する．組立後、
適宜増し締めをする．ここで、2 つのフックはフリーで回ることを確認する．スプリン
グ (AWT12-40) とスプリングポスト (AIPOZ8-35) 連結し，両側のボルトに掛ける．矢
印Φ 8x25 のカラー (KNCLB5-10-25)3 個と，六角穴付ボルト M5x35 でプレートとフ
ランジを連結する．正面を見て，プレートと軸の隙間が均等になるように締める．ブラ
ケットを六角穴付皿ボルト M5x10 2 個で取り付ける．スプリングポストをブラケッ
トの穴に通し，M8U ナット（2 個）で締め上げる．おおよそ，ポスト先端が 15mm ぐ
らいになるまで引っ 張る．このばねが、ハンドル中立の復帰力になる．プレートのΦ
6mm の穴よりノックピン (MSTP6-30) を打ち込む．フックと干渉しないように，軸を
まわして中心に移動させる．ヒンジケースを六角穴付ボルト M5x15，スプリング ワッ
シャー，平ワッシャーで仮締めする．（スプリングが利く程度）Φ 6x30 ノックピンを
Φ 6mm の穴に打ち込む． その時，矢印のエアベンド（平面部）が上向きになるように
する．ノックピンは 2 つのフックの間に収まる．ノックピン打ち込み後，ヒンジケース
のボルトは忘れずに締める．ボルトがブラケットの R 部にフィットしていない場合は，
一旦ブラケットを止めている皿ボルトを締めなおす．しかし，締め直すのは一苦労であ
るため，できれば一発で決めましょう．１０ K Ω可変抵抗器とブラケットを取り付け
る．その後ギヤを挿入する．この時ホーローはまだ締めない．テスターで 2 箇所の端子
を測定し，5K Ω付近になるよ うに可変抵抗器を調整する．調整後，2 つのギヤのホー
ローをしっかりロックする．ホーローをロックなどわからない表現だが，要約すると全
て六角レンチで締めれば終了である．ギヤに無理な力が掛かっていないことを確認しな
がら，ガタなくブラケットを締める．ステアリングケーブルをハンダ付けする．（端子
部は収縮チューブで絶縁を行う．このままではコードが通らない． 一旦，コードを切
断することも視野に入れる． そして，コードを通した後で，改めて繋ぎ直す．ヒンジユ
ニットとブラケットをボルト締めする．その次に本体と取り付けを行うのが正しい手順
だが先にハンドルと本体を固定してしまうと，バッテリを入れるのが大変になってしま
うため，バッテリを組み込んだあとに，ハンドルユニットを固定する．
ヒンジ部の組み立てコンソールボックスをハンドルバーに取り付ける．スイッチ穴の向
きがあるため，バーに対しての取り 付け方向は全体イメージを参照する．パイプが挿
入できない場合は，適宜穴をヤスリで広げる必要がある．スイッチをハンダ付けする前
に，ハンドルケーブルを先に通す．
LED にハンドルケーブルをハンダ付けする．（詳しくは回路図を参照．）
Group Report of 2012 SISP
- 138 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
SUS のカバーを外す．その後ハンドルパイプを通し，M3 ビス止めします．パイプに
M3 タップ加工をする．SUS カバーを戻し、付属のグリップを挿入する．
コネクタを接続する
ハンドルバーをヒンジユニットに挿入し取り付けを行う．円盤状の SUS カバーを六角
穴付ボタンボルト (BCB3-6) で取り付けを行う．※タップ側はアルミ鋳物であるため
強く締めすぎるとネジ穴がつぶれる恐れがあるため注意する．
（※文責: 黒坂愛）
基盤作成
メイン基盤作成
ハンダ付けを行う際には，必ず部品の高さが低い順にハンダ付けを行っていく．高いも
のからハンダ付けすると低いもののハンダ付けをする際に取り付けにくくなる．
全ての部品を取り付けたら，バッテリ残量アナログ入力用の可変抵抗器を調節する．
mbed はこの時点では，まだ装着ないように．
裏側の矢印の部分にテスターを当て，抵抗値が 36k Ωになるように調整する．
ジャイロセンサーの取り付け
2012 年度 4 月では上記画像のものだったが，現在ではバージョンアップされ上記画像
のものでない可能性あり．
今回は，上記画像のものでの説明を行う．
上記画像のように，部品別で送られてくる． これを組み立てるが，組み立て時に絶縁処
理を施さないと通電してしまい，破損するので注意すること．
まず，上記画像のように左側の穴付近から少し離して，絶縁テープ (両面テープでも可)
を貼り付ける．
必ず上に ADXRS 下に ADXL を固定する。 しかし，下記画像のようにコネクタを
先にハンダ付けしたほうがやりやすくなる．
（※文責: 泉拓哉）
配線
全体の配線
ドライバケーブルは，黒：０ V 赤：5V 白：S1 緑：S2 へ接続する．
電源ケーブル 2 は，ドライバの B+ B-へ接続する．
コネクタを接続する．
mbed の USB ポートを右向きに挿入する．
センターパネルＬＥＤへのハンダ付け
LED ケーブルの赤を ＬＥＤ Anode ( Red ) へ
LED ケーブルの白を ＬＥＤ Anode ( Green ) へ
LED ケーブルの黒を ＬＥＤ Common へ
端子間は収縮チューブを入れて確実に絶縁を行う．
Group Report of 2012 SISP
- 139 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
（※文責: 黒坂愛）
最終組み立て
画像上の 1 番を取り付ける際には前部にネジをつけるのはやめましょう．中でハンドルユ
ニットと干渉してしまいます．ほかの部分を三点ほど締めれば十分固定できます．ほかに
も，ドライブユニットの内側にカバーを付ける部分がありますが，ネジ穴が合わないので取
り付けるのは不可能です．部品として余ってしまいますが気にしないでください．
（※文責: 岩山拓哉）
その他この項では Selfi1 台目及び 2 台目の不具合について記述する．
角速度センサと加速度センサについて
Selfi 1 台目の角速度センサ及び加速度センサは正規品ではなく，正規品のものと同
じ動作をする各種センサを組み合わせた自作品となっている．この自作品による本
体の動作への影響は見られなかった．また，用いたセンサは ADXL203 評価ボード
(ADXL203EB) と ADXRS624 評価ボード (EVAL-ADXRS624Z) となっている．
Selfi1 台目の警告音について
Selfi 1 台目は起動すると警告音が鳴り続けてしまう状態になっている．この警告音
はバッテリーの残量不足を知らせるためのものだと考えられるが，十分に充電した状態
であっても 1 台目のみ警告音が鳴り続けてしまう．この原因は，基盤にあるバッテリー
からの電圧を測定する部分に断線等で電流が流れていかないため，正しいバッテリー残
量を測定できなくなっているのではないかと考えられる．しかし，警告音を止めること
はできないが本体の動作自体に影響は見られない．
本体を傾けたときになる警告音
起動中に Selfi 本体を大きく傾けたとき，警告音が鳴ることがある．この現象は，プ
ロジェクト前期活動中には見られず 11 月頃 mbed に新たに書き込みを行った後に見ら
れるようになった．警告音が鳴るときの角度の詳細や警告音が鳴る原因については未調
査である．また，公式サイトである FIT-Robots にアップロードされているプログラ
ムまたは設定ファイルが更新された可能性があるため，仕様である可能性もある．
圧力センサについて
Selfi 2 台目の圧力センサの内，本体正面から見て左手前側のセンサの端子が破損し
ている．しかし，本体の動作自体には問題ない．また，圧力センサの端子が付いている
フィルムは裂けやすいため組み立てや分解時には扱いに注意する必要がある．
以上が 1 台及び 2 台目に見られる不具合である．本体の起動やメンテナンス時には
これらの点に注意するべきである．
（※文責: 浅野翔太）
7.6
IMES 設定
IMES 送信機
以下の図??のように IMES 送信機を AC アダプタで接続しパラメーター設定は付属の赤外
線コントローラとソフトウェアを介して行う．この操作パネルでは PRN 番号，緯度経度，
ID 等を入力する．
Group Report of 2012 SISP
- 140 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
図 7.5 IMES 送信機簡易図
図 7.6 IMES 操作画面
1. 操作装置選択
2. PRN 番号 171∼182 までの範囲で設定可能
3. ロケーションパラメータ 緯度経度，高度，ID などを設定可能
なおオプション上にある Communication を選択することで Com port を指定することがで
き赤外線コントローラーの通信ポートを指定することが出来る．
IMES 受信機
基本仕様として Bluetooth 接続機能をサポートしており使用するには起動後，Android と
図 7.7 IMES 受信機
ペアリングする必要がある．この方式でデータのやりとりを行うにはコマンドを介する．
(Android は末尾に＜ LF ＞が必要)
基本コマンド一覧
@SOM 400 1000 3001//受信機を初期化
Group Report of 2012 SISP
- 141 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
@CD//受信機をコールドスタート
@SW//受信機ウォームスタート
@SR//受信機をホットスタート
@POSE//IMES 受信機の位置入力
@TIM//時刻設定時刻設定
#SIC//受信チャンネル割り当て
#SIF//サーチ周波数オフセット割り当て
#SIS//サーチモード設定
#NM//出力設定
（※文責: 小野修都）
Group Report of 2012 SISP
- 142 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
第8章
まとめ
この章では現時点のプロジェクトの成果を述べる.
8.1
プロジェクトの成果
本プロジェクトの前期の成果について，ハード班は Selfi の組み立てを行った．組み立てによっ
て，Selfi の構造やしくみの理解をすることができた．組み立て後のテスト走行では，室内走行では
安全面での問題があることが分かった．現在の Selfi のままでは，室内の走行を想定されていない
ため，室内での安全走行に関して機能の拡張が必要ということが分かった．また，位置情報班はナ
ビゲーションアプリの製作を主に行った．屋外ナビゲーションシステムでは GPS を用い目的地ま
でのルート検索機能の実装と目的地の選択方法の実装，RSSI 方式を用いた位置情報取得システム
を製作した．また，その取得した位置情報を元にナビゲーションができるナビゲーションアプリも
製作した．
本プロジェクトの後期の成果について，前期のタスクの続き及び新規タスクについて取り組ん
だ．具体的には以下に記す．
まず，移動手段の構築として前期に取り組んで分かった室内で走行するにあたっての問題点とし
て，安全面に配慮するような機能の拡張が必要という点について最重要項目として取り組んだ．拡
張案については様々な案が出たが，本プロジェクトで今期取り組むことができ，また早急に必要と
されるだろう機能に絞って開発を行った．大きく，タイヤカバー，足型，接近報知音，発着場の 4
つについて取り組んだ．1 つ目として，Selfi のタイヤが外部に露出していて足や靴紐を Selfi が巻
き込む危険性があった．そこでタイヤと足場の間にタイヤカバーを設置することによって解決を目
指した．このカバーの取り付けによって問題点を解決することは出来たが，用いた素材であるアク
リル板には強度面での若干の不安が残った．2 つ目として，Selfi に乗る位置が悪いために，Selfi
の制御に関わる圧力センサがうまく反応せずに，操作しにくい問題があった．そこで足をおく目印
を置き解決を目指した．この目印を工夫し，足型にして製作し，製作後乗りやすさについてのアン
ケートを行った結果乗りやすいという結果が得られた．3 つ目として，Selfi が屋内で走行するに当
たって他の人に自分の存在を知らせる必要があった．そこで，接近報知音を Android 端末から鳴
らし Selfi の存在を知らせることにした．鳴らすことにより他の人に存在を知らせることができる
距離が縮めることが出来たが，更なる研究や改善が必要であった．最後に，Selfi 本体の乗りにく
さや乗る際のぐらつきを改善する必要があった．そこで，Selfi 本体を固定し，同程度の高さから
Selfi へと乗れる発着場を製作した．Selfi の乗りにくさについて改善することが出来たが，ぐらつ
きを固定するにはこれも更なる研究や改善が必要だと分かった．このように安全面での拡張として
は，上記の 4 つについて大きな成果をあげることができた．
次に，ナビゲーションシステムの基礎の構築としては，前期でも取り組んでいた屋内でも位置情
報取得，階層変化，ナビゲーションの大きく３つについてより完成度を高め ALEFUN へと実装で
きるように取り組んだ．1 つ目として，屋内では GPS が使用できないため正確な位置情報を取得
することができなかった．そこで，Wi-Fi 電波強度を用いて現在地を取得するアプリケーションの
製作を行った．結果誤差はあるが，屋内の位置情報を得ることができた．2 つ目として既存の位置
情報取得技術では高低差を把握できないため自分がいま何階にいるのかが分からないという問題が
Group Report of 2012 SISP
- 143 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
あった．そこで，IMES による位置情報のデータ送信によって階の高さを把握することを目指し
た．アプリケーションであり IMES への反映までこそいかなかったが，IMES からの位置情報取
得という点については達成できた．3 つ目として，屋内での最短ルート探索方法について確立でき
ていなかったため，ダイクストラ法を用い，いくつかのルート検索の実装が出来た．
最後に，前期ではまだ取り組んでいなかった Selfi と Android 端末とをつなぐ仕組みづくりとし
て ADK による連携を目指した．大きく音声認識と Selfi のバッテリー残量取得という 2 つの内容
について取り組んだ．1 つ目として，走行中の Android 端末操作は，Selfi 走行時に事故を起こす
危険性が高まるという問題があり，Selfi や Android 端末操作の一部を音声認識で操作できるよう
にした．今回実装したのは，
「暗い」という音声を Android 端末が認識すると，Selfi につなげられ
た LED ライトが点灯できるようにした．これによって，大きな Android 端末操作をしなくても，
LED ライトの点灯を行えるようになった．2 つ目として，Selfi が走行する時にバッテリー残量が
分からないためあとどのくらい走行できるか分からないという問題があった．そこで Android 端
末にバッテリー残量を表示できるようにした．これによって，どのタイミングでバッテリーを充電
するか目で見て確認できるようになり，走行中にバッテリー不足になることを防ぐ機能の実現がで
きた．
以上のように，本プロジェクトの成果として安全な移動手段の構築，屋内ナビゲーションシステ
ムの構築， ADK 技術による Selfi と Android 端末との連携について大きな成果をあげることが出
来た．
（※文責: 泉拓哉）
8.2
今後の課題と展望
本プロジェクトのタイトルである『知能機械技術による施設内案内』を実現するため，班ごとと
全体の課題が挙げられた． 前期では，ハード班では Selfi の安全性向上と Android 端末へ情報を送るための上位マイコン
の実装が課題として挙げられた．位置情報班では IMES を用いた屋内位置取得システムを構築し，
屋内での位置情報取得の精度を高め，屋内でも正確かつ屋内外間でのシームレスなナビゲーション
アプリを実装したい．また，ハード班と位置情報班での共通の課題として Selfi と Android 端末間
での連携を ADK を用いて実装をするであった．
後期では，ハード班では，靴紐などがホイールに巻き込まれないようにするためにタイヤカバー
を作成したが，まだタイヤの走行面を覆っていないため転倒したときなどにタイヤの走行面に乗っ
かってしまうとタイヤが回転してしまい危険なのでタイヤカバーの改良がまず挙げられる．また，
ハンドルが現状のままだと初めて乗った人には操作が難しいので自転車やバイクのように，操作が
比較的に簡単で誰にでも扱いやすいようにするという課題もある．最後に，Selfi を屋内で使うに
あたって，Selfi は乗り物であるので，一定のスピード制限を設ける必要がある．なのでスピード
メーターの構築と一定スピードが早すぎる時に，運転手に知らせるようなシステムの構築が望まし
い．位置情報班は，前期同様，IMES に対応することができなかったので，IMES への対応，ま
た，現状の屋内ナビアプリケーションは 3 階の限られた範囲でしか対応できていないので，階層変
化にも対応し，学内全体を網羅する必要がある．そして，屋内と屋外のナビアプリケーション間で
まだ連携が取れていないので屋内と屋外間での移動にも対応できるよう連携する必要がある．
以上を実装して，私達の目指そうとする知能機械技術完成させたい．
Group Report of 2012 SISP
- 144 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
（※文責: 伊東翔）
Group Report of 2012 SISP
- 145 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
第 9 章 謝辞
本プロジェクトを遂行するにあたり，Selfi やその他の物品・技術を提供していただいた新技術開
発サロンの皆様，特に大竹様，熊井様，松村様と発明協会からお越しいただいた大嶋様には深く感
謝いたします．プロジェクトの始動時には今回用いた技術についての知識は皆無でしたので協力が
なければ今回のここまでの実装は出来なかったと思います．
また，１年間私たちの指導教員として様々なアドバイスや指導していただいた高橋先生，三上先
生，竹之内先生にも感謝いたします．
最後に本プロジェクトの活動において実験のアンケートや発表会での評価などをしていただいた
本大学の学部生や院生を始め，多くの方々ににご協力いただき誠にありがとうございました．
（※文責: 畠山大樹）
Group Report of 2012 SISP
- 146 -
Group Number 04-A/B/C
Intelligent Machines as Institutional Guides
参考文献
[1] GPS 衛星みちびき×網走監獄！？ 大規模実証実験レポート in 北海道
http://weekly.ascii.jp/elem/000/000/062/62614/
[2] G 空間 EXPO G-spatial EXPO 2012
http://www.g-expo.jp/index.html
[3] 朝日新聞デジタル：セグウェイでキャンパス移動 名古屋大で利用実験 - 社会
http://www.asahi.com/national/update/0118/NGY201201180011.html
[4] 自律移動支援におけるＩＭＥＳの利用状況と課題
http://www.bk83.com/
[5] 長井技研 精密板金 wiz
http://www.meti.go.jp/policy/it policy/GIS/090319/1 navitime.pdf
Group Report of 2012 SISP
- 147 -
Group Number 04-A/B/C