LabVIEW の活用により、将棋電王戦用のロボットシステムをわずか１ヶ月半で構築

1. 背景

将棋電王戦は、公益社団法人日本将棋連盟と、ニコニコ動画の開発・配信などで知られる株式会社ドワンゴの主催によって実施されているイベントである。プロ棋士とコンピュータ将棋ソフトとの戦いは高い関心を集めており、2012 年に開催された第 1 回以降、年に 1 回のペースで実施されている。ただ、指し手は確かに将 棋ソフトが決定しているのだが、2013 年の 第 2 回までは駒の操作は人が代わりに行って いた。つまり、コンピュータを人が手助けしているという点で、「人類とコンピュータの戦い」が完全に実現されているわけではなかった。そこで、2014 年の第 3 回では、コンピュータ側の駒の操作をロボットによって行うことになった。そのロボットを供給するメーカーとして選択されたのがデンソーウェーブである。

主催者側から打診を受けた当初は、開発すべきシステムについては仕様と呼べるようなものがまったく存在しなかった。そのため、どのようなかたちで主催者側の要望を具現化するのか、 現実に即したイメージをしっかりと共有することから始める必要があった。認識の共有を進め、 現実的な解を探っていった結果、図 1 のようなかたちでシステムを構築することになった。その構成要素は、将棋ソフトが稼働する PC、サーバ、指し手の情報を受け取る PC、プロ棋戦専用ロボットアーム（以下、ロボットシステム） である。これら以外の要素としては、将棋盤、駒、 棋士側の駒をとったときにその駒を置いておく置台、「成り」に対応して駒を裏返す操作に使用する反転台が存在する。

このなかで中核的な存在となるロボットシステムでは、次のような駒の操作を実現する必要があった。

• 駒を置く操作：将棋ソフトが指定したコンピュータ側の駒をピックアップし、将棋ソフトが指定したマスに配置する
  
• 棋士側の駒をとる操作：コンピュータ側の駒を置く前に、棋士側の駒をピックアップして置台に移動する
  
• 置台にある駒を置く操作：置台の上にある駒をピックアップし、将棋ソフトが指定したマスに打つ
  
• 「成り」の操作：将棋ソフトが決定した手が「成り」である場合には、将棋盤上の駒をピックアップし、それを反転台にいったん移動して裏返したうえで将棋ソフトが指定したマスに配置する

上記の機能を実現するうえで、駒の移動については産業用途向けのロボット（ロボットアームとロボットコントローラから成る）を使用することにした。また駒のピックアップ/ 配置には、バキューム装置（真空用コンプレッサ）を使用する。加えて、駒の種類を識別するためには画像認識技術を適用することにした。つまり、カメラを使用したビジョンシステムを構築するということである。画像認識を行ううえでは、対象物を光で照らすことが重要なので、照明装置も必要になる。さらに、棋士の安全を確保するため（詳細は後述）に、エリアセンサも使用することにした。ロボットのプログラミングはデンソーウェーブが行うが、このシステムには、PC からの制御やビジョンの制御といった要素も含まれている。そこで、PC による制御に長けており、デンソーウェーブのロボットの制御にもすぐに対応できる企業として、マックシステムズが参画した。さらに、主に画像処理を担当する協業企業として松浦電弘社も加わった。

2. 課題

この案件には、当初から1 つの大きな課題が存在していた。仕様がまったく見えないところから始まるようなプロジェクトであったのにもかかわらず、非常に短い開発期間しか許されていなかったのである。

将棋電王戦は、5 人の現役プロ棋士と5 種のコンピュータ将棋ソフトの団体戦という形態で行われる。その第1 局が行われるのは2014 年3 月15 日と決まっていた。ところが、デンソーウェーブがこの案件を受託すると決まったのは2013 年12 月末のことだった。マックシステムズや松浦電弘社との協業が決まったのはその後の話であり、仕様が定まってきたときには、すでに2014 年1 月末となっていた。実際の開発作業には、その後の1 ヶ月半しか残されていなかった。

このような超短期開発に対応しなければならないことだけでも大きな問題である。しかし、実際のプロジェクトでは、産業用途向けの通常の案件ではありえないさまざまな条件が次々と発覚していった。以下に、代表的な例を列挙する。

