2016年 02月 24日

ルンバをオフィシャルメンテナンスに出した

 -

5.0 / 5.0

2013年の3月に買ったルンバをオフィシャルメンテナンスに出しました。約3年ぐらい、平日は毎日稼動させていました。

最近どうもガタガタ、ガタガタと言うときがあり、調べてみると後退したり旋回するときに、片方のモーターが動いていないような挙動でした。前進のときは問題なく、特定の場合だけなります。

一応一通り分解して清掃はしてみましたが、おそらく一番の原因であろうタイヤユニットまわりは中まで分解できるようになっておらず、他全てを綺麗にしても直りませんでした。

この時点では2つの選択肢がありました。

  • タイヤユニットだけを買って交換する 約6000円 (ただし直るかわからない)
  • オフィシャルメンテナンスに出す 定額だと約13000円〜 (直る)

前進は大丈夫で後退だけがダメ、なおかつ片方だけという状態だったので、なんとなく内部のDCモータードライバ回路の一部がおかしいのではないかという疑いもありました。もしそうならタイヤユニットを買っても無駄になってしまいます。

ということで自力で頑張るのは早々に諦めてオフィシャルメンテナンスに出しました。

結果

(途中で「バッテリーもヘタっているから変えるか? 変えるなら18000円のプランになるが良いか?」という趣旨の電話がありました。差額が5000円なので、まぁどうせだからと思い18000円のプランに変えました。オフィシャルバッテリはそもそも10000円ぐらいするので差額5000円なら互換品なみに安い)

返ってきたルンバは全体的に綺麗になっていました。メンテナンスの結果のレポートによると

  • 内部基板ユニットの交換
  • タイヤユニットの交換
  • エッジクリーニングブラシユノットの交換
  • メインブラシユニットの交換
  • フィルタの交換
  • バッテリーの交換(新型のXLifeバッテリーになった)

という感じで、ダストボックスと本体以外ほとんど全部変わってました。内部基板ユニットの不具合がやはりあったみたいで(モータードライバかどうかはわかりませんが)、自力でどうにかできる範囲ではなかったので今回に関しては判断は正しかったようです。

バッテリの寿命も伸びたみたいなので、とりあえずこれであと2年ぐらいは元気に動いてくれることを期待します。

オフィシャルメンテナンスは高いか?

メンテナンス費用には送料も含まれています。だいたい往復で3000円ぐらいかかるとすると、約10000円(ブラシパック)/15000円(サービスパック)が実際の工費になります。

700シリーズ メインブラシ+フレキシブルブラシ + エッジブラシ1本 - iRobot (アイロボット)

iRobot (アイロボット)

3.0 / 5.0

メインブラシ及びエッジクリーニングブラシが約1500円

ルンバ(Roomba)iRobot(アイロボット) 700シリーズ専用フィルター2セット(4個) - アイロボット(IRobot)

アイロボット(IRobot)

3.0 / 5.0

フィルタが1セットあたり約600円

はブラシパックの場合必ず交換、サービスパックの場合は必要に応じて交換

Roomba ルンバ エンハンスドクリーニングヘッド 【並行輸入品】 - アイロボット(IRobot)

アイロボット(IRobot)

3.0 / 5.0

もし壊れているなら上のようなモジュール(6000円〜)が交換

ルンバ用バッテリー 日本企業による販売365日保証 長寿命2倍 長時間稼働2.5時間 ルンバ500 600 700 800 900シリーズ対応 5bt_ao - Orange Line

Orange Line

3.0 / 5.0

サービスパックの場合バッテリーが必ず交換 (↑これは互換品ですが)


ということで、単体として高いかというとそうでもなく、点検修理の工数を考えるとむしろお得ぐらいの価格設定です。


ただ、修理の場合実際あたまに浮かぶのは買い替えでしょう。別のルンバに買い替えるなら修理のほうが当然安くすみます。他社製品は今回検討しませんでしたが、もし安くていいのがあれば修理と競合しそうです。

Mockito の any(Class<?> clazz) や anyString() や他の any ナンチャラは型チェックはしない

any() 系のマッチャは常に「あらゆるオブジェクト」にマッチします。この挙動は Javadoc にも書いてあって、もしかすると将来的に変更するかも、みたいなことが書いてあります。

