2015年4月30日木曜日

Beagle Bone BlackとWebカメラ(logitech C310)で高速!OpenCVで顔認識




今回のプロジェクトでは(机の引き出しで眠っていた)Beagle Bone Black(以下BBB)とUSBカメラLogitec C310を使ってOpenCVでフェイストラッキングをやってみることにします。このプロジェクトのできしだいでは、今後のロボットプロジェクトなどで活用したいと考えています。

レシピ
  • Beagle Bone Black(以下BBB) Rev. ?
  • ウェブカメラ Logitech(Logicool) C310 
  • OpenCV 2.4.8

環境を構築する

今回のプロジェクトでは、OSにはUbuntu(14.04.2 LTS)を使用、外部電源とUSBカメラ(Logitech C310)、ネットワークケーブルをBBBに指しています。ちなみにこの写真のケースは3Dプリンタで作成したものです。

BBBには、オープンソースのコンピュータビジョンライブラリ「OpenCV」をインストールします。OpenCVは2.4.8をクロスコンパイルでビルドしました。OpenCVの環境構築はネットで広く紹介されていますので今回は割愛しますが、[0]を参考にして構築しています。

あれっ?640x480サイズの画像がキャプチャできないぞ!?

早速OpenCVのVideoCaptureクラスを使ってWebカメラのキャプチャープログラムを実行します。しかし以下のようなエラーメッセージが表示されるばかりで、全く画像をキャプチャーすることができません。あれ、こいつはオカシイぞ・・・壊れたかな?(汗)

 select timeout
 select timeout 

気を取り直して、今度はOpenCVを使用しないプログラムでWebカメラから画像を取得できるか試してみます。UVCカメラ用のビューワープログラム「luvcview」で試したところ、Webカメラから画像を取得して画面に表示できることが確認できました。ふーむ、どうやらC310は正常に動作しているようです。

うーむ。これはいったい、どういうことだ??

いろいろとネットで情報を集めた結果、BBBでウェブカメラを使用する場合、以下の問題があることがわかりました[0][1]。
  1. Beagle Bone BlackではUSB経由でWebカメラを使用する際にデータ転送(バルク転送)に制限がある
  2. この理由により、無圧縮の画像フォーマットを使用し、かつ高フレームレートで画像をキャプチャしようとするとエラーが生ずる
  3. したがって、Webカメラから高フレームレートで画像を取得したい場合には、圧縮フォーマットを使用し、Webカメラから送信されるデータ容量を削減し、そのうえで画像をキャプチャする必要がある
無圧縮時の、カメラから送信される画像サイズおよびFPSとデータ容量の関係は以下のようになります

  高さ x 幅 x  3 x 8 x フレーム数 (bps)

BBBではこの上限がおおよそ13MB程度であるため、これ以上のデータを転送しようとすると先ほどのようにエラーが発生します(640x480では約26MB)。

さて、なるほど、BBBの事情は大体分かりました。ではC310はどうなのでしょうか?対応する画像フォーマットを調べてみましょう。v4l2-cntlで情報を取得すると以下のような情報を得ることができます。

ubuntu@arm:~$ v4l2-ctl -d 0 --list-formats
ioctl: VIDIOC_ENUM_FMT
 Index       : 0
 Type        : Video Capture
 Pixel Format: 'YUYV'
 Name        : YUV 4:2:2 (YUYV)

 Index       : 1
 Type        : Video Capture
 Pixel Format: 'MJPG' (compressed)
 Name        : MJPEG

C310は画像フォーマットとしてYUYVとMJPEGに対応していることがわかります。YUYVは無圧縮、MJPEGはJPEG圧縮を行うフォーマットになります。OpenCVのソースコードを斜め読みした限りでは、OpenCVが画像フォーマットを自動的に判別するんですが、C310の場合はYUYVが優先的に設定されているようです。UYUVフォーマットですと無圧縮なので、転送データ量が前述の上限を超え、timeoutエラーが生じてたようです。

ためしに画像サイズを320x240に縮小するか、フレームレートを10以下に設定するとOpenCVのVideoCaptureでもtimeoutが発生せず画像が取得できることがわかりました。

