GPSアプリのデバッグでコンパスが使えなくなる ― 2016年02月02日 17:52
Windows10 mobile搭載機であるKATANA01でGPSやコンパス、傾斜計を使ったUWPアプリを作り始める。
センサーからデータを読み出して表示するところまでは、簡単。緯度経度は、Google Mapで見ると、ピンポイントで位置がわかってしまう精度なのが恐ろしい。コンパスは、手元のSUUNTOと比べると10度ほど差があるのが気になる。磁北との差か。
さて、VS2015でデバッグ実行して、■ボタンで終了後、再度、デバッグ実行をしようとすると、コンパスと傾斜計が使えなくなる。初回では正しい値を返していたGetDefault()がnullを返すようになる。MSのサンプルアプリでも同じ。GPS機能を実装する前は問題なかった。KATANA01を再起動すると回復する。
とりあえずの対処としては、VSのデバッガから、プログラム停止を指示しない。KATANA01でアプリを終了させてから、VS2015のデバッガを終了させる。このあたりは、ファームの問題かなあ。
P.S.
それでも、発生することがある。この場合、デバッグ実行にはならないが、配置のみ実施し、プログラムの起動をVSから行わないことで回避できる。DELLのタブレットの方は問題ないのだけど。
Visual Studio Team Services (VS Online) ダウン中 ― 2016年02月04日 20:36
夕方になって、Visual Studio Team Services (以前の名称だとVisual Studio Online)につながらなくなる。GitHubのトラブルをつい最近聞いたばかりのこの時期に。
Webの作業管理画面がエラー番号500を表示。
Visual Studio Team ServicesのBlogに経過報告が出る。このチームのTwitterにも速報が。どうも、認証まわりにトラブルがあるらしい。
MSのクラウドサービスは、なにかと認証まわりでトラブルが多い。Office365でもずいぶん苦労した。ずいぶん前から、手を打っているとは聞いていたのだけれど。
P.S.
5時間ほどで回復したようです。説明によると、SQLサーバのストアドプロシージャが長時間運用の中でメモリを食いつぶしていた、とのこと。
太陽3個分の重力波 ― 2016年02月13日 12:21
LIGOからの発表は大きなニュースになった。装置ができても、予想された事象の発生頻度から、はっきりした成果が出るには数年かかってもおかしくない、と思っていたので、このタイミングでの発表は驚き。巨大な物理現象の頻度は、思ったよりも多いのかも。
※LIGOの発表
いろいろなニュースサイトを見たが、表面的な解説に終始するニュースサイトが多い中、一番しっかりした解説は、the guardian。解説図もわかりやすい。
※the guardianの記事
ニュースサイトで触れているところは見なかったが、LIGOの発表を読むと、太陽29個分の質量を持つブラックホールと、36個分のブラックホールが合体し、うち、3個分の質量に相当するエネルギーが重力波として放たれた、とある。合体後のブラックホールが太陽65個分とする記事もあるが、62個分くらいといったところか。
2つの星が一つになるには、お互いの持つ位置エネルギーを失う必要がある。それが、この場合、太陽3個分。ブラックホールなので、光などを放つわけにもいかず、重力波になるのか。一瞬にして、太陽3個分の質量が消え、空間を歪める。
そうして発生した波が、13億年かかって届く。減衰しないのか。回折や干渉はするのか。波の重なりで、空間の歪みは大きくなるのか。粒子としての性質はどのようなものか。興味は尽きない。
プライバシーポリシーとサポート情報 - お散歩コンパス ― 2016年02月13日 19:24
本アプリについて (About this app)
2016年8月更新
本アプリは、散歩などに持ち歩くコンパスと傾斜計の機能を提供します。インターネットが利用できる環境では、今いる位置を中心に国土地理院地図を開くことができます。また、適宜、現在位置を記録することで、簡易ですが、経路を表示できます。
それぞれの機能の利用可否は、機器に搭載されるセンサの有無に依存します。すべての機能を利用するには、電子コンパス、傾斜計、GPS、および、インターネット接続が必要です。
現在位置の表示には、位置情報を使用します。使用を許可するには、Windowsの「設定」→「プライバシー」→「位置情報」の設定が必要です。
プライバシーポリシー (Privacy statement)
対象アプリ:お散歩コンパス
本アプリの製作者である The Fourteenth Lab (第十四工房) は、本アプリによって、お客様の個人情報およびプライバシーに関する情報を収集しません。
サポート情報 (Support)
ご質問や不具合のご連絡は、このページの「コメント欄」をご利用いただくか、「このブログについて」に記載の連絡先までお願いします。
あらかじめのおことわり (FAQ)
1)コンパスの北は、赤い針の方向です。方位は、電子コンパスとGPSから求められますが、本アプリは、電子コンパスの値を採用しています。試験用の機材と、手持ちのコンパス(デジタルでないもの、SUUNTOのA-30)と比べると、5~10度ほど差が見られます。また、電子コンパスは周囲の磁場に反応しやすいようです。
2)針のまわりの円の半径を、地図の右下に表示します。標準で500mですが、ズームイン、ズームアウトにより変わります。
3)針のまわりの円の上を回るのは太陽です。電子コンパスが機能しない場合でも、太陽の位置からおおよその方角がわかるようにとの趣旨です。大まかな近似計算で、日の出と日の入の時刻を求め、表示色を変えていますが、精度は高くありません。参考程度に願います。
4)電子コンパスや傾斜計のデバイスの存否をチェックしていますが、デスクトップPCでは、ダミーのデバイスがあるため、計測値が得られない場合があります。
5)地図表示は、緯度と経度をURLに埋め込んで、国土地理院地図を呼び出して表示しています。表示に際して、国土地理院地図には加工を施していません。なお、ウェブサイトの仕様の変更により、表示できなくなる可能性があります。
※国土地理院地図のウェブサイト
ズームイン「+」、ズームアウト「-」のボタンにより、縮尺を変更できます。それぞれ2段階です。地理院のタイル仕様のズームレベルでいうと、13~17(標準は15)の間です。
6)地図表示の縮尺などは、ウェブサイトのボタン等でも変更できますが、本アプリの表示は、変更内容と連動しません。「地図」ボタンを押すと、アプリの設定に戻ります。
7)メニューから「位置情報の表示」を選択することで、地図上にこれまで記録した経路を表示できますが、緯度、経度、距離の計算方法は、本アプリと地図では異なるため、正確には一致しません。あくまで、参考表示程度とご理解ください。
8)地図表示は、移動しても自動では追尾しません。「地図」ボタンを押して、適宜、更新してください。バックグラウンドでのバッテリ消費を控えたいとの趣旨です。
9)緯度と経度、およびその差分からの距離の計算は、「理科年表 平成27年版」、「地学部」の地球楕円体に関する計算式(定数は、測地基準系1980の値)をもとにしています。
10)記録した位置は、ファイルに書き出すことができます。カンマ区切り形式のテキストファイルです。各行の項目は、順に以下の通りです。
・記録順
・日付
・時刻
・緯度
・経度
・高度
・前回記録からの経度方向の距離m
・前回記録からの緯度方向の距離m
・前回記録からの直線距離m
・前回記録からの方位(北が0度、時計回り)
法華経寺の猫 ― 2016年02月18日 14:01
GPSアプリのデバッグをかねて散策中、法華経寺の山道脇の草むらにて、気持ちよさそうな表情に目を奪われる。そろそろ春の足音を聞く。
お散歩コンパス - アプリリリース ― 2016年02月18日 18:10
「お散歩コンパス」の名称で、ユニバーサルWindowsアプリをリリース。実際、野山を歩いて回るときは、SUUNTOのコンパスと、事前に印刷した国土地理院の地図を携行。街中なら、Google Mapがあればおよその用は足りるが、少し離れると地形図が欲しい。手持ちの端末には、各種のセンサが搭載されているので、代わりになるものか作ってみた次第。
※アプリのページ
開発時間は60時間強。うち、電子コンパスと傾斜計、GPSのセンサーまわりの仕様の習得と実装に20時間ほど。緯度経度から距離などを求める地球楕円体のクラスと、日の出日の入り時刻を計算するクラスの実装に10時間ほど。国土地理院地図の地理院タイルの仕様の理解と画面のマッピングに10時間ほど。
UWPのセンサーのAPIの使い方はそれほど難しくない。サンプルプログラムもあるので、値を得るだけの処理はすぐにできる。それをどう表現するのが課題。
距離や方角を扱うため、ずいぶんと久しぶりに三角関数と対面。「科学新興社 モノグラフ」を引っ張り出す。このシリーズは、トピックごとに概要から応用までまとめられていて便利。この頃はブルーバックスも矢野さんの本が人気だった。記述に制限のある教科書と違って面白かったが、これに相当するようなものは、今はあるのだろうか。
センサーのあとは、地図と実際の緯度経度、および、画面のピクセルとのマッピングに苦労。メルカトル図法の原理を学びなおす羽目に。今回は、ズームレベル15を選んだので、GPSから現在の緯度を拾い、この緯度での円周(卯酉線:ぼうゆうせん)の長さを求め、2の15乗(32768)で割ると、地理院タイル1枚分の長さが求まる。これが縦横256ピクセルなので、ここから1ピクセルあたりの距離が求まり、画面との対応が取れる(はず)。
※地理院タイルの仕様
あとは、ひたすら歩く。一辺が300~500mくらいになるような長方領域を歩いて、地図と記録した位置がずれないか確認。ずれが大きいと持ち帰りデバッグ。この時期、外が寒いのが難点。工事現場にWiFiがあって、GPSではなくてそちらを拾って位置がずれたりも。WiFiはオフにして歩く。
日の出日の入りの時刻計算は、理科年表に推算表があるが、これを使わず、お遊びで近似計算をしてみたが、高い精度は得られず。やはり球面の幾何にまじめに取り組まないと。
Windows10 mobileでfoobarやTwonkyの楽曲を制御したいが ― 2016年02月20日 14:07
普段聴く音楽は、Twonkyやfoobarといったメディアサーバで管理している。それで、ちょっと音楽を聴きたいとき、でも、PCを立ち上げるのはちょっと、というときがある。
iOSやAndroidだと、スマートフォンからリモコンのように操作するアプリがある様子。スマートフォン自身で鳴らすのではなく、楽曲を選んだり、再生停止を指示するもの。Windows10 mobileだと、そのあたりはまだ。
※たとえば、MonkyMoteとか。UPnPの実装ではないようだけど。
Twonkyサーバがあれば、ブラウザから、楽曲と再生機器(メディアレシーバ)を選んで、似たようなことができる。
Windows10 mobileでもEdgeからアクセスすれば、操作できなくはない。操作性はちょっと厳しい。
同じWindows10でもデスクトップなら、エクスプローラの「ネットワークの場所」欄に、Twonkyやfoobarが現れ、ここから楽曲を探すことができる。Windows10 mobileのエクスプローラでは現れない。
楽曲を見つけたあとは、右クリックのメニューから、「デバイスキャスト」を選べば、ネットワーク上にある機器に再生を指示できる。複数選べば、続けて再生できるが、シャッフルボタンはない。上図は、ヤマハのAVアンプで再生。
このあたりどうなっているのか、簡単なコードを書いてみる。Twonkyやfoobarにアクセスするのは、「KnownFolders.MediaServerDevices」プロパティから、「GetFoldersAsync()」でできる。
Windows10 デスクトップの実行例。フォルダのリストに値が入り、サーバが2つ表示された。
Windows10 mobileの実行例。「KnownFolders.MediaServerDevices」プロパティにアクセスした時点で、例外が発生。メディアサーバを処理する機能は、未実装ということ。探してみると、MSのコミュニティのやりとりでも確認できる。
このあと、ApiInformationから、実装の有無を確認しようとしたができていない。コードの最初は、その試行の跡。
さて、半年も待てば、実装したバージョンが出てくるような気もするのだが、どうしたものか。待てないなら、UPnP(DLNA)の仕様を実装することになる。対応アプリがないのは、皆さん、このあたりを考えあぐねている様子。
※UPnPの仕様
UPnPのDeviceInformationの情報では不足なので ― 2016年02月25日 12:34
Twonkyやfoobarにアクセスするのに、「KnownFolders.MediaServerDevices」プロパティが使えないとすると、DeviceInformationからアクセスせよ、とMSDNの説明にはある。
※MSDNのデバイスの列挙(Enumeration)の説明
DeviceInformationからUPnPデバイスの情報を取得する処理を書いてみると、確かに、IDや名称、カテゴリ、IPアドレスは取得できる。もっとも、実際のアクセスには、ポート番号やデバイスの詳細情報を示すXMLへのパスが必要。しかし、それを示すと思われるプロパティの値は、null。図中のIPアドレスは、ひょっとして使えるかと思ったが、違った。
デバイスの属するコンテナの情報も取得してみる。オーディオやビデオ、写真など、どういった種類のメディアをサポートするかの情報も得られる。ただし、不足は解消しない。
いろいろ探してみると、以下の記事に詳しい。名称が付与されておらずGUIDでのアクセスが必要な属性もある。いろいろ試してみるが、結局、必要な情報は得られず。欲しい情報は軒並みnull。
※Codeprojectの記事
また、実際に動かしてみると、情報の取得に時間がかかり(20秒強)、エクスプローラでTwonkyやfoobarがすぐに認識されるのと比べ、挙動が異なる。思うに、エクスプローラはDeviceInformationは使わず、独自の実装をしているのではないか。そのあたりで、デスクトップとmobileのコードの統合が未了のため、両者の実装が異なるのではないか、と想像してしまう。
ここで止めるのも惜しい。先のCodeprojectの記事のつづきに、Datagram SocketでSSDPにマルチキャストで問い合わせするコード例があるので、参考に処理を書いてみる。
こちらは、1秒もかからずに答えが返ってくる。アクセスするためのパスは、"LOCATION:"のタグで得られる。名称などの追加の情報は、このパスにアクセスして入手する。上から順に、foobar、ヤマハのAVアンプ、Twonky。
※Codeprojectの記事
それではと、Twonkyのパスにhttpでアクセスした結果。HttpClientのクラスを使えば簡単。XMLで記述された情報が得られる。
ヤマハのAVアンプのパスにhttpでアクセスした結果。改行コードが入っていないが、こちらもXMLの情報が得られる。
これでようやくスタートライン。この先は、UPnPの仕様書を紐解いていけば、なんとかなるはず。実に読みにくいんだけど。
最近のコメント