じゃあなんで any(Class) とか anyString() とかあるのか?という気持ちになるわけですが、これはたぶんオーバーロードで複数の選択肢がある場合に、ある特定のメソッドを確定するときに便利だからだ、と思います。

なお、あるクラスのインスタンスかどうかをチェックするマッチャは isA(Class clazz) のようです。

Arduino で一定時間ごとに何かをする interval クラス

一定時間で何かをする、といえばタイマーの割込みを使うことでしょうが、タイマーを使いたくないないし使えないということもあると思います。

そういうときループをぶんまわしながら、時刻などを比較して一定時間ごとに処理をするという方法をとったりすることがあります。今回はそれを簡単に書けるスニペットを考えたという話です。

他のライブラリでどうにかする

こういうことをするライブラリを調べてみると、Metro というのがあります。これは以下のようにして使うライブラリのようです。

Metro interval250 = Metro(250); 

void loop() {
    if (interval250.check()) {
        // ここで 250msごとの処理
    }
}

もちろん悪くはないのですが、変数宣言と実際の処理が分かれており、余計な変数を宣言する必要があってなんか嫌です。(変数名をいちいち考えたくないという意味です)

loop() でいきなり使える定期実行

そこで以下のようなスニペットを考えました。interval class が本体です。

template <uint16_t time>
class interval {
	uint32_t next_run = 0;

	template <class T>
	void _run(T func) {
		uint32_t now = millis();
		if (next_run < now) {
			func();
			next_run = now + time;
		}
	}

	interval() {}
public:

	template <class T>
	static void run(T func) {
		static interval<time> instance;
		instance._run(func);
	}
};

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

void loop() {
	interval<250>::run([]{
		Serial.println("250ms 1");
	});

	interval<250>::run([]{
		Serial.println("250ms 2");
	});

	interval<1000>::run([]{
		Serial.println("1000ms");
	});

}

loop() 内でいきなり適当な書きかたをするだけですみます。

interval クラス

事前準備 (グローバル変数やstatic変数を自力で宣言したり) をせず、いきなり静的な関数ないしメソッドを読んで使うことができるようにするため、以下のような感じになっています。

まず、interval クラスは time をテンプレート引数にとっているので、time ごとに別のクラスが作られます。

各 time を持つ interval クラスには、さらに引数 func の型をテンプレート引数にとる run() という static メソッドを持っています。

run() は内部で static 変数として interval

func には lambda 式を書くことを想定しています。lambda 式の型は書く度に違うものになるので、同じ time を持つ処理も複数書けます。

つまり、テンプレート引数を使うことで、グローバルな状態を複数作っています。自分で余計な変数を宣言せずに「状態」を持つためにはこのような小細工が必要なようです。

これにより、各 time と引数 func ごとに interval

2016年 02月 23日

自作 デジタル SWR 計(再) 2 | 方向性結合器の改善編

FT82-43 に20ターンでやってみましたが、結果が芳しくありませんでした。

そこで、FT82-61 に 30 ターンという、おそらくこれが最善だろうと思われる組合せでやってみることにしました。昔に

FT82-61 (AL= 79) のほうが透磁率がちょうど良さそうだけど、手元になかった。

http://lowreal.net/2014/11/11/1

と書いていました。このとき実はコアを買って巻くところまではやったのですが、実際に換装するところまでやっていませんでした。1年ちょっと越しの挑戦です。

結果

SWR / リターンロス

結合器自体の SWR/RL です。

全く問題ない感じです。

方向性など

FT82-43 T20
測定周波数 kHz IN [V] OUT [V] FWD REF IN [W] OUT [W] FWD [W] REF [W] Insertion Loss Coupling Isolation Directivity
1910 51 51 2.490 0.060 52.02 52.02 0.124002 0.000072 0.00 -26.23 -58.59 -32.36
7010 49 49 2.470 0.090 48.02 48.02 0.122018 0.000162 0.00 -25.95 -54.72 -28.77
28010 52 53 2.700 0.278 54.08 56.18 0.145800 0.001546 -0.17 -25.69 -45.44 -19.75
50010 55 52 2.970 0.530 60.50 54.08 0.176418 0.005618 0.49 -25.35 -40.32 -14.97
FT82-61 T30
測定周波数 kHz IN [V] OUT [V] FWD REF IN [W] OUT [W] FWD [W] REF [W] Insertion Loss Coupling Isolation Directivity
1910 49 49 1.671 0.004 48.02 48.02 0.055845 0.000000 0.00 -29.34 -81.76 -52.42
7010 49 49 1.666 0.005 48.02 48.02 0.055511 0.000001 0.00 -29.37 -79.82 -50.45
28010 52 53 1.850 0.008 54.08 56.18 0.068450 0.000001 -0.17 -28.98 -76.26 -47.28
50010 52 53 2.132 0.013 54.08 56.18 0.090908 0.000003 -0.17 -27.74 -72.04 -44.30


