メモ

調べたり思いついたりしたことをメモします

加速度センサ（ADXL343）を Raspberry Pi 4 で使う

f:id:uenoshin:20190720150540j:plain

Analog Devices の３軸加速度センサ ADXL343 を £5 ぐらいで購入できましたので Raspberry Pi 4 で動かしてみました。 9pinの足を全部はんだ付けしてブレッドボード上に実装しています。ちなみにはんだ付けする前の写真はこちらです。あんまり上手じゃないですけど、とりあえず繋がりさえすればOKです。

f:id:uenoshin:20190720151311j:plain

I2Cでの接続になります。ADXL343 上の VIN を Pi 4 の 3v3 へ接続、GND,SDA,SCL はそれぞれ同名のクチにジャンパ線で接続しています。

正しく接続できたか i2cdetect で確認します。 先日遊んでいた BME680 も接続していますのでアドレスは 0x53 と 0x76 の両方が見えていますが ADXL343 は 0x53 の方です。

pi@raspberrypi:~/rpiLogger $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- 53 -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- 76 --

今回、I2Cの Read/Write には pigpio というライブラリを使っています。 abyz.me.uk

pigpioで読み出した x, y, z の３軸データをビジーループの中でCSVファイルに吐き出すようにしてみました。 CSVの左列にはunixtimeとマイクロ秒を並べて時系列データのようにしています。 時系列のピッチが不揃いなのはご容赦ください。ビジーループで雑に吐き出しただけですので。

書いたソースを全文貼っておきます。雑なＣ言語ですみません。もし同じようなことをする人がおられましたら、

$ gcc -Wall -pthread  file.c  -lpigpio -lrt

pigpio のインストール後、このようにコンパイルして実行ファイルが作れます。

ちなみにこのpigpioで i2cOpen() するときにアドレスを 0x53 ではなく間違った値を入れてしまっても正常リターンが返されます。 その後読み書きのAPIが PI_I2C_READ_FAILED や PI_I2C_WRITE_FAILED で失敗する振る舞いになりました。Openの時点でエラーになってくれれば分かりやすいのに、かるくハマりました。。

ソースはこちら

#include <stdio.h>
#include "pigpio.h"

#define ADXL343_I2C_ADDR_PRIMARY    0x53
#define ADXL343_BW_RATE             0x2C
#define ADXL343_DATA_FORMAT         0x31
#define ADXL343_FIFO_CTL            0x38
#define ADXL343_POWER_CTL           0x2D
#define ADXL343_DATAX0              0x32
#define ADXL343_DATAY0              0x34
#define ADXL343_DATAZ0              0x36

static int handle;
static FILE *fp;

void initSensor()
{
    /* BW_RATE : 0x0f = 1600Hz */
    i2cWriteByteData(handle, ADXL343_BW_RATE,       0x0f );
    i2cWriteByteData(handle, ADXL343_DATA_FORMAT,   0x00 );
    i2cWriteByteData(handle, ADXL343_FIFO_CTL,      0x00 );
    i2cWriteByteData(handle, ADXL343_POWER_CTL,     0x08 );
}

void writeCSV(int x_dat, int y_dat, int z_dat )
{
    int seconds,micros;
    gpioTime(1, &seconds, &micros );
    
    fprintf(fp, "%d %6d: x:y:z ,%6d,%6d,%6d\n",seconds,micros,x_dat,y_dat,z_dat );
}

void readSensor()
{
    int x_dat, y_dat, z_dat;

    while(1)
    {
        x_dat = i2cReadWordData(handle, ADXL343_DATAX0);
        y_dat = i2cReadWordData(handle, ADXL343_DATAY0);
        z_dat = i2cReadWordData(handle, ADXL343_DATAZ0);    
        writeCSV( x_dat, y_dat, z_dat );
    }
}

int main(int argc, char *argv[])
{
    if (gpioInitialise() < 0) return 1;
    handle = i2cOpen(1, ADXL343_I2C_ADDR_PRIMARY, 0);
    fp = fopen("save.csv","w");

    initSensor();
    readSensor();

    fclose(fp);
    i2cClose(handle);
    gpioTerminate();
}

