honeylab's blog

各種ハードウェアの改造、主にファミコンミニなどをやってます(ました)

続々・ATOMCam2が(中略)RTSPサーバ機能を追加した(パッケージ更新)

こちらの機能を統合した新パッケージを作成しました。

↓こちらの記事が最新のパッケージになります。

honeylab.hatenablog.jp

 

このアプリの使用条件は特にありませんが、こういったものを作るにあたっては突発的にアマゾンで何かを買うことができる資金があることは大変助けになります。

もしアマゾンで何か買うことが多い利用者の方は、是非上記のリンクから入って買い物をしていただくと、売り上げの一部が私に還元されますので是非。

以下の記事は技術情報として残しておきます。

 

サーバパッケージを更新しました。

drive.google.com

どうしてもメモリが足りない状態が多いので、やむなくSDカード上にswapファイルを作成しました。
SDカード上へのswapはちょっと思うところがないわけではないですが、まぁSDカードにはずっと録画データを書いているわけなのと、そこまで頻繁にswapしているというわけでもなさそうなのでしばらくこれで様子見てみます。

念のため、高耐久性で、でも壊れてもいいSDカードを使用してください。

 ーーーーーーーーーー

refererからfacebook辺りから人が来てるっぽいんですが、どこで紹介されてるかわからないので、もしよければコメントから教えてください

(ニッチな用途なので、ある程度ユーザを把握したいです)

ーーーーーーーーーーー

 

honeylab.hatenablog.jp

 

honeylab.hatenablog.jp

 

上の2記事からの続きです。

あれやこれや調べた結果、かなり力技ですが、タイトル通りRTSPサーバ機能を追加し、
ローカルLAN内でVLCなどのRTSPビューアで表示ができるようになりました。

 

もちろん、ルータの設定などを行えば外からも見ることが可能です。
実行ファイル群はATOM CamのOEM元の系統であるWyzeCamのオープンファームウェア「OpenMiko」からの拝借です。

github.com


(手元でT31用のSDKを使ってパッチ・再コンパイルしています)
「OpenMiko」の本来の使い方では完全にファームウェアを入れ替えてしまうため、これと同じように作るともともとの便利なATOMCamのどこからでも見れる機能が使えなくなってしまいます。
それはそれで不便なため、元の機能をうまいこと残し、追加機能を共存させることに成功しました。

ATOM Cam2で使うためには、microSDカードにここにあるアーカイブ内の「Test.tar」と各種フォルダを置いて、カメラを起動するだけでこの機能が使えるようになります。

 

f:id:honeylab:20210705121130p:plain



本体上のストレージには何の影響も与えませんので、microSDカードを抜いて再起動すれば、完全に元の状態で動くようになります。

一応おいておくので試してみてもいいですが、
動かなかったら、あぁ動かなかったな、忘れよう。と思っておいてください。

また、動体検知等の機能はOFFのほうがよさそうです。メモリが足りないです。


尚、この実行ファイルはmicroSDカードに置かれるので、アプリから「microSDカードのフォーマット」をすると、たぶん動作がおかしくなりますので、これだけはやらないように注意する必要があります。
(もちろん、microSDカードを抜いて再起動すれば元通りになりますし、改めてファイルを書き戻せばハック状態にできます。)

 配信されているIPアドレスは、ATOMCamの公式アプリを起動して、デバイス情報の中にある「IPアドレス」になります。

VLCで開くアドレスは rtsp://[IPアドレス]:8554/unicast になります。

f:id:honeylab:20210705121537p:plain

 なお、現時点ではストリームできるのは画像のみです。

 

さて、この実装に関して肝となるのはOpenMikoにも入っている「v4l2loopback」というカーネルモジュールです。

github.com

 

このモジュールを使うと、システム内に任意の /dev/video[x] デバイスを作成することができ、このデバイスに画像データを流し込むことで、通常のLinuxで使用される、/dev/videox をキャプチャデバイスとして扱うようなプログラムに画像を渡す、いわゆる「バーチャルカメラ」や「仮想キャプチャデバイス」などと呼ばれるもの相当が実現可能になります。

あとは、ATOM Camのプログラムの起動時に仕掛けをして、カメラから画像データが到着するたびに、この仮想キャプチャデバイスにデータを渡し、バックグラウンドで一般的に使われているRTSPサーバ「v4l2rtspserver」

github.com

を動かせばいいだけです。

(↓参考リンク)

dev.classmethod.jp

カメラ内のプログラムに仕掛けをしているコードはこんな感じです。

gist.github.com

 

ここで少し課題があります。

今のところ割り込んで画像を取得しているのは、カメラからの直データではなく、その次に接続されたH264エンコーダの出力になっています。

そのため、おそらく今のところ「mjpg_streamer」(生画像データかJPEGデータが必要)はまだ動かせません。/dev/videoから出てくるデータは生データとは限らないのです。


その代わり、H264エンコードはハードウェアで行われていますので、追加の負荷がほとんど発生しない状態でRTSP配信ができています。

