hirotakaster のすべての投稿

Alexaで開発する流れ(日本語UI)

Alexaで日本語で開発できるようになったから、サクット作る流れをメモで残しておく。詳細はAmazonの資料だけど、見てもなかなか分からなかったり、謎な部分のお助けになれば。

■ 利用するもの
登録はやっておきましょう。
– Alexaの管理画面(日本版) : https://alexa.amazon.co.jp
– Alexaの管理画面(こっちは米国版) : https://alexa.amazon.com
– Amazonの開発者ポータル : https://developer.amazon.com/edw/home.html#/
– AWS Lambda : https://console.aws.amazon.com/lambda/

ここではサンプルで使われるLambdaのサンプルにもある「色をAlexaに言わせるスキル」の簡易版を作る。どういったものか?と言うと、Alexaに向かって、
自分:「好きな色は赤です。」
Alexa:「あなたの好きな色は赤ですね。」
と色を反芻して言ってくれるもので、基礎的だけど初歩としては簡単な1歩になると思われ。ということで進めていく。

■ Amazonの開発者ポータルで情報を入力する
1. Alexaの開発者ポータルにログイン

2. 新しいスキルを作っていくボタンをぽちる

3.1. スキルの情報を入れていく

言語で日本語を選択できる。スキルの種類については、こちらを参照。自分が使いやすくて感動したのはスマートホームスキル。

3.2. スキルの情報をいれた結果

適当に名前を入れる。呼び出し名は「Alexa、なんちゃらかんちゃら」とスキルを起動するときの”なんちゃらかんちゃら”の部分。名前と呼び出し名を一緒にしておくと、分かりやすくて良いと思われ。もちろん、日本語名が使える。
そして、アプリケーションIDが発行される。この”アプリケーションID“のIDはあとでLambdaで利用する。

4.1.対話モデルを作っていく

スキルビルダーをポチって画面遷移

4.2.スキルビルダー画面

ここで対話モデルを作っていく。ザックリだと、

1. Alexaに話しかける話の構造(Intent)
2. 話しかけた結果から取得できる変数の設定(Slot)
3. 変数に割り当てることができる値の定義(SlotTypeに値を割り当て)

といった感じ。ここで設定した名前が後でAWS Lambdaのプログラム側で利用できるようになる。例えば、次から設定する流れだと、

1.1. Intentの名前を決める(MyColorsIntent)
1.2. 話しかける内容をつくる(“好きな色は {Color} です”と話かけられるようにする。ここで {Color} は可変の値。)
2.1. 変数(Slot)の設定を行う。
2.1. Slotのタイプを作る(Color_ITEM_LIST)
3.1. 変数に割当られる値の定義(緑、赤、青…etc)を入れていく

つまり、Alexaに話かける内容はここで決める。「怪しい {Color} は何ですか?」「{Color}をもう一度言ってくれますか」といった話を入れていったりする。
なにはともあれ、”Intentの+”ボタンをクリック。

4.3.Intentの名前を決める

ここでは”MyColorsIntent”という名前にする。この名前はあとでLambdaで利用する。この名称に日本語は利用できない。

4.4.話しかける内容をつくる

「好きな色は {Color} です。」と入れて”+”をクリック。この時、{}の前後に半角スペースを1個いれる。これを入れないとモデルを作る時にエラーになる。

4.5.Slotの設定を行う

右側のタブに”Color”という項目が追加されるので、その下にある”Choose a slot type…”をクリックするとリストが出てくる。ここで、新規に”COLOR_ITEM_LIST”を追記&作成して”+”をクリック。
割り当てたSlot(変数)には型が必要で、デフォルトで利用できるもので、AMAZON.City, AMAZON.DATE…etcが並んでいる。TEXTやStringといった文字列が無いのが辛い(少し昔はあったけど、無くなってしまった)。自作スキルでデフォルトで利用できる型があればそれを使った方がOK。大抵の場合は使いたい型が無いと思うので、自分で型を作ることになると思われ。

4.6.Slotに割当られる値の定義

「赤、緑、青…etc」を入れて”+”を押して、Slotに割当られる値を定義していく。ここで割り当てた値が、あとで作るLambdaで利用することが出来る。
設定関係はここまで。

5.作ったモデルを見てみる

“Code Editor”をクリックすると、作ったモデルのJSONの表現が見れる。ここで直接、モデルを記載していってもOK。

6.モデルの保存とビルド

“Save Model” -> “Build Model”で作ったモデルをビルドしておく。終わったら”Configuration”ボタンをクリックして、作ったスキルの設定をしていく。

7.Alexaの設定画面

ここでAWS Lambda(プログラム側)との連携の設定をする。サービスエンドポイントはAWS Lambda(HTTPS側で自前サーバも可)で、デフォルトのテキストボックスの所にLambda側のARNエンドポイントを入れる。まだLambad側は作っていないので、とりあえずAlexa側の設定はここまで。次にLambdaでプログラム側の設定をしていく。

■ LambdaでAlexaスキルを作っていく
1. Lambdaの関数を作る。

AWS Lambdaの詳しい説明はググればOK。ザックリだと、サーバを作らなくてもアプリでスケールしてくれるPaaSといった感じ。何はともあれ「関数の作成」をクリック。

