honeylab's blog

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

atomcam_toolsをATOM Cam Swingに対応しました

現状、atomcam_toolsの機能としてはmnakada氏のforkがかなり高機能になっていますが、
私のほうで公開していたv1.0rc2およびそちらのforkが現在ATOM Cam Swingには対応していない状態でした。

そのため、とりあえずv1.0rc2を修正してまずはATOM Cam2と同様に使えるように修正しました。

github.com

 

修正個所としては、モータドライバが読み込まれていない部分を追加

github.com

 

しただけです。

また、mnakada氏のforkでは、atomcamの起動スクリプト内で無線LANドライバを読み込んでいる部分が独自記述になっていて、ATOM Cam Swingで発生したドライバファイルの移動に対応できていません。

github.com

私のほうは、ATOMCam内のスクリプトを読み込むようになっているため問題が発生していなかったようです。

 

Swingで更新された起動スクリプトを貼っておくので…是非…ご対応を…っっっ

gist.github.com

ATOM Cam Swingが発売されたので(略)

Image

今回、水面下で噂のあったATOMCamの新製品

なんと防水屋外用のパンチルトカメラ

ATOM Cam Swing」が発売されました。

 

f:id:honeylab:20211210103312p:plain

※アプリのバグにより突然現れた新製品の表示を発見されたユーザが掲示板に書き込んでいました(テスト環境を間違えてコミットしたとのことです)

 

実は今回、発売元のアトムテックさんがご乱心で、この、ATOMCam改造ブログの主でもある私に発売前テストユーザーに選んでくれる、という事故が発生しました。

 

f:id:honeylab:20211210104837p:plain

大丈夫…??

 

しかし、発売前日に情報公開して翌日発売、とはちょっと予想してなかったですね。

(発売日まで内密に、とのことだったので上の書き込みは私が直後に発見して担当者に連絡し、投稿者さんに連絡の上削除させていただいたとのことです)

実は、技適の検索には9月ぐらいから乗っていたようですが、誰も見つけてなかったみたいです。

 

f:id:honeylab:20211210103733p:plain

さてさて、今回はかなり思い切った防水対応なうえに、価格はなんと4280円。
これは思ってたより安いです。

(アトムテックならかなり安い値付けをするだろうけど、それでも4800円かな、と思っていました)

 

そして気になるのは防水性能。
本チャン発売機が手に届いたのと引き換えに、テスト機を分解してみました。

(テスト機とは言いますが、技適にも出してるのでたぶん同じだと思います)

 

特に防水機ですから、分解に手を染めるのはなかなか覚悟がいると思いますので、
こちらの記事を見ていったん手順を確認してからのほうがいいともいます。
(いや、分解しないほうがいいと思うよ)

 

ATOMCam2と同じように、フロントカメラの保護パネルを剝がします。

Image

ねじを四本外すと、パッキンがついたユニットが外れます。
Image

Image

ぱかっと開いた様子。(見日下の青黒白の線は後付けのシリアルの配線です)

 

基板の写真。SoCはATOMCam2と同じIngenic T31 、無線LANチップはATOMCam2後期ロットと同じATBMです。それに加えてモータドライバ用の回路が増えているぐらいで、イメージセンサはATOMCam2と同じはずです。

Image

ここまで書いて、写真を一枚ずつ張るのがめんどくさくなったので、
残りはTwitterからどうぞ(私は職業分解屋にはなれないな…)

 

そんな感じで、ちゃんと防水なんだと思います。

使い勝手のほうは、他のブログなりTwitterなりでレポートしてくれるでしょうw

 

さて、なんか面白い使い方できないかなぁ…

ATOMCam2の無線LANチップが変わっていた件

ATOMCam2、初回ロット、そのあとに届いた回収版、そして10月頃に買いなおした3台、どれもすでにバラバラになっているのですが、これらの基板についていた無線LANチップは、間違いなくRTL8189というものでした。

このチップは、普通に使えば子機にもなるし、hostapdを立てれば親機になり、
やろうと思えばad-hocモードという、いわゆる子機同士、ルーターなしでネットワークを構築することができるものでした。
なので、ちょっとこいつをいじって、ルータからの電波の届かないところでも、子機同士でルーティングしてデータを飛ばしたりしたい、ということを思いついていたので、追加でもう一台買ってみました。

すると…あれ??無線LAN基板の色が違うぞ…

f:id:honeylab:20211117153120p:plain

ATBM6031 … えっ、何それ、知らない

 

無線LANチップが変わってる…

 

嫌な予感…

Image

ああぁぁぁぁぁぁあ!!! ad-hoc(IBSS)が設定できないぃぃぃぃぃぃぃ!!!!

f:id:honeylab:20211117152125p:plain

