rsj2013 sekiyama 1
TRANSCRIPT
RTルームデモシステムにおけるRaspberryPiの
連続運用のための予備評価
○関山守(産総研) 鍛冶良作(産総研) 安藤慶昭(産総研)
村上青児(筑波大学) 梶谷勇(産総研) 阪口健(産総研)
神徳徹雄(産総研) 谷川民生(産総研)
1
目次
• RTシステム構成へのRaspberryPi導入の意義
• RTルームデモシステム
• RaspberryPiによる機能の代替導入評価
– RTミドルウェアに関わる導入例
– それ以外での導入例
2
RaspberryPi 特徴
• Linuxワンボードマイコン:名刺サイズ – 低価格（3000円前後） – Linuxが動作（Debian, Fedora, Arch Linux） – CPU：ARM11/700MHz
– メモリ：512Mバイト
– ストレージ：SDカード
– GPIO, I2C, UART, SPI
– GPU, HDMI出力
– 専用カメラ
• セットアップが簡単
• セルフコンパイルが可能
• PIC部分もPC部分も置き換え可能
• CANへの拡張も可能
•
CANボード搭載RaspberryPi 専用カメラ搭載RaspberryPi RTシステムへの導入？
3
RTシステムへのRaspberryPi導入
拡張性が高い
GPIO, SPI, I2C, UART
PC上で動作するLinuxと差がない
apt-get によるパッケージ取得
gcc, make, cmake, git, svn
OpenRTM-aist 価格が安い
価格の割に高性能： 費用対効果
RTシステムへ導入できる信頼性はあるのか？
仮に導入できた場合の費用対効果は「革命的」 ArmadilloやPCの1/10の価格
若干信頼性が低くても、多重化などで補える？
サイズが小さい
ほぼ名刺サイズ
RaspberryPi導入について評価を行う意義
4
どこでRaspberryPiを評価するか？
RTルーム 目的：RTミドルウェアの利用、RTコンポーネントの作成教育・評価・開発
過去研究の資産であるRTコンポーネントが利用可能
ネットワークを介してデモの状態が確認可能
5
インタラクション系RTC群 センシング系RTC群
モニタ・表示系RTC 家電・窓制御RTC群
入退出管理RTC群
Web表示 窓開閉制御
家電制御
RFIDによる
人状態検出
人感センサ
音声合成 音声認識
タブレッド
玄関ドア制御
シナリオコントロールRTC
制御シナリオRTC
制御シナリオRTC
制御シナリオRTC
RTルーム
6
恒常的に動作しているコンポーネント
センサ サービス提供
7
RTルームの特徴
• RTコンポーネント開発
• RTコンポーネントの動態展示 – 常時30個以上のコンポーネントが動作
• 通信経路：有線LAN, 無線LAN, PLC, CAN, ZigBee, Bluetooth
• 動作環境：PIC, SH2, SH4, Armadillo, iOS Device, PC(Windows, Ubuntu)
• 開発言語：C(C++), Python, C#
• OpenRTM：MiniRTC, MicroRTC, RTC-Lite, .NET版, aist版
• ロバスト性の維持が難しい – 系全体でみればロバストであるが、特定の弱点を持つシステム
Ex. 旧世代PLC使用部分は電源ノイズに弱い
• 開発効率が悪い・メンテナンスが難しい
多様性
ヘテロなシステム
開発が難しい
代替が効かない
8
RaspberryPiによるRTルームでの
機能の置き換え • 対象：
– RTルームのように環境やコンポーネントが様々に入り組んだヘテロなシステム
• 追加目的： – ヘテロなシステムをRaspberryPiで「フラットなシステム」に置き換える
• 評価1： – 対象システムの機能をRaspberryPiで置き換えることが可能かを評価
• 評価2： – RTシステムへRaspberryPIを導入可能かどうかを評価
• ポイント – PIC， 組込用途マイコンを置き換え可能？
• MiniRTC, MicroRTC, RTC-LiteをすべてフルLinux+通常RTCで置き換え可能？
– 信頼性はどうなるのか？： • 信頼できるのであれば強力
– 二重化が可能
– 交換が簡単
– 開発が簡単
– 動画によるデモ確認のような負荷の高い機能を置き換え可能？
｝ 本当にそうであるのか？
9
今回の報告における
実際に行った評価内容
• RTコンポーネントのビルド・RTコンポーネントサーバとしての機能代替 – 実際にLinux, Windowsの上で動作するコンポーネントをRaspberryPi上に移植
– 複数を一度に動作させての負荷チェック
– 3か月ほど断続的に動作させて確認
• 全体のデモを管理・運用する機能部分での代替 – USBカメラ＆Webカメラによるデモの確認
– Webサーバ&Webクライアント
– リモートデスクトップでのデモ実行
10
評価：RTコンポーネントサーバ
• デモシステム内で動作するRTコンポーネントをRaspberryPi上でビルドする
• RaspberryPi上にてネームサーバと12個のRTコンポーネントを動作させる
– Webサーバ：Apache2も同時に動作
→CPUの負荷率は30％程度であった
11
評価：RTコンポーネントサーバ
• Linux(Ubuntu)で動作していたコンポーネント：修正無しでビルド・動作
• Windowsで動作していたコンポーネント：若干の修正でビルド可能・動作
• 3か月の断続動作後も特に問題もなく動作することを確認
• ただし、ネットワーク（有線LAN、USBドングルを用いた無線LAN）の部分のエラーはよく起こる – これらのエラーを前提に入れたうえで、システムを設計する必要がある
コンポーネント内容 動作周期
エリア型赤外線人感センサによる人検出データ受信 5msec
エリア内滞在人数把握 200msec
温度・湿度センサの値からWBGT値を算出 500msec
複数デモシナリオ間の調停，人間からの入力を受信 333msec
各種センサ値，トイレ転倒アラートをWeb出力 1000msec
ベッド設置RFID人感センサ信号出力 1000msec
トイレ設置RFID人感センサの信号をデータ出力 1000msec
ドアの鍵，開閉状態，各種人感センサ，Felica用RFタグリーダの値から施錠等を行うセキュリティシナリオ
1000msec
ドアの鍵，各種人感センサ，Felica用RFタグリーダの値から人間の在室状況，夜間起床回数等のデータを出力
500msec
温度センサ値から，窓・空調用家電機器を操作する空調シナリオ 1000msec
人感センサ値から起床時の電灯，機器等の操作を行うシナリオ 333msec
各種人感センサ値から夜間転倒予防と電灯の点消灯を行う見守りシナリオ 125msec
12
評価：全体のデモを管理・運用する
機能部分での代替
• Webカメラによる動画サーバー機能をRaspberryPi+mjpg-streamer+USBカメラで代替 →フレームレートは10fpsを超えないが特に遅延もないため、適用場所を選べば動画サーバーとしても扱える
• Webクライアントによる画像データ表示処理をRaspberryPi+XWindow+Midoriで代替 →1秒ごとに自動更新がかかるページでpng画像（センサ値のグラフ）を表示させたところ、特に遅延もなくページを表示した。Webクライアントとしても十分扱える
• リモートデスクトップでのWindows画面の表示処理をRaspberryPi+XWindow+rdesktopで代替 →画面の変化への追従もマウス入力をWindows側へ伝達する処理も非常に遅く使い物にならないレベル、動作していることが確認できるだけ
13
結論
• 処理能力：高い – そこまで負荷の高くないRTコンポーネントであれば10個以上を周期実行させることが可能
– 動画配信のような負荷の高そうなタスクであってもそれなりの処理が可能
• 信頼性：微妙 – これまでに10個程度のRaspberryPiを操作したが初期不良は1個、使用中にUSB&有線LAN用チップ(SMSC LAN9512)が破損したものは1個
– ネットワーク（Ethernet）の断絶にケアが必要
→Armadilloのような信頼度の高いボードを簡単に置き換えるのは問題あり
• 二重化（RaspberryPiのみでの並列，他のシステムと並列）などで信頼性を担保することは必須
14
まとめ • RaspberryPi＝低価格
– RaspberryPiをRTシステムに組み込むことで得られるアドバンテージが大きい
→RTルームデモシステム内でRaspberryPiを評価
• RaspberryPi上で10個を超えるRTコンポーネントの安定動作を確認
• 動画配信とWebブラウザ，リモートデスクトップの動作検証 – リモートデスクトップの動作：実用が難しいレベル
– その他の用途：実用レベルと判断
• ただし、信頼性については若干の問題あり
• FutureWork：RaspberryPiをさらに評価する – 二重化（多重化）による高信頼化は可能か
– OpenCV関数のような高負荷モジュールのRTコンポーネント化は可能か
– PIC, 組込み専用マイコンを用いたシステムの代替は可能か
15
ご清聴ありがとうございました
16