2. 関数の作成

テキストボックスの所に”Alexa”と入れると、Alexaで利用できる関数一覧が出てくるので、”Alexa-skills-kit-color-expert-python”をクリック。

3. 関数の設定

作成する関数の”名前”、ロールは既存のロールで、”service-role/alexa-skill”を選択。
ページの一番下にある”関数の作成”ボタンをクリック。

4. 関数の作成完了

これでLambda側の関数が作成できた。サンプル通りで非常に簡単。次に赤枠にある部分のARNという部分をコピーしておいて、実際にAlexa側と連携させてテストをする。

■ Amazonの開発者ポータルでスキルのテスト
1. AlexaとLambdaの連携

作ったLamdaのARNを”デフォルト”という部分に入れて(arn:lambda:…という文字列)、”次へ”をクリック

2. Alexa上でテスト

Alexaのテスト画面。”無効”となっているため、クリックして有効にする。

3. サービスシュミレーター

少し画面のしたに行くと”サービスシュミレーター”があるから「好きな色は赤です」と入れて、”色を呼ぶを呼び出す”をクリックすると結果が表示される。

スキルの開発の流れはここまでで終わり。シュミレータでテストを行ったり、いちいちAlexaに話しかけるのが面倒な時はボイスシュミレーターで話させたりも出来る。
あとは自分でアプリを作ったり、音声で遊んだり。外部連携をLambdaでやって、カメラと連動させて「いまのお家の状態を写真を撮ってメールで送って」といったセキュリティデバイス化させたり、LINEと連動させたりするのも面白いと思われ。
スキルタイプで、カスタムは一般的な対話で遊べるけど、スマートホームAPIは使ってみるとかなり面白いと思う。自分はスマートホームAPIでデバイス連携をさせた時、簡単で美しい流れにちょっぴり感動してしまった。

あとプログラムを書くのが苦手で、とりあえずRSSフィードだけ読ませてみたい…という時はフラッシュブリーフィングでサクット作るのもアリだと思われ。”マイチャンネル”みたいな扱いとしても使える。

