「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。
ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ
ソフテックでは、C言語プログラミングコントローラeMbedded M@chine-Controller(以降e-RT3)を使った開発をソフテックだより第73号「RTOS対応組み込みコントローラとモーションコントローラによる機械制御」などでいろいろ協力させていただいております。
今回は、横河電機殿から新しく発表されている「e-RT3 2.0マシンビジョン・ソリューション」を試用・評価する機会がありましたので、その構成や開発方法などについてご紹介したいと思います。
まず「e-RT3 2.0マシンビジョン・ソリューション」とは何かというと、e-RT3の最上位機種である「e-RT3 2.0」をベースに、「アナログ画像入力モジュール」、「ユニバーサル・グラフィック表示モジュール」と、「位置決めモジュール」を組み合わせ、画像処理と位置決め制御を1つのコントローラで実現したソリューションです。
画像処理には、当社でも使用しているLinX社製「HALCON」を搭載し、リアルタイムOSには、WindRiver社製「VxWorks」を採用し、豊富な画像処理機能と制御を安定して高速に並列処理することが可能となっています。
つまり、このコントローラの登場によって、今まで画像処理に必要だったパソコンや画像処理コントローラが必須ではなくなります。そこから、省スペース化や小型化、信頼性向上、また、機器間の通信が不要になることによるデバッグ効率などが期待されています。
詳細は、横河電機殿e-RT3 2.0マシンビジョン・ソリューションホームページを参照いただければと思います。
e-RT3 2.0の用途はいろいろあると思いますが、今回紹介するのはe-RT3 2.0のターゲットとして最適であろう画像アライメント処理を想定して、下図基板のアライメントマークを元にした位置決め制御を試してみました。
図1. 基板画像
動作させる処理の流れとしては、
図2. 動作フロー
①基板画像取得
②画像解析
③位置決め
差分座標の調整のため位置決め制御指示
④画像表示
画面へ検出結果表示(部分)
となります。
今回のモジュール構成および使用機器は以下のようになります。
図3. モジュール構成
Slot No | 項目 | 型番 | 備考 |
---|---|---|---|
1 | e-RT3 2.0-CPUモジュール | F3RP62-2L/L1 | |
2 | アナログ画像入力モジュール | F3UM02-0N | |
3 | グラフィック表示モジュール | F3UM01-0N | |
4 | 位置決めモジュール | F3NC34-0N | 2軸使用 |
- | モノクロカメラ | SONY XC_HR90 |
フレームレート:30fps 解像度:1280x960 |
- | パルスモーター×2 | Orientalmotor:CFKシリーズ | モータ:PK543NAW ドライバ:DFC5107P |
- | LCD | IIYAMA | VGA(640×480) 15インチ |
表1. 使用機器
上記のような環境を準備して、カメラ画像取得→画像解析→位置決め制御までを実際に試してみました。
今回は、実際に制御する装置までは準備できなかったため、モータへの指令制御までとしています。
開発の流れは基本的に以下A〜Hの8ステップになります。
図4. 開発の流れ
必要な開発環境は2つあり、一つはVxWorks統合開発環境であるWorkbench、もうひとつはHALCONの統合開発環境である、HDevelopです。
基本的にその2つの環境をそれぞれ使い分けながら開発していくことになります。
まず、開発におけるターゲットとホストの設定を行います。ここでのターゲットとは、e-RT3 2.0CPUモジュール、ホストとは開発用PCを指します。VxWorksのデバッグは、Ethernet経由で実行され、また、シェルはRS-232C経由で使用可能ですので、これらの設定を行います。
プロジェクトの作成は、基本的にはウィザードに沿って設定するだけで完了します。ここで補足ですが、e-RT3はいろいろなミドルウェアやドライバをライブラリとして提供しています。入出力リレー、入出力データレジスタ、CPUデバイス、リンクデバイスへのアクセス機能など、各デバイスへアクセスするための方法は基本的に提供されています。
画像入力プログラムは、PC版HALCONと同じように、HALCON APIを使用することで簡単に取得できます。
e-RT3 2.0ではグラフィック表示用ライブラリWindML(Wind Media Library5.0)がサポートされていますので、WindML APIを使って作成します。
画像解析プログラムを作成するために、カメラから取得した画像をe-RT3 2.0からHDevelop上(開発用PC)で参照できるようにする必要があります。
そこで、まず取得した画像をファイルとしてe-RT3 2.0内に保存します。
次に参照方法ですが、e-RT3 2.0はNFS(Network File System)機能をもっているため、開発用PCからNFS経由でe-RT3 2.0内にある画像ファイルを参照することが可能です。
画像解析プログラムは、ほとんどのHALCON APIがそのまま使えますのでPC版HALCONと同じようにプログラミングが可能です。
画像解析プログラムの作成が終わったら、画像解析プログラムをWorkbenchに戻す必要があります。
HDevelopには、画像解析プログラムのエクスポート機能がありますので、その機能を使用して、Workbenchへ取り込みます。
最後に、制御プログラムの作成ですが、位置決めモジュールへのアクセスも、ライブラリとして提供されていますので、基本的にはパラメータをセットして書き込むことで制御可能です。
以上、簡単に構成や開発の流れを説明させていただきましたが、実際に開発してみた結論として次のように感じています。
e-RT3 2.0のみで画像処理と制御を行えるため、簡単にアライメント処理のプログラミングが可能でした。e-RT3 2.0を使わない場合には、画像処理用のPCやコントローラ、制御用のボードやPLCが別途必要になりますが、e-RT3 2.0であれば1つのコントローラ上ですべて実現できるため、ストレスなく立ち上げができたと思います。
新しく覚えなければならないことがあるのは事実ですが、基本的には横河電機殿から提供されているドキュメントやマニュアルに沿ってやれば1週間程度で立ち上げることができました。
PCを使った場合と比較した時の大きな違いのひとつとして、リアルタイム性があげられます。安定した稼動ができるというのは、PCのように並列処理実行時に予期せぬタイミングで処理時間が変わらないため、時間を計算できる。つまり、時間的な信頼性が高いと感じています。
PCレスの構成が可能となるため、HDDや電源などハードの故障率が下がります。よって、稼働率での信頼性も向上していると感じています。
また、e-RT3 2.0の場合には処理がe-RT3の中で完結しますが、そうでない分散したシステムの場合には各機器との通信が発生します。そのため、一つのコントローラで完結するということは、通信への影響がなくなるということでもあるため、通信レスによる信頼性の向上でもあると考えています。
e-RT3 2.0ではHALCONのAPIは基本的にそのまま使うことが可能でした。
画像解析にはいろいろな調整がつきものですが、HALCONによって簡単に設定可能です。
また、WorkbenchのSystemViewer(タスクやCPU状態の視覚化ツール)を使用すれば、詳細な時間情報が分かるので、デバッグやチューニングにも大きく役立ちました。また、WorkbenchはEclipseプラットフォーム(オープンソースの統合開発環境)をベースとしていますので、静的解析ツールなどいろいろなプラグインも使用可能になっています。
今回は使用しませんでしたが、e-RT3 2.0が提供する機能として、ビデオキャプチャ機能(NTSC)やSDカード、USBホスト機能、ウィンドウオーバーレイなど、さまざまな機能が提供されています。そのため、画像をリアルタイムで確認するや、マウスやキーボードを接続すれば、タッチパネルの代わりとしても使用可能となっています。
以上のように、さまざまなライブラリやデバッグ支援ツールがそろっているので、開発効率があがるのではないか?と期待しています
分散したシステムだと、トラブルが発生した場合どこが原因なのか特定するまでに時間がかかってしまうことが多いと思います。しかし、e-RT3 2.0の場合には、画像解析、制御をすべてe-RT3で行うため、トラブルが発生した場合でも、問題の早期解決へつながるのではないか?と期待しています。
以上のように、e-RT3 2.0は画像解析+制御システムに適していると感じており、開発システム事例で紹介させていただいている「ワーク搬送装置」などは今後e-RT3 2.0で構築されていくことになるだろうと感じています。
(H.K.)
関連ページへのリンク
関連するソフテックだより