コードレス掃除機の充電器

２年以上前に買ったコードレス掃除機のバッテリ充電器が壊れた。
接続端子のパーツが外れて、傾いている。

装置を振ると「カラカラ」音がする。固定用の部品が折れたようだ。
このままでは充電できないし、この掃除機バッテリは非常用電源として使うための装置を自作しており、まだまだ使いたい。
ついでに、明日大停電級の災害がおきたら、せっかくの努力が肝心な時に役に立たないということになる。

もう保証期間は終わっている。
修理をお願いしても新品を買うのを勧められるのがオチだろう。通販で探してみたけど、おおよそ8,000円ちょい。安いとは言えない。
捨てるなら、その前に自分で修理できるか見てみる。分解すると黒いプラスチックの破片が出てきた。

そして、端子のパーツの固定部分がやはり破断していた。

２箇所をネジで固定していたようだが、両方共部品が粉々に割れていた。
元々がどんな形だったのかを知るために、大きめの破片を集めて接着剤で貼り合わせてみた。
ネジで固定するための部分のようだ。

集めた破片には、1mm以下の小さな粒もいくつかあった。流石にそれらは貼り合わせられない。
何故こんなに小さく割れたのだろう？にわかには信じがたい。

修理できたとしても、原因がわからなければ、繰り返すことになる。
プラスチックは、負荷が加わっていると疲労が蓄積して破断するときがある。バッテリ挿入時に接続端子部分に下向きに負荷がかかる。その負荷を２本のネジだけで受けていた。
バッテリの重さを支えるだけなら大した負荷ではないが、しっかり確実に挿入するために「グッ」と押し込むようにしていた。
その負荷には耐えられなかったと考えられる。(これで8,000円ですか？)

バッテリの押し込みでかかる負荷は、下方向だ。
その方向の負荷を、もっと広い面で分散して受けるようにすれば、割れないかもしれないと期待できる。

というわけで、今はなき近所のビバホームで以前買った木っ端切れを加工して、負荷を受ける部品を作ってみた。

(写真を撮影していなかったので、全部作った後で分解して撮影した)

この木の部品は、土台になる黒いプラスチック部品にネジ止めする。
ネジは、自宅にあった適当なやつだ。何かを買った時についていたあまりのネジだと思う。
4mmタッピングのトラスネジだ。長さが25mmでちょうどよかったのでこれにした。木の引っ掛かり部分の中までネジが入ることになる。

ネジの位置を決める。
黒い部品なので、線が描けない(描けても見えない)。
とりあえず、マスキングテープを張って、その上に線を書いた。

ネジで固定とはいえ、元々あったネジの支柱にも引っかかるようにしてある。負担を分散させるためだ。
支柱は15度傾いているので、15度傾けて穴を開けるための土台も作った。

(これも撮影していなかったので、後から撮影した)

ここまでくれば後は組み立てだ。
土台と木製部品をネジでしっかりと固定する。

加工は、先日購入した丸ノコ盤と以前からあるボール盤を使って行った。丸ノコ盤については、近い将来記事にするかも。

これで、下向きの負荷を受けることができるが、前後方向にも固定しないと、外れてしまう。
変なことをしない限り、前後方向の負荷は少ないので、いくつかの小さなネジで固定することにした。
このネジもうちにあった適当な真鍮の木ネジ。

(洗濯機の脱水がうるさい)
縦方向の負荷は木で受け止めているので、わずかに遊びを残して締めてある。
ネジで締め付け過ぎると、またプラスチックが割れてしまうかもしれないと考えたからだ。

とりあえず、また使えるようになった。
とはいえ、また壊れてしまうかもしれない。その時はもう少し工夫しよう。

シンクロナイズド・オフピーク通勤

2020年6月以降、5:30に起きて、オフピーク通勤のために１時間早くウチを出ている。

今日は少し遅れ気味に駅についたのだが、駅の周りにも、ホーム上も人が多かった。
当初、微妙に遅れたからからかな...？ぐらいに軽く考えていた。
すると、府中本町駅で発煙・ボヤ騒ぎがあったため、電車が遅れているという放送があった。
時間がかかりそうな気がしたので、職場に「遅れます」メールを送った。

