そういや行ってきたの書いてなかったな…と思って残しておくことに。
写真類は Maker Faire Bay Area 2019 に残して公開してあるからご自由にどうぞです。

まず…SSSSをゲットした。初めてのSSSS、大量に積み込んだハンドスピナーが影響したのだろうかw
とは言っても登場する前にダブルチェックがある位で、まぁ大したことは無かったし、国内でのフライトでも特に何を言われることも無かった。まぁ…キャリーケースの中を開けても、大量のハンドスピナーと分解されたギターが入っている位で、開けたら別の意味でビックリだっただろう。

持っていった物は大量のハンドスピナーとギター。去年のMaker Faire Tokyo、Kyotoと同じ構成で。反応はどこの国でも一緒っすね。辛かったのが、去年全部配って無くなってしまったから、今回も100個全部揃えることになった。協力してくれた皆さんあざーっした!!

会場はやたら広く感じた。出展者が少なくなったのか何なのか、通路が広い(気がする)。今年で最後というのが、ジワジワと感じるものがあった。そして出展者の多くを困らせたと思うのが、凄まじいほどの雨だった。まさに土砂降りで、雰囲気的にもつらみ。屋外の人たちは残念としか言いようがない。屋外の人たちが室内に来た分、屋内展示の方は凄まじいほどの人だったと思う。

超巨大な物はお約束的に沢山あった。光る・デカイ・火を吹く、というのは定番みたいな感じかな。

巨大なクマの中は幻想的な雰囲気

紹介しきれないほど、沢山の作品があった。写真類は Maker Faire Bay Area 2019 に残して公開してあるからご自由にどうぞです。なんじゃこりゃ？みたいなのが沢山あった面白い。そして、今年もパエリアパーティでビールを大量に飲んできた。

晴れた時に練り歩いていた。ドコドコ良い感じね。

今年でBay Areaは終わりなのかどうか、2020年もあるのかしら…雰囲気は今年で終わりか…って感じはモリモリだった。
難しいと思うのが定性的な「感動や面白い!!」ことの数値化・定量化〜お金に還元することなのかなと。個人的には文化と社会の成熟は未発達な所から、商業主義に向かって(作る・売る・仕事をするだけ儲かる)、次は精神的な部分(感動や体験、一見するとお金にならない物に価値が付く)で回って発展していくと思っている。それだけに、本当に終わってしまうなら少し残念でもある。

偶然に撮った一枚。雨上がりの芝生で、紙飛行機(世界チャンプのだと思われ)を飛ばしていたチビッコがなんか印象的になった。将来なんか面白いのでも作ってくれたらなーって思ったりもするし、出展者の一人として楽しんで貰えたらなによりかなと。
“雨降って地固まる”って言葉もあるからね。

メインの開発で使っているWindows10が修理に行くことになって、その間に開発が出来なくなるのはつらすぎる….ということで、Macbook Pro 2011を再生させることにした。

でかいのがMacbook Pro 2011モデル。3台貰ったんだけど、どれも訳アリな感じで。
1. そもそも起動しない…
2. バッテリーが膨張してヤバい…当然起動しない。
という、そもそも動かないMacbookを再生させることにした。

というのも、一応、Corei7でメモリも8Gbyte(増強して16Gbyte)もあれば十分開発用途としても使える。とりあえずSSDに換装して、バッテリーを入れ替えれば動くんじゃ？という安直な感じだけど、やってみることにした。
ただ問題点としては、High Sierraまでしか対応していない。無理やりMojaveにも出来るといえば出来るけど、一応はHigh Sierraまではアップデートした。

結果的には3台全部復活!!サクサク動いてめちゃ良い感じになった。捨てるMacbook Pro・ゴミと思われる物でも復活できる。

1.SSDに換装

何はともあれSSDに換装しよう。チョイスしたのはこの2つ。

視点は非常にイージーで安いSSD。どうせ元々死んでいたMacbookだし、256Gbyte前後もあれば十分だろうということで。OSとアプリ周辺、諸々整備して200Gbyte以上は使える領域で残るはずだし、3〜4000円のSSDを使うことにした。

2個ともHDに換装させてあげる。ちなみに、このバージョンのMacbook ProはSATA2までだから、SSDのSATA3の爆速パワーは体感出来ない。まあ、それでもHDより数倍早いから、起動も一瞬・アプリの動作・開発も普通にできている。

どちらもSATA2で使うことになっているから、Macbookから使っている時の性能は変わらない。もともと、どっちのSSDもSATA3だからね。

2. バッテリー交換

次にパンパンに膨らんだバッテリーを交換することに。ゲットしたバッテリーはこちら。

本当にこれで大丈夫か？と思ってゲットしてみたんだけど、いまの所は発熱も何もなくて普通に使えている。自分は専用のドライバは持っているから別に要らなかったけど、ドライバも2本付属してきて、特殊ネジ用のドライバを持っていない人でもこれは良いんじゃないかと思われ。

3.OS再インストール

ここまでやって気づいたことが。MacOSの再インストールどうしよう？ということだった。まずは[option] + [command] + P + RでNVRAMをリセットして再起動、WiFiに接続して最初からインストールで見事に復帰。High Sierraまでしか進化出来なかったけど、十分使えるマシンになったから大満足

I made the LED Fretless guitar for just my fun, but I want to MAKE something custom reconstruction . Now, here is my fretless guitar spec
– stratocaster type led guitar
– MCU : Particle Argon/XENON
– LED : WS2812Bx10
– Sensor : MPU-6050

I thought automatic picking guitar application is funny idea, so I tried to make the picking machine with my solenoid. Then I removed the ham pickup and manufactured the aluminum plate into an L shape, fixed it with solenoid, and embedded it in the guitar body.

