uitspitss blog

プログラミングと音楽とエッセイ ※記載内容は個人の見解であり、所属する組織とは一切関係がありません。

node.jsでScratchXとDigisparkをつなげる

今年の頭にやっていたことを振り返って、ターゲットとして初心者を想定した割に、 手順が多すぎると感じたので、node.js(electron)で手順を少なくした。
※毎度のことですが、実際にやるときは自己責任でお願いいたします。

f:id:uitspitss:20160930052102j:plain

electronでバイナリ化

最終的な形としては、これを目指していて、Windowsでもこれがやりたかった。
現時点、Macのみ対応。Windowsについては後述。
動作確認した環境は

  • OS X 10.11 (El Capitan) - 64bit
  • macOS 10.12 (Sierra) - 64bit

準備

Digispark

Digisparkには、ArduinoIDEを使って、File > Examples > DigisparkUSB > DigiBlinkの DigiBlink.inoを書き込んでおく。

libusb
  • libusbが必要になるので、パッケージマネージャーのHomebrewを入れる。
  • Homebrewを使って、libusbをインストール。 brew install libusb
app

実行

app実行時にクリップボードにURLのコピーが行われるので注意!
DigisparkをUSBに挿した状態で、中に入っているappを実行すると、以下のようなウィンドウが立ち上がる。

f:id:uitspitss:20160930051712p:plain

appを立ち上げたときに、ファイアウォールからの警告が出てきたら、「許可」「拒否」どちらかを選択で警告ウィンドウは消す。

あとは、立ち上ったウィンドウに表示されているURLにウェブブラウザ(Chrome推奨)でアクセスすると、 以下の画像のように、その他(Others)のところにDigispark用のブロックが読み込まれているはず。

f:id:uitspitss:20160930051707j:plain

この読み込まれたブロックを組み込んでプログラムを書くとその通りに動く。

Windows

Windowsでは、electronとnode-usbの相性問題でelectronがコケてしまうので、 electronを使わずにCLIで動くものも書いた。

環境

動作確認した環境は

  • Windows10
  • node.js - v6.1.0
  • npm - 3.8.6

準備

Digispark

ここは、上述のelectronバージョンと同様。

libusb

Windowsではzadig(usbドライバ書き換えソフト)を使ってインストール。

  • zadigをダウンロードする。
  • zadigでDigiUSBのドライバをWinUSBに変更する。
node

まず、下のリポジトリをクローンしたら、コマンドプロンプト(cmd.exe)で落としてきたディレクトリの中に入る。

uitspitss/electron_scratchX-digispark

そして、 npm installで必要パッケージをインストールする。 (package.jsonのelectronは不要であれば、はずしてしまっても大丈夫)

実行

パッケージのインストール後、同ディレクトリの中で node no_electron.js とすると、 以下のような出力が出てくる。

-master>node no_electron.js
Digispark is opened.
ACCESS to following URL
http://scratchx.org/?url=http://localhost:9911/myscratch.js
R:255(100%), G:255(100%), B:255(100%)
R:130(51%), G:10(4%), B:8(3%)
R:212(83%), G:105(41%), B:222(87%)
R:245(96%), G:145(57%), B:161(63%)
R:77(30%), G:229(90%), B:171(67%)
R:214(84%), G:184(72%), B:222(87%)
R:117(46%), G:0(0%), B:26(10%)
R:217(85%), G:41(16%), B:102(40%)
R:41(16%), G:242(95%), B:224(88%)
R:61(24%), G:66(26%), B:194(76%)

-master>

実行後に出力されるURLにブラウザ(Chrome推奨)でアクセスすると、 上述したelectronのものと同様の動作をする。 R:~以下の部分はScratchXで組み込まれたブロッグが実行されると出力されるもの。

終了するときは、Ctrl-Cで終了。

Windows環境においてのelectronとnode-usbの問題

electronは、使用するパッケージ内部のnodeのバージョンとelectron内部のnodeのバージョンを合わせるようにパッケージをリビルドする機能がある。 しかし、このリビルドがコケてしまい、electronで起動すると、node-usbでできなかった。 このあたりは、node-usbのissuesのあたりに前例はあったけど、VisualStudioのバージョンも噛んだりしていて、私の環境では解決しなかった…

まとめ

技術的なところ

今回は、できるだけnode.jsで使うパッケージを減らす方向で作り始めた。 というのも、下調べ段階で、node.jsとelectronがともにのバージョンアップが頻繁であり、 パッケージのバージョン違いでビルドが失敗しているのをよく見かけたため。

