2018年7月14日

HDピコレーザープロジェクター 自作キットを組み立ててみた

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
つい先日、Twitterのタイムラインを眺めていたら、こんなものを発見。


これは試してみるしかない、と1台買ったので組み立ててみました。
ちなみに、お値段は購入時点で税込15,120円。限定数販売後は値上げするようです。


届いた中身はこんな感じ(写真には写ってませんが、レーザー出力部とHDMI信号を受ける基板を繋ぐフレキも入っています)


ひとまず、ベースとなるアルミプレートに基板とレーザー出力部を仮置きしてみる。
基板はそのまま「1」の番号が振ってあるネジで5箇所を固定。


レーザー出力部に付属のフレキを「TOP」の刻印がある向きで接続。
反対側を基板に繋ぎつつ、固定場所に位置合わせします。


レーザー出力部を「1」の番号が振ってあるネジで3箇所 固定。


トップのアクリルパネルを固定するためのシャフト(3番の部品)を、アルミプレートの裏側から「2」の番号が振ってあるネジで5箇所 固定。


最後に、アクリルパネルの保護紙を剥がして、「4」の番号が振ってあるネジで5箇所 固定。

なかなかコンパクトで、サイズはiPod Classicと同じくらい、重さは87gでした。


同じくレーザー走査型のプロジェクターで、SONYが海外にて販売しているMP-CL1Aとサイズ比較。
MP-CL1Aは個人輸入で1台5万円くらいだった記憶...


少し明るい環境だったので、はっきりとした比較にはなりませんが、レーザークラス3RのMP-CL1A(左)と比較して、HDピコレーザープロジェクター(右)はクラス1にしては健闘していると感じました。

ちなみに、MacとHDMIで接続したところ、YPbPrの信号には対応してないようで、画面全体がピンク色に...
手元にあるRaspberry PiやPINE64では問題なく表示されました。