でも、せっかくC310はHD720p対応のWebカメラですがから、もっと大きな画像サイズ、高フレームレートで使いたいですよねえ。
C310をめぐる冒険
[0] でも触れられていますが、C310の課題の一つはjpegデータにハフマン符号テーブルが欠落していることです。一部のWebカメラでは、どうもそのような仕様になっているようです。毎フレームに同じデータを埋め込むわけなので、無駄なデータ容量を削減するための合理的な判断、といったところでしょう。luvcviewのソースでも確認しましたが、この問題に対処するためには、v4l2でバッファメモリをコピーした後に、省略されれているハフマンテーブルを適切な位置に埋め込むことが必要です。幸い、OpenCVのimdecodeでは自動的にハフマンテーブルの欠落を認識し、これを修正してくれるので助かりました。というか、当初はそれを知らなかったので自力でハフマンテーブルを埋め込む処理を実装していたんですが・・・無駄な苦労?・・・いやいや、これも修行です。
MJPEG専用OpenCVキャプチャーの作成

BBB上でWebカメラから高FPSで画像をキャプチャするには、圧縮フォーマットを使用して、転送データを上限以内に抑える必要があります[0]。そこでOpenCV互換のMJPEGフォーマット専用キャプチャークラスMJPEGCaptureを作成しました。さきほど参照したブログ[0]と[3]で公開されているプログラムをベースに改良したものです。v4l2を使用してMJPEGフォーマットで画像をキャプチャします。

githubで公開していますので興味のある方は試してみてください。

https://github.com/yamsam/MJPEGCapture

なおこのプログラムはcmakeを使用しているので以下のように依存ライブラリ(OpenCVとV4L2)の設定が必要になります。以下はccmakeでの設定例になります。

 CMAKE_BUILD_TYPE                                                            
 CMAKE_INSTALL_PREFIX   /usr/local                                
 OPENCV_FOUND                ON                                        
 OpenCV_DIR                      /usr/local/share/OpenCV                    
 OpenCV_FOUND                 ON                                        
 V4L_INCLUDE_DIR              /usr/include                              
 V4L_LIB                            /usr/lib/arm-linux-gnueabihf/libv4l2.so


測定実験

キャプチャー性能の測定

githubで公開しているソースコードから、純粋にキャプチャ性能だけを測定するプログラム「bench」を実行した結果です。

Capture 320 x 240 pixels at 30 fps
mjpegcapture time=6.88099
fps=14.5328
Capture 640 x 480 pixels at 30 fps
mjpegcapture time=6.93616
fps=14.4172
Capture 1280 x 960 pixels at 30 fps
mjpegcapture time=6.97647
fps=14.3339

カメラ設定がデフォルトの状態だと、320x240~1280x960までの画像サイズで、大体15FPSの性能が得られました。カメラ側の設定は30FPSとなっているので、この測定値ではFPSが設定値の半分しか得られていません。MJPEGの圧縮率から考えると、30FPSでもBBBの上限には達しないと思われるため、もっと高い値であってもよいはずです。

これはカメラ側の自動露出が原因のようです。

Webカメラの設定を変更するにはv4l2-ctrlコマンドを使用します。今回はv4l2-ctrlで設定を以下のように変更し、自動露出を停止、露出をマニュアル指定します。設定可能なカメラパラメータはv4l2-ctl --all コマンドで取得が可能です。C310はexposure_autoで自動露出、exposure_absoluteでマニュアル露出の設定が可能になっています。今回は以下の値を設定してみました。

v4l2-ctl -d 0 -c exposure_auto=1 -c exposure_absolute=300

マニュアル露出を設定した場合の測定結果は以下の様になります。

Capture 320 x 240 pixels at 30 fps
mjpegcapture time=3.35413
fps=29.814
Capture 640 x 480 pixels at 30 fps
mjpegcapture time=3.40226
fps=29.3923
Capture 1280 x 960 pixels at 30 fps
mjpegcapture time=6.35601
fps=15.7331

このように自動露出を停止すれば、画像サイズ1280x960以外では、C310のスペック上の最大値である30FPSが得られることが確認できました。ただしマニュアルで最適な露出を指定するのは一般的に難しいので、プロジェクトによっては、FPSは半減するけれども安定した画質を優先し自動露出を有効にしてもよいでしょう。一方で、FPSを重視するプロジェクトでは自動露出をOFFにし、マニュアル露出を適切に設定するとよいのではないでしょうか。

さて、こうして、ついに、ようやく、やっと、C310を本格的に活用できる体制が整いました。
ここまでが長かった・・・

フェイストラッキングの測定