しばらく出発しなかったので、だんだん乗客が増えていった。
1つ駅を移動して、数分待つの繰り返しで、なかなか進まないし、どんどん乗客が増える。
しまいには、東所沢駅で折り返し運転にダイヤを変更するという放送があった。
東所沢駅は、すでにたくさんの乗客が待っている。そこにこの電車が到着すれば、ホームは人があふれるだろう。
わざわざオフピーク通勤で密を避けているのに、これでは本末転倒だ。

折り返し運転のため、下りホームに電車は到着した。
案の定、上りホームはすでに人がいっぱいだったが、下りホームはあまり人はいなかったので、身動きができないほど混む前に駅を出た。
出る前に振り返ると、上りホーム側の階段の上まで行列ができていた。
密を避けるべきなのは解っていても、どうしても早く到着しないといけない人もいるだろう。

私は多少遅れてもかまわない仕事だ。私がこの激混みを避けることで、多少なりとも密度が下がるだろう。
ということで、東所沢駅外のモスバーガに入って、コーヒーを飲みながら30分待った。
「異常な密度なので遅れる」メールを、職場に入れておいた。

30分後に、ホームに行くとガラガラ。
この時間は、オフピークではない通常シフトの時に乗る時間なのに、乗客が極端に少ない。
どうやら、みんな「右へならえ」で、シンクロナイズド・オフピークしていたようだ。
さらにシンクロして、ボヤ騒ぎまでおきたので、普段よりも超高密度激混み地獄になっていたようだ。

コロナ後は新しい世界？

コロナのワクチンが開発されて、昔の生活が戻ってくる。
そのように期待したいが、新しい世界は何処へ？

去年からの困難を「コロナ危機」と考えれば、出口が見えてきたと言える。
しかし、「世界的パンデミック危機」と考えると、また別の感染症が原因で発生する可能性がある。
コロナが終わったとしても、感染症との戦いは終わらない。

だから、それに対応した強い生活スタイル、強い社会にしていくことが必要だろう。
解っていても難しい。理想を掲げても、すぐには実行不可能なこともある。だから、一時的に逃げるのもありだろう。

とはいえ、長期的な視点で新しい世界を作っていくべきだ。
失敗を繰り返し、失敗を受け入れて続けていけば、いつかは到達できるだろう。

あけましておめでとう

大晦日になって、国内の一日あたりのコロナ感染者数の記録更新。いよいよ非常事態宣言発令かという危機的状況で、今年は始まった。
度重なる大災害も、助け合い精神で乗り越えてきた。しかし、疫病はその助け合いを制限してしまう。
どんなに社会が発展しようが、結局、自助努力が重要だ。

問題に対処するためには、まずその問題をしっかり明確に理解しなければならない。
人は弱いもので、周りのせいにして誤魔化しがちだ。認めたくないものでも、客観性をもって正面から問題に対峙するべきだ。
私は時々「問題は自分の失敗にある」と堂々と認めるため、「開き直っている！」と文句を言われることがある。時には「絶対にこっちの失敗を認めたらダメだ」と怒られることすらある。

余裕があるうちは、「誤魔化し」でも何とかなる。
しかし、余裕がなくなると、一気に吹き出してきて、手が付けられないくらいの大きな問題になることが多い。
だから、普段から問題に対処しておくべきだ。

---

去年は、色々あった。
こういうときは、問題点を認識するチャンスだ。危機的状況下では、普段無視している問題点も見えたりする。
せっかく見えたのなら、どんどん対処しておくのが良い。
中古とはいえ新しいPCやプリンタを買ったり、棚やテーブルを買って自宅での作業環境の整理をしたり、電子辞書利用環境を構築したり、ダウンライトに普通のライトを付けるための工夫をしたり、掃除機の動力ヘッドを修理したり...。

