わふうの人が書いてます。

iOSアプリケーション開発、BLEのファームウェアとハードウェア試作のフリーランスエンジニア。

nRF52 Global Tech Tour 2015 に参加してきました

nRF52 Global Tech Tour 2015 Nordic Semiconductor は、Nordic Semiconductor社のBluetooth Low EnergyシングルモードチップnRF52の開発者向けイベントです。

世界各国で開催されていますが、日本では12月8日に東京そして12月10日に大阪で開催されます。東京 六本木ヒルズでの回に参加してきたので、レポートします。

ツアーの雰囲気や飲食

ツアーに参加すると最後に、9500円位するnRF52版開発ボードが参加者全員にプレゼントされました。各国の電波法の適用は受けていないので、外部に電波が出てしまわないようにシールドボックス内部などで使う必要がありますが、太っ腹です。

会場や集まった方々の雰囲気

場所は アカデミーヒルズ でした。360席ほどある会場が満員でした。
周りをざっと見渡すと、年齢は30代から50代、9割位の方がスーツ、またほとんど9割以上が男性でした。
日本の電気工学系の学部は、女性比率が2%程度だったりするので、こうなってしまうのだろうと思います。

プレゼンテーションは英語ですが、日本語の同時通訳が提供されていました。質疑応答も通訳の方がサポートしてくれるので、日本語で大丈夫でした。
同時通訳のイヤホンを使われている方は、見渡すと1割くらいで、普通に英語に慣れている方ばかりなのだな(大手電機メーカの方もきっと多いと思うので、それが当然なのかもしれませんが)
と思いました。

フロアにあるお手洗いは1つで、男性12人程度で一杯になるもので、休憩のたびに少し行列ができていました。私は出口付近の席にいたので、いの一番に外に出られたので、並ばなくてすみました。座る場所は指定されず、どこでもよいので、早めに出かけて場所を確保しておくのが、いいのかもしれません。

飲食など

お昼にはお弁当が出ました。

会場の直ぐ側には、飲み物とお菓子がたくさんありました。
紅茶、コーヒー、ペットボトルの水、そしてマフィンのようなお菓子が常に補充されていました。紅茶ばかり頂いていましたが、美味しい紅茶でした。

スライド抜粋

nRF52の概要

nRF52シリーズは、Nordic Semiconductor社にとって第3世代となるBluetooth Smart Socです。

nRF51シリーズは、2.4GHz帯の汎用無線回路と周辺回路そしてプロセッサを組み合わせて、通信処理をプロセッサに担わせることで規格の機能追加に柔軟に対応できる構成をとっています。

nRF52でも、その構成はnRF51と同じです。プロセッサの処理能力を高めフラッシュおよびRAM容量を増加、電源制御や周辺回路の数や能力を強化、そしてNFCを搭載しています。

nRF51はBluetooth 4.0までの無線通信技術に対して最適化されている感じがします。

nRF52は、Bluetooth4.2で追加されたセキュリティおよびIoTに向けた機能、また今後のBlueototh無線通信技術に追加されていくかもしれない、通信の高速化、音情報のやりとり、またIoTに向けたネットワーク技術への対応などに対応できる構成となっています。

プレゼンの構成

セミナーの流れとその雰囲気は、 nRF52 セミナー のまとめ がよくまとまっています。とくに@ksksueさんの一連のTWは、詳細までまとまっていて、素晴らしいです。

セミナーの資料は当日ダウンロード配布されていました。セミナーで配布された資料全体を不特定多数に勝手に配布したりするのは、やめてくれという話でしたが、ブログで技術紹介をするときに、スライドの一部を参照するのはできるっぽいらしいので、このブログでは必要な部分を掲載しています。

全体のプレゼンテーションは、半導体のハードウェア構成、その特徴と活用のポイント、そしてソフトウェア・スタックやSDKのファームウェア・開発、そしてIoT系の話題で構成されていました。また最後に、日本のモジュール・メーカ各社(太陽誘電、富士通、ブレイブリッジ、ホシデン)から、nRF52の無線モジュールについてのプレゼンテーションがありました。

プレゼンテーションは、ほとんどがハードウェアよりの内容でした。BLEは2015年時点では、スマートフォンと連携するハードウェアによく使われています。ですから、スマートフォンおよびそのアプリケーションとの連携や開発情報は重要だと思うのですが、そういったものは今回はカバーされていませんでした。その代わり、2015年はいろいろなところで話題にされたIoTについて、1セッションが取られていました。

プロセッサとその周辺

  • プロセッサの処理能力の強化
  • EasyDMAとPPIを組み合わせたプロセッサを使わずに済む仕組み
  • スリープ時の消費電流をより低減

などが特徴です。

処理能力の強化

nRF52は、デジタル信号制御市場向けに開発されたARM社のプロセッサCortex-M4Fをコアに採用しています。

Cortex-M4自体、デジタル信号処理に適した命令が追加されてDSP機能が強化されています。Cortex-M4Fは、Cortex-M4に、さらに32ビットの単精度浮動小数点ユニットというハードウェアを追加したものです。

nRF52の動作周波数は 64MHz RAM 64 kByte フラッシュROM 512 kByte です。

nRF51は、Cortex-M0 で、動作周波数 16MHz、 RAM 16 kB または 32kB、 フラッシュROM 128 kB または 256 kB です。

nRF52はnRF51よりも、単純にクロックで4倍、また浮動小数点演算は専用の演算回路がハードウェアであるため10倍ほどの演算能力があります。

プロセッサを使わずに済む仕組み

nRF52は、nRF51にもあったPPIおよびEasyDMAという2つの機能を強化して、プロセッサがスリープしたままでも、例えばTWIで接続された加速度センサーから一定周期でデータを読み込む、ような処理ができます。

PPIはnRF51からある機能です。これは周辺回路にあるイベントとタスクを、ソフトウェアで結びつけて、周辺回路を組み合わせた機能を実現するものです。

例えば、パルス幅変調信号を生成したいとします。

PPIでは、周辺回路にはイベントとタスクという概念があります。

TIMERには、オーバフローやカウント値が設定値と同じになった等の、いくつかのイベントがあります。またTIMERには、カウント値をカウントアップする、または0クリアする等のタスクがあります。

TIMERの、カウント値が設定値と同じになったイベントを、カウント値を0クリアするタスクに、プログラムで結びつけるように設定します。こうすると、カウント値ごとにイベントが発生させられます。

また、汎用IOであるGPIOTEには、出力値をトグルするタスクがあります。先ほどのTIMERのイベントを、このトグルするタスクにも結びつけましょう。すると、一定期間ごとにGPIOの出力がトグルする、つまりカウント値で指定した期間の2倍のパルスが出力できます。

例にあげた、PWM信号の生成は、プロセッサではよく使われる機能です。ですから、一般にPWM信号を生成してGPIOから出力する機能は、マイコンメーカ各社がそれぞれ工夫してタイマー自体の機能として提供しています。nRF51およびnRF52は、これ以上シンプルにできないところまで機能を簡素にして、それらの機能をソフトウェアで組み合わせられるPPIという仕組みを使って、複雑で多種多様な機能を組み上げるというアプローチをとっています。

EasyDMAはnRF51でも採用されていましたが、無線回路やSPIスレーブなど一部の周辺回路のみにありました。nRF52では周辺回路全てにEasyDMAが入りました。

EasyDMAは、周辺回路が64kBのRAM領域に直接読み書きする機能です。例えば、TWI(いわゆるI2Cです)などのシリアル・インタフェースで加速度センサーの値を読みだす時に、プロセッサを起動することなく、TWIから設定されたRAM領域に直接データを書き込ませられます。

PPIとEasyDMAを組み合わせると、例えば、TWIで指定したメモリ領域から2バイトを出力(加速度センサーのアドレスと読み出し指示)して、3バイトを読み込みメモリポインタをインクリメントしつつRAMに書き込む、これを10回繰り返したら、プロセッサに割り込みをかける、といったシーケンスを組み立てられます。

このシーケンスの実行に一切プロセッサは必要ないので、プロセッサはスリープ状態、つまり電力を低減できるというわけです。

スリープ時の消費電流をより低減

nRF52には、スリープ時の消費電力も、より低減できる工夫が入っています。プロセッサのコア動作時の消費電力は、3V電源でDCDCが有効なとき3.3mAです。RTCが有効なアイドル時の消費電流が1.6マイクロアンペア、スリープから40マイクロ秒でスタートアップします。

また、RAMの値保持は、4kBごとに保持するしないが指定できて、保持する場合は4kBごとに40nAです。nRF51はRAM全体で保持する保持しないを指定できて、保持する場合の消費電力は1.2マイクロアンペアでした。

消費電流を極限まで低減したい場合に、ファームウェア開発者がよりハードウェアにより手が届くようになっています。電源がACアダプタなどであれば、マイクロアンペア程度の消費電流の増減が問題にはならないなら、そのような作り込みをする必要はまったくありませんが。

周辺回路

無線回路

無線回路の消費電流は、動作電圧3VでDCDCが有効なとき < 6mA です。送信電力が最大+4dBm、最小-20dBmに設定できるので、消費電流に幅がでます。

受信感度は-96dBm、nRF51が-93dBmですから2倍高感度化、またオンチップバランにより外付け部品は回路図上では2つにまで簡素化されます。

nRF51に対してnRF52は、受信時の消費電流を半減、送信時の消費電力を3割減となっています。この値はnRF52のオンチップDC/DCが有効な場合での値です。DC/DCを使わない構成をとった場合は、オンチップのLDOのみが使われます。この時、nRF51に対してnRF52の受信時消費電流は1割減、送信時消費電力は4パーセント増となります。

またオンザフライでパケットの暗号化/復号化、またペアリングした相手がランダムアドレスを使っている時に、そのアドレスを復号する機能が無線回路に入りました。

Bluetooth4.0では、ホワイトリストに指定できるアドレスは、パブリック・アドレスのみでした。Bluetooth4.2では、ランダム・アドレスも指定できます。

nRF51ではランダム・アドレスの解読はプロセッサで処理する他ありませんでした。これが無線回路で処理されるので、消費電力を増やすことなく、Bluetooth4.2で追加されたホワイトリストの機能が活用できます。

またIoTなどの通信では、パケットの暗号化/復号化は常に使われる機能となっていくでしょう。そのような処理を無線回路で行うことは、消費電力低減に役立ちそうです。

電源回路

nRF51はDC/DCを使う/使わないで、外部配線が異なりました。nRF52はDC/DCに必要なコイルとコンデンサが、あるかないかだけのシンプルな違いだけになります。