ではOpenCVを使って顔検出を行ってみます。

今回、顔検出には、OpenCVのカスケード型分類器を使用、特徴量には高速なLBP特徴量(lbpcascade_frontalface.xml)を使用します。

  • 画像サイズ640x480

   fps=2.27589

  • 画像サイズ320x240

   fps=9.01146


320x240であれば10FPS近く出ました。以下は、実験中に撮影した顔認識の結果画像です(640x480)。、最近、超過酷な、娘のおままごとタスクフォースに派遣されている英国陸軍特殊部隊の方(対テロ装備)に協力していただきました。



まとめ

今回のプロジェクトをまとめますと、やはりシングルボードLinuxでリアルタイムのコンピュータビジョンを行うのは、厳しいと言わざるをえません。幸い今回の性能は、筆者のようなアマチュア向けの用途であれば、ギリOK、というところでしょうか。組み込みLinuxで本格的なリアルタイムコンピュータビジョンを実現するには、アクセラレーションが欠かせないでしょう。

今回のプロジェクトの教訓

GPUでOpenCVを高速化ができる、NvidiaのJetson TK1がスゴーク欲しい!

残念ながら当ブログは慢性的なリソース不足なんで、当分、購入見込みはありませんが(泣)


今後の予定

[2]ではドローンにBBB搭載して、OpenCVの画像認識によって、ドローンを自動着陸させる研究が報告されています。これを読むと、思ったよりもNEONでは高速化されないことや、libjpegの代わりTurboJPEGライブラリを使うことで若干高速化することなど、BBB上でOpenCVを利用する上での、貴重な知見を得ることできました。

この文献から得られた重要なトピックスのもう一つは、制御用ミドルウェアとしてROS(Robot Operation System)を使用していることです。今回作成したプログラムで、まあまあな速度のフェイストラッキングが実現できましたから、今度はBBB上にROSプラットフォームに乗っけて、OpenCVとROSを連携させたいと思います。

というわけで、次回はBBBでROSにチャレンジします!こうご期待!



その他、課題

デスクトップPCで問題ないんですが、BBBでMJPEGCaptureを実行すると以下のエラーメッセージが表示される問題が未解決です。

Corrupt JPEG data: 2 extraneous bytes before marker 0xd4

画像は正しく取得できているようなのですが、デコーダー周りになにか問題があるのか?BBB上でlucvviewを実行してもエラーは表示されないので、lucviewのjpegデコーダーを移植してみるとよいかもしれません。

あとOpenCV-3.0.0-rc1でも測定するべきだな。

参考文献
[0]How to Achieve 30 fps with BeagleBone Black, OpenCV, and Logitech C920 Webcam ,http://blog.lemoneerlabs.com/3rdParty/Darling_BBB_30fps_DRAFT.htm
[1]http://blog.lemoneerlabs.com/post/BBB-webcams
[2]Real-time Image Processing on Low Cost Embedded Computers, Sunil Shah ,
http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-117.pdfhttp://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-117.pdf
[3]https://bitbucket.org/beldenfox/cvcapture/src



2015年2月22日日曜日

テキサスインスツルメンツのBLEアプリ開発キット「SensorTag」

先日、昨年末に注文してずーと入荷待ちだった、テキサスインスツルメンツのBLEアプリ開発キット「SensorTag」がRSコンポーネンツ様から届きました!やったね!

BLE(低消費電力のBluetoorh)、センサーてんこ盛り、そしてリーズナブルなプライス($25、日本ではRSコンポーネント様で3350円)の人気のあるキットです。小型(71.2 x 36 x 15.5mm)で素敵な赤いカバー(シリコン?)もついているので持ち運びも便利ですし、3Dプリンタでケースをプリントする必要もありません。また国内認証も取得済みで、さらに最新のファームではiBeaconも対応しているとのことなので、たっぷりと遊べそうですね。

sensorTagとultimakerロボ


搭載されているセンサは以下の通りです。
・赤外線温度センサ TMP006(TI)
・湿度センサSHT21(Sensirion)
・圧力センサT5400(Epcos)
・加速度センサKXTJ9(Kionix)
・ジャイロセンサIMU-3000(InvenSense)
・磁気センサMAG3110(Freescale)

さて、今回はSensorTagとRaspberry Pi をBLEでつないでセンサーデータを取得するところまでやってみましょう。

