IndoorAtlasとは磁場を測定することで建物内での位置測位が可能なシステム&会社名。SDKは公開されていて無料の枠で使えたりするのだが、使う際にはまず最初に位置測位を実際に使う場所の磁場をマッピングする。その際のマッピングの注意点についての記事を簡単に訳す+僕なりの精度向上Tipsをまとめた。重要だと思うポイントのみをきちんと訳してマップの正確性を上げようとしたので、ただの操作説明やそこまで重要と思えなかった情報は訳していない。ご了承を。

推奨Android

Nexus 5, 5X, 6, 6P
OnePlus2
LG G4
Xiaomi Mi4

indooratlasのマッピングにおける重要なポイント

Waypointsの場所

かんたんに正確に分かる場所（柱やドア）に置く
10-20m以上離して置かず、壁から0.5-1m程度離して置く
3m幅の通路などの狭いエリアをマッピングするには2-3のパス（75cmずつの距離で空ける）でカバーするとよい

重要：異なるWaypointsで同じ場所をオーバーラップするパスを作ることで完璧なカバレッジが可能になる。例えば、同じパスを反対方向から計測するなど。ABCDのWaypointがあり、ABCDの順に回ったら、次はBDCAの順に回るなども良い。これをするとポジショニングとアナリティクスの向上に繋がる。

計測時の注意点

出来る限りまっすぐに自然に歩く。その時スマートフォンは水平にして前を向いた状態に。
スマートフォンは常に身体の近くに。腕の動きを影響させない。
曲がるときはスマートフォンも曲がるべき。
なにかにブロックされたらその場で止まってそれがなくなるを待つ。レコーディングを停止しない。
同じWaypointになんどでもチェックインできる
歩ける場所全てを1.5mのギャップがパス同士にないようにカバーする
１つのパスでのレコーディングは2.5分までにする

マッピング時

重要：マッピング中はかならずアプリケーションがアクティブである必要があります。アクティブでなくなるとデータが消えます。（ex.電話に出る）

スタート時のWaypointをタップし自分自身をそのWaypointの真ん中に来るようにします。ズームして完全に真ん中になるように調整しましょう。
計測開始時に自分が歩くと画面の中の自分の位置を示すドットも動くことがありますが、これが実際の動きと異なる場合でも気にせずにあるきましょう。

訳者的注意点

実際に試したところ、良くないパスになったなと思ったら躊躇なく破棄し、良いパスのみを保存すると良かった
- 初期のよく分からずにやっていたパスを全て破棄し、慣れたあとのパスのみでマップを作ると精度が一気に向上した
ごく近くのWaypoint（2m以内程度か）だとチェックイン不可能
- たまに出来るが無理やりチェックインしようとするよりはパスがオーバーラップするようにして、チェックインしない方がよい感じ
最初の地点に来たとき、ユーザに操作させたり、ビーコン等を使って位置を特定することでその後の動きの精度が上がった
広いところは四隅を四角く取得 + 真ん中で斜めにクロスさせる形で取得するとよい

2017-07-12

openFrameworksでやっておくとよいこと

openFrameworks

仕事するたびに毎回忘れてしまった！って思ったりするのでまとめておく。

設計編

全体の設計を考える
- アプリを分けてOSCで連携する
  - 規模が大きい & 期間が長い場合はAPIを先に定義し、各々がモックで開発するべき
- ofxStateMachineを使って各Stateごとの動作にする
- そもそもoFを使わない（UI系はネイティブなども検討する）
クラスの設計
- 基本はシンプルにオブジェクトの保有とポリモーフィズムで
- コールバックはofEventを使う
設計と資料（全て手書きで良い）
- クラスが10を超えるならクラス図を作る
- 複雑な処理はシーケンス図を書いて把握する
- 他のアプリやデバイスと連携が必要なときもシーケンス図で処理を把握する
- 状態遷移が多いものは、画面遷移図か状態遷移図を用意する
設計のためのデザインパターンを知っておく
- 非直感的な設計のデザインパターンは大変便利なときがある
- デザインパターンは一度覚えて忘れるといいと言うネットミームがあるが、割とそう思う
- 他のフレームワークに使われるパターンを踏襲すると良かったりする

プロジェクトの進め方編

文と図
- タスクはまず文にする
- 文で把握出来ないタスク（=1次元で把握できない）は図に起こす（=2次元化する）
いきなり実装しようとしない
- メソッド呼び出しだけで終わらないと思ったらシーケンス図を描く
  - コールバックは1回あるだけでも追いづらい（クロージャは別だと思う）
  - マルチスレッドなどの並行的な動作やShaderなどとの連携は慎重に扱う
- 普通の処理もまずはやりたい処理を日本語で書いてタスク化すると迷わない
大きめの検証は別アプリでやる
- ある機能を加えたいが、その機能の検証が必要になったら別アプリで確認しその後本番の方に反映する

Tips編

ofxGUIを使いこなす
- 全ての調整しうるパラメータはofxGUI経由で変更出来るようにする
  - ofParameterとofXmlSettingsを使ってファイルに保存、読込が出来るようにすると完璧
ハードとの連携
- ofxGUIを使い、ハードからの値を表示
- 上記をすることで、ソフト的にシミュレーションも可能になり開発スピードが上がる
git管理は必須
- oFは設定が壊れやすいのでgitで管理する
- どうやっても動かなくなったら、変更済みファイルを別に保存しrevertしよう
- ルートに置くreadme.mdにプロジェクトの説明（バージョン情報と利用するデバイスの型番など）を書いとくと将来に便利

Beyond Interaction[改訂第2版] -クリエイティブ・コーディングのためのopenFrameworks実践ガイド

作者: 田所淳,齋藤あきこ
出版社/メーカー: ビー・エヌ・エヌ新社
発売日: 2013/06/26
メディア: 単行本（ソフトカバー）
この商品を含むブログ (4件) を見る

2017-07-12

UnityのTextureで線が繋がるお絵描きをする

Unity

miso-engine.hatenablog.com
oFでお絵描きしたら、今度はUnityでもやってみる。先人たちが結構やっているので、まず参考リンクから。
Unityでテクスチャにお絵描きしよう - おもちゃラボ

点を打つのではなく線を引く

上記の実装だと点なので、oFでもやったように線にしよう。Unityではテクスチャに対する描画系のメソッドが一切ないからよりプリミティブな実装が必要になる。「ブレゼンハムのアルゴリズム」というものがあるので、それを利用した。
ブレゼンハムのアルゴリズム - Wikipedia

実際のコードはこちらのQiitaの記事が参考になったというかほぼ同じになったので掲載しない。Qiitaを参照して欲しい。
ＤＸライブラリとブレゼンハムのアルゴリズムを使って線分を描画 - Qiita

線にする条件マジックナンバー0.12

oFのときは線にするかどうかをマウスイベントで判断していたが、マウスイベントを渡す実装がちょっと手間だったので描画メソッド呼び出しの間隔で判断するようにした。つまり前回の描画メソッドの呼び出しからの秒数によって前回打った点と今回の点との間で、線を描くかどうかを決めるという仕組みだ。これは非常にうまくいった。今回のプロジェクトでは0.12秒以内だといい感じだった。最初は0.5秒にしていたが、そうすると例えばひらがなを書くと指を離したはずなのに繋がってしまっていた。というわけでマジックナンバー0.12、オススメです。マウスイベントによって分岐させるよりもシンプルに書けるし。