• 手作りの駒しか使用できない：コンピュータ側の駒の操作として、例えば「2 八のマスにある『銀』を移動する」場合には、「2八」のマスにある駒が確かに「銀」であるということを画像認識で確認する。ところが、駒はすべて手作業で作られているため、同じ「銀」でも、1 個1 個の寸法や各面の角度が異なっている。しかも、「銀」の文字も手書きなので、1 個1 個に微妙な違いがある。こうした条件に対応するために、パターンマッチング用に通常よりも複雑なアルゴリズムを考案しなければならなかった
  
• 棋士の駒は一定の位置に配置されない：棋士は各マスの中に駒を置く。しかし、具体的にマスの中のどこの位置に置かれるかは一定ではない。マスに対して駒がどのような角度で配置されるかも、その都度異なる。そのため、棋士が打った駒をとる際には、その位置や角度を画像で認識し、駒の中心を狙ってとりにいくという補正処理を行う必要がある
  
• 手作りの将棋盤しか使用できない：通常の産業用アプリケーションであれば、ロボットアームによる移動の対象物が置かれる平坦な台には厳密な寸法図面が存在し、それを基にして移動位置が厳密に決定される。しかし、将棋盤は手作りなので寸法図面は存在しない。しかも、表面は必ずしも平坦ではないし、まったく同じ寸法のものは1 つも存在しない。常に1 つの将棋盤を使い続けることが主催者側から認められたので問題は緩和されたが、このような条件は産業用途ではあり得ないものであった（なお、画像処理についても、同じ駒を使い続けることが認められたので、認識/ 補正が成り立っている）
  
• 設置場所が毎回異なる：ロボットシステム、将棋盤、置台、反転台の位置関係は、常に一定でなければ正確な操作を行うことができない。通常の産業用システムであれば、一度設置した場所から移動することはないため、この条件を満たすのは容易である。ところが、電王戦は第1 局から第5 局までがそれぞれ異なる会場で行われる。そのため、各会場のエレベータや通路などに収まる大きさに分割できるようシステムを設計し、現地で正確な位置関係が再現できるように組みなおさなければならなかった。しかも、畳、絨毯、表面が平坦ではないコンクリートなどの上に設置しても、まったく同じ動作が安定して行われるようにする必要があった
  
• 背景や照明の条件が画像認識に適していない：画像認識の成否は、照明と背景の条件に強く依存する。通常、対象物が白色系である場合には、背景には濃い色を使用するといったことが行われる。ところが、今回の背景は、駒と同じく木でできた将棋盤以外にありえなかった。しかも、実施会場が毎回異なることから、照明だけでなく、外乱光などの光の条件も一定ではない。こうしたことも、産業用途ではありえない条件だった
  
• 棋士の安全を確保しなければならない：本来、人とロボットが共存する状態は安全性の観点から許されるものではない。やむを得ず共存させる場合には、人はヘルメットを被り、いつでも非常停止ボタンを押せるようにしておく必要がある。しかし、対局の場をそのような環境にすることはできないので、このアプリケーションでは、エリアセンサで棋士を監視し、許容できないところまでロボットアームに近づいたらシステムが非常停止するようにした
  

このように、電王戦向けロボットシステムの開発には、産業用アプリケーションの開発に携わっている技術者にとっては想定外の課題が遍在しており、それらが次々に表面化するという状態だった。それにもかかわらず、1 ヶ月半のうちに開発を完了しなければならなかった。

3. ソリューション／効果

上述したさまざまな課題を解決するうえで鍵に なったのが、グラフィカルシステム開発プラットフォームであるLabVIEW だ。電王戦向けの ロボットシステムは、具体的には図2 のようなかたちで構築した。構成要素は先述したとおりだが、あらゆる制御の中核として、LabVIEW が稼働するWindows ベースのPC を使用している点がポイントである。