GPIOの入出力電圧には、VDDがそのまま使われます。

DC/DCとLDOを組み合わせて、コア電圧は無線回路などが使う1.3V、プロセッサが使う0.9Vの2種類が作られます。これらはチップ内部でのみ使われます。

システムの動作状態で、DC/DCおよびLDOの動作状態が自動的に切り替わります。

リフレッシュモードの消費電流波形をみると、例えばスライドの例では、350マイクロ秒ごとに、15mA 10マイクロ秒のスパイク状の電流が流れています。

消費電流を計測するときに、普通のテスターをDC電流モードで直接使うと、このようなスパイク状の電流をサンプリングできずに、正しく計測できません。デジタル・マルチメーターの中には、電流値を積分して平均値を表示するもの、例えばADCMTの76461Aなど、がありますが、サンプリング周波数は20kサンプル/秒、5マイクロ秒周期で、10マイクロ秒のパルス電流を測るには、足りません。

nRF52の開発ボードのHardware Filesにある回路図 PCA10036_Schematic_And_PCB.pdf の6シート目を見ると、電流測定用に、P22があり、SB9をパターンカット、R6に適当な抵抗をつければ電流測定に使えるようになっています。

オシロを使うなり、適当な抵抗と大きめの電解コンデンサを組み合わせて、十分なまった波形にするなりして、測定するようにします。

HFCLK

nRF52の32kHzのクロックと32MHzのクロックがあります。HFCLKは32MHzのクロックのことを指します。このクロックはnRF52内部のPLLが出力しています。

外部の32MHzの水晶は、常に発振しているとは限りません。ソフトウェアあるいは内部ハードウェアから、XO REQUESTという信号がHIGHになった時に、水晶発振回路が動作を開始して、それにPLLがロックします。

XO REQUESTがLOWであれば、PLLはフリーラン状態です。またXO REQUESTがたってからPLLがロックするするまで、いくらか時間がかかります。

ADC

8/10/12-bitの逐次比較型ADC(Successive approximation ADC)です。0からVDDまでのフルスケール入力レンジ、シングルエンドまたは差分入力、最大8チャンネル、外部タイマーを必要とせず連続サンプリング(~200kHz)できます。

ADCに限らずnRF52の周辺回路は、通常であれば別にタイマーが必要になる場面でも、そもそもタイマーが必要になる周辺回路には、外部からタイマーを必要としないようになっています。タイマーは貴重な資源ですから、周辺回路に取られずにすむのは、ありがたいです。

nRF51のADCとは、ハードウェアが違うADCが採用されています。ファームウェアからの使い方も、まったく異なります。nRF51からnRF52にコードを移植するときは、ADCを使っているならば、書き直します。

4回サンプルして平均を求めるオーバサンプリングなど、音声用途などに使える機能があります。

PDM, I2S, PWM

PDMは、Two wire digital audio interfaceの略です。マイクロホンに使われる、パルス幅信号入力です。L/Rの2つのマイクロホンから信号を取り込むことができます。

I2Sは、SPIをベースにオーディオ向けに変更されたシリアル・バスインタフェースです。コーデックを内蔵したオーディオ用半導体によく使われています。それらの半導体の接続に使えます。

nRF52のPWMは任意波形の生成にも使えるほど、強力です。おもちゃ品質の音出力であれば、PWMつまりnRF52単体でも、波形を生成、出力できます。またLEDのフェードイン/フェードアウトなどにも使えます。

NFC

nRF52には、NFC-A Listen mode compliant な機能があります。NFC-Aは、13.56MHzの磁界を発生するイニシエータと、その磁界を受け取り負荷変動でイニシエータに信号を返すタグの2つがあります。nRF52がなれるのはタグで、Read/Write Modeをサポートします。nRF52はイニシエータには、なれません。

BluetoothはNFCを、無線通信を使わない鍵交換手段として活用します。無線以外の媒体で鍵を交換することで、セキュリティをより強固にできます。また、NFCはモノ自体に近づかないと反応しないので、いま接続したいものが何かが物理的にわかりやすくなることも利点です。

NFCで鍵を交換する場合、Just works、OOB(Out-of-Band)ペアリング ができます。

nRF52のNFCは3つのモードがあります:

  • DISABLE
    – すべてが電源オフ
  • SENSE
    – システムはオンまたはオフ
    – 消費電流は100nA程度
  • ACTIVATED
    – フレームの送受信ができる
    – 400uA程度

NFC-Aのプリコンパイルされたライブラリで、Type 2 Tagの次の機能が使えます。

  • NFC NDEFメッセージフォーマット
  • コネクション・ハンドオーバ・レコード
  • アプリケーション・ランチ・レコード
  • URIレコード

これらを使うと、BLE機器が対応しているアプリケーションを開く、(商品や解説などの)ウェブページを開く、などもできます。

このライブラリがサポートしているのはreadモードだけです。writeモードはメモリ消費量などを考慮して、今は対応されていません。対応はできるので、要望があればwriteも提供するとのことです。

nRF52のファームウェア・開発

Bluetoothの認証を確保したまま、ユーザアプリケーションを動作させるために、半導体と一緒にソフトウェア・デバイスという、スタックや時間制御を行うものをバイナリで提供しています。

ユーザアプリケーションは、タイミング制御などをこのライブラリに任せることで、Bluetoothの認証制度の恩恵を受けることができます。

nRF51ではS110, S120が提供されてきました。これらはメンテナンスモードに。新機能などはS130に移行。S130はnRF52のSDKとAPIが近い。もしもnRF51からnRF52に移行するならば、S130を使っておけば、移行しやすくなるかも。

nRF52のソフトウェア・デバイスは、S132。リリースは2016年2月予定。

  • S132
    – タイムスロットAPI。マルチプロトコル。
    – メモリの効率、セキュアDFU。
    – セントラルとペリフェラルの数、選択設定できる。
    – バンド幅、それぞれのリンクごと。設定。

タイムスロットAPIとは、無線回路がBLEに使われていな空き時間に、ファームウェアから利用するAPI。例えば、独自のメッシュネットワークや、独自の無線通信プロトコルを、BLEと共存させながら、ファームウェアで実装できる。

S132はANTを含む。リアルタイムOS、RTXとFreeRTOSに対応している。ソフトウェア・デバイスの上に、リアルタイムOSが乗る形。

  • S132の次
    – IPv6 over BLE
    – L2CAP チャンネル
    – Long MTUサイズ
    – 1パケットの255バイトまで

SDKには、標準的なSDKに加えて、他に:

  • IoT SDK
  • HomeKit SDK

がある。

IoT系の話題

省略。メッシュネットワークはどうなる?の質問が多かった。

日本の会社からの無線モジュールのリリース予定

2016年2月あたりから日本の各社から無線モジュール。

質疑応答のまとめ

  • iBeacon用にはnRF51よりもnRF52がおすすめなのか?
    – nRF52はDCDCまわりが変更されている。自動的にダイナミックにモードを切り替えるから、DCDCを有効にして使え。
  • 電源の入力電圧範囲が最大3.7V。最近のLi-ionでは、3.8Vとかそれ以上になる。Li-po等は想定外か。
    – nRF52とは別にDCDCを用意して対応すればよい。(注釈:充電管理ICをつけることになるので、大抵そうなる)
  • Q: nRF52内部のフラッシュには、どのタイミングで書き込まれるのか。
    – pstorageというライブラリを通じて行うことで、ソフトウェアデバイスを通じて、フラッシュ書き込みがされる。
  • Q: フラッシュの書き込み位置の分散しているのか
    – それはしてない。
    – (注:)
  • S130とS132の互換性は?
    – スタックの内部とかは異なってくる。その辺りは違う。まぁいけるか。
    – APIは互換。
    – 移植、ピン配置まわり、PWMの設定。
  • BLEのセントラル、ペリフェラル、ANT、3つを統合したスタックは出るのか?
    – nRF51では現在のスタックで、メンテナンス。つまり、でない。
    – nRF52で提供。
  • nRF52に対して、ShockwaveやGazelは提供がある?
    – 提供される。
  • ソフトウェアデバイスにとられる最大の処理時間はどの程度か。
    – 60us、最大で。
  • QDID、いままでS110/S130でIDが違う。今後は1つに統合されて?
    – 統合される。
  • RTOS2つあるけど、どっちがおすすめ?
    – どっちでも。自分はFreeRTOSが好み。
  • IoT SDK タイムライン?
    – アルファステート。nRF52のみ。別途マーケティングから。
  • NFC的な、技適みたいななにか制度が必要?
    – NFCフォラームのロゴ認証程度?
  • サービスとキャラクタリスティクス、数の上限はあるのか?
    – メモリとチップでの制限。
  • nRF51、キャラクタリスティクス8つくらいだと、繋がりにくかった時が。
    – 通信相手の問題じゃない?

Nordicの開発環境で、J-Linke/Liteでリアルタイムなログ取りをする

Nordic Semiconductor社のnRF51822は、BLEシングルモードのSoCとして数多くのモジュールに採用されていて、開発でもよく使います。

SoCのなかにあるCortex-M0はMDK-ARMを使うと、J-Link liteでブレークポイントを4つまで設定できます。通常の組み込み機器のファームウェア開発であれば、デバッグしたければブレークポイントを設定して値や実行フローを確認します。しかしBLEのファーム開発では、止めてしまうと通信が止まってしまいます。

Nordicの開発環境には、SDKにある debug.h をみると、シリアル端子からのprintfデバッグと、フラッシュメモリにログメッセージを貯めておく2つの方法が提供されています。シリアル端子はよく使うのですが、製品化の基板ではIO端子を使いきってしまっていたり、基板に余裕がなくて端子をつけられないなどで、デバッグ専用のシリアル端子が確保できないこともあります。

そのようなときに、SWD (Serial Wire Debug) http://www.arm.com/ja/products/serial-wire-debug.php 経由で、ターミナルにテキスト出力する機能が、SEGGERの Real Time Terminal (RTT) https://www.segger.com/jlink-real-time-terminal.html です。

チュートリアルとソースコードを公開されています。

https://devzone.nordicsemi.com/tutorials/6/debugging-with-real-time-terminal/

printfを、このターミナルにリダイレクトすることもできますが、簡単にsprintfで内部的に切り替えてしまうのもいいのかもしれません。