実行してみたところ、CSVファイルは３軸それぞれの値が２バイトデータで出力されます。 時間出力の読み方ですが、左列の1563603955のような10桁数字が1970年1月1日からの秒で、その横の6桁数字がマイクロ秒です。このマイクロ秒部分を読み取ると、サンプルごとの時間間隔はおおむね1500マイクロ秒（1.5ミリ秒）ぐらいになっている模様です。

1563603955 512977: x:y:z ,    12,    62,   228
1563603955 514534: x:y:z ,    18,    74,   238
1563603955 516064: x:y:z ,    16,    58,   238
1563603955 517594: x:y:z ,    12,    56,   242
1563603955 519121: x:y:z ,    16,    58,   242
1563603955 520650: x:y:z ,    20,    58,   236
1563603955 522177: x:y:z ,    26,    64,   236
1563603955 523705: x:y:z ,    22,    66,   240
1563603955 525233: x:y:z ,    24,    62,   232
1563603955 526762: x:y:z ,    20,    62,   232
1563603955 528290: x:y:z ,    20,    68,   230
1563603955 529817: x:y:z ,    22,    66,   230
1563603955 531345: x:y:z ,    16,    64,   232
1563603955 532873: x:y:z ,    10,    74,   224
1563603955 534401: x:y:z ,    16,    70,   228
1563603955 535929: x:y:z ,     8,    60,   232
1563603955 537458: x:y:z ,    14,    64,   224
1563603955 538985: x:y:z ,    12,    64,   224

すこし気に入らなかったので I2C の速度をデフォルトの 100KHz から 400KHzに変更してみました。 /boot/config.txt に

dtparam=i2c_baudrate=400000

と書いて再起動します。

この状態で実行してみたところ、時間間隔は約0.8ミリ秒ぐらいに縮まりました。1.0KHzサンプリングの時系列データを作るぐらいならぎりぎりなんとかなりそうな性能ですね。このあともう少し試行錯誤していると0.4ミリ秒ピッチぐらいで動けるようになってきました。安定した定周期で時系列データを取れるようにしていきたいと思います。

1563605344 553451: x:y:z , 65472, 65520,   240
1563605344 554291: x:y:z , 65478, 65528,   230
1563605344 555131: x:y:z , 65476, 65518,   220
1563605344 555972: x:y:z , 65478, 65530,   222
1563605344 556814: x:y:z , 65482, 65524,   236
1563605344 557654: x:y:z , 65480, 65530,   234
1563605344 558499: x:y:z , 65502, 65528,   240
1563605344 559340: x:y:z , 65492, 65530,   224
1563605344 560180: x:y:z , 65480, 65524,   232
1563605344 561021: x:y:z , 65480, 65524,   232
1563605344 561861: x:y:z , 65452, 65526,   234
1563605344 562702: x:y:z , 65486, 65524,   238
1563605344 563543: x:y:z , 65486, 65532,   214
1563605344 564384: x:y:z , 65476, 65526,   200
1563605344 565225: x:y:z , 65482, 65524,   224

温湿度・気圧・ガスセンサ（BME680）を Raspberry Pi 4 で使う

f:id:uenoshin:20190712214250j:plain

別に Raspberry Pi 4 でなくとも同じだとは思いますが、一応 Pi 4 でも使えたよという実績を書き残しておきます。 使ったのはこちらの BME680 です。£16ぐらいで買えました。

Getting Started with BME680 Breakout - Pimoroni Yarr-niversity

写真にあるブレッドボードとT型拡張ボードはそのへんの安物で十分でしょう、たぶん。Amazonでこういうのを買うといろいろ使えて便利だと思います。

さて、実装ですがブレッドボード上の 3.3V, SDA, SCL, GND を合わせて差し込みます。RPiのGPIOの並びなら特にジャンパピンなども使わずにそのままぶっ刺すだけでOKです。