このSensorTagにはiOS, Androidのアプリとソースが公開されているのでBluetooth4.0対応のスマートデバイスをお持ちの方は簡単に動作確認やアプリ開発ができます。

が、私の所有している携帯とタブレットは古くてBLE未対応でして動作確認ができませんでした。とほほ・・・。Qtでもアプリ作りたかったんだけど無念です

Raspberry Piのセットアップ

まずRaspberryPiにはBLEに対応したBluetoothのUSBドングルを指します。今回はPLANEXのBT-Micro4を使用しました。

RaspberryPiでBLEを扱うためには、blueZと呼ばれるライブラリを使用することになります。今回は、ほぼこのページを参考にして進めました。

簡単に手順を紹介していきましょう。

・必要なライブラリをインストールします
sudo apt-get install libdbus-1-dev libdbus-glib-1-dev libglib2.0-dev libical-dev libreadline-dev libudev-dev libusb-dev make

・blueZのソースコードを取得
mkdir -p work/bluepy
cd work/bluepy
wget https://www.kernel.org/pub/linux/bluetooth/bluez-5.4.tar.xz
xz -d bluez-5.4.tar.xz
tar xvf bluez-5.4.tar

・blueZのコンパイルとインストールをします
cd bluez-5.4
./configure --disable-systemd
make
make install

RaspberryPiでのコンパイルには多少時間がかかるので、その間、筆者は酒を飲んでました。

RPi2だと早いんだろうなという・・・make -j4とかな

SensorTagのスキャン

blueZのインストールが終了したらSensorTagをスキャンしてしましょう。SensorTagのボタンを押して次のコマンドを実行します。

sudo hcitool lescan
成功するとSensorTagのMACアドレスが出力されます。00:1e:3f:22:4b:a7のようなアドレスが表示されるのでCtrl-Cで終了し、アドレスをメモしておきます。

Pythonスクリプトの作成

さて、ではBLEキットと通信を行うプログラムはPythonを使ってサクサクと書いていきます。

今回はBlueZ用のpythonモジュールbluepyを使用しました。bluepyのgithubはこちらです。

workディレクトリに移動し、次のコマンドでbluepyを取得します。

git clone https://github.com/IanHarvey/bluepy.git

幸い、bluepyにはsensortag用のサンプルコードsensortag.pyが用意されています。

cd bluepy/bluepy
python sensortag.py --all sensortagのMACアドレス

実行すると以下のような出力が表示されます。素晴らしいですね。
('Connecting to ', '・・・・・・')
('Temp: ', (14.96875, 12.533883072524134))
('Humidity: ', (15.248315429687501, 53.9365234375))
('Barometer: ', (14.273310661315918, 1011.8373356866581))
('Accelerometer: ', (0.0, -0.96875, 0.046875))
('Magnetometer: ', (23.4375, 91.705322265625, -73.760986328125))
('Gyroscope: ', (0.0, 0.0, 0.0))

sensortag.pyは、以下のオプションで有効にするセンサを選択することが可能です。

optional arguments:
  -h, --help           show this help message and exit
  -n COUNT          データを取得回数
  -t T                 時間間隔
  -T, 温度
  -A, 加速度
  -H, 湿度
  -M, 磁力
  -B, 気圧
  -G, ジャイロ
  --all すべてのセンサを有効にする

おまけ

最後にSensorTagで取得したデータをIoTプラットフォーム「ThingSpeak」へアップして作成したグラフを紹介します。このグラフは私の部屋の温度ですね。



当初、BLEの低消費電力と搭載センサー群から、SensorTagは屋外用の気象センサとして最適ではないかと考えていましたが(特に気圧センサや磁気センサ)、実際使用してみると有効距離が短いことがわかりました。RaspberryPiと同じ部屋に置いている場合は問題ないのですが、壁ひとつ隔てた隣の部屋に置いただけで接続が不安定になります。ましてや屋外では全くつながりませんでした。しかし、それを除けばコストパフォーマンスは優秀ですから、室内用モニターとして使う分には満足できる性能ではないかと思います。

私の場合は、ホスト(RaspberryPi)は室内に設置することが前提となっていますが、当然ホストを屋外に設置できる場合にはまた違う結論になると考えられます。というか、もともと開発用キットですからね、無理を言っては申し訳ないです。開発用キットとしてはSensorTagはとても優秀です。

ThingSpeakとの連携方法についてはまた別の記事で詳しく解説する予定です。