f:id:honeylab:20210705112310p:plain

 

理論上は、カメラ直後のYUVストリーム、うまくいけばハードウェアJPEGエンコード後のストリームも取れるはずなので、それは別デバイスに流してmjpg_streamerに食わすかcgiで吐き出せば、普通のブラウザでJPEG画像としてみることも可能になるはずです。追々挑戦してみたいと思います。

 

 あと、おまけ機能としてtelnetdを上げてあります。
上にあるIPアドレスに、telnetで、ユーザ root パスワード atomcam2でログインできます。

追記:とりあえずJPEG画像を取得する

エンコードされたフレームから再生成するので直接よりは画質が落ちますが、スクリプトなどで実行して送ったりするためにはffmpegを使うといいです。

ffmpeg -i rtsp://192.168.0.18:8554/unicast -f image2 -frames:v 1 test.jpg -y

などとやると、test.jpgが保存されます。 

続・ATOM Cam2がいつまでたってもONVIFに対応しないのでハックで殴る

honeylab.hatenablog.jp

 

上の記事でも紹介しましたが、ATOMCamシリーズ、そのまま使うには玄人にはちょっと不便な部分をハックするにあたって、T31のSDKを使って直接新しいアプリケーションを書き、画像を取得することにすでに成功しています。

しかし、今はまだアトムテックのサーバーは生きていますし、同じような機能を実装するのは大変です。
そのため、上の記事ではあきらめていた、既存のアプリに手を入れて、欲しいストリームを横取りすることができないかを調べてみました。

まずは、ダンプから抽出した実行ファイルを眺めてみます。

/sysetem/bin 以下がこんな感じ

f:id:honeylab:20210630140049p:plain

そして、/system/libがこんなかんじ

f:id:honeylab:20210630140133p:plain

 

この中からアプリ「iCamera_app」と、そのライブラリ、「localsdk.so」を、定番の「Ghidra」で解析、逆コンパイルして、映像の初期化あたりから辿っていきます。

f:id:honeylab:20210630101259p:plain

どうやらこの辺がビデオストリームを生成しているところのようです。

f:id:honeylab:20210630101352p:plain

local_sdk_video_createなどの関数が見えてきます。

f:id:honeylab:20210630101559p:plain

local_sdk_video_set_encode_frame_callbackという関数があります。
おやおや、もしかすると、これはフレームの到着のたびに呼ばれる仕組みがあるのでは???という期待が出てきました。

localsdk.soを見ていきます。

f:id:honeylab:20210630101808p:plain

この関数を調べていくと、get_venc_sb_pstという関数で取得した関数テーブルに外部関数を登録していることがわかりました。

そして、実際にビデオストリームが開始すると、

f:id:honeylab:20210630102009p:plain

登録した関数にフレームバッファを渡して呼び出してくれそうなことがわかりました。

(わかりました、って書いてるけど、全然簡単じゃなくて何時間もかかってるのよw)

では、このコールバック登録を横取りして自作の関数を呼び出させてしまえばいいじゃん、ということになります。

しかし、そんなことできるのでしょうか。

Linuxには LD_PRELOAD という呼び出し方法で、実行ファイルから呼び出される外部ライブラリの対象に自作の関数を割り込ませる方法があります。

qiita.com

この方法を使って、コールバック登録関数を上書きして動作を変更します。
本来、コールバック登録関数に渡されるのはATOM Camの中の関数ですが、
その登録作業を横取りし、自作の関数を呼び出させます。そして、そのあと、本来のATOM Camの関数が呼び出されるようにすれば、ATOM Cam側では何も気づかず今までと同じ動作を続けます。

このために、以下のような関数を定義します。

gist.github.com

このファイルをコンパイルして、.soファイルを作成します。

mips-linux-uclibc-gnu-gcc -fPIC -shared -o libcallback.so snooper.c -ldl 

 そして、本来のアプリが呼び出される部分を変更し、

LD_PRELOAD=./libcallback.so.bin /system/bin/iCamera_app &

として呼び出すと、アプリでliblocalsdk内の”local_sdk_video_set_encode_frame_callback”を読んだつもりが、新しく私の書いた関数が呼び出されてしまうのです。

新しく書いたコールバック関数内では、渡されたフレームバッファを単純にファイルに書き出してみました。

 

うまくいけば、これでカメラから出力され、H264エンコードされたストリームが取得できるはずです。

出力されたストリームを、ffplayに渡してみると

 

Image

やった!!!!画像が出てきました。

どうやらうまくいったようです。

この方法だと、前の記事に書いたように一から新しいアプリを書く必要もなく、もともとのサーバ中継システムを生かしたまま、新たにRTSP配信など、直接データを取り出すことが可能になります。

ここで取り出されたストリームは H264 NAL ストリームなどと呼ばれているようです
ffplayに渡して再生できるので、たぶんffmpegなどに渡してトランスコードするだけで配信サービスができる気がするんですが…ffmpegコンパイルがちょっとめんどくさそうですね…

 