1
2
3
4
5
6
#define RTT_PRINTF(...) \
do { \
char str[64];\
sprintf(str, __VA_ARGS__);\
SEGGER_RTT_WriteString(0, str);\
} while(0)
1
#define printf RTT_PRINTF

IoT雑感

IoTとか単語が盛り上がっているので、そういうニュースを見ると影響を受けて、自分が考えていることが変化していくと思う。なので、2015年3月3日の時点で、自分が何を考えていたかのメモ。

IoTって自分がしばしば目にするけど、なぜ話題になるのだろう? わからん。

世の中が動くときは、必ずお金の動きがそこにあるはず。なので、例えばものからデータを取り出すことができるようになったことが世の中を変えるとすれば、その流れは、データを取り出す、そこから意味を取り出す、行動に反映されるの1ループ。

つぎに、どんなものの何のデータ(質や種類)か、意味を取り出すのは誰か(データを生み出した人の端末、データを取得したネットワーク側、データを購入した何者か)、行動に反映する(購買の推薦、道順の提案、割引クーポンを提示する)。3つの段階それぞれに、主語と目的語と動詞、を当てはめて生み出される無数の組み合わせ、それらすべてがIoTと呼べる何かだろうし、その中の幾つかは、強烈なお金の流れを伴ってきそうな気は、なんとなくするといえばしそう。

  1. ニュースの話題が少なくて、取り上げやすいIoTという単語で特集を組むところが多い。

タイトルをみて買う買わない読む読まないを判断する人が多いならば、盛り上がっているならば、タイトルにIoTという単語を入れておきたい。
技術系の話題であれば、ネットワークに接続するものであれば、およそあらゆる話題をIoTという単語に結びつけて話ができる。なので、結びつけてしまえばいい。いろいろな媒体がそれをすると、自然と同期して、全体でなんとなく盛り上がり感がでて、さらにその流れが強まるフィードバックがかかる。

  1. モバイルのニュースに意味がなくなった。

iOSも登場して、新しいサービスやアプリケーションへの関心は、もうない。iPhoneそれ自体、新機種がでても薄い板の別種がでたのか程度でしかない。性能が向上して、初めて手にする人が多い時期は、どんなアプリケーションを使おうかと興味関心が高い。その時期であれば、新しいアプリを紹介して、その広告やインストール実績でお金を得ることもできた。だが、スマフォが日常になれば、いちいちゲームを探すのは、もともとゲームが好きな極めて一部だけに戻る。たいていは、リアルの人脈で、口コミでという流れに、戻るだろう。

  1. 前提が変化した。

スマートフォンが普及したので、データ収集するネットワークに常につながった、いわゆるエッジのデバイスが大量に世にあふれた。また、スマートフォンにアプリケーションを簡単に配布できるので、その普及した装置をインフラとしてとらえて、サービス展開もできるようになった。またAzureなどで機械学習がサービス化されて、データの蓄積とあわせて手軽に運用できるようになっている。

どこかのだれかしかできない特殊な技術だったり、技術自体は公開されても高度すぎて理解できなかったり、あるいは実行環境が高価すぎて、その環境を使いこなせる人の数が少なすぎて、誰か雇って業務として割り当てようにも人がいないとかだと、絵に描いた餅に終わる。また、競合他社も同じ状況だろうから、ちょっと試して効果を見たい程度のモチベーションだろう。そうすると、高価で希少ななにか、に投資する気にはならない。

BLE系を見ていても、センサーやスマートフォンという環境が整い、開発者も何万人単位でいる。いままで絵に描いた餅だった前提が、一気に崩れてる気がするので、もしも競合他社がひっそりそれを試して知見を蓄積していたら?と思えば、手を付けない理由が消えていく気がする。

  1. サービスだとネットワーク側にデータを蓄積することが価値にもなりそう

機械学習やら実行していくとなると、今後の変化にあわせて追従していくなら、フィルタしない生のデータを蓄積しておきたくなる。適当なクラウドサービスを使うとしても、バイト数でみて現実的に引っ越し可能な量を簡単に超える。だから、クラウドサービスを提供する側から見れば、適切な価格で他社にもある機能を同程度に提供しているなら、顧客は簡単には契約先を変えないだろうと思いそう。

サービス提供側も、十分なデータ量をもっているかが、サービスの提供の振る舞いにつながるだろうから、データは貯めるだろうし。

  1. 人間の習慣の変化。

スマフォの経路案内を見て移動するのが日常になってきているから、画面を見て行動するのが、習慣化していそう。また購買活動も画面を見て、気に入ったらその場で発注とか。

  1. IoTというけど先行事例はウェブ系、ただ参考にはならないか

データ収集がはじめから仕組みとして入っていて、ネットワークに接続していて、人の行動を変化させることで利益を得るなら、ウェブ系のあらゆるサービスはそれになる。開発投資も何年もされているから、IoTといえど仕組みはそこにありそう。ただ、成績評価の指数が、人間が何かを買う、人間がリンクをクリックする、人間が画面を見る、なので、その指標がIoTで同じように使えるか?は気をつけないと、仕組みが違うものを無理やりウェブの仕組みで理解したら、勘違いしかなさそう。

  1. 端末機器メーカ

IoTといって、スマートウォッチ(自称)を発表する端末機器メーカがたくさん出てきています。端末機器メーカは、より多くのハードウェアを販売すること、が本能です。そのために、外観デザインやスペックの高さ、あるいは価格の値ごろさをアピールします。

スマートウォッチ(自称)は、Androidなどが提供する通知の仕組みなどに対応することで、Androidのアプリ開発者が用途を開発して利用場面を提供してくれそうですから、ハードウェアだけで閉じこもれるので、手をつけやすそうです。また、端末機器メーカは売上の絶対値もですが、シェアが勝負です。競合他社が持っている商品ジャンルが自社にはないのは、売る本能からすれば恐怖になりそうです。

スマートフォンも、最初の1台が売れる黎明期、年々性能が高まり、その性能に合わせてより魅力的なゲームやアプリケーションが登場する成長期を超えて、いまではたいていの端末でたいていのアプリケーションは快適に動く、必要だから買うだけの成熟あるいは飽和期です。人とは違うものや、必要を超えたハイスペックなど、趣味性の高いものも出せば売れるでしょうが、それはパソコンの時代でも同じように、主流ではありません。

コモディティ化したパソコンの世界では、製造会社は残りませんでした。Dell、あるいはThinkPadを買収したLenovoのように、製造と販売とサポートを統合した会社が、たまたま製造をしていると見るくらいが良さそうです。

  1. 半導体関連

次の半導体のシェアを競う場面として、車載、そしてIoT系も話題としてはありそうです。

車載のキーワードを上げると、安全、事故回避、自動運転系があります。イメージセンサや高周波レーダーのセンサーデバイスからの情報を統合、事前に学習しているデータから危険性があると判断すれば、運転操作に干渉して危険度を引き下げる仕組みです。今の技術や半導体の製造費用が、実用範囲に入り話題になっているのだと思います。技術開発競争は進むでしょうから、基本、人間よりも信頼度は高くなるでしょう。

自動車の動力源が、電気であろうがガソリンであろうが、高度な電子回路が不可欠になります。電気であればモータの制御、ガソリンであっても高い燃費の実現には機械制御が不可欠です。それらの動力源、またブレーキを含めた操作など運転操作の基本機能を支えるために、半導体が不可欠です。その一方で、前に上げた安全装置あるいはカーナビやカーオーディオに人間の目に入るメータ表示など、より多くの台数を売るために、アプリケーションの魅力を高める必要も出てきます。

この組み方は、携帯電話の半導体は、アプリケーション・プロセッサと、通信を制御するベースバンド・プロセッサに分かれて開発されてきた歴史によく似ています。今までの携帯電話での半導体会社の競争と同じパターンを、なぞりそうです。

IoT系は、開発ツールなどを各社で足並みをそろえつつ、独自色を追加して行く感じでしょうか。マイクロプロセッサを販売するためには、開発環境、コンパイラ、そしてそれらに慣れた大量の技術者が必要です。独自のプロセッサコアでは、最後の大量の技術者が確保しづらいでしょうから、今のようにARMに集中する、ライセンス料が高くて払えない場面はMIPSも登場する感じでしょうか。

mbedというハードウェアを抽象化したオンライン開発環境に、各社のクラウドとすぐに連携する評価キットまで登場して、なにか動くものを作るならばスキルも理解すら必要がなく、手順にしたがいサンプルを動かして、ちょっと変更するだけで要望を満たせるまでになってきています。

どうやって半導体会社は儲ける気なのでしょうか。

ウェブ系の開発が参考になるかもしれません。パソコンさえあれば、基本ウェブサービスは開発できます。テキストエディタを開いて、JavaScriptを書いて、ブラウザで動かせばいいでしょう。Node.jsなどもありますから、サーバサイドをローカルで閉じて開発し切ることもできます。開発したものは、AWSなどに乗せてサービスとしてデプロイできます。サービスを開始するまでのコストは金額的にはゼロに限りなく近いです。

ウェブの世界で、開発キットで儲けているところはあるでしょうか。ありません。ウェブ系での儲けは、サービスを提供する側の売上、そしてサービスを提供するインフラを提供する会社の使用料を回収です。半導体自体はサービスが売れれば自動的に売れます。ネットと連携している土俵が同じなら、自社製品も他社製品も価格は同じで、IOやADCなどの周辺、あるいは静電気に強いとか、電源電圧範囲や消費電力、あるいはロジックブロックやアナログブロックを内蔵しているなど、マイコンとしての価値自体でうる、純粋に半導体での商売になりそうです。

  1. ハッカソン

そうはいっても、会社を作って事業となると、雇いたい人は、取りあえず動くものを一人完結で作れる人になりそうです。それは、人数が小さいほうが、やりとりの手間と時間を省けるので早い場合がある。トライ・アンド・エラーをするときには、一人もしくは数人程度の小さいほうが、変なトラブルを巻き込まず純粋に技術だけで動きやすい。など。

そんな人材は教育でどうなるものではなく、たいていは天然物なので、そういう人が反応しそうな面白そうなイベントを開催して、まずリアルな場面に寄せ付ける。そのうえで、フィルタリングをかけて、誰がどの程度できるのかをあぶりだして、雇用を持ちかけるとかに、ハッカソンは便利に使えそうです。

iOS8のvisit monitorin (訪問先追跡)

iOS8のvisit monitoring