下側が FT82-61 での結果です。

50MHz でも 44dB とれています。 (SWR 計としては 25dB 以上なら良い)

精度

正確な信号源があるわけではないので精度というのもあれですが、以下のようになりました。

スペアナの 0dBm 出力と、FT-450D の 40W 出力を使って

solve([2188 * a + b = 2109, 1050 * a + b = 959], [a, b]);

という連立方程式を maxima に解かせてキャリブレーション値を求めています。KX3 の表示電力と出力電力はあんまり信用していないのでキャリブレーションに入れていません。KX3 以外では誤差が10%範囲に納まっています。

仕様変更

30ターンにしたので、カップリングは -29.54dB になっています。アッテネータとあわせて 45.64dB の減衰。-26.36〜61.64dBm (2μW〜1458W)

感想

センサー部分としては十分上出来になったと思います。すくなくとも前回作ったときよりは、かなり良くなりました。

これで I2C 接続の SWR 計ができたことになるので、インターフェイスをうまいこと作ってあげたいという気持ちになりました。

2016年 02月 22日

自作 デジタル SWR 計(再) | ログアンプを使いQRP〜1KWまで

なんとなくもう一台を作りたくなったので作っています。実は基板自体はだいぶ前(数ヶ月以上前)に作っておいたのですが、設計ミスがあったりして面倒なのでちゃんと作りはじめてませんでした。

AD8307

AD8307を使ってログアンプ検波するバージョンの SWR 計の例があることは知っていましたが、前回はそこまですることはないと思ってとりあえず簡単な方法で作りました

というのもログアンプは大変高価だからです。秋月でAD8307のDIP版が売っていますが、単価が1100円します。なお DigiKey で買うともっと高価なので、秋月は安いほうです。

(最近知りましたが中華性AD8307というセカンドソース品、というよりコピー品があり、こちらは単価が50円!!と激安のようです。SOICで、ebay で手に入ります)

方向性結合器 + 検波 + ADC

例の回路をほぼ完全にパクって実装しました。

方向性結合器は、タンデムマッチで、FT82-43 を使い、20T にしてみました (26.02dB のカップラに)。線間容量を減らして、高い周波数での特性が改善しないか?と思い巻数を減らしています。#43 は透磁率が高いので、多少巻数を減らしてもインピーダンスは高いままですが、ロスは多くなるはずです。

検波部は結合器からの出力をアッテネータ(16.1dB)を通し、インピーダンス変換を行なって AD8307 に入力しています。AD8307 のオフセットや切片調整はしていないので、25mV/dB の出力にはるはずです。

方向性結合器で 26.02dB、アッテネータで16.1dBなので、AD8307 には 42.12dB 減衰された信号が入力されます。言いかえると、AD8307の入力範囲は -72〜+16dBm ですから、-29.88〜+58.12dBm の入力範囲 (約1μW〜648W) にシフトしたことになります。

ADC は ADS1015 という 4ch + PGA 付き I2C デバイスにしてみました。ここは入手性の問題からオリジナルと違います。

実装

最初は方向性結合器の部分も基板を起こしていましたが、どうも作りにくいので立体配線に変えました。2つのトロイダルコアの間に容量結合防止のためのGNDを立てたいわけですが、プリント基板だとかえって面倒でした。

そんなこともあろうかと、基板を作る段階で途中で切って使えるような感じにしておいたので良かったです。

検証

作ったはいいのですが、どうもうまくいかず悩みました。

一つはコイルを逆付けしていてまともに方向性結合器として動いていなかったのが原因でした。

もう一つはAD8307の出力の問題で、どうしても入力電力から計算される出力電圧が出ず、未だ完全に理由がわかっていません。

AD8307 の出力