とはいえ、前回の記事よりは圧倒的に進歩しました。
せっかくここまではできたので、このままローカルでストリームが取得できるところまでどうにか作ってみたいと思います。

 

ATOM Cam2がいつまでたってもONVIFに対応しないのでハックで殴る

ONVIF対応について | ATOM Tech(アトムテック)

 

知ってる人は知ってると思いますが、使い始めるまではクッソ簡単なATOMCam2ですが、ちょっと凝ったことをしようとすると、例えばブラウザからjpgが見てみたい、とかVLCでストリームを見たい、とかローカル内でマルチカメラを自分で見たい、とか言った目的のために、いわゆるONVIF対応が待ち望まれていて、さらにそれは開発中だと言い続けて早数か月、ユーザからは悲観的なコメントがあふれ、不満のコメントがぶつけられ続けています。

community.atomtech.co.jp

community.atomtech.co.jp

改めて言うけど、ちょっと使うにはすごいいいです。

個人的にたくさん並べてますし、交差点カメラとしての動作もばっちりです。

f:id:honeylab:20210628150320p:plain

f:id:honeylab:20210628150338p:plain

 

しかし、これをプログラムから自動化しようとすると、途端に何もできないのです。

ATOM Cam2の基板にははIngenic T31というSoCとイメージセンサが搭載されていますが、例えばラズパイにUSBビデオキャプチャをつなげた時のように、/dev/video0にアクセスすれば画像ができる、といった仕組みにはなっていません。

この組み合わせのための専用のSDKが準備されています。
しかし、そのSDK自体はその辺には転がっていません。
ネットの海をあれこれして、怪しげなサイト(別に怪しくはないのですが)にクレジットカード番号を入力したところ、T31用のSDKを入手し、サンプルコードを実行させることができました。

 

f:id:honeylab:20210628141201p:plain

 

f:id:honeylab:20210628145446p:plain

 

 

f:id:honeylab:20210628141238p:plain

 

 


サンプルコードは非常に簡潔で、どうやらWyzeやATOMCamのアプリを制作している会社がラップしている"localsdk"は、このSDKに一枚皮をかぶせ、SDKの"sample"などの文字列が残ったままで作られている程度のもののようです。

また、元のSDK自体にもLinuxソースコードやビルド済みカーネル、rootfsなどが添付され、割と簡単にカスタムファームウェアを作れるレベルの内容であることがわかりました。また、WyzeCamではv2までのカスタムファームウェアが実際にリリースされていますので、まともなエンジニアがちょっと本気を出せば、ONVIF機能などあっという間に完成するもののはずです。

 

このサンプルコードを改変し、boa(httpサーバ)を使い、ATOMCam2の画像をローカルLAN経由で取得することに成功しました。

f:id:honeylab:20210628141558p:plain

 


これを拡張していく、例えばmjpg-streamerやffmpegなどに画像を渡すことで、ONVIFやRTSPへの対応ができるものと考えられます。

では、ATOMTechは何でできないのか。

エンジニア逃げたのかなw

 

いや、もともと内部にはエンジニアはいなくて、下請けに何らかの理由で追加開発を拒否されているんでしょうか。

 

さて、ここで一つ問題があります。
出荷されたATOMCamでは、iCamera_appというアプリがカメラの制御をすべて使用していて、あとから機能追加などをすることができません。
(試してないんですが、たぶん。)
つまり、いまのATOM アプリを使用しつつ、自作の画像取得アプリを動かす、というのは、iCamera_appからのソースコードレベルでの改変を行わないとおそらくできないものと考えられます。

(いや、すごい頑張ればできるんだけど…逆アセンブルから大体のプログラムの構造はわかってて、それに対して適当にinjectionすればできそうではあるんだけど…)


まぁ、これらを踏まえると、ATOMTechが倒産した暁には、iCamera_appを完全に無効化し、何らかの画像中継サーバなどを利用するか、ローカルでどうにかするためのアプリをリリースする環境は十分に整っていると考えられます。

(私がやるとは言ってない…)

 

なので、皆さん、安心して ATOM Cam2を買うんだ!
市販レベルでは結構最高品質のカラーナイトビジョンとWiFi搭載マイコンボードがついてなんと3000円!!安い!!!!買うなら↓のリンクから(アフィ)

 

こんなアフィ記事ねーよ。

 

 

 

 

ATOM Cam2にUSB-Ethernet変換アダプタを使って有線LANで使用する

件のATOMCamやATOMCam2は、基本的に自分の配下の無線LANに接続して使うように設定することが前提になっていますが、有線LANを使用したほうがいいような環境(電波状態)もあり、一部のユーザからは何でできないの、という声も上がっているようです。

というわけで、無理やりハックしてATOM Cam2を有線LANで使用できるように調整してみました。

必要なファイル類はここにあります。

github.com


SDカード上には、このリポジトリにあるTest.tarとscriptsフォルダをコピーしておきます

