maaash.jp

what I create

BLE-Proximity for COVID-19 contact tracing

コロナウィルスが広まり始めてから、自分の専門性を生かして何かできないかと考えていた。

Bluetooth Low Energyを使ったスマートフォンアプリを配布し、誰と誰が近くにいたか履歴をとっておいて、後にアプリのユーザーの中から感染が確認されたら、そのユーザーが近くにいた他のユーザーに警告する、
というアイディアがあることを知ったのは 鐵人三國誌 だったか。

これは得意領域やん、と思い飛びつき、
コロナのおかげで自分も時間が多少できたので(!?)
そこからシンガポール/TraceTogetherヨーロッパ/Decentralized Privacy-Preserving Proximity Tracingで検討/実装されているアプリ Projects using personal data to combat SARS-CoV-2 をリサーチをしつつ、プライバシーを保護して、どうBLEを使えばBackgroundでしか使わないだろうこのアプリ間の通信が可能で、Androidも共存できて、小さく初めてすぐにリリースできて、アプリユーザーが増えてもサーバ負荷が軽そうな仕組みを考えていた。

そして昨日 Privacy-Preserving Contact Tracing を発見するまで一週間ばかり。

Apple, Googleが5月に出すならそれを待とう、という空気だと思うので、この一週間ばりばり書いていたコードを公開して 供養したい

BLE-Proximity / BLE-Proximity implements contact tracing on iOS, to prevent COVID-19 transmissions.

このプロジェクトは何もなければフリーズしますが、何か良い利用方法があれば協力したいです。右の連絡先にご連絡ください。


考えていたアプリの仕組みは(英語で)レポジトリのREADMEに書いたがここでは日本語で。

要約すると、

  • UInt64のランダムな数をアプリ内で生成してuserIdとする
  • Bluetooth Low Energyでこれを交換する
  • 定期的にuserIdは更新し、アプリ内に自分のuserIdの履歴を保存する
  • BLEで受け取った相手のuserId(peerIdとする)も履歴を保存する
  • 履歴は4週間まで保存し古いものは捨てる
  • COVID-19 positiveになった人は、自分のuserIdの履歴を、同意の後、(ここはTODOだったが)医者の電子署名(ができる国だったらよかったな〜)など信頼性を保証しつつサーバへ保存
  • サーバではpositiveだった人のuserIdの履歴を公開
  • アプリはpositive userIdリストをダウンロードして、アプリ内のpeerIdの履歴にマッチするものが無いか探す

という感じ。

サーバ側の開発が軽い、プライバシー面が安心(サーバに送る情報がpositiveでなければ何もない, BLEを通して送るuserIdもランダムだし更新する)、という意味で筋が良いと考えていた。

そしてこのアプリの機能が広く多くの人に使ってもらえることを考えると、LINEやメルカリなど多くのユーザーがダウンロードしているアプリのアップデートとして使ってもらうのが最高だろう(もちろん自分の意思でオプトインしてね)。ということを考えてFrameworkとアプリを分けてFramework側にこの機能を実装していた。

https://www.apple.com/covid19/contacttracing から辿れるApple, Googleのドラフト技術資料を見ると大きな違いは、

1. BLEではAdvertisingにデータをのっける

そりゃできたらそうするわ!
iOSではAdvertising dataにアプリが(GATT ServiceのUUID以外の)任意のデータをのせられる公開APIは無い。

First, in May, both companies will release APIs that enable interoperability between Android and iOS devices using apps from public health authorities. These official apps will be available for users to download via their respective app stores.

https://www.apple.com/newsroom/2020/04/apple-and-google-partner-on-covid-19-contact-tracing-technology/

これ英語が意味不明なのだが、”both companies will release APIs” なのか “download via their respective app stores” なのかどっちなのか。
Advertising dataをアプリからいじれてそれが非公開APIとしてiOS13.xからできるようになり、その後公開されていくとしたら熱いがそれは無いかなあ…

これができないので、BLE-Proximityでは、read characteristic, write characteristicを用意し、BLEでuserIdを読み書きできるようにした。AdvertisingしているiOSアプリをScanで見つけられてread/writeできない、ほど一時的に近くにいる場合は無視してよいでしょう。それにread, write characteristicを両方持っていれば、BackgroundでAdvertiseしているiOSアプリを2つ考えた時に、それぞれのアプリが相手のAdvertiseをScanして発見しなくてよい(片方だけでよい)ので発見率が上がるはず。