javascriptのコードがES6の書き方をしているのもあれば、 ES5?の書き方をしているもあるのは、そのせい。

思ったこと

最近では、Arduinoなどを使えば、ハードウェアに飛び出していけるものが簡単に作れるようになった。 しかし、それを使うには、プログラミングをする環境をそろえたり、そこに出てくる問題を解決したりしなければいけない。 それがプログラミングのおいしいところにたどり着くまでの障害になっていることもよくある。

そこで、使い方によっては、繰り返し処理(for,while)や条件分岐(if,else)などの深いところまで 使うことができる、ScratchXをベースとして、手軽にプログラミングを楽しみたい。楽しませたいのである。 特にハードウェアに結果が出力されるものは、個人的におもしろいと感じるので、Digisparkを使っている。

最後に、node.jsやelectronに詳しい方は、ぜひ、Windowsバージョンのバイナリ化に挑戦してみてください! 成功しましたら、ご連絡いただけると大変うれしいです。

ダ○ソーで売っていたLEDランプの外装をランプカバーにすると、かわいい。

参考にしたサイト

ティアマト彗星に類似した彗星

最近、映画「君の名は。」が話題になっていますね。 新海誠さんの作品と言えば、「ほしのこえ」を始めとして、作中に宇宙に関するものやSF要素が散りばめられているのが印象的です。 そういえば、私がJAXAの前身であるNASDAを初めて知ったのは、「秒速5センチメートル」を見た時だったかもしれません。

さて、今回の「君の名は。」では、この記事のタイトルにある、ティアマト彗星が物語の鍵として描かれています。そこで、ふと、「こんな彗星あるのかな?」という疑問が浮かんだので、さらっと調べてみました。

作中で描かれているティアマト彗星は、1200年周期で太陽を公転し、軌道長半径は168億km以上とのこと。簡単に、ケプラーの法則で軌道長半径を確認してみると、

 a = \left( GP^2 \frac{M+m}{4{\pi}^2} \right)^{1/3}

(それぞれ文字については一般的に使われている意味と同じなので、ここでの説明は割愛します。) さらに、この式に対して、 M + m \approx M、Pに1200年を当てはめてみると、

道長半径 a は確かに168.9億kmとなります。

地球の公転軌道の約100倍、海王星の公転軌道の約3倍強の軌道長半径です。遠いですね。

さて、そのような彗星はあるのでしょうか。ここで、NASA/JPLSmall-Body Database Search Engineの出番です。 Cometに限定してテーブルを出力。そのテーブルから公転周期が1100年から1300年までのものを抽出すると、以下の通りでした。

彗星名 道長半径(億km) 周期(年)
C/2016 N4 (MASTER) 162.3349711 1125.873107
C/2014 C3 (NEOWISE) 162.6250627 1128.892347
C/2010 E1 (Garradd) 165.5987407 1159.99698
C/2012 T4 (McNaught) 170.0622661 1207.211201
C/2015 F4 (Jacques) 174.5471269 1255.27931

これらの彗星名でググると、おそらく吉田誠一さんのHPが引っかかると思います。 そこで、彗星の画像など、それぞれの彗星について詳しく見られます。 中でも「C/2016 N4」は2ヶ月前に発見報告がされている旬な彗星です。

長周期の彗星は、何かロマンがあって素敵ですよね。 今回のテーブルでは、あの百武彗星は周期が108303年になっていました。 人類は再び、百武彗星を見ることができるのでしょうか…

今回は、いつもと逆で小説を読んでから、映画を見に行こうと思っていて、 小説は昨日読み終わったので、今度映画を見に行こうと思います。

Googleのサイエンスジャーナルで実験

先日、5/20にGoogleからローンチされた、自由研究アプリ「サイエンス ジャーナル」。 このアプリで本当に実験ができるのか、単振り子の実験で試した。 ※カジュアルな実験なので、そのあたりはご了承ください。

実験環境

  • Android端末「XPeriaZ(SO-02E)」

開発環境

  • Windows10
  • Python(3.5.1) on Anaconda

実験

今回は、振り子の周期を出すことを目標に実験をした。

  • 時間もあまりかけられなかったので、脚立、少し太めの竹串、塩ビパイプで、簡単な振り子を作った。
  • 試行回数は4回。
  • サイエンスジャーナルで、端末座標上のX軸、Y軸、Z軸、それぞれの方向の加速度を記録。