iOSは、位置情報取得が初めて登場した時から、電池消費量に注意して設計されています。位置情報を調べる物理手段は、携帯電話基地局、WiFiルータの識別子、GPS などがありますが、アプリケーションが位置情報を取得するときに、どの物理手段を使うかを直接していすることはありません。必要とする位置精度にあわせて、iOSが最適な物理手段を選択して、アプリケーションに位置情報を通知してくれる作りになっています。

毎年新しい位置情報の技術と機能が導入されているiOSですが、iOS8では、visit monitoring という訪問先の自動記録機能が導入されました。これは24時間365日、ユーザが訪問した場所とその滞在時間を記録し続ける機能です。

Githubのサンプルアプリ。visit monitoringで取得したデータをテキストで表示し続けるだけのサンプルアプリです。

https://github.com/reinforce-lab/ObjC_Codes/tree/master/visitMonitoringTest

visit monitoringの使い方はとても簡単です。

iOS8は、位置情報取得の権限が、when in use, アプリが実行されている間のみ(画面表示されている間のみ)と、always, バックグラウンドなど常に取得、の2つにわかれました。

まず、訪問先を記録し続けるなら、アプリケーションが画面に表示されていない時(バックグラウンド)でも情報が取得できなければ意味がないので、常に情報取得する権限を要求します。

CLLocationManagerのオブジェクトにデリゲートを設定して、 requestAlwaysAuthorization メソッドを呼び出し常に位置情報を取得する権限を要求します。初回呼び出し時には、iOSがユーザに権限要求のダイアログを表示してくれます。

Xcodeで、プロジェクトの Capabilities の Background Modes で Location updates にチェックを入れておくのも、忘れないようにします。

1
2
3
4
5
6
7
CLLocationManager *_locationManager;
...
_locationManager = [[CLLocationManager alloc] init];
_locationManager.delegate = self;

// requesting a permission. NSLocationAlwaysUsageDescription key must be in your app’s Info.plist file.
[_locationManager requestAlwaysAuthorization];

アプリケーションが実行されると、必ず CLLocationManager のステータス変更が通知されます。権限があれば、位置情報取得を開始したいので、この didChangeAuthorizationStatus: のなかで startMonitoringVisits

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
-(void)locationManager:(CLLocationManager *)manager didChangeAuthorizationStatus:(CLAuthorizationStatus)status {
switch (status) {
case kCLAuthorizationStatusAuthorizedAlways:
[_locationManager startMonitoringVisits];
break;
// 権限がない場合は、なにもしない
case kCLAuthorizationStatusAuthorizedWhenInUse:
default:
break;
}
}

- (void)locationManager:(CLLocationManager *)manager didVisit:(CLVisit *)visit {
//ログを残す
[self write:[NSString stringWithFormat:@"%@", visit]];
}

visit monitoringは、イベントが発生するたびに iOSは CLVisitのオブジェクトを渡して デリゲートの didVisit: を呼び出します。訪問場所に入った時点、訪問場所を去った時点それぞれ通知が来ます。

どの条件で訪問したと判定するかはわかりませんが、飲食店や書店あるいはオフィスなど、訪問したことに意味がありそうな場所が通知されている感じはしました。電力消費量は、気になるレベルではない感じです。

位置情報の取得にどんな手段を使っているかは、わかりません。CLVisitの位置精度を見ていると、+-60メートル程度のログをよく見るので、おそらく基地局レベルとWiFiを組み合わせて受動的に取れる範囲の位置情報を使っているのではと思います。もしもGPSを利用しているなら+-20メートル以下になるでしょうから。

いまのiOSデバイスは、少ない電力で動きを常時検出できるように、小さいマイコン(M7/M8プロセッサ)が入っています。それらの動き情報も統合して利用しているのだろうとは思います。

電池消費量を気にするにしても、訪問したと判定した瞬間、その瞬間にGPSをONにしてもよさそうなものだと思いますが、訪問先が屋内であったりすること、必要なものは位置精度というより、お店に立ち寄ったといったイベント情報であれば、GPSという精密な位置情報それ自体に意味を見出さない考え方なのかもしれません。

iOSは、WiFiの識別子を取得する関数がプライベートAPIになっていて、ストア承認されたアプリでの利用が禁止されています。ですがiOS自体は、お店のWiFiだとわかるようなデータベースを持っていたりするのかもしれません(あてずっぽう)。屋内地図のデータ提出受付をしたときには、WiFiやiBeaconを含めて、より詳細な位置情報をAppleつまりiOSが持つことになるのは、確実だと思います。

ただ立ち止まったりしただけでも記録されるかなど、実験してみてもいいのかもしれませんが、めんどいのでパス。

何に使うのか

まず思い浮かべるのは、カレログ、ですが、iBeaconの時にそうであったように、単一のアプリの視点からみても、利用場面は出せないものなのだろうと思います。

Bluetooth Low Energy の時もそうでしたが、Appleは、自社が組み上げるサービスに必要な新しい技術要素を、サービス発表の2年前から出してくる感じがします。おそらく、iBeacon、visit monitoringなどは、iOS8以降の世界を組み上げるのに必要な1技術要素なのだろうと思って、とらえたほうが良さそうです。

SceneKitで遊んでみる

SceneKitで遊んでみる

iOS8にはいった、3Dの何かを簡単に作れるSceneKitで遊んでみた。

キャラクタが画面中央に表示されて、5秒に1回ジャンプのアニメを実行する。BananasAsimpleSceneKitplatforminggame と https://github.com/shu223/iOS8-Sampler のSceneKitのサンプルをコピペでつなぎあわせたようなもの。

感じ的には、three.js で3Dしている方の説明とおんなじ感じだなと思った。せっかくだから、ミクさんのアプリを作ればいいのに、3Dデータ変換方法がわからなくて、断念。

Githubのサンプルアプリ。
https://github.com/reinforce-lab/ObjC_Codes/tree/master/SceneKitDaeExample

https://developer.apple.com/library/mac/documentation/3DDrawing/Conceptual/SceneKit_PG/Introduction/Introduction.html

SceneKit Framework Reference
https://developer.apple.com/library/ios/documentation/SceneKit/Reference/SceneKit_Framework/

3Dデータの変換

https://github.com/ark-project/ark-project にオープンなデータがあったので、サンプルに使わせてもらった。
cheetah3dというMacのアプリで読み込んで、dae形式に書き出して、テクスチャの設定をする感じ。

モデルが最初真っ白だったから、まず左のペインのMマークのマテリアルで、diffuseにテクスチャの画像ファイルを指定。光の放出を意味するEmissionが白だと、やっぱり白いままなので、これを黒に変更、とかすると3Dモデル+テクスチャが表示される。

lapisの3Dモデルは、上腕部がXcodeでプレビュ表示されない。またビルド時にdae形式のアイルを変換するっぽくて、その時にエラーが出てた。なので、モデルファイルはプロジェクトからは削除してある。

ツールによって、ファイルフォーマットの相性とか、データの作り方や命名方法など、実際にやっていくと、いろいろあるんかもね。

SceneKitの使いどころ

3Dのモデルを読み込み、それを表示させたり、アニメーションをさせたり、物理シミュレーションで動かしたりするのが簡単にできるのが、SceneKit。昨年iOS7で導入された2Dテームを手軽に作れる SpriteKit の3D版といった感じ。

3Dゲームを作る環境には、Unity等がある。それに比べて何か利点があるかというと、多分ない。開発環境を見ても、3Dのモデルはプレビューはできるけど編集能力はないし、物理シミュレーションやアニメーションができるけど、現在のところはインタラクティブに確認する機能もないから、ビルドして振る舞いを見るしかない。プラットフォームもiOSかMacOS縛りになる。

Unityを使うほどではないとか、Unityのラインセスをとって学ぶのが大変だとか、Unityを使った人がいないときに、アプリにちょっと3Dを入れたい場合には便利だと思う。3Dのシーンを見せるのに、レンダリングした動画を入れちゃうと、見るだけになるけど、例えばカメラアングルをぐりぐり動かしたいとか、アプリ側から演出したいとか、そういうときに3Dモデル+アプリ的ななにか、をちょっと入れる場面も、使えると思う。

イメージ的には、アイカツ!ミュージックビデオメーカーみたいな。http://app.famitsu.com/20140806_420069/

あるいは、月齢表示とかのアプリなら、月の3Dモデルに太陽と地球の放射光があたっているさまを、表示するとか。

SceneKitのなかみ

プロジェクトのサンプルコードを見たら、そのままだけど。

表示は、UIViewを継承する SCNView 。これのsceneプロパティに、SCNScene のオブジェクトを入れる。ゲームだと、3D画面の上に操作用画面をいれるけど、それはSCNScene のoverlayなんとかに、SpriteKitの画面を入れられるので、それを使うといいっぽい。

SCNScene は、3Dモデルやアニメーションといったデータを保持するクラス。内部のデータ構造は、SCNNode をノードにする木構造。ノードを作っては、そこにカメラとかオブジェクトとかを張り付けていく。木構造の根は、SCNScene の rootNode プロパティ。

3Dモデルのテクスチャには、リソースの画像ファイルや、文字列やら、CALayerやSpriteKitの画面が貼り付けられる。だから、カメラのプレビュ画面がCALayerから派生しているけど、そういうカメラ動画を貼り付けるとか、そんなのも簡単にできる。

OpenGLのレンダラを生で叩くとか、低レベルなところもありっぽい。OpenGLで別で自分で書いたのと融合とか、面白い事が出来る人には、使いこなせるんあろうと思う。

面白いのは、アニメーションの指定がCoreAnimation。ノードに貼り付けた3Dオブジェクトやライトやカメラの、位置や速度や質量や加速度やらをCoreAnimationでアニメできる。また、アニメのデータは dae 形式のファイルに入れたアニメのデータをCoreAnimationとして読みだすことができるので、別にコードで書かなくてもいい。

2次元のUIのアニメだと思っていたCoreAnimationのスキルが、3Dなところでもそのまま使えるのは、汎用的で面白い。

あとはパッと見たところで:

SCNProgram

OpenGL Shading Language (GLSL)で記述したシーエだープログラムを使ってカスタムなレンダリングを実行する。
バーテックスシェーダー、フラグメントシェーダー

https://developer.apple.com/library/ios/documentation/SceneKit/Reference/SCNProgram_Class/index.html#//apple_ref/occ/cl/SCNProgram

SCRenderer

https://developer.apple.com/library/ios/documentation/SceneKit/Reference/SCNRenderer_Class/index.html#//apple_ref/occ/cl/SCNRenderer

すでにレンダラのコンテキストが指定されているアプリに、別のコンテキストを指定できる。EAGLContext object 。