ライブラリのインストールは公式サイトに記載の通りです。

git clone https://github.com/pimoroni/bme680
cd bme680/library
sudo python setup.py install

これでインストールが出来た状態となりますので動作確認用のスクリプトを動かしてみます。

cd /home/pi/bme680/examples
python read-all.py

するとエラーメッセージが出ました。

read-all.py - Displays temperature, pressure, humidity, and gas.

Press Ctrl+C to exit!


Traceback (most recent call last):
  File "read-all.py", line 15, in <module>
    sensor = bme680.BME680(bme680.I2C_ADDR_SECONDARY)
  File "build/bdist.linux-armv7l/egg/bme680/__init__.py", line 43, in __init__
IOError: [Errno 2] No such file or directory

よく考えたらI2CをEnableにしていなかったので raspi-config を使って設定変更します。

sudo raspi-config

f:id:uenoshin:20190712220655j:plain

5の Interfacing Options を選びます。

f:id:uenoshin:20190712220815j:plain

P5の箇所の I2C を選びます。

f:id:uenoshin:20190712220915j:plain

すると I2C を Enable にするか聞いてくるので「はい」を選択します。 これで I2C が有効になったので気を取り直して再度動作確認用スクリプトを動かします。

pi@raspberrypi:~/bme680/examples $ python read-all.py 
read-all.py - Displays temperature, pressure, humidity, and gas.

Press Ctrl+C to exit!


Calibration data:
par_gh1: -37
par_gh2: -8441
par_gh3: 18
par_h1: 853
par_h2: 995
par_h3: 0
par_h4: 45
par_h5: 20
par_h6: 120
par_h7: -100
par_p1: 37742
par_p10: 30
par_p2: -10529
par_p3: 88
par_p4: 7839
par_p5: -83
par_p6: 30
par_p7: 70
par_p8: -6136
par_p9: -1168
par_t1: 26291
par_t2: 26386
par_t3: 3
range_sw_err: 0
res_heat_range: 1
res_heat_val: 37
t_fine: 141008


Initial reading:
gas_index: 0
gas_resistance: 6250729
heat_stable: False
humidity: 53.186
meas_index: 0
pressure: 998.4
status: 32
temperature: 27.54


Polling:
27.55 C,998.40 hPa,53.18 %RH
27.56 C,998.38 hPa,53.12 %RH,1692 Ohms
27.58 C,998.44 hPa,53.04 %RH,2316 Ohms
27.61 C,998.43 hPa,52.94 %RH,3029 Ohms
27.63 C,998.42 hPa,52.84 %RH,3634 Ohms
27.66 C,998.44 hPa,52.71 %RH,4206 Ohms
27.67 C,998.41 hPa,52.61 %RH,4768 Ohms
27.69 C,998.43 hPa,52.50 %RH,5329 Ohms
27.70 C,998.46 hPa,52.39 %RH,5863 Ohms
27.71 C,998.45 hPa,52.29 %RH,6440 Ohms
27.71 C,998.46 hPa,52.16 %RH,7048 Ohms
27.72 C,998.45 hPa,52.08 %RH,7624 Ohms
27.73 C,998.44 hPa,51.97 %RH,8251 Ohms
27.74 C,998.45 hPa,51.89 %RH,8897 Ohms
27.74 C,998.44 hPa,51.81 %RH,9547 Ohms
27.75 C,998.43 hPa,51.73 %RH,10200 Ohms
27.76 C,998.44 hPa,51.66 %RH,10823 Ohms
27.77 C,998.44 hPa,51.61 %RH,11477 Ohms
27.77 C,998.43 hPa,51.55 %RH,12131 Ohms
27.77 C,998.44 hPa,51.51 %RH,12893 Ohms
27.78 C,998.43 hPa,51.47 %RH,13508 Ohms
27.78 C,998.42 hPa,51.43 %RH,14185 Ohms
27.79 C,998.42 hPa,51.40 %RH,14839 Ohms
27.79 C,998.41 hPa,51.40 %RH,15602 Ohms
27.79 C,998.42 hPa,51.41 %RH,16396 Ohms
27.80 C,998.42 hPa,51.43 %RH,17106 Ohms
27.80 C,998.42 hPa,51.41 %RH,17834 Ohms
27.81 C,998.43 hPa,51.40 %RH,18578 Ohms
27.81 C,998.41 hPa,51.37 %RH,19405 Ohms
27.81 C,998.46 hPa,51.34 %RH,20152 Ohms
27.82 C,998.46 hPa,51.29 %RH,20917 Ohms
27.82 C,998.45 hPa,51.25 %RH,21697 Ohms
27.83 C,998.44 hPa,51.21 %RH,22538 Ohms
27.83 C,998.43 hPa,51.19 %RH,23342 Ohms
27.83 C,998.43 hPa,51.16 %RH,24118 Ohms
27.83 C,998.43 hPa,51.15 %RH,24936 Ohms
27.83 C,998.43 hPa,51.11 %RH,25795 Ohms
27.83 C,998.42 hPa,51.09 %RH,26699 Ohms
27.83 C,998.42 hPa,51.06 %RH,27595 Ohms
27.83 C,998.43 hPa,51.04 %RH,28554 Ohms
27.83 C,998.43 hPa,51.01 %RH,29374 Ohms

