うごくものづくりのために

技術的な備忘録がメインです。

ワイヤレスなノイズキャンセリングイヤホンを聴き比べた

愛用していたイヤホン Sony WI-1000X が壊れました。 左耳から音が聞こえません。 ノイズキャンセリング付きのワイヤレスイヤホンで、音も良くとても気に入っていたのですが残念です。

というわけで、秋葉原の e-イヤホンに行き、ワイヤレスなノイズキャンセリングイヤホンを聴き比べて来ました。
備忘録として、感想を残しておきます。

試聴したイヤホンは以下。

WI-1000X を基準として、私がイヤホンに求める各項目に点数を付けました。最大5点。 点数は完全に私の独断と偏見です。

商品 音質 NC性能 装着性 完全ワイヤレス 価格
(Sony WI-1000X) 3 3 3 X 27000円
Sony WI-1000XM2 4 4 4 X 35000円
Sony WF-1000XM3 2 2 2 O 25880円
Apple AirPods Pro 1 5 5 O 27800円
1More EHD9001TA 2 4 4 O 18000円

以下、それぞれの詳細な感想です。

Sony WI-1000XM2

今回壊れた WI-1000X の後継機です。

すべてが順当に進化してるな、という印象です。
一番良くなっていると感じたのはNC性能です。 前モデルに比べて一回り雑音を抑えられている感じがしました。
音質も全体的なバランスが良く、解像度も上がっている感じがしました。個人的にSonyの音が好きなので、音質は満足です。
また、ネックバンドが完全シリコンゴム製になっているのがうれしいですね。 前モデルは金属が入っているため強く曲げられず、持ち運びに不便でした。このモデルは完全に折りたたんで持ち運べます。持ち運び用のポーチも付属するようでした。

ただ、今回聴き比べた他のモデルと異なり、ネックバンド型というのが若干ネックです。(洒落です)
着けてしまえば肩に乗っているのは気にならなくなるんですが、移動中にケーブルの風切り音が入るのが辛いところですね…。
あと価格が高い。

Sony WF-1000XM3

Sonyの完全ワイヤレスイヤホンです。最近売れ筋ですね。

音質についてですが、きちんとSonyの音が鳴っておりおおむね良好です。ただ、 WI-1000X に比べると若干劣る感があります。
気になったのは装着感でした。頭や体を揺らすと、イヤホンが動くのが分かります。激しい運動をすると取れるだろうと感じました。イヤーピースの相性もあるのかもしれません。
また、NC性能は WI-1000X よりも一回り劣る感じでした。個人的にはちょっと弱すぎるかなぁ…。

Apple AirPods Pro

最近大人気で入荷待ちの商品ですね。 e-イヤホンも新品は取り扱いが無いとのことで、中古品を試聴しました。

まず、装着感がとても良いです。本体が小さく、かつ質量もまとまっていて落ちる心配は全然感じません。 耳に押し込むカナル型と比べて圧迫感もありません。
NC性能も抜群です。 BoseのQC30 に匹敵するんじゃないか?ぐらいのNC性能がありました。
話題のアンビエントモードもかなり良かったです。完全に耳!とまではいきませんが、割と自然に外音を聴かせてくれます。Sonyのものより良く出来てるな、という感想です。

ただし、肝心の音質が良くありません。全体的にのっぺりとしていて、迫力にかけます。また、解像度も悪くぼんやりとした印象を受けます。
がっつり音楽を聞きたい人にはおすすめできません。作業用にずっと流しておく、程度の聞き方であれば良いかも…。

1More EHD9001TA

試聴しに行った日の前日からたまたま発売されていたNC付き完全ワイヤレスイヤホンです。
1Moreというメーカーは初めて聞いたのですが、中国のメーカーらしいですね。

装着感は割と良いです。耳の上の方に刺さるようなサポート?構造があり(伝わってくれ…)、頭や体を揺らしてもズレる感じはしませんでした。 NC性能は割と良いです。 WI-1000X よりは良く、WI-1000XM2 と同レベル程度と感じました。

音質はドンシャリ系でそこまで悪くないですが、中音~高音にかけて薄っぺらいというか安っぽい感じがしました。

値段の割には良い製品かなと思いました。


……
で、お前は一体どれを買ったんだという話ですが、実はどれも買っていません。。。
正直なところ、今回視聴した中にはビビビッとくる物がありませんでした。 WI-1000X 並の音質とNC性能で、完全ワイヤレスなイヤホンが出たら多少高くても買うんですけどね…。

