2015年7月23日木曜日

【Qt5.5 Qt Location】国土地理院地図プラグインを作ろう!(その2)

Qt Location 国土地理院地図プラグイン

国土地理院で提供されている地理院タイルをQtLocationで使用するためのプラグインが大体できたので公開します。


地理院タイルを利用する際は利用規約をよーくお読みくださいね。

現在用意しているのは、地理院タイルのうち以下の3点になります。
  •  標準地図 
  •  色別標高図
  •  写真

 
プラグインの使用方法

上記プロジェクトファイルをQtLocationのplugin/geoservicesに追加してビルドします。
コンパイル後、ライブラリ libqtgeoservices_kokudo.so が作成されるので、これをビルドディレクトリ/plugin/geoservicesに置きます。これはandroidだったら

Qt/5.5/android_armv7/plugin/geoservice

などになります。

QMLのMapのpluginプロパティに"kokudo"と指定してください。


備考

私のアンドロイド開発用デバイスはNexus7(2012)を使っています。今回、こちらを使用してプラグインのテストを行っていたところ、Mapを表示中になぜかタイルの一部が欠けてしまうという現象に悩まされました。これは今回追加したプラグインだけでなく、プリセットのOSMプラグインでも同様の現象が確認されました。

最初は「キャッシュメカニズム周りが臭いな」と予想してソースにダイブしてたんですが、最終的には、以下のようなメッセージが表示されることから、このタブレット(Nexus7 2012)がOpenGLのstencil bufferがサポートされていない為だと考えています。おそらくレンダリング処理で失敗しているのだろうと。

QSGContext::initialize: stencil buffer support missing, expect rendering errors

といっても他に代替できるAndroidデバイスはないので、仕方なくQtのバグトラッカーをあさったところ、この根本的な原因は未解決のこちらの問題が原因だと思うんですが、あいにくOpenGLの知識がないので自力では治せそうになく、ダメ元でこちらの情報をもとに


QQuickWindow* window = qobject_cast<QQuickWindow*>(engine.rootObjects().at(0));
QSurfaceFormat format = window->format();
format.setStencilBufferSize(-1);
format.setDepthBufferSize(-1);
window->setFormat(format);


を試してみたところ、タイルが欠ける問題は収まりました。なぜかわかってないけど、まあよかった(?)

あと、つまずいたとこは、プラグインのProvider名を日本語にすると、なぜかキャッシュのパスに使用されてしまいタイルデータがキャッシュできなかったです。

2015年7月9日木曜日

【Qt5.5 Qt Location】国土地理院地図プラグインを作ろう!(その1)

先日正式リリースされたQt5.5では、テクノロジープレビューとしてQt Locationが追加されました。QtLocationは地図、ナビゲーションなど、いわゆる地図アプリを作成するための素敵なライブラリです。

QtLocationでは対応するバックエンドのプラグインとして以下のものが用意されていますが

  • OpenStreatMap
  • MapBox
  • Nokia Here

こと日本の地図に関して言えば、OpenStreatMap以外はかなり残念な内容になっています。筆者は、常々、Qtで登山用の地図アプリを作ってみたいと考えていましたが、これでは到底使える内容ではありません。

そこで今回のプロジェクトでは、国土地理院で提供されている地理院地図API(地理院タイル)に対応したQtLocationのプラグインを作成してみました。

実装の詳細は後ほど報告したいと思いますが(githubで公開予定)、今回は速報として軽く紹介まで。

さて、以下の図は、新しく作成した地理院地図プラグインをQtのサンプルプログラムMapViewerに組み込んで、地理院地図を表示している様子です。

横浜駅周辺


ケーブルカーが新しくなった大山周辺



うーん、完璧。

どうです!これなら登山用の地図として使えるんじゃないですか?
こいつでROS用のGPSナビゲーションプログラムなども作りたいなあ。

いやー、本当、Qtは面白くなってきましたねえ。

2015年5月13日水曜日

作りかけのarduino化T34



作りかけの、arduinoでbluetoothラジコン化したT34を久しぶりに動かしてみました。やっぱりパワーが足りないし、足回りがいまいちだな。モーターの電源を9V電池に換装してみようかしら。入るかな?


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に送信する方法について解説します。お楽しみに!