温度・気圧・湿度・ガス抵抗値 が一秒ごとに出力されていきます。

あと、ちなみにこのBME680のアドレスは 0x76 です。今後ほかのI2Cデバイスも並べて使っていこうと思うので覚書までに。

pi@raspberrypi:~/bme680/examples $ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- 76 --

Raspberry Pi 4 での UnixBench 結果

f:id:uenoshin:20190712212432j:plain

技適待ちのため日本では未発売の Raspberry Pi 4 を入手しましたので UnixBench を動かしてみました。 あ、ちなみに現在地はイギリスで作業しておりますので技適の問題はありません。

ご参考に結果を貼っておきます。 ブートに使用したMicroSDカードは 30MB/s のものなのでFileCopy系はかなり遅いです。

実行環境のバージョンはこちらの通りで現在時点で最新のraspbianを用いています。

pi@raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

UnixBench結果

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: raspberrypi: GNU/Linux
   OS: GNU/Linux -- 4.19.50-v7l+ -- #895 SMP Thu Jun 20 16:03:42 BST 2019
   Machine: armv7l (unknown)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   CPU 0: ARMv7 Processor rev 3 (v7l) (0.0 bogomips)

   CPU 1: ARMv7 Processor rev 3 (v7l) (0.0 bogomips)

   CPU 2: ARMv7 Processor rev 3 (v7l) (0.0 bogomips)

   CPU 3: ARMv7 Processor rev 3 (v7l) (0.0 bogomips)

   21:20:25 up 4 min,  2 users,  load average: 0.43, 0.31, 0.15; runlevel 5

------------------------------------------------------------------------
Benchmark Run: 木  7月 11 2019 21:20:25 - 21:49:43
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       10108266.1 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2391.7 MWIPS (9.6 s, 7 samples)
Execl Throughput                                908.6 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        112845.1 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           31478.7 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        319531.9 KBps  (30.0 s, 2 samples)
Pipe Throughput                              161087.1 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  48543.7 lps   (10.0 s, 7 samples)
Process Creation                               1919.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   2457.6 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    702.0 lpm   (60.1 s, 2 samples)
System Call Overhead                         495075.4 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   10108266.1    866.2
Double-Precision Whetstone                       55.0       2391.7    434.9
Execl Throughput                                 43.0        908.6    211.3
File Copy 1024 bufsize 2000 maxblocks          3960.0     112845.1    285.0
File Copy 256 bufsize 500 maxblocks            1655.0      31478.7    190.2
File Copy 4096 bufsize 8000 maxblocks          5800.0     319531.9    550.9
Pipe Throughput                               12440.0     161087.1    129.5
Pipe-based Context Switching                   4000.0      48543.7    121.4
Process Creation                                126.0       1919.9    152.4
Shell Scripts (1 concurrent)                     42.4       2457.6    579.6
Shell Scripts (8 concurrent)                      6.0        702.0   1170.1
System Call Overhead                          15000.0     495075.4    330.1
                                                                   ========
