第12回レスコン用システム開発記

中村祐一君(電子機械工学科3年)

今年の「救命ゴリラ!!」は、inrevium杯「第12回レスキューロボットコンテスト」競技会で、ベストテレオペレーション賞を受賞しました。このページでは、受賞理由として審査員の先生方に評価をいただけた統合情報中央管理システム「CIMI」の解説と開発経緯をレポートします。

今年で私は3回目のレスキューロボットコンテスト参加になりました。今年の役割も去年と同じで、電子回路設計とファームウエア開発です。

今年は画像と音声の情報を1つのコンピュータで集中管理するシステム「CIMI」と、TPIP2ボードを用いた制御システム「CACS」の2つに携わりました。

そして、サンリツオートメーションがユーザー向けに公開している「遠隔操縦用ソフトウエア(TPIP-RRC)」の改良も私の役割でした。

今年は、去年ほどの時間がなく、レスコンにかける時間が限られていましたが、できる限り全力で自分の仕事を完遂するべく、完成までのスケジュール管理をしました。

システム概要

画像と音声の情報を1つのコンピュータで集中管理するシステム「CIMI」

中央情報管理システム:CIMI (Central Information Management Integration system) は、次の図に示すように各ロボットに搭載しているTPIPボードから送信される音声と画像の情報を1つのコンピュータで集中管理するシステムです。各データについては、各ロボットのTPIP2-RRCのjpegデータをストリームソケット(TCP/IP)通信を使用して1つのコンピュータにまとめ、中央のコンピュータで処理します。

このシステムを使用することで、リーダーは各ロボットが助けようとしているダミヤンの情報を1つの画面で把握することができるため、個体識別が簡単になります。また各ロボットの状況も同時に把握できるため、リーダーがオペレータ達に適切な指示を出せるようになり、オペレータがロボット操縦に集中できるようになります。

TPIP2ボードを用いた制御システム「CACS」

CACS (Changeable Adapting Connector System)は、各ロボットの制御に必要な主要機能をユニット化し、簡単に付け替えが可能となるシステムです。システムを構成するユニットをCACSユニットと呼び、システムの中心のユニットをコアユニット、コアユニットからの指令を受けて動作するものをサブユニットと呼びます。

コアユニットは、TPIP2ボードと後述するCoMuB(Control Multi-functional Board )基板を組み合わせたもので、電源供給用にバナナコネクタを、モータの制御信号と画像・音声信号の入出力用に50pinのDサブコネクタを使用します。図2にその外観を示します。また、コアユニット筺体には図3に示すように、各ロボットに共通で取り付け可能なレールが取り付けられているため、どのロボットに取り付けたコアユニットも簡単に抜き差しができるようになります。これにより、ロボットの動作不良時に不具合があるかどうかの確認や、故障した部品や基板の交換が容易になり、メンテナンス性を向上させることができました。サブユニットはCoMuB基板とレスコン認定のスピコン基板を組み合わせたもので、コアユニットから受信したデータでモータを制御します。

これらのユニットに使用するCoMuB基板にはTPIP2ボードと通信する機能、他のCoMuB基板と通信する機能、レスコン認定のスピコン基板へモータ制御信号を出力する機能等の機能が備わっています。TPIP2との通信では、TPIP2のシリアル通信信号と10個のPWMポートの信号を使用し、複数のモータの制御情報を1つのパケットとして他のCoMuB基板と送受信を行い制御します。これにより10個以上のモータを同時制御することが可能となりました。このパケット内に記述されている制御モータ数を実際に使用するモータ数にして使用します。今回の救命ゴリラ!!では1台のロボットで最大14個のモータを制御していますが、実装中のファームウェアでは最大50個の制御が可能です。

また、CACSユニットでは各サブユニット自身が必要なデータパケットを選択して受信するようになっています。そのため、他のロボットに使用していたユニットを接続した場合、ハードウェア的な変更をせずにTPIP2-RRCのコンフィグレーションデータの変更を行うことのみで使用可能になります。この変更データはSDメモリに記述することで変更可能です

