2016年1月31日日曜日

アイデアメモ。センサネットワーククラウド接続サービス

こんなもの考えてみたのでアイデアメモ。

提供したモジュール(ハードウェア)を利用してもらえば、あとはAPIでデータの取得が出来る等のサービスがあったら便利ではないかなと思った。

やることは大きく2つ。
・クラウドに自動で接続されるセンサネットワークを簡単に作れるモジュールの提供
・クラウドからAPIの提供

絵にするとこんなイメージ
1.ローカルネットワーク


2. クラウド


それぞれが分かれてるサービスなら既にあるんだろうけど、統合されてるサービスってあまりないんじゃないかな?(調べてないけど)

これを著しく簡単に利用できるサービスって作れるのか興味湧いたので調査してみよう。

思いついた課題一覧
・デバイス間の通信モジュールは?
・デバイス間の通信プロトコルは?
・パレント、チャイルドの認証は?
・ツリー構造取れる?
・パレント、クラウド間の通信プロトコルは?
・ユーザ自身でデバイスをクラウドに登録させる手順は?
・クラウドからデバイスにデータ送る方法は?
・デバイスのデータはどこに保存?
・ユーザがデバイスのデータにアクセスする方法は?
・サービスの料金体系は?


自分用のアイデアメモでした。


2016/2/12追記:

さくらのIoT Platformというサービスでほぼこれと同じもののサービスが始まりました!びっくり!

Tech crunchの記事:

さくらインターネットのslideshareページでみたんだけど、モジュール毎の料金、月々数十円程度ってまじかよ。。。3G通信モジュールだけでも2万しそうなんだけど。私がモジュール作って売るなら3万円位は最低かかるから、5年償却としても1月当たり500円なんだよな。料金はまだオープンになってないので楽しみに待ってよう。



2016/2/22追記:

一通り調査してみた感じ、作れそう。感想をまとめる。

さくらのIoTとはやっぱコンセプトちょっと違うなと思った。
もともと、私が考えてたものは、インターネットの接点をより少なくするシステム。
それぞれのデバイスがインターネットに接続するとコストかかると思ってるから。(3G使うと特に。)
インターネットへの接続は、有線でもwifiでも3Gでも良くて、親機に集約されていたらあとはなんとでもなるかなってイメージしてる。

モジュールとサーバで利用するのにMQTTというプロトコルも考えたが、Websocketにしようと思う。
この、親機だけがインターネットに接続するという形式だと、MQTT使うメリットが無くなってしまうことが分かった。pub/subだったり、willだったり。
そしたら、技術的に枯れてるwebsocketの方がいいかなと思っただけ。実際に使ってみて不便だったらまた変えればいいや。

以前の疑問に一応、回答。
・デバイス間の通信モジュールは? → xbee使う。APIモードなら動的にIP振れる。
・デバイス間の通信プロトコルは? → しらん。xbeeがセキュリティにも配慮してくれてるらしい。
・パレント、チャイルドの認証は? → ★今後の課題
・ツリー構造取れる? → ★作れそうだが、xbeeは動的にそういった構造とれるとこまで出来るかは分からん。要調査。
・パレント、クラウド間の通信プロトコルは? → SSL+websocket
・ユーザ自身でデバイスをクラウドに登録させる手順は? → ★検討
・クラウドからデバイスにデータ送る方法は? → SSL+websocket
・デバイスのデータはどこに保存? → ★調査する
・ユーザがデバイスのデータにアクセスする方法は? → WebAPIを提供
・サービスの料金体系は? → デバイスは原価以上。基本クラウドで利益だしたいところ。


次のものを作れば大体システムになるかな?
・Webコンソール(rails)
・WebAPI(rails)
・デバイス通信サーバ(nodejsがwebsocket強いの?railsとnodejs比較しよう)
・親機デバイス(xbeeとpicでなんとかする)
・子機デバイス(xbeeとpicでなんとかする)

うむ。


2016/3/5 追記:

ハードウェアモジュールとクラウドをセットで提供してるサービス既にあった。
Digi Device Cloud」ってやつで、画面部分が「Digi Remote Manager」っていうパッケージになってる。(?)
Digiが提供している、Digi TransPort(4G LTE M2Mルータ)を使うと、そのデータをweb上に保存して管理画面で状態を確認できる。APIを使えばデータも取れそう。
remote managerは1device当たり2.5$/Monthが基本料金らしいが、見積もりボタンがあるので開始するためにいくらかかるのかもしれない。あと、このルーターの値段が分からん。

十分便利そうじゃん(笑)

2016年1月25日月曜日

組み込みで使える無線の種類と特長まとめ

「wifiやbluetoothなどは用途に合わせて選ぶ必要があります」みたいな説明ばっかで分かんねーよってことで、まとめる。

日本で利用しているモデルの場合、どの位の距離と通信速度が出るのかなど。
組込み用無線モジュールにおける無線規格の選び方」というページを最初に参考にした。

現状で組み込みに利用する無線通信規格は次の6種類が代表的っぽい。

  • モバイルネットワーク(2G/3G/LTE)
  • wifi
  • Bluetooth
  • ZigBee
  • IrDA(赤外線)
  • NFC

今、個人的にIoTに興味あるので、それらの危機に利用できそうな、モバイルネットワーク、wifi、ZigBeeを比較する。


No. 種類 モジュール価格 通信速度 通信距離 消費電力
1 モバイルネットワーク
FOMA
1~3万円?
ググった感じ高そう
下り14Mbps、上り2Mbps docomo回線の距離 多い
2 wifi
11nで調査
500~1000円
安い
600Mbps 250m
※直線で障害物無し
多い
3 Bluetooth
class2について
1000~3000円
class1は2万円
24Mbps 10m
class1だと100m
※直線で障害物無し
少ない
4 ZigBee 1500~2500円 250kbps 100~300m
※直線で障害物無し
少ない


さらに長距離を飛ばしたい場合は、こういった規格に合わない独自通信モジュールを使う場合もあるっぽい。

あと参考にしたページ「BluetoothとZigBeeの違い

なるほどねぇ。色々だねぇ。

世界展開考えるなら、一般化してる規格で製品作ったほうがよさそう。

2016/1/28 追記:
IP500っていう新規格が省エネでパフォーマンスいいらしいよ。
http://prtimes.jp/main/html/rd/p/000000001.000012835.html

日本の技適通ってるCNX100Jっていう製品があるらしいけど、メールか電話で問い合わせろってHPに書いてあった。日本のショップにならぶまでもう少し時間かかりそう。

2016/1/31 追記:
PCとモジュール3つセット2000ユーロだって。高ぇよ。PC除いても1000ユーロ。
もう少し待つべきだな。
http://www.corenetix.com/devkit.html

2016年1月24日日曜日

IoTサービス調べた事メモ(AWS IoT、AkaneとSango、SORAKOM)

2015年10月から、AWSのサービスに「IoT」なる項目が追加されてたらしい。最近知った。
AWS IoTで何が出来るか調べてて一緒に知ったサービスもメモ。
※この記事は表面的な事しかまとめないので、具体的に調べたい人はもう一度Google検索!

AWS IoTについて

公式の説明見た感じ次のことを主な目的に使えばいいのかな。(xivelyでできることはやれそう。)
  • プロジェクトとデバイスの登録
  • デバイスからのデータ受信
  • デバイスへのデータ送信
AWS IoTを利用するメリットとしては次のものがありそう。
  • AWSサービスとの連携のし易さ
  • ハードウェア向け、アプリ向けSDKの提供
  • 暗号化通信の提供
  • モニタリング機能提供
  • シャドウというデバイス復旧機能提供
  • ルールというメッセージ変換機能
AWSのSDKを使えば開発が簡単になりそうだね。

AkaneとSangoについて

