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月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の仕様書を紐解いていけば、なんとかなるはず。実に読みにくいんだけど。
ARIA The NATURAL セレクション上映会 ― 2016年02月27日 18:50
昨晩は新宿で、ARIA The NATURAL セレクション上映会。投票で選んだ5話を大きなスクリーンで観る企画。The NATURALは、どこから観てもいつ観ても楽しめる話が多い。こういう企画にぴったり。The ORIGINATIONだと、順序通りに見ないといけない気がする。
選ばれたのは、次の5話。
5位：宝探しの話。第2話。
第12話と同数だったが、企画担当の一押しでこちらに。灯の歌は即興だったと、葉月さん。鳩との会話は、予想の斜め上の演技で、皆、仰け反っていたと飯塚プロデューサー。
ごちうさの宝探しの話と関係があるのか、伊独で似たような風習があるのか。
4位：晃が悪口を言われている話。第24話。
職業アニメとも言われる所以。社会人になる覚悟を教えてくれる。
The ORIGINATIONのトラゲットの話と合わせ、好きな話の一つ。
3位：アリスの影踏みの話。第13話。
監督の伝言曰く、ARIA唯一のアクション回。アリア社長のコッコロはアドリブ。
2位：雪だるまの話。第26話。
大原さんのリクエストで実現した話。監督の伝言曰く、アニメ向きではない話だが、最終回の演出ならと言うことで成立。まだ誰も足を踏み入れていない小路に駆け出すアリシアさんを追う、灯の少し小悪魔的な表情はアニメではめずらしい、と葉月さん。
1位：ゴンドラとお別れする話。第16話。
第17話とつづきの話。2クールの折り返しでスケジュール的にきつく、取材も大変だったと、監督の伝言。傷んだゴンドラは、名古屋にあったイタリア村のゴンドラを参考とのこと。
以上、ケットシーなどがでてくるファンタジー回が入らなかったのは少し意外。参加者の年齢が高めだったからかな。テレビシリーズということであまり期待していなかったが、音響面の充実にも驚く。背景に流れる音や効果音、会話でたくさんの気づきがある。劇場で観ることは、意義深い。
10年経っても、関係者どうしでも知らない話が出てくるところなど、聴いているこちらもなかなか楽しい。最後に、ARIAカフェをやりたい、との話が出て会場拍手。採算を考えると秋葉原とかになるのかもしれないが、明るい海辺がいい。家族連れが気軽に来れる、というなら、葛西臨海公園あたりはどうだろう。
最近のコメント