本選での活用と感想

ファースト・ファイナルミッションでCIMIを使ったところ、オペレーターのコンピュータを全く触らないので、操縦の邪魔にならずスムーズな解析ができました。

昨年、音声点滅パターン解析したときは、操縦者のコンピュータを使って、そのコンピュータで音声データを受信しUSBメモリーに保存。そして別のコンピュータに入っている、音声解析ソフトウエアにデータをコピーし解析開始。という工程で解析していました。さらに、本当に音声データが入ってきているかどうかの確認が、直接ヘッドホンで聞くことができなかったので、「音声が入っているであろう」という、不十分な状態で解析を行っていました。それに加えて、時間的に一度解析に失敗した場合、やり直しができないので、確実な解析が困難で、上手くできませんでした。

しかし今年は、CIMIを用いることで、ダミヤン救助中でもリヤルタイムにダミヤンより発せられる音声を、直接ヘッドセットより聞くことができ、さらに、救助活動中でも音声解析ができたので、精神的にも効率的にもスムーズな解析ができるようになりました。

ベストテレオペレーション賞は、認識情報を一つのコンピュータにまとめて、操縦者とダミヤン識別者を完全に分離して上手く役割分担ができたことについて評価していただきました。

ベストテレオペレーション賞が発表されたときは、我を忘れるくらいうれしかったです。評価内容を聞いたときは、本当に頑張ってよかったという感動がありました。システムを上手く活用して、役割分担ができたのは、各オペレータが識別するときに識別をしやすいように配慮をしてくれたり、識別の練習を手伝ってくれたりと、協力があったからこそです。

システム開発は、かなりの急ピッチで行ったため、今後は、制作したCIMIのプログラムを見直し、来年以降プログラムをする後輩がCIMIのソースコードを見て改良ができるようにしたいです。

本選中にCIMIが上手く動いたので言える事ですが、CIMIのプログラムソースコードは、C++を初めて一から組んだプログラムなので、物凄く見づらく、乱雑に組まれており、コンテスト中バグが起こらなかったのが奇跡ぐらい、適当なプログラムでした。ですから、見やすく整理したいと思います。

そして、制御回路基板CoMu-Bについては、内蔵しているmicroSDスロットを使い、C言語を知っている人が、それを簡単に使えるようにするための、SDファイルアクセスライブラリや、タイマ・割り込み・ADコンバータ・DAコンバータ等を、少しのマイコンの知識で使えるようにする専用ライブラリ等を構築して、他のプロジェクト等でも幅広く使っていただくための準備をできるだけしたいと思っています。

3年間レスコンを通して、私はずっとマイコンを使った回路と制御ソフトウエアの担当をしていました。おかげで、ものすごく膨大な知識を吸収できたと思っています。この膨大な知識を全て後輩に伝承するのは困難だと思いますが、できるだけしていきたいと思っています。

来年以降はレスコンに出場できないと思うので、最後のレスコンとなりました。自分としては、功績を残せたと思っており、自由工房レスキューロボットコンテストプロジェクトに所属できて、とてもよかったと思います。

完成までのスケジュール

2011年12月中頃

初めに、CIMIの開発から取り掛かりました。

しかしCIMIが、私の技術力で完成可能であるかわかりませんでした。そのため、手始めに、専用のネットワーク通信ライブラリを制作して、通信テストを行いました。

2012年2月12日

そのライブラリの通信テストをするため、マイコンカーラリー電通大杯でスタートゴールシステムとして使用しました。結果、ネットワーク通信は正常に動きましたが、通信以外の場所にて重大なバグがあり、あまり使えませんでした。

けれども、その大会前に何度も行っていた、試用テストの結果等も含めて、ネットワーク通信は自分の技術力でも可能であると考え、CIMIの開発を決定しました。

3月〜4月末