Hm…subtle…verrrry subtle. And it’s need to think about the solenoid power supply, I thought that adding battery into guitar is ugly. And I remembered Paul Gilbert’s guitar playing.

Yes!! Drill!! Play the guitar using the drill(pick attached to the tip of the drill) is great idea. Paul Gilbert, you are so great!! He made the how to use the drill with guitar!!

And I decided to include the motor with pick to the guitar. Then I removed the front ham pickup and I manufactured the aluminum plate into an L shape, fixed it both sides of the motor. Guitar pick fixed to the motor axis.

Here is new guitar spec,
– stratocaster type led guitar
– MCU : Particle XENON
– LED : WS2812Bx10
– Sensor : MPU-6050
– Motor : FA-130R
– Motor Driver : TB6612FNG Dual Motor Driver

2 motors connect to motor driver through backside of pickup, motor driver include to space of the volume toggle. Motor pick machine attack to 1, 2, 5, 6 strings. The bass sound and treble is easy to play fast with motor power.
Drill motor start up with button on the pick guard it have a two mode. Picking while the pressing the button mode and picking for fixed time mode.
First of all, let’s play.

And when the button is pressed and drill is working, the LED will set to rainbow color. I think this guitar have a two playing pattern.
1. Pressed the button with one hand(right-side), other hand(left-side) play the strings.
2. Press the button just a one time motor work fixed time, while that time play the guitar normally(very fast picking with drill).
Adjust the strings height, it play with the drill working where you pressed the strings.

This guitar could play everybody!!

This guitar can use Bluetooth/6LoWPAN with XEON, LED and Drill can work from internet or other PC, cell phone. Yes, this guitar have a remote play mode.

Fret-less guitar original sound, fast playing the guitar with drill are this guitar special set. I will use this guitar for one fo the sound make.

RISC-V用のQEMUが公開されていて使ってみることにする。QEMU/LLVMともに開発速度が猛烈に早いから、このビルド方法は”現時点”でのビルド方法になる。 またビルドにはEC2 t3.2xlarge(8vCPU/32Gmem/30GSSD/Ubuntu 18.04)を使ってみた。1時間使っても40円弱、めちゃくちゃ安い。 自分のPC(VirtualBox: 2vCPU/4Gmem)でビルドをすると、この辺のはいつになっても終わらないから、クラウド上でビルドしてローカルに持ってくればそれでOK。サクサク時間の節約にもなる。以下、手順を踏んでトータルで1時間もあればビルドが終わって確認できるはず(多分)。

# 必要な物をざっくりインストール
sudo apt-get install gcc libc6-dev pkg-config bridge-utils uml-utilities zlib1g-dev libglib2.0-dev autoconf automake libtool libsdl1.2-dev libpixman-1-dev cmake

# qemu build
# 4.1系を使う必要あり、4.0系だとこれにハマる。
# https://github.com/sifive/freedom-e-sdk/issues/260
# 4.1.0-rc0だとパッチがかかっている。
wget https://download.qemu.org/qemu-4.1.0-rc0.tar.xz
tar xvJf qemu-4.1.0-rc0.tar.xz
cd qemu-4.1.0-rc0
./configure --target-list=riscv64-softmmu,riscv32-softmmu,riscv64-linux-user,riscv32-linux-user
make -j$(nproc)
sudo make install

次にPlatformIOを使ってqemu向けベアメタル用のelfを作る。hifive1ボードをターゲットにしてサクッとビルドするだけ。それにしてもpioはこの手の組込み向けだと最強というか、VScodeは何でも出来てしまうヤバさがステキすぎる。ちなみに、みんな大好きSiPEED向けのボードも既にpioに入っていて、kendryte210 SDKでのビルドも作れる。

これで出来たfirmware.elfをEC2側に送ってqemuですぐ動かすことが出来る。
次に折角なのでLLVMのビルドも作っておく。これは以下の手順通りsifive(hifive1)の手順があって、toolchain/llvmの手順通り流すとビルドが終わる。
https://github.com/sifive/riscv-llvm

以上で物が揃って、全部qemu risc-vエミュ上でサクッと動かせる。あとはこんな感じで。
　

qemu-system-riscv32 -nographic -machine sifive_e -kernel firmware.elf 
qemu-riscv32 hello

これで一通り、gnu-toolchain/llvm/qemu上での動作が確認できる。よくあるFedora RISC-Vも普通に動く感じ。次はQEMUのRISC-V命令セット部分をいじっていこう。

最近、機械学習でsciket-learnを色々と使っていたりで、なんとなく動画をPCA次元削減して遊んでみた。元々はPCAを行ったあとにk-meansでカテゴライズをしたりする時に使ったりする訳だけど、画像を次元削減して見てみると面白いフィルターとして使えそうな。
動画は元々はMaker Faire Bay Areaで撮った1920×1080のmp4ファイルをJPEGで取り出して、ちょっと大きいから半分にサイズを減らした後、10(右下), 60(左下), 120(右上), 240(左上)次元削減している。次元が少ない方が面白い感じに。動画から切り出した写真で10・240次元削減した物はこんな感じになる。

• 

• 

ソースコードはこんな感じ。とっても簡単。PCAのモデルは処理が終わったら保存しておいて、別途回せるように保存している。

import cv2
from PIL import Image
import numpy as np
import pickle
from sklearn.decomposition import PCA

# 動画の読み込み
cap = cv2.VideoCapture("movie.mp4")
dataset = []