System Benchmarks Index Score                                         322.7

------------------------------------------------------------------------
Benchmark Run: 木  7月 11 2019 21:49:43 - 22:19:38
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       29366589.4 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     7098.4 MWIPS (12.8 s, 7 samples)
Execl Throughput                               2187.1 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        169230.2 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           45748.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        514405.5 KBps  (30.0 s, 2 samples)
Pipe Throughput                              520367.8 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 148603.5 lps   (10.0 s, 7 samples)
Process Creation                               4236.3 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   4446.5 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    592.2 lpm   (60.1 s, 2 samples)
System Call Overhead                        1608674.6 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   29366589.4   2516.4
Double-Precision Whetstone                       55.0       7098.4   1290.6
Execl Throughput                                 43.0       2187.1    508.6
File Copy 1024 bufsize 2000 maxblocks          3960.0     169230.2    427.3
File Copy 256 bufsize 500 maxblocks            1655.0      45748.5    276.4
File Copy 4096 bufsize 8000 maxblocks          5800.0     514405.5    886.9
Pipe Throughput                               12440.0     520367.8    418.3
Pipe-based Context Switching                   4000.0     148603.5    371.5
Process Creation                                126.0       4236.3    336.2
Shell Scripts (1 concurrent)                     42.4       4446.5   1048.7
Shell Scripts (8 concurrent)                      6.0        592.2    986.9
System Call Overhead                          15000.0    1608674.6   1072.4
                                                                   ========
System Benchmarks Index Score                                         681.5

Swarmの過去のチェックイン履歴をGoogleカレンダーに移行

少し前から Foursquare の Swarm アプリによるチェックイン履歴が Googleカレンダーに反映されなくなってしまいました。どうやら2019/03月頃に Foursquare のフィード が終了になってしまったとのことです。

とりいそぎフィードを使うのをやめてIFTTT経由でチェックイン時にGoogleカレンダーへ登録させるようにしたので問題はないのですが過去のチェックイン履歴も見えなくなってしまったので困りました。

しかたがないので Foursquare から履歴をエクスポートして、Googleカレンダーへインポートしてしまいました。手順をメモしておきます。

 

FoursquareへWebでログインし、「設定」ー＞「プライバシー設定」に「自分のデータをエクスポート」というボタンがあります。これを使うと少し待たされますがデータをダウンロードできるリンクがメールで送られてきます。私の場合は約１日で来ました。

ダウンロードするとzip形式の中には幾つかの CSV と JSON がありますが目的のものは "checkins.csv" です。これを展開します。

 

Googleカレンダーへそのままインポートできる形式ではなかったので変換が必要です。ここが一番面倒なところなのですが awk で変換してしまいました。

 

Googleカレンダーへ入れる情報

Google カレンダーへの予定の読み込み - カレンダー ヘルプ

詳細はこちらを参照。

必須ヘッダは Start Date, Start Time, Subject の３つですが、せっかくなので Location も入れておこうと思いました。ヘッダはこれを使います。

Start Date, Start Time, Subject, Location

 

FoursquareのCSVを変換

checkins.csv の中身は下記構成です。

前から2カラム目（createdAt）：日時情報
後から2カラム目（venue.url）：URL
後から3カラム目（venue.name）：チェックイン先の文字情報 

 チェックイン時にコメントを書いたかどうかで行によってカラムが異なります。

これちょっと衝撃的な仕様なのですがしかたありません。カラムの変動に影響を受けないように変換が必要です。

また、面倒なことに createdAt は unixtime で書かれています。年月日と時分 に分けてやらないといけません。

 

１．csv内の各ヘッダ行を削除する

"id","createdAt","type","timeZoneOffset"....  のようなヘッダが多数混ざり込んでいますのですっきり削除します。