人が集まれないために仕事がなくなる業界がある反面、人が集まれないためにお金を払わなくなっている仕事もある(特に公共の仕事は、そういう事になりがち)。
「余った予算で新製品を。」ということで、去年8月頃から急に「早く作れ！早く作れ！」になった(個人的な収入は変わらない)。
急ぐ気持ちはわかるが、同時に２製品の開発を要求され、しかもハードウエア技術者も別の２製品をやっているので、最初の立ち上げ時の共同作業ができず、余計に時間がかかる。
２つ同時に開発すれば、一方の作業が停滞している時に、別の作業をすることで効率が上げられるという考えだろうと思うが、実際にはそうはならない。
作業内容がコロコロかわると、どこまで作業していたか忘れてしまい、思い出すために作業をやり直したり、やったつもりでやってなかったり、あるいはもっと単純に失敗したりする。結局２つ同時に作業することで、１つずつ順番に作業するよりも、作業量が増え、浪費する時間的リソースも増える。
要求に答えて早く作ろうと１人で焦っても、共同作業をするには１人ではどうにもならない。
イライラがどんどん増えるだけだ。

非常にドタバタしている状態だからこそ、問題点がよく見えた。できる範囲で環境の改善に取り組んだ。
振り返ってみれば、見えていなかった問題への対処が、去年の今頃よりも多く進んだ。
忙しいのに、逃げずに努力を続けた。
今年は、それらが収穫になるかも。期待しよう。

カラフルなカリフラワー

紫色のカリフラワーが売っていた。

面白そうなので、買ってきた。
おそらく、アントシアニンの色だろう。

この紫カリフラワーの色からは、全く想像できないかもしれないけど、アントシアニンは、イチゴの色素でもある。
実はアントシアニンは、酸性で赤、アルカリ性で青や緑になる色素だ。
イチゴが真っ赤なのは、酸性でアントシアニンが濃いためだ。ネットで検索すれば青いイチゴを見ることもできるだろう。この青いイチゴは全く味がしないらしい。すなわちイチゴ独特の酸味が無いため、青くなるのだ。

青い食べ物は少ないせいか、なんとも不気味に感じる。
背後に写る重曹(炭酸水素ナトリウム)の水溶液は、アルカリ性だ。
この紫カリフラワーを重曹で茹でれば、青いカリフラワーになるだろう。

「重曹で茹で」だけでなく、「ポッカ100レモン茹で」「塩茹で」をして、色の違いを見てみよう。

左から、薄紫が「ポッカ100レモン」、紫が「塩」、水色が「重曹」だ。
レモン汁が少なかったためか、赤がいまいち。
塩茹ででも、少し青みが強くなった感じがする。
重曹は、シアンっぽい色になった。綺麗な言い方をすれば「ティファニーのカリフラワー」だ。
(ネパール人なら、ティファニーの氷フライ)

もちろん、全部マヨネーズをかけて食べた。
味はどれも変わらなかった(レモン汁も重曹もそんなにたくさん入れてない)。
食べきらなかったぶんは、甘酢漬けにして冷蔵庫に置いていた。

数日後に見たら、すごいピンク色になっていた。

アメリカ人のケーキのような蛍光ピンク。
すごいピンクだなと思いながら、ぱくぱく食べてしまって、途中で「写真をとっておけば良かった！」と気がついて、慌てて残ったものを撮影した。

---

2021/01/04 追記

青いイチゴはフェイクらしい。 今日になって、数年前に読んだ記事を探してみたが見つからず、「青いイチゴ」や"blue strawberry"でGooglingしまくったら、Blue Strawberry, Real or Myth?を見つけた。 農作物を寒冷環境に適応させるために、Arctic flounder(北極のヒラメ)の不凍糖タンパク質の遺伝子を、植物に移植する事が20年も前から行われていたらしい。 しかしながら、それでイチゴが青くなるわけではない。 青いイチゴの写真は、「不凍」から連想する自動車用のクーラントの色に、Photoshoppingしてつくられたイメージだそうだ。 「アントシアニンは、アルカリで青くなる」という知識があったせいで、騙されてしまった。 それにしても、なんとフェイクニュースの多いことか。