■ その他
1. Lambdaの応答の日本語化
サンプルのColor-me-expertは日本語を戻していない。ただ、普通にPythonのプログラムで応答の文字列の部分を日本語にしてutf-8(# coding:utf-8)をコードの頭に追加すれば、日本語を利用することができる。以下はサンプル中に日本語をいれたもの(超簡単)。
日本語とは関係ないけど、ここでの注意点は”lambda_handler(event, context):”でAlexaアプリのIDを指定して、作ったAlexaスキルからしか実行できないように制限をしている。

# coding:utf-8

from __future__ import print_function


# --------------- Helpers that build all of the responses ----------------------

def build_speechlet_response(title, output, reprompt_text, should_end_session):
    return {
        'outputSpeech': {
            'type': 'PlainText',
            'text': output
        },
        'card': {
            'type': 'Simple',
            'title': "SessionSpeechlet - " + title,
            'content': "SessionSpeechlet - " + output
        },
        'reprompt': {
            'outputSpeech': {
                'type': 'PlainText',
                'text': reprompt_text
            }
        },
        'shouldEndSession': should_end_session
    }


def build_response(session_attributes, speechlet_response):
    return {
        'version': '1.0',
        'sessionAttributes': session_attributes,
        'response': speechlet_response
    }


# --------------- Functions that control the skill's behavior ------------------

def get_welcome_response():
    """ If we wanted to initialize the session to have some attributes we could
    add those here
    """

    session_attributes = {}
    card_title = "ようこそ"
    speech_output = "これは好きな色のサンプルアプリでーす "
    reprompt_text = "好きな色を言ってね。 "
    should_end_session = False
    return build_response(session_attributes, build_speechlet_response(
        card_title, speech_output, reprompt_text, should_end_session))


def handle_session_end_request():
    card_title = "おわりです"
    speech_output = "サンプルを使ってもらってありがと" 
    should_end_session = True
    return build_response({}, build_speechlet_response(
        card_title, speech_output, None, should_end_session))


def create_favorite_color_attributes(favorite_color):
    return {"favoriteColor": favorite_color}


def set_color_in_session(intent, session):
    card_title = intent['name']
    session_attributes = {}
    should_end_session = False

    # この Color がSlotで設定した名前
    # intent['slots']['Color']['value'] で値を取得できる。
    if 'Color' in intent['slots']:
        favorite_color = intent['slots']['Color']['value']
        session_attributes = create_favorite_color_attributes(favorite_color)
        speech_output = "あなたの好きな色は " + \
                        favorite_color + \
                        "ですね。 " \
                        "他に好きな色は?"
        reprompt_text = "好きな色を言ってね。 "
    else:
        speech_output = "色が分からなかったよ。もういちど言って " 
        reprompt_text = "色が分からなかったよ。 " \
                        "好きな色は赤ですとかって言って "
    return build_response(session_attributes, build_speechlet_response(
        card_title, speech_output, reprompt_text, should_end_session))


def get_color_from_session(intent, session):
    session_attributes = {}
    reprompt_text = None

    if session.get('attributes', {}) and "favoriteColor" in session.get('attributes', {}):
        favorite_color = session['attributes']['favoriteColor']
        speech_output = "あなたの好きな色は " + favorite_color + \
                        "です。終わります。"
        should_end_session = True
    else:
        speech_output = "私はあなたが好きな色が分からないです。 " \
                        "好きな色は赤ですとかって言って。"
        should_end_session = False

    return build_response(session_attributes, build_speechlet_response(
        intent['name'], speech_output, reprompt_text, should_end_session))


# --------------- Events ------------------

def on_session_started(session_started_request, session):
    """ Called when the session starts """

    print("on_session_started requestId=" + session_started_request['requestId']
          + ", sessionId=" + session['sessionId'])


def on_launch(launch_request, session):
    """ Called when the user launches the skill without specifying what they
    want
    """

    print("on_launch requestId=" + launch_request['requestId'] +
          ", sessionId=" + session['sessionId'])
    # Dispatch to your skill's launch
    return get_welcome_response()


def on_intent(intent_request, session):
    """ Called when the user specifies an intent for this skill """

    print("on_intent requestId=" + intent_request['requestId'] +
          ", sessionId=" + session['sessionId'])

    intent = intent_request['intent']
    intent_name = intent_request['intent']['name']

    # この部分でIntentで設定した名前で処理を分岐することができる
    if intent_name == "MyColorIsIntent":
        return set_color_in_session(intent, session)
    elif intent_name == "WhatsMyColorIntent":
        return get_color_from_session(intent, session)
    elif intent_name == "AMAZON.HelpIntent":
        return get_welcome_response()
    elif intent_name == "AMAZON.CancelIntent" or intent_name == "AMAZON.StopIntent":
        return handle_session_end_request()
    else:
        raise ValueError("Invalid intent")


def on_session_ended(session_ended_request, session):
    """ Called when the user ends the session.

    Is not called when the skill returns should_end_session=true
    """
    print("on_session_ended requestId=" + session_ended_request['requestId'] +
          ", sessionId=" + session['sessionId'])
    # add cleanup logic here


# --------------- Main handler ------------------

def lambda_handler(event, context):
    print("event.session.application.applicationId=" +
          event['session']['application']['applicationId'])

    """
    ここの部分でAlexaアプリのID(applicationId)を設定しておく。このlambdaの関数がAlexaの当該アプリからしか実行できないようにしておく必要あり。
    """
    if (event['session']['application']['applicationId'] != "amzn1.ask.skill.XXXXXXXXXXXXXXXXXXXXXXXX"):
        raise ValueError("Invalid Application ID")

    if event['session']['new']:
        on_session_started({'requestId': event['request']['requestId']},
                           event['session'])

    if event['request']['type'] == "LaunchRequest":
        return on_launch(event['request'], event['session'])
    elif event['request']['type'] == "IntentRequest":
        return on_intent(event['request'], event['session'])
    elif event['request']['type'] == "SessionEndedRequest":
        return on_session_ended(event['request'], event['session'])


2. Alexaの管理画面
作ったアプリはAlexaのスキルで確認できる。

これはAlexa側のスキル管理画面。この右上に、自分がいれたスキル一覧が分かるボタンがあって、見てみると。

作ったスキル”色を呼ぶ”が入っている。スキルの追加は、スキル一覧から選んで有効にする必要があるが、開発版のタグ(devJP)が付いて、正規のアプリとパット見で区別して分かるのは良い感じ。

2.1. 自作スキルをAlexaに追加するには?
米国版のスキルだと開発するとすぐAlexaのスキル一覧に表示されて分かるのだけど、日本版では「スキルのベータテスト」から追加する流れのようだ(2017/11/15現在)。

開発者コンソールで、アイコンや色々な情報を入れてリリース申請の直前まで行える状態になると、このボタンが押せるようになる。

すると次のような画面になる。

ここでAlexaに登録している人のメアド等を入れて”テストを開始”ボタンを押すと招待URLが送信される。メールの中に”JP customers: To get started, follow this link:”という方のURLリンクがあるから(別の方はUS側のリンク)、そっちをクリックするとスキル一覧に追加されて、実機Echoでテストを進めることが出来る。

3. Lambda利用料金
AWSは従量課金で沢山使うほど課金される。基本的に何かをやろうとすると有料で、Alexaスキルを作ってみたいけど有料なのはなぁ…と思うかもしれない。
自分はAmazonの回し者でも何でもないけど、Lambdaは超安いです。Alexaスキルをさらっと作って動かして開発するくらいなら、課金額は10円もかからないと思われ。サンプルを動かすくらいなら、1円もかからない。気軽に動かしてみよっとー、って感じで全然大丈夫なはず。

4. リリース
実際にスキルを一般にリリースするには、公開情報の設定(スキルのアイコンや説明文)などの設定が必要になる。開発版なら、自分のスキル一覧上で使えるから特に気にする必要はないけど。
設定を適当に入れてリリースすれば一般利用者にすぐ使って貰えるか?と思ったら…Amazonによるリリース判定が待っていた。申請内容はこちら
スキルの説明文や、Alexaに話しかける内容をちゃんと作らないと、あっさりNGが来る。申請すればすぐ通るんじゃん!!と思ってやってみたら、全くそんな事が無かった(まぁ、ちゃんと作らないとダメというのは当然と言えば、当然だけど)。

上モノフェス

上モノフェスが10/8, 9に長野 上田市で開催されて行ってきた。

場所はサントミューゼというオシャレ空間でした。ぼーっと原っぱに座って寝ているだけでも何か満たされそうな感じ。

自分の展示空間は暗室独り占めー!!ひゃーっほい。

実はこの暗室空間はコンサートホールとエントランスの間にある踊り場の空間で、設置当日に準備をしてもらって感謝です。こういう滅多に使えない場所を使えるというのは実験をしたくなってくる。

投影する方向は、開けたらすぐというコンサートホールの扉に決めた。まさか、こういう所でKinect v2/XtionでDepthを取って投影したりサーボやステッパを動かして、LEDフラを回しまくる!!という非日常は無いだろうと…

諸々のものを設置。物としては、Kinect v2/Xtion、プロジェクタで投影もの、PCx2、LEDフラx2、ステッパ&サーボx9の最近製作しているものを持って来ました!!といった感じ。この青いLEDバーもゴッツリ動く(Kinect v2連動でUnityから制御)。

予想外だったのが…めっちゃ人。マジでめっちゃ人たくさん。はい、凄かったっす。たまに脱走して戻ってきたら、この暗室に自分が入れない…という状態になっているほど人たくさん。「こういう謎のオモシロ展で、人がどれくらいかなぁ…」と思っていたら、すげーかった。時間があっと言うまに過ぎて、他の皆さんのを見て回る余裕が無いくらい凄かった。あんまり他の所の写真を撮れてなかった…

1日目が終わって、ふと前スレのDepth輪郭に手を入れて見ようか…と思って、声をバーっと出すと投影しているのが分身/分裂するようにしてみたら…チビッコ達がワーキャー!!と声を上げてくれて、展示の3要素と思っている「光る(LED群)・大きい(バーが全体的に動く)・音がなる(人間の声)」が揃った。対応の忙しさに自ら火に油を注いでしまったか…と思ったけど、チビッコがキャーキャーしてむしろ楽しかった。

分裂しているのがブレてよく撮れて無いっすね。背丈ほどのフラを持って、声を出して、謎の動きをするバーの前のチビッコという謎のこの状態の写真が何気に面白い。

新聞に掲載されて、「新聞でこの光るのを見て、何かと思って来てみた」という年配の方とか、わざわざ来てくれた方とかいたり有り難かった。
とにかく、めっちゃ沢山のお客さんで凄かった。運営・手配して頂いたみなさん、ありがとうございます&次回or来年も楽しみにしています。

depth contour man

これはMaker Faire Bay Area 2017でダークエリアでプロジェクタを使って何か投影したいな…と思って、フライトの前日くらいにサクッとノリで作った。元々はDroneへの投影で使ったプログラムを流用して、少し変化をさせたものでXtionを使った。Depthをとって、輪郭抽出、密度を変えたり3Dの距離に応じてメッシュ化していたりもするけど、超シンプルにしてみた。Depth周りをやったことがある人なら、そっすね…1時間くらいでサクッと作れちゃうやつです(多分)。



超気合いを入れた凝ったものより、サクッと作った物が何故かウケが良くなる…というのは良くあることで、何故かこれを見て踊る・動く・声をだす(上モノフェスでは、さらっと改良をして声の大きさで分身させるようにするエフェクトを入れたり)、楽しんで貰えて何より。自分も、こういうシンプルな物の方が分かりやすくてウケるというのが理解できた。



これは投影する前の状態をキャプチャーし続けていたもの。ずーっとDepthデータも保存していたら何かで使えて面白いかも…と今更思っていたり。

ブースの前はこんな感じ。ずーっと人だかりだった。

わりと好きな1枚。ハートマークを作って遊んでいた。人が重なると千手観音みたいなことも出来るのよね。

前スレのフラとPETS、菊池さん、itogさんのも含めて光モノ展な感じ。左のLEDマトリックスも綺麗。この3人であの超大量のお客さん達をよく対応できたと感慨深いものがあったりする。

LED hula hoop

年初に光るフラフープを作っていた。写真で見ると幻想的になる。


Maker Faire Bay Area 2017


Maker Faire Tokyo 2017


Maker Faire Tokyo 2017


Maker Faire Bay Area 2017

単に光るフラフープはあるけど、これはネットワーク(WiFi)で接続して色を制御することができる。Bluetoothを使わなかったのはスマホとかからBluetoothで接続して利用するより、WebAPI(小さいサーバがフラフープの中で動いている)としてアクセス可能にした方が、PCやスマホからHTTPリクエストをするだけで簡単に使えるという利点の方が高いと思ったからだ。つまり…

「WiFiに接続して色を変えて遊べるフラフープ」という着地点になる。

利用したのはESP、LiPo、LED Stripsというシンプルな構成で、フラフープの中に丸っと組み込めばOKだろう、と安易に思って取り掛かることに。
というので問題になったのが、フラフープの径だった。外径が20mm、内径が12mmのフラフープをゲットして、組み込むことになるのだけど、このサイズに適合する端末と電池を考えるという問題になった。

LEDは入る。問題はESPとLiPoだ。ESPはアンテナに注意して削って小さくして収めることができた。LiPoは最初は単三電池x3のフラフープ用のホルダーを設計してみたけど、単三x3だとフラフープの中に入れた時に電池の長さ(単三x3分)で光らない影になる部分が出てくる。そこでフラに入って容量も大きい電池を探すことになった。

結局利用したのは、Trustfireのこちら。これをフラフープの内部に収まるように設計したホルダーに入れて、ESPとLEDと結線したら良い感じに。

ESPの方は内部でWebサーバを動かして、WiFiに接続したら他の端末からWebAPIを叩いて色やパターンを投入して変えられるようにした。LEDの総数は50個程度だから簡単だけど、これをなるべく即時で部分的に色を変化させる(1-20は赤、21-40は青、41-50は緑)、グラデーション変化をネットワーク経由で与えようと思うと少し考える必要が出てくる。出来るだけ通信の回数・サイズ(帯域)を抑えつつ効果が出せるように。
そこで出来るだけ簡素なAPIリクエストでガラッと色を変えられるように仕様を考えて、サクサクと色(RGB 255/255/255)を、全体・部分・パターンでサクサクと変えられるようにした。

フル充電だと光りながら2-3時間くらいは頑張ってくれる。電池容量的にそんなに持つはず無いだろうと思うかもしれない。もちろん、LEDが常に全力で点灯しっぱなしだと30分くらいで電池が切れてしまう。ただし、見栄えとして光る部分/光らない部分やグラデーションをつけたりするから常にフルで光っぱなしという訳では無い=>利用する環境次第で現実的に運用すると結構持つ、ということになる。

案外これは良い感じかもと思ったのが、LEDと端末、LiPoはフラフープの外径の硬質プラスチックで保護されるから、相当強烈な衝撃を加えても大丈夫。LEDの発熱も全く大丈夫。と言っても、Maker Faire Bay Areaでちびっ子達にバシバシぶん投げられたり、アスファルトに叩きつけられたりして、中の配線がちぎれて1個壊れてしまった…多分数千〜万人には触られたとは思うけど、パターンで光るプログラムも投入していたから完全に放置でOKという楽な部分はあった。そして壊れたから補強と対策をやって、Maker Faire Tokyo、上モノフェスの方は放置しておいても大丈夫だった。

こちらはMaker Faire Bay Areaで回していた人たち。首で回すというのは初めてみた。


現地のダンサーさんがやたら気に入って踊っていた。「売って」と言われたけど残念な事に、今売ってしまうと展示が出来なくなっちゃうのですよ>< あとでカメラマンも連れてきてバシバシ撮っていた。

微動だけで回していた人とかすごい。

露光で回しながら何か撮ったりとか、夜・暗室のイベントとかで遊んで使えると思われ。ちなみに…自分はほとんど回すことが出来ないっす。

lighting paper lantern



よく光る提灯や上下に稼働する物はあるけど、提灯自体が稼働して動いたら面白いんじゃ…と思ってカッと作った。

最初はIKEAの紙提灯をみた時に作れるのでは?と思って、何個かゲットしてきたのが最初だった。

これで稼働させると次のようになる。




これを利用すると縮む時に微妙な動きになる。というのは提灯は中の紙巻が螺旋状になっているため、力を加えるとどうしても斜めから縮む・広がるといった動作になる。ちなみに中の構造は次のようになっている。

非常に簡単だ。よく利用するParticleにモータードライバ、LEDにモーターと電源でLipoが入っている。色の変化はネットワーク経由でMQTTでRGBを制御、提灯の伸びる・縮まるといった動作はモーターで巻き上げる事で制御している。大きくなる時は自重で下がるように重さを調整している。
モーターを2個利用してよりパワーアップ、巻き上げを面で行えるようにしても、どうしても螺旋状の不均一な巻き上げ・伸びを解決できなかったから、別の提灯を利用することにした。

コストパフォーマンスが良くて、巻き上げ・伸びを綺麗にできる物はないか…と思っていたら、ダイソーの提灯を発見した。これは中の構造が螺旋状ではなく、同心円状になっていて均一な縮み・伸びが実現できそうだ。

動かして見るとこの通り良い感じ。



上下に稼働するのに加えて、形状も変化して大量に並べて光らせて遊んだら、わりと楽しいと思われ。

mbedTLS implementation to Particle

Now I contribute/maintenance 2 TLS client library to the Particle, TlsTcpClient, MQTT-TLS. Many developer request is “Please update to the light-weight library”, then I update to the light version!!
Initital TLS version(0.0.1) size is 111Kbyte flash image, too big:-< here is TlsTcpClient sample sapplication build.

Now latest version MQTT-TLS(0.1.3), TlsTcpClient(0.1.15) 40Kbyte over size down 70Kbyte:) I think only TLS library real size maybe 60-70kbyte.