f:id:honeylab:20210626223630p:plain

Test.tarってなんだよ?っていう方はこの辺を参考にしてください。

qiita.com

 

物理的には、USB電源供給OTGケーブルを使用し、ATOM Camに電源を、ATOM Camからのホスト信号をUSB Ethernetアダプタに接続します。

(写真はハック用なので分解された姿です)

 

 たとえばこんなやつで

 

 

 

 

ちなみに、都合のいいことにASIX AX88772 などのUSB-Ethernetドライバがカーネルに組み込まれているため、これらは挿入するだけで認識されます。

未確認ですが、Realtek r8152のドライバもあるため、これも認識する可能性があります。

 

OTGケーブルは付属のケーブルと同一寸法ではないため、屋外に設置するのであれば
この部分をうまいことして防水性能を担保する必要があります。
付属のケーブルは電源の2本しか接続されていないため、このケーブルのA側を加工してもダメです。本体基板のUSBコネクタの信号を使用する必要があります。

 

Test.tar内の test.shの中身はこんな感じです。

github.com

 

このコードにより、本来のカメラアプリ「iCamera_app」の起動前にSDカード上のscripts/pre.shが、起動後にscripts/post.shが呼び出されます。

また、このスクリプトではtelnetdを立てていますので、Advanced IP scannerなどを使用してIPアドレスを確認した後、telnetでshellに接続することができます。

(ユーザ名は root 、パスワードは atomcam2 )

 

f:id:honeylab:20210626235425p:plain

 

pre.shの中身は

github.com

 

ここで、scripts/wpa_cli.shコマンドがミソになります。

github.com

ATOMCamの組み込みアプリでは、wlanの設定のためにwpa_supplicantや設定の取得のためにwpa_cliを外部コマンドとして実行し、結果を読み込むことでwlanの接続状態を取得したり、IPアドレスの確認を行っています。

wpa_cli -p /var/run/wpa_supplicant -i wlan0 STATUS | grep ip_address
wpa_cli -p /var/run/wpa_supplicant -i wlan0 STATUS | grep wpa_state

 内部的には↑のコマンドが呼び出されています。

なんと、これに必要なだけの応答を返すため、中身はたった4行です。ひどい。

#!/bin/sh

echo 'wpa_state=COMPLETED'
echo ip_addresss=`ifconfig eth0 | awk '/inet / {print $2}' | awk -F: '{print $2}'`

 

このwpa_cli.shを本来の/bin/wpa_cliにovermountし、

mount -o bind /media/mmc/scripts/wpa_cli.sh /bin/wpa_cli

 

iCamera_appから呼び出されるようにしてしまい、実際にはwlanではなくusb etherで通信を確立し、iCamera_appをだますことで有線LANを使用可能にすることができます。

 シリアルからifconfigして確認してみると、確かにwlan0の接続が確立していない状態、eth0のみipaddressが来ている状態でATOMアプリから接続ができています。

 f:id:honeylab:20210626231014p:plain

また、この状態でATOMアプリに新規登録する際、適当なSSIDとパスワードの組み合わせを入れておけば、無線LANを一度も使わずに登録ができることを確認しました。

 

さて、scripts/以下のファイルを変更する際に、Test.tarの変更は不要です。

そのため、scripts/pre.sh , scripts/post.sh の中身は自由に書き換えて、ハック用の追加コマンドを実行することができます。

  

突貫で作ってみましたが、とりあえず動いてはいるようです。
もし使う人が多いようならば不具合も出てくるでしょうし、その解決方法も出てくるでしょう。

まあ、とりあえず技術的にはできたよ、っていうことで。

 

電気工事法違反のコインパーキングを見つけた気がしたので改めて確認した

先日とある格安前払い方式のコインパーキングを利用した際、
地中を通したと思われる電線が派手に破損している部分を見つけました。

 

現場はこちら

f:id:honeylab:20210607131151p:plain

 

このブログを読んでいる方には、「電気工事士」という資格があることを知っている人は多いかと思いますが、工事をするには資格があるだけではだめです。

そもそも、電気工事士の資格とは他人の財産、生命を感電や火事などによって傷つけたり、失わせたりしないようにするために一定の方法・品質で工事をすることを義務付けるために設定されたものです。当然、各種工事はこの法律に従わなければなりません。
(加えて、業として工事を行う場合は都道府県への工事都道府県への工事業者と業者としての登録が必要です。)

(ちなみにブログ主は第二種電気工事士の免状を取得済みです。認定電気工事従事者の講習も受講済みですが、めんどくさくなって免状の申請をしていません。)

 

 


jeea.or.jp

 

第1図 地中電線路の一般工事方法

 

このような地中を通す、または頻繁に車が通るような部分に電線を通す場合、きちんとした電線の保護が必要です。

 
車両の影響がある場合ですから、上記のサイトにあるようにコンクリート製の暗渠を使い、1.2m以下に埋めるなどの埋設方法をとらなければ違法となります。

それに対してなんじゃこりゃ。

 

