TensorFlowを試してみる(1)

ふとTensorFlowを試してみたくなりました。(そのためにDocker環境作ってました)

で、なかなかよさげなTensorFlowのチュートリアルを発見しました。

TensorFlow入門(https://deepinsider.jp/tutor/introtensorflow

こちらを参考に進めてみます。

第2回の環境構築でつまづきましたので、そのメモです。

環境は、冒頭に書いたとおり、TensorFlowを試すためにDockerの環境を作ったので、Docker前提で進めます。(Docker環境にしたのは、現状のLinuxMintの環境をできるだけ壊さないためです)

で、TensorFlowの公式サイト(https://www.tensorflow.org/install/)を参考にTensorFlowコンテナをインストール、起動します。

公式サイトの冒頭の起動方法では、まず docker run コマンドに -u オプションをつけろ、と警告が出ます。上記では「-u $(id -u):$(id -g)」を付けています。
しかし、この環境では python のバージョンを確認すると2.7でした。python3とするためにコンテナのタグに-py3を付けます。

python3での対話モードでの確認もエラーは出ませんでした。が、こんどは Jupyter Notebookでハマります。結局、ホスト側でJupyter Notebookのディレクトリをまず作ります。

その上で、Jupyter Notebookに対応したイメージを引っ張ってきて起動します。

ということで、

で起動するのが最終形となりました。起動後、ブラウザで表示されたトークンを含む形(今回の起動であれば http://127.0.0.1:8888/?token=3dcab8dd69809896495d64041dba74e654c52612ea877c70 )にアクセスすると、

こんな感じでアクセスできました。ちなみに、Docker環境を終了させる場合には、Ctrl + Cで「y」入力です。

とりあえず、第2回まで完了です。

Dockerでイメージ・コンテナを作ってみる

とりあえず、空のubuntuのイメージの雛形を作ってみる。

Dockerfileに元になるイメージとイメージ生成時に実行するコマンドを記述して、docker build コマンドでイメージを実際に作成、docker images コマンドで作成されたイメージを確認。元になった ubuntu イメージと作成した my-ubuntu イメージが存在することを確認。

イメージを起動するが、net-toolsもない状態なので ifconfig もエラーになる。
そこで net-tools をインストールして ifconfig コマンドを実行。当然うまくいくが、そのまま終了してみる。

終了してもコンテナ自体は残っている。そこで、残っているコンテナを廃棄して、再度起動して ifconfig を実行すると、エラーになる。つまり、前回イメージを起動した状態と同じ状態になっている。

再度イメージを起動して net-tools をインストールして終了、コンテナIDを確認。

コミットしてコンテナを廃棄。

イメージを起動すると、今度は net-tools がインストールされた状態で起動される。historyも残っている。

つまり、以下のような感じで作業していけばよさそう。

  • 失敗したら終了してコンテナ廃棄。再度イメージを起動してコンテナ生成して再トライ。
  • うまく行ったら、節目節目でコミット。
  • 手順がはっきりしたら、history で作業手順確認してDockerfileに記述、イメージ生成してうまく行っているか確認。

Docker CEをインストール

LinuxMint19にDocker CEをインストールしてみます。

Ubuntuへのインストール方法を書いていただいている方がたくさんあるのであまりハマりどころはないのですが、注意点はリポジトリの設定のところです。

まず、レポジトリ設定の前の部分まで。

リポジトリの設定のところはUbuntuと同じ方法のままでは後でエラーになります。このためUbuntuの場合と異なる作業になります。

あとはUbuntuと同じ作業です。

最後のは一般ユーザーでdockerを実行するために必要なグループ設定です。一旦ログアウトしてログインし直します。

こちらの記事を参考にさせていただき、hello-word コンテナで試してみました。

Google Cloud Print Connectorを設定

これまでAndoidから印刷するのに、わざわざGoogle DriveかGmail経由でLinux Mint側にファイルを持ってきて、それから印刷していたのですが、これが面倒なので、Google Cloud Printが使えるように設定してみます。
プリンタはBrother HL-2240DでLinuxMint19のPCにUSBで接続しています。

1.インストールと設定ファイル生成

まずはSynapticパッケージマネージャで「google-cloud-print-connector」をインストールして、引き続き設定ファイルを生成します。

ローカル印刷は引き続き使うので「Yes」を入力

クラウドプリントを使うので「Yes」を入力

ここでGoogle Chromeを起動して、https://www.google.com/device にアクセスするとGoogleアカウントの認証を求められるので認証ログイン。さらに、コードの入力に移るので、上記のコード(XXXX-XXXX)を入力。入力すると、コンソール画面が進んで、使わせたいユーザーの

Google Cloud Printを使いたいユーザーのメールアドレスをカンマ区切りで入力

入力すると設定ファイルが生成されたことが表示されます。

2.動作テスト

試しに動かしてみます。

Android側では「クラウド プリント」をインストールします。

インストールされた状態でアプリケーションのメニューで「印刷」を選択して、「プリンタの選択」でLinux側でCUPSで管理されているプリンタを選択して、プリンタのアイコンをタップすると印刷できました。

3.自動起動の設定

cloud-print-connector というユーザー/グループを作成します。ホームディレクトリは不要、ログインしないのでログインシェルも不要です。

実行ファイルへのシンボリックリンクを作成します。

設定ファイルを /opt/cloud-print-connector にコピーして適切な権限を付けます。

systemd のサービスファイルをダウンロードしてインストールします。

Google Cloud Print CUPS Connector serviceを許可してスタートします。

停止する場合は、

とします。

鉛蓄電池を充電

4年ほど放置していた鉛蓄電池があるのですが、「ダメになってるかなー」と思ったけど電圧を測ってみたら11.6Vくらいあったので、充電することにしました。(追記:後で知りましたが、テクニカルマニュアルによると、ほぼ完全放電状態。室温での4年放置は「Not Allowed」みたい・・・・)

鉛蓄電池なので、定電圧定電流充電ということで、AliExpressでDC入力のCVCC電源ボード(しかも、Stepup-Stepdown両方で動けるもの)が安く出ていたものを購入。ボードの説明をよく見ると、出力側からの電圧印加はダメと書いてあったので、出力側で対策をすることにしました。単純にダイオードを入れようかとも思ったのですが、3Aくらいで充電すると2W近い熱がでることと、以前秋月で見かけたPowerPathコントローラICが気になっていたので、これを買って理想ダイオードの構成としてみました。

回路はほぼLTC4412のデータシートの表紙の標準的応用例のままですが、あくまで充電器なので、左のバッテリーのマークのところにCVCC電源ボード、右側のLOADのところに鉛蓄電池を接続、WALL ADAPTER INPUTのパスは削除しています。なので、LTC4412とPchのPowerMOSFET(今回は60V36Aの2SJ673を使用)とパスコン、接続部品・ヒートシンクのみというシンプル構成です。

実際に充電している歳の様子です。

今回作った理想ダイオードの部分です。かなり余裕のあるFETを使っているので、もっと大きな電流を流す用途にも使えるはずです。

組み立てが終わったら、まず入力にDC12VのACアダプタを接続してDCDCコンバータ単体で電源投入。UV-SET(入力電圧低下時のカットオフ電圧)FAULTのLEDが点灯しない位置にセットします。出力電圧をモニタしながらVOUT-SETの半固定抵抗を13.8Vにセット。CC-SETの半固定抵抗は(確か)左へ一杯に回しておきます。
次に、理想ダイオード部分をつないで電源投入。出力電圧が13.8Vのままなのを確認します。
さらに、鉛蓄電池のGND側のみ接続、+側はテスタで電流を測定できるようにして一瞬つないで電流を読みます。値は30mAくらいでしたので、CC-SETの半固定抵抗を回して1Aになるところにセットしました。
+側も直結したあと、最後にACアダプタの電源を切った時に、理想ダイオードの出力側は電池の電圧のまま、入力側の電圧は徐々に下がっていくのを確認して、完成です。

今回は補充電として使っていますが、鉛蓄電池ごとケースに入れてもっと充電電流を増やしてやれば、車で移動中に充電しておいてエンジンOFFの電源として使えるかなーとか思っています。(データシートによると3.6Aまでは充電電流を増やせそうです)

ESP32-CAMをテスト

Aliexpressで見つけた格安カメラモジュールのESP32-CAMを入手したので試してみました。OV2640カメラモジュール付きで$7.5という激安っぷりです。

1.ESP-IDFのインストール

まずはファームウェアをビルドするために ESP-IDF をインストールします。
インストールは https://github.com/espressif/esp-idf に沿って行えば難しくありません。(初期のESP8266の頃に比べると随分簡単になったような気がします)

環境変数を設定するため、~/.profile に以下を書き足します。

書き足したら、一旦ログアウトしてログインし直して、作業環境に反映させます。

2.ハードウェアの準備

ハードウェアの情報については、githubに上がっている仕様書を参考にしました。(※ダウンロードできなくなると手も足も出なくなるので同じものを113990580 ESP32-CAM Product Specificationに上げておきます。)

今回は、USBシリアル変換にFT234X使用のこちらを使いました。Linuxだといろいろトラブルが起きるのですが、セルフパワーで動かす分には大丈夫そうなので使ってみます。

ブレッドボード上にこんな感じで組んでみました。
シリアルの接続と、電源の供給(電源は仕様書の記載ではVccではなく5V端子に供給するようです)、それからブートローダモードにするためのIO0端子をGNDに落とす線の5本です。

3.サンプルのビルド

サンプルをビルドしてみます。

で環境設定をします。環境設定が完了したら、IO0端子をGNDに落とした状態でリセットボタンを押してブートローダモードに入ります。
※ウラ面なので、ブレッドボードに設置した状態だと大変です。リセットを押した瞬間に白色LEDが一瞬つくので、リセットを押せたかどうかは確認できます。

このとき、

としてシリアルをモニタしておくと、以下の表示が出ますのでダウンロード待機状態であることが確認できます。

screen コマンドを終了してから、

でビルドと書き込みを行います。完了したら、IO0のプルダウンを外してリセットするとシリアルに115200bps N81で以下のように繰り返し出力されます。

ということで、Hello world!を出力後、再起動を繰り返します。

4.カメラにブラウザでアクセス

以下のサイトを参考にして行いました。(参考というか、Windows環境かLinux環境かの違い程度で概ねそのまんまですが)
https://robotzero.one/esp32-camera-module/

顔認識のサンプルをgitから引っ張ってきます。

この中のCamera Web Server Exampleを動かしてみます

以下の項目を設定して保存します。

保存したら、ビルド&書き込みです。

しかし、ここで

というエラーが発生してしまいました。
ぐぐると、esp-idfが古そうな感じです。しかし、

としても更新してもダメでした。でも、よくみるとesp-whoディレクトリの下に、esp-idfが丸ごと含まれているっぽいです。ですので、こちらを IDF_PATH に設定して試してみます。

ということで、python絡みで何か文句を言っています。結局は pip がないために依存関係が満たせていないようです。

としてpipと必要なものをインストールした後、

で無事にビルド&書き込みができました。

しかし、書き込んでIO0のプルダウンを外してリセットしてもSSIDが見えません。

で見てみると、

ということで、Wi-Fiの初期化のところでBrownout Detectでリブートを繰り返しています。

PCから長いUSBケーブルで給電とシリアルコンソール確認を兼ねているので、電源のインピーダンスが高いことは確かです。そこで、1000uFのコンデンサをVcc-GND間に追加したところ、Webサーバの起動まで進むようになりましたが、スマートフォンを帰属させるとやはりリブートしてしまいます。そこで、短いケーブルでACアダプタから直接給電したところ、192.168.4.1にブラウザでアクセスすると設定画面が表示され、Get stillでカメラ画像も取得できるところまで行きました。
しかし、それでも動作が不安定です。FT234Xのシリアル変換モジュールには100mAのポリスイッチが入っているので、こいつが悪さをしているのか、あるいはまだ電源のインピーダンスが高いのかわかりませんが、今日はここまでとします。今後、レスポンスがどのくらいなのか、確認はしてみたいと思います。

#どのくらいのパフォーマンスか見たいだけなので、もう少し試してみたら、積みボードになりそう。

TTGO T-Cameraを開封レビュー

Twitterで見かけたESP32 WROVERとセンサー色々搭載のTTGO T-Cameraを購入してみました。(⇒Aliexpressのページ

ESP32 WROVERにカメラ、人感センサ、温度・湿度・気圧センサなどのセンサ、0.96インチのOLEDディスプレイ、I2Cでの外部拡張端子がついて、魚眼レンズタイプで17.6ドル(今はさらに下がって16.5ドル)で入手できる上に、githubでArduino環境のソースコードまで手に入ります。

梱包は比較的簡易なものでしたが、このようなポリプロピレン製のケースに入っているので、潰れて送られてくる、ということはなさそうです。

ポリプロピレンケースの中に入っていた製品はこのように帯電防止の袋に入れられて密封されていました。

開封するとこんな感じで、電池を接続するためのケーブルも添付されていました。ここにLiPoをつないで充電ができるといいのですが、そこまではまだ調べていません。

裏面はこんな感じです。

MicroUSBの端子がついているので早速適当なUSBの電源アダプタにつないでみると、こんな画面で崩れて表示されてしまいました。

この状態でも無線APとして動作していて、スマートフォンで接続でき、ブラウザで 2.2.2.1 に接続するとカメラ画像の取得などができました。

電源をPCから取ると、このように正常に表示されました。ACアダプタやモバイルバッテリーは軽負荷時にノイズが大きいので、その影響だったのだと思います。
しかし、温度表示が39.61℃と異常な値が表示されています。カメラ右下についているのがBME280だと思いますが、ESP32の自己発熱でかなり温度が上がってしまうのでしょうか??
温度がおかしいと、気圧や湿度も補正できないはずなので、残念です。

・・・と思ったら、バージョンアップ(?)により役に立たないBME280は削除されているようです。

ま、とりあえずおもちゃ入手レポートでした。(なんかおもちゃばっかりですが・・)

追伸

IPS液晶搭載の後継モデルが出ていました。人感センサとスイッチがなくなっているようですが、カラー液晶、MicroSDカードスロット搭載、BME280復活となっています。スイッチが残っていればUIとかも付けられるかな?と思うのですが、スイッチ無しなので用途がいまいち思いつかないところです。(バッテリー駆動するなら不要なときは液晶をOFFにしたいですし)

静的サイトジェネレータHugoを試してみた

このサイトは編集をいつでもどこでも簡単にできるようにWordPressで作成していますが、内容を固定したサイトの場合には、WordPressで作成すると定期的にアップデートが必要となるので結構管理が面倒です。(それでも、WordPressはセキュリティアップデートは勝手にやってくれるので、だいぶ楽ですが)

また、プラグインやテーマもちょっとマイナーなものを入れると、本体のアップデートについていけず、結構悩むことになります。

で、最近知ったのが静的サイトジェネレータというもので、マークダウン言語で書いた記事をHTMLとCSSに変換してくれるものだそうです。HTMLとCSSだけでデータベースなどはないのでセキュリティ上の心配も少なくて済むようです。で、変換したHTMLとCSSをまるごとサーバ上にアップロードすればOK(実際には同期するのかもしれませんが)ということらしいです。

今回はその静的サイトジェネレータの中からHugoというのを試してみることにしました。

1.Hugoの環境構築

今回は諸般の事情から、素のUbuntu18.04LTS環境に導入してみます。Hugoで検索すると、WindowsかMacOSのものが大部分で、Linux環境の場合にはどういうわけか(探し方が悪いのか)古いものしか見つかりません。どうせなら最新版をインストールしたいところです。そこで参考にしたのは一つ目はこちらの記事です。何はともあれ、参考にしながら最新版をgithubからダウンロードしてインストールしてみます。

下記手順で素のUbuntu18.04LTSに対してアップデートとVirtualBoxのGuest Addtionsのインストールを行った後、Hugoのバイナリパッケージをインストールします。
※今後の再テストを短時間で行うため、VirtualBoxのディスクイメージのスナップショットも採取しています。

2.新しいサイトの作成

3.新しいページの作成

以下の方法で新しいページを作成します。

実際にやってみます。

として、contentディレクトリの下のpostディレクトリの下に記事を生成します。生成したら、自動生成されたファイルcontent/post/test-page.md を編集します。冒頭の draft: の行は削除します。(この行があると、記事が生成されません)

4.テーマをダウンロード

テーマをダウンロードします。ここでは試しに mainroad というのを使ってみます。

mainroadというテーマを使うために、config.toml に

を書き足します。

5.サイトを生成してみる

で、publicというディレクトリが生成されて中にデータが生成されます。

で組み込みサーバーが起動するようです。http://localhost:1313/ でインデックスページにアクセスできますが、かなり質素です(mainroadというテーマはこんなに質素じゃないはずなので要調査)。Ctrl+C で停止できます。

このまま、

として、もう1ページを作成、content/post/sample.md を編集します。冒頭の draft: の行は削除しつつ適当に内容を作成すると、自動的にブラウザで開いていた記事のリストが更新されます。

記事を一通り作成したら、publicディレクトリを丸ごとWebサーバにアップロードすることで、公開完了、ということみたいです。(実際には rsync などで同期を取る形で運用するのが楽なのだと思います)

6.参考になりそうなもの

ラジアスゲージ作ってみた

これまでFusion360で現物合わせで何か作る場合には、円弧の部分は目分量でデザインして、現物合わせしていました。・・・がラジアスゲージ作ってみました。

上は Thingiverseにあったものを出力しただけのものですが、180度で作成されているため、例えばスマートフォンの角のRがいくつになっているのか等は確認できません。なので、下にあるように90度で設計してみました。

写真は厚さ3mmで出力したのですが、もう少し厚みがあってもいいかと思って5mmで出力し直しています(Fusion360の画面キャプチャは5mmに変更後です)

3Dプリンタで出力する際には少し潰れ気味(つまり、実際の半径は少し小さくなる方向)になるので、精度があるものではありませんが目安としては十分です。手軽にこういうものを作って使えるのはやっぱり便利です。

MKRVIDOR4000_graphicsの中身を見てみる

Quartus Prime LiteでMKRVIDOR4000_graphicsの中身を見てみます。

projectディレクトリの中にMKRVIDOR4000_graphics_lite.qpfがあるので、これをQuartus Prime Liteで開いてみます。

左の方のProject Navigatorのところでソースツリーっぽいところ(Entity)が見えて、ここに MKRVIDOR4000_graphics_top があるので、これをクリックすると、そのソースコードが開きました。トップレベルモジュールの verilog ソースコードのようです。端子の定義と信号の定義、出力バッファ近傍のセレクタなどがあるようです。

Project NavigatorでIP Componentsを選択し、EntityのところでMKRVIDOR4000_graphics_lite_sysをダブルクリックすると、Platform Designerが開いてIPマクロ間の接続の全体像が少しわかります。nios CPUのメモリマップもここで確認することができて、niosの命令バスはオンチップメモリとQSPIフラッシュメモリからフェッチできるようになっているようです。(SDRAM ARBITERとsdramのところを編集するとSDRAMからのアクセスもできるように修正できるっぽい雰囲気です)

上の方の再生ボタンみたいな Start Compilation をクリックすると論理合成して、配置配線、タイミング解析をしてくれます。Task のパネルに進捗が表示されて、完了すると、Entityのところに各モジュールの構造がツリー状に表示されました。このあたりをもう少し見ていくといろいろわかりそうです。

一方で、VidorBitstream-releaseディレクトリの下にipというディレクトリがあり、ここにIPコアのコードが入っているようです。各モジュールの softcore というディレクトリの下にFPGA側のniosのコードが入っています。graphicsの描画処理は ip/GFX/softcore/src/gfx.c というソースの中の gfxRpc() の中で受け取ったリモートプロシージャコールのパラメータに応じて描画関数を呼び出していました。

また、VidorBitstream-release/project/MKDVIDOR4000_graphics/build/software/launcher_lite_bspの下にsummary.html というファイルがあり、これがnios側の諸情報のようです。この中にLinkerのSectionに関する情報があり、nios側のコードもデータもbssもheapもオンチップメモリ上に配置されているようです。また、mem_init.mk というファイルによるとリセットベクターも 0x00a00000 となっているようで、これはメモリマップによればやはりオンチップメモリのようです。nios上のコードはniosとは関係なくオンチップメモリ上に転送しているのかもしれません。(FPGAのコンフィギュレーション時に書き込まれるんでしょうかね??)

まだまだ弄るといろいろわかりそうですが、時間もかかりそうです。