iBeaconを使えば、というオプションもあった。
iOSアプリでiBeaconのふりをすることは可能だが、バックグラウンドでは継続してiBeaconとしてAdvertiseできない & iBeaconのAdvertiseにアプリからのせられる情報はMajorとMinorの合計32bitで、それだとuserId空間が足りない。

という理由から却下した。このアプリをForegroundで使うことは考えにくいので、iOSアプリ間で、バックグラウンドで通信できないのはきつい。

もちろんiBeaconでなくてもBackgroundのAdvertiseはForegroundに比べ見つかりにくいので..ではあるが

2. userIdの生成が違う

Apple, Googleのドキュメントでは、userIdに相当するものは Tracing Key –> Daily Tracing Key –> Rolling Proximity Identifier と生成され最後のが交換される。 positiveな人がいたらその人のDaily Tracing Keyに相当するものがサーバにアップされる。

こうすると、サーバ上にアップする情報は、Daily Tracing Key x その人がウィルスを持っていた期間の日数になり、Rolling Proximity Identifierはもっと頻繁に変更できる。

BluetoothのMACアドレスの更新と同期するというのもなるほど。BluetoothのMACアドレスの更新タイミングってiOSアプリで公開APIから知れるんだっけ?

なるほどHKDF便利やん…


ということで、何かを作ってみると他の人が作ったものがいかによくできているか痛感できてさらに勉強になる、という良い例であったのと、

プラットフォーム側にたつのは自由度が高く楽しいだろうなあ、

このアイディアもっと早くに思いつけていたら違ったはずだ、がんばれ。

とまとめてしまいとする。

ラムネのあれ

ラムネのあれを3Dプリンタでつくった。

Untitled

Untitled

「いつものより開けやすい」と好評です。

エストニアに引っ越した

エストニアの首都タリンに引っ越してから5ヶ月たった。

Untitled

タリン旧市街

2013年にカヤックをやめた理由の1つがそれだったので、もう5年もずうっと海外に引っ越したいと考えていてやっと叶った。5年もかかったのは条件が厳しかったからだろう。

仕事面では、

  • 小さく柔軟な会社
  • 何かしら世界を良くしようとするビジョンとロジックがあること

場所に対しては

  • 英語教育がちゃんとしていること
  • 安全であること

この両立。

自分がウェブやスマホアプリの開発をやってきていたので、「やっぱりベイエリアに行って本場にいたい」と思っていたが、ビザ面でうまくいかなかった。

アメリカの就労ビザを小さい会社がサポートするのは厳しい。
H1Bは抽選だし、抽選に通っても給与の下限が賃金1000万円以上という条件があるので会社が小さすぎるときつい。
Eビザもあるが、基本的には「アメリカで人を採用してくれるんだろうな?」ということなのでその計画がたっていないときつい。

1年日本で仕事してLビザでアメリカへ行くのが手っ取り早そうだが、やはり1,2番目の条件に引っかかり踏み出せなかった。
グリーンカード抽選が当たるほどラックにふられている設定ではなかったようだった。

そうこうしているうちにトランプが大統領になり、アメリカでは学校での発砲事件が引き続き問題になっていて、
「おいおいアメリカでいいのか?」と思うようになってきた。
YouTubeでなんでもいいからトランプの演説を見てみるといい、このおっさんが大統領になるようではだめだ。

逆にエストニア移住につながるきっかけがあり、エストニアになびいていった。
エストニア移住プランは上記の条件を満たしていた。

エストニアについて調べるとどんどん気になっていった。

  • E-Governmentの分野で先進的である
    E-Residencyというのが始まった。

  • 首都タリンの人口が40万人程度で小さい
    日本の藤沢市と同じくらいか、、と知ると急に親しみが湧いた。
    小さな島のようなコミュニティはむかしから好きだった。

  • 寒い
    札幌くらいか、、と知ると、スキーヤーなので(エストニアにはマウンテンスキーする山は無いが)雪が降る街か、、と急に楽しみになった。

  • エストニアの大統領
    女性で46歳。
    トランプは72歳、安倍首相は63歳。

  • 見学に行った
    英語で授業をしている小学校を見て、町並みを見て、誘ってくれた会社のメンバーに会った。

ある時、もしかしたらエストニアは国レベルでスタートアップなのではないか?という考え方が生まれた(Exitはないから中小企業かもしれないが)。

20万人以上社員のいる大企業(P)と、個人事業や2人創業者のスタートアップで働いた経験を、
日本やアメリカとエストニアに照らしてみると、国に対しても会社選びと同じような嗜好で選べばいいんじゃないか、