SCNView。カメラグリグリ動かせる、フレームレート(最大60、デフォルト60)、スナップショット。

https://developer.apple.com/library/ios/documentation/SceneKit/Reference/SCNView_Class/

SCNScene。Vihicleのサンプル、オーバーレイが継承している。

SKSpriteNode。2次元の画像。

SpriteKit(2次元ゲームを作るやる)のシーンをオーバレイ。速度メータとか。

1
2
SKScene *scene = self.overlaySKScene
//self はSCNView

SCAAnimationEvent。足音とか、アニメに同期した音

MacとiOSで同じ名前空間

SceneKitとSpriteKitは、MacとiOSで同じ3Dなものを同時開発するのに、便利だと思う。iOSとMacで、名前空間が同じでAPIも同じように振る舞うから、画面サイズが違うだけのなにか、として開発できる。

色を扱うとき、MacだとNSColor、iOSだとUIColorだけど、こういう些細な差分は SpriteKit の SKColor を使えば吸収できるようになっている。SKColor は ifdef で、NSColor と UIColor を切り替えているだけのものだけど、標準のSDKで名前の些細な違いを吸収する仕組みが入っているのが、いい感じ。

色以外にも、いろんな違いがあるんだろうけど、そこまで詳しくないからしらない。

PlayGroundで使えるの?

PlayGroundは、Swiftで簡単なコードを作り、その場で実行して結果を確認できるXcode6の新機能。3Dモデルの読み込み結果及び簡単な動作確認やパラメータの調整に使えると便利だろうと思ったけど、2014年10月3日に、Maverickでの、Xcode6.0.1およびXcode6.1beta(2014年9月30日時点)の2つの環境では無理っぽい。

何が無理っぽかったかというと:
2つの環境で、 MyPlayground.playground を実行してみる。これはiOSをターゲットにしたPlayGroundでの、SceneKitのサンプルコード。

アシスタントエディタを表示(View->Assistant Editor->Show Assistant EditorをON)にすると、実行画面が確認できるけど、

2014-10-03 12:37:51.185 MyPlayground[11251:1205362] Error sending deferral props: 0x10000003

こんなエラーが出る。iOS dev forumをみても、同じようなエラーが報告されているけど、対処はわからない。

iOSターゲットがだめなら、Macターゲットならどうだと思って、そんなPlaygroundをつくろうとすると、Xcode6.0.1はMacのPlaygroundにまだ対応していない。仕方ないので、Xcode6.1beta を入れてMacターゲットで実行しても、エラーはでないけど、なんか表示画面が真っ黒のままで表示されない。

よくわかんない。ツールの問題ということにしておきたい。そのうち動くんじゃないかしらと思う。

リソースの管理

3Dのテクスチャやモデルを管理するなら、アセットにしておくと便利。フォルダを適当に作って、そのフォルダ名に”.scnassets”という拡張子っぽい名前をつけて、Xcodeに放り込めば、アセットとして扱ってくれる。

リソースファイルを追加したいときは、そのフォルダにファイルを放り込めば、自動でXcodeに反映される。

モデルとアニメのファイルはフォルダ構成で区別してやればいい。
例えばサンプルプロジェクトは art.scnassets/characters/explorer/run みたいにして、冒険者のキャラクタの走る場面のアニメーションファイルを入れている。

3Dモデルデータ

Xcode6は、Colladaファイル(.dae)という形式で3Dモデルを読み込める。”Import COLLADA 3D objects and build scenes composed by cameras, lights, and meshes. “ だそうだ。

Colladaファイルは、非営利技術コンソーシアムのクロノス・グループが管理していて、”COLLAborative Design Activity” の略。対話型3Dコンピュータ・グラフィックス・アプリケーション間の、交換用のファイル・フォーマットで、その中身はXMLファイル。バージョン? 1.4で物理学(Physics)、摩擦係数とかが追加されているらしい。カメラとかアニメーションデータとかも1つのファイルで扱えるので便利。

ミクミクダンスとかのファイルをdaeに変換して読み込むフローがつくれると、iOSアプリでお手軽ミクさんフローが作れていいなとおもったけど、MMDの形式をdaeに変換する方法がわからないから、断念。

daeファイルを動的に読み込む方法

ゲームとかだと、データファイルを後からダウンロードさせたいときがある。そのとき、daeファイルが読み込めないとエラーになることがある。

Mac OSだとdaeファイル自体を読み込めるが、iOSのSceneKitは、前処理されたdaeファイルしか読み込めない。http://www.the-nerd.be/2014/11/07/dynamically-load-collada-files-in-scenekit-at-runtime/ ここに詳しく書いてあるように、xscassetsの前処理を自分でコマンド実行して、その結果ファイルを使わないといけない。

/Applications/Xcode.app/Contents/Developer/usr/bin/copySceneKitAssets product-1.scnassets/ -o product-1-optimized.scnassets

ここ、結構引っかかるので、めも。

iOS8の高度計(気圧計)

iOS8の高度計(気圧計)

iPhone6 Plus および iPhone6には、気圧計が入っています。

今どき気圧計は高精度で、気圧の値の変化から、1メートル程度の高さの変化が十分にわかります。これがあると、例えば、ユーザが今ビルの何階にいるかがわかるわけです。

サンプルコードはこんな感じ。

1秒に1回の頻度で、気圧値が更新されて通知されてきます。相対高度(relativeAltitude)は、前回の通知から今回の通知までの高度の変化分を通知しています。今の実装は、おそらく、単純に気圧値の差分に定数をかけるとか、そんな感じなのかもしれません。

更新頻度を指定する方法は、今のところないみたい。

ハードウェから見ると、iPhone6の分解 http://www.techinsights.com/teardown.com/apple-iphone-6/ から、センサは Bosch Sensortec BMP280 Barometric Sensor

仕様を見ると、動作範囲(full accuracy) 300 ~ 1100 hPa、平均測定時間 5.5ミリ秒、分解能0.01 hPa (< 10cm)、温度 0.1度、絶対精度(950 ~ 1050 hPa) +- 1hPa、相対精度 +ー0.12 hPa (高さ+ー1m相当)。 (1hPa(ヘクトパスカル) は 100パスカル。)

センサの仕様から、今の振る舞いは、ほぼセンサの値をそのまま利用する単純な実装をしているのかな、と思いました。

Githubのサンプルアプリ。
https://github.com/reinforce-lab/ObjC_Codes/tree/master/barometer

ここの気圧と高度の計算式で、標高ゼロメートル、温度27度(絶対温度で300K)のときに、1mあたりの気圧の変化は、11パスカル。

http://keisan.casio.jp/has10/SpecExec.cgi?path=05000000.%95%A8%97%9D%8C%F6%8E%AE%8FW%2F02100100.%92n%8Aw%2F12000200.%95W%8D%82%82%A9%82%E7%8BC%88%B3%82%F0%8Cv%8EZ%2Fdefault.xml

アプリの値の変化を見ていると、たしかにそれっぽい感じで、とれている。

ソースコード

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
@interface ViewController () {
CMAltimeter *_altimater;
bool _isFirstSample;
double _currentValue;
double _averageValue;
double _altitudValue;
}

@property (weak, nonatomic) IBOutlet UILabel *currentValueTextLabel;
@property (weak, nonatomic) IBOutlet UILabel *averageValueTextLabel;
@property (weak, nonatomic) IBOutlet UILabel *variationValueTextLabel;
@property (weak, nonatomic) IBOutlet UILabel *warningTextLabel;
@property (weak, nonatomic) IBOutlet UILabel *altitudeValueTextLabel;

@end


@implementation ViewController

- (void)viewDidLoad {
[super viewDidLoad];

// Do any additional setup after loading the view, typically from a nib.
_isFirstSample = YES;

self.warningTextLabel.hidden = [CMAltimeter isRelativeAltitudeAvailable];
if([CMAltimeter isRelativeAltitudeAvailable]) {
_altimater = [[CMAltimeter alloc] init];
[_altimater startRelativeAltitudeUpdatesToQueue:[NSOperationQueue mainQueue] withHandler:^(CMAltitudeData *data, NSError *error) {
[self altitudeDataHandlr:data error:error];
}];
}
}

-(void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];

[_altimater stopRelativeAltitudeUpdates];
}

- (void)didReceiveMemoryWarning {
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
}

-(void)altitudeDataHandlr:(CMAltitudeData *)data error:(NSError *)error {
if(error != nil) return;

double altitude = [[data relativeAltitude] doubleValue];
double pressure = [[data pressure] doubleValue];

_currentValue = pressure;
_altitudValue = altitude;

if(_isFirstSample) {
_averageValue = pressure;
} else {
_averageValue = 0.1 * _currentValue + (1 - 0.1) * _averageValue;
}
_isFirstSample = NO;

self.currentValueTextLabel.text = [NSString stringWithFormat:@"%1.5e", _currentValue];
self.averageValueTextLabel.text = [NSString stringWithFormat:@"%1.5e", _averageValue];
self.altitudeValueTextLabel.text = [NSString stringWithFormat:@"%1.3e", _altitudValue];

}

iPhone6ぶっちゃけ雑談

iPhone 6買ったので雑感を書いてみる。

ハードウェア

箱をあけて手にとってまず思ったのは、カメラ周りの作りが、あまりにも雑だと思った。レンズは本体から飛び出ているし、レンズ周りの金属パーツはやたら余裕がなくて樹脂部品と近く、あまり美しいものに見えない。

iPhone6のスペースグレーを買ったのだけど、樹脂部品の色も何とも言えない灰色で、全体から見ても美しい色には見えない。確かにハードウェアの性能高いのであろう。だがこれに7万の金を出すようなものに見えなかった。

実際に手に持ってみるとどうだろう。液晶のガラスは微妙にカーブしていて、持ち心地が良い。だけどテキストを打とうとすると、キーボードが下のほうに出てきて、片手持ちでは指が届かない。

テキストタイプ

それでも無理に指を届かせてタイプするのだけれど、本体の重心が真ん中にあるのに本体の下を持つものだから、重心が手のひらから外に出てしまう。だからうっかりすると本体落としそうになる。とても不安定で使っていられない。

仕方がないから左手で本体を持って、右手でキーボードタイプするのだけれど、今まで片手でできていたことが片手できなくなって、とても不満に思う。

横方向に持って使えばいいのだろうかと思って、そのように使ってみるのだけれども、メモ帳などのアプリは回転に対応していても、ホーム画面が回転に対応していないから、なんとも使い勝手のバランスが悪い。