最初は 3.3V で動かしていたのですが、どうしても途中から出力電圧が上がりませんでした。定格上では 3.3V でも +10dBm までは入力可能のはずなのですが、-2dBm ぐらいから出力が上がらなくなり、全くよくわかりませんでした。

5V で動かしてみたところ、とりあえずこれは解決したように見えました。

しかし電源電圧を 5V に変えても、入力電力に応じた出力電圧にならず難儀しました。どうしても 25mV/dB の傾きになっておらず、オフセットが含まれているように見えました。切片調整もしていないし、オフセットがどこから入っているのかもわかりませんでした。

結局これはキャリブレーションと称してプログラム上で補正をかけることにしました。どっちにしろ 25mV/dB の傾きは定格上でも 23〜27mV/dB の範囲があるので調整を入れなければなりません。

ということで、適当に係数を求めたら、だいたいそれっぽい値が出るようにはなりました。

正確な電力を計る方法がないので、一定以上は調整しようがありません。

Google Spreadsheet に実測と理想を書いて比較してがんばりました。。。

方向性結合器

追記:FT82-61 を使ったバージョンに変更しました。
自作 デジタル SWR 計(再) 2 | 方向性結合器の改善編 | tech - 氾濫原

SWR はこんな感じでした

SWR だとよくわからないので、リターンロスでみるとこんな感じです

肝心のディレクティビティなどの特性です。蓋をあけた状態で電圧をオシロで計って50Ω換算で出しています。残念ながら前回作ったものよりも良くありません。

ログアンプの効果

ダイオード検波の場合、微小電力ではダイオードの Vf を超えることができず、それはそのまま誤差になります。

ログアンプ検波することで、ダイオード検波の欠点はなくなり、微小電力から計れるようになりました。具体的には、スペアナのトラッキングジェネレータ出力を 0dBm にして計っても、多少の誤差はありますがちゃんと 1mW ぐらいの値が出てきます。

通常送信機の電力測定ではこんな微小電力まで計れる必要は特にないかと思いますが、SWR 計として反射電力を計りたい場合、SWR が低いときには反射電力も非常に小さくなりますから、ダイナミックレンジの広い測定が必要になります。ダイオード検波と通常のリニアなADCを使うことに対する最大のメリットはここだと思います。

方向性結合器部分はまだ追試が必要

SWR計としてまとめるのではなく、方向性結合器として一旦作って評価をしてから、検波回路を外付けするほうが安定したものが作れそうです。次はそのようにしたいと思います。

制御

インターフェイスはまともに作っていなくて、Arduino で I2C から値を呼んで計算させてシリアルに出力だけさせてテストしていました。今のところまだ実用にはなっていません。

2016年 02月 20日

mbed のフレームワークの温度感

mbed の API 経由でできる以上のことをやろうとする場合、結局 mbed 側で何をやっているか (どのAPIでどのレジスタが変更されるか) は理解していないといけない。

つまり mbed のラッパーのソースコードが手元にないと、プログラムできない。しかし実際のコードがどこにあるのかわかりにくい。

基本的には mbed のライブラリ経由でできることが殆どだとは思うが、例えば高度なスリープを行いたいとか、ウォッチドッグタイマを使いたいとなると、低レベルなレジスタアクセスが必須になる。

ghq で全部落としとくぞ

Mercurial (hg) のレポジトリとして公開されている。

 ghq get https://cho45@developer.mbed.org/users/mbed_official/code/mbed-src/
 ghq get https://cho45@developer.mbed.org/users/mbed_official/code/mbed/ 

してmbed 関係のヘッダと実装を手元に置いておく

mbed LPC1114

メインのレポジトリはこっちなのですが、ヘッダファイルだけ
https://developer.mbed.org/users/mbed_official/code/mbed/file/252557024ec3/TARGET_LPC1114/TARGET_NXP/TARGET_LPC11XX_11CXX/TARGET_LPC11XX

実装は mbed-src にあった。
https://developer.mbed.org/users/mbed_official/code/mbed-src/file/a11c0372f0ba/targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/TARGET_LPC11XX/system_LPC11xx.c

mbed 関係ない部分

LPC1114 のリファンレス
http://www.nxp-lpc.com/images/LPC111x_UM_Rev.00.15_Japanese.pdf

NXP による LPC の定数定義
https://developer.mbed.org/users/mbed_official/code/mbed/file/252557024ec3/TARGET_LPC1114/LPC11xx.h