社員数 / 国の人口
若いCEO / 若い大統領
会社のプロダクト / 国の施策

若いリーダーが率いる小さな国のメンバーになる、というのはおもしろい体験なのではないか?
そういうリーダーを選べる国民がいる、というのはおもしろいんじゃないか?
と思うようになってきた。

中略…

まとめ

タリンに引っ越しました。

PS. エストニアや海外と仕事したい方、興味があればどうぞ
海外/エストニアと日本をつなぐセールス/サポートエンジニアをWanted!

SR-90サーボホーンのギザギザ付きをつくった

SG-90 servo horn

サーボを使った何かをつくっている。
最も手に入りやすく安い SG-90 をいくつか買って、Arduino Unoから角度を変えてみたりしていると、付属のサーボホーンでは物足りなくなくなってきたので作ってみた。

SG-90 near shot

このようにサーボの先端には細かなギザギザがついていて、付属のサーボホーンはこのギザギザにマッチするギザギザが穴の内側にあるため、ネジを使用しなくてもサーボの先端に固定されてくれる。

先駆者である Modelling a Servo Spline を参考にしつつ、
Fusion360でこんな感じで2等辺三角形を21個、円周上に繰り返すと敷き詰められる。
contraintに式を使うと連動して全体が変わるのがおもしろい。

Fusion360 constraints for SG-90 horn

2等辺三角形の1辺の長さを変えると、円周上に並んだギザギザの高さが変わるので、
これを3Dプリンタで出力してSG-90にはめてみては
また2等辺三角形の1辺の長さを変えて、と3回繰り返したらいい感じにはまるのができた。

IMG_1461

Afinia H480, ABSを使用してうまくいったのが以下のファイル。

SG-90

Fusion360 archiveでダウンロードすると取り込んでconstraintを編集できそう。
3Dプリンタや樹脂の素材で仕上がりが異なるだろうと思うので、2等辺三角形をご自由にいじったり、(そもそも穴がまだ空いてないので)ご自由にあけて使ってください。
共有URLができるのはFusion360素晴らしいな!

SG-90 servo horn with gears on thingiverse

Prototyping Lab 第2版にIRKitを取り上げていただきました

Prototyping Lab 第二版の作品紹介にIRKitを取り上げていただきました!

Untitled

IRKitをなぜ作ろうと思ったのかから、IRKitができあがっていくまでの軌跡がまとまっています。

Orphe, Mesh, HACKberry, ベゼリーなどの作品紹介も楽しい。

Orpheの、LEDストリップをサイドから底面向きに変更するエピソードは、一気に問題がいくつも解決するアイディアでありながら新たな問題が複数発生したんだろうなと想像できて熱くなる。 こういった、ハードウェア製品を作る際に立ちはだかった問題とこうやって解決した、っていうストーリーをもっと読みたいんだけれど、良い方法は無いものか。

本はその後、入力(センサ)、出力、データ処理、、とArduinoのコードを交えてプロトタイプの作り方を紹介していくが、コードを読み書きせずに各レシピの概要を読むだけでも価値がある気がする。 ハードウェアを作るようになって実現できることの可能性が無限大とは思うものの、発想するアイディアの範囲は知識に限定されるので、知識をどう広げていくかが重要。

それに、以下のように、

  • センサの原理からくる得意/不得意な環境
  • センサのキャリブレーション
  • ノイズを含む入力にかけるフィルタ
  • ヒステリシス
  • 状態遷移

(いちいち説明するのがめんどくさい)エンジニアリングの基礎的な知識がまとまっていて、 エンジニアと会話できない非エンジニアにそっと渡したい、共通語彙集としても良い一冊かも。

Amazon Alexaにエアコンをつけてもらう

Nature Remoは、機能的にはIRKitの正統な進化形と考えていただいてよいと思います。

と書き先日告知したNature RemoのKickstarterが成功して終了しました!!
応援していただいている方、ありがとうございます。

昨日から、引き続きMakuakeでクラウドファンディングを開始していますので、
Kickstarterを逃した方はぜひ!!

今日は、Kickstarterサイトでも提供すると約束していて、個人的にもすごく熱いと思っている、Alexa連携をIRKitで試してみました。
Nature Remoで試すとサンプルコードまだ出せないのでね。

Alexaは様々な理由から

  • Amazon Echoは国内で販売していない Amazon Tapはあるようだなあ…
  • Amazon.comアカウントが必要
  • Amazon.co.jpのPrimeアカウントが使えない><
  • 日本語対応していない

