Contents
APIを使った機器制御の試み
1.APIを使った機器制御への展開
初めに「APIを使った機器制御への展開」に関して説明します。図1に一般的なWeb APIを使った情報取得の図を示します。この前の記事でAPIを使ったクラウドからのデータ取得に関して説明していますが、 APIと言えば、一般的にはクラウドやサーバ上のデータベースからデータを取得する際に使用するインターフェースの決まり事です。ユーザーがHTTP requestを使ってAPIをクラウドやサーバに投げると、レスポンスとして、データが送られてくるという1対1のやり取りで使用されるます。
このAPIを機器の制御に応用すると便利だと考えられます。現状は、機器へのコマンドはメーカーや機器によって異なります。そのために、機器の制御は個別にプログラムを作成して行う必要があります。これを、例えば、ベルトコンベアであれば、動作ON/OFF、回転方向、回転スピード、移動距離など共通する仕様をAPIとしてJSONフォーマットで規定することで、共通化ができ、メーカーや機器を変えることで動作プログラムの基本部分の大きな作成変更が必要なくなります。また、追加の仕様は、JSONで追加していけば良いです。
図2に「APIの機器制御への展開」の図を示します。
さらに、このAPIによる機器制御をMQTTを使って、1対多に展開するとさらに利便性が上がると思います。MQTTのトピックを機器ごとに分けて、ユーザーのPC（これは、クラウドのVMでもOK）からMQTTに機器制御のAPIをパブリッシングして、機器のマイコンがトピック毎にサブスクライブして動作を行うという展開が考えられます。MQTTに関しては、こちら(MQTTによるデータ送受信)を参照ください。図3にイメージの図を載せています。この絵では別々の機器で描いていますが、同じ機器を複数でも問題ありません。WiFiを受信できるマイコン(ESP32など）を機器につなげることでAPIを取得、機器制御を行います。
2章「ベルトコンベアのAPI検討」と3章「2軸カメラ駆動機のAPI制御」で、1対1の機器制御のAPIを考えてみます。
4章で、MQTTを介した1対多の機器制御のAPIを考えてみたいと思います。
2.ベルトコンベアのAPI検討
2-1.ベルトコンベアの動作要素
ベルトコンベアの動作要素は、以下の項目に分けられます。
これから、APIとしては、以下の4つが考えられます。
{“動作”:”ON” or “OFF”}、{“方向”:”normal” or “reverse”}、{“速度”:xx}、{“距離”:yy}
2-2.ベルトコンベアの識別
動作以外にも複数のベルトコンベアがある場合は、どのベルトコンベアに対するコマンドなのかを指示する必要があります。
そのためのAPIとして、{“id”:zz}を準備します。
2-3.APIの整理
ベルトコンベアの識別用の項目“id”は必ず必要です。しかし、その他のAPI項目に関しては必ずしも毎回すべて伝える必要はありません。
例えば、{“動作”:“OFF”,“方向”:”normal”,”速度”:20}の場合のように動作を止める場合には、”方向”と”速度“は不要です。また、{“動作”:”ON”,”方向“:”reverse”,”速度”:10,“距離”:20,“距離”:1}と指定した時には、{“動作”:”OFF}は不要です。指定した距離に達した時点で停止することがベルトコンベアに求められています。
また、変更が無ければ毎回送る必要もないと考えられます。ただし省略する場合には、動作モードの考え方が必要になります。
これらの観点からAPIを整理すると以下の様になります。
2-4.応答のAPI
送ったAPIの実行が完了した旨、ベルトコンベアから応答が必要になります。特に、距離モードの場合は必須です。
完了のAPIとしては、
{“id”:zz,”処理”:“OK” or “NG”}
NGの場合には、動作を止めたうえで応答をしてくる必要があります。
3.2軸カメラ駆動機のAPI制御
3-1.目的
バイポーラ ステッピングモータ2個とドライバL64702個をつかって、カメラの2軸駆動機を試作した。この2軸駆動機の動作制御用のAPIを作成し、Node-REDを使って動かしてみます。
2軸カメラ駆動機のハードに関しては、こちら「2軸カメラ駆動機」をご覧ください。
3-2.2軸駆動機の動作要素
2軸駆動機の動作要素は、左右(水平)方向と上下(垂直)方向に分けられます。それぞれ以下の動作要素を持ちます。
これから、APIとしては、以下の4つが考えられます。
{“動作”:”ON” or “OFF”}、{“方向”:”右(上)” or “左(下)”}、{“速度”:xx}、{“角度”:yy}
3-3.APIの整理
左右と上下の識別用の項目“id”は必ず必要です。左右回転(1軸)を id=0、上下回転(2軸)を id=1とします。また、ドライバへの命令で、動作許可時には、方向指示が必要なため、動作許可と方向指示はペアになります。angleを指定した場合には、指定した角度分動作すると停止します。しかし、angleを指定しない場合には、{“operation”: “stop”}で止めないと止まりません。
これらの観点からAPIを整理すると以下の様になります。
Node-REDのフローに実装する際には、idを配列にしたjsonフォーマットにしました。
3-4.応答のAPI
送ったAPIの実行が完了した旨、ベルトコンベアから応答が必要になります。特に、角度モードの場合は必須です。
完了のAPIとしては、
{“id”:zz,”result”:“OK” or “NG”}
NGの場合には、動作を止めたうえで応答をしてくる必要があります。
3-5.Node-REDの制御フロー
2軸駆動機の動作制御を行うNode-REDのフローを以下に示します。
1) 初期設定で、Node-RED起動時に初期の設定を行います。
2) Operation Modeの部分で、switchノードを使用して動作のモードを切り替えます。
結果をtextノードで表示しています。
3) Speed settingで、スピードの設定を行います。1軸と2軸は同じスピードにしています。
sliderノードとtextノードを使用しています。
4) Angleの部分で、angularモードの時のHorizontal方向とVertical方向の回転角度を指定します。ここもsliderノードとtextノードを使用しています。
5) Directionの部分でongoingモード時にどの方向に動作させるのかを指定しています。
angularモード時には、いずれかを押すと指定した角度で動作を開始します。
buttonノードとfunctionを使って、flowの設定を変えています。その後flowを読み出し、出力します。
3-6.操作画面
中段にあるMode selectスイッチで、ongoingモードを選択します。
1) ongoingモード
Speedを設定して、8方向のいずれかのボタンを押すと動作を開始します。
中央の停止ボタンを押すまで動き続けて止まりません。
API出力例：右上を選択、speed6
{“id”:[{“mode”:”ongoing“,”direction”:”right“,”speed”:6,”angle”:0},{“mode”:”ongoing“,”direction”:”up“,”speed”:6,”angle”:0}]}
2) angularモード
speedとHorizontal(左右)とVertical(上下)の角度を設定して、右上,右下,左上,左下の4つのボタンのいずれかを押します。
設定した角度まで1軸2軸ともに動作をして止まります。
API出力例：左右 90°、上下 -80° speed 4を設定
{“id”:[{“mode”:”angular“,”direction”:”right”,”speed”:4,”angle”:90},{“mode”:”angular“,”direction”:”up”,”speed”:4,”angle”:-80}]}
４．１機器内の多チャンネル制御
制御される機器は1台だが、上述した2軸CAMのように、対象となる駆動部分が機器内に2つ以上ある場合、それぞれにたいして順番に操作するのか、同時に操作するのか。それぞれについて、解説します。
まず、順番に操作する場合は、以下の手順になります。
ホストから動作信号を受ける➡第１駆動部（第１軸）に対して動作信号を送る➡第１駆動部の動作完了を機器内で確認した後、第２駆動部（第２軸）に動作信号を送る（この時点では、ホスト側に信号は送らない）➡第２駆動部の動作完了後、ホスト側に動作完了コードを返信する
一方、同時に操作する場合には、次の手順になります。
ホストから動作信号を受ける➡第１、２駆動部（第１、２軸）同時に動作信号を送る➡すべての駆動部の動作完了後、ホスト側に動作完了コードを返信する
具体的に第3章で説明したAPIを使って、説明します。ホスト側からの動作のAPIは、以下の様です。
例として、ホスト側から、以下のAPIが来たとします。
それぞれの機器は、以下の様に動作します。
５．MQTTを使った１対多制御
ここでは、MQTTを介した機器制御のAPIの検討を行いたいと思います。2章、3章、4章との違いは、1対多の制御(図4参照)になることです。そのため、複数のAPIをMQTTブローカーに対してパブリッシング(発行)する必要があります。それぞれの機器は、サブスクライブ(購読)しているトピック(記事)が異なりますので、指示する機器のトピックに合わせてAPIをパブリッシングする必要があります。
また、それぞれの機器に駆動部がいくつあるか、複数ある場合には、同時に動かすことが可能か、また、変数(アナログ値)がいくつあるかによってもAPIが異なります。
以下、図4の場合を想定して、1対多のAPIを検討します。そして、最後に一般化してみたいと思います。
5-1.図4の構成のAPIの検討
図4の1対多のMQTT用のAPIを以下の様にまとめてみました。動作の方向とパラメータを組み合わせたJSON形式になります。駆動部の数が1つでない場合には、配列を使って記述しています。
distance, angleを指定しない場合は、directionでstopしないと止まりません。distance, angleを指定した場合は、到達すると停止します。
動作完了時のresponseに関しては、機器側からresponseのパブリッシングを行い、ホスト側でそれをサブスクライブし、次の動作に入るという手順になります。
動作完了時のresponseのAPIを次にまとめます。機器は、正常動作完了の場合は、”000”を返します。エラーの場合は、エラーコードを返します。
何か情報を付け足す場合は”val”で追加情報をパブリッシングします。
駆動部が2つある場合には、全体の動作完了を”code”で返し、”subcode”で軸毎の情報を付け加えます。“subcode”は配列で軸の情報を持たせます。
5-2.MQTT用APIの一般化
機器がz台の場合で駆動部と変数の数もそれぞれ異なる場合のAPIを次にまとめてみました。同じ機器が複数台合っても、すべて異なる機器であっても使えるのではないかと思います。
動作完了時の機器からのresponseのAPIもまとめます。各機器からトータルの結果と合わせて、駆動部ごとの結果がパブリッシングされます。
６．安全機能の追加
機器を遠隔で制御する場合、必ず安全であることを確認してください。例えば、扉の開閉を行う場合では、人や物が挟まれないか等、十分注意して制御システムを構築してください。パトライトの点滅やブザーの発報などを行ってから、機器の動作を行うことをお勧めします。
また、機器の誤動作に対する対策を必ず考慮しなければなりません。
例えば、電熱器をON/OFF制御するケースを考えると、OFFの信号を受け付けなくなり、加熱し続けてしまう異常事態を想定し、事前に対策を講じておくことが必要です。例えば、WDT(watchdog timer)を別回路として設け、設定時間以上連続してONが続いた場合には、強制的にOFFにする回路を付加するなどです。
尚、WDTによる監視回路は、駆動回路の直近に組み込むことが必要で、例えば、ノーマリーオープン(N.O.)のリレー接点などを使い、制御側からの信号の有無にかかわらず、WDT回路そのものが働かないときには、駆動回路がオープンになり電熱器の加熱ライン（駆動回路）そのものに電流が流れないようにしなければなりません。
サンプル回路図を追加
モーターや電磁弁等の使用する部品については、電源が切れた場合安全側になるように設計してください。例えば、巻き上げ機の場合、電源が切れても荷物が落ちないようにブレーキがかかる駆動器を使用すなどです。電磁弁の場合も、電源が切れた際の動作を考慮してシステム設計してください。ちなみに、血圧計用の加圧ポンプは電源が切れると空気が抜ける設計になっており、故障（電源切断）した場合にも腕を絞め続けないようになっています。