8 Cipher Suites are included in this library, TLS_RSA_WTIH_AES_256_[GCM|CBC]_SHA384、TLS_RSA_WTIH_AES_128_[GCM|CBC]_SHA256、TLS_RSA_PSK_WTIH_AES_256_[GCM|CBC]_SHA384、TLS_RSA_PSK_WTIH_AES_128_[GCM|CBC]_SHA256
here is MQTT-TLS tls 1.2 negotiation flow(my MQTT server port is 1883).

It’s hard to lightweight TLS library for think about the selection of the TLS protocol/cipher suites and algorithm, application have to include 2048bit root certificate as a result it waste 2048bit flash area. I think maybe more lightweight TLS library(about 50kbyte) could be. If more issue/request coming, I will try to update the library:)

—–

mbedTLSの組込で分かったこと に続いて…TLSをメンテしたり、色んなリクエストに対応しつつTLSの組込という事をしている。この2つTlsTcpClient, MQTT-TLS

めっちゃ軽量化した。111kbyteから70kbyteに、40kbyteの軽量化。これだけ空けばアプリも十分書けるでしょう。ちょっとヤベーなーと思って軽量化した理由のひとつに、”USING TWILIO SYNC WITH MQTT ON A PARTICLE PHOTON“で使っちゃってるやん…完全にネタで作ったのにDocに入れられると、危機感を覚えてマジメになるというか何というか。twilio以外にもmathworksとかsamsung, losant, 本家のIBMに…etc だったりMQTT使って便利だぜ!!みたいなのが使われていたし、マジメに対応しなきゃなーと思っていたりはしていた。