日本では流行ってる話をほとんど聞きませんが、こないだ渡米した時に感動して買ってきてしまいました。

感動ポイントはとにかく音声認識がすごいこと。

遠くからでも、音楽再生するなど雑音環境下でも、ほとんど認識失敗にしない感覚があります。
Siriだと、認識失敗したら「まだSiriにはできないか(落胆)」と感じるところ、
Alexaだと、「あれ、自分の英語の発音が悪かったかな」ってなる。
音声認識って使えるじゃん

Alexaの認識対象の語彙を限定するルールベースのアプローチがしばらくは優位なんじゃないか


さて、Alexaに何か音声でしゃべりかけて外部サービス連携するためには、Alexa Skills Kit (ASK)を使います。

Alexa Skills Kitの中にはCustom SkillsとSmart Home Skillsがあり
まずは簡単なCustom Skillsで作ります。

手順は

  1. Skillをつくる

  2. Invocation Nameを設定

    上のビデオの中で “Ask {IRKit} to turn on the air conditioner” と話していた {IRKit} の部分
    これはSmart Home Skillsでは操作対象が制限される分必要なくなるようだが、Custom Skillsには必要

  3. Intent Schemaの設定

    音声で操作したい内容を定義する

     {
       "intents": [
         {
           "intent": "ControlAC",
           "slots": [
             {
               "name": "Control",
               "type": "LIST_OF_CONTROLS"
             }
           ]
         },
         {
           "intent": "AMAZON.HelpIntent"
         },
         {
           "intent": "AMAZON.StopIntent"
         },
         {
           "intent": "AMAZON.CancelIntent"
         }
       ]
     }
    

    ControlACというのがエアコンの操作で、LIST_OF_CONTROLSというCustom Slot Typeで今回のアプリケーション固有の単語を設定する。
    今回は on | off | start | stop のみ。

  4. Sample Utterancesの設定

    音声認識する語彙を設定

     ControlAC turn {Control} my air conditioner
     ControlAC turn {Control} my AC
     ControlAC turn {Control} the air conditioner
     ControlAC turn {Control} the AC
     ControlAC turn {Control}
     ControlAC turn {Control}
     ControlAC {Control} my air conditioner
     ControlAC {Control} the air conditioner
    

    この文字列をしゃべると、{Control}に入ってたon | off | start | stopをLambda関数に渡してくれます。

  5. AWS Lambda関数を作成

    TriggerにAlexa Skills Kitを設定
    LambdaのNodejsのコードは最後に。
    IRKitにエアコンコントロールしてもらうのにIRKitのInternet HTTP APIを使うので必要なdeviceidclientkeyを取得します。

  6. これでiPhoneのAlexaアプリを開き Skills -> Your Skills と開くと

    Untitled

    IRKit Skillが見つかれば準備OK

  7. Alexaにしゃべりかける

    “Alexa, ask IRKit to turn on the air conditioner”

  8. 他の人にも使ってもらうためには審査に提出するが今回はしない

ということで、開発者であればわりと簡単に、
自分のIRKitをAlexaを通して音声で操ってエアコンをコントロールする、
ところまでいけますが、
開発者でない方でも(または開発者でも面倒であれば)、音声エージェントに話しかけてスマートホームしたければ、
ぜひ早期割引期間中にNature Remoをゲットしてください!!!!


Lambdaのコードはこんな。

USBRH Linux用ドライバをラズパイにインストールする

USBRH Linux用ドライバ をラズパイ上でビルドしインストールするまでのyak shavingの記録。

Makefile にあるように、ビルドしようとするラズパイのカーネルのソースが必要。

github.com/notro/rpi-source/wiki を使用すると、よしなにソースを /home/pi/linux-a7b329ab34dcea81650f5b5c9c77208907dde23c とかにダウンロードし、/lib/modules/4.4.14+/build からそこへのシンボリックリンクを作るなどしてくれる。

上記URLにあるようにgccのバージョンをあわせたり(Raspbian Wheezy上でgcc4.8.3以上を入れる)、ncurses-develを入れたりする。

Raspi上で素のviが全然使えず諦めてsudo apt-get install emacsした。

Nature RemoのKickstarterを開始しました

IRKitを販売し始めたのは 2014年1月15日 なので、2年と4ヶ月ちょいになります。
あっという間ですね。 その間製造したのは…
100 + 500 + 1000 + 1000 + 2000 + 2000 + 3200 = 9800
約1万台。なんで最後3400にしなかったのか、悔やみきれません。