ええええー。なんででしょうかね。RTLが入手不能っていうよりは、たぶん格安の無線LANチップが出たからっていうことで乗り換えたんだと思うんですけど…

ファームウェアを見ると7月ぐらいのにはすでに対応されていて、その後新しい無線LANチップでの技適申請の追加が行われており、適法に更新されています。

が、えーーー。

https://www.altobeam.com/api/sys/stl/actions/download?siteId=1&channelId=28&contentId=139&fileUrl=JDpii4VLW8obArXHgMAKFrRIZZN4Pxu7fawSYRX0slash0sT6V4Q0add0R8DhN0vPCBQMJ7Lbx1kVDP00MpQ2x7G4hmKZ30A0equals00equals00secret0


データシート的に対応しないってことはないような気がするので、あれやこれやといじってみてもダメ。

あちこち漁って出てきた、ATBM603xのドライバのソースとにらめっこしてみると、
デフォルトのソースではデバイス登録の時にフルスペックにしているのに、
ATOMCam2のドライバとして入れてるときにはなぜかAPとCLIENTにしか使えないようにプロファイルを設定しているようです。

f:id:honeylab:20211117152405p:plain

…えーと、運が良ければアドホックの部分のコードは入ってるはず。
ならば、登録のとこにパッチ当てたるわ!!!!と思ってやってみましたが(力技すぎる)
iw wlan0 info のところにはスペックが表示され、ad-hocモードになっているとは表示されますが、BSSIDの設定や周波数設定が動かず…ダメか…

リファレンスのソースコードはビルドはできるのですが、この無線LANチップはSDIOのため、ハード依存のmmcの初期化などのコードが含まれていません。
そこを自前で実装するのは大変です。


でもね。

f:id:honeylab:20211117152716p:plain

GPL!!!GPL!!!このドライバはGPL!!!
カスタムコード入れたとこ、まとめて頂戴!!!!

f:id:honeylab:20211117153018p:plain

待ってるにょ!!!!

 



 

ATOMCam2にDeibanを入れる

honeylab.hatenablog.jp

 

こちらの記事に引き続き。

せっかくオリジナルカーネルが動くことが確認できたので、ユーザーランドも入れてみることにします。
こういう組み込み機器で何かしたいとき、結局クロスコンパイルや何やらが必要になったりして、自分の好きなアプリを入れるのが難しい場合が多いです。
openmikoでも使われているbuildrootにはそこそこパッケージが準備されていますが、
それだけでは物足りなかったり、どうせだからセルフコンパイルしてしまえ、といった場合にapt-getが使えるdebianを入れてしまうとらくちんになります。

ちなみにこういうことができるのはArmadillo-440をいじっていた時に覚えました。

armadillo.atmark-techno.com

例えば、プレイステーションクラシックにdebianを入れる、なんてこともできます。

 

 

さて、しかしながらATOMCam2で使われいるCPUはMIPSとやや特殊な環境。
CPUIDを見るとMIPS R3000と出ていますので、対応しているディストリビューションは結構古く、どうやらDebian8(jessie)まで、の気がしました。

また、対応カーネルが3系、であり、これ以上の上位カーネルを作るのはおそらく無理だと思います。

というわけで、まずはbuildrootで簡易ユーザーランドを作り、debootstrapを使ってjessieを入れてみました。

 