while(cap.isOpened()):
    ret, img = cap.read()
    
    if ret == True:
        # CV2ImageをPILImageに変換
        img = img[:, :, ::-1].copy()
        img = Image.fromarray(img).resize((int(960), int(540)), Image.BICUBIC)
        
        # (540, 960, 3)配列にして１次元にする
        img = np.asarray(img)
        img = img.reshape(1, img.shape[0] * img.shape[1] * img.shape[2])
        dataset.append(img[0])
    else:
        break

# PCA実行
pca = PCA(n_components=10)
pca.fit(np.array(dataset).astype(np.float64))

# モデルを保存しとく(後で使うとき用)
with open('pca.pickle', mode='wb') as fp:
    pickle.dump(pca, fp)

# 動画を作成
fourcc = cv2.VideoWriter_fourcc('m','p','4','v')
video = cv2.VideoWriter('result.mp4', fourcc, 30.0, (960, 540))

for img in dataset:
    # PCAして動画に突っ込む
    transformed = pca.transform([img])
    pilImg = Image.fromarray(255 - (transformed.dot(pca.components_).reshape([540, 960, 3])).astype(np.uint8))
    cv2Img = np.asarray(pilImg)
    video.write(cv2Img)

video.release()

画像を色々と集めてきてPCAをかけたモデルを保存して、思わずJamiroquaiのVirtual Insanityの動画をmp4で取得してきてPCAをかけた。なんとなく最初に浮かんだのがJamiroquaiだったからで、特に深い意味は無いけど。

• 

• 

• 

面白いフィルターとして使えそうな気がちょっぴりしていたり。RGB成分をそれぞれ分離して、それぞれの成分毎に圧縮して掛け合わせてみても面白いかも。

ポジションマーカーにneopixel(ws2812b)フルカラーLEDを搭載して、MPU6050(加速度・ジャイロ)をギターのボディに搭載、Particle Argon(ESP32/nRF52)でThread Mesh(IPv6/Bluetooth) Gatewayになるギターを作成した。

もちろんシールドからアンプを通すと音は鳴る。ネタ的にやってみたかったHD、アンプ＆オーバードライブ回路付きのスピーカーに接続して音を出してみた。

フレットレスギターを作って弾いてみて分かった事は、自分がどれだけフレットに依存してギターを弾いてきたのか（というか、そういう楽器なのだけど）ということだった。押さえる所が少し変わるだけで、音が凄まじく変わる。すぐ弾けるか？というと、練習が必要になってきた。良い点としては、中間の音を出せるようになった。例えば、C, C#の間の音も簡単に出せる。スライドさせると面白い音が出るから、ワウと組合わせて使うと楽しくなりそう。スライドを多用して弾くことになりそうな気がしている。

という事で、このギターの作りかたを残しておく。ちなみに、ギターを分解してここまで改造するのは自分は初めてだ。

1．ギターを分解する

まずはギターを分解する。自分は何本かギターを持っている。それらの1本を使って…というのはあまりにもチャレンジングすぎるから、ヤフオクで2,500円のギターを1本入手した。昔は持っていたストラトの形状のギターだ。ストラトタイプというのが後々に電池(LiPo)を格納する場所で利点を発揮する、というのはこの時はまだ気づいていなかった。まずはネジ類を取ってギターを分解する。

２．フレットレス化

最初の目標通りフレットレスギター化をする。フレットをペンチを使って指板から全部抜いてしまう。

次に抜いたフレットの溝をエキポシ樹脂で埋めていく。エキポシはキャンドゥーで何個かゲットしてきた。マスキングテープでネック部分に付かないように保護してから行った。塗りたくったら24時間放置して固まるのを待つ。

エキポシが固まったら、ひたすらヤスリをかけてエキポシの凹凸が無くなるように磨く。ヤスリも100均でゲットした紙やすり(60, 120, 240)を使った。仕上げにスポンジヤスリ(240番)を使って、良い感じに滑らかにする。

これでフレットレス化は完了で、さらにエキポシを指板に塗って、弦高調整でヤスリを再度かけるとフレットレスギターとして使えるようになる。ここで、指板にLEDを仕込んでは？という甘い誘惑に乗って、ここから指板分離という作業にとりかかることにした。未知の作業ほど楽しいものは無い。

３．指板分離とネックのLED化

まず最初に沸いた疑問は、指板ってそもそもネックから取れるの？という事だった。シリコンラバーヒーターを使って指板とネックの接着剤に熱を与えて、上手い具合に少しづつ分離できるような事は書いてあったりした。ただ、シリコンヒーターを持っていないため、スチームアイロンを使うことにした。布をネックの上において、その上から蒸気と熱をバンバン与えていく。本当は金属ヘラを使ってネックと指板を少しづつ分離していくようだけど、この時は金属ヘラが無かったから包丁を指板とネックの間に差し込んでみたら、少しづつ分離することができた。

ネックに包丁が突き刺さっているのは、あまりにも作業としても危険でシュールすぎるから、指板の分離が出来ることをここでは確認して、金属ヘラをダイソーで入手して作業を続けることに。指板が割れてしまわないよう、慎重に少しづつ分離した。

幅広と細い物の2本の金属ヘラとスチームアイロンを使って、少しづつ接着材を溶かして指板とネックの分離をすることが出来た。当然だけど包丁を使うより、金属ヘラを使う方が遥かに効率が良かった。

次にポジションマーカーの部分をLEDで光らせるため、ドリルでポジションマーカーに穴を開けていく。指板にドリルを当てるというのは、なかなか緊張する。ドリルは細いのから太いのまで順番に交換しながら、指板に穴を開けていく。

ポジションマーカーに穴が開いたら、動作確認としてLEDをポジションマーカーの裏から光らせてみて、期待通りに光るかどうかを確認した。良い感じに光りそうでちょっとここで一安心。