f:id:honeylab:20210607112648j:plain

車の通路に投げ出された100Vの配線

 とりあえずフレキ(CD管)には通してはありますが、ほぼ地面の真下に通してあるため、はがれた舗装からむき出しになり、水たまりに浸かっている状態です。
中を通っているケーブルはVVFですから、一応二重絶縁ですが、紫外線には弱く、屋外配線としては直接使用してはいけないことになっています。
また、このCD管自体も対候性はありませんから屋外露出には向きません。

 

さらに駐車場内にいくつかついているLED照明を確認してみます。


地中をPF管から引き出された配線ボックスに接続したまではいいですが、さらに照明までの配線がVVF+PF管のみ、インシュロックで固定されただけです。また、インシュロックも劣化して切れてしまい、ぶらぶらしています。 

f:id:honeylab:20210607112831j:plain

風に吹かれてぶらぶらするPF管

f:id:honeylab:20210607112547j:plain

切れたインシュロックが供えてあります


もう一つの照明、一応水が入らないようにとか思ってPF管をまげて施工しているようですが、PF管をこんな鋭角で曲げているためあっという間に劣化して切れてしまっています。

f:id:honeylab:20210607124739p:plain

これではここから水が浸入し、PF管を通って下のボックス内に溜まっていってしまいます。漏電まっしぐら。

ちなみに正しい方法としては、電線管とエントランスキャップを使う工事が普通です。

f:id:honeylab:20210607130021p:plain

エントランスキャップ

 エントランスキャップだって、値段としては数百円なんですが…

 

加えて、精算機のそばにある配線ボックス…

 

f:id:honeylab:20210607112726j:plain

蓋割れとるやんけ!!!!!!!!
防水のためのボックス割れて水かかり放題じゃん!!!


ひどいひどい。
こんな感じですから、この看板に書いてある同じ経営ではないかと考えられる近隣のパーキング、同様の状態なのではないかと思いチェックしてきました。

 

f:id:honeylab:20210607112711j:plain

 

 

看板②のパーキング

 

そもそも先ほどの駐車場ほど広くないため、照明の数は少なかったですが、
同様にPF管をまげていても施工が不十分なためここから水が浸入してしまいます。

もう一か所もこんなん。

f:id:honeylab:20210607125058p:plain

この駐車場内の照明はすべてこのような状態でした。

 

っていうか、もはや電線の自重で照明の線が引っ張られてるじゃん…

看板につながる照明への配線もVVFからケーブルへの直結で防水もテープ巻きのみですね。中で圧着端子使っていればテープ巻きでも十分ではありますが、これは配電盤にでも入れたいところですが…

 

f:id:honeylab:20210607113310j:plain

さて、看板①のパーキングに来てみました。

予想に反して、こちらは照明間の配線に金属電線管が使われ、正しい工事が行われているようでした。

f:id:honeylab:20210607113709j:plain



一か所PF管が割れていますが、ここはまぁ精算機への配線とコンクリート埋設なので大丈夫かな…

 

さて、こんな感じで街中には皆さんが気づかないまま、違法であったり、大変漏電の危険の高い状態のまま放置されている場所があるようです。

ここはいわゆる駅チカの激安前払い駐車場として、投資を最低限にするために激安の素人工事屋にでも頼んでしまったのでしょうか。

ちなみに管理会社のサイトの説明はこんな感じです。

sanpark.jp

 

f:id:honeylab:20210607131933p:plain

こんな感じの看板、見たことありますよね?


実際に事故が起きてからでは遅く、それが大変危険であるために法律で制限されているわけですから遵守されていて当然です。
ましてやそれが不特定多数の方が利用する駐車場のような場所の場合、施工業者だけでなく管理者の責任も逃れられないと思われます。

というわけで、この状態を各種関連窓口に通報してみたいと思います。
この管理業者に通報したとしても内部で処理されてしまったりして今後の改善につながる気があんまりしてませんので、上から順に投げていきたいと思います。

 

調べてみると、管轄の警察・消防・電気工事士の管轄である経済産業省、地域の電気保安協会、などがあるようですので順々にこのURLを添えて投げていってみたいと思います。

 

 

経鼻胃カメラ検査をしたのでDICOMデータをお土産にもらってきた

突然ですが、こちらが私のここ3年間の健康診断の結果です。

https://previews.dropbox.com/p/thumb/ABKJtD1i6J-5nDOUy_Y0Bzra0khPrrlQIYP9sLBfGmZZ8YZHDqmKr2km_JBJnmWT6qqhW1DlYomzPOnvpsFoPPfwwwatuSXr2MsEsg4CXWuoFJS_9aBx7OMDSa2U9f9Z24H7UFYsu69sJYCNpaejX1NCP7V6ry5PfxebaLF8ek_bYbPIjYBaTEXIct7f3x6EqCMGdF8MZgHz6KHbAXQoFpChaAaKsQq-be9XDMKSGzVc5amfR8rigc4QTnL4iJj1y3LT4Dc2WLgU8x7l1dPDyR-myhLqvF9CNXTIvD1rFNA-QbKEHxJONczDuIvG1hdi3YtHGlyo9Q9Dx_LMgM0RXstJagr9sC46Juwbzl5gRdRWhA/p.jpeg?size=2048x1536&size_mode=3