Qualcommがアクティブノイズキャンセリング対応のチップを出しているらしく、それが採用された製品がそろそろ市場に出てくるはずなので、しばらくは待ってみようと思います。

ファーストキャビン 羽田空港第1ビルに宿泊した

ハイクオリティカプセルホテルとして有名なファーストキャビン。その中で一番有名であろうファーストキャビン羽田に宿泊しました。

f:id:tilt_silvie:20191017080627j:plain 誰もいない羽田空港

個人的にカプセルホテルが好きで、今までいくつか利用してきました。あの秘密基地感がたまらないんです。
今回は、それら「普通の」カプセルホテルとファーストキャビンの違いに目を配ってみます。

ファーストキャビン羽田には、部屋の広いファーストクラスと、一回り狭いビジネスクラスがあります。
私は今回ビジネスクラスを利用しました。

良かったところ

 客室

f:id:tilt_silvie:20191017081919j:plain

客室は普通のカプセルに比べて広いです。1段しか無い為高さが確保できており、身長170cm強の私ならベッドの上にゆうゆうと立てます。カプセルホテルではベッドの上で着替えや荷物整理などするので、広いのは助かります。
また、客室内に貴重品ロッカーがあり管理が楽でした。もちろん普通サイズのロッカーも別途あります。

フロントの対応

良かったです。普通のホテルと同じ、とまではいきませんがカプセルとしては高い水準にあります。

民度

良いです。比較的価格が高いためでしょうか。
あの独特の治安の悪さがカプセルの一つの醍醐味だったりするんですが、ここではあまり感じられませんでした。

イマイチ(というか普通)だったところ

お風呂

普通です。特に期待して行くものではないです。
湯船のキャパは10名ぐらい。 寝湯があったのは良かったです。

トイレ

客室から期待するほどの清潔感はありません。共用部なのでしょうがないですが。 市販の芳香剤が並んでいて安っぽいです。

アメニティ

男性専用カプセルだとひげ剃りグッズが充実しているところがありますが、ここはそうではありません。
カミソリは有料。洗面台に据え置きのシェービングクリームもありません。
もうちょっと充実していると嬉しいです。

まとめ

客室とフロントはやはり値段に応じて良いです。 しかし、普通のホテルほどの期待をしていくとガクッと来る部分がありました。
やはりカプセルホテルはカプセルホテルですね。

また機会があれば利用しようと思います。

LinuxのVSCodeで、Xmodmapでのキーアサイン変更が反映されなくてハマった

UbuntuLinux版のVSCodeVim拡張を入れて使っていたところ、 Xmodmapでのキーアサイン変更が反映されなくてハマりました。

結論: settings.jsonに以下を追記する

"keyboard.dispatch": "keyCode"

VS Code no longer respects remapped escape key using xmodmap · Issue #32037 · microsoft/vscode · GitHub

以下駄文

普段自分は、Xmodmapで 全角半角キーをEscに、 CapsLockを左Ctrlに変更して使っています。

~/.Xmodmap

! Zenkaku_hankaku -> Esc
keycode 49 = Escape

! CapsLock -> Control_L
keycode 66 = Control_L

が、VSCode上で 全角半角キーを押してもVimのインサートモードから抜けられず困りました。 ググったら上記のIssueがヒットしたので、settings.jsonに追記したところきちんと効くようになりました。

dockerコンテナ内で動作するGUIの画面を他のコンテナで表示する方法

ほとんど需要ないと思いますが…。

xserverが動作しているコンテナ(コンテナA)に、GUIソフトが動作するコンテナ(コンテナB)を接続して、コンテナB上のGUIウィンドウをコンテナA上に転送します。

方法

まず、以下の2つを用意します。

  • コンテナA: GUIが動作する(xserverが動作している)dockerコンテナ (ubuntu-desktopなど)
  • コンテナB: GUIソフトを動作させるdockerコンテナ

今回は、コンテナAはuphy/ubuntu-desktop-jpを、コンテナBは gns3/xeyes を使います。

https://hub.docker.com/r/gns3/xeyes

https://hub.docker.com/r/uphy/ubuntu-desktop-jp


まず、コンテナAを起動します。