ただ、「軽量化して!!」というリクエストは受けていて、完全スルーしていたから良い機会だし、セキュリティを考えつつ軽量化をした。Cipher Suiteは固いものが8つ。まぁ大丈夫でしょう。

■ サイズとの戦い、軽量化!!軽量化!!軽量化!!
TLSは基本(サイズ的に)大きい。普通のPCでもメモリに16Gbyteとか余裕で搭載する時代に、たった数百〜数kbyteを巡って軽量化を考えるのは地味な修行になる。

例えば、2048bitのRoot CAをアプリに内包する必要があるけど、それだけで2kbyteもの領域とメモリが強制的に消費されてしまう。さらにサーバー証明書を使うとなると、さらに2048bitのメモリの領域が消えて行く。現時点の70Kbyteのサンプルアプリだと、約3%もの領域が何もしなくてもflash領域で使われて消えてしまう…これはぶっちゃけ辛い。

例えば、無理やり方法でやってみたのが、
1.端末のEEPROMにデータを退避させておく。
2.librayrで必要なメモリの一部でEEPROM/SRAMを利用。
といった、使える領域は何でも使ってみる戦術をやってみたりした。ただ、EEPROMは回数制限があるし、あまりにも変態的な使い方になるから、正攻法で普通に実装した。

またリクエストがあれば軽量化をすると思う。もう少し頑張れば50kbyte台も行けると思うし、特定のCipher Suiteに限定すれば更に軽くすることも出来るから。