はやぶさ2が帰ってきた

はやぶさ2が帰ってきた。
22万キロで切り離したカプセルが予定通りウーメラ砂漠に降りた。
後は、カプセルに砂が入っているかどうかだ。
宇宙一の運び屋だから、何とかなるかな。

先代はやぶさは、満身創痍で最後は神風ミッションになってしまったが、はやぶさ2は新たな旅に出た。
使えるものは、どんどん使って、経験を積もう。

はやぶさ2は、うまく行き過ぎるぐらいうまく行った。
はやぶさ1帰還後、2年で用意したため、結果として枯れた技術が多かったのかもしれない。
とはいえ、海外のローバーを持っていったり、インパクターを使ったり、インパクターの撮影用に子機を使ったり、着陸の瞬間も撮影したり、新しい技術もあった。
新たな挑戦に成功するたびに、感動した。
無理をしないで、地道に、こまめに、慎重であったからこそ、挑戦もできた。成果につながった。

真面目にやることが、成功への近道であることを、改めて感じた。
徐々に寿命が来るだろうが、次の10年も活躍が楽しみだ。

とりあえず、ありがとう。はやぶさ2。

Ubuntu の日本語入力って…

VirtualBoxで動かしている Ubuntu Budgie 20.04 の更新をしたら、SystemTray上のiBusのアイコンが表示されなくなった。
直接入力と日本語入力の区別をそのiBusアイコンで行っていたので、なくなると困る。

なぜ表示されなくなったのかと調べてみた。budgie-wmがibus-daemonを'--panel disable'付きで起動するようになっていた。
budgie-vmは、budgie-coreパッケージに入っている。ソースパッケージを入手して、'--panel disable'を外して自分でビルドし直せば良いのだが...。
そもそも最近はiBusで直接入力と日本語入力の切り替えをするのではなく、入力ソースを切り替える方式になりつつある。
実際にはだいぶ前(14.04?16.04?)からその方向になっていた。

apt-get changelogを見ると、