だからホームに戻るとアプリのアイコンが変な具合に並んでいるようにしか見えなくて、やっぱり使いづらい。

アプリの画面設計

改めて全体を考えてみると、もともと手のひらに収まる小さい画面で便利に使えるように設計された、iOSのUI、それを無理やり5インチに引き延ばしているのだからそれが不自然ないわにならないわけがない。

そうやって全店がそうやって画面を見てみると、キーボードわかめサイズが大きくなったのに比例してそのまま何も考えずに大きくなっていて、指のサイズに日間に合わなくて使いづらいし、ナビゲーションバーは画面の上に表示されるから、指を大きく伸ばさないと達することすらできない。

新規にインストールしたiOS8のメールアプリにGmailアドレスを登録したら、メールが来ないし、メールは送信できないし、設定アプリは突然終了するしと、iOS自体の完成度にも疑問を感じる。iPhone6についてきたGarageBandの楽器アプリなんて、起動したら直ちに落ちるし。何この質の悪さ、と思っちゃう。

今までのiPhone体験は、ユーザインタフェースと本体ハードが統合してデザインされていて、とても自然な使い心地で毎日使うことができた。このiPhone 6はその自然な体験を全て台無しにしてしまった、そう思った。

iPhone6plusがなければiPhone6は売れなかったのでは

iPhone6のほうが6plusより数量が売れているそうです。実際に手にとって、6か6pかと言われたら、それはそうだろうと納得です。

では、もしも6plusを発表していなかったら?

きっと、iPhone5sに比べて片手で操作できない、いままでのiOS体験を台無しにするこんな機種を誰が買うのか、と散々な評価を与えられたと思う。裏面の雑な仕事は、その着火剤と燃料に十分成り得た。でも、より大きな6plusがあって、それとの比較で、6か…となるこの流れ、Appleはユーザ体験の設計が絶妙だと思う。

でも買うならiPhone

でも、買うならiPhone6、おすすめ。

キャリア買い上げ価格を見てもわかるように、iPhoneが顧客釣り上げツールに一本化された象徴デバイスとなったことで、カバーを付けて利用して2年後外観が新品同様だったら、1/2金額で下取り。これはAndroidであり得ない、やすさの源。

2GBのパケットプラン(今はキャンペーンで1年間ほど+1GBの実質3GB)+音声定額なら、3キャリアどこを選んでも月額6500円。その月額からの割引の合計で、iPhone6 16GBの実質価格が0円になる。2年後にそれが3万円程度で下取りしてもらえるなら、2年間の端末利用代金は、キャリアの月額に含まれていて、2年間新品同様に使っていたら3万円のキャッシュバックが得られる形態と見える。

この料金プランは、とても合理的。MVNOでiij みおふぉんを利用して、(いまは4GBに増量されているけど)2300円ほどの月額プランで運用すれば、2年間の本体込の合計利用額は、3キャリアの合計金額の-3.5万円ほど。だから本体が2年後に3万円程度で下取りしてもらえるっていうことは、接続やテザリングに不安のない通信ブランドを、実質MVNO料金で使えるってこと。

お金の流れをみて、正しく土管をやってるな、そう思う。

auは、国内ではSIMロックだけど、海外SIMを挿したら使えちゃう?、これ海外SIMに対してはSIMロックフリーなの?みたいなのをみたり、ソフトバンクにいたっては、アメリカ放題とかいう、なんかもう訳の分からないサービスまで登場して、国内ではお互いSIMロックで戦うけど、それ武器にしたら、海外に行くユーザには総スカンだよね、みたいなところも手当してるっぽい感じが、面白い。土管やってるなって思う。(ただしドコモは除く)

つまり、月額6500円(2GBのパケット+音声定額+端末利用権 込)で、2年間綺麗に使ったら3万円のキャッシュバック。実質月額、ぜんぶこみこみ5250円。2014年7月の二人以上世帯の通信費(固定を含む)平均支出が年額1.5万円だから、その金額の範囲に綺麗に収まる。古い本体を保持しないといけない開発者の方々は、儲けの道具、経費で買えるのだから、そのところは養分になってください。

iPhoneは、実質、実際安い。

だけど、それはブランド力あってのこと。

売上の絶対額って、超重要だから、3.5万円で下取り前提なら7万円という他社+50%価格が納得できるって仕組み、とても大切。それを納得させる理由に、今まではブランドが使えたけど、いまでは”安物ではないけど、実際安い”やんな。この背面デザインでその仕組、来年も続けられるのかしら?

それともケースをつけて利用するから、問題がないのかしら。電車で使ってても、もはやiPhoneなのかAndroidなのか、わからないし、わかる必要もない時代なのかもしれない。

こうしてみると、ハードウェアが正しくゴミになっている

こうしてみていると、ハードウェアは、正しくゴミになっている。普通なら、型落ちで新品の機種を買ってキャリアは別途通信プラン契約で使うのが最安の利用方法になろう。だけどiPhoneの場合は、常に最新機種を持つことで、2年後の高い下取り価格と月々割による実質本体ゼロ円で、日本では最安のスマフォになっている。

iPhoneのシェアが高いのは、単に最安だから。その最安を支えているのは、キャリアのユーザ獲得合戦があって、高い下取り価格と月々割による実質ゼロ円が維持されているから。そのユーザ獲得合戦にiPhoneが使われているのは、毎年1機種を決算セールの9月に出してきて、売りやすいから。

だから、型落ちを買う必要はない。何も考えず、常に最新機種が出れば脊髄反射で購入して、2年後に下取りにだせばいい。それが、最もお得。いままでのiPhoneと同じよに運用されているなら、ひどいOSのバグで悲惨な目にあうことは、少ないだろうし、例えばバグに遭遇しても世の中の大部分の人が、同じバグに遭遇しているのだから、”いやぁiPhoneのバグで困っちゃいまして”って、逆に話題にできる。これがAndroidだったら、馬鹿か?バグのない別機種買ってこいよ、の一言で切り捨てられる。

いろんな要素が、うまく噛み合っている。うまい。

新しいアプリの体験

iOS8のヘルスアプリという新しいアプリの見せ方も不自然だ。Bluetoothのエナジーの心拍センサーを身に付けているがヘルスアプリ自体がデータを吸い上げることがない。だから一般ユーザーにはこれがどう使うものか伝わることはないだろう。新しい体験を伝えずにアプリだけ置いて不自然なやり方だと思った。

なぜこんなiPhone 6を発売しただろう、今までのiPhone体験が全て台無しになったような気がして理解すら覚えた。

音声入力からみると?

簡単に体験できるから、一度試してほしい。

設定アプリから、一般 - Siri とたどり”Hey Siri”を許可を、ONにする。そしてiPhoneを電源に接続して、ホーム画面も何も表示されていないところで、へい、しり、と話しかけてみる。そうするとSiriが起動して、音声コマンドを受け付けてくれる。

仕事に便利よ

25分仕事して5分休むを繰り返すポモドーロっていうテクニックがあるけど、”へい、しり。25分後に知らせて”で25分タイマーが起動するから、そういう使い方に、むちゃくちゃ便利ですよ。

音声テキスト入力?

Twitterのアプリを起動して、音声入力でツイートしてみるとその考えが、違うものになった。

iPhoneを左手に持って音声でテキスト入力する。iPhoneは力は音声がリアルタイムに認識されて入力されていく、その精度が非常に高い。だから指でいちいちテキスト入力しなくても普通に使える。もうテキストタイプするその使い方自体が時代遅れなのかもしれない。

だからアップルが時計を発売したらそれには必ず音声入力と出力を機能として追加しているだろうから、メールメール11位は声だけで終わってしまうじゃないかな。

今までのiPhone 5sそれとiOS 7だと入力がリアルタイムではなかっただからいちど話してそれが認識される結果をまとめて食べていけない。だから正しく入力されたのかとても不安になるしつまり使えない。

iOS 8ではHomeKitと言う家電操作のAPIが搭載された。あれはまさに音声入力で操作するものだから、常時Siriが起動していて、声だけで操作するという世界それが次のiOSの目指して世界なのかもしれない。

でもこのSiriの音声認識の精度が非常に高い強い。特にリアルタイム性がヤミツキなるほど高い。本体自体音声認識をやっているんだろう、辞書自体も本体中に持っていてサーバーへのアクセス自体をあまりつかわなくなって、できるのかもしれない。

だから音声入力端末だと思ってしまえば左手で端末を固定してニュークス分だけだからものすごく快適になる。

だから結論として、いままでのiPhone体験をiPhone6で得ようと思うと、ものすごいフラストレーションを感じる。これじゃない。

でも、音声入力を体験すると、全く違う新しいものがそこにある気がする。

もちろん街中で音声入力を使うのは、今は心理的な抵抗感があるだろう。花粉症のマスクが街中で見られるようになった程度に、変化しうるのかもしれない。

不特定多数がいたらダメじゃないかと思うかもしれないが、声質から個人を特定するのは、難しい技術じゃない。

今の時代になってみれば、できない理由は一つ一つ解決可能で、ただそういう習慣がないから、そうしていないだけ、に思える。

新しい時代にあわせて設計されたから、このiPhone6は、従来のiPhone体験からしたらこんなにひどいものなんだとしたら、それは面白そうだなと思う。

この文は、音声入力で書いてます

さすがに無修正そのままというわけではありませんが。
メモ帳で音声入力で書いたものを、誤字をちょっと修正、キーボードで追加して書いてます

あともう一つ、なんでシームレスさが話題にならないのか

iOS8の解説で、iPhoneの電話がiPadに伝わるとかのYosemiteでも体験するだろうシームレスさ、それはBLEも利用して初めて実現できるものだけど、が全然取り上げられてないの、iPhone登場時のiTunesを取り上げないみたいなもんだと思う

iOSのシームレス、というか、同じ持ち主のものなら、同じだよねっていうこの空気感、クラウドっていうより雰囲気感、見えないものを受け取る第6感な感じ、iOS8の真骨頂の1つだろうに

さいごに:ごめんねAppleStore

iPhone6を20秒触って、あまりにも頭にきたから、SIMロックフリーのiPhone5sをAppleStoreでポチったけれど、あまりの怒りに最大容量を選択しても32GBしかないことにすら気付かずに注文してしまって、AppleStoreさん、ごめんなさい。

iPhone6は、片手で使おうとしたら、こんなものいらないけど、机において音声入力専用にする別の世界のデバイスだと思えば、ありだと思ったので、新しい時代には新しい器をと、これを使おうと思います。