次に、CoMu-Bの開発に着手しました。CoMu-Bに使用したマイコンはAtmelのXmega128Aです。このマイコンを使いこなすため、複数の評価ボードを利用して、レスコンで発揮する機能を習得しました。同時にCoMu-Bの仕様を決定しました。

CoMu-Bに使用する回路基板の回路図を制作、基板を発注するためのアートワークを作り、入部先生の指導の下、何とか完成にこぎつけました。

5月上旬〜6月中旬

基板が届くまでの間、必要部品の選定を行い調達。到着してからすぐに部品のはんだ付けをし、12枚の基板を完成させました。ちなみに、この頃からスケジュールに遅れが見られました。

そして、あらかじめ作っておいたマイコンの変数を組み込み、6月初頭に動き、6月中旬に完成させました。予定では6月10日頃の完成でしたが、約1週間遅れての完成となりました。

6月中旬〜

ところが、ロボット本体の制作スケジュールが大幅にずれこんでいました。予定では、ロボットとCoMu-Bが同時に完成して、次のステップに踏み込むはずでしたが、ロボットが未完成。このままでは大会に出場できない事態になりかねないため、制作のサポートをしていました。そのため、ここまで順調に進んでいた回路・ソフトウエアの開発スケジュールは大幅にずれ込み、完成度が下方修正されました。

7月〜本選

予選が終わり、CoMu-Bの改良と、開発が止まっていたCIMIの制作を再開しました。開発期間は2週間です。まず、各オペレータのPCが受信していた画像データを、ひとつのコンピュータにまとめるプログラムを作成しました。

ここで問題が発生しました。データ量が多すぎて、ネットワークが遅くなり、ロボット操作に支障が出る現象と、それによって画像通信が受信できなくなる現象です。この現象の解決に約4日要しましたが、何とか解決しました。

そして、各ロボットから音声データを通信するためのプログラムを作りました。こちらは想定外の問題がなく、順調に完成しました。最後に、別の担当者が制作する予定だった、音声周波数解析プログラムが完成しなかったので、余っている2日間を使い制作しました。かなりの精度を誇っているFFTWと呼ばれる、高速フーリエ変換ライブラリを使い解析をしました。

そして、CIMIが完成しました。大会5日前です。

私は、ここで重大なミスに気がつきました。ミーティングでCIMIを発表したとき、先生より「良いソフトウエアができたからと言っても、ソフトを使う練習をしないと全く意味がない」との指摘をいただいたのです。

考えてみればその通りです。私は残り5日間をデバックにと思っていましたが、音声点滅パターンに関しては、コンピュータを使っての手作業の解析です。ところが、私はスケジュールに練習の日程を組み込んでいなかったのです。

これはまずい、と思い残り3日間必死に音声点滅パターンの解析練習を行いました。初めは2分45秒かかっていた解析が30秒弱での解析が可能となりました。

そして、本選前日にも会場で練習をする機会がありました。

まず初めに、実際のダミヤンを使い、周波数解析をしました。しかし、マイクで音声は取れているのですが、意図しない周波数結果が出力されました。別の人が作ったAndroidアプリのスペクトラムナライザでも同じく違った周波数結果が出ました。レスコンのダミヤン仕様書では「ブザー周波数は 0。5 kHz〜2kHzの範囲で発振する。周波数の最小分解能は0。25kHz(例0。5kHz、0。75kHz、･･･など)」と書かれており、音声周波数測定器を用いて測定したらその結果が出ると読めるので、通常の周波数解析をしていました。

ところが、実際は圧電ブザーにかける電圧信号の事で、圧電ブザーの出力特性上、3khz以下の周波数は低い値となり、他の500Hzから2000HZ周辺の値は、ブザーが鳴っている時と、鳴っていない時との差の変化が、ほとんど見えませんでした

結局、周波数解析はあきらめました。仕様書の書き方には不服がありますが、圧電ブザーの特性を全く理解せず、「普通に音声をフーリエ解析して、一番高い結果が周波数だ」という、浅はかな考えがこの結果を生んだのだと思います。