1.2 HARKの設計思想

ロボット聴覚ソフトウエアHARKの設計思想を以下にまとめる．

入力から音源定位・音源分離・音声認識までの総合機能の提供：ロボットに装備するマイクロフォンからの入力，マルチチャネル信号処理による音源定位，音源分離，雑音抑制，分離音認識にわたる総合性能の保証，
ロボットの形状への対応：ユーザの要求するマイク配置への対応と信号処理への組込，
マルチチャネルA/D 装置への対応：価格帯・機能により多様なマルチチャネルA/D装置をサポート，
最適な音響処理モジュールの提供と助言：信号処理アルゴリズムはそれぞれアルゴリズムが有効な前提を置いており，同一機能に対して複数のアルゴリズムを開発し，その使用経験を通じて最適なモジュールを提供，
実時間処理：音を通じたインタラクションや挙動を行うためには不可欠である．

このような設計思想の下に，オープンソースとしてHARKの公開を行ってきた．改良，機能向上，バグフィックスには， HARK Forum ¹ に寄せられたユーザからの声が多く反映されている．

$\includegraphics[width=0.95\linewidth ]{fig/Intro/Stacks}$

Figure 1.1: ロボット聴覚ソフトウエアHARKとミドルウエアFlowDesigner，OSとの関係

HARK は，図1.1に示すように，音声認識部(Julius, Kaldi) やサポートツールを除き， HARK middlewareをミドルウエアとして用いている (なお，ver 2.5 までは， FlowDesigner [2] を利用していた)．

$\includegraphics[width=.95\linewidth ]{fig/Intro/HARKDesignerNetwork}$

Figure 1.2: HARKを用いた典型的なロボット聴覚のモジュール構成

1.2.1 ミドルウエア HARK Designer

ロボット聴覚では，音源定位データを基に音源分離し，分離した音声に対して音声認識を行うことが多い．各処理は，アルゴリズムが部分的に置換できるよう複数モジュールで構成する方が柔軟である．このため，効率のよいモジュール間統合が可能なミドルウェアの導入が不可欠である．しかし，統合するモジュール数が多くなると，モジュール間接続の総オーバヘッドが増大し，実時間性が損なわれる．モジュール間接続時にデータのシリアライズを必要とするCORBA (Common Object Request Broker Architecture) のような一般的な枠組みではこうした問題への対応は難しい．実際，HARK の各モジュールでは，同じ時間フレームであれば，同じ音響データを用いて処理を行う．この音響データを各モジュールがいちいちメモリコピーを行って使っていたのでは，速度的にもメモリ効率的にも不利である．

このような問題に対応できるミドルウエアとして，我々は，データフロー指向のミドルウェアHARK middleware を開発した． HARK middleware は，それまでミドルウェアとして用いていた FlowDesigner [2] の機能向上版であるが，中身はスクラッチから再実装している． HARK middleware は，従来の FlowDesigner と同様に， ROS や CORBA等汎用的なモジュール統合のフレームワークと比較して，処理が高速で軽い．

FlowDesigner は，単一コンピュータ内の利用を前提とすることで ²， ³．高速・軽量なモジュール統合を実現するフレームワークであったが， HARK middleware は，複数台のコンピュータを使って分散処理を行うことも考慮した実装となっている．実装言語は，FlowDesigner は C++ のみで実装されていたのに対し， HARK middleware は，C++ と pyhton の組み合わせとなっている． FlowDesigner と比較すると，オーバヘッドは増大しているものの，最小限に抑えるよう実装している．また，モジュールの実装については，完全に FlowDesigner とコンパチブルであり，これらのクラスは，共通のスーパークラスを継承した C++ のクラスとして実現される（HARK-Python を用いれば pyhton でモジュールを記述することも可能）．このため，モジュール間のインタフェースは自然と共通化される．モジュール間接続は，各クラスの特定メソッドの呼び出し（関数コール）で実現されるため，オーバヘッドが小さい．データは，参照渡しやポインタで受け渡されるため，前述の音響データのような場合でも，高速にかつ少ないリソースで処理できる．つまり， HARK middleware の利用によって，モジュール間のデータ通信速度とモジュール再利用性の両立が可能である．

$\includegraphics[width=.7\linewidth ]{fig/Intro/GHDSSProperty3}$

Figure 1.3: GHDSS の属性設定画面の例

$\includegraphics[width=.5\textwidth ]{fig/Intro/ASIMO-Robovie-ears.eps}$

Figure 1.4: 3種類のロボットの耳（マイクロフォン配置）

HARKを用いた典型的なロボット聴覚に対する HARK middleware 用のネットワークを図1.2に示す．ファイル入力によりマルチチャネル音響信号を取得し，音源定位・音源分離を行う．得られた分離音から音響特徴量を抽出し，ミッシングフィーチャマスク (MFM) 生成を行い，これらを音声認識 (ASR) に送る．各モジュールの属性は，属性設定画面で設定することができる（図1.3は GHDSS の属性設定画面の例）．

HARKで現在提供している HARK モジュールと外部ツールを表 1.1 に示す．次節では，各モジュールの概要をその設計方針とともに説明をする．

1.2.2 入力装置

HARK では複数のマイク(マイクアレイ)をロボットの耳として搭載して処理を行う．ロボットの耳の設置例を図4に示す．この例では，いずれも8チャネルのマイクアレイを搭載しているが，HARK では，任意のチャネル数のマイクアレイが利用可能である． HARKがサポートするマルチチャネル A/D 変換装置は，下記のとおりである．

システムインフロンティア社製，RASP シリーズ，
ALSA ベースの A/D 変換装置，例えば，RME 社製 Hammerfall DSP シリーズ，Multiface AE．
Microsoft Kinect
Sony PS-EYE
Dev-Audio Microcone

これらのA/D装置は入力チャネル数が異なるが， HARKでの内部パラメータを変更することで対応できる．ただし，チャネル数が増加すれば，処理速度は低下する．また，量子化ビット数は16ビット, 24ビットの両方に対応している． HARKの想定するサンプリングレートは，16kHzであるので，48KHzサンプリングデータに対しては，ダウンサンプリングモジュールが用意されている．なお，東京エレクトロンデバイス社製 TD-BD-16ADUSB（USBインタフェース）は，サポートするカーネルのバージョンが古いため，HARK 1.2 からサポート対象外となっている．

マイクは，安価なピンマイクで構わないが，ゲイン不足解消のため，プリアンプがあった方がよい． RME社製からは OctaMic II が販売されている．ヤマハ製のマイクロフォンアンプの方が，収録音のノイズが少ないようである． TD-BD-16ADUSB や RASP は，プリアンプおよび，プラグインパワー対応の電源供給機能を有しているので，使い勝手がよい．

Footnotes

https://wp.hark.jp/forums/
コンピュータをまたいだ接続は，HARK における音声認識との接続部のようにネットワーク接続用のモジュールを作成することで実現可能である．
FlowDesignerのオリジナルは， http://flowdesigner.sourceforge.net/ から， FlowDesigner 0.9.0 の機能向上版は，https://www.hark.jp/ からそれぞれダウンロードできる．