Raspberry Piをいろいろ使っている．．．． [Raspberry Pi]
Raspberry Piを知ったころは、まさかそんなことにはなるまい、と思っていたけど、2年近く経った最近では仕事にRaspberry Piを使うようになってきた。もちろん計算とかに使うわけではなくて、会社の工場に入れた組み立て装置や測定装置の一部としてである。「なぜRaspberry Piか？」というはひと段落したら落ち着いて分析しようと思うけど、大きな要因はなんといっても価格が安いこととほぼ完全なDebian OSが実用的なパフォーマンスで動作することが両立している、という点であることは間違いない。
最近の使い方では、モータを回したり光をフォトディテクタで受けてA/D変換したり、ということをやってその指示やデータはホストとやり取りするように書いている。これまでそういう作業のために何を使っていたかというといわゆるシーケンサである。僕はラダープログラムを書けないのでこれまでは専門家の設備屋さんに投げていた。もちろんシーケンサをすべてRaspberry Piに置き換えるなんてことはできないけど、Raspberry Piでも十分な作業のために高価でゴツいシーケンサを、これまで無批判に使っていたとは言えるので、僕としては反省している。
僕が使うシチュエーションでは、Rapberry Pi自身はユーザインターフェイスを持たず、ホストとのコミュニケーションはネットワーク、つまりは無線LANを使う。LAN経由のやり取りは遅いんだけど、それが問題になるほどではない。最初はUDPで垂れ流していたんだけど、そういう使い方ではRaspberry Piの高いパフォーマンスを生かしきれなくて、最大負荷でも8割がたは遊んでいる（VAX/VMSでいうとNULLさんがCPU時間を占有してる）状態。Raspberry Piにはもっともっと難しいことをしてもらわないといけない．．．．
そうすると、Raspberry Piにはもっとまとまった仕事を任せることになる。こないだ書いたのはモータふたつを動かしながらフォトディテクタで光を受けるというもの。一つのモータは光ディテクタの位置を、もう一つのモータは向きを変える。それらは非線形な関係だけど協調的でないといけない。
位置を移動させるモータはストロークも長いので、昔ながらの大きなステージを動かすステッピングモータにしたけど、向きを変えるモータはRCサーボモータを使った。位置移動はステージ含めて百万円近いけど、向きを変えるモータは500円ほどのラジコン用モータに僕が半田付けした電流電圧変換回路こみのディテクタを接着剤でサーボホーンに貼っただけなので、総計千円いかない。金額ではすごいダイナミックレンジのシステムになった。
大きなステージはイナーシャもデカいので、やり直しや緊急停止以外は定速で動かして、それに従ってディテクタの向きを変えていく。それをRaspberry Piにやらせた。ホストからパラメータを受け取ると、そのあとは初期的な状態にしたあと、終状態までのある時刻での位置と角度と光量をRaspberry Piからホストに報告させるように書いた。そのためにソフトウェアとしてはTCPでの通信とデッドロック回避のためのpthreadを使ったマルチスレッドプログラミングというどっちかというと低レベルな書き方になった。他にもいろいろなチョアをやらせたんだけど、動かしてみると4コアのうち2コアは完全に遊んでる、という状態だった。Raspberry Piにとってはアクビ混じりに片手で仕事をしているということ。
ハード的にはとりあえずはそれでいいとして、ホストとのやりとりはもう少し考えないといけない。UDPのデータ垂れ流しから、ちゃんとパラメータをホストからうけとって、まとまった信頼性の高い結果をホストに返す、という方式にするためにUDPからTCPに変更した。ホストとはちゃんと対等に、実行できないパラメータ、例えばステージの移動速度が速すぎるとかサンプリング間隔がA/D時間より短いとかの場合、エラーをホストに返すというふうにした。いかにも、もっともらしい。
その通信プロトコル、というか通信路上のデータ形式はASCIIのcsv形式、つまり改行で区切られてコンマで語を区別するという形にした。そうするとお互いの解析は簡単だし、バイトスワップの問題は無いし、受け取ったデータはそのまま文字列としてファイルにすると、みんなが大好きなエクセルで開くことができる。
でもそれだと、パラメータを増やすとか減らすとかいう変更をした場合、ソースから書き換えないといけない。また、パラメータの型、つまり整数か浮動小数点か文字列か、などは前もって決めておかないといけない（エクセルの真似して間抜けな型判別なんかはやりたくない）。そうするとcsv形式では限界がくる。
そうするともうすこしプログラムから使いやすくて記述としては柔軟性の高い形式にしたい。というとやっぱり今ではXMLだろうな。Raspbianではlibxml2がデフォルトでインストールされているのでDOMもSAXも（その負荷がどのくらいかは実際にやってみないとわからないけど）標準的に使える。OS XではObjective-Cのオブジェクトで同じようなことをするNSXMLDocumentのクラス群があるのでホスト側も問題ない。
もちろんXMLで読み書きしてもそのメタな定義をどうするかでプログラミングの手間は全然違ってくる。通信データをXMLにするだけではなく、その内容の記述もXMLにして、Raspberry Piとホストが同じXMLファイルを読み込んでパラメータ定義を得るようにしたい（もちろんパラメータを変更するということはそのパラメータを使って作業する部分は書き換えることになるけど、通信の部分はそれとは無関係にしていろいろな装置に使いまわしたい）。もう少しじっくり考えないといけない。
そうやってRaspberry Piにやらせることが増えるとホストは実質的にユーザインターフェイスしかない、つまりユーザからパラメータの設定をもらってそれをRaspberry Piに渡して、あとはRaspberry Piから受けとったデータを表示するだけということになる。次にこれから作ろうと考えている測定器はまさにそういうものになる。そうすると僕のプログラミングの都合でホストをMacにする、とは言い難くなってくる。
では、Raspberry Piにユーザインターフェイスを持たせるか？でもそれはXtとwidget、いやそれはあまりに古い、今だとGTK+なんかを使うことになるだろう。でもそのあたりは僕は疎くて、そのためだけにこれから勉強しようという気にはなかなかならない。しかもその場合、測定器を使う人がRaspbian、というかX-Windowをある程度知っている必要もあって結構敷居は高い。
そうすると、Raspberry PiでHTMLサーバを動かして、ユーザインターフェイスは測定器を使う人が自分のパソコンのブラウザをそのまま利用する、というのがいいのかな。ダイナミックにHTMLを生成するというとWebObjectsを思い出すけど（WebObjectsは昔なぜかJavaに書き換えられたあとAppleが開発言語としてのJavaのサポートをやめた。登らされたハシゴをあとからはずされた格好で、なんでそんなことしたのかAppleの意図がよくわからない）、今ではいろいろあるらしい。なんか簡単な方法はないかな。
いやいや、Raspberry Piにユーザインターフェイスを書くぐらいなら、Mathematicaを使ってしまった方がプログラミングは簡単で、グラフィカルな表示がバカチョンでできる。ずっと昔、当時としては複雑な計算をする測定機のホストにMathematicaを使ったことがある。Mathematica4.0〜4.1とかの時代なのでかなり古いけど、Mathematicaにパネルを開かせてボタンを配置して、それをクリックすると測定が始まって（ハード的につながったカメラからのデータをMathlink経由で受け取る、なんてことを書いた。あのころは僕も元気だった）、結果をノートブックにグラフィカルに表示する、というもの。使う人からの評判では「最悪」という評価を受けたけど（ユーザインターフェイスも変だったけど、とにかく遅かった）、プログラミングはめちゃ楽だった。なんといっても、出来上がってしまってから言われるアレをやれコレが無いとダメというのに対応するのがすごく簡単になった。
そういうのもアリかなあ。でも使う人からはまた嫌がられるだろうなあ。しかしどうでもいいけど散漫な話になったなあ．．．．
最近の使い方では、モータを回したり光をフォトディテクタで受けてA/D変換したり、ということをやってその指示やデータはホストとやり取りするように書いている。これまでそういう作業のために何を使っていたかというといわゆるシーケンサである。僕はラダープログラムを書けないのでこれまでは専門家の設備屋さんに投げていた。もちろんシーケンサをすべてRaspberry Piに置き換えるなんてことはできないけど、Raspberry Piでも十分な作業のために高価でゴツいシーケンサを、これまで無批判に使っていたとは言えるので、僕としては反省している。
僕が使うシチュエーションでは、Rapberry Pi自身はユーザインターフェイスを持たず、ホストとのコミュニケーションはネットワーク、つまりは無線LANを使う。LAN経由のやり取りは遅いんだけど、それが問題になるほどではない。最初はUDPで垂れ流していたんだけど、そういう使い方ではRaspberry Piの高いパフォーマンスを生かしきれなくて、最大負荷でも8割がたは遊んでいる（VAX/VMSでいうとNULLさんがCPU時間を占有してる）状態。Raspberry Piにはもっともっと難しいことをしてもらわないといけない．．．．
そうすると、Raspberry Piにはもっとまとまった仕事を任せることになる。こないだ書いたのはモータふたつを動かしながらフォトディテクタで光を受けるというもの。一つのモータは光ディテクタの位置を、もう一つのモータは向きを変える。それらは非線形な関係だけど協調的でないといけない。
位置を移動させるモータはストロークも長いので、昔ながらの大きなステージを動かすステッピングモータにしたけど、向きを変えるモータはRCサーボモータを使った。位置移動はステージ含めて百万円近いけど、向きを変えるモータは500円ほどのラジコン用モータに僕が半田付けした電流電圧変換回路こみのディテクタを接着剤でサーボホーンに貼っただけなので、総計千円いかない。金額ではすごいダイナミックレンジのシステムになった。
大きなステージはイナーシャもデカいので、やり直しや緊急停止以外は定速で動かして、それに従ってディテクタの向きを変えていく。それをRaspberry Piにやらせた。ホストからパラメータを受け取ると、そのあとは初期的な状態にしたあと、終状態までのある時刻での位置と角度と光量をRaspberry Piからホストに報告させるように書いた。そのためにソフトウェアとしてはTCPでの通信とデッドロック回避のためのpthreadを使ったマルチスレッドプログラミングというどっちかというと低レベルな書き方になった。他にもいろいろなチョアをやらせたんだけど、動かしてみると4コアのうち2コアは完全に遊んでる、という状態だった。Raspberry Piにとってはアクビ混じりに片手で仕事をしているということ。
ハード的にはとりあえずはそれでいいとして、ホストとのやりとりはもう少し考えないといけない。UDPのデータ垂れ流しから、ちゃんとパラメータをホストからうけとって、まとまった信頼性の高い結果をホストに返す、という方式にするためにUDPからTCPに変更した。ホストとはちゃんと対等に、実行できないパラメータ、例えばステージの移動速度が速すぎるとかサンプリング間隔がA/D時間より短いとかの場合、エラーをホストに返すというふうにした。いかにも、もっともらしい。
その通信プロトコル、というか通信路上のデータ形式はASCIIのcsv形式、つまり改行で区切られてコンマで語を区別するという形にした。そうするとお互いの解析は簡単だし、バイトスワップの問題は無いし、受け取ったデータはそのまま文字列としてファイルにすると、みんなが大好きなエクセルで開くことができる。
でもそれだと、パラメータを増やすとか減らすとかいう変更をした場合、ソースから書き換えないといけない。また、パラメータの型、つまり整数か浮動小数点か文字列か、などは前もって決めておかないといけない（エクセルの真似して間抜けな型判別なんかはやりたくない）。そうするとcsv形式では限界がくる。
そうするともうすこしプログラムから使いやすくて記述としては柔軟性の高い形式にしたい。というとやっぱり今ではXMLだろうな。Raspbianではlibxml2がデフォルトでインストールされているのでDOMもSAXも（その負荷がどのくらいかは実際にやってみないとわからないけど）標準的に使える。OS XではObjective-Cのオブジェクトで同じようなことをするNSXMLDocumentのクラス群があるのでホスト側も問題ない。
もちろんXMLで読み書きしてもそのメタな定義をどうするかでプログラミングの手間は全然違ってくる。通信データをXMLにするだけではなく、その内容の記述もXMLにして、Raspberry Piとホストが同じXMLファイルを読み込んでパラメータ定義を得るようにしたい（もちろんパラメータを変更するということはそのパラメータを使って作業する部分は書き換えることになるけど、通信の部分はそれとは無関係にしていろいろな装置に使いまわしたい）。もう少しじっくり考えないといけない。
そうやってRaspberry Piにやらせることが増えるとホストは実質的にユーザインターフェイスしかない、つまりユーザからパラメータの設定をもらってそれをRaspberry Piに渡して、あとはRaspberry Piから受けとったデータを表示するだけということになる。次にこれから作ろうと考えている測定器はまさにそういうものになる。そうすると僕のプログラミングの都合でホストをMacにする、とは言い難くなってくる。
では、Raspberry Piにユーザインターフェイスを持たせるか？でもそれはXtとwidget、いやそれはあまりに古い、今だとGTK+なんかを使うことになるだろう。でもそのあたりは僕は疎くて、そのためだけにこれから勉強しようという気にはなかなかならない。しかもその場合、測定器を使う人がRaspbian、というかX-Windowをある程度知っている必要もあって結構敷居は高い。
そうすると、Raspberry PiでHTMLサーバを動かして、ユーザインターフェイスは測定器を使う人が自分のパソコンのブラウザをそのまま利用する、というのがいいのかな。ダイナミックにHTMLを生成するというとWebObjectsを思い出すけど（WebObjectsは昔なぜかJavaに書き換えられたあとAppleが開発言語としてのJavaのサポートをやめた。登らされたハシゴをあとからはずされた格好で、なんでそんなことしたのかAppleの意図がよくわからない）、今ではいろいろあるらしい。なんか簡単な方法はないかな。
いやいや、Raspberry Piにユーザインターフェイスを書くぐらいなら、Mathematicaを使ってしまった方がプログラミングは簡単で、グラフィカルな表示がバカチョンでできる。ずっと昔、当時としては複雑な計算をする測定機のホストにMathematicaを使ったことがある。Mathematica4.0〜4.1とかの時代なのでかなり古いけど、Mathematicaにパネルを開かせてボタンを配置して、それをクリックすると測定が始まって（ハード的につながったカメラからのデータをMathlink経由で受け取る、なんてことを書いた。あのころは僕も元気だった）、結果をノートブックにグラフィカルに表示する、というもの。使う人からの評判では「最悪」という評価を受けたけど（ユーザインターフェイスも変だったけど、とにかく遅かった）、プログラミングはめちゃ楽だった。なんといっても、出来上がってしまってから言われるアレをやれコレが無いとダメというのに対応するのがすごく簡単になった。
そういうのもアリかなあ。でも使う人からはまた嫌がられるだろうなあ。しかしどうでもいいけど散漫な話になったなあ．．．．
2015-10-15 21:31
nice!(0)
コメント(2)
トラックバック(0)
「Raspberry PiでHTMLサーバを動かして」の亜流というか、「UDPからTCPに変更した」の部分を、「Raspberry Piで（自流ではない）既存のフレームワークやライブラリを使ったWebSocketベースなどのTCPサーバを動かす」に変更するのも、一回やってみると面白そうな気がします。そのTCPサーバと通信する相手方は、Raspberry Pi内のhttpサーバでも良いし（ユーザが実際に使うのは手元のPC上のブラウザ）、ユーザのPC内にhttpサーバを兼ねた通信ソフトを入れても良いし（ユーザが実際に使うのはやっぱり手元のPC上のブラウザーただしアクセス先はlocalhost）でも良いですし。
もちろん、「車輪の再発明大好き！最高！」主義を誇りにされていることは承知していますが…
by Jun Hirabayashi (2015-10-16 07:02)
コメントありがとうございます。
WebSocket全然知りませんでした。面白そうです。
HTMLサーバにするにはApatcheとMySQLとPHP入れて．．．なんてやってたら今回のような用途では重すぎるので、ちょうどいいレベルみたいです。Objective-Cでサーバ実装してる人もいてちょっと見てみるとそれほど膨大なコードではないようです。
しかしよく考えれば、二十数年前にもNEWSワークステーションに、ナマのTCPで測定サーバと表示および計算クライアントとのやり取りを書いていました。
「また古い話を喋っております」
米朝さんの前口上みたいになってきた。「ブンブの背中はぴーかぴか」です。
そういえば、先日会社の業務報告の場で、この装置が動作してる様子をムービーで紹介して、シーケンサ+タッチパネルに比べればずっと安上がりでしかもスマートなインターフェイスになってる、と言おうとしました。
ところが、反応は冷ややかで、しばらくシーンとしたあと「質問がなければ次へ」。
どうやらみんな「会社の金で遊びやがって」と思ってるみたいです．．．．．
by decafish (2015-10-16 21:36)