hirax.net::Keywords::「計測」のブログ

■「1秒間に2回の運動は”エンディング”近く」の法則　

　どんな業界でも「その業界のプロには”見れば”わかる」ということがある。

　AV業界の監督さんが「HカップかJカップかは"一目見れば"わかる」と言っていた。計測器も真っ青の「プロの目」だなぁ、と感心させられた。そして、AV業界と言えば、編集者が書いていたこんな言葉にも驚かされた。

　ちなみに、一秒間に２回の運動は結構激しいですから、そういう動きを横目で見るだけで「あぁ、エンディングが近いんだ」とわかります。

　ビデオ画像を一目見ただけで、そのビデオのコンテキスト（文脈）解析をして、「今目に入った場面が」全体のどこに位置しているかを一目瞭然に判断しているわけである。まさに「プロの目」である。

　以前「アダルトビデオの動画解析」をしたことがある。この時は15秒間の動画からオプティカルフロー（動き）を解析したのだが、全編に渡って動画の動きを解析し、ビデオのコンテキスト(文脈)解析をしてみるのも面白いかもしれない。もしかしたら、すでに「オプティカルフロー計算→コンテキスト解析解析→スクリーンショット作成」といったフローがアダルトビデオサイトのバックエンドでは動いていたりするのかもしれない。

　今度、「1秒間に2回の運動は”エンディング”近く」の法則を使った”スクリーンショット作成”WEB APIを試しに作ってみることにしようか。

■Rubyで「シリアル通信スレッドクラス」を作る　

　Rubyで「(Ｒｕｂｙシリアル通信ライブラリ（Windows用）TEXCELL を使った)シリアル通信スレッドクラス」を作りました。ソースコードとサンプルはここに置いておきます。”Microsoft Windows VISTAではほとんど見捨てられているような”シリアルポートでの送受信をRubyでスレッドを使って行うクラスです。Queueにデータを突っ込めば「シリアル通信スレッドクラス」から自動的に送信されます。また、受信した文字列が「（指定した改行コードで）一行になるたびに」receiveイベントが呼ばれるので(また、その際にQueueを指定しておけば受信行が自動的にそのQueueに追加されていきます)、読み込みのタイミング・必要な情報がまだ途中までしか読み込まれていない場合などの処理を気にすることなく使いたい、と考えながら作ってみた「シリアル通信スレッドクラス」です。
　たとえば、COM3で受信した内容をコンソールに出力するだけであれば、このようなコードで動くはずです。

require 'comThread'
receiveComThread=ComThread.new({:icomno=>3})
receiveComThread.start({:receive=>true, 
　　　　　　　　:receiveMonitor=>true})
sleep 60
receiveComThread.stop

　シリアル通信モニタプログラム(シリアルポート間で送受信されている内容を眺めるプログラム)も、多分10行くらいで書けると思います。チェックせずに書いてしまうと、こんな感じになると思います。

  require 'comThread'
  q=Queue.new
  receiveComThread=ComThread.new({:icomno=>3,:rq=>q})
  sendComThread=ComThread.new({:icomno=>4,:sq=>q})
  receiveComThread.start({:receive=>true,
　　　 :receiveMonitor=>true})
  sendComThread.start({:send=>true})  
  sleep 60
  sendComThread.stop
  receiveComThread.stop

　以前、こんなことを書きました。

　「計測・解析ソフトウェア/ハードウェアのハック」が実験系技術者の一番のLifeHackかもしれない…と思っています。その思いを逆に言うならば、実験系技術者が費やす多くの時間を、計測・解析処理が消費していると思っているからです。そして、一番時間を消費している部分の高速化をすることが、全体の高速化に効果的だろう、と思っているわけです。

　そんなこんなで、何を今更…という、Perlで「シリアル通信とユーザインターフェース自動制御」のやり方を整理しておくことにしました。なぜかというと、経験的に(既成機器をを使わざるえないことが多い)「計測・解析ソフトウェア/ハードウェアのハック」は、シリアル通信制御とユーザインターフェース自動制御でほとんどの場合対応できる、からです。

　というわけで、先週末はこの「Perlでシリアル通信とユーザインターフェース自動制御のやり方を整理しておくことにしました」の部分を「Rubyでシリアル通信とユーザインターフェース自動制御を書いて整理しておくことにしました」ということをしてみたわけです。この「シリアル通信クラス」と「ユーザインターフェース自動制御」があると、結構便利な実験屋さんもいるかもしれません。

■Thinkpad加速度センサ取得用C++クラスの手直しをしました　

　Lenovo(IBM) Thinkpad加速度センサ取得用C++クラス（関連記事・Thinkpad加速度センサ取得用C++クラス／新しいThinkpad にも対応した加速度センサ値取得プログラム）を少し手直ししておきました。動作は全く変わりませんが前回の修正の際に不要な部分が残っていたので、その点について直しました。

　Thinkpad加速度センサ取得用C++クラスをまとめたヘッダファイルソース(Sensordll.h)、および、使用サンプルソース・バイナリ(sample.cpp・sample.exe)は、ここに置いておきました（古いバージョンは、サブディレクトリに置いてあります）。

サンプル・アプリケーション例では、よく意味がわらないままに、"Temprature"も出力するようにしてあります。

sample.exe 1000 10

という風にコマンドラインからアプリケーションを実行すると、

0=x, 0=y,35=temp.
0=x, 0=y,35=temp.
0=x, 0=y,35=temp.
0=x, 0=y,35=temp.
1=x, 1=y,35=temp.
-16=x, -3=y,35=temp.
-1=x, -1=y,35=temp.

とった具合に左右方向の傾斜と奥行き方向の傾斜（とtemprature）を出力します。

■麻雀の科学「麻雀牌の厚みは結構違う?」　

　麻雀の科学「白牌と中牌で重いのは白牌だ…は本当か!?」で、白牌と中牌の厚みが、想像以上に違っていたので、今日は（白牌と中牌だけでなく）全麻雀牌の厚みを測ってみました。その結果が、下に貼り付けたグラフです。これは牌種毎の厚み（mm）を４枚の牌間のばらつきで見積もったエラーバー（±３σ）付きで示してみたものです。

　最薄の牌と最厚の牌は、1m弱ほども厚みが違いました。また、牌毎に厚みのバラツキはそれなりにあるにしても、それでも牌種毎の「おおよそこのくらいの厚み」という数値になっていました。

　ところで、このグラフは牌種が（横軸の左から右に）字牌（三元牌 ・風牌）→数牌（筒子・萬子・索子）という風に並んでいます。…その並びとともに、上のグラフを眺めると、何やら興味深い傾向が見えてきます。これは、まだまだ調査を続けてみたくなりますね。