AWS IoTの説明に「MQTT」なる単語が出てきて、なんぞやと調べて知ったサービス。
MQTTとは通信仕様の1つでHTTPとは仕様が異なる。
MQTTはパブリッシャーサブスクリプションモデルで、ブロードキャストを容易にする仕様があり、IoTに向いてる部分があるらしい。IoTの通信方法を選定する時に選択肢の1つになるそう。

このMQTTは仲介するブローカ(サーバ)を必要とするのだが、このブローカサービスを提供しているのがAkane。Akaneをブラウザから利用できるサービスを提供するのが姉妹サービスのSango。ちょっと、よく分かってないから間違ってるかも(笑)

このサービスの運営の時雨堂っていう会社、説明見たらすごかった。
一日6時間労働。役員、社員全員同一賃金。利益を人数で分配するだけ。等、衝撃(笑)

SORAKOMについて

SORAKOMプラットフォームは「格安SIM」「クラウドの接続セット」を提供している。
クラウドで操作できるSIMは新しいしSIM料金がスゴく安くて驚いた。
IoTプラットフォームを目に見える形で身近に ─元AWS玉川憲氏が率いる企業ソラコムが始動

AWSの人と思ってた玉川憲さんが代表で2015年に設立された会社。AWSで一緒だった何名かで立ち上げたっぽい。それにも驚いた。



まだまだ調べないといけないことが沢山だな。

2016年1月10日日曜日

レジスタとかコンフィグとかPICのプログラムが分からなすぎて調べた

まず、PICの入門に古い本はやめたほうがいい。
私は回路や部品が秋月でセット販売されているという理由で「プリント基板で作るPIC応用装置」(amazonリンク)という本を入門用に買ったのですが、プログラムが古くて動かせない!

本が出版されたの2009年10月、現在は2016年1月。
この間に開発環境も変わって、ヘッダファイルも変わって、コンフィグの書き方とかも変わったようだ。
以前の記事「【PIC入門】MPLABとXC8をインストール、PICKIT3を接続など簡単な回路を動かすまでのまとめ」で書いた開発環境だと、本のサポートページからダウンロードできるソースコードがエラー出て動かんのですよ。。

PICプログラムと開発環境の基礎が解ってる人は、なんとか出来るんでしょうけど初心者には厳しい!一応、最後まで目は通してパーツは組み立てるけど苦労するぜ。。

それで、ネットでとりあえず最近の開発環境で動く単純なプログラムを調べてみることにした。
本のプログラムでエラー出たタイミングですぐやれよって今更思った(笑)

今回理解するための目標プログラム

ちょうど手元にあった PIC16F88 のプログラムを”xc8”でコンパイルするプログラムをグーグルで検索。このコンパイラ名を指定して検索するのがポイント!そうしないと、古いプログラムとかアセンブラとか沢山混ざってくる。

16F88 XC8開発例 - LEDを蛍のように点灯させる(CCPモジュールのPWM機能)」うむ、簡単そうだし、丁寧に説明してあるので、このページのプログラムを目標に設定。

順番に読んでいく。その前に、コンフィグについて寄り道。

PICプログラムの一般的な設定

PICはチップによってピン数や機能が違うので一様には説明できないが、基本的な考え方がある。
まずはこのページ「コンフィグレーション・ワードについて」を読んだ。

次のように説明がある。
プログラム領域・・・実行するプログラムを格納しておく領域
EEPROM領域・・・電源供給がなくてもデータを記憶しておく領域
コンフィグ領域・・・動作設定を格納

これ読んだら「なんでプログラムのmainで実行する設定の他に、プリプロセッサで指定する設定があるんだろ?」と思ってた疑問が解けた。
(自分的推測)
そもそも、プリプロセッサで指定している設定は、プログラム領域に焼いていない。
プログラム開始では間に合わない処理を予め「コンフィグ領域」に焼いている。
プログラム開始後に行う設定は、柔軟に対応出来るようプログラムで行っている。
(推測終わり)