Realtime Cyber Attack Visualizer

以前、Firewallの可視化で取得したデータを使って何かやりたいなーと思っていて、こんなのを作っていた。


Unityで作ったもので、普通の一般な人達に地球上を飛び回っている軌跡とParticleってなーに?と思わせて、実は「あれは東京にあるサーバへのサイバー攻撃が各国から来て、世界中を攻撃データが飛び回っているんだよ。」という可視化の一巻で。

■ なぜ世界中をデータが飛び回るのか?
イギリスに居る人から、日本に向かってデータが来るとき、そのデータは光ケーブルを辿って来る訳だけど、「イギリス->東京」と直接くることは無い。例えるなら、郵便物を送る時に、「手元 -> ポスト -> 郵便局 -> 配送 -> 郵便局 -> 配達員さん -> ポスト -> 相手の手元」といった感じで、色んな場所を経由して届く感じに似ている。

今、このblogを見ている文字や写真、youtubeのデータさえも直接見れているという訳ではなく、色んな所を経由して来ている。その経路はtracerouteという物で辿れて(正確には経路はA->B、B->Aという相互で同一の経路になるとは限らないため、あくまでも経路の確認用。行きと帰りで違う道を通って行くのに似ている)、そのデータを利用している。

分かりやすく見てみたのがこちらにまとめて置いた物。これは全て「インド->日本」への経路を引いた物。

こちらはopenFrameworksを利用して昔作った物。貯めていたデータを全て表示すると、地球上をデータが覆い尽くすような感じになる。

動画で見ると糸で覆われていくような。


いま見ている画面や動画は、直接誰かとやりとりしている訳じゃなく、世界中を駆け巡って来ている。世界中に引かれた光ファイバーや、目に見えない無線で相手との距離感は一瞬に感じられるけど。

■ もう少しネットのデータを見て見たい…
PCやネット上のデータは2進数(0と1)だけでやりとりされている。実際は16進数で見たりする事は多いけど。

そこでスマホでQRコードを読み込んでアクセスするとWebサーバにアクセスして、そこでアクセスしたデータを2進数で表示して、プリントアウト->利用者に渡す物を作って、2016年のインターネット闇市で配って来た。表示されているのは、IPアドレスとUser-Agentというごく一部のデータを0と1で。この0と1、もしくは16進数だけでアクセスしたデータを使って何か表現して使ってみるのは何気に面白いかも。