多少悪いですが、急に命に関わったりはしなそうです。

いや、ちょっと血圧がやばそうですが…
(祖父、父どちらも高血圧、脳卒中経験なのでたぶん私もぼちぼちやばいです)

 

この結果だけ眺めて、まぁぼちぼち気を付ければいいや、と思っていたところ、二枚目があることに気づきました。

 

胃部X線:胃ポリープ、胃角部変形の疑い

 

Image

 

 

えぇぇっ!???この辺今まで何か出たことないのに!!!胃ポリープ、はなんとなくわかるけど各部変形の疑いって何!!!???

 

ちょっと調べてみると、胃ポリープは良性の場合もありその場合は様子見、明らかに悪性の場合は摘出、この辺は想像通り。

胃角部変形の疑いって何よ…と調べてみると、胃がんとかでそういう風になることもあるとか

 

うぇぇぇぇ???

やっべやっべ。

ということで慌てて近所の、かつ苦しくない経鼻胃カメラができる病院に転がり込み、偶然翌日朝に検査ができるということで早速予約をとり、翌日鼻から撮影を受けてきました。

 

鼻からカメラ、聞いてた通り楽です。ただ、鼻の奥が狭い場合口からになりますって言われてて、年中点鼻薬が手放せない私は結構ビビっていたんですがねw

 

で、結果としては胃ポリープは治療不要、胃角部変形は若干の胃炎、そのほか食道に若干の胃酸の逆流の形跡があることなどを指摘されましたが、2~3年に一度の内視鏡検査をすればいい、ということになりました。

 

焦った…

 

で、せっかく検査をしたので、その写真をお土産にもらってきました。
なんとなくそういうことができるということは知ってる方も多いと思いますが、
実際にやってみようとするとなんて言ったらいいかわかんなかったり、もらってもどうしようと思ってもらわない方も多いと思いますので、ここではもらえるデータについての技術的情報を書いていきたいと思います。

 

現在、X線内視鏡、超音波検査などで取得された画像データは”DICOM”(ダイコム)と呼ばれる共通画像交換形式ファイルとして保存されることが多いです。
一昔前は、X線X線感光フィルムに撮影・現像し、写真として取り扱われていましたが、今ではX線感光CCDなどで直接デジタルデータが撮影できるため、必要なX線の量も少なく、より安全に、鮮明な画像が取得できるようになっています。
小さなクリニックなどでは機械単位でしかデータを取り扱っておらず、直接機械からCDーRやメモリカードにデータをエクスポートしたりすることもありますが、大病院や電子カルテが扱える病院では撮影データをきちんとカルテと結び付け、診療情報として出力できるようです。

この診療情報、総合受付や診療科受付、担当医師などに「検査画像データをCDでください」というだけでもらうことが可能です。特に理由の説明は必要です。紹介状の必要性などを聞かれるかもしれませんが、画像が個人的に欲しいです、とだけ言えばいいです。
料金は自費なので1000円~3000円(税抜き)の場合がほとんどですが、病院によっては即日とはいかない場合もあります。

 今回は大きな病院だったこともあってか、立派にラベルも印刷されたCD-Rが当日、一時間ぐらい待って1000円で発行してもらえました。

 

 

では、この中には何が入っているのでしょうか。
まず、先述したDICOM画像データが入っています。
DICOM画像データの入ったCDは、パソコン汎用機ではない検査・閲覧機器などで読み込むことも考慮してDICOMDIRという認識ファイルと、DICOMディレクトリが必ず存在しています。

f:id:honeylab:20210528102040p:plain

DICOMDIRファイル(バイナリデータ)

そのため、DICOM対応機器に挿入すれば見ることができます。

が、そんなものは一般家庭や、ちょっとしたクリニックには無いこともあります。

しかし、一般の家庭でも見ることを考慮し、CD-R作成の際に汎用PCやブラウザでも閲覧可能になるように、PCビューワソフトやhtmlディレクトリを出力してくれていることが多いです。

 

DICOM画像ファイルは、デジカメの写真などについている.JPGなどのような拡張子を持ちません。

f:id:honeylab:20210528102200p:plain

DICOMDIRフォルダ内にあるファイル

画像フォーマット情報(色深度)や患者情報、撮影条件などがファイル内にバイナリデータとして埋め込まれているだけです。

f:id:honeylab:20210528102246p:plain


どちらかというと、その情報のほうが重要です。
いくら画像を見せられても、それがどんな機器で、どんな条件で撮影されたかの情報を含まなければ、医療診断画像としては役に立たないからです。

 

このCD-Rには”AOC_mini”というビューワが付属していました。

f:id:honeylab:20210528102736p:plain