budgie-desktop (10.5.1-6ubuntu0.2) focal; urgency=medium

  * Bug-fix
    Allow non-xkb layouts to appear and chosen in the keyboard applet
    show-non-xkb-layouts.patch (LP: #1902317)
    Display spotify cover-art
    fix-spotify-album-art.patch (LP: #1895720)
    Fix broken chrome-based notifications
    chromium-browser-notifications.patch (LP: #1895697)

 -- David Mohammed <fossfreedom@ubuntu.com>  Fri, 30 Oct 2020 22:14:52 +0000

この１行目のnon-xkbの件は、入力ソースの切換ができるようになったことを示している。
逆に言えば、正常に動作していなかったのだ。
そのため、方向は逆だと解ってはいるものの、使える手法としてiBusでの切り替えを使っていた。

今回使えるようになったのだが、ibus-mozcのデフォルト入力が直接入力なので、入力ソースを英文字入力からibusに切り替えてもデフォルトでは日本語入力にならない。起動後にibusの入力を日本語にしなければならない。
すなわち、ibusの切り替えも必要なのだ。

結局、budgie-wmを改造してSystemTrayにibusアイコンが表示されるようにしてしまった。逆方向の改造だ。
おそらく、正しくないやり方なので、あえてその詳細は書かない。

一体どうするのが正解なのか？

Ubuntu 20.04 で Raspberry Pi 3B のUSBブートを有効にする

以前買った Raspberry Pi 3B で時々遊んでいる。
最初はRaspbianを入れていたが、途中でLubuntuにしていたが、最近では、Ubuntu20.04を使っている。PCでもUbuntuなので、統一しておいたほうが便利だからだ(とはいえ、PCはbionic、RaspberryPiはfocal)。

以前、PCでUSB Bootable Ubuntuを、普通に使っていたことがある。8GBのUSBメモリだったが、毎日使っていると１ヶ月ぐらいでUSBメモリでエラーが出るようになっていた。
リムーバブルメディアの寿命は、基本的にそんなものだ。MicroSDだったとしても、大して変わらない。
しかしながら、SSDは多少事情が異なる。
SSDは頻繁に読み書きする事を前提で設計されているので、寿命が長い。
最近のUSB接続のSSDの容量が、512MBではなく480MBなど少なめの中途半端な容量になっているのは、おそらく代替え領域などを多めに確保しているためだろう(未確認。詳細不明)。
RaspberryPiもUSBポートがあるので、USB接続のSSDが使える。
本格的に使うなら１ヶ月で壊れるものは使いにくい。SSDの方がMicroSDよりもいい。
以前、どこかでRaspberryPi3BでもUSBブートできるという記事を読んでいたので、それをやってみようと思った。

---

もう一度調べ直すと、おおよそ

• OTP(One Time Programable)領域の特定のビットをセットする。
• セットするには、/boot/config.txtの末尾に、"program_usb_boot_mode=1"を書き込んでリブートする。
• 確認には、vcgencmdコマンドを使う。

ということだ。難しそうな所はない。
過去に調べた時、そのような操作をしたような気もするが、不可逆的なので躊躇していたようにも思う。Raspbianを使っていた頃のことなので、もうだいぶ時間が経っている。記憶があやふやだ。

確認しようとして、Ubuntu20.04で、vcgencmdを起動しようとしたら、動かない。
focal(Ubuntu20.04)には、vcgencmdが入っていないのだ。
ネットで調べると、PPAを設定して入れる方法が見つかったが、focalでは動かない。focal用のものが用意されていないようだ。
OTPの物理アドレスが解ればアクセスできるかと思ってそれを調べたが、この記事の中ぐらいに、以下のような書き込みを見つけた。

That's impossible to do because of the closed source GPU code. 
There's no user API to access any OTP memory.

自分なりに訳すと、

それを行うのは不可能だ。なぜならクローズドソースのGPUコードだからだ。
あらゆるOTPメモリをアクセスするユーザAPIは無い。

直接アクセス可能な物理メモリ空間にあるのではなく、GPU経由でアクセスするメモリに存在しているようだ。これでは読めない。

やはり、なんとしてもvcgencmdを動かさないといけない。
色々調べると、githubでuserlandのソースが管理されている事がわかった。
以下のようにして、gitリポジトリをクローンする。

git clone https://github.com/raspberrypi/userland.git

サブディレクトリ userland/ ができている。
スクリプトのbuildmeを読むと、uname -mの戻り値によっては、セルフビルドするようになっている。ただし、cmakeをインストールする必要がある。
ビルドツール類をまだ入れていないなら、それらもまとめてinstallしてしまおう。
以下のようにする。

sudo apt install cmake build-essential

後はビルドするだけだ。

git cloneでできたサブディレクトリuserland/へ移動して、buildmeを実行する。

cd userland
./buildme

なんだかんだ色々表示されてビルドが終わる。終了後、/opt/vc/以下に様々な生成物がinstallされている。
もちろん念願のvcgencmdも/opt/vc/bin/の下にある。

ビルドはできたが、このままでは、ライブラリパスも実行パスも通っていない。
まずは、ライブラリパスを通す。
ファイル /etc/ld.so.conf.d/00-vmcs.conf を以下の内容で作成する。

/opt/vc/lib

この状態で、"sudo ldconfig"を実行し、ライブラリパスをキャッシュする。

sudo ldconfig

これで、ライブラリパスの設定はおわり。

つづいて、実行パスも通すのだが、vcgencmdはsudo経由で実行しなければならないため、/etc/sudoersファイル内の、Default secure="..."に、"/opt/vc/bin/"を追加する。
また、このファイルは、直接編集できない。"sudo -e /etc/sudoers" で編集する。
結果的にその行はウチでは以下のようになった。

Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin:/opt/vc/bin"

これで、vcgencmdが実行できるはずだ。 以下のようにして、vcgencmdを実行してみたら、

$ sudo vcgencmd otp_dump | grep '^17:'
17:1020000a

うーん。これではUSBブートできない。3020000aでないといけない。
不可逆な変更なので、躊躇していたようだ。
それにしても、たった1bit確認するだけで、細かく色々、どんだけ手間がかかるんだ。

---

USBブートがセットされてないことが解ったので、セットしよう。
セットするには、/boot/config.txtの末尾に、"program_usb_boot_mode=1"を書き込んでリブートするらしいのだが、Focalでは/boot/config.txtが存在しない。
Raspbianのイメージをダウンロードして調べてみると、MicroSDの第一パーティション(FATフォーマット)のconfig.txtだ。
Focalでそれは/boot/firmware/config.txt だ。
そのため、以下のようにして書き込む。

echo program_usb_boot_mode=1 | sudo tee -a /boot/firmware/config.txt

これで、再起動してOTP領域を確認すると、

$ sudo vcgencmd otp_dump | grep '^17:'
17:3020000a

よしよし。やっとUSBブートのセットができた。

---

これで全てではない。
ダウンロードしてきたイメージをUSBでブートできるようになったのだが、実際に使うにはもう少し手間がかかる。
1ビット確認して、1ビット書き換えただけで、妙に長くなってしまったので、とりあえず今回はここまで。

つづく。

新しいプリンタを買った

昔から使っているCANON LBP-1310は未だに健在だ。しかしながら、白黒だし、スキャナも欲しかったので、インクジェットを新たに買った。
今回は、EPSON EW-M752T にした。EPSONのプリンタは20年ぶりぐらいだろうか。
エコタンク対応で、ランニングコストが安価になる。古い機械を長く使う人にしてみれば、効果的だし、コンビニのビニール袋すら問題視する時代に合っていると言えよう。

急激なテレワーク化のため、プリンタもまたバカ売れ品薄状態で、先月の末に店頭で注文したのに、届いたのは昨日だった。

届いてから、おもむろにLinuxドライバを探した。
MacのおかげでCUPSが発展し、最近ではLinuxでも簡単にプリンタが使えるようになっていたので、ほとんど気にしていなかったのだが、検索して出てきた「Linuxドライバーダウンロード可能機種一覧」のページをみて愕然とした。

購入したEW-M752Tが、その一覧には無いのだ。

「…やってしまった。」と思ったが、一応ドライバダウンロードへ移動して、ダメ元で検索してみた。
すると、以下のような結果が表示された。

あるじゃん！
しかも、ARM用のパッケージまである。armhf用なので、RaspberryPi 3系で使える。4でもLinuxが32bit版なら使えるだろう。

まずは、PC(amd64)のプリンタドライバセットアップをする。
epson-inkjet-printer-escpr2_1.1.17-1lsb3.2_amd64.deb をダウンロードしてくる。
ダウンロードページの下の方(上記画面の"ESC/P-R Driver 2 (generic driver)"の行の「ダウンロード」をクリックした後で、ソフトウエア使用許諾に同意した後で表示される)に、以下のような事が書いてある。

[Notice]
In order to install these drivers, you need to install LSB package (version 3.2 or later) beforehand.

Ubuntu:
# apt-get install lsb

Fedora:
# yum install lsb

OpenSUSE:
# yast --install lsb

最初の部分には、「これらドライバをインストールするためには、LSBパッケージ(バージョン3.2またはそれ以降)を事前にインストールする必要がある。」と書いてある。このlsbは、"Linux Standard Base"と呼ばれる機能のパッケージらしい。最新のUbuntuでは、これは全機能を提供していないようで、サードパーティプリンタドライバとの互換性のためだけに提供されているもののようだ。
ウチは、Ubuntu 18.04なので、以下のようにしてインストールした。

sudo apt-get install lsb

その後、ダウンロードした epson-inkjet-printer-escpr2_1.1.17-1lsb3.2_amd64.deb を以下のようにインストールする。

sudo dpkg -i epson-inkjet-printer-escpr2_1.1.17-1lsb3.2_amd64.deb

あっさりと終わってしまった。次は何をすれば良いんだ？
よくわからないので、とりあえずcupsのWebI/F(http://localhost:631)で見てみる。
上の方の「管理」をクリックして、「プリンタの追加」ボタンを押すと、「発見されたネットワークプリンター」の中に「EPSON EW-M752T Series (EPSON EW-M752T Series)」がある。

注意:上記画面は、プリンタ登録後にキャプチャしたので、すでに上にプリンタが見えている

ここに見えていれば、後は普通に設定すればプリンタは使えるようになる。

次にスキャナも使えるようにする。
ダウンロードページの一番下の行の"Scanner Driver"、"All-in-one package"と書かれているところの「ダウンロード」をクリックする。
使用許諾が求められ、同意すると、PDFファイルのダウンロードとその下に、"Package Download"リンクが表示される。
PDFファイルは、スキャナドライバのインストール方法が書かれている。
"Package Download"をクリックすると、各ディストリビューション、アーキテクチャ用のtarファイルのダウンロードページが表示される。

うちのUbuntuは18.04のamd64なので、imagescan-bundle-ubuntu-18.04-3.63.0.x64.deb.tar.gz ダウンロードした。
インストールは基本的には、tar.gzファイルを展開して、 展開後にできるディレクトリ内のinstall.shを実行すればいい。

$ tar -xf imagescan-bundle-ubuntu-18.04-3.63.0.x64.deb.tar.gz 

$ cd imagescan-bundle-ubuntu-18.04-3.63.0.x64.deb/

$ sudo ./install.sh

install.shはよくできており、足りないパッケージを自動的に apt-get install するようになっている。

ドライバのインストールはできたが、スキャナは自動検出＆認識ではない。
/etc/imagescan/imagescan.conf でIPアドレスを指定する必要がある。
各ネットワーク環境毎にやり方は様々だと思うが、とにかくEW-M752TのIPアドレスを固定化して、そのアドレスを得ておく。
そうして、以下のように /etc/imagescan/imagescan.conf を書き換える。

# /etc/imagescan/imagescan.conf -- Image Scan configuration
# Refer to the documentation for details on the configuration options
# for the software.  Plugins should come with their own documentation
# if they have configuration options.
#
# Lines starting with a # or a ; are comments.  Comments must be on a
# line of their own.  End-of-line comments are not supported.

[devices]

myscanner.udi    = esci:networkscan://192.168.xxx.xxx:1865
myscanner.vendor = Epson
myscanner.model  = EW-M752T

注意:上記 "192.168.xxx.xxx"には、EW-M752T のIPアドレスを指定する。

この状態で、Terminalからimagescanと入力するか、メニューから「グラフィック」-> 「Image Scan」(ウチはGnome session flashback環境)をクリックすると、imagescanというアプリが起動する。
「更新」ボタンをクリックすると、プレビューが表示される。以下は、プリンタについていた「インクボトルガイド」をプレビューした様子。

---

一瞬、未対応かと冷や汗をかいたが、バッチリじゃん。
最近のLinux環境は良くなったものだ。

さらにarmhfアーキテクチャのドライバまである(まだ試しいていない。将来記事にするかも)。CANONには無かったと思う(最近見てないので詳細不明)が、CANONとEPSONはお互い切磋琢磨しているので、徐々に良くなるだろう。
RaspberryPiも、PCの代わりに使えるぐらいの性能になった。しかし、実際にPCの代わりに使うには、プリンタやスキャナも普通に使える必要がある。
残念なことに、arm64のドライバはまだ提供されて無いようだ。RaspberryPiでも64bitを必要とするようになったのは最近のことだし、MacもARMに移行するらしいので、arm64の環境も徐々に充実するだろう。
期待して待とう。

雲のタイムラプス

台風10号が九州に接近している。
かなり強力な台風なので、関東にも影響が出ている。
晴れたかと思えば、突然雨が降ったり、雷が鳴ったり、不安定だ。

雲が流れていくのを見て、タイムラプスで見てみたいと思って撮影した。

2020年9月6日 12:50頃から、15:38頃までの2時間48分、さいたま市で撮影。
x60倍速再生のため、1分で1時間に相当する。
撮影時に雷も光っていたが、とびとびなので動画では見えない。