次は真っ暗な環境で試してみようと思います。(続報はTwitterに書くかも

追記:真っ暗な部屋で映してみました。



投影先は天井、距離は2mくらいで、正確に測ってないけど50インチくらいはあるはず。
小さい文字はボケるけど、動画を見る分には悪くないかなというところです。

iPod Classicに大容量ストレージとバッテリーを搭載してみた

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
というわけで、長年考えていた「最強のiPod Classicを作りたい」という目標を実行してみたお話です。

改造に必要なiPod Classic(最終世代)の調達
ヤフオクやメルカリ等で電池消耗はあるけど外観の状態が良さそうな物を4つ(シルバーとブラック2個ずつ)購入、うち2個はApple Storeにてバッテリー交換して保管用に、残り2つのうち1個を比較用に未改造状態、もう1個を改造用として用意しました。

iPod Classic ... 1個 約1万円

ストレージ用の変換基板
iPod 第5世代やiPod Classic(6世代以降)に対応した、microSDカードが4枚挿しできる基板を購入。
https://www.iflash.xyz/store/iflash-quad/

iFlash Quad ...  42ドル = 約5,000円

ストレージ用のSDカード
ここ1年くらい大容量MicroSDカードの値動きを追っていて、200GBが1枚6000円を切ったら実行しようと思っていて...
ついに、先日、テクノハウス東映でSanDisk Ultraの200GBが6000円を切ったため4枚まとめ買い。


SanDisk Ultra microSD 200GB ... 1枚5,880円 x4 =23,520円

256GBを4枚挿しで1TBというのも憧れるけど、200GBと比較して256GBはまだまだ高いので、次やる時の楽しみにとっておきます。

「800GB」刻印のバックパネル (スリム仕様)
せっかく大容量化するので、刻印も実際の容量と同じ 800GB の物を購入。
あと、フロントもバックパネルも金属製のClassicは開ける作業が非常に難しく、歪みや傷が入ること必至なので元のバックパネルは使わないという前提です。
Aliexpressにて購入。


バックパネル ... 950円 + 送料 200円くらい = 1,150円

1950mAhのバッテリー
iFlash QuadとmicroSDの組み合わせでは元のHDDと比較してかなりスリム化するので、空きスペースに大容量バッテリーが入ります。
eBayでフレキが互換の交換用バッテリーを購入。

バッテリー ... 14.99ドル + 送料 350円くらい = 2,050円

これでパーツは一通り揃ったので分解作業開始...


想定どおり非常に開けづらいので、開腹作業には1時間くらい要しました...
今回はフロント側に傷を入れないようにし、バックパネルはどうなっても良いというスタンスで作業をしたので、バックパネルは縁が歪んで再度の取り付けは厳しい状態に。
また、クリックホイール操作時にクリック音を鳴らすための圧電スピーカーがイヤホンジャック下部のフレキに付いていましたが脱落... 慌てて追加でこのフレキ部品を発注するも、結局使わないことに(後述)


HDDを取り外して、iFlash QuadにmicroSDカードを4枚セット、HDDと同じ部分に置いてみる。
この状態だと元のHDDと比べて非常に薄いので、スッカスカです。
一応、iFlashにはバッテリーを増量せずにデフォルトのバッテリーで筐体を閉じるために、スペーサーとなる黒いスポンジも付いています。


次にバッテリーの接続。
左は元々の550mAhバッテリー、右が1950mAhバッテリーです。


1950mAhバッテリーを入れるには少々フレームに加工が必要で、元のHDDを固定するために付いている突起を削る必要あり。


こうして完成したものを閉めようとすると...
クリック音用のスピーカーが絶妙にバッテリーと干渉して液晶画面側が僅かに浮いてしまいます。
ということで結局、分解時にスピーカーが脱落してしまったフレキを再利用することに...


iPodをMacと接続し、iTunesからファームウェアを復元、実際に使用できる容量は730GB程度のiPod Classicが完成。

試しに90GBくらいの音楽ライブラリを同期して、LossLess音源を連続再生することでバッテリー持続時間を計測中...
48時間程度経過した段階で、バッテリー表示上は7割くらい残っているようです。

掛かった費用は4万5000円くらいでしょうか。
最近流行りのハイレゾ対応プレイヤーだと物によるけど5万円以上したりするので、ハイレゾとまでは行かないものの48kHz/16bitまで再生できて大容量で長時間再生できるプレイヤーとしては割とお得なのでは?と思ったり...

iTunesで10年以上続く音楽ライブラリを管理しているので、これからもiPod Classicには活躍してもらうことにします。

追記:重さの比較してみました。


シルバーが今回改造したiPod Classicで123g、ブラックが未改造で135gでした。
体感としては、僅かに軽くなったかなというくらい。
バッテリーが550mAhのデフォルトの物だと凄く軽く感じるけど、逆にオモチャっぽさを感じたので、ある程度の重さがある方が質感アップに寄与する模様。

2018年3月26日

気象庁防災情報XMLの受信と周辺サービスをGCPに移行した話

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク

そろそろ何かアウトプットしておかないとNo Activityマンになってしまうと思いつつも色々やることは山積みで筆の捗らない今日この頃、みなさんいかがお過ごしでしょうか。

さて、2015年12月にEVI 地震火山詳報を公開してから約2年と3ヶ月(その前身の桜島詳報から数えると3年7ヶ月)が経過しました。
実は、2017年10月頃のConoHaの障害によりサブスクライバが長時間止まってしまい、気象庁のPuSH配信から外されたため同月よりEVIのサービスが停止しておりました。
この際、本業(ゲヒルンUN_NERVへ作画提供)でも震源・震度地図の作画エンジンを作っているので完全にサービスを畳んでしまおうかとも思ったのですが...
振り返って周りを見てみれば、インタラクティブな震源・震度マップに挑戦している方が意外と少なく、作画方法も本業の仕組みとは全く異なるので 防災情報デザインに関する異なるアプローチの研究 ということで緩く継続してみようと思い立った訳です。

#防災情報デザイン、特に地震に関するものに関しては、様々な方が主にUN_NERVで提供されている地図デザインをパクって何度も何度も車輪の再発明をされていますが、みなさん少しは配色を変えてオリジナリティを出したり、「俺ならこうする!」といった伝え方の工夫を取り込んでみてはいかがでしょうか...? 芸が無さすぎて全くつまらんです。

EVI 地震火山詳報のサービスと後ろ側については、以前書いた記事をご覧ください。

地震とか火山噴火情報を閲覧できるWebサイトを作った (2015年12月)

上記の記事の通り、EVIは後ろ側がかなり複雑に絡み合っており、機能追加や改修をするにも面倒になっていました。
また、受信したXMLや生成したGeoJSON、画像の保管も同じインスタンス内に入っていたため、ある一定期間ごとに古いデータを削除する等のメンテナンスが必要でした。

...そこで、今回EVIを改修するにあたり以下の目標を立てて移行計画を実行することにしました。

1. 出来る限りマネージドなクラウドサービスに載る(俗にいうサーバレス)システムにする
2. 出来る限り最新の設計・構築方法、技術を用いる
3. デザインをなんかイケてる感じにする←重要

ということで、これらを念頭に置きつつ、隙間時間を使って3ヶ月ほどで作ったものがこちらになります。(冒頭のスクリーンショットのサービス)

QUAKE.ONE
https://quake.one/

#火山要素が消えたことには目をつぶってください

Twitterは以前のIDのまま Prioris_EVI を使っています。

Pushbulletも以前のままです。

日本国内で発生した全ての震源・震度情報
earthquake_jp

日本国内で発生した震度3以上の震源・震度情報
earthquake_int3over

さて、ここからは技術的なお話。

EVIからの進化ポイントは以下の通り。

1. 小さな画面を持つデバイスにおいて、操作可能な地図が非常に小さくなる問題を解決
→どの画面サイズのデバイスにおいても全画面で地図を表示し、情報をマップ上に配置する新しいデザインを採用

2. OpenLayersのバージョンアップ
→OL3から最新のOL4へ移行

3. ページを動的から静的生成に変更、SPA(single-page application)化
→地震発生をトリガーにしてレンダリング用のJSONをあらかじめ生成

4. Twitter、Pushbulletにて配信する画像形式の震源・震度地図のデザイン変更
→画像の生成方法もwkhtmltoimageからPuppeteer + Headless Chromeに刷新

また、これに伴ってサブスクライバから後ろも全て刷新しました。
構成図は以下の通り。(横に非常に長いので、拡大してご覧ください)


使用したサービスは以下の通り。

Google Cloud Platform
・App Engine
・Compute Engine
・Cloud Functions
・Cloud Datastore
・Cloud Storage
・Cloud Pub/Sub
・Firebase Hosting

地震が発生して「震源・震度に関する情報」が流れてきた時のパターンを簡単に説明すると...

1. 気象庁からPubSubHubbubでJMAXML publishing feedを受ける
2. atomを解析してEntryを取り出し、Task Queueに投げ入れ、Entryの内容をDatastoreに書き込む
3. WorkerはXMLを取得、XMLスキーマを適用してJSON形式に変換、XMLとJSONをStorageに保存し、JSONをPub/Subに流す
4. 3種のPub/Subトピックのうち地震に関係するトピックにぶら下がっているCloud Functionsが実行、Datastore内の地域コード対地域重心座標に基づいてGeoJSONを生成してStorageに保存、概要をPub/Sub(topic: quake-one)に流す
5. Pub/Sub(topic: quake-one)にぶら下がっているCloud Functionsが実行、Puppeteer(+Express)が待ち受けているGCEインスタンスに画像生成リクエストを送信
6. Headless Chromeで画像用ページを表示して撮影、Storageに保存
7. 画像生成リクエストが成功すると、当該eventIDの地震の概要と画像のURLをPub/Sub(topic: quake-one-with-image)に流す
8. Pub/Sub(topic: quake-one-with-image)にぶら下がっている各Cloud Functionsが実行、PushbulletやTwitterへ投稿
9. QUAKE.ONE はStorageを参照し、概要の入ったJSONとインタラクティブ地図描画用のGeoJSONを取得、JavaScriptでレンダリング

以前の複雑に絡み合った状態からすれば、随分とメンテナンスしやすいシステムへと変わりました。

AppEngine、Firebase Hostingは自動的にLet's EncryptでSSL証明書を更新してくれるし、しっかりキャッシュ、CDNが効いてくれます。
Storageは、ライフサイクルを設定することで、古いXMLやJSON、画像データを自動的にNear line→Cold lineと安価なストレージに移行、あるいは削除してくれます。
Cloud Functionsは実行時課金で、気象庁XMLをトリガーにして実行する程度の回数では全て無料範囲内に収まります。
唯一、画像を生成するためのPuppeteer + Headless Chromeが入っているGCEインスタンスだけは面倒を見てあげなければなりませんが、これも永続化が必要なデータやステートは持っていないので管理は楽々です。

さらに、副産物としてJMAXML JSON Viewerも出来ました。
こちらはデータ保存期間が浅い&検索が弱いので受信状況の確認程度用です。
商用利用は禁止ですので、お仕事で使いたい方はゲヒルンの気象庁XML Viewerをご契約ください。

というわけで、出来る限り新しめの手法でマネージドな感じのイケてるサービスが出来ました。

めでたし、めでたし。(終)

Recent Photos from Atelier (Flickr)

作業場で撮影した写真をアップロードしています。記事にする前の試作なども公開中です。