「これだけの0と1という膨大な量がコンピュータで処理されている」という実感は自分でも全く無い。もはや人力では不可能な膨大な量を、気づかないうちにコンピュータやネットワークが処理している。その0/1を紙に出して見ると凄まじい量で、普通に驚きだった。

Maker Faire Bay Area|Tokyo 2017

最近はblogを書くペースも落ちてきているけど、久しぶりに。

まずは、Maker Faire Bay Area 2017(Google Photoのアルバム、自由に見てOKです)はこんな感じでした。

New photo by Hirotaka Niisato / Google Photos

初日に寺崎さんに連れて行って頂いた、Computer History Museumの写真が最初に。ここはかなりテンションが上がる場所でした。これはCray3…何か生き物のような配線。断線したらメンテ不能な気もする凄さがある。

New photo by Hirotaka Niisato / Google Photos

Maker Faireは初のダークエリアで、この”3″のエリア。itogさん、菊池さんにご協力頂いた。ちなみに会場全体の広さは感覚的にはビックサイトの敷地全てくらいな感じ。やたら広いですね。来場者数は12.5万人だったとのこと。

言葉での説明は不要っす。どんな感じだったのか…Google Photoのアルバムを共有しておく。

Maker Faire Bay Area 2017 / Google Photos

プロジェクタ物(前日に投影物が作りたくなってサクッと作った)とWiFiを内蔵してリモート制御できるフラフープとPETS、開発中の物、そしてitogさんの現場で制作物でした。

New photo by Hirotaka Niisato / Google Photos
New video by Hirotaka Niisato / Google Photos
New photo by Hirotaka Niisato / Google Photos
New video by Hirotaka Niisato / Google Photos

(ベリーダンサーのお姉さんがお気に入ったようで、売ってと言われたり)

プロジェクタ物のウケがやたらと良かった。プロジェクタ物は遠くからも見えるから、そこで人を呼んで近くはフラフープとPETSとメガネでワーキャーと。凄い人の量でした。いままで屋外、屋内、寂れたエリア…と各所でやってきたですが、最上級の人の量でした。途切れない人、投影物の前で手を上げてワーキャー、チビッコ沢山、気付くとフラフープがどこかに行っていたり、あまりの衝撃で壊れたり、とにかく凄まじい人の量でした。多分、ダークエリアはここだけだから来場者が全員来ていたものと思われ。

他ダークエリアの展示物はこんな感じ

New photo by Hirotaka Niisato / Google Photos
New video by Hirotaka Niisato / Google Photos
New photo by Hirotaka Niisato / Google Photos
New video by Hirotaka Niisato / Google Photos

楽しかったのが、寺崎さんに凄くお世話になって、Airbnbで一軒家を借りて皆んなで会期中に過ごしたのが、合宿感があってむちゃくちゃ良い感じでした。

New photo by Hirotaka Niisato / Google Photos
New photo by Hirotaka Niisato / Google Photos
New photo by Hirotaka Niisato / Google Photos

———————-
そして、Maker Faire Tokyo 2017(Google Photoのアルバム、自由に見てOKです)

こちらはこんな感じ。はい…Bay Areaとほぼ一緒です!! フラフープは破壊された物を修復してブラッシュアップしたり微調整をしたり。

New photo by Hirotaka Niisato / Google Photos

付け加えたのはCDタワー

日本でも回るフラフープ

New photo by Hirotaka Niisato / Google Photos

ちょっとダークエリアのスペースが狭かったのもあって、周りに気を使いながらブルンブルンと。あとはスピーチをしてきたりでした。

面白かったのが初めて触ったtoio。むちゃくちゃ良かったでした。

New video by Hirotaka Niisato / Google Photos

ヒゲキタさんの3D影絵。秀逸でした。

New photo by Hirotaka Niisato / Google Photos

あと、ダークエリアをよくぞ発見(奥のまさに壁!!にあるドアを開くと…って感じw)してもらって、色んな人に来て頂いて、あと店番をやって頂いてありがとーございました。気づいたら展示物が持ち寄った物で増えていて、カオス感満載でとても良い感じでした。

LTE端末でIPv6

ついにIPv6がやってくる。

国内スマホユーザーを“IPv6デフォルト化”する計画が明らかに、携帯キャリア大手3社が2017年夏ごろ対応開始

というニュースが前に出ていて、どーせいつものヤルヤルでやらないんだべ…ヲレ知ってるもん。と思っていたら…

インターネットプロトコル IPv6対応について
Xi契約で、2017年夏モデル以降の対象機種はIPv6化!! しかも…

2017年夏モデル以降は原則、対応機種であれば、デフォルトでIPv6通信を利用する設定となっています。

マジでデフォでIPv6キタ━━━━(゚∀゚)━━━━!!
ってことで…もう暑いし夏っぽい気もするし、IPv6使えるんぢゃね?と思ってやってみたら、凄いっす…マジでIPv6降臨してくる。

■ iPhone
放置していたら、IPv6が降ってきていた。

■ Android
docomoの設定方法の通り、SPモードの設定をすると降ってくる。