awk -F ',' '! /\"id\"/' checkins.csv > work1

 

２．Googleカレンダーのヘッダに合わせて抽出する

こうやればcreatedAt , venue.name , venue.url の３つを取り出せました。

awk -F ',' '{print $2","$(NF-2)","$(NF-1);}' work1 > work2

 

３．csvの中から "" を削除する

viで開いて削除しました。お好きなエディタで一括置換しても同じだと思います。

viの場合はコマンドは、まあこんな感じです。

:%s/\"//g

 

４．unixtimeを変換する

"年/月/日 時:分" という形式に変換したかったのでこうしました。

awk -F ',' '{print strftime("%Y/%m/%d",$1)","strftime("%H:%M",$1)","$2","$3;}' work2 > fin.csv

 

５．最後にヘッダを先頭行に

このヘッダ行をファイル先頭にテキストエディタで書き込みます。

Start Date, Start Time, Subject, Location

これでインポート用のファイルは完成です。

 

Googleカレンダーへのインポート

WebからGoogleカレンダーへ行きます。「設定」の中に「インポート／エクスポート」というのがあるので、それを使って csv をアップロードしてカレンダーへインポートすることが出来ます。

私の場合は "Foursquare" という名前のカレンダーを予め新規で作っておき、そこへインポートしました。IFTTTでリアルタイムにチェックインを同期するのもこのカレンダーを指定しているので、見た目も色分け等できて綺麗です。

 

スマートウォッチ Withings Activité Pop の使い勝手

Amazonで Withings Activité Pop というスマートウォッチを購入しました。

かなりキレイでシュッとしたデザインにも関わらず、しっかりスマートウォッチでした。

f:id:uenoshin:20160127194548j:plain 【日本正規代理店品】Withings スマートウォッチ Activite Pop ( 歩数 / 消費カロリー / 移動距離 / 睡眠 / 50m防水 / 時間自動調整機能 ) Shark Grey 70080401

主な機能ですが、歩数計・睡眠トラッキング程度です。 この潔さがいいですね。スマートウォッチにありがちなメールや電話の"通知"だけしてもらっても別に嬉しくありませんし。

歩数計はスマホのアプリでも類似のことはできますが充電の持ちを気にしてしまうこともあって、ONにし忘れるため結局使わないのです。こちらの Activité Pop は常にトラッキングしてくれているのでONにし忘れることはありえません。この手のトラッキング系はやっぱりウェアラブルデバイスである腕時計にふさわしいものだと思いました。

Withings Health Mate というアプリをスマホにインストールし、Bluetooth経由で連携させることで時計合わせやトラッキングデータの同期ができます。同期したデータはPCからWebで見ることもできますし、使い勝手はかなりいいです。 消費カロリーのチェックもできますので、ダイエットをしているときなど運動量を気にしている場合にもちょうどよい感じです。私は健康診断で中性脂肪値が高いと出たので形から入った次第です。

電池はボタン電池CR2025です。約8ヶ月もつそうで、その後は自分で簡単に入れ替えできます。 充電を心配しなくて済むというストレスレス仕様が気に入りました。 家に帰ったときにたくさんのデバイスを充電する毎日にちょっと疲れていたので。

トラッキングされた歩数と睡眠のデータはこんな風に見えました。

f:id:uenoshin:20160127200054p:plain

あんまり寝てないし歩いてないですね。はい。

こういう生活習慣を知り、改善の目安を持てるという点でとてもいいものだと思いました。買って良かったです。使い続けようと思います。

AmazonLinuxでXアプリを動かす

SSHを使う時のターミナルソフトは TeraTerm が定番ですが、最近 mobaXTerm がお気に入りです。

MobaXterm free Xserver and tabbed SSH client for Windows

SSHだけでなくDOS窓やPowerShellとしても使えますし、SFTPも使えます。 なによりXServerになっているのでXアプリが使える事が最大の特徴です。 SSHでLinuxにログイン後、

$ firefox