次はLEDを仕込んで固定・導線の経路の確保をする。neopixelことws2812bは指板のポジションマーカーの部分に仕込むことにした。そして導線はトラスロッドの部分を利用することが出来る。テープLEDの幅とトラスロッドの溝が良い感じに合致するという幸運を利用するとにした。

そして、LEDは多少高さがあるから、ポジションマーカーの部分(指板の後ろ側)をLEDのサイズに合わせて彫刻刀とヤスリを使って調整する。この時、指板とネックをクランプする次の作業を考えていて、LEDがクランプの圧力や弾いている時にダメージを受けないよう、良い感じにポジションマーカーに収まるよう意識して調整していった。

導線の確保は12フレット以外はそのままトラスロッドが使えるものの、12フレット部分はポジションマーカーが上下にあるため、ネックの12フレットの部分にLEDと導線を確保するための溝を入れてあげた。

いよいよLEDを装着する。テープLEDを1個づつ切り取って、ポジションマーカーの部分に合わせて導線をつないでいく。あと、トラスロッドには絶縁テープを貼っておく。LEDと導線は指板に超強力両面テープ(3Mとかの)で固定してあげた。指板とネックを合わせた時に圧力や弾いている時の衝撃でLEDが壊れてしまわないよう、この辺は地味に注意をしつつ行った。というのも、ネックと指板を接着してしまうと、LEDや導線はもう二度と手を入れられない部分になるから、自分が弾いたりギターを扱う時の衝撃を想定して作業をした。

指板とネックを接着するまえに、ポジションマーカーを作成していく。元々あったポジションマーカーはドリルで見事に貫通させちゃったから、東急ハンズで5mm アクリル棒をゲットしてきてポジションマーカーとして利用することにした。良い感じの長さで切り取ったらポジションマーカーに入れて、指板を傷めないようにヤスリで綺麗に高さを調整した。

この時、弦を指で押さえた時の衝撃で、アクリルからLEDに衝撃が加わってLEDが破損される事が考えられた。エキポシで指板を再度コーティングして保護するとしても、押弦した時の繰り返し衝撃にLEDは間違いなく耐えることが出来ないと思っていて、これを解決しないといけない課題の一つだと考えていた。

最初はポジションマーカーの中をグルーで埋めて緩衝にさせて、その上からアクリルをはめ込もうか…と考えた。ただ、幸運なことにアクリルを差し込んでみて分かったのが、ドリルで開けた指板表面ポジションマーカーの径が広く、指板裏のLED側の径が狭くなっていた。つまり、どんなにポジションマーカーを押し込んでもLEDまでアクリルが到達しない、ろうと状の構造に全ポジションマーカーがなっていた。という事で、安心して全ポジションマーカーにアクリル棒を切ってバンバン埋めていく。（ろうと状の構造になっていなかったら、グルーでLED保護の緩衝を流し込んで、その上からアクリル棒の外面に接着剤を塗ってポジションマーカーとしてはめ込んだと思う。なるべくLEDに衝撃が伝わらないように。）

ここまで出来たら、LEDの点灯確認をする。次はいよいよ、指板とネックの接着になる。接着したら、もう二度とLEDや導線に手を出すことが出来なくなる。失敗したら、また指板分離すれば良いのかもだけど、もう分離しないぜ！！といった気持ちで接着をすることにする。

教えてもらった、楽器とかで利用される木工用で強力なタイトボンドを指板・ネックに塗りたくって、あて木をしてからクランプする。この時が最高にドキドキする時だった。LED・導線が圧力で壊れてしまったら、ここまでの努力が水の泡に。色々と気を使った事を信じて、思いっきりクランプして1日放置した。

1日クランプしたまま放置して、ドキドキのLED点灯の瞬間…見事に全部OKだった。ほんと、心からほっと一安心した瞬間だった。ネックのLED部分が出来ればもう安心だ。

そして、次はまた指板の保護としてマスキングテープでネック部分を保護して、全体にエキポシを塗りたくって1日放置する。フレットレスだから弦で指板にダメージが発生するのと、弦高調整、弾くときにスライドが滑らかになる効果、押弦した時に弦の振動を木よりも固いエキポシの方が良いだろう、という色々な効果を期待して塗りたくった。1日放置して紙やすりでエキポシをひたすら磨いていく。

次にボディ側に導線を確保するためにドリルで穴をあけた。ギターのボディに直接ドリルを入れるのは何気にドキドキする。LEDの導線をネックのジョイント部にドリルで開けた穴を通じて、ボディの中に引き込んでいく。LEDの制御はボディのどこかの空間でやればOKだろう、くらいの感じで考えていた。

ちなみに、このネックのジョイント部にあるドリルの”ためらい傷”のような大量の穴の痕跡は自分がやった物ではない。最初からついていたもので、この大量のためらい傷は一体何なんだろう…？

何はともあれ、まずはネックから出ている導線部分を樹脂で保護することに。この部分は弾いている時に圧力がメチャクチャかかる部分で、何か不測の圧がかかって断線しないように、とりあえず導線部分をかるくグルーで保護してあげた。そして、ネックとボディをジョイントするときに導線がダメージをうけないよう、ボディにドリルで開ける穴と導線の位置をよく確かめてから、ドリルで導線用の穴を確保した。

ネックとジョイントさせてLEDの動作確認をして問題が無いことを確認。あと使い捨ての弦(1セット270円をゲットしていた)を張って、実際にテンションをかけても問題なく動作する事の確認をした。ネックにテンションがかかった時に何かあるかもしれない…というドキドキ感があった。