これは、DICOM画像ワークステーション”Array AOC"という機器から出力された機能のようです。

Array AOCについてのFAQ - 製品情報 | Array Corporation - アレイ株式会社

f:id:honeylab:20210528102505p:plain

 

ソフトを起動すると、収録された画像のサムネイルが表示されます。

f:id:honeylab:20210528102855p:plain

内臓画像のため、一応ぼかしてますw

パソコンに詳しい方ならこのソフトを使っていろいろできるとは思いますが、トーンカーブの修正などを行って、患部の読影を行う、などお医者さんが使うと便利な機能がついていて、一般的な画像編集ソフトとはだいぶ使い勝手が違うため、慣れるまでは結構難しいと思いますw

 

f:id:honeylab:20210528103147p:plain

 

それとは別に、記念に見るだけ、や家族への説明などのため、ビュワーのほかに、INDEX.HTMファイルがあり、ブラウザからも閲覧できます。

f:id:honeylab:20210528102631p:plain



… コスプレROM写真集と一緒ですね!←

 

ブラウザでならボタンをポチポチするだけで、撮影画像を見ることができます。

 

が、こちらはJPGがされた画像が出力されていて解像度も多少低く、医療診断に使うには不正確になる可能性があります。
しかし、家族に対して、患部はここだよ!などと説明したり、今後の話し合いをしたりするためには非常に重要なツールとなると思います。

ほら、便利!!

重要な診断を受けた場合、是非データをもらっておくと可能性が広がると思います。
皆さんもぜひ!!!

 

 

 

 

例のごとくATOM Cam2を使い倒す(telnetdとftpdを使う)

さて、ATOM Cam2ですが、例のごとくONVIF対応もなく、
NAS対応がされていないようで、せっかく防水外部設置ができるのに、例えばmicroSD内のファイルを一括ダウンロードするような操作のために本体にアクセスしなければいけなかったりしていまいち使いにくいです。

NAS対応についてですが内部的には対応しているようですが、IPアドレスなどの設定情報を書き込むUIが無いために動作していないように見えます)

f:id:honeylab:20210526022225p:plain

起動ログにはNASに関するメッセージが出ている

ということで、ATOM Cam2を遠隔操作、自動化するための方法をまとめておきます。

 

できること

telnetによるシェル操作

ftpによるファイル転送

注意

・上記の機能追加はセキュリティ上の脆弱性となります。パスワードを適切に設定したり、アクセスポイントに対するセキュリティを強化するなど、十分な対策を行う必要があります。

また、この機能は本体のFlashに何の変更も与えません。
機能が不要になった場合、microSD内のTest.tarを削除すれば、完全に元のカメラシステムに戻ります。

 

やり方

ATOM Cam2では、先代のATOM Camと同じようにファクトリテスト用の謎のバックドアシステムがあります。

qiita.com


これがそのまま残っていますので利用します。
簡単のために私が作成したTest.tarパッケージを置いておきます。

github.com

 

このTest.tarを空、もしくは現在ATOM Cam2で使用しているmicroSDのルートフォルダに入れます。

f:id:honeylab:20210526015513p:plain

microSDを挿入し、ATOM Cam2を再起動します。

しばらくして、カメラがネットワークに接続したら、IPアドレスを確認します。
ローカルLAN内を検索できるアプリや、無線LANルータのDHCP割り当て確認などを使用してもいいですが、ATOMアプリのカメラ→デバイス情報でIPアドレスを確認することもできます。

起動時のスクリプトはこんな感じになっています。

github.com

 

IPアドレスを確認したら、telnetを試してみます。

tera termやRLogin、wsl上のtelnetなどが使用できます。

 

f:id:honeylab:20210526015633p:plain

f:id:honeylab:20210526020535p:plain

ログインに必要なパスワードは"atomcam2"としてあります。
取り扱いには注意してください。

Test.tar内、shadowファイルにハッシュ化されて記述されています。もし変更したい場合、Test.tarを展開し、この部分を編集し、再度Test.tarを作成することができます。

Test.tarのディレクトリ構成を変えると動作しなくなります。

 

ログインしてしまえば、通常のLinuxのように何でも処理することができます。

f:id:honeylab:20210526022113p:plain

 

デフォルトでインストールされているbusyboxシュリンクされていましたので、
このカメラのベースとなっているWyzecam用に作成されたカスタムファームウェアからコピーしています。

github.com

 

[root@Ingenic:~]# busybox
BusyBox v1.29.0.git (2018-06-23 20:08:52 CEST) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
or: busybox --list[-full]
or: busybox --install [-s] [DIR]
or: function [arguments]...

BusyBox is a multi-call binary that combines many common Unix
utilities into a single executable. Most people will create a
link to busybox for each function they wish to use and BusyBox
will act like whatever it was invoked as.