そして昨日の夜、新作であるNature RemoのKickstarterを開始しました!

Nature Remoは、機能的にはIRKitの正統な進化形と考えていただいてよいと思います。
IRKitの欠点として一番多くTwitterで見かけたりお問い合わせいただいたのは

  • 青いLEDが眩しすぎる

という点で、それを修正するのと(笑)、

  • 38kHz周辺のキャリア周波数のみ対応 -> より広いキャリア周波数の範囲に対応する
  • 赤外線が飛ぶ方向が前方2方向のみ -> 広い範囲に飛ぶように

といった基本的な機能の強化。

  • ArduinoIDE, 自作のアップデート用PCアプリを使ったファームウェアアップデート -> Over-The-Airアップデートできる
  • いろんなセンサがついてる
  • 静電タッチセンサがついてる

さらに

  • ACアダプタが付属する

など(笑)、一般的な電気製品の様相を呈するようになっています。
自分は意外とこのタッチセンサが好評になるんじゃないかと想像しています・・・

電気回路やファームウェア全部がオープンソースになることは考えにくいですが、
メジャーなものを使っているので、おそらく開けれb…(略

IRKitのAPIを使ってハックしていた方は、そのままNature Remoに移行できればいいなと考えています。
が、、、まだどこまでできるか決まってはいません。
Remo用のAPIを用意する、という非互換の修正を入れる良いチャンスにそうしないではいられないので、うまくバランスを取っていきたいです。

長期的な構想も楽しみです。
一台で家中スマート化、米Natureが小型IoT機器、外からスマホで家電操作、電力の需給調整も

まとめると、
KickstarterキャンペーンのEARLY BIRDの価格を考えると
今ならIRKitより高機能なものがよりお安く手に入るかも?

もしよろしければ応援お願いします!
Nature RemoのKickstarter

メイカーズのエコシステム出版記念イベント@3331

メイカーズのエコシステム出版記念イベント@3331 に呼んでいただいて、IRKitの製造の話をしてきました。

メーヴェ作っている八谷さんを始めおもしろい登壇者陣。

7月末にやるという北海道のテストフライトは見に行きたいなあ。
自分のロールモデルである。
そのプレゼンに出ていた動画はこれ

「電波法の認証を、FCC認証とおってれば省略していいんじゃないか」
っていうアイディアが最後質疑の中であったけど、
日本が今後衰退していく中で置いてけぼりにならないためにもこういう工夫はしてほしいなあ

自分の発表資料はこちら
メイカーズのエコシステム出版記念イベント@3331 IRKitの話

次期製品は今月中盤以降、Kickstarterに出す予定なので、乞うご期待!

それでは メイカーズのエコシステム 新しいモノづくりがとまらない。 について。

“輪郭がはっきりしていない。” メイカームーブメントの輪郭、全容をつかめる一冊。
最も印象に残っているのは (書籍内の引用の引用だが…)

メイカームーブメントによって、世界は良い方向に変わっていくと考えている。 中略…
重要なのは、メイカー全員がMakeすることによって、「ある変化」を体験することだ。
いまの世の中には、コントロールできないものが多過ぎる。Makeのカルチャーは「コントロールできるものを自分たちの手に取り戻そう」という考え方だ。政治や経済は自分たちでコントロールできない。だが、ものを作ることは自分でコントロールできる。
この「自分は何かをコントロールできる」という想いをいただくことを、メイカーはとても大事にしている。
例えば、椅子を自作したとする。もちろん既成品より出来は劣る。しかし、自分で作った椅子には愛着が湧き、さらに「既成品の椅子が、どういう接着剤やネジを使って作られているか?」といった新しい視点が生まれる。それまでの人生では、作りの良い椅子を見ても特に何も感じなかったかもしれないが、実際に手を動かして関わってみることで、かつて無縁だったものに親しみが生まれ、まるで仲間が作ったもののように思えるようになる。
こうした経験を積むことで、作り手に対する感謝や尊敬の念を持てるようになるのだろう。

「そうなんだよ!」自分はこういった変化を促進しようとものづくりをしている。
人の言葉でそれを語られてくすぐったいような嬉しい気持ちだ。
自分で作ってみるからこそ、「これは自分には作れないなあ」とため息をついて、作れる人に対して尊敬の念が生じるのは気持ちがいい。
何気なく見かけた電気製品を見て、「おお、こだわって作ってるなあ」と笑みを浮かべるのも気持ちがいい。

メイカームーブメントってなんなんだろって思ってる人は手にとって見ると良いと思います。