あと、ここで指板に塗りたくったエキポシをヤスリで磨いて、弦高調整をした。 ちゃんと各ポジションで音が響くように ナットを少し溝切をして、サドルを調整しつつ、指板(エキポシ)を磨いていくことに。何気にこの弦高調整がメチャクチャきつかった。テンションをかけて確認しながら、緩めてエキポシを磨いて実際に音を出して…の繰り返し。

４．ボディの配線と端末格納

一通りネック側が出来たら、今度はボディの加工に移っていく。

ボディに空間を躊躇なくあけた。どこに端末を格納するための空間を用意するか考えた結果、ピックガード裏に空間を作ることにした。理由としてはピックガードで空間を隠すことが出来るから。あとネックからのLED導線をなるべく近くで終端させてあげたかったから。ちなみにボディの鳴りという部分はとっくに諦めている。

マーカーでサイズを決めたら彫刻刀でひたすら掘っていく。何気に大変だったのが、ボディの塗装が思ったより厚くて、最初は彫刻刀の刃が入らなかった。そこで、ドリルを何か所かあてて塗装と表面の樹脂を取ってから、ボディの木材を彫刻刀で穴をあけていった。ボディの鳴りという部分は、この塗装・樹脂・木材が一体となって効いてくるというのを実感した瞬間だった。

一通り空間が出来たら、空間にエキポシを塗りたくって、木材の表面をコーティングした。

最後に端末を格納していく。ここで利用したのは端末にはParticle Argon(ESP 32/nRF52)とMPU 6050(加速度・ジャイロ)センサーになる。格納する空間がわりと広いから、他の端末やセンサーを入れてこれからも遊ぶことが出来るようになっている。他にもギターがThread(6LoWPAN, IPv6/Bluetooth)のGatewayとしても利用できるネットワーク端末にもなる。

端末自体はWeb上でプログラミングをしてWiFi経由でアプリを流し込めるから、ピックガードを閉じた後でもLEDの光り方やセンサーの扱い方をリモートで変更することも出来るようになっている。加速度・ジャイロでギターの動きや弦の振動からLEDの点灯制御をしてみたけど、プログラミングがリモートで色々と変えられるという便利さもあって、他にも色々と遊んでいけそうだ。

電源はトレモロユニットの部分に格納することにした。当初はボディに開けた空間に端末と一緒に格納しようと思ったものの、電池交換するため「弦を外してピックガードを外す」のはさすがにムリがある。

そこで、ボリュームからボディ裏のトレモロユニットに抜けているアース線の穴を利用することにした。端末を格納している空間からボリュームやトーンのある空間にドリルで穴をあけて、そこからアース線と同様にトレモロユニット側に電源を通していく。LiPoはマジックテープでボディと合わせて固定する。これで、LiPoの交換は裏カバーを外していつでも出来るようになった。耐衝撃性もそれほど悪くないだろう…

とりあえず完成。ちゃんとアンプを通して音を出して爆音で弾くことも出来る。 まとめ的に、やってみて分かった事とかは…

・ギターのクラフトマン凄い。自分は”とりあえずやってみた”だけど、こんな自分の作業の比較じゃないほど凄い質と量をこなしているクラフトマン、マジで凄いというのを実感した。
・フレットを外す時にナットも一緒に外して作業すれば良かった。何で外さなかったのか…
・ヘッドのロゴの所に思わずMaker Faire Bay Areaで貰ったステッカーを張ってみた。
・弦高調整で指板をヤスリかけて、エポキシを磨いて調整したけど、ハンドサンダーを最初に使って荒く磨いた方が楽だった。手でやるのマジで辛かった。ただ感覚的な所で、最後は手で磨くことになると思われ。
・ギターのネックにLEDの他にも静電容量センサでも仕込んで、弦無しで指板上を触れると音が鳴る、とかも面白いと思ったり。
・他にもセンサーを付けたり、内部にエフェクタ機能を入れても面白そう。ネックのLED化と外部電源無しに単体で遊べるから、音をいじったりもしたい感じ。

ギターの改造は一度はやってみたかったから、未知の作業や”多分、こうじゃないかなぁ…”みたいな感じでメチャクチャ面白かった。

何となくふと思い立って、土合駅に行きたくなった。急に雪を見たくなったのと、昔電車で通り過ぎたことがあって、今度は駅に降りてみたくなったからだ。 始発で向かって、電車の中ではLed Zeppelin、OASISを聞きながら寝て、スキーやスノボを持ってゲレンデに向かう人達に囲まれながら約3時間、ようやく土合駅に到着した。

降りるときに、スキーに向かう大学生たちが、「こんな駅で降りるなんて、よっぽどの物好きか何かじゃね」と言っているのが聞こえた。そんな自分は物好きなのかも知れない。ちなみに自分は鉄っちゃんでは無い。雪と非現実な駅を体験しに、まるで遊園地のアトラクションでも楽しみに行くような感覚で土合駅に降りた。

ここからひたすら460段、70m超の高低差のある階段を登っていく。400段の階段というとピンとこない。何となくサクッと登れそうな気もする。1000段とか桁が変わると、さすがに大丈夫かな？と思ったりするけど、460段だったら簡単に登れそうな気がしてくる。 そんな思いは途中で打ち砕かれて、自分の体力の無さを思い知ることになった。

ひたすら階段を登っていく。土合駅は氷点下近くですごく寒いと思って、コートにマフラーで寒さ対策をして行ったのに、登っていく間に体は温まっていく。寒さは何も感じない、むしろコートやマフラーが邪魔になるほどだ。ふと登ってきた階段を見下ろしてみた。