2015年1月22日木曜日

Slic3rのマニュアルを日本語訳してます

以前からSlic3rのマニュアルには参考になる情報が書いてあるなあと思っていまして、マニュアルの重要な部分を選択して翻訳をしているので紹介します。知り合いに読ませようと思ってやっています。今回はプリント時の「ファーストレイヤーの重要性について」です。

もっとも最近育児が忙しくて3Dプリンタ自体は動かしてないんですが(汗)
昨年からの書きかけの記事も仕上がってないのに寄り道して・・・

githubでフォークして作業してるんでフィードバックはこちらまでお願いします。



ファーストレイヤーの重要性
最初のプリントの作成にのめりこむ前に、ちょっと回り道をしてファーストレイヤーを正しく 作成することの重要性について議論しても無駄ではない。これまで多くの人間が 試行錯誤の中で発見してきたように、ファーストレイヤーがベストでない場合、部品の剥離 や歪みなどの全くの失敗につながるからだ。これを最小限に抑えるために注意すべき テクニックや推奨方法を紹介する。

ベッドは水平に

ベッドを水平にすることはとても重要だ。ノズルの先端とベッドの間の距離に、 ほんのわずかでもズレが生じると、材料がベッドに載らないか(ノズルが近すぎてベッド をひっかいてしまうからだ)、遠すぎてベッドに正確に付着しないだろう。

温度は高めに

エクストルーダーのホットエンドとベッドを温める際、ファーストレイヤーの温度を高く すれば、プリント時の材料の粘性が少なくなる。だいたい5°程度高くすることを勧める。

ゆっくりと

ファーストレイヤーの押出速度を遅くすれば、融解した材料が押し出される際に加えられる外力 が減り、のばされすぎたり、正しく付着しない確率が減ることになる。通常の速度の 30%から50%が推奨だ。

押出量は正確に

押し出された材料の量が多いと、ノズルはそれを次のパスまで引っ張ってしまうことが あり、ファーストレイヤーが引きはがされる原因となる(特に材料が固まっている時)。 一方で量が少ないと、ファーストレイヤーが後から緩くなってしまい造形物の剥離や歪み を引き起こすことになる。これらの理由により、§[calibration]で推奨しているように、 押出量を正しく調節することが重要である。

ファーストレイヤーは厚く

レイヤーを厚くすればより流出量が増えることになり、その結果より多くの熱が加えられ、 材料がベッドによりしっかりと付着するようになる。これにはさらにベッドの水平度に対する トレランスを増加させる効果もある。ファーストレイヤーの高さをノズルの直径と合わせることをお勧 めする。たとえば0.35mmのノズルにはファーストレイヤー高を0.35mmに設定する。 (注)simple mode ではファーストレイヤーの高さはこの方法で設定される。

押出幅を太く

ベッドに接触する材料が増えれば増えるほど、造形物がベッドによりしっかりと 付着することになる。これはファーストレイヤーの押出幅を増やすことで実現可能だ。値はパーセント か固定値で指定する。押出間の間隔は自動的に調整される。
値はだいたい200%が推奨である。ただし、この値はレイヤー高から算出されるため、設定するときは レイヤー高をなるべく大きくすべきである。たとえばレイヤー高が0.1mmで押出幅が200% だとすると、実際の押し出された材料の幅は0.2mmにしかならず、これではノズル幅よりも小さくなってしまう。 この結果、流出量が足りず、プリントは失敗するだろう。したがって、前述のファーストレイヤーの設定 テクニックと併用することを強く推奨する。ファーストレイヤー高をノズル幅と合わせて0.35mmとし、 初期押出幅を200%にすれば、実際の押出幅は0.65mmと良好な太さになる。

ベッドの素材

ベッド素材の選択やベッド表面を整備することによってファーストレイヤーの 付着性を劇的に改善することができる。
PLAは扱いやすく、PET、Kapton、そしてblue painters tape(訳注:3Mのマスキング テープ)と相性がいい。
ABSは気難しくなだめすかしてやる必要がある。PET、Kaptonと相性がよいが、プリント 前にベッドにヘアースプレーをかけて成功したという報告がある。ほかにもABSのスリラー (ABSをアセトンなどで溶かしてつくる)を薄く塗布することでプリントの接着性が 改善したという報告もある。クーリングはいらない。

冷やすな

