本稿では、マニピュレータと移動ロボットという2つの産業用ロボットの制御システムソリューションを比較し、それぞれの特徴を紹介します。
上記の分類はアプリケーション オブジェクトに基づいています。さらに、市場には、非標準機器を制御する、より一般的なモーション コントローラーも存在します。
1 コントローラのボトムレベル ソリューション 1.1 マニピュレータ タイプ マニピュレータ タイプのコントローラは、以前に開発され、比較的成熟しています。既存の制御システムのボトムレベルのソリューションを見てみましょう。 1.2 移動ロボットの種類 移動ロボットのコントローラは比較的新しい方向に属します。産業用移動ロボットには、AGV、無人エンジニアリング機械などの形式があります。制御システムのボトムレベルのソリューションは次のとおりです。
1.3 比較
マニピュレータは精度や動作の安定性に対する要求が高いため、計算量が多く周期が短く、一般に移動ロボットに比べて1～2桁高くなります。一般に、モバイル ロボットには同期精度に対する高い要件はなく、その構成は比較的低くなります。
マニピュレータは通常、固定エリアで動作し、そのコントローラは通常シャーシ内に配置されるため、保護レベルは高くなく、一般に IP20 です。移動ロボットは頻繁に移動するため防水・防塵性が求められ、特に屋外の土木機械では防水・防塵性を考慮する必要があります。保護レベルは高く、通常は IP67 です。
2 CoDeSys の概要 2.1 CodeSys の構成
多くのロボット制御ソフトウェアが CoDeSys を利用して実装されていることがわかりますが、CoDeSys とは何ですか?
CoDeSys は、有料のソフト PLC 開発ソフトウェアです。簡単に言うと、開発システムと実行システムの 2 つの部分で構成されます。開発システムは、プログラミングに使用されるソフトウェア インターフェイスです (Visual Studio、Eclipse、その他のソフトウェアと同様、IDE とも呼ばれます)。 PLC プログラムの設計、デバッグ、コンパイルはすべて IDE で実行され、ユーザーが頻繁に扱う部分です。
PLC プログラムを作成した後、操作のためにハードウェア デバイスに転送する必要があります。ただし、現時点では、生成された PLC プログラムを単独で実行することはできません。特定のソフトウェア環境で動作する必要があります。この環境はランタイム システムであり、ユーザーには見えません。
通常、両者の設置場所は異なります。通常、IDE は開発用コンピューターにインストールされ、ランタイム システムは制御の役割を果たすハードウェア デバイスに配置されます。通常、両者はネットワークケーブルで接続されており、プログラムはネットワークケーブルを介してランタイムにダウンロードされて動作します。
CoDeSys は中国ではあまり知られていませんが、ヨーロッパ、特に産業制御の分野では長年にわたって高い評価を得ています。 KEBA、Beckhoff、Googol、およびほぼすべてのモバイル ロボット コントローラー メーカーなど、上で紹介した多くのロボット企業が同社の製品を使用しています。
CoDeSys を設計した会社 3S は、ハードウェアではなくソフトウェアのみを販売しています。ハードウェア回路はユーザーが設計する必要があり、3S はランタイム システムを顧客のハードウェアに移植する責任を負います。ランタイム システムはハードウェア上で裸で実行できますが、通常はオペレーティング システム上で実行され、オペレーティング システムの構成も顧客の仕事です。
顧客の要求に応じて、CoDeSys の IDE をカスタマイズして顧客のロゴや外観を変更することができます。そのため、メーカーごとに開発プラットフォームが異なって見えるものの、スタイルは比較的似ていることがわかります。
もちろん、ユーザーは他の IDE を使用することもできます。たとえば、ベッコフ氏は Microsoft の Visual Studio を使用していますが、コンパイラの背後にあるカーネルと関数ライブラリは依然として CoDeSys のソリューションを使用しています。
CoDeSys のランタイムは強力な適応性を備えており、ほとんどのオペレーティング システムとハードウェア チップ アーキテクチャをサポートしています。
2.2 CoDeSys ランタイムの原則
CoDeSys の IDE 部分は無料で、公式 Web サイトからダウンロードして体験できます。実際の料金はランタイム システム Runtime System です。
CoDeSys は、設計の初めに、バス プロトコル スタック、ビジュアル インターフェイス、モーション コントロール、安全制御など、機能をいくつかのコンポーネント モジュールに分割しました。ユーザーは必要なモジュールを選択して、ビルディング ブロックのように独自のシステムを構築できます。カスタマイズされた制御ソフトウェア プラットフォームを形成します。
ソフト PLC を初めて使用するユーザーの中には、この部分に馴染みがないと感じる人もいるかもしれませんが、実際にはこの設計方法は非常に一般的です。たとえば、MATLAB Simulink のリアルタイム ツールボックス (Real-Time) はこのように動作します。ユーザーは、Simulink のグラフィカル インターフェイスにドラッグ アンド ドロップして制御プログラムを設計し、実際のハードウェアにダウンロードして実行します。ここでそれについて学ぶことができます。
ベッコフらしいこんな使い方もありですね。ユーザーはTwinCAT IDEでプログラムを作成し、Beckhoffのコントローラにダウンロードします。実際、コントローラーにはランタイムがプリインストールされています。 Siemens STEP7 も IDE であり、その PLC にも一致するランタイムがあります。
ユーザーが作成した PLC プログラムは、コンピューターのアプリケーションに似ています。それはランタイム システム上で実行され、ランタイム システムはオペレーティング システム上で実行されます。
ランタイム システムは、アプリケーションとオペレーティング システムの間に位置します。したがって、ミドルウェアと呼ぶことができます。ロボットソフトウェアではROSやOROCOS(Real-Time Toolkit)などが同様の位置づけとなります。
CNC 工作機械と同様、ロボット制御にはリアルタイム パフォーマンスが必要なため、オペレーティング システムとしてはリアルタイム オペレーティング システム (RTOS) を選択することが望ましいです。残念ながら、Windows や Linux など、私たちがよく使用するオペレーティング システムはリアルタイムではありません。しかし幸いなことに、誰かがそれらを修正、つまりリアルタイムパッチを追加しました。
一般的に使用されるリアルタイム オペレーティング システムには、VxWorks、QNX、Windows RTX、Xenomai、RT Linux、Linux RTAI、WinCE、μC/OS、SylixOs などが含まれます。Windows および Linux オペレーティング システムのユーザーが多いことを考慮して、CoDeSys は対応するリアルタイム パッチ (RTE) により、ユーザーが変更する手間が省けます。
CoDeSys Runtime の詳細については、公式ドキュメント [数学処理エラー] [1][2][1][2] を参照してください。
2.3 CoDeSysの欠点
CoDeSys はコントローラー開発に利便性をもたらし、最初から始める手間を省きます。ただし、CoDeSys などの商用ソフトウェアに基づいて独自のコントローラー製品を開発する場合には、多くの欠点もあります。
(1) 基礎となるアルゴリズムがオープンではない
CoDeSys によって統合されたモーション コントロール コンポーネントとバス プロトコル スタックはすべてカプセル化されています。ユーザーは内部の詳細を理解することも、特定のニーズに応じてカスタマイズしたり最適化することもできません。彼らは単にそれらを呼び出すことしかできません。ユーザーは CoDeSys プラットフォームのみに依存することができ、独自のコア テクノロジーを形成することは困難です。
(2) 機能が限定的で拡張が難しい
マシンビジョン、人工知能、自動運転に代表される新技術は現在飛躍的に進歩していますが、産業制御の技術の多くはまだ20年前のものです。移動ロボットのナビゲーションシーンを例にとると、視覚やレーザーに基づくナビゲーション方法では、大量のデータを収集して処理する必要があり、多くの行列計算が必要になります。
現在、PLC は逆方向 1 次元デジタル計算のみを実行できるため、複雑なアルゴリズムを実装することが困難になっています。人工知能コミュニティのオープンソース スタイルとは対照的に、産業制御コミュニティは互いに閉鎖的です。独自の関数ライブラリを開こうとする人は誰もいません。オープンソース関数ライブラリ (OSCAT) はほとんどありません。最も基本的なフィルタリング アルゴリズムや行列計算でさえ、最初から作成する必要があります。さらに、国際標準が提供する基本機能は限定的すぎて、新しいシナリオにまったく適応できません。彼らは緊急に拡大する必要がある。
(3) 更新が難しい
CoDeSys に完全に依存しているため、顧客独自の製品ハードウェアのアップグレードにはカスタマイズと移植が必要となり、コストが増加します。
3 オープンソース ソリューション
現在、Beremiz、Orocos、OpenPLC、OpenRTM、ORCA などのオープン ソースの制御システム ソリューションがいくつかあります。
ロボットコントローラーの開発は大変な作業です。一連のパフォーマンス要件を明確にする必要があります。その最初の要件はリアルタイム パフォーマンスです。
リアルタイム パフォーマンスは一般に産業用ロボットに必要ですが、サービス ロボットやエンターテイメント ロボットには必ずしも必要ではありません。一般の人は「リアルタイム性」を処理速度や応答速度が速いと誤解しがちですが、実際には「リアルタイム性」とは時間の「確定性」を意味します。たとえば、リアルタイム オペレーティング システム (RTOS) における割り込み応答やプロセス切り替えの遅延時間は、一定の時間範囲内になければなりません。
私たちが一般的に使用しているオペレーティング システム (Windows、Linux) は、スループットを考慮して設計されており、すべてのイベントが特定の範囲内で処理されることを保証できないため、リアルタイム オペレーティング システムではありません。たとえば、標準イーサネットの伝送速度は、リアルタイム産業用イーサネットの伝送速度よりもはるかに高速ですが、データが所定の時間内に伝送されることも保証できないため、これもリアルタイムではありません。
リアルタイムを理解することは難しくありませんが、ロボットのどのタスクをリアルタイムで実行する必要があるのでしょうか?ロボットのパフォーマンス要件 (1ms または 10ms) に従ってプログラムを実行する時間間隔を決定するにはどうすればよいですか?リアルタイムはハードウェアまたはソフトウェアに依存しますか?
リアルタイム (ARM または X86、Linux RTAI または VxWorks) に基づいて特定のハードウェアとソフトウェアを選択するにはどうすればよいですか?インターネット上ではこの点についての深い議論が不足しており、大手ロボットメーカーは試験や実験結果を開示しようとしません。この部分は主に経験と試行錯誤に頼っているようです。
ここで私が提供できるのはいくつかの指標だけです。現在、産業用ロボットアームの制御周期は1ms程度ですが、高性能サーボドライブの位置ループの制御周期は125[演算処理誤差]μsμsに達することもあります。 PLCopen は、プログラミング言語、基本的なモーション制御機能ブロック、入出力インターフェイスのパラメーターなどを含む、サーボおよびモーション制御のいくつかの標準を定義します。 [数学処理エラー] ^{[3]}
[3] 特定の実装コードの詳細は、さまざまな製造元から提供されています。