詳細は参考サイト見て欲しいのですが、おおまかに次のことを設定すれば良いそう。
コードプロテクトを有効にする。(お遊びの場合は無効でOK)
低電圧書き込みを有効にする。(PIC書き込み専用ツール使うなら無効)
ブラウンアウト・リセットを有効にする。(お遊びの場合は無効でOK)
パワーアップ・タイマーを有効にする。
ウォッチドッグ・タイマーを有効にする。(お遊びの場合は無効でOK)
動作クロックを選択する。
基本はこれだけでいいと分かったら見通し良くなった。
ブラウンアウトリセット、パワーアップタイマ等を知らなかったが、サイトの説明がとても親切だった。

リセットに関しては「リセットの使い方」というページの説明が細かったが分かりやすかった。
4つの種類のリセットについて説明してある。
(1) パワーオンリセット
(2) MCLR端子によるリセット(外部リセット)
(3) ウォッチドッグタイマタイムアウトによるリセット
(4) ブラウンアウトリセット(BOR)

MCLRという単語はPICのコンフィグでも出てきて、利用するかどうか必要になる。


プログラムの設定を理解する(mainより前)

それでは、参考にしたサイトのプログラムの前半部分を読んでコメント入れてみた。
最近の書き方はpragmaでやるっぽい。古い書き方してると、__CONFIGとかになってる。
// picプログラムおきまりのヘッダファイル
#include <xc.h>

// _XTAL_FREQ を定義しないとコンパイル時にエラーになる
#define _XTAL_FREQ 8000000      // 8MHz

#define PR2_DATA 0xFF           // PR2 設定データ
#define T2_DIV_BY_1 0b00000000  // T2CON 設定データ
#define CCP_PWM 0b00001100      // CCP1CON 設定データ

// 16F88
// CONFIG1
#pragma config FOSC = INTOSCIO // 内部発振使用(昔は外部の発振を使ったりした)
#pragma config WDTE = OFF   // ウォッチドッグタイマ
#pragma config PWRTE = ON   //パワーアップタイマーON
#pragma config MCLRE = ON   //マスタークリアー機能
#pragma config BOREN = ON   // ブラウンアウトリセットON
#pragma config LVP = OFF    //低電圧プログラム書き込みOFF
#pragma config CPD = OFF    //データーコードプロテクションOFF
#pragma config WRT = OFF    // フラッシュ書き込みOFF
#pragma config CCPMX = RB3  // CCPのパルス出力ピン
#pragma config CP = OFF     //プログラムコードプロテクションOFF

// CONFIG2
#pragma config FCMEN = OFF  // Fail-Safe Clock Monitor
#pragma config IESO = OFF   // Two-Speed Start-up

config2の部分は「PIC18F2550を使う (2) コンフィギュレーションビットについて調べる」 というページの途中に説明が書いてあった。今回は使わなそう。

あと、xc8インストール時にハードディスクに保存されるコンフィグ説明も参考になるかもしれない。
私の場合、ファイルパスは C:\Program Files (x86)\Microchip\xc8\v1.35\docs\chips/16f88.html だった。

プログラムの設定を理解する(main以降)

個々の部分、どの手順でどれを設定すればOKか読み終わっても分かってない。
PICの仕組み(PIC16F84A編)」も読んだがもうちょっと調べないと駄目だな。

OSCCON = 0b01110000;    // 内蔵クロックの周波数を8MHzに設定

PORTA = 0x00;           // PORTAを初期化
PORTB = 0x00;           // PORTBを初期化

TRISA = 0x00;           // PORTAの入出力設定
TRISB = 0x00;           // PORTBの入出力設定

ANSEL = 0x00;           // A/D変換を無効化
ADCON0 = 0x00;
ADCON1 = 0x00;

mainの最初に上記の設定をしていた。この辺で、入出力に利用するピン等の指定をしているようだ。それぞれのピンの指定方法はここを参考にした。
http://www.xcprod.com/titan/XCSB-DOC/physical_io.html
http://www.xcprod.com/titan/XCSB-DOC/physical_io_16f88.html


中途半端だけど、ガンダムが始まるので今日はここまで!!


2016/1/11追記:

レジスタの初期設定について