2016年 02月 19日

トランジスタ技術 2016年 2月号 の GPS 特集

トランジスタ技術 2016年 2月号 - トランジスタ技術編集部

トランジスタ技術編集部

3.0 / 5.0

ここ1ヶ月ぐらい GPSDO に興味があって調べていたのですが、先月のトランジスタ技術がまさにGPSの特集だったようでした。

なんか知らずに流行りに乗ったみたいでかっこわるい…… というのはおいといて、おもしろそうなので買って読んでみました。

GPSDO については1記事だけでした。しかしMCUなしでの製作という、男らしい感じなのですが、残念ながらあんまり参考になりませんでした…… 使っているモジュールはちょっと前に買ってみたNEO-6Mで親近感がありました (というか1PPS出せて安いのをebayで探すとこれが最安なので第一候補になるわけですが)

ublox のモジュールは TIMEPULSE ピンに 1PPS に限らず安いものでも10kHzぐらいまで可変で出せるのですが、製作記事でもこの機能を使っていました (MCUを使わないことによる副作用として)。個人的にはこの機能を使うのはいまいちというか、他のGPSモジュールとの互換性がなくなるのがなあと思ってしまいます。

読んでていて疑問に思った点

  • 出力にバンドパスフィルタをつけてサイン波にしているのは?
    • 普通はサイン波で出すから?
    • 高調波成分が含まれるのが嫌?
    • 矩形波出力で立ちあがりを高速にしたほうがクロックとして有利なイメージがあるけどそうではない?

そもそも基準クロックというのに疎いので根本的なところがよくわかっておらず難しい。

出力を4分配にしているところで、バッファ+トロイダルコアを4つ使って分配しつつ直流的に?アイソレーションしているみたいでしたが、1つのバッファアンプ+ハイブリッドのほうが部品点数は減りそうだけど、うまくいかないのだろうか?とか机上の空論を考えてました。

精密なAD変換器のような非常に敏感な回路などではこの問題を避けるために、矩形波の代わりに正弦波をタイミング基準として使用する。

https://ja.wikipedia.org/wiki/%E7%9F%A9%E5%BD%A2%E6%B3%A2

Wikipedia にも書いてありましたが、クロックの高調波の影響を排除するために正弦波を使うんですね。無知でした。

その他

現在 GPS に載っている発振器のほとんどがルビジウムオシレータでびっくりしました。なんとなく全てセシウム原子時計が載っていると思い込んでいました。

AD9851 DDS モジュールを LPC1114/mbed と

AD9851 は Arduino で一度動かしてみましたが、LPC1114/mbed な環境でも動かしてみました。


DDS モジュールの定格は5Vですが、3.3Vで動かしてみています。振幅は当然減りますが、ちゃんと70MHzぐらいまでは波形が確認できました。

コード

Arduino のコードとほぼ一緒です。というか殆ど正規表現で置換しただけで動かすことができました。GPIO の操作だけなので本当に頭を一切使わずに移植できました。

GCC かつ -std=c++14 な環境なため mbed のオンラインコンパイラではコンパイルできないと思います (すこし修正すればいけるはずですが C++14 が使えない環境に興味がないので……)

また、なんとなくシリアル経由で周波数を変えるインターフェイスにしてみました。mbed のライブラリに CircularBuffer があるので簡単です。C++ の STL に circular buffer / ring buffer 相当のものがないのが不思議なんですが、いつか入る予定はあるんでしょうかね?

#include "mbed.h"
#include <CircularBuffer.h>
#include <cstdlib>
#include <string>

template <uint32_t CLKIN, bool MULTIPLIER>
class AD9851 {
	static constexpr double PHASE_FACTOR = 0x100000000 / (double)(CLKIN * (MULTIPLIER ? 6 : 1));

	DigitalOut PIN_DATA;
	DigitalOut PIN_FQ_UD;
	DigitalOut PIN_W_CLK;
	DigitalOut PIN_RESET;