上記に関連して、ファンなどの冷却機構が機能しているのにファーストレイヤーの温度 を上げても全く意味がない。最初の数レイヤーをプリントする間はファンを切る ことを推奨する。

2014年12月15日月曜日

【IoTをDIY!】ThingSpeakで作る湿温度モニター(第一回)

今回のプロジェクトでは Internet of Things プラットフォーム「ThingSpeak」と室温度センサを使用して、Web上であなたの部屋の室温度をモニターするシステムを作ります。

ArudinoやRaspberryPiが普及したおかげで、「モノのインターネット」を誰でも簡単に作れるようになりました。ArduinoやRpiを使えば、誰でも簡単にセンサーデータを取得するデバイスを作り、それをネットに繋ぐことができます。でも待ってください、そのデータ、いったい管理はどうするんですか?その答えがIoTプラットフォームなのです。今では、ネット上にはそうしたフリーで利用できるIoTサービスが、まるでタケノコのように生えてきています。今回はその中から「ThingSpeak」を紹介したいと思います。


ThingSpeakを使えばこんな感じで、あなたの部屋の温度を、インターネットを介していつでもどこでも見られるようになります。今回はRaspberry Piとpythonを使って、簡単な室温度モニターシステムを構築しながら、Thingspeakの魅力をお伝えしていきたいと思います。






必要なもの
  • Raspberry Pi
  • 室温度センサ DHT11 or DHT22

ThingSpeakの設定

ThingSpeakは最近増えてきている、IoT向けのWebサービスの一つです。IoT、つまりインターネットに接続されたセンサーや製品から出力される各種データの収集と可視化をWeb上で簡単に行えるサービスです。ThingSpeakはシンプルなので、さくっと導入できるのが魅力です。

アカウントの登録

まずThingSpeakにアカウントを登録するところから始めましょう。

https://thingspeak.com/ にアクセスして、トップぺージから「SignUp」をクリックし、アカウントを登録します


必要事項を入力しましょう。TimeZoneはお住いの地域に応じて選択してください。日本でしたら、TokyoかOsakaから選びます。入力が終わったら「Create Account」をクリックしてアカウントを作成します。

チャンネルの作成

ThingSpeakでは、データはチャンネルという単位で管理します。たとえば、今回のような室温度モニターのようなプロジェクトであれば、センサデバイスを配置する大まかなロケーションごとにチャンネルを分けるとよいでしょう。たとえば、「家」、「会社」など単位でチャンネルを作ります。
 一つのチャンネルには最大8つまでのデータ(Field)を登録することができます。今の例ですと「会社」チャンネルには、「居室1」、「居室2」、「会議室」といった詳細なロケーションに分けてFieldを登録することができます。

 また後ほど説明しますが、ThingSpeakではチャンネルごとに、そのチャンネルへのアクセスするための鍵(API-key)が作成されます。したがって、チャンネルの設計は、アクセス権に応じて決めてもよいでしょう。たとえば「家」チャンネルの鍵はプライベート情報なので秘密にしますが、「会社」チャンネルの鍵はオープンにして、従業員へ配布すれば、職場の同僚がThingSpeakを通じて職場内のデータに自由にアクセスすることができるようになります。

では、チャンネルを作成しましょう。チャンネルの作成は以下の画面のように「Channels」→「New Channe」lボタンを押して作成します

チャンネルの設定

チャンネルの設定は「Channel Settings」タブで行います。ざっとみると沢山の項目がありますがここでは基本的なものについて説明します。正直私も全部理解しているわけではないので、興味のある項目についてはみなさんで調べてみてください。



  • Name: チャンネルの名前です。これはたとえば「●●工場」などとします。日本語もOK。
  • Make Public?: チャンネルを公開するかどうかを決めます。チェックを入れるとPublicViewが作成されます。
  • Field 1~8:  チャンネルに登録するデータです。8つのデータを登録することができ、それぞれに名前を付けることができます。たとえば「湿度」、「温度」です。fieldを新たに登録するにはadd fieldにチェックを入れます。 

チャートの設定

channelに登録したデータのチャートはViewで表示することができます。Viewには公開用のViewである「Public View」と、プライベート用のViewである「Private View」が容易されています。「Private View」はSignInしないと表示されませんが、「Public View」はSignInしなくても閲覧することができます。Public Viewを作るには、Channel SettingsでMake Publicを有効にする必要があります。