見下ろすと、そこに居たはずのホームが点ほどにも見えない。地下に向かって、無限ループのように続く階段と手すり、照明とトンネルがあるだけだ。何か幻覚かVRのような物でも見ているような感覚になってくる。つい数分前、この無限ループの先に自分が居たという現実が実は作られた物だったという気すらしてくる。 階段を登っていくと、ようやくゴールが見えてくる。薄暗いトンネルの中に、唯一地上から差し込んでくる光だ。

続きはまた。

Particle Meshが届いた。

オーダーしたのはArgon、Xenonが(予想外に)大量に届いた。Argonのスペックはこちら。ESP32、nRF52840が1ボードに搭載されているとう変態端末とも言える。そして同じくXenonはこちらで、nRF52840が搭載されている。
更にLTE(blox, LTE CAT M1/NB1, 2G/3G)とnRF52840が搭載されているBORONというのもあるけど、こっちはポチっていない。まぁ…LTE側はまぁ別にいいかなーと。日本もエリアに入っているし、先代のElectronも国内で使えていたみたいだから、LTEでネットワークを終端して周囲にメッシュネットワークというのも面白いと思うけどね。

■ パッケージ
大量にポチった理由はプレオーダー(人柱?)の安さだった。Argonは$15、Xenonは$9でプレオーダーは送料無料!!海外からの送料は高くなる事が多いなかで、このスペックで送料無料というのはヤバすぎる。パッケージの中身はこんな感じ。

本体とアンテナ(Argon)、ブレッドボード、白色LED、照度センサ、抵抗x2が化粧箱に入ってこの値段はヤバイ。間違いなく原価割れしているだろう…プレオーダーだからといって、こんな値付けで大丈夫なんだろうか…と心配してしまうほどだ。

■ Mesh!!
Thread/6LoWPANでのメッシュ、WiFi/LTEで終端したGatewayを通したクラウド側との疎通が最大の目玉。

こちらのコミュニティスレから。このThread Topologyをサクッとめちゃ簡単に作れる。実験してみたら、切断したノードの電源投入と共に自動でメッシュネットワークにJoinして、クラウド側からノードにアクセス出来るようになる。これは割と感動した。
このコミュスレにある通り、遠くまでメッシュでネットワークが数珠つなぎになって疎通することが出来る。まぁメッシュネットワークでどこまでも…といえば、そりゃそーなんだけど、BLEとWiFiで構築されるメッシュネットワークにクラウド側からサラっとアクセスできるというのは、混雑エリアや遠くまでとか可能性をめちゃ感じる。

■ クラウドからアクセス
左がArgon(WiFiノード)で、右がXenon(Threadノード)でLEDと付属の照度センサをつけた。

ちなみにFirmware(アプリ)はWebIDEからOTAで投入できる。クラウド(firmwareのコンパイル&ビルド)=>Internet=>WiFiノード=>Threadノード、といった感じでどこまでもOTAでアプリを投入できる＆めちゃ簡単。USB SerialからもデスクトップのIDEでアプリをブチ込めるけど、ブラウザで適当にビルドして投入できるお手軽感が良い。これはCore/Photonから続く流れなんだけど、Thread/6LoWPANを経由してもOTAでfirmwareをブチ込めるのにはわりと感動する。Maker Faire Bay Areaでデモを見せて貰ったとき、本当にThread経由でOTA出来るのかよ!?と全く信じていなかったけど、マジで普通に出来る。いままでのParticleだと、初期ロットはクソみたいな出来栄えで、まともに動くと全く思っていなかっただけに、ビックリしてしまった。

Web上ではこんな感じでターゲットになる端末にfirmwareを投入していく。Webだけじゃなく、デスクトップIDE、コマンドライン(API)を叩いてもアップロード出来る。コードは適当にこんな感じ。

int illuminance = 0;
int counter = 0;

// クラウド&APIから実行できる関数をデバイスに登録(Function機能)
bool success = Particle.function("function1", function1);
int function1(String extra) {
  Particle.publish("function/call", extra);
  return 0;
}

void setup() {
  pinMode(D2, OUTPUT);

  // クラウド&APIで取得可能な値を登録(VARIABLES機能)
  Particle.variable("illuminance", illuminance);
}

void loop() {
  counter++;
  digitalWrite(D2, HIGH);
  illuminance = analogRead(A4);

  delay(2000);

  digitalWrite(D2, LOW);

  delay(2000);
  
  // カウンター値をクラウドにPublish(Subscribeもある)
  char buff[128];
  sprintf(buff, "%d", counter);
  Particle.publish("counter/val", buff);
}

Arduinoライクにコードは書ける。この中で面白いのが、Function機能・VARIABLES機能が地味にイケていた。Publish/Subscribeは前々からあるからいつもの感じ。Particleのコンソールで端末とクラウド連携が確認できる。

ソースコードでFunctionで登録した関数がクラウド側にも登録されてWeb上から端末上の関数を叩くことが出来る。そしてVARIABLESはGlobal変数で登録しておくと、いつでも値をGETすることが出来る。EVENT LOGSにはPublishされた値が流れて出ている感じ。
つまり、端末上の関数・変数とクラウドが綺麗に結合して、どちら側からも簡単に使うことが出来るようになっている。ビビるのがWiFi/LTEのGatewayを経由して、Thread/6LoWPAN経由でエンド・ノードに対して実行可能なところで、これ普通にイケてると思われ。

■ スマホからいじる
スマホからWiFi/Bluetooth経由で設定とかもアプリから出来る。これは自分の端末一覧。Particleの歴代端末(めちゃ買ったんだ…)が登録されている。