のように打つだけでXアプリとしてfirefoxが立ち上がってきます。 いちいち別途XServerを立ち上げる手間もなく、mobaXtermひとつあればすべて賄える点で 私の中ではTeraTermやRLoginを超えました。

で、AWSのEC2で Amazon Linux のインスタンスを立ち上げた時にXクライアントが標準では 入ってなかったので調べてインストールしました。

$ sudo yum install xorg-x11-xauth.x86_64 xorg-x11-server-utils.x86_64 dbus-x11.x86_64

やってみると簡単なことでこれだけで良かったようです。 これでXアプリも動くようになりました。

モバイル端末としての Firefox OS

www.adventar.org

Firefox OS Advent Calendar 2015 の記事です。 今後の Firefox OS について思うこと、期待することを書いてみたいと思います。

Mozilla が Firefox OS をキャリア経由での販売を行わない旨の発表を行ったことは記憶に新しいと思います。 このことの真意はまだちょっと測りかねていますが、単にキャリアの独自サービスや、メーカ毎のハードウエアポーティングに開発リソースを割かないというだけで、Androidのようにそれぞれキャリアやメーカが自前で開発をすれば良いという意味と捉えるのが普通の解釈かと思いました。

Here is how Microsoft can push OS updates to Windows 10 Mobile without carriers now (and forever) | Windows Central

もしくは Microsoft が Windows 10 で類似の発表を行ったように、キャリアやメーカを介さず直接アップデートを提供する方式（Apple方式かと）に移行するということかもしれません。 おそらく前者のAndroid方式の方かと思いますが。。

Firefox OS の考察

昨今のクラウドサービスはその多くがWeb系技術を用いたものですのでそれを使うクライアントにはブラウザさえあればよく、シンクライアントとまでは行かないまでもそれに近い思想でブラウザベースのモバイル端末はとてもシンプルであり、余計なシステムリソースを使わない点で合理的であると言えます。

パワーがなくてもよいので低スペックな端末を安く入手することができることにつながります。

アプリにはweb型だけではなくインストール型もあり、Android や iOS のユーザから見ても親しみやすい仕組みになっています。Java屋さんや C++屋さん よりもHTMLの有識者は人口が多いため、アプリ開発者の間口が広く、開発者人口の増加が期待されています。

Firefox OS はデバイスを操作するための API が多数用意されているので従来プログラマがC,C++を駆使して書いていた処理を JavaScript で書くことができます。 C,C++が完全に置き換わる程、自由度が高いわけではなく凝ったことをやろうと思ったらそれなりに苦労することにはなりますが、そこそこ一般的なニーズに応える分には充実しています。 Firefox OS は低廉・軽量派のプラットフォームであり、web標準にマッチした"筋の良い"プラットフォームなので透明度が極めて高い点が訴求力だと言えます。

まとめると「ロースペック端末を安く買えてそこそこ使える」が特徴だと思います。

Firefox OS の弱点とユーザニーズ

日本の場合モバイル端末≒スマホ・タブレットであり、その用途はゲームとSNSが大半の模様です。 SNS は LINE や Facebook 等、もちろん Firefox OS でも利用可能です。
しかしながらゲームが大きな弱点になり得ます。

パズドラやモンスト、白猫プロジェクトなど、最近の人気ゲームはグラフィカルで処理も重いのでハイスペック端末の方がヌルサクに遊べます。私だけかもしれませんがスマホ購入を検討する時はCPUやメモリ量をどうしても気にしてしまいます。販売側も同様と見えて、カタログや広告には高性能をアピールしたものが多く見られます。 高性能高価格、低性能低価格 のように性能と価格で差別化したラインナップになっています。

Firefox OS の場合、Unity のアプリを動かすことも可能にはなるのでしょうが、元々のコンセプトから考えて端末にパワーがありません。 webサービスを前提にするFirefox OS の場合、端末側のスペックはそれほど意味がない事が多いのが一因なのでしょう。
Fx0 は実は十分に高性能なのですが、Snapdragon 400、1280×720、RAM1.5GB と、昨今のスマホと比べるとミドルレンジの部類です。Firefox OS であるからこそ、サクサク快適に使えているんでしょうね。 端末性能の微妙さと市場のシェアが低い事からだと思いますが、メジャータイトルは移植されていません。マーケットプレイスを見てもビッグなプロダクトは少なめです。開発費を投資できない現実があるのだと思います。