sudo docker container run -it --rm --name container-a -p 8080:8080 -v /tmp/.X11-unix uphy/ubuntu-desktop-jp:latest

uphy/ubuntu-desktop-jpでは、 http://localhost:8080/に接続することでnoVNC経由で画面が表示できます。 確認しておきましょう。

次に、コンテナBを起動します。

sudo docker container run -it --rm --name container-b -e DISPLAY=:0.0 --volumes-from container-a gns3/xeyes

うまくいっていれば、コンテナAの画面(http://localhost:8080/)に、カーソルを追いかける目玉が表示されているはずです。

f:id:tilt_silvie:20190114144104p:plain

仕組み

ミソは2つあります。

1つめのミソは、/tmp/.X11-unixのコンテナ間での共有です。
/tmp/.X11-unixは、xserverとxclientの間の unix domain socketです。要はこのソケットを通じて、GUIを表示したいソフト(xclient)とその処理をするxserverとの間で情報をやりとりしています。
今回は、コンテナA内の /tmp/.X11-unixを、dockerのData Volume機能を使ってコンテナBに共有することで、あたかもコンテナBがxserverを起動しているかのような状態にしています。

2つめのミソは、環境変数DISPLAYの定義です。 コンテナB起動時の -e DISPLAY=:0.0 がそれです。
DISPLAYはxserverのパスを指定するための環境変数ですが、今回はコンテナBにコンテナAの/tmp/.X11-unixをマウントしているので、ローカルに画面があるときと同じ:0.0としています。

参考

Dockerコンテナの中でGUIアプリケーションを起動させる | Unskilled?

Ubuntu 16.04 で ワイヤレスネットワークカード Intel Dual BandWireless-AC 8265 が動かなかった話。

結論

Ubuntu16.10なら動く。 が、サポート切れてるのでやるべきじゃない。

いきさつ

諸般の都合があり、今年買った ThinkpadにUbuntu16.04を入れることになりました。
入れたのはいいんですが、ネットワークカード(Intel Dual BandWireless-AC 8265)が全く認識されてない。 ifconfigしてもloしかありません。

というわけでGoogle先生に色々聞きました。

どうやらネットワークカードがUbuntu16.04がリリースされてからだいぶ後に製造されているもののため、デバイスドライバUbuntuに含まれていないらしい。

それならば、と Intelのドライバページを確認しに行ったところ、対応したドライバが配られていました。

https://www.intel.co.jp/content/www/jp/ja/support/articles/000005511/network-and-i-o/wireless-networking.html

f:id:tilt_silvie:20180907215358p:plain

で、試しに入れてみたんですが、動きません。なんで。。。

よく見ると、ドライバ配布ページの注意書きに

この表にはリリースされている最初の公式ファームウェア・バージョンのみが記載されています。これは表で指定されているカーネルバージョンのみで動作することが保証されています。新しいカーネル用に最新バージョンを入手するには、firmware git tree をご利用ください。

とある。
今回のネットワークカード(~8265)は、4.6 以降 でないとだめみたい。

Ubuntu16.04のKernelのバージョンを以下のページで確認したところ、4.4とある。だめじゃん。

attachment:Ubuntu Kernel Support Schedule.svg of Kernel/Support - Ubuntu Wiki

Ubuntu16.10は4.8なので、条件を満たしてそうですね。

というわけで、Ubuntu16.10を入れてみます。


Ubuntu16.10なら、特に何もせずに普通にネットワークカードが認識されました。
が、2017年7月でサポートが終わってるので、運用すべきではありません。

素直にUbuntu18.04 でちゃんと動く環境つくります。

中華製のやっすいロジックアナライザを試してみた。

以前amazonで中華製のやっすいロジックアナライザを購入していました。

24MHz 8CH で1150円(!?)という代物。本当に動くのか。

環境のセットアップから、最終的にはUARTのプロトコルアナライザを動かすところまでやってみたいと思います。

環境

開封

袋には、本体、USBケーブル、測定用のフラットケーブルが入っています。取扱説明書など無し。

f:id:tilt_silvie:20180729162832j:plain f:id:tilt_silvie:20180729162835j:plain

とりあえず、本体にフラットケーブルを接続。

セットアップ

ソフトのインストール

amazonのコメントによると、Sigrokというソフトが使えるようです。

The sigrok project aims at creating a portable, cross-platform, Free/Libre/Open-Source signal analysis software suite that supports various device types (e.g. logic analyzers, oscilloscopes, and many more).

(Sigrok ホームページ(https://sigrok.org/)から引用)

ロジアナとか、オシロスコープなどのデバイスクロスプラットフォームで汎用的に使えるようにしよう、というプロジェクトのようです。

私はWindowsなので、以下のURLからDL。

http://sigrok.org/jenkins/job/sigrok-cross-mingw/buildtype=static,debugtype=release,platform=cross-i686-w64-mingw32/lastSuccessfulBuild/artifact/pulseview-NIGHTLY-32bit-static-release-installer.exe

セキュリティソフト入れているとうまくインストールできないことがあります。僕はAvastに怒られました。が、とりあえず一時的にセキュリティソフトを無効化して、インストール。

インストール自体は普通にウィザードに従って、デフォルトでOKです。

接続・ドライバインストール

次に、ロジックアナライザをPCにUSBケーブルで接続します。 その後、スタートメニューに追加された Zadig(Pulse View)を起動します。

接続したロジックアナライザUnknown Device #1として認識されていることを確認して、Install Driverをクリックして、ドライバを入れます。

ちょっと待つとドライバのインストールが開始されます。The driver is installed successfully.とウインドウが出たらドライバのインストール完了です。Zadigを閉じましょう。

ここまででセットアップは完了です。

使ってみる

起動

スタートメニューに追加されたPulse Viewを起動します。

その後、左上付近の●RUNボタンを押すと、データの取得が開始されます。波形が右に伸びていくのでわかるかと思います。

試しに、CH0にスイッチをつないで、3.3V ⇔ 0V をパチパチ切り替えて見ました。

f:id:tilt_silvie:20180729162924p:plain

見えてる、すっご…

UARTのプロトコルアナライザとして使ってみる

右上のAdd low-leve, non-stacked protocol decoderをクリックして、デコーダのメニューを表示します。表示されたメニューの中から、UARTをクリックします。

f:id:tilt_silvie:20180729163004p:plain

すると、波形画面の一番下にUARTと名前のついたチャンネルが表示されます。

f:id:tilt_silvie:20180729163019p:plain

そして、左のUARTと書いてある ボタンをクリックすると、設定画面が表示されます。

観測したいUARTに合わせて設定してあげます。今回僕はこんな感じ。

f:id:tilt_silvie:20180729163029p:plain

それから、通信をまともに見るならサンプリングレートを上げる必要があります。適当にこのくらいの値にしました。

f:id:tilt_silvie:20180729163110p:plain

RXとTXに指定したCHにそれぞれケーブルを繋いで、●RUNしてみましょう。 今回は、UARTで「Hello World !」とマイコンから送信し、そのUARTをこのロジアナで観てみました。

f:id:tilt_silvie:20180729163122p:plain

一番下のUARTのところで「Hello World !」と表示されていますね。すごい。

最後に

半分お金をドブに捨てる気持ちで買いましたが、普通に使えてびっくりしました。

Sigrokのソフトが優秀で、様々な通信のプロトコルアナライザがついてますので、基板の通信デバッグにかなり役立ちそうです。

参考

https://wave.hatenablog.com/entry/2017/03/12/083000

DeepLearningの勉強メモ

明けましておめでとうございます。
正月休み暇なので、「人工知能でなんとかなりませんか」おじさんに対抗できるよう理論武装しておきたいと思います。
なお、この記事は自分用のメモであるため、読んでもあまり参考にはならないかと思います。。。

書籍「ゼロから作るDeepLearning」をベースに進めていきます。

勉強は書籍を一通り嘗めてやる予定ですが、ブログには新しく学んだことや忘れそうなことだけ書いておくことにします。


3章 ニューラルネットワーク

パーセプトロンニューラルネットワークの違い

パーセプトロン:ステップ関数
ニューラルネットワーク:シグモイド関数

出力層の活性化関数

解決したい問題によって変更する
回帰問題は恒等関数(出力層への入力をそのまま出力する)
2クラス分類はシグモイド等
多クラス分類はソフトマックス

ソフトマックス関数


y_k = \frac{\exp (a_k)}{\sum_{i=1}^{n} \exp(a_i)}

出力の総和が1になるので、各出力を確率として扱うことができる

\exp(n)が、nの値によってすぐ巨大な数になるので、オーバーフロー対策が必要

学習ステップでは使うけど、推論ステップでは用いない
入力と出力の各要素の大小関係は変動しないので、使う意味がほぼ無い

4章 ニューラルネットワークの学習

勾配降下法


\boldsymbol{x_{n+1}} = \boldsymbol{x_n}  - \eta \frac{\partial f}{\boldsymbol{\partial x_n}}

あるサンプル点 \boldsymbol{x_n}偏微分を計算(数値微分)して、傾きを求める
その傾きに学習率  \eta を掛けて、次のサンプル点 \boldsymbol{x_{n+1}} とする

学習率 \etaはハイパーパラメータ
ハイパーパラメータのチューニングは人力が多いが、自動化の手法もある (グリッドサーチ、ベイズ最適化等)

損失関数が重みの関数として表されるので、損失関数の極小値を求めることで重みを最適化(?)できる

重みの初期値

正規分布で初期化するのが標準的みたい
重みの初期値は学習がうまくいくかどうかの重要なパラメータになるので、必ずしも正規分布で初期化するのが正しいとはいえない

5章 誤差逆伝播

計算グラフ

演算をノード、数値を矢印として表現し、グラフで計算を表す
ある値Aに対する値Bの偏微分は、矢印を逆順に辿り、各矢印の偏微分係数をかけ合わせていくだけで計算できる
矢印ごとの偏微分係数は、その矢印を通るすべての演算において再利用可能

出力層の活性化関数と損失関数の組み合わせ

正しい組み合わせを使うと、逆伝播される値が出力信号と教師信号の差分 \boldsymbol{y} - \boldsymbol{t}というシンプルな数式になる。
そうなるように、損失関数が設計されている。

多クラス分類:「ソフトマックス関数」と「交差エントロピー誤差」の組み合わせ
回帰    :「恒等関数」と「二乗和誤差」の組み合わせ

勾配確認

誤差逆伝播法による微分は実装ミスが起こりやすいため、数値微分の結果と比較することで実装の正しさを検証する

6章 学習に関するテクニック

最適化手法

  • SGD 普通の勾配降下法
    最適化対象の関数に等方性が無い場合、収束が遅くなる

  • Momentum 最適化の探索に慣性を導入するイメージ
    探索点の移動のさせ方について、SGDでは勾配 = 速度だが、Momentumでは勾配 = 加速度 になるイメージ

重みの初期値

重みの初期値は重要なハイパーパラメータ
重みの初期値によっては、学習が全く進まないことがある(勾配消失、表現力の制限など)

活性化関数の種類によって、適切な重みの初期値が変わる
ReLUの場合:Heの初期値
 stddiv. \sigma =\sqrt{ \frac{2}{n}} | n : 前層のノード数

sigmoid, tanhの場合:Xavierの初期値
 stddiv. \sigma =\sqrt{ \frac{1}{n}} | n : 前層のノード数

Batch Normalization

層の出力に対して、平均が0, 分散が1となるように正規化を施す

効果

  • 学習を早く進行させられる
  • 初期値にそれほど依存しない
  • 過学習を抑制する

過学習

訓練データのみに適応したネットワークになってしまうこと
ネットワークの表現力が高かったり、訓練データが少ない際に起こりやすい
大きすぎる重みによって、過学習が引き起こされることが多い

対策 - Weight decay 損失関数に重みの2乗ノルムを追加する
重みが大きいと損失関数が大きくなるので、重みが小さくなるように学習が進む

  • Dropout 学習時に隠れ層のニューロンを消去して学習する
    推論時は全ての層を使って計算するが、各ニューロンの出力に対して学習時に消去した割合を乗算する
    仮想的にアンサンブル学習を行っているものとみなせる

ハイパーパラメータの探索

ハイパーパラメータの探索用のパラメータとして、検証データを用意する

DeepLearningで用いるデータセットは - 訓練データ - 検証データ - テストデータ の3つになる

テストデータでハイパーパラメータの探索をしない理由…
テストデータに適したハイパーパラメータになってしまう… → 過学習的なことが起こる

ノウハウで行う部分が大きい
ベイズ最適化という手法で、かっこよくハイパーパラメータの最適化ができる(らしい)

実験計画法とか使えないのかな…?

7章 畳み込みニューラルネットワーク

 データの次元

普通のNNは入力データを1次元化してしまうので、2次元画像に含まれる特徴が失われる可能性がある
CNNはデータの形状を維持したまま入力できる