もう注文キャンセルできなくて返品するしか対処方法はないのですが、AppleStoreさん、ごめんなさい。

おまけ

いままでのiOSがとても楽しかったので、こんなあれこれを考えたり書いてみたりしているけど、実際のところは、世界で大画面なファブレットもラインナップに必要だよねで、たんに6/5/4インチの製品ラインナップを作ったら、4インチのはプロセッサの性能や画面など、技術的な要素で+20%アップみたいなことが言えなくて、6と5インチラインの製品だしました、だけかもしれないけどね。

毎年、1つのロードマップで、数値を重ねて、より素晴らしいものが出るという、これまでの体験は、この横並び並列製品群化で、無効になっているから、来年からはiPhone Air/ iPhone mini / iPhone みたいな名前で、iPad mini みたいくRETINAとか、なにか特徴を表す単語を1つつける名称方式に、変えてきたりして。

iPhone6plus-sとか、どーかんがえても、ありえんでしょ。

中国で売るためになら、なんでもやりそうだし。

参考資料: iPhone6予約時に検討した2年間利用総額の計算メモ

auをiPhone5で2年間利用している場合の計算メモ:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
iPhone6 64GB, 月2~3GBのパケット利用 (めんどいので消費税は8%)
音声通話あり、SMSあり(2段階認証のために)

au:機種変更
本体: 85320円 (消費税 6826円)
月々割: 2410円x24ヶ月
月額: 基本2700円+データ定額2 3500円+LTE NET 300円 = 6500円 (消費税 520円)
(別に1年間の+1GBの特典あり)
2年間利用総額:
本体 83320+6826 +(6500 + 520)x24 -2410x24 = 200,786円
もしも1.5万円割引クーポンがあれば:
200,786円 -15,000 = 185,786円

IIJのみおふぉん:
初期費用: 3240円(税込み)
月額:2GB/月 2397.6円(税込み)
au MNP転出手数料: 2000円(消費税 160円)
本体: 79800円 (消費税 6384円)
2年間利用総額:
本体 79800 + 6384 + 月額 2397.6 x 24 + 初期 3240 + MNP転出 2160 =149,126円

差額3.7万円くらい
テザリングと2年間の音声通話分で月1500円なら、同等くらい?

ドコモ:
本体 86832円 (6946円)
2GB: 月額 2700円+ISP 300円 +3500円 = 6500円 (消費税 520円)
月々サポート 3078円
2年間利用 本体 86832 +6946 +(6500 + 520)x24 - 3078 x 24 = 188,386円
MNPの手数料:2100+3150 = 5250円

2GBでは繰り越しがないのよね。

Recent trend of iBeacon in Japan

iBeacon is one and the only one powerful tool for sending a event trigger to an iPhone be meters away from a beacon. I introduce recent trend of iBeacon in Japan, because I have not read an article like this in English, yet.

I talk about beacon manufacturing companies, services that uses iBeacon, and application delopers (iOS and server applications) communities in Japan.

iBeacon manufactureres

Aplix Corporation http://www.aplix.co.jp, translated by Google transate, has been proving beacons since October 2013. Their beacons, product page, translated page, are resonable prices and very unique.

Power efficient beacon

The “MyBeacon ™ Pro MB004” is a low cost beacon that starter Pack (10 units included) 10,000 yen, 500 yen / unit 20,000 Lot.

Usual beacon has only one bluetooth single-mode module. It is required to receive RF-signals (scanning requests and connection requests) after transmitting advertising packets (beacon packets). This results in large power consumption.

Their beacon has two modules as shown in the picture. One module works in non-connectable mode that it never listens for scanning requests and connection requests after sending beacon packets. Therefore power consumption is minimum.

The beacon can be configured over BLE through the other module which is connectable and its advertising interval is long to minimize power consumption.

Touch solutions

This beacon provies touch solutions similar to NFC. Touch interactions is very popular in Japan, for example Osaifu-keitai http://en.wikipedia.org/wiki/Osaifu-Keitai. However using usual beacon that sends radio wave, trasmission distance is about one meter even when transmission power is very small. Their touch solution beacon probably uses leaky cable as an antena.

Beacon module to combinate with sensors

An beacon connected to sensors is the key device to connect the everythings of the world to the internet. This module is for the people who want to make products and services of the original by connecting the sensors and switches.

iBeacon contents management systems

ACCESS CO., LTD. http://www.access-company.com provies beacons and contents manage systems http://jp.access-company.com/news_event/archives/2014/20140130/, translated by Google.

Services

The first service using iBeacon appears in a restaurant nearby Shinagawa station on March 2014 https://translate.google.co.jp/translate?hl=ja&sl=ja&tl=en&u=http%3A%2F%2Fiphone.ascii.jp%2F2014%2F03%2F26%2F32432432%2F.

Their service uses iBeacon to simply detect customers are in the restaurant. Customers can get some coupons and place an order using the iOS application. As we know, iBeacon is not suitable technology for precise indoor position detection. They uses QR 2-d barcodes to identify customers table number.

An indoor navigation using beacons in Shibuya station https://translate.google.co.jp/translate?hl=ja&sl=ja&tl=en&u=http%3A%2F%2Fk-tai.impress.co.jp%2Fdocs%2Fnews%2F20140325_641086.html .

When they started the trial on March, they said they used beacons probaly because they had not be licenced MFi(iBeacon). But they probably use iBeacon now.

A more sophisticated iBeacon smart order service has emerged on June 26 https://translate.google.co.jp/translate?hl=ja&sl=ja&tl=en&u=http%3A%2F%2Fweekly.ascii.jp%2Felem%2F000%2F000%2F232%2F232144%2F .

iBeacon developers

Smart cushion using iBeacon https://translate.google.co.jp/translate?hl=ja&sl=ja&tl=en&u=http%3A%2F%2Fjapanese.engadget.com%2F2014%2F04%2F27%2Fibeacon-ios%2F&sandbox=1 .

An iBeacon handbook written in Japanese.

iOS8でのiBeacon活用

WWDC2014のプレゼンテーションから、iOS8での/iOS8からのiBeaconの活用方法をまとめてみます。

すでに iOS8で正体を現したAppleの屋内位置測位。iBeaconは第一形態だった。Maps Connectとは? #WWDC14 で詳細に記述されていますが、重複しつつも改めてまとめてみます。

資料

開発者向け情報:

iBeaconの開発者および敷設と管理者向けの一般情報:

iBeaconの設置および建物の所有者向け:

  • https://mapsconnect.apple.com 屋内地図の登録申請が始まっています。Apple IDでログインできます。所有する建物や図面フォーマットなど屋内マップに必要な情報が項目にあります。

建物の所有者向けの情報、iOS8に向けた準備

建物所有者がiOS8に向けてできることは:

  1. WiFiやiBeaconを含めた屋内地図の登録申し込みを始める,
  2. iBeaconの設置計画をたてる,
  3. 屋内ナビゲーションアプリをリリースするならばアプリケーション開発を始める,

です。

WWDC2014では、iOS8の屋内測位についての明確な技術情報は提供されてはいません。プレゼンテーションでは、位置情報を提供するフレームワークが、CLFloorクラスという建物の階をアプリケーションに伝える機能が追加された、屋内ナビゲーションアプリを作成するときに緯度経度と地図画像の座標変換を楽にするヘルパー関数が提供される、発表があった程度です。

Appleの地図アプリへのデータ提供

https://mapsconnect.apple.com では屋内地図の登録申請が始まっています。このサイトには、開発者でなくとも一般的なApple IDでログインできます。所有する建物の住所および提出できる図面フォーマットや屋内測位に使えるWiFiやiBeaconを設置しているかなどの、屋内マップ作成に必要な情報が項目にあります。

これはAppleの地図アプリケーションに屋内マップ表示を取り込むためのものだと思われます。特に駅や空港などの公共機関は、地図データの登録のやりとりを早く開始すべきでしょう。

屋内地図を使う場面には、ユーザの現在位置表示が必要です。GPSが届かない屋内での位置推定は、カーナビゲーションと同じように加速度センサなどを活用した慣性航法を提供するかもしれません。ですがこの方法は誤差が積分されていきます。その補正にWiFiやiBeaconの屋内の電波状態を使うと思われます。

WiFiは通信環境を構築するために設置しますから、特に屋内ナビゲーションのために何かをすることはないでしょう。ただし、iBeaconはWiFiよりも電波が届く範囲を小さく設定するなど自由度が高いですから、ユーザが必ず通過しかつ移動範囲が限定される入り口などにより集中して設置することで、初期位置の補正に有効に使えます。

建物へのiBeaconのビーコン設置は、電池ではメンテナンスが手間でしょうから、電源配線が必要になるでしょう。またビーコンの設置そして動作していることをモニタリングする仕組みも必要になります。

屋内案内のアプリケーション開発

例えば百貨店などでは、屋内位置がわかるだけでは不十分で目的のお店の位置表示およびナビゲーションが必要になります。配置が頻繁に変更されるテナントの詳細情報までは、Appleへの屋内地図データ提供では対応しきれないでしょう。このような場合は、専用のナビゲーションアプリケーションの開発があります。

iOS8は、アプリ屋内案内のアプリケーション開発を手助けする屋内案内地図表示のヘルパ関数を提供しています。しかし、アプリケーションが開発できても、問題はユーザがそのアプリケーションをどうやってインストールしてくれるかです。

iOS8は位置に紐付いたアプリケーションのインストールに:

  • AppStoreのnear-me,
  • ロック画面のアプリまたはAppStoreアイコンの表示,

を提供します。

AppStoreのnear-meは、AppStoreアプリのタブ”近くで人気”のことです。その場所で人気のアプリケーションを表示するので、例えば先ほどの百貨店のアプリケーションは店舗の近くでアプリケーションが表示されます。アプリケーションと位置の対応付けを、アプリケーション提供者が設定できるかなどの仕組みは、不明です。

iOS8からは、ロック画面にその位置に関連するアプリケーションのアイコンまたはAppStoreのアイコンが表示されるそうです。これも、どのように関連付けされるのか、また設定ができるのかはわかりませんが、わざわざユーザがAppStoreを開く手間を省くことを提供すると思われます。

この新しい屋内位置案内は米国内で順次提供が開始されるそうです。近々には

  • California Academy of Sciences, San Francisco
  • Westfield San Francisco Centre, San Francisco
  • Mineta San Jose International Airport, San Jose

だそうです。

開発者向けの情報

iOS7で開発したアプリケーションはiOS8で動作するか