チャートの設定ダイアログは編集アイコン(チャート右上の鉛筆)を押して起動します。線の種類は線分(line)、曲線(spline)、横棒(bar)、縦棒(column)の4種が容易されています。また平均、中央値、合計値などの簡単な統計操作が用意されているので便利です。

次回

Part1ではThingSpeakのアカウント作成について解説しました。Part2ではRaspberryPiを使って、センサーデータをThingSpeakに送信する方法について解説します。お楽しみに!

2014年11月4日火曜日

タミヤの戦車プラモデルをarduino化しよう!(第一回)

今回のプロジェクトでは、タミヤの1/35スケールの戦車のプラモデルを使って、スマートフォンから操縦することのできるラジコン戦車を作成します。

戦車の操作回路はarduinoを使って作成し、Bluetoothでスマートフォンと通信を行います。スマートフォンのOSはAndroidです。Qt5(QML)を使用して作成したコントローラーアプリを使ってarduinoとの通信を行い、戦車を操縦します。アプリはQt5で作成しているので、近い将来、iPhoneにも対応できると思います。



今回戦車のキットには、ラジコン化のし易い、初期のMMシリーズである旧ソ連の傑作戦車T34/76(76ってのは砲身の大きさで、ミリタリー界ではより大口径の85mmを積んだ後期型のT34と区別するためこのように呼びます)を使用します。タミヤの初期の戦車キットは、もともとモーターライズとして開発されたキットをベースとしているため、戦車の足回りを特に改造することなくRC化することができます。またキット自体も部品数が少なく非常に作りやすい、しかも安い、素晴らしいキットです。しかし当然あなたの好きな戦車を選んでも問題ありません。

レシピ

・タミヤ MM59 T34/76
・タミヤ ツインモーターギアボックス
・Arduino pro mini (3.3v)
・Bluetoothモジュール
・デュアルモータードライバー polou TB6612FNG
・単4電池x4

arduio pro miniは小型のarduinoです。今回のプロジェクトのように、小さいものを作るのに適しています。本番用のarduinoです。検討段階では通常のUNOが扱いやすいです。pro miniは3V駆動8Mヘルツのものを選びました。

TB6612FNGはPWM対応の小型のモータードライバーで、動作電圧はロジック2.7~5.5V、モーター側は4.5~13.5V、最大1Aです。PWMでスピードのコントロールができます。どちらもスイッチサイエンスさんで取り扱っています。

Bluetoothモジュールは様々なものが市場に出回っていますが、なるべく小型で省電力のものを選びます。千石さんで販売されているSparkFun WRL-12580などが使いやすいと思います。

作り方

ギアボックスの作成

ある程度プラモを組んだら、転輪を回転させ履帯を動かす動力となる、ツインモーターギアボックスを車体に組み込みます。

T34の車体は小さいので、ツインモーターギアボックスがすんなりと車体に入りません。写真のように、ギアボックスの後部を斜めに削カットし、車体上部のエンジンカバーに収まるようにします。またギアボックスのシャフトも、そのままでは長すぎるので適当な長さにカットします。シャフトのカットには金属用のこぎりなどがあるとよいでしょう。ギアボックスの切断はプラ用ニッパで行いました。

 ギアボックスを車体に設置するには、車体内部にあるでっぱりなどを削り落としたり、転輪とシャフトの接着など、詳細は省きますが、このあたりはある程度のDIYスキルが必要でしょう。


制御回路の作成

ラジコン戦車の心臓部である制御システムを作成します。今回のプロジェクトで行う戦車のarduino化、その最優先事項はずばり「コンパクト」です。1/35スケールは小さいのでarduino unoはまず入りません。そこでArudinoにはpro miniを採用、モータードライバーも小型のものをえらびました。また、動作電圧も単4電池2本の3vを想定し、それぞれ3.3vで動作できる種類を選択します。Fritzingで作成した回路図は以下のようになります。左から、TB6612FNG、Arduino pro mini, Bluetoothです。(図ではTB6612FNGはpolouのではなくてspark funのドライバーになってますが、たまたまネットで拾ったのがspark funのだったんです、配線に特に問題ないと思います)






ユニバーサルボードで作成したプロトタイプ一号です。



車体にセットする

車体前部には、回路用の単4電池2本、モーター用の電池2本の、合計4つの単4電池をおさめます。ここでも電池ボックスを適度に削って車体にフィットするようにしました。制御回路は電池ボックスの上において、ちょうど砲塔の穴から顔を出すようにします。