…普通ならここで手順を書くべきですが、基本的にものぐさなのでそういう記録を全くとっていません(ポンコツ

microSDカードの第一パーティションに、カーネルのuImageであるfactory_t31_ZMC6tiIDQNを置いておくのはraspberry-piとかと同じですが、

ATOMCamを使うにあたって、複数のパーティションを作ったり、extパーティションを作るのはちょっと面倒です。そのため、ちょっと複雑ですが(atomcam_toolsも同じ方法ですが)、ext2ファイルシステムイメージをfatパーティションに置き、initramfsでマウント、switch_rootすることでdebianを起動させます。

 

というわけで、まずは結果のみ。

f:id:honeylab:20211018110536p:plain

ATOMCam2のMIPS上で動作するdebianです。

f:id:honeylab:20211018111009p:plain

Flash上のパーティションもマウントできますので、既存のシステムのファイルが読めます。
atomcam_toolsに、なんだかどんどん拡張用の修正を加えてくれる方がいるので、
これと結合すると、このdebian上でATOMのアプリを動かすこともおそらく可能になると思います。

いやまあ、わざわざdebian使うか?っていう話もあるんだけど、まずは動かしてみる、という環境を作る、っていうのはそれなりに大事なのよね。apt便利。

apt-getでセルフコンパイルgccを入れれば、なんとそこでhello,worldがかけるんですよ。

 

ATOM Cam2でSDカード上から自前Linux Kernelを動かす

honeylab.hatenablog.jp

 

↑のようなものを作るにあたって、今まではなぜか存在しているいわゆる「Test.tar」機能を利用し、起動中のスクリプトに割り込む形で各種機能を実現していました。

しかし、このままでは

・Test.tar昨日はrootfs内のスクリプトで実行されているため、メーカーがこの機能を外すと起動できなくなる

・iCamera_appなどを使わず、自前の録画アプリなどを動かそうとすると、その前にウォッチドッグが有効化されてしまい、定期的に犬に餌を与えなければならない。それは結構めんどくさい

など、若干の問題があります。

また、ハードウェアや周辺機器を最大に生かすためにはカーネルの再構築がどうしても最終目標として挙がってきます。

かろうじて今まではinsmod可能なkoモジュールの導入に成功していましたが、カーネルを実際にコンパイルし、flashに書き込んでみると途中で止まってしまったりしてうまくいきませんでしたが、あれこれオプションをいじっていることで、どうにか単体起動な独自カーネルuImageが完成しました。

しかし、これを実際に動かすためにユーザーがFlashに書き込むというのは若干のリスクがあり、また、それを動かすためのdemo.binを生成するというのも少々めんどくさいという問題がありました。

で、今までu-bootのメッセージに出ていたこのfactory_t31_ZMC6tiIDQNという謎ファイルを探している表示について改めて調べてみることにしました。

f:id:honeylab:20211008132622p:plain

すると、発売直後にアトムテックにオネダリしてもらったu-bootのソースコードの中に見つけました(まぁ前から見つけてはいたんだけど)

github.com

動作をよく見てみると、どうやらSDカード上にこのファイルがあると、メモリ上に全部ロードして、ヘッダチェック後、bootmコマンドで起動してくれそうな感じでした。

キタコレ!

f:id:honeylab:20211008133036p:plain

しかし、これではコマンドラインが固定されてしまっています。
おそらくrescure mode的な使用が想定されているのでしょう。

また、出荷時にu-bootのdelayが0に指定されているため、手動でu-bootの環境を変えるのもめんどくさいです。

そこで、カーネルコンパイルオプションとして、本来普通に起動するときに使われているパラメーターを埋め込み、さらに、起動時にu-bootから渡されるこのcmdlineを無視するように設定します(ふつうはつかわないきのうです)

f:id:honeylab:20211008133258p:plain

こうすると、内蔵Flashのルートシステムを使い、自前のカーネルで起動させられそうです。

出来上がったuImageを「factory_t31_ZMC6tiIDQN」の名前でSDカードに配置してATOMCamに挿入して電源を入れると…

 

見事にSDカードからカーネルを読み込んで起動してくれました!

Flashの書き換えも何も必要ではありません。ファイルを置くだけ。

Test.tarと違ってスクリプトへの割り込みやファイルシステムの縛りもない

自由なLinux環境が手に入りました。

また、これはuboot環境での仕様なので、rootfsやkernelのOTA更新によって改変される可能性がかなり低いです。素晴らしい。

 

とりあえずusb-hdmiを使ってHDMIディスプレイをつないで遊んでみる

ローカルの画像や動画が表示できるので、もしかしたらカメラの設置とかそういうのにも使えるんじゃね??とか思ってますが、もしかするとパフォーマンスが足りないかもね。

 

まぁ、こんな感じで割と簡単にLinuxを起動できることが確認できました。

いまはbuildrootでrootfsを作っていますが、普通にdebianとかも入れられる気がします。
ATOMCam2の暗視性性能はかなりお墨付きで、天文観察愛好家の方々がいろいろ試行錯誤して使っているのが観察されています。
このようなガチ工夫によって、何らかの新しい使い方が発見できないか、今後もいろいろ試していきますので、何かそういったことがありましたら是非教えてください。

 

 

atomcam_tools v1.0 rc2を公開しました。

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

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

github.com

 

ダウンロードは↑から。

FTPアップロードフォルダにスラッシュを入れるとうまく動作しなかった問題に対処しました(thanks to mnakada!)

 

そして、今までPCなどから画像を撮るためにはRTSPストリーミングが必要でしたが、待望のjpeg直接取得機能が実装されました。

 

これにより、ブラウザなどから表示することはもちろん、wgetなどで静止画を撮ることが可能になりました。

 

あ!!!今気づいたけど、この機能RTSPストリーミングを有効にしてないと動かないぞ…

あーー、まぁ公開しちゃったから次のリリースで治すね。

この機能が気になる方は、RTSPストリーミングをONにしたうえで /cgi-bin/get_jpeg.cgi を呼んでみてください! 

パラパラ連番サンプルとして /still_image.html も準備してあります。

ただし、このjpg取得ルーチンは、あまり多数のクライアントから同時に呼ばれることを想定していません。そうするとたぶん画像が壊れますので、
複数に配信したい場合はいったん何かで受けてからにしてください。

その辺もそのうち。