	void serial_write(uint32_t freq, uint8_t phase, bool powerdown) {
		// freq (delta phase)
		for (int i = 0; i < 32; i++) {
			PIN_DATA = (freq>>i & 1);
			PIN_W_CLK = 1; wait_us(4);
			PIN_W_CLK = 0; wait_us(4);
		}

		// control bits
		PIN_DATA = MULTIPLIER ? 1 : 0;
		PIN_W_CLK = 1; wait_us(4);
		PIN_W_CLK = 0; wait_us(4);
		PIN_DATA = 0;
		PIN_W_CLK = 1; wait_us(4);
		PIN_W_CLK = 0; wait_us(4);

		// powerdown
		PIN_DATA = powerdown ? 1 : 0;
		PIN_W_CLK = 1; wait_us(4);
		PIN_W_CLK = 0; wait_us(4);

		// phase
		for (int i = 0; i < 5; i++) {
			PIN_DATA = (phase>>i & 1);
			PIN_W_CLK = 1; wait_us(4);
			PIN_W_CLK = 0; wait_us(4);
		}

		PIN_FQ_UD = 1; wait_us(4);
		PIN_FQ_UD = 0; wait_us(4);
	}

public:
	AD9851(
			PinName data,
			PinName fq_ud,
			PinName w_clk,
			PinName reset
		) :
			PIN_DATA(DigitalOut(data)),
			PIN_FQ_UD(DigitalOut(fq_ud)),
			PIN_W_CLK(DigitalOut(w_clk)),
			PIN_RESET(DigitalOut(reset))
	{
		PIN_DATA = 0;
		PIN_FQ_UD = 0;
		PIN_W_CLK = 0;
		PIN_RESET = 0;
	}

	/**
	 * W0 ... W31  -> Freq (LSB first)
	 * W32, W33    -> Control (for factory test)
	 * W34         -> Power-Down
	 * W35 ... W39 -> Phase (LSB first)
	 */

	void reset() {
		// ensure low
		PIN_DATA = 0;
		PIN_FQ_UD = 0;
		PIN_W_CLK = 0;

		// reset
		PIN_RESET = 1; wait(1);
		PIN_RESET = 0; wait(1);

		// reset to serial mode
		// Pins of D0, D1 = 1, D2 = 0 for serial mode
		PIN_W_CLK = 1; wait_us(4);
		PIN_W_CLK = 0; wait_us(4);

		PIN_FQ_UD = 1; wait_us(4);
		PIN_FQ_UD = 0; wait_us(4);
	}

	void set_frequency(uint32_t frequency) {
		set_frequency(frequency, 0);
	}

	void set_frequency(uint32_t frequency, uint8_t phase) {
		uint32_t deltaPhase = PHASE_FACTOR * frequency;
		serial_write(deltaPhase, phase, 0);
	}

	void powerdown() {
		serial_write(0, 0, 1);
	}
};

AD9851<30000000, true> ad9851(/*data*/dp28, /*fq_ud*/dp26, /*w_clk*/dp25, /*reset*/dp1);

//AnalogIn adc1(dp9);
//AnalogIn adc2(dp10);
//AnalogIn adc3(dp11);
//AnalogIn adc4(dp13);

Serial serial(USBTX, USBRX);

CircularBuffer<char, 80> serial_buffer;

int main() {
	serial.baud(115200);
	serial.printf("init\n");

	ad9851.reset();
	ad9851.set_frequency(10e6);

	for (;;) {
		if (serial.readable()) {
			char c = serial.getc();
			if (c == 0x0D) continue; // ignore CR
			if (c == 0x0A) { // treat LF as line end
				std::string line(80, '\0');
				line.clear();

				char c;
				while (serial_buffer.pop(c)) {
					line += c;
				}
				serial_buffer.reset();

				serial.printf("GOT: %s\n", line.c_str());

				uint32_t new_freq = std::atoi(line.c_str()) * 1e6;
				ad9851.set_frequency(new_freq);
				continue;
			}

			serial_buffer.push(c);
		}
	}
	return 0;
}

メモ: mbed 移植正規表現

S/digitalWrite\(([^,]+), ([^)]+)\)/\1 = \2/
s/delayMicroseconds/wait_us/g
s/delay/wait/g

未確認で進行形を最高と確認できるアマゾンプライムビデオ

アマゾンプライムビデオがはじまったのはもちろん知ってはいましたが「PC で見れてもなぁ」と思ってました。PC で動画を見る習慣がないので結局見ません。

しかし PS4 で直接見れることに気付いて、ただただ、最高という気持ちに変わりました。

まぁアマゾンプライムビデオとかは些細なことで、未確認で進行形を見なおしてるんですが、最高です。最高です。小紅は最高に可愛い。