今回は、思っていたよりも回路基板が大きくなり、回路と砲塔基部と接触してしまったため、車体側面を削って位置を調整し、なんとかおさめていますが、もっと回路をコンパクトに作成すればきちんと収まると思います。また電源もLipoバッテリーなどを使用すれば空間に余裕がでるでしょう。


次回予告

第二部はarduinoのスケッチを解説します。
第三部はQt5を使ったandroidアプリ作成について解説する予定です。
お楽しみに!

2014年10月5日日曜日

Qt5で作るロボットコントローラーアプリ

Arduinoで作成したロボット戦車を操作するAndroidアプリを作りました。アプリの作成にはQtのQMLを使用しています。Qtのバージョンは5.3.2です。





ArduinoのロボットはBluetoothのシリアル通信(SPP)によって操作できます。前進、後進、回転、速度調節などの操作が可能です。Bluetoothを使ったプログラミングは今回が初めてでしたが、Qtを使うとBluetoothとUIを連携したAndroidアプリが簡単に書けてしまうのが驚きです。

またこのコントローラーではロボットの操作だけではなく、ギミックとして、Android側でリアルな効果音を再生したり、動画を再生したりするなどの機能を追加して、戦車として臨場感を盛り上げています。QMLではこうしたマルチメディア再生も簡単に扱えます。

いやー素晴らしいですQML。

Qtはクロスプラットフォームなので(動作確認はしてないけど)Android以外の各種プラットフォームで動作するはず、のも素敵。


まだまだコードが汚いので、きれいになったら公開したいと思います。


ロボットの詳細
参考までにロボットの構成はこんな感じです

  • arduino uno
  • adafruit モーターシールド
  • adafruit 130サイズモーター(9V) これは3Vのタミヤのモーターと交換
  • Bluetoothモジュール
  • 測距離用の超音波センサー
  • タミヤ トラックホイールセット
  • タミヤ ツインモーターギアボックス

2014年7月6日日曜日

3Dプリンタの排気設備を作る

格安3DプリンタキットPrintrBot Simple用の排気設備を作りました。

レシピは以下のようです。



合計3000円くらい?かな。アクリル板とファンは余ってたものを使ってます。

ダクトホースとファンの接続アダプタは3Dプリンタで出力しました。STLデータの作成はFreeCAD-0.13を使用。FreeCADは、文字通りオープンソースのCADです。0.13からスケッチ機能が使えるようになり、かなり便利になりました。私の知る限りオープンソースのCADではベストです。でも
時々クラッシュするので、頻繁に保存しましょう。



出来上がったものはこんな感じ。当然ファンともピッタシです。キットで余った3mmネジで止めました。

さきっちょにダクトホースが刺さります


排気ボックス作成時に悩んだのはフィラメントの供給方法です。試行錯誤の結果、上部にフィラメント用の穴をあけ(スペーサを突っ込んで結束バンドで固定)、上部からフィラメントを供給する方式にしましたが、これが中々グッドですね。するする入っていきます。

今回使用したファンは、たまたま余ってたものを使ったんですが、パワーがまだ足りないですね。もっと流量の大きなファンに交換する予定です。

ボックスの正面は透明アクリル板を張って中が
見えるようになっています。またサイドには空気取り入れ口があります。
こうしてみると手作り感満載ですね(笑)


印刷時のトラブル

今回作成したダクトホースアダプタは、一辺80mmの大きさです。
Simpleのプリントサイズは最大4インチなので、Simpleにとっては大きめなサイズ。印刷時間もたっぷり半日以上かかります。

これほどの長時間のプリントは初めてだったので、長時間印刷ならではの問題に悩まされました。印刷途中でホットエンドの中でフィラメントが詰まってしまう、ジャムです。拳銃でいうところの弾づまり、紙プリンタでいうところの紙詰まりのような現象ですね。

エクストルーダーからひっこぬいたフィラメントを見ると、ホットエンドの上部でフィラメントが柔らかくなってしまいコブのような形状が形成され、引っかって詰まってしまうようでした。

いろいろ設定を変えてトライしましたが、結局、温度設定が問題だったようです。

Slic3rの設定で、初期温度195度、通常温度190度、ファン使用

にするとジャムもなく印刷ができました。温度設定は難しいですね。