Currently defined functions:
[, [[, acpid, add-shell, addgroup, adduser, adjtimex, arch, arp,
arping, ash, awk, base64, basename, beep, blkdiscard, blkid, blockdev,
bootchartd, brctl, bunzip2, bzcat, bzip2, cal, cat, chat, chattr,
chgrp, chmod, chown, chpasswd, chpst, chroot, chrt, chvt, cksum, clear,
cmp, comm, conspy, cp, cpio, crond, crontab, cryptpw, cttyhack, cut,
date, dc, dd, deallocvt, delgroup, deluser, depmod, devmem, df,
dhcprelay, diff, dirname, dmesg, dnsd, dnsdomainname, dos2unix, dpkg,
dpkg-deb, du, dumpkmap, dumpleases, echo, ed, egrep, eject, env,
envdir, envuidgid, ether-wake, expand, expr, factor, fakeidentd, false,
fatattr, fbset, fbsplash, fdflush, fdformat, fdisk, fgconsole, fgrep,
find, findfs, flash_eraseall, flock, fold, free, freeramdisk, fsck,
fsck.minix, fsfreeze, fstrim, ftpd, ftpget, ftpput, fuser, getopt,
getty, grep, groups, gunzip, gzip, halt, hd, hdparm, head, hexdump,
hexedit, hostid, hostname, httpd, hush, hwclock, i2cdetect, i2cdump,
i2cget, i2cset, id, ifconfig, ifdown, ifenslave, ifplugd, ifup, inetd,
init, insmod, install, ionice, iostat, ip, ipaddr, ipcalc, ipcrm, ipcs,
iplink, ipneigh, iproute, iprule, iptunnel, kbd_mode, kill, killall,
killall5, klogd, last, less, link, linux32, linux64, linuxrc, ln,
loadfont, loadkmap, logger, login, logname, logread, losetup, lpd, lpq,
lpr, ls, lsattr, lsmod, lsof, lspci, lsscsi, lsusb, lzcat, lzma, lzop,
makedevs, makemime, man, md5sum, mdev, mesg, microcom, mkdir, mkdosfs,
mke2fs, mkfifo, mkfs.ext2, mkfs.minix, mkfs.vfat, mknod, mkpasswd,
mkswap, mktemp, modinfo, modprobe, more, mount, mountpoint, mpstat, mt,
mv, nameif, nanddump, nandwrite, nbd-client, nc, netstat, nice, nl,
nmeter, nohup, nproc, nslookup, ntpd, nuke, od, openvt, partprobe,
passwd, paste, patch, pgrep, pidof, ping, ping6, pipe_progress,
pivot_root, pkill, pmap, popmaildir, poweroff, powertop, printenv,
printf, ps, pscan, pstree, pwd, pwdx, raidautorun, rdate, rdev,
readahead, readlink, readprofile, realpath, reboot, reformime,
remove-shell, renice, reset, resize, resume, rev, rm, rmdir, rmmod,
route, rpm, rpm2cpio, rtcwake, run-init, run-parts, runlevel, runsv,
runsvdir, rx, script, scriptreplay, sed, sendmail, seq, setarch,
setconsole, setfattr, setfont, setkeycodes, setlogcons, setpriv,
setserial, setsid, setuidgid, sh, sha1sum, sha256sum, sha3sum,
sha512sum, showkey, shred, shuf, slattach, sleep, smemcap, softlimit,
sort, split, ssl_client, start-stop-daemon, stat, strings, stty, su,
sulogin, sum, sv, svc, svlogd, svok, swapoff, swapon, switch_root,
sysctl, syslogd, tac, tail, tar, taskset, tc, tcpsvd, tee, telnet,
telnetd, test, tftp, tftpd, time, timeout, top, touch, tr, traceroute,
traceroute6, true, truncate, tty, ttysize, tunctl, ubiattach,
ubidetach, ubimkvol, ubirename, ubirmvol, ubirsvol, ubiupdatevol,
udhcpc, udhcpd, udpsvd, uevent, umount, uname, unexpand, uniq,
unix2dos, unlink, unlzma, unshare, unxz, unzip, uptime, users, usleep,
uudecode, uuencode, vconfig, vi, vlock, volname, w, wall, watch,
watchdog, wc, wget, which, who, whoami, whois, xargs, xxd, xz, xzcat,
yes, zcat, zcip

これだけ入ってればたいていのことはできるのではないですかね。

 

続いて、ftpの動作テストです。

FFFTPなどを使用して、接続設定を作成し、接続してみます。

f:id:honeylab:20210526021243p:plain


 SDカード上の録画ファイルは /media/mmc/record に発生します

f:id:honeylab:20210526021341p:plain

このように、mp4ファイルが個別にアクセスできます。

telnetftp、この二つがあれば外部からのファイルアクセスの自動化は十分に可能だと思います。

例えば、一定時間ごとにFTP経由で同期するようにNASに設定したり、別のマシンからとりに行く、などが自由にできると思います。

 

最後に、この操作に関して、製造元は一切関知していませんので、問い合わせなどしないように。
また、いつ使えなくなるかもわかりません。
お約束ですが、これを実行したことで発生する不利益については関知しません。