もともと Firefox OS は端末側のスペックをフルに使い倒すオプティマイズや、プロプライエタリな巨大アプリの開発を行うコンセプトではありませんでした。追随しようとしているようですがまだまだ途上にあるのが現実です。

現状、Firefox OS の弱点は「ハイスペック端末上でモダンでビッグなメジャータイトルが遊べない」ところにあり、その傾向は今後も続くと見る事ができます。

使われ方

「カメラで写真を撮ってSNSに投稿」「ニュース見る」「メール・メッセンジャー」のようなユースケースだけならもはや OS は出る幕もないので低廉なものが望ましいです。安価な Firefox OS 端末でなんの問題もありません。 ゲームをしない人はたくさんいるのでそういうライトユーザにとっては十分にメリットがあるでしょう。

でも、ビジネス的に数字を取れるのは課金ゲームです。 ゲームを実装する開発者にとって、自由度は必要です。別にオープンなweb仕様を求めておらずオレオレプロダクトでいいんです。どうせプロプライエタリですし。 Hello World が簡単に作れますよ、ではダメで、ビッグプロジェクトを組んで巨大なプロダクトが動作するプラットフォームでなければならないです。

ゲームをしないようなライトユーザなのに、なぜでしょうか、日本人は iPhone のような高いものを購入するのですよね。 大は小を兼ねますのでお金を出せる人には高性能の方が有利なのだと思います。

進化していく方向

電卓や電子辞書は今やスマホの一機能です。 書籍もスマホに取り込まれました。 ウォークマンも同様です。 携帯電話に出来る事はスマホでほぼ全部出来ます。 これまで持ち歩いていた電子デバイスのほぼ全てがスマホに吸収されつくしています。 持ち歩かなければならないデバイスを統合して軽くできることはユーザメリットが大きいです。

現在、スマホはPCに代わるものと認知されつつあり、スマホが向かう進化の方向は高機能高性能化が既定路線です。 そうやって従来PCの担ってきた機能までもがスマホへ取り込まれて行くことになります。

ハードウエアの高性能化とそれに追随できる OS とアプリによって、様々な機器の集合体になっているのが今のスマホであり、ウェアラブルをも巻き込んだハブになっています。

こういう方向で進化していこうとしている以上、スマホを舞台にして Firefox OS が勝ち残る未来はあんまり見えてこないところです。 むしろ得意分野に特化した方面に選択・集中するほうが望ましいのではないかと思います。

今後の期待

まだまだ Firefox OS には大きな期待を持っています。

特に組み込みソフトの分野です。 組み込みソフトでは軽量OSが必要なので Linux を使う事が多いのですが Yocto ベースに環境を作ってもそこにはろくなアプリフレームワークがありません。BSPはあってもアプリを動くようにするのが一苦労なのです。

Gonk の足回りを強化して Yocto Project と連携するなどして、多くのデバイスに容易にポーティングできる仕組みになってもらえると組み込み開発の生産性が激変することになるでしょう。 いまは Open Web Board や Chirimen のような限られたボード上でしか動かないと思いますが、 connected device に注力するとの話もあるようですし NVidia や TI や Renesas など多様なデバイスに簡単にポーティングできるようになれば組み込みソフトOSの未来を切り拓けるのではないでしょうか。

組み込みソフトは高機能高性能なアプリを載せませんし、素早くリリースする事を求められる、といった特徴があります。最近はIoTの一部としてweb技術を前提とする機器も多くなっています。量産する事も多いので低廉なハードウエアで動く事が前提です。 ブラウザベースなのに組み込み？って意外性はありますが、こうした特徴は実に Firefox OS にフィットしていると考えており今後の進化に期待したいところです。