ロボットアームの動きの制御は、そのためのプログラムを搭載したロボットコントローラによって行う。このシステムでは、デンソーウェーブ製の垂直多関節ロボットアーム「VS- 060」とロボットコントローラ「RC8」を採用した。この RC8 は、アプリケーションソフトウェア向けのプラット フォームとしてORiN（Open Robot/Resource Interface for the Network） を搭載している。そして、NI は、デンソーウェーブ製品で稼働するロボットプログラムと LabVIEW の連携を可能にするものとして、ORiN に対応するLabVIEW Robotics Library for DENSO を提供してい る 。これを利用することにより、LabVIEW と ロボットコントローラの接続が非常にスムーズ になり、シンプルな制御を実現することができ た。このことから、開発時間を大幅に短縮することが可能になった。

また、図2 に示したように、ロボットコントローラはロボットアームのほかに、バキューム装置、 エリアセンサにも接続されている。しかし、ロボットコントローラは、これらの制御の主体として機能するわけではない。実際の制御を担っているのはLabVIEW ベースのプログラムであり、ロボットコントローラはそのプログラムから送られてきた指示に従って動作しているだけだ。また、図に示したとおり、カメラと照明装置の制御もPC 上のLabVIEW ベースのプログラムによって行う。つまり、ロボットアームの 動き以外の制御は、LabVIEW ベースのプログラムに集約されているということである。

さらに、画像認識に関連するあらゆる処理も LabVIEW によって実現した。テキストベースのプログラミング言語とは異なり、LabVIEW であれば熟練度が低い若年層の技術者でも十分に使いこなせる。基本操作としてはアイコンをワイヤーでつないでいくだけなので、テキストベースのプログラミング言語を使う場合にあり がちな単純なコーディングミスは発生しない。 また、デバッグを行う際にも、あらゆる情報が視覚的に示されるので、どこに問題があるのかを容易に理解できる。問題点を即座に修正して、 すぐに再実行することも可能だ。このデバッグの容易さが、今回のプロジェクトでも有効に働いた。

今回の構成では、デバッグ作業をPC 上の LabVIEW 環境で完結させることができる。 LabVIEW 環境に1 つのプログラムだけが存 在する状態になるので、各構成要素間のハンドシェイクの確認作業などはほとんど行う必要がない。制御の主体としてPC を使用し、必要なソフトウェアをLabVIEW に集約することで、 産業用途で使われている既存の技術をそのまま流用して短期開発を実現することができた。通常の産業アプリケーションと同じようなシステム構成では、納期までに開発を完了することは 不可能だったであろう。

このようにして、基本的な開発作業は1 ヶ月ほ どで完了することができた。その後、テストの段階になり、このアプリケーション特有の課題を半月間のうちに解消していった。手作りの将棋盤や駒に起因する画像処理の問題なども、このテストの段階で解消した。このテスト/ 改善 のフェーズでも、LabVIEW が非常に有効に機能した。

このアプリケーションの場合、設置場所が毎回異なることから、現場での微調整がその都度必要になると考えられた。例えば、照明の条件なども会場ごとに異なるので、現場にシステムを設置してから微調整を施さなければならない 可能性があった。そうした場合でも、現場での条件に応じ、フィルタ処理やエッジ処理など、 LabVIEW にあらかじめ用意された膨大な関数 の中から必要なものを選び、その場で適用することができる。つまり、LabVIEW をベースとしたシステム構成にしておけば、現場であらゆる条件に対応することが可能になるということだ。短期開発が求められていたことに加え、そうした臨機応変な対応も必要であったことから、PC 上のLabVIEW 環境ですべてを管理する方法でなければ、プロジェクトを成功に導くことはできなかったと言える。

4. 今後の展開

例えば、PC を使って設備を制御したい、あるいは研究/ 開発で使用しているものをそのまま製造現場でも使いたいといったケースはよくある。そうした場合にも、今回のロボットシステ ムと同様に、PC とLabVIEW の組み合わせが 有効に機能するはずだ。実際、デンソーウェーブやマックシステムズは、ロボット、ORiN、 LabVIEW を組み合わせた製造ライン向けソリューションの提案を行っているところだ。 PC とLabVIEW を使ったロボットシステムを 構築したことから、さまざまな可能性が見えてきた。NI のPXI 製品も組み合わせれば、ロボットによる操作に伴って発生する電波や振動などの情報を取得する計測アプリケーションなども容易に実現できるだろう。

著者情報:

鈴木 達也 氏
株式会社デンソーウェーブ 営業部 中部支店 係長
Japan