そしてピンの活性化(DigitalRead/Write/AnalogRead/Write)もアプリからいじって、直接ピンの値をいじって遊べる。

ざっくり、端末スペック・価格が凄いというのもあるけれど、それと同じくらいクラウド側やソフトウェア面もかなり充実している感がする。あとは、自分がParticleにconotributeしているライブラリがちゃんと動くか(どーせ、また動かねーとか、機能追加しれ!!とかあるんだろうなぁ…)、メンテと検証を引き続きやらなきゃ!!って感じかな。いま見たら、使ったアプリの総数が150K超えているし。
何にしてもThread/6LoWPANでのMESHネットワークがどれくらい使えるものか、超混雑エリアや距離といった点で遊んでみたい。そして、もう少し詳しくみて、ESP32/nRF52840を直接さわって遊んだり、IPv6ネットワークを使った何か出来ないか…とか、色々と遊べるよーな気がする。

Particle Meshというデバイスが10月にいよいよ発送される。

Meshという名前のとおり、Bluetoothでメッシュネットワークを構築して、WiFi/LTEでインターネットに抜けていく。メッシュネットワークはThread(6LoWPAN: IPv6)で構成される。各端末のスペックはリンク先を見れば分かるとおり、何気にすごい。Bluetoothのみの端末Xeon、WiFi/Bluetoothで構成されるArgon、LTE/Bluetoothで構成されるBoron(2G/3G版もあり)という3種類。BluetoothはNordic nRF52840、WiFiはESP32という最近流行りの構成な感じ。そして現在のところ、最初のオーダーは送料無料で安い!!
　
　
■ ギテキというもの…
このParticle、昔はSpark CoreというArduinoコンパチ風な端末(ギテキあり)を出していて日本国内でも使えた。そして次に出してきたPhotonという端末が主力になっている。ただ、このPhotonはギテキが無いくて国内では使えない。自分はこのSpark CoreのときにMQTT ライブラリをcontributeしたせいで、次のような現象が起きている。

1. Spark Core(ギテキあり)にライブラリを公開
2. ライブラリがめちゃ使われる
3. Particle Photon(ギテキ無し)が主流になる
4. Spark Coreはほぼディスコン状態
5. ライブラリのメンテ・サポートを続ける…

ギテキ無しの端末のライブラリをメンテ・サポートを続けているという状態だ。現在のところ約12万アプリがライブラリを利用している。恐らくIoT的な側面で考えると、かなり使われている方だと思う。まぁ国内で使われなくても、世界中で使われるとそんな感じかなと。たまに、「２Gの端末で何かおかしいんだけど？」と聞かれるけど、そもそも日本には2Gは無いしデバックをお願いしていたりもする。

ここで思ったのが次のMeshだ。ギテキ無いんじゃね？みたいな(お約束)。ざっくりこんな素敵な構成が出来るのに…

コミュニティに上がっている最新情報で、実際に動いているネットワークのトポロジなんかを見るとわりと感動するものがある。国内で使えるよう、どこか持ってきてくれないかしら…まぁ、自分は10個ほどプレオーダーしちゃってるんだけどね。どうせ、またメンテしないといけないし(白目)。

this pic from Particle community site.
　
　
■ WebからOTA、IDE環境、NodeJS、iOS/Android…etc
このParticleがイケているのが、周辺環境が恐ろしく充実しているという点もある。Web IDE上でコードを書いてWiFi経由でアプリを流し込めて、端末やライブラリの管理を行える。ログもWeb上で確認できる。これがSpark Core(2013年)時点から使えているのだけど、何気にこれが良い感じだったりする。

さらに面白いのがMQTTのようなPublish/Subscribeの環境が利用できる。正確に言うとMQTTではなく、CoAPをDTLS上で動かして実現している。このWebIDEはよくあるAzure,Google Cloud、Webhookにデータを流すように利用することができて、大抵のクラウド環境との疎通もParticle上を経由してデータのやりとりをすることが出来る。あとSIMの管理とかもあったりする。

つまり…端末をネットワークに接続すれば、あとはすべてWeb上からコードを書いて、ログを見てデバックして(もちろん、PCにUSB経由でシリアルも出力)、NodeJSやWebAPIを使って自前のシステムを作ったり、iOS/AndroidのアプリもOKと…かなり充実した環境になっている。

NodeJSはこんな感じでParticle CloudとのPub/Subをサクッと書ける。

var Particle = require('particle-api-js');
var particle = new Particle();
var token;

// データのPublish
particle.publishEvent({ name:"banjo_normal/get", data: "test val", isPrivate: false, auth: 'auth token' });

// SubscriveしたEvent情報ほ処理
particle.getEventStream({ deviceId: 'banjo_normal', auth: 'auth token' }).then(
	function(stream) {
		stream.on('event', cloudEventHandler);
	},
	function(err) {
		console.log("error starting event listener", err);
		process.exit(1);
	});

cloudEventHandler = function(data) {
	console.log("Event", data);
}

そして端末側はこんな感じ。A0からアナログデータを読んで、Publishする。コードはArduino likeに書ける(C++)。

#include "application.h"

String deviceName = "";

void subscribeHandler(const char *event, const char *data) {
    Serial.print(event);
    Serial.print(", data: ");
    if (data)
        Serial.println(data);
    else
        Serial.println("NULL");
        
    // publish sensor data to "[device_name]/put/val" endpoint
    int val = digitalRead(A0);
    char buffer[128];
    sprintf(buffer, "%d", val);
    Particle.publish(deviceName + "/put/val", buffer);

}

void namehandler(const char *topic, const char *data) {
    // get device name
    deviceName = String(data);
    Particle.unsubscribe();
    Serial.println("This device name is : " +deviceName);
    
    // subscribe devicename/data endpoint
    Particle.subscribe(deviceName + "/get", subscribeHandler);
}