実験が終ったら、実験結果の数値データを解析するために、エクスポートする。 Googleドライブに出してしまうのが、早そう。

f:id:uitspitss:20160608152438p:plain

結果

今回、サイエンスジャーナルで得られた実験結果が妥当かどうかを調べる方法を以下のようにした。

  • サイエンスジャーナルの実験結果データから周期を予測する。
  • 動画から周期を予測する。

この2つの方法から確かめた結果が合えば、妥当ということで…

実験データから周期を予測

実験結果のデータはcsvなので、メモ帳やエクセルなど、適当なエディタで開くことができる。

とりあえず、1回目の実験結果から見ていくと、

1回目

数値データのグラフが下記の通り、今回欲かったX軸方向のデータに関してはまずまず周期的に見える。 他のY軸とZ軸に関してのコメントは後述の考察にて。ちなみにこの傾向は、他の試行でも同様だった。

f:id:uitspitss:20160608150906p:plain

ここで、X軸方向のデータからグラフのピーク間の秒数を計測して、半周期の予測をする。 今回は、ノイズが少なさそうに見える、timeが8~20の範囲のデータを用いた。 計測結果は、

f:id:uitspitss:20160608150910p:plain

ピーク間の時間間隔[s]
最小時間間隔 0.07
最大時間間隔 1.24
平均時間間隔 0.40

バラツキはありますが、半周期が0.4秒前後だろうと予測できる。

他、3回の試行結果のデータは、

2回目

f:id:uitspitss:20160608150916p:plain f:id:uitspitss:20160608150918p:plain

ピーク間の時間間隔[s]
最小時間間隔 0.34
最大時間間隔 1.36
平均時間間隔 0.57

3回目

f:id:uitspitss:20160608150923p:plain f:id:uitspitss:20160608150925p:plain

ピーク間の時間間隔[s]
最小時間間隔 0.07
最大時間間隔 0.89
平均時間間隔 0.39

4回目

f:id:uitspitss:20160608150942p:plain f:id:uitspitss:20160608150945p:plain

ピーク間の時間間隔[s]
最小時間間隔 0.07
最大時間間隔 0.89
平均時間間隔 0.42

動画から周期を予測

実験の様子を撮影した動画から、下のように10秒前後のところを切り出してスローモーションで動画を確認して、 左右に最大に振れた時間の間隔を記録すると、 ※タイムコードからタイムへの変換は30fps動画なので、(タイムコード)×100/30で求めた。

f:id:uitspitss:20160608151803g:plain

タイムコード タイム[s] 時間間隔[s]
20:24 20:80 -
21:06 21:20 0:40
21:20 21:67 0:47
22:02 22:07 0:40
22:16 22:53 0:46

動画からは、半周期が0.4秒強と予測できる。

結果のまとめ

以上の結果より、この単振り子の周期は、

  • サイエンスジャーナルから、(0.40 + 0.57 + 0.39 + 0.42) / 4 * 2 = 0.89[s]
  • 動画から、 (0.40+0.47+0.40+0.46) / 4 * 2 = 0.87[s]

と予測できる、という結果になった。 こういった実験で使うには十分な精度の結果が得られるようだ。

考察

動画から時間間隔を求めるのは手間だったので、1回目の試行の動画の、さらに、2秒間の部分だけから最終結果を出しているので、マズい気もしなくはない…

さて、数値データから作成した実験結果のデータを見ていると、X軸方向以外のY軸・Z軸方向にも、周期的な振動があるように見える。 Y軸・Z軸方向のデータについても、同様に周期を予測してみると、

  • Y軸方向には、0.30秒前後
  • Z軸方向には、0.40秒前後

という、X軸方向の周期より短かい時間間隔の周期が陽に表われた。 これは、実験装置自体が揺れてしまったためだと考えられる。 また、X軸方向でピーク間の時間間隔を計測した際に、最小値が異様に小さく出てしまったのも、これが原因だろう。

最後に、サイエンスジャーナルで取得した実験データを扱うときの注意として、

  • サイエンスジャーナルの数値データの計測頻度は、0.1秒間に1回ないしは2回程度(端末によって違いがあるかも?)
  • 今回のように、1回の計測で複数の数値データを取得することが可能だが、計測した瞬間のタイムスタンプは一致しない。
    → 解析用コードを作る際に、そのあたりは予想できたので、つまづかなかったが、知らずにハマってしまうことも…