Androidの場合は既存端末は設定が必要だけど、iPhone大国日本(w)だとデフォでみんなのスマホがIPv6化されているという流れが予想される。つまり…特に何も気にしなくてもIPv6を利用している、といった状態になるでしょー。
既にGoogle、Twitter、Akamai、Facebook…etcとか海外のサービスは、IPv6で利用できる。YoutubeとかはIPv6&QUICで動いていたりする。

■ IPv6デフォになった時の利点
国内の大抵のサービスはIPv4のみだったり、IPv6を振らないで運用していると思うけど、IPv6のアクセスがIPv4に比べて、結果的に相対的に早くなる。まず、環境的にはこんな感じ(IPv6グローバルを晒すけど、マスクするの面倒くさいし、まぁ良いっかwって感じ)

– 端末 : docomo SPモード(普通のSIM)、iPhone7 Plus、IPv4/v6が降ってきている、こんな感じね。

– サーバ: テスト用サーバ
同じサーバで適当に取っていたドメインを利用
domain : techgeeek.tokyo(ipv4のみ), www.techgeek.tokyo(ipv4/v6)
IPv4 : 150.95.155.109
IPv6 : 2400:8500:1302:829:150:95:155:109

この時、IPv4、IPv6でテスト用サーバにHTTP:80で接続するとき、最初のHTTP GETが端末から発行されるまでの時間をチェックする。

IPv4の時、first HTTP GET : 1.012014sec

IPv6の時、first HTTP GET : 1.003130sec

IPv6の方が、8.8msec早い。何度かやって平均を見てみると分かると思うけど、測定している時の端末やNW状況にも依存するものの、〜20msecほどIPv6の方が早かった。DNS応答の場合に依っては1秒超えることも。この原因の元になるのは、
大抵のOS(iPhone, Linux系、Win系)はIPv6のDNS問い合わせを優先する。
このことに起因している。

IPv4の接続シーケンスを図で見てみると…

AAAAも問い合わせるけど、Aレコードが戻ってきてTCP(SYN)で接続が行われる。他方…IPv6の場合は、Aレコード(IPv4)側が戻ってこなくても、最初に問い合わせたIPv6のAAAAを利用して、すぐさまTCP(SYN)が飛んでいる。まぁ、最初にAAAAの名前解決をしに行っているから当然と言えば、当然だけど。

つまり…IPv4/v6 Dualでスマホから接続しに行く時、IPv6の方が早く接続されるという流れになる。

■ 通信速度の利・欠点
サーバ側がIPv6も持っていると、端末からのアクセスが早くなる。地味にx0msecの差は大きい。
つまりIPv4のみの場合、IPv6に比べて遅くなる。現時点で、IPv4のみのNW、スマホもIPv4のみが多いから、IPv6 Globalを降っても何も変わらないけど、スマホがIPv4/v6 Dualになると顕在化する。例えば、広告や大量配信しているシステムやゲーム、数msecでも早くデータを渡したい!!といった所だと、この差がジワリと現れてくる。

「DNSが一旦解決されてキャッシュされれば問題ないべ?」とか優先度を変えればいいじゃん、と思うかも知れない…けど、残念な事にIPv4のみの場合、最初に何故かIPv6 AAAAレコードを問い合わせてから無かったら、IPv4側で接続しに行くというのが発動する(iPhoneで。常時では無いけど)。つまり…キャッシュされていてもIPv6側を問い合わせてから、IPv4側のキャッシュを使って接続する…という、IPv4に対する嫌がらせ(www)としか思えない動きが発生する。そもそも、DNSで設定していないにも関わらず。

(1行目、既にv4のアドレスを解決しているにも関わらず、AAAAを問い合わせる。)

まぁ、あれっすよ…GoogleのIPv6テストページを見て見るとヲレ未来に来ている感(w)で満足しちゃいそう。だけど、このIPv4のみで運用した場合に発生する、アクセス遅延について、IPv6を渋っている上司やら管理者を説得する材料とかでどぞ、「v4のまま、遅いアクセスを許容するんですね!!」って感じで。

まぁ…スマホ側がIPv4/v6のどちらも使えるのに、システム・サーバ側がIPv4だけ!!とか、もう意味ワカランというかカオス感はするけどねw 徐々にIPv6が使われますよーに:)

iOS 11 – AVDepthData camera test

Apple release new API AVDepthData(A container for per-pixel distance or disparity information captured by compatible camera devices.) on iOS11 beta, it can use on iPhone 7 dual camera now.

– DepthCamera image.
full body.1

full.body.2

left hand

– chair
RGB

DepthData

– ramen
RGB

DepthData

– box on chair
RGB

DepthData

– 3 box on texture sheet
RGB

DepthData

– on my desk
RGB

DepthData

– Japanese traditional armor
RGB

DepthData

– simple passage
RGB

DepthData

– on my desk
RGB

DepthData

– windshield
RGB

DepthData

– checker board on wood table
RGB

DepthData

– box&can on checker board(wood table)
RGB

DepthData

– box&can on wood table
RGB

DepthData

– box&can on white table
RGB

DepthData

– box&can on checker board(white table)
RGB

DepthData

– checker board on white table
RGB

DepthData

– white table
RGB

DepthData

– outside
RGB

DepthData

– outside
RGB

DepthData

– bamboo
RGB

DepthData

– rose
RGB

DepthData

– hydrangea
RGB

Depth