void setup() {
    Serial.begin(9600);

    // get device name from cloud
    Particle.subscribe("particle/device/name", namehandler);
    Particle.publish("particle/device/name");
}

void loop() {
}

自分がcontributeしているMQTT(TLS)を使うと直接外部のクラウド(Azure, Cloud Core, IoT Core…etc)と接続して通信を行うことが出来る。逆にParticleのPub/Subはサービスとしてエレガントになっていて、端末の起動・停止といった情報をとって既に用意されているSDKを使って開発を進められることが出来る。外部との疎通はどちらを使っても大丈夫になる。

このPub/Subは現在のところ、MQTT・Particleのどちらを使おうとしてもサーバーを経由したメッセージのやりとりになる。次のMeshになるとThread(6LoWPAN)上のメッシュネットワークに閉じたメッセージングと、今までと同様のインターネット上のゲートウェイに投げるメッセージの両方が使えるようになる。
これはかなり面白い。インターネットへの疎通がなくてもメッシュネットワークを構成して、WPAN上でのメッセージングが出来る。また、自身はインターネットに接続していなくても、メッシュネットワーク経由で上位のエッジ(Argon, Boron)を経由してインターネットに抜けることが出来る。
人が多くて混雑した所での利用、大量の端末・制御を使いたいときは有効に働くと思われ。
　
　
■ ギテキ、うまいのそれ？
当初のSpark Core, Particle Photonのfirmwareは色々あって、UDPパケットを投げると端末が停止したり、メモリリーク、とあるクラスを使うとメモリフラグメント、端末の認証(priavate 証明書)を差し替えるとネットワークに接続不能になったり…いまでも謎の現象が起きたりもする。この辺はgithub上のソースコードが丸々上がっていて、自分で書き換えたりもできる。あと自分で作ったlibをcontributeして使ってもらうことも。まぁ、最初のMesh firmwareはちゃんと動かないとは思うけど、将来的な期待感がめちゃ高い。

ただ、問題はギテキ、これに尽きる…

NASAは太陽の画像データを公開している。SDO(Solar Dynamics Observatory)というサイトで、膨大なデータを公開している。これらのデータはこの辺のパスを降りていくと見ることが出来る。

例えばこんな磁力線がバンバンな写真とか、ゾクゾクしてくるものがある。

この画像データを使って動画として見たくなる…という気持ちが働いて、対象のデータを指定するとある一定日時の分だけクロールしてくるのをgolangで作った。

package main

import (
	"fmt"
	"io"
	"io/ioutil"
	"net/http"
	"os"
	"regexp"
	"strings"
	"time"
)

const baseurl string = "https://sdo.gsfc.nasa.gov/assets/img/browse/"
// 保存先
const filepath string = "/tmp/img/"

// 取ってくるファイルサイズとデータ型
const targetimg string = "512_HMI171pfss.jpg"

// 何日分とってくるか
const daycount int = 100

// 開始日時
const startday string = "2018/02/01"

func saveImg(url string, filename string) {
	response, err := http.Get(url)
	if err != nil {
		panic(err)
	}
	defer response.Body.Close()

	file, err := os.Create(filename)
	if err != nil {
		panic(err)
	}
	defer file.Close()

	io.Copy(file, response.Body)
}

func crawlurl(url string) {
	var client = http.Client{}
	req, err := http.NewRequest("GET", url, nil)
	if err != nil {
		panic(err)
	}

	resp, err := client.Do(req)
	if err != nil {
		panic(err)
	}
	defer resp.Body.Close()

	body, err := ioutil.ReadAll(resp.Body)
	if err != nil {
		panic(err)
	}

    // 対象のファイルがあるかチェック
	re := regexp.MustCompile("<a href=\"(.*?)_" + targetimg + "\".*?>")
	group := re.FindAllStringSubmatch(string(body), -1)
	for _, c := range group {
		// get target url
		fmt.Println(url + c[1] + "_" + targetimg)
		
		// save img to local
		go saveImg(url+c[1]+"_"+targetimg, filepath+"/"+strings.Replace(c[1], "_", "", 1)+".jpg")
		
		// 5 second delay
		time.Sleep(5 * time.Second)
	}
}

func main() {
	for i := 0; i < daycount; i++ {
		t, _ := time.Parse("2006/01/02", startday)
		t = t.AddDate(0, 0, i)
		crawlurl(baseurl + t.Format("2006/01/02/"))
	}
}

あまりバンバンcrawlすると迷惑になっちゃうと思うから、ちょっぴりdelayを入れておく。対象のファイルは毎日存在する訳でも決まった時間に出来るわけでも無さそうだから(ただ、ほぼ毎日8時間おき位で作られている)、directory indexから取ってくるのを見て、存在したら取ってくる感じで。画像の権利的なところはこちら。2048のサイズまで使える。ただ、大きいサイズはそれだけ容量を消費するのと動画に変換するときの負荷が高くなるから、とりあえず最小の512サイズで。golangでサラッとした処理を作るときの便利さはハンパない。

これでファイルを取得してきたら、avconvで動画に変換する。

# ファイルを連番に変更して
ls *.jpg | awk '{ printf "mv %s %03d.jpg\n", $0, NR }' | sh 
# 動画に変換
avconv  -r 10 -start_number 1 -i "%03d.jpg" solar.mp4

これで完了。mp4のファイルが出来上がる。こちらは2018年2月〜9月頭まで、約半年分のものを動画にした感じ。

Solar AIA 094/335/193

Solar AIA&HMIB