動作するはずです。

iBeaconに関係するCoreLocationのAPI自体は変更はありません。ただしiOS8では位置情報のユーザ認可(authorization)が変更されています。ストアのiOS7対応のアプリケーションをiOS8のデバイスにインストールした場合は、のちに述べるAlways authorization で実行されます。

iOS8でのiBeaconアプリ開発

iBeaconに関わるCoreLocationのAPIは、iOS7とiOS8で変更はありません。

ただし、iOS8では位置情報のユーザ認可(authorization)が変更されています。iOS7までの位置情報のユーザ認可は1つだけでしたが、これがiOS8では、アプリ実行時およびバックグラウンドで常に位置情報を取得できる Always authorization と、アプリが実行状態の間だけ位置情報を取得できるWhenInUse authorization の2つに分離されます。

位置情報の利用認可ダイアログに表示するテキストを指定する Info.plist のキーおよびauthorizationの要求のAPIはiOS8で廃止されます。iOS8では、Always authorization および WhenInUse authorization それぞれに対して、ダイアログに表示するテキストを指定する Info.plist のキー値およびCoreLocationのAPIが追加されています。

Always authorization と WhenInUse authorization

WhenInUse authorization は、Continuous Updatesを受け取れます。アプリケーションが表示されている間に、CLLocationの位置情報取得を実行できます。

Continuous Updatesは、Location , Background , Location Ranging の3つです。WhenInUse authorizationでも、バックグラウンド状態での位置更新情報が受け取れることに注意します。WhenInUse authorizationはアプリケーションがフォアグラウンドの間しか位置情報取得の開始/停止はできませんが、バックグラウンドでの位置情報の取得はできます。

Always authoriazationは、Continuous Updatesに加えて、Location Monitoringもできます。Location Monitoringは、Region monitoring、Significant location changesの2つです。

いずれのauthorizationでも、アプリケーションが最初に位置情報を要求した時に、ユーザに位置情報利用認可ダイアログを表示します。Always authoriazationのときのみ、数日後にこのダイアログが再度表示されます。プライバシーに配慮して再度確認するようです。

iBeaconを使うアプリケーションは、レンジング(ranging)および領域監視(region monitoring)を使うでしょう。もしもアプリケーションが表示されている間だけiBeaconを検出するならば、WhenInUse authoriazationでよいでしょう(未確認)。領域監視も使うならば Always authorizationが必要です。

iOS7向けに開発されたアプリケーションがiOS8なiOSデバイスにインストールされた場合は、Always authorization とみなされますから、領域監視をするアプリケーションでもそのまま動作するはずです。

その他WWDC2014ののセッションメモ

その他、What’s New in Core Location, Session 706 での要点メモです。

新しくはいった機能は3つ。

  • Location authorization
  • Visit monitoring
  • Indoor positioning

Location authorizationは上記で述べたので省略。

UILocalNotification が位置をトリガーにすることができます。

1
2
region-based triggering。
@property(nonatomic,retain) CLRegion *region;

MKMapViewに、現在のユーザ位置を表示するかの設定が入ります。

1
2
MKMapView
@property (nonatomic) BOOL showsUserLocation;

Web viewsに、To allow web content that uses HTML5 geolocation

また訪れた場所を24時間/7日モニタリングしつづけられるVisit monitoringが新しく加わります。ユーザがある場所に到着/出発したタイミングで、到着時間/出発時間また位置と位置精度が通知されます。

1
2
3
4
5
6
7
8
9
10
11
12
@interface CLLocationManager (CLVisitExtensions)
- (void)startMonitoringVisits;
- (void)stopMonitoringVisits;
@end

CLVisit
@interface CLVisit : NSObject <NSSecureCoding, NSCopying>
@property (nonatomic, readonly, copy) NSDate *arrivalDate;
@property (nonatomic, readonly, copy) NSDate *departureDate;
@property (nonatomic, readonly) CLLocationCoordinate2D coordinate;
@property (nonatomic, readonly) CLLocationAccuracy horizontalAccuracy;
@end

Taking Core Location Indoors,Session 708 の要点メモ。

Wi-Fi on, device unlockek すれば 建物の階がわかる。

ヘルパー関数は:

  • MKMapPointForCoordinate
  • MKMetersBetweenMapPoints
  • MKMetersPerMapPointAtLatitude
  • CGAffineTransformMakeScale
  • CGAffineTransformMakeRotation
  • CGPointApplyAffineTransform

雑感

Visit monitoringなんて、何に使うのでしょうね。

iOS8と雰囲気の世界

iOS8の発表を見ていると、雰囲気をキーワードにするとおもしろいと思ったので、メモしてみます。

2014年になって、O2O (Online 2 Offline)、ウエアラブル、そして身の回りのモノや現象がネットとリアルタイムで同期するIoT (Interne of Things)が話題になっています。スマートフォンの可能性がひと通り探索しつくされて、他社よりもよりユーザの目を奪う、ユーザの時間を獲得できる手段はなにかを求めているためだろうと思います。

雰囲気とは

辞書をひくと、雰囲気は、その場にかもし出されている気分やムード、または天体をとりまく大気のことを指します。ここでは、なーんとなくただよっているムードとでもしておきます。

雰囲気は、自分が感じ取るものと、自分が出す場合とがあります。雰囲気を感じ取ったら、それをそうだねと黙って感じ取るだけの場合と、なにかしらの反応を返す場合があります。

iBeaconは雰囲気そのもの

iOS7で新しいローケーション技術としてiBeaconが導入されました。これはiOSデバイスが常時Bluetooth Low Energy技術を利用したビーコンに反応する技術です。例えば、自社のアプリにビーコンの処理を入れておけばユーザが店舗に近づいたときに設置されたビーコンを検出して適切なタイミングで適切な通知を送れるため、O2Oの切り札として注目されています。

iBeaconは雰囲気そのものです。ビーコンが出す側、iOSデバイスが感じ取る側です。反応するのはビーコン検出を実行しているアプリケーションです。ビーコンが周囲に出している情報をiOSデバイスが嗅ぎ取ります。iOSデバイスは常時ビーコン検出をしていて、検出したビーコンが検出条件に一致すればそのアプリケーションに通知します。

アプリケーションがビーコンに反応して出せる反応は、iOS7では微妙です。iOS7はユーザが画面を見ることが前提だからです。たとえローカル通知でロック画面に情報表示ができても、iOSデバイスがポケットの中にあっては意味がありません。かといって音や振動で通知すれば、迷惑だと嫌われます。

iOS7は、ロック画面を表示した瞬間にビーコンを検出する、notifyOnDisplayというiBeacon独特のバックグラウンド検出モードがあります。これはiOSデバイス単体でかつユーザが画面を見る利用場面が前提のiOS7にあわせた、うまいモードです。

でも、これではちょっと不満です。

iWatchが使うだろうANCSは、雰囲気を伝えるもの?

実はiOS7にはApple Notification Center Service (ANCS)という機能が入っています。

これはiOSの通知情報をそのまま、Bluetooth Low Energyで、周辺デバイスに流す仕様です。雰囲気メガネがこれを使って実装されています。

iOS5から導入されたCoreBluetoothフレームワークで、iOSアプリケーションは任意のBluetooth Low Energyデバイスと直接通信ができるようになりました。このおかげでガジェットを販売するベンチャーがたくさん誕生してきたのです。

しかし、iOSの通知情報はiOSアプリケーションからは取得できません。それはiOSだけが知っている情報です。このANCSは周辺デバイスにその通知情報をたれながす仕様です。発売が噂されるiWatchのように、ウエアラブルと呼ばれるジャンルのデバイス、ユーザが直接身につけ続けるなにかのための仕様なのでしょう。

ANCSも雰囲気を醸し出す技術です。通知情報は、iCloudからくるものや、アプリケーション、あるいはiBeaconに反応したアプリケーションが出す通知があります。それらの通知情報はユーザが持っているiOSデバイスに一度集約されて、そこからANCSで周辺デバイスに通知されます。

クラウドや周辺環境を含めた雰囲気的な通知情報を、一度iOSデバイスが嗅ぎ取り集約して、ANCSデバイスに中継する流れです。

iBeaconの登場と同時にANCSなデバイスがあれば、おもしろかっただろうにと思います。実際にはiWatch的なデバイス自体がBLEを搭載しているわけですから、iBeaconの検出であればそのデバイス単体でできてしまうでしょうから、ANCSはいらないのかもしれませんが。

iOS8と雰囲気

HealthKitは、Bluetooth Low Energyなどの生体情報をiOS自体が取得して集積するサービスです。iWatch的なデバイスは、いまさら腕時計といわれちゃいますが、健康とかロギングしちゃいます、心拍のゆらぎで疲労度とかチェックできますとなると、身につけておく理由づけができるから、毎日身につける習慣付けになるんだろうなって思っています。

いまさら、うでどけい、とふつー思いますよね。メインはANCSの通知系サービスの習慣付けかもしれませんけど、電池をバカ食いしてあんまり実用でないとしても、最初の身につける習慣付けまでの撒き餌さとしては、ありなんだろうなと。

HomeKit。これはSiriの音声コマンドでいろいろ操作ができるようになるものなんですけど、iOS8でSiriが常時稼働になるんです。さすがに既存のiOSデバイスでは電池消費量がでっかすぎるでしょうけど、音声検出用の超低消費電力回路は発表されているので、次のiPhoneあたりはハードが対応しているのかもしれません。あるいは、家に常設する新しいタイプのデバイスを出してくるか。

こういう流れを見ていると、雰囲気というキーワードでみてきましたけど、ユーザがいちいち画面をみるって不自然でしょう? と思えてきます。実際街なかでスマフォ片手に歩いている人とかを見かけますけど、不自然です。車運転している人すらいて、危険すぎます。

もう意識しなくても、虚空に向かって話をすれば、ソーシャルメディアの投稿も、メールの送受信も出来る程度に雰囲気的な世界になるんだろうなって思います。

そのとき、ユーザの活動時間の争奪戦の勝者は、どこになっているんでしょう。アプリで差別化できるとは思えません。だって、画面を見ること自体が、不自然な世界なのですから。勝利要素として、iWatch的なハードウェアを持っていることだけは、確実だと思います。

最後にここまで書いといてなんなのですが

感触が雰囲気的なものに移行していくと思うので、ソーシャルメディアとかゲームとか、今の時点で見逃せない視点だと思って書きだしたんですけど、

まじめに書こうとすると、テンションあがらなくて、ものすごくつまんないことしか書けないです。