ちょっと調べた。
PIC16F88のデータシートが最終的に見るべきものなのだが、これは英語だし長いしとっつきにくい。
PIC 16F88の構造(PIC16F88-I/F)」というレジスタ周りを日本語で説明してるページがあった!すげぇ。。


最小限やるなら次の6つを設定しておけば良いらしい。
1. OSCCON
2. ANSEL
3. TRISA
4. TRISB
5. PORTA
6. PORTB

OSCCONはOSCILLATOR CONTROL REGISTERの略で周波数設定。
ANSELはANALOG SELECT REGISTERの略でA/D変換の設定。
TRISはTRISTATE PORT REGISTERの略で、ピンの入出力設定。
PORTはそのままPORT REGISTERの略で、ピンの値設定。

データシートの53ページに次のような文がある。
PORTA is an 8-bit wide, bidirectional port. The corre-sponding data direction register is TRISA. Setting a TRISA bit (=1) will make the corresponding PORTA pin an input (i.e., put the corresponding output driver in a high-impedance mode). Clearing a TRISA bit (=0) will make the corresponding PORTA pin an output (i.e., put the contents of the output latch on the selected pin). 
要約すると、「PORTとTRISは対応してて一緒に使うんだよ。bitに0と1で入力出力切り替えできるからよろしく。」って感じかな。

ここまで分かれば、実際の回路に合わせてレジスタ初期化を書いてあげればよさそうだな。

追記終わり。

PIC焼く汎用基板作った

ちょっと前の記事「PICkit3でPICを焼くための汎用基盤を作ろうの巻」の続き。

実際に作ってみた。

完成品がこちら。



裏面。前に書いた回路図通りに順番に配線していきました。
キレイに取り回せないのでビニル線でジャンプしてるw



ちなみに参考にしたサイトのこの画像を当初目標にしていました。


ほとんど、線が交差してない。よく作るなぁ。。


Pickitと接続しやすいように専用のケーブルも作った。



接続するときはこんな感じ。


超便利!!
これでブレッドボード使ったpic焼きを卒業できるぜ。


2016/2/28 追記:


2016年1月2日土曜日

3GIMとxivelyの組み合わせた位のサービスがあったらIoTをもっと利用しやすくなると思った

3GIMとは株式会社タブレインが開発している3G通信モジュール。(説明ページ「3GIMの紹介」)
コマンド類も似ているので、広く使われている3G通信チップのコンフィグを調整したり、ハード的に利用しやすくしているのだと推測している。

次に、xively(ザイブリー)というのはIoT向けのwebサービスで、ハードウェアから送信された値(例えば、温度)を保存するときに利用する。( https://xively.com/ )
POSTをするときにトークンを付与すれば、指定したアカウントに紐づく、特定のハードウェアとして認識されてデータが分類される。

さっき思ったことは、この2つのサービスがくっついていてもいいなと思った。
つまり、通信モジュール+クラウドサービスのセットで、通信モジュール→クラウドへのデータ送信はもちろんとし、クラウド→通信モジュールにデータ送信することもできたらいいなと。

使い方としては、例えばビニールハウスの温度調整でストーブに通信機能をもたせたとする。
「ストーブ」にこの通信モジュールをくっつけているとする。
温度と使用した燃料は常にクラウドのサーバに送信している。
室内の温度も見れるし、webで温度調整もできるようになるのではないか。
ビニールハウスは燃料代がすごいらしいから、無駄を減らしたいよね。

あと、3G通信機能をもったやつを親機、短距離無線機能を持ったやつを子機として動作するモジュールにしてあげとけば、色々と使いやすそうに思うんだよね。

実際、自動販売機とかトラックとかには通信モジュールが載ってて、データは送信しているんだけど、こういった汎用的なウェブサービスっていうのは無いと思う。(調べてないけど)

簡単じゃないのかなぁ。結局、ハードウェア毎にプログラムしないといけなくて、コストの割に楽にならないかもしれない。

ふと思ったのでメモ。(いつか何かをひらめくかもしれないので)