_❚ クラウドな太陽光発電と蓄電をやってみよう！

パネル１枚バッテリー１個のコンパクト・シンプルな蓄電システムを作ります。Galileoで発電／充電を制御し、その様子を”見える化”します。

かねてから太陽光発電と蓄電装置とを組み合わせたシステムには興味はあって電気エネルギーを買うばかりでなくDIYで作ってみたいと思っていたのですが、実用的な製作にはなかなか結びつかないでいました。
あの大地震から3年半、以来、太陽光パネルと各種バッテリーを組み合わせた市販製品は多く発売されていますが、今回はわたしなりに納得のいく機能・仕様をGalileoを活用して実現したいと思います。
試作という位置づけですので基本的な動作原理やハードウエア・ソフトウエアの枠組みの確立に注力することにします。

電気が足りるの足りないの、計画停電だのというあの時の事情は実は何も変わっていません。
2011年の出来事を忘れず、せまりくる次の災害への備えにも発展できればと思います。

本稿は2枚めのGalileoのレビューです。
前回の「3Dプリンタ」は、構想実験段階のまま頓挫したかの様相を呈しておりますが、技術的な課題がクリアされしだい、最終段階に入る予定です。
今回は、これまでのGalileoに関する蓄積をもとに他のレビュアーの方々が献身的に提供されている情報に感謝しつつ進めてまいります。

なお、このレビューはGalileoの活用を紹介する目的で執筆しておりますので、手順を再現するためにはさらなる解説や補足が必要かもしれません。

#PREMIUM REVIEW #プレミアムレビュー

_❚ 効率よく電気を取り出し蓄えるには？

高効率なMPPT方式*

バッテリーに充電するには、コントロールされた安定した電源が必要です。
太陽光パネルを直接バッテリーにつないでも充電できるかもしれませんが、全く充電できないこともあるし、どちらかが壊れたり、発火するかもしれません。
そこで、コントローラが必要となります。
自然エネルギーは、活用する側からみると安定しておらず、特に太陽光は１日の内で必ず変化しますし、天候、季節、地域などに左右されます。
太陽光パネルを充電用の電源に使用する場合は、一定の電圧に変換するだけでは足りません（市販のコントローラーには電圧変換の機能しかないものもあります）。また、太陽光パネルは負荷をかけ過ぎると電圧が一気に下がるという性質があるので、工夫が必要となります。
MPPT方式は、太陽光パネルから取り出す電力が常に最大となるよう調整しつつ充電や機器用の電源を作り出す方式です。

*  MPPT = Maximum Power Point Tracking

クラウドの可能性をさぐる
IoTというのが流行っているようです。
IoT（Internet of Things ＝モノのインターネット）とは、製品にネット接続の機能を付加してクラウド経由で情報や制御をやりとりする考え方です。電子レンジと洗濯機とですらつなげることができてしまうのですが、何のためにつなげるのかよく考えて作らないと、出来上がってから笑われます。
その点、発電／充電装置は、小規模なものでもIoT（ネット接続）機能があれば、手軽に装置の状況把握ができたり、マイクログリッドの一部となることができるので、利便性が向上するはずです。

_❚ 何が必要か？

機能の検討、仕様

今回の試作機のおおまかな要件を検討します。

• 充電はMPPT方式とする。できれば、過放電防止機能もつける。
• 太陽光パネルは100W程度のポータブルタイプ、
• バッテリーは、鉛蓄電池（12V、普通車に搭載されているくらいの大きさ）とする。
  （パネルとバッテリーを合わせて、子供でもカートで運べるくらいのサイズ）
• 発電／充電のログを取り、他機から閲覧できるようにする。できればクラウドに記録する。
• ネット接続はできればWi-Fiで。
• LCD表示はしない。本体のステータス表示はLEDで行う程度。
• 蓄電容量は、60WのノートPCなら10時間程度、20WのLED照明なら30時間程度。
  （12V、5時間率容量 は54Ahのバッテリーを用います）
• 太陽光のみでの充電時間は未知数です。

要件を実現するためのToDoリスト

回路はシンプルなのに、考えるべきことがたくさんあります。

【充放電制御】

MPPT制御をするための回路設計と部分検証
― 電圧・電流のアナログ取得の方法の確認
― バッテリーへ向けるFETを使ったスイッチング部の部分検証
― PWM出力のコントロール方法の確認
― オシロスコープを何とかする
上記回路の制御プログラム（ハードウエアと合わせた統合動作確認）

【充放電モニタ】
Linux部分でWebサーバーとSQLサーバーが使えるようにする
― データ取得＋SQL書き込み（MPPT制御のループ内で）プログラム
― SQL読み出し、SQL読み出しリクエスト＋表示

_❚ Galileoとの機能的なマッチング

ハードウエア入出力

MPPT方式を実現するために、電圧・電流値取得のためのアナログ入力が3～4本、充電制御のためのPWM出力が1本必要です。入力は太陽光の変化に追従できればよいので、1秒に1回くらい測定できれば十分なはずで、低速なGalileoのGPIOでも対応できるはずです。PWMの周波数は、スイッチング電源のFETを駆動する周波数になるので15～20kHz程度必要なところ、回路図と仕様を読む限りできそうですがほんとうに実現できるのか実機で確認するまで不安ではあます。

Linux部分でモニタ機能

実況（実績）データを取得して蓄積する（＋クラウドへ送る）部分はLinuxで行います。Galileo公式のLinuxは、YoctoプロジェクトのPokyというディストリビューションです。Debianなどと勝手が違うようですががんばってなんとかしていきたいと思います。

類似機との比較

ちなみに、RaspberryPiは、SQL、WebサーバーをLinux上で内部に持つことができるのですが、PWMの周波数が数百HzどまりなのでFETを駆動することはできません。
また、ArduinoUNOは、PWMの周波数を必要なところまで引き上げることはできそうですが（レジスタの操作が必要）、単独ではネット接続機能やそれ用のデータ保持の方法がありません。
よって、これらのことが１枚のボードで実現できればGalileoは理想的な１枚と言えるでしょう。

市販品の状況

なお、今回製作する規模のMPPT方式のコントローラは市販品では中国製品が１万円前後から入手できますが、この価格帯ではネット接続機能を含む製品は見当たりません。
メガソーラーで用いる規模の製品では当然通信機能を含んでいるでしょうし、一般住戸用ではパワーコンディショナーがそれにあたり、「HEMS」（ヘムス）という業界規格（発電データや家電品の連動の通信用のプロトコルとデータ仕様（？））も提案されています。

_❚ どこまで行けるか

このレビューのゴール
MPPT回路は、シンプルな実験回路を検討していますが、市販製品ではもっと何らかのテクニックが入っているかもしれません。
電源制御回路は、アナログ的な要素が大きく、プロの設計者もどこか職人的経験に基づいているようなところがあります。なので、今回は実験レベルのMPPT方式でどの程度の充電ができるか検証したいと思います。
データ取得・記録・表示部分（”見える化”部分）は、データ保持・表示ともにGalileo内に持つか一部クラウドに分散するか検討中ですが、いずれにせよ他機（PC、タブレット）の画面で確認できることを目標とします。

ゴールの先

出来上がる前から夢ばかり語ります・・・

ネット機能が備われば、装置の様子をツイートしたりメールしたりできそうです。
また、負荷側の接続機器によりますが、電気の使用状況のデータを活用して、たとえば、ひとり暮らし世帯のライフマーカーとして遠隔地から見守りができたりするかもしれません。
平時の使用は12v仕様のLED照明などを想定していますが、災害時には携帯・スマホ用の複数の充電口を備えて、避難所などで利用できるようにしておきたいです。

興味ある方があれば、このシステムが再現できるよう、オープンソース的に広めたいと思います。ワークショップなどができれば、みんなで楽しみながら発電ができます。

_❚ Galileoのセットアップ

電源で注意事項あり

ACアダプタのケーブルとUSBケーブルを抜き挿しする順番は守らないと壊れるかもしれないとのことです。
起動時：ACアダプタケーブル → USBケーブル の順に挿す
終了時：USBケーブル → ACアダプタケーブル の順に抜く
（正確には、「電源はACアダプタから取れ。USBの電源を使うと壊れる。」と下記「Galileo GettingStarted」にあります。回路図を見るとACアダプタが挿されていない時は、内部でUSBの電源に切り替えて使うしくみになっているので、USBからの電源で動作する場合に不具合が起こると理解すれば上記の抜き挿しの順でよい考えられます。なお、2014年5月にGalileoのACアダプタのリコールがアナウンスされており、このボードの電源まわりは注意して扱った方がいいのかもしれません。ACアダプタを急に抜き挿ししないとか、IOピンにつなぐ回路は定格に注意して優しく扱うとか、挿し間違いにいつも以上に注意するとかくらいしか思いつきませんが。）

はじめに必要な情報は公式サイトで

製品には一般的な安全に関する注意書きが各国版で添付されるだけで、他に何の案内も同梱されません。一見不親切なようですが、ひと通りの情報は公式サイトに揃っています。

公式ドキュメント（一覧）
https://communities.intel.com/community/makers/galileo/documentation/galileodocuments
公式ダウンロード（一覧）
https://communities.intel.com/docs/DOC-22226

電子的なドキュメントなら机上に紙類が増えないのでエコといえばそうかもしれません。検索もラクですが、ポストイットが貼れないのが不便です。
公式ドキュメントは英語です。日本語版は見当たりません。
ダウンロードてきるのはドキュメントもイメージ類も最新版だけです。どうしても旧版が欲しい場合は、非公式なものを探すことになるのかと思います。

箱から製品を取り出してするべきことは、Intelのサイトにある「Galileo GettingStarted」（PDF）に記述があります。
付属品は世界対応のACアダプタだけです。
USBケーブル、microSD、LANケーブルなどは別途準備します。

電源投入！ ～ テストラン
まずは、適切なプラグをセットしたACアダプタを接続して、Arduino互換のIDE（統合開発環境）をインストールしたPCとUSBで接続します。このとき、Galileoは、FlashROMの小さなLinuxで起動しますが、LANやmicroSDは使用できません。プログラムをUSB経由でロードできますが電源を切ればプログラムは消えてしまいます。
この状態でIOピンには何も挿さなくてもオンボードのLEDを点滅させるサンプルプログラム（Arduinoでプログラムのことをsketchと呼びますが、Galileoでも踏襲しています）がIntelのサイトからダウンロードできますので、これを走行することで初期動作の確認が可能です。

基板を安定させるために４隅にスペーサを取り付けておきます。

Galileoの時計
もちろんハードウェアクロック（CPUとは独立したRTCによって管理される時計）を搭載していますがそれ用のバッテリーがオプションなので、起動のたびに時計はリセットされます。
ハードウェアクロック用のコイン形バッテリーを付加するか、システムの起動時に毎回時計合わせの操作を行うかそのようなプログラミングが必要です。

システムクロック（Linuxカーネルが管理している時計）を操作するコマンド：
date（手動で設定）、ntpdate（ネットにつながっていればNTPから取得して設定）
ハードウエアクロックを操作するコマンド：
hwclock（電池がなければ設定しても無意味です）

ファームウエアのアップデート

本体のファームのアップデートはIDEから行います。
2014年7月末現在の最新版は、1.0.2 です。ファームの更新は、一度行うと、以前のリビジョンに戻すことができません。今回は最新版が良かろうということで何も考えず更新しましたが、のちに後悔することとなります。
IDEの機種選択の項目に「Galileo2」の文字が見えます。IDEはこのバージョンからGalileo2に対応しているようです。
Galileo2の発売アナウンスは早くからありましたが、現物はまだ入手できる状態ではないようです。

microSDから起動

microSD用のイメージをダウンロードし、「Galileo GettingStarted」の手順にしたがって作成したmicroSDを本体のカードスロットに挿し起動すると、microSD内のLinuxから起動するようになります。起動に約58秒かかりました（ACアダプタケーブルを挿してからSSHが使えるようになるまでの時間）。

microSDを使用すると、IDEからロードしたプログラムはmicroSDに保存されますので、再起動した場合、すでにロードしたプログラムがあれば自動的に走行するようになります。
また、microSD内のLinuxを使用することで、SSHが使えるようになります。Wi-Fiも使えるようになるとありますが、Wi-FiとはUSBドングルタイプのアダプタのことなのかminiPCIeタイプなのか、両方可能なのか、後ほど試します。miniPCIeタイプだとさらにアンテナが必要だったり、電波法上の懸念が残るので、工夫が必要になるかもしれません。

_❚ GalileoのLinuxは、初体験がいっぱい♡

Galileo公式のLinuxは、上でも書いたとおりYoctoプロジェクトのPokyという見慣れないディストリビューションです。組み込み用Linuxとのことなので、案外身近でそれとわからず存在しているのかもしれません。
ところが、いざ触れてみると apt も yum もなく、パッケージマネージャとしては opkg というのが含まれているのですが、レポジトリやパッケージリストを変更する方法があるのかないのか、それさえわからない状況です。使い慣れたapacheやSQLiteがインストールできないので困惑しました。

特に公式Linuxは機能を限定してコンパイルしているようで、なにかと不自由なようです。

RaspberryPiでは、用途に応じてカスタムチューンされたLinuxのイメージが豊富に配布されていて、公式サイトや非公式サイト、雑誌（日経Linuxなど）にも紹介されています。そうなら便利なのですが、現在のGalileo界はそのような状況にありません。

非公式のLinuxイメージを使ってみる

対処方法はいくつかありました。

▷メジャーなディストリビューションを自前でGalileo用にソースからコンパイルする

自分で作るほどの知識もありませんし、模倣できそうな情報もありません。「１つのイメージを作るのにコンパイルに十数時間かかり、エラーが出るとやり直し」との情報もありましたので、できるだけ避けたい作業です。

▷メジャーなディストリビューションに公式のLinuxイメージから必要なファイルを追加/置換する

手順を提示してくれている方がありましたので、実際にやってみました。たしかにイメージは完成しますが、手順そのものに”未解決な問題”が残っていたり、起動すらしなかったりします。起動しない原因の１つに本体のファームとのバージョンの不整合もあったかと思います。

▷ 非公式Linuxイメージとして公開されているのを利用させていただく

結局これを選択しました。

公開されている中には、上記の第２の方法でマージして作成されたものと、Intelから公式にリリースされている「Board Support Package Sources for Intel Quark」（BSP）を利用して作成されたものがあります。後者は限りなく公式に近いので、ファームのバージョンに注意さえすれば、確実な動作が期待できます。ディストリビューションは自動的に yoctoとなりますが、その代わりコンパイル環境などのツールが豊富に組み入れられています。

AlexT_Intelさんの非公式microSDイメージ

それで、BSPを利用して構成された非公式Galileo用Linuxイメージを次のリンクからダウンロードして試したところ、WebサーバーやSQLをインストールするところまでできました。

AlexT_Intelさんは、中の人を思わせるIDですが、非公式な方のようです。とても親切に対応してくださっているので助かります。

image-devtools-1.0.2-1.tar.bz2
https://communities.intel.com/message/241462#241462

PCとの接続（LAN経由）

SSH接続やSCP接続に問題はありません。

ArduinoIDEのプログラムの受け付け、USB経由でOK。

非公式イメージの中には、ArduinoIDEとの連携機能を外してしまっているものもありますが、こちらは、ちゃんと転送できました。
 

PWM、OK。

LinuxのGPIOを経由して行うPWMの動作を確認しました。今回、最優先の機能です。とりあえず安定して出力できるようです。ただし試した周波数は1kHzまでで、さらに速いPWMについては未確認です。
ちなみに、GalileoのPWM出力は8本あります。その全てがハードウエア出力です。しかもCPUとは別のIC（CY8C9540A）が出力を担当しておりCPUはそのICに対してI2Cを通してコマンドを発行するだけなので、CPUの負担は少なくかつ波形の安定したPWM出力が期待できます。

CY8C9540A自体は、PWMを16本出せるのですが基板上で結線されていません。線をICから直接引き出せば、もしかすると、使えるようになるのかもしれません。

大変わかりにくいですが、手前のLEDは、5秒間隔で 90％→40%→10%→90％・・・ とGalileoのPWMで明るさを変化させています。その変化を 別のArduino＋PCの簡易オシロスコープ（後述）で観測しているところです。

アプリケーションのインストールは、ソースからコンパイル

次に、アプリケーションのインストールを試みました。
パッケージマネージャは非公式版でも相変わらず opkg のままですし、wget や git コマンドは発行できるのになぜかエラーになります。

けれど、nginx（webサーバー。発音はエンジンエックスが正式らしいが、ねぎねっくすと言ってしまう）と MySQL(（SQLサーバー）のインストールはできました。
別のPCでダウンロードしたソースの圧縮ファイルをSCPで転送、通法にしたがってコンパイルを開始するとmake install まで完走しました。途中、依存するファイルを別途ダウンロードする必要があったり、エラーで進まず１つ古いバージョンのソースで再コンパイルしたりして、都合丸１日かかりました。普段 apt や yum を使えば数分で終わる作業なのに、ちょっと苦労が多すぎました。

nginx (webサーバー)に他機からアクセス、OK！

MySQLのコマンドプロンプト、出た！

特に、MySQLをコンパイルするためにCMake というビルドを自動化するためのプログラムが必要で、これのインストール（コンパイル～ビルド～メイク）に時間がかかりました。CMakeが必要ない旧版のMySQLか、他のSQLを選択すればよかったかもしれません。
今回の要件ではもっと簡単なDBやWebサービスで十分なのですが、GalileoがどれくらいフルスペックのPCに接近しているかということを確認したかったということもあって、こうした選択をしました。

組み込みLinuxと仲良くしよう

どうにかインストールはできましたが、さらに、OSの起動時にそれらアプリも自動起動する設定は Debianなどと方法が異なります。具体的には、service コマンドがありません。start-stop-deamon というコマンドが対応するようですがオプションや文法が異なります。また、組み込みLinuxならではの仕組みとして BusyBox というのがあって、cp や ls などのコマンドはBusyBox として一括してコンパイルしてあり、それはコンパイルの手間の簡略化とバイナリのディスク専有を節約する目的とのことです（コマンドを発行する際には意識する必要はありません）。

組み込みLinuxの事情に慣れるのにはしばらくかかりそうです。

_❚ 役に立ちそうなこと

レビューの本題からそれるかもしれませんが、あれこれ探すうちに興味深いものを発見したので２点ご紹介します。

Arduinoで簡易オシロスコープ

Arduino 簡易オシロスコープ - 九州工業大学情報工学部

http://www.iizuka.kyutech.ac.jp/faculty/physicalcomputing/pc_kitscope/

電源関係のハードウエアを作るのならオシロスコープは必須ツールなのですが、実は所有していません^^;
ArduinoとPCで簡易的なオシロスコープができるというのを発見したので使わせていただくことにしました。PC側のプログラムは「Processing」というJavaでできた仕組みで動いています。
厳密な波の形よりもおおまかな周波数やデューティ比が確認できればよいので今回は十分活用できそうです。

「Processing」は、PCもOSも幅広く対応しているので、Celeron 900MHz 機に Konalinux というちょっと酷な環境で試用してみましたが意外にも実用に耐える動作をしています。

「Processing」でGalileoのことをモニターできたりするといいなと思っています。今回余力があればprocessing の利用も考えてみたいです。IDEの見た目がArduinoの色違いになっているのも意味がありそうです。

Processing

https://www.processing.org/

GalileoでWindowsAPI ？

Windows Developer Program for IoT
http://dev.windows.com/en-us/featured/Windows-Developer-Program-for-IoT

どうやら、GalileoでWindowsAPIが動くということらしいです。マイクロソフトの公式で、開発環境はVisual Studio の模様。しかも費用がかかるという記述はありません。おもしろそうなので、いずれ試してみたいと思います。

 （2014/07/27 ここまで）

_❚ ハードウエア

どんな回路にするか

以下の要素を含みつつ、GalileoのGPIOとの接続を検討したのが下図の回路です。

・ 電力を扱う回路：

100W程度の太陽光パネルの使用を想定していますので、5～10A程度流せる回路設計が必要です。

配線材も部品も定格が足りないと発煙や発火の危険がありますから注意します。

・ PWM制御でDCDC変換：

MOSFET（モスフェット）で入力電力を高速でON-OFFし、その波形をコイルとコンデンサで平準化して充電に使用します。そのON-OFF制御にGalileoのPWM信号を利用します。PWMの周波数は15kHz以上で0から100％まで1％以下のステップで変化させます。

・ 測定：

１秒に１回程度の周期で常に入力の電圧、電流を測定します。最大の電力が得られるポイントを探すためです。

・ 過放電防止、過充電防止：

バッテリーの電圧が設定した電圧以下になると、つながっている機器へ電力の供給を止めるためのスイッチです。バッテリーの電圧が低下し過ぎると再び充電するのが困難になるからです。

充電中、バッテリー電圧が一定以上になった場合は、バッテリー保護と安全のために充電を中止します。バッテリーの電圧は常に監視しているので、基準に達した時PWMのデューティを0％にしてMPPTの電力変換を止めることで実現できますので、そのための回路は必要ありません。

一般に、12Vの鉛バッテリーは、無負荷時電圧で、
・充電終止電圧：13.7V
・放電終止電圧：10.8V

とされているので、この範囲で充放電ができるようにします。

（回路図CAD： BSch3V） 

電圧と電流の測定 

電圧・電流の測定を入力側と出力側で行っていますが、MPPTで電力を制御するのに必要なのは入力側の測定値だけです。出力側の測定は、制御結果（蓄電状況）や電力の使用状況の確認と過放電防止のために行います。

電圧の測定は、3.9kと1kの抵抗で約1/5に分圧した値を用いています（回路図左下の囲み）。精度は5％の抵抗を使用していますが、この電力変換で最終的に必要なのは相対的な最大電力なので、誤差は問題になりません。誤差が大きいことが問題となるようなら、プログラムの方で補正して値を利用します。

電流の測定は、専用ICを使用したユニット基板を購入しました。

・sparkfun ACS721(x05B)電流センサモジュール

VCC（５V）を電源として0Aのとき2.5Vを基準に、プラス方向マイナス方向とも1Aあたり185ｍV増減した電圧を出力するので、Galileoのアナログポートで受けます。

MOSFETで電力の変換 

MOSFETにはその構造の違いから、PチャンネルタイプとNチャンネルタイプがあります。

今回は、Pチャンネルを使用しています。（FX20ASJ-03F）

Nチャンネルの方が電気的な効率が良く品種も豊富なのですが、付加回路なしには回路のプラス側（ハイサイド）でON-OFFさせることができません。

今回の電力変換では、典型回路でBuck型（降圧型）のDCDCコンバータを作ろうとしていて、ハイサイドでON-OFFのできるMOSFETが必要です。Nチャンネルで実現できないわけではありませんが、回路が少し複雑になってしまいます。

一方、Pチャンネルは電気的な性能はNチャンネルに比べて劣りますが、回路のプラス側をON-OFFさせることができるのでわかりやすい設計の回路が可能です。
過放電防止回路は、回路のマイナス側をON-OFFする方法でも実現可能なのですが、グランド側をON-OFFするのはどうしても気持ちが悪いというのもあって（回路全体が不安定にならないかという心配）、電力変換で選定したのと同一のPチャンネルMOSFETを選定しました。

MOSFETをドライブするためにデジタルトランジスタを使用しています。（RN1201）

通常タイプのトランジスタをデジタル回路に使用する場合の定型的な抵抗を内蔵しているので便利です。

今回は、MOSFETとトランジスタの部分をユニット化して、後日交換して試せるようにしました。（回路図の点線の囲みの部分）

たとえば、NチャンネルMOSFETをこの回路で使用する場合は、別途絶縁型のドライバ回路を組むか、専用のドライバICを使用することになるのですが、そのような実験も可能です。

出力側の電圧センサーのところが制御した結果の電力になっています。

出力側のMOSFETは、過放電時に負荷への出力をOFFにするスイッチです。MPPT用のFETユニットと同じ回路です。

ユニバーサル基板 

回路図の右下の囲みがGalileoのGPIOコネクタです。arduinoのシールド用のユニバーサル基板に中継用のコネクタを載せてメインの電力変換回路とケーブルでつなぎます。
シールド基板をほぼコネクタとしてしか使用していなくてもったいない感じですが、追加で何かを載せたい気はしています。

今回は、MOSFETのユニットもユニバーサル基板を使用していますが、配線の下書きのつもりでPCBCAD（Eagle ＝ 基板パターン作成CAD）を使用しました。回路図からネットリストを作ると自動配線も可能なCADですが、今回は使用していません。

回路図を見ながらユニバーサル基板に部品をいきなりハンダ付けしていくこともできそうですが、後戻り作業が発生すると結局面倒なので前もって画面上で結線してみます。

実体配線図のように配線
実際に結線したところです。

実用機では部品の形状やスペースにしたがい、効率や安全性、耐ノイズ性を考慮して基板のパターンを作りますが、今回はできるだけ回路図の配置にあわせて実物の部品を配置しています。

線が未整理ですがちゃんとつながっています。（出力側の電流センサーは故障したので外しています。）

ターミナルや端子を多用して部分の交換や測定を行い易くしておきます。部品のトラブルや改変を想定しています。

太い線が電力系（黄：変換前電力、赤：変換後電力、黒：グランド）、細い線が制御系です。電力系と制御系の分離には気を遣います。

電力系と制御系のグランドは、どこか１点だけで接するようにします。それぞれの回路のグランドはどこをとっても全く同じ0Vというわけではなく、 特に電力を扱う回路では場所によってグランドの電位が微妙に異なることがあります。「１点グランド」はこのように異なる電源を持つ回路どうしを接続する場合のセオリーです。

Galileoからの線は、５Vとグランドの線を余計めに出しているので多くみえますが、信号線としては６本です。

電力を変換している部分です。

ポリプロピレンのトレイを裏返して、カッティングマットも裏返して重ねて実験台にしました（いずれも100均商品）。大きさは、A4版相当です。
実用機に組み替えてケースに収める場合は、メイン回路は10cm 四方くらいの基板に収まるのではないかと思います。
けれど、大電力化する場合は、放熱性と配線の安全性の点からこのくらいの余裕があった方がよいのかもしれません。

_❚ ソフトウエア

node.js を試してみる
Galileoのセットアップのときに、webサーバーのnginxとデータベースのMySQLをインストールしました。これらとpythonのプログラムを記述して制御するつもりだったのですが、node.js（ノードジェイエス）をsocket.io（ソケットアイオー）というプラグインとともに使用すると、ブラウザとの間で双方向にリアルタイムな処理ができることがわかりました。 

しかも、node.js のプラグインに galileo-io というGalileoのインタフェースへアクセスを簡単にしてくれるものがありました。さっそく利用することにしました。

Lチカ^*の場合

たとえば、SSHから次のように操作すると、デジタルの6番ピンがONになります。

# echo -n "1" > /sys/class/gpio/gpio24/value

（Linuxでは、ハードウエアのIOもファイルのように扱い、そのときのデジタルの6番ピンの値を示すファイル名とパスが /sys/class/gpio/gpio24/value）

スケッチなら、

digitalWrite(6, HIGH);

です。

node.js でも、

board.digitalWrite(6, 1);

と書けます。

ただし、どの場合もそのピンについてあらかじめ信号の向きなどを設定しておく必要があります。

＊ LEDチカチカ＝初めてのハードウエアや言語環境を体験する際によく行われる

双方向・リアルタイム

node.js は、単体ではスケッチで書くのと変わらないかと思われますが、socket.io をプラグインすることで、クライアント（ブラウザのHTML）とリアルタイムな双方向の処理をしながらIOを変化させたり、その変化をクライアントに反映することができます。

このことにより、Galileoの操作手段として、LCDやボタンの付いたarduinoのシールドを流用した方法とは別の有力な方法が見えてきました。

（2014/09/04 ここまで）

_❚ MPPT用PWMパルスの生成

このシステムで最も重要な機能です。

MPPTは日照の変化に追従するしくみ

太陽光パネルは、負荷を接続して電力を取り出すと電圧と電流が低下します。

最大限の電力を取り出すには、負荷を接続した状態で負荷が必要とする電流と電圧を変化させつつ得られる電力を計算して電流と電圧が最適なポイントを常に探し続ける必要があります。

太陽の高度や雲の影響で日照条件が時間の経過とともに変化するので、”常に”得られる電力を計算して最適なポイントを得ることになります。
引用図で、電圧を取り出すほど（x方向にプラス）、電流が下がります（y方向にマイナス）。または、電流をたくさん流すと電圧が下がることになります。電力は、電圧ｘ電流なので、グラフ上アミの部分の面積が最大になるポイントが、得られるエネルギーが最大になるポイントです。

MPPTの方法とアルゴリズム

MPPTを実現するには、周期的（1秒～数秒ごと）にパネルの電圧と電流を測定して電力を計算します。電力の変化を監視して電力が最大になるよう、出力を調整します。

すなわち、ある時間ごとに測定を継続するとして、ある測定点の電力が前の測定点の電力より大きくなっていれば、次の時点で取り出す電力も増加するよう調整します。また、ある測定点の電力が前の測定点の電力より小さくなっていれば、次の時点で取り出す電力も減少するよう調整します（山登り法）。

原理的には、この図のようなフローで処理できます。

• データを２つ（電圧、電流）取得

↓

• 出力増減の判定

↓

• 出力値を決定しパルス出力

というプロセスを数秒ごとに繰り返します。

node.js でMPPTを実現する

ところが実際には、値を取得、パルス出力変更、変化を観測するタイミングを考慮する必要があり、ループする速さや、与える変化量に調整が必要です。

特に、Linux上の node.js は、マイコンのように厳密にミリ秒単位でタイミングを取ることが難しく、調整は、実験を繰り返し、経験的に設定値を詰めていく必要があります。
さらに、node.js に socket.js をアドインしてHTMLと通信しているので、この通信のタイミングとの兼ね合いもあります。

このように現物合わせ的な作業に、HTMLで作成した操作画面がたいへん役っています。

GalileoのPWM周波数（クロック）を変更する

MPPTを実現するためにはPWMのデューティの調整するだけでなく、あらかじめPWMの周波数を適切に設定しておく必要があります。これは、MOSFETによるBuck型（降圧型）のDCDCコンバータを動作させるための設定で、今回の回路では、15kHz以上に設定する必要があります。

次の手順で行いました。

① i2c-tools を下記URLからダウンロードし、インストールします。（コンパイルが必要です。）

http://www.lm-sensors.org/wiki/I2CTools_Documentation

② node.jsで次のようなコードを書きました。

まず、IOエクステンダIC（CY8C9540A）の設定を変更します。

// CY8C9540A (チャンネル:0 アドレス:0x20 クロックのレジスタ:0x29 1.5MHz:0x02)
// クロックが1.5MHzのとき、パルスは20kHz となる

var exec = require('child_process').exec,
　　child;
　　child = exec('/usr/local/sbin/i2cset -y -f 0 0x20 0x29 0x02',
　　function (error, stdout, stderr) { // 戻り値がないので不要かもしれないが、
　　　　console.log('stdout: ' + stdout); // 定形のままにしておく
　　　　console.log('stderr: ' + stderr);
　　if (error !== null) {
　　　　console.log('exec error: ' + error);
　　}
});

これは、node.js から外部コマンドを実行する手法です。エラー処理の部分は念のためお手本どおりに残しています。SSHコンソールで、

# ./i2cset -y -f 0 0x20 0x29 0x02

を実行するのと同じです。

実際にPWMを使用するには、さらに

this.pinMode(5, this.MODES.OUTPUT);

を記述します
node.js のプラグインの galileo-io を前もって下記からインストールしています。

https://www.npmjs.org/package/galileo-io

以上で、PWMの周波数を20kHzに設定とピンの初期設定が出来ました。

MPPTの動作の最適化

・動作周期

10秒間隔に設定しています。
１回ごとのMPPTコントロールの変化が現れるのは即時というわけでなく、また日照の変化におよそ追従できれば十分なので、もっと長くてもよいかもしれません。

・変化量

PWMのデューティは0～255の値で設定します。255を設定すると、100％のデューティとなります。
太陽からのエネルギーが増え、デューティを増す場合は、256ステップの内の4ステップずつ加算しています。
逆に、減らす場合は、2ステップずつです。
デューティ増加動作による電力の変化には限度があるので、速めの増加曲線を描くような動作でも問題が起きません。PWM値は255止まりであり、発生できる電力量は日照のエネルギー、パネルの性能に制限されるからです。
これに対して、デューティを減らす動作の場合は、電力量を増やすことが目的なのに、場合によっては減ることもあります。その減少をきっかけに日照状況によっては、なだれを打つように0にまで達することがあります。下りのステップ幅を小さくしてゆっくりとPWM値を減らすことでこの誤った減値をさけることにしました。

ロジックのセオリーはあるのか？

Galileoの処理が十分速く、処理中にフリーズ（アベンド）することはまずないので、node.js の性質を織り込んだプログラムを作ることによって正常に動作させることができています。

正直なところ、まだよく理解できていない部分もあります。

たとえば、node.js で アナログポートを読む場合、

board.analogRead('A1', function(data_n1){

　　～ 処理 ～

});

とコード中に１ヶ所書くと0.1秒くらいの周期で常に読み取りが実行されます。
他のポートの読み取りをする記述が同じプログラムにある場合、どういう順番で読みに行くのかよくわかりません。読み込むと 「～処理～」の部分が実行されます。 

１回だけ読みに行きたいときはどうしたらいいものか、いまだにわかっていないのですが、今のところ20～100回分の結果の平均値を測定値として使用するとか、カウンタを設けて回数が満ちたときにルーチン外へ値を渡す処理をすることで対処しています。

もしかすると、この対処で正しいのかもしれませんし、他によりよい解があるのかもしれません。

処理が輻輳しても大丈夫

ポートを読み取る他に、1000ミリ秒ごとに行うタイマ処理やPWMのパルスを出力する処理も同時に行っています。

感覚的には、ポートの読み取り、タイマ処理、socket.ioでHTMLからやってきたデータに対処するそれぞれの処理が複数同時並行に走行しているか、それらの処理か発生するたびにインタラプトが発生している感じです。順番に上から処理しているわけではなく、処理が輻輳しているようにみえても、止まってしまう気配はなく、各処理はきちんと完結しています。このシステムを繋ぎこんだ時点からずっとGalileoの電源は入れたままで再起動すらしていません。プログラムの更新時にnode.js のリスタートはしますが、OSの再起動の必要は感じません。 
Galileoも、いったんシステムが安定すれば、堅牢なデバイスという印象です。

実際に、下記のHTMLからの操作で手動、MPPTの計算による制御ともにPWMを変化させることができていて、発電も蓄電も可能になっています。

アミかけ部分が未完成です。

デバックは、console.log を活用して変数をSSHコンソールに表示しながら行います。

_❚ ブラウザから操作する

上記の node.js を自動起動に設定しておけば、日照のあるときにMPPT方式で発電・充電することは可能になりました。

加えて、今回は実験とデータ取りをしたいので、手動でPWM値を変更できるスライダーや、すべての測定値を示すインジケータ、負荷を手動でON-OFFするスイッチを備えた操作画面をHTMLで記述しました。

もし実用機とするなら、発電電力、使用電力のリアルタイム表示があれば十分かと思います。

HTMLでできているので、PCだけではなく、タブレットやスマホでもアクセスできます。

基本的な画面のデザインの枠組みにBootstrapを使用し、いまどき風のフラットUIのパーツを集めて作り込んでみました。テンプレート等は使用しておらず、ソースのほぼ全部がオリジナルです。

http://getbootstrap.com/

太陽光発電は、日照と密接に関係するので、天気情報（現在天気）が表示できるようにしました。OpenWeatherMap というサイトから情報をJSONで取得して30分ごとに更新するようにしています。

http://openweathermap.org/

HTMLは、上記のnode.js とリアルタイムかつ双方向に通信しています。 

・パネル電圧

・パネル電流

・バッテリー電圧

・負荷電流（センサーが故障しているので現在 値なし）

・発電電力（パネル電圧 x パネル電流 の計算結果）

以上は、画面更新の操作などなしにインジケータが変化します。

・MPPT自動 ON-OFF スイッチ

・負荷側 ON-OFF スイッチ

・PWM値の手動設定 スライダー

をそなえ、

・PWM値（node.jsからの実データ）

・現在天気（30分毎に更新）

・現在時刻（1秒毎に更新）

などを表示しています。

表示や操作のタイミングは、ほぼ即時です。遅延による違和感はほとんどありません。

たとえば、ブラウザの画面から負荷ON-OFFスイッチをONにすれば、HTMLから即座にnode.js

に通信がおこなわれ、その瞬間にLEDが点灯します。

これにより、ブラウザがGalileoの操作パネルの役を担うことができるようになりました。

このあと、「クラウドな」の部分＝発電の実績を記録するためのデータベース、データを閲覧するためのグラフを含む仕組みをつくります。 

データを見える化することで、発電の様子を楽しむだけでなく、おうち発電の意義や今後のことなど、わかりやすくなることと思います。

_❚ 途中ですが、気になる点をいくつか

node.js 内のループ処理

node.js にsetInterval や setTimeout で繰り返し処理のループを作っていて、複数のクライアントから接続した場合、そのクライアントごとにループが起動します。
そして、そのクライアントとの接続が切れても（ブラウザを閉じるなど）ループは回ったままです。

さらに、クライアント のHTMLをリロードするとリロードの回数分ループの数が増えます。

結果、同じループが無数に動き始めます。

node.jsの制御方式は、スレッドモデルではなくてイベントループだと言われます。そのことが奏功して、ノンブロッキングなプログラムが記述できている限り、現状のようにループが多数走り始めても全体がクラッシュすることはありません。しかし、たとえば当レビューで行っているMPPTの制御の対象は１つなので、幾つものループから制御が発生すると電力デバイスが混乱してMPPTの動作が乱高下するなどの事態に陥ります。
DBへの書き込み処理を行う場合、重複書き込みなどの弊害があるかもしれません。

適切な処理としては、おそらく接続してくるクライアントごとのスレッドを管理するとか、リロード分のループは止めるとかであるとは思いますが、いまのところその方法を習得していません。
そこで対症的な策として、ループの中でタイマー変数を持って、if文で判定しながら処理をすることとしました。

// 時間変数は、グローバル

var pastTime = new Date();
var pastMsec = pastTime.getTime();
var nowTime = new Date();
var nowMsec = nowTime.getTime();

setInterval(function(){
　　var nowTime = new Date();
　　nowMsec = nowTime.getTime()
　　if(pastMsec + 8000 <= nowMsec){
　　　　～ 処理 ～
　　　　var pastTime = new Date();
　　　　pastMsec = pastTime.getTime();
　　}
}, 1000);

（1000ミリ秒ごとにループがまわります。スレッドが複数ある場合はもっと短い周期でまわりますが、いくつのループがまわっていても、実際の処理は8000ミリ秒に1回だけ実行する対策をしたコードです。）

これだと、MPPT処理の重複実行は避けられますが、node.js の中に不要なスレット（ループ？）が残っていても放置することになり、いずれ破綻する可能性もあるので根本的な対応が必要かもしれません。
解決案としては、一定時間通信のないスレットをdisconnect するような処理をいれるとか、ループにIDを振って最新の１つだけを実行しあとは止めるとか、そもそもMPPTのnode.jsとクライアントと通信するnode.jsを分けるとかの方法もあるのかなと思いますが、未解決です。

MPPT制御の最適化

MPPTをコントロールするために、電力値の変化によってPWMのデューティを変化させています。そのPWMのデューティの変化量を条件によって増減させることが有効ではないかと考えています。

たとえば、起動直後や日照条件が急変した場合は変化量を増やして最適値にいち早く達するようにし、MPPTで生成する電力が安定していて変化が少ない場合は、PWMの変化量を減らす、などです。具体的には、パネル電圧とバッテリー電圧の差が大きい場合はPWMの変化量を増やすということで良さそうですが、設定を決めるのには実績データが必要です。
また、一定以上電力が変化しない場合はPWMの値も変更しない方が安定することは当初から考慮していて、この判定と制御はすでに実装しています。

Galileo自身の消費電力

発電量が数W増減するたびに一喜一憂するような小規模発電ですので、Galileoの仕様にある「最大 TDP 12.5 W」が実際にはどうなのか、省電力動作の可能性はあるのか、気になっています。

現在、Galileoは商用電源/ACアダプタで動作させていますが、最終的に独立した電源系としたいので発電した電力でGalileoを動作させる工夫もしたいと考えています。

ただ、あまりにもGalileoが電力を消費して、せっかく発電した電力を使い果たしてしまうような笑い話だけは避けたいと思っています。

ほんとうにMPPTが効いているのか

非MPPT方式に相当するサンプルとしてPWM値をマニュアルで80％に固定した設定と、今回作成しているオートなMPPTの設定とで発電効率を比較してみたいと思います。

文献によると、「MPPTは曇天時やバッテリーの電圧が低下しているときに有効」とあるので、そのような傾向についても検証できればと思います。

厳密な比較はできませんが、アルゴリズムがある程度決まって、データ取りとグラブ描きが可能になったら実施します。

（2014/09/12 ここまで）

_❚ SQLサーバーへ記録する

SQLサーバーを立てる

LAN内のサーバー専用機（HP MicroServer N54L ＋ Hyper-V）に設定した仮想マシンにCentOS7をインストールして、SQLサーバーとして使えるよう準備しました。
CentOS7は、このエディションからSQLが使えるリレーショナルデータベースとしてMariaDBが採用されていたり、コマンドが少し変更になっていますが、調べつつ構築しました。

たとえば、SQLサーバーにLAN内の他機からアクセスできるようにポートを開けるコマンドは次のようになります。

# firewall-cmd --permanent --zone=public --add-port=3306/tcp

MariaDBは、MySQLと全く同じコマンドで動作するので、設定コマンドやSQL文を書くにはMySQLの資料が役に立ちます。

SQLサーバーに次の設定をしました。

• LAN内の他機からアクセスできるようにポートを開ける
• 使用する文字コードをUTF-8 にする
• 外部からアクセスできる「どこからでもアクセスできる」アカウントを作成
• SQLデータベース「galileo_solar」を作り、そのなかにテーブル「10sec_real」を作る

データベース「galileo_solar」には、今回の蓄電システムだけでなく、同じシステムの複数台数や、他の機能のデバイスの記録も一括して収納することを想定しています。

テーブル「10sec_real」には、今回のMPPTの動作を逐次（PWM値の変化ごとに）記録していきます。「10sec」となっていますが、実際には8秒に1回新規レコードを生成しています。

テーブル「10sec_real」のための create文は次のようにしました。（テーブルの定義がわかります。）

create table 10sec_real(
　　id int not null auto_increment primary key,
　　device_id int,
　　panel_Voltage double,
　　panel_Current double,
　　load_Current double,
　　batt_Voltage double,
　　pwm_value int,
　　load_on bool,
　　mppt_on bool,
　　created datetime,
　　KEY created (created)
);

その時点で測定した電圧電流データのすべてと、PWM設定値、スイッチの状態、日付時刻、デバイスIDを含みます。

Galileo の node.js から SQLへ記録する

node.js から SQLへ接続するには、「node-mysql」プラグインを使用します。

# npm install mysql

でインストールし、node.js のはじめのところで、

• 宣言

var mysql = require('mysql');

• 接続

var pool = mysql.createPool({
　　connectionLimit : 10,
　　host : '192.168.0.64',
　　database : 'galileo_solar',
　　user : 'zigsow_user',
　　password : 'zigsow_pass'
});

とすると、プログラム中で次のようにアクセスできます。

• データ編集 

post = {
　　device_id: 1, // 1 = 'Galileo Solar'
　　panel_Voltage: 12.12,
　　panel_Current: 3.12,
　　load_Current: 4.13,
　　batt_Voltage: 12.78,
　　pwm_value: 128,
　　load_on: true,
　　mppt_on: true,
　　created: '2014-09-30 12:12:12',
};

• DBアクセス 

pool.query('INSERT INTO 10sec_real SET ?', [post], function (err, connection) {
　　if(err){ console.log(err);}
});

これで、連想配列型のオブジェクトpostに編集した内容が SQLデータベースのテーブル 10sec_real に1レコード追加されます。

データベースの open / close は、pool が管理してくれるので任せます。

MPPTを実行するモードでデータを連続的に記録した後、テーブルを直接開くと次のように確認できます。

日付時刻は、UTCで（協定世界時間(UTC)かJST(日本時間)か）

クラウドに移行することを意識する場合には、まちまちのローカル時刻を持ったデバイスが接続することを考慮します。
今回、SQLに記録する日付時刻はUTCとして、入出力の際にローカルな表示に変換することにしました。
また、UNIXエポック（1970-01-01T00:00:00（UTC）からの秒数）で記録することも検討しましたが、DBを直接 select した時の可読性がよくないので、文字列による表現としました。

たとえば、日本時間 2014年9月30日 22時33分32秒は、

• UNIXエポック ⇨ 1412084012
• 文字列による表現（UTC）⇨ '2014-09-30 13:33:32'

となります。

_❚ 記録したデータをグラフ化する

SQLサーバーからデータを取得して見やすく表示する

一般に、HTML（内に記述したJavascript）に直接SQLにアクセスするコマンドは書きません。そのような作りにするとセキュリティ上問題となるからです。そこで、HTMLからSQLに対して読み書きを行う場合は、サーバー側に何らかの準備をしてサーバー内でSQLコマンドを発行するようにします。

今回は、Galileo内の node.js が モニター画面（HTML）のwebサーバーの役割を担っていますので、SQLサーバーからのデータ取得も node.js / socket.io 経由で行います。
（他にCGIを使用してHTMLから .getJSON コマンドなどでデータの取得を行う方法もあります）
グラフの表示は、使い勝手が悪いですが当初の仕様として、8秒間隔で記録されたデータを新しい方から件数を指定して取得して表示することにします。

HTMLからwebサーバーへリクエスト

まず、[graph!]ボタン をクリックすると、フォーム（テキストボックス）に入力された値を socket.io 経由で node.js へ送ります。

$('#graphStart').click(function(){ // ボタン graph! をクリックした時の処理
　　// node.js に SQLの実行をリクエストする(グラフ描画のトリガーとなる)

　　var dataCont = $('#dataCont').val()
　　socket.emit('emit_from_client_sqlRequest', dataCont); 
});

変数 emit_from_client_sqlRequest は、HTMLからnode.js に渡るデータで、取得したいデータの件数が代入されています。

node.js がSQLサーバーへアクセスし、HTMLへデータを返す 

次に、node.js がSQLサーバーへSQLコマンド（クエリー）を発行します。

宣言や接続の手続きは初期設定としてすでに実行しているので、コマンド発行時には不要です。

SQL文にHTMLから受け取った取得したいデータの件数を編集しています。

// 【ボタン graph!】 SQLの実行リクエスト受信
socket.on('emit_from_client_sqlRequest', function(data){
　　// クエリー実行
　　pool.query('select * from 10sec_real order by id desc limit '+ data , function (err, results) {
　　if(err){ console.log(err);}
　　socket.emit('emit_from_server_sqlResults', results);
});

クエリーの結果は、変数results に返ってきます。

変数resultsには、次のような配列がリクエストした件数分連続して格納されています。

0: Object

　　batt_Voltage: 12.39

　　created: "2014-09-30T22:46:26.000Z"

　　device_id: 1

　　id: 52734

　　load_Current: -0.003959

　　load_on:0

　　mppt_on: 1

　　panel_Current: 0.2111

　　panel_Voltage: 12.55

　　pwm_value: 194

開発用の仕様なので、取得できる件数に制限もなく、輻輳処理もしていない状態ですが、テスト環境で1000件（約2時間分のデータ）をリクエストしてからグラフを描画するまで約19秒かかっていて、その時間のほとんどはGalileoがデータを中継する処理時間です。その間Galileoの稼働は topコマンドによると node.js の分として99％に達していて、他の処理は止まった状態です。モニター用の通常のデータ更新が行われず、8秒間隔で記録しているデータの記録ができなかったりしますが、全体の処理が混乱して結果が返ってこないということはありません。

しかし、実用的な処理と操作を考慮すると、たとえば現在の環境でこの項目数の取得なら、1度の処理で100～300件程度が限度のようです。

取得件数や範囲指定をできるようにして使い勝手やレスポンスの向上を図りたいところです。

HTMLでグラフを描画する

node.js から渡ってきた配列をグラフのプラグインが受け取れる形式の配列に編集します。
その時、電流と電圧から電力を計算し、日付時刻文字列をUNIXエポックの数値に変換します。

グラフのプラグインは、Flotr2 の MouseZoom を使用しています。

http://www.humblesoftware.com/flotr2/

このグラフは、リアルタイムの動作を確認するためのグラフです。

• アミ付き薄青：発電実績
• 薄緑の線：消費実績
• 赤の線：MPPT用PWMの値

8秒に1回更新されるPWM値によって電流や電圧が次の瞬間にどう変化していくかモニターできます。
グラフは拡大したい範囲をドラッグすると詳細が観察できるグラフです(上の画像は画面キャプチャーなので、操作はできません。)

時間単位、日単位の発電実績、消費実績のグラフは別途計画（作成）中です。

_❚ グラフ付きの操作盤としての画面

ヘッダ部

• リアルタイム発電量（テキスト表示）
• 時計表示（テキスト）
• 天気（天候、気温、雲量、日の出／日没時刻 ＝ OpenWeatherMapから取得）

メイン部

• PWMマニュアル操作スライダ
• 負荷のON-OFF（バッテリーの電力を外部のデバイスで使用する時ONにする）
• MPPTのマニュアル操作のON-OFF（手動でPWM値を設定する時ON）
• リアルタイム発電量（インジケータ表示）
• リアルタイムパネル電圧（インジケータ表示）
• リアルタイムパネル電流（ゼロ点調整付き）（インジケータ表示）
• リアルタイム負荷電流（ゼロ点調整付き）（インジケータ表示）
• リアルタイムバッテリー電圧（インジケータ表示）
• メッセージ表示（Galireo から HTMLへ、 任意のメッセージを横スクロール表示）

グラフ部

• 8秒ごとのデータを新しい方から件数を指定して１つのグラフに表示する
  （横軸：時間、縦軸：電力（ｗ）または、PWM値）

そのほか、ファビコン（ブラウザのタブに表示されるアイコン）や天気表示のアイコンを編集しました。

_❚ MPPTのアルゴリズムは意外に複雑

原理的にはシンプルなMPPTですが、実際に試験運用を始めると、状況を判断してそれに応じた制御が必要なことがわかりました。

条件によって、PWMの上げ幅、下げ幅を変化させ、場合によっては変化させないロジックを含みます。

もっと整理した適切なアルゴリズムも考えられるのかもしれませんが、ある程度冗長的な部分を許し、わかりやすい流れで処理するようにしました。

このロジックを8秒に1回実行しています。（当初10秒毎でしたが、少し速くしてみました。）これにより、MOSFETへのPWMパルスのデューティが変化し（グラフの赤色の線）、パネルから取り出す電力を最適に調整しています（グラフの薄青色の部分）。

_❚ Galileoの電源回路（5V）はACアダプター直結

回路図によると、GPIOコネクタJ2A1の5Vピンに出力される V5_ALW_ON ラインは、ACアダプタの電圧のままなので、正確な5.00Vがほしい場合は、レギュレータなどで安定化した方がよさそうです。
電流の測定にACS712電流センサモジュールを使用していますが、このデバイスは、電源（VCC）の5Vを基準にして、0.0AのときVCC半値の2.5Vを出力し、プラスマイナス両方向の電流が測定できる仕様です。そのためVCCが安定かつ正確でないと正確な電流値が得られません。
Galileoの内部の結線を意識せずに電流を測定し続けたところ値が安定しないので、不可解に思っていました。
正確に測りたかったのでとりあえずの対処として、測定プログラムの方でゼロ点調整ができるようにしました。
論理的には、入力が0.0Aの時センサーの出力は2.5VでAD変換後の値は5V全値1023の1/2の511か512が返るはずですが、現状では521～524となっていて高めな上に一定していません。
ACアダプタの電圧が一定でないことが原因のようなので、根本的な解決にはなっていませんが一応実際の値に近い値を測定できるようになりました。

_❚ システム全体の仕様（できあがり）

結局、Galileoはイノベーションだった
Galileoで、nodo.js を使うことによって、LinuxPC的な機能とマイコン的な機能とが融合したようなシステムができました。
socket.io で クライアントのHTMLとの間でリアルタイムな双方向通信を行い、node-mysql により、SQLサーバーとデータの授受を行い、同時並行にMPPT用のMOSFETを駆動する・・・などということは、PCだけ、またはマイコンだけでは困難だっと思います。
「Arduinoとの互換」が情報としてインパクトがあるため、そのためにGalileoの実力が伝わっていない気もします。（不完全な互換仕様のために評判を落としているかもしれません。）

たしかに、組み込みLinux機として性能を発揮させるためには、Linuxのビルドから行う必要があって、そのための情報が十分ではありませんでした。たとえば、USBにWi-Fiのトングルを挿して無線LAN化するには、Linuxのカーネルを対応したものにしなければならず、手間がかかります（当初は、ビルドが必要ということさえわかりませんでした）。

けれど、刻々と情報は増えつつあり、Galileo2 も入手可能となっている現在の流れでは、今後とも急速に開発しやすくなっていくのではないかと思われます。
そして、CPUとしてQuark SoC X1000を搭載した小型ボードは、ウエアラブルなものも含めていくつか発表されていますので、入手が待たれるところです。
Quark SoC X1000 にせよ、他のARMアーキテクチャ品にせよ、クラウドやIoTを意識していてOS層にLinuxのベースさえあれば、開発の手法は汎用化されどんどん便利なものになっていくのかなと感じます。
Galileoはその新しいステージの扉へ案内してくれた、と言って良いかもしれません。

このレビューで身についた（かも知れない）スキル

• nodo.js （Javascript）のコーディングが少し上手になったかもしれません。
• 最新のCentOS7 ＋ MySQL の扱いについてフォローできました。
• MPPTのノウハウが実機をとおして理解できました。
• 鉛バッテリーの挙動について、複数のプロに質問する機会もあってよく知ることができました。（本文には記述していませんが、その情報はアルゴリズムの検討にたいへん役に立ちました。）

クラウドへの可能性
GalileoからLAN内とはいえ外部のSQLに読み書きをしながら、別機のブラウザからGalileoの操作をしデータを受け取ることができました。
IPアドレスやファイアーウォールの調整は必要ですが、LANもインターネットも同じ技術で成り立っていますから、このシステムも Galileo から直接クラウドに接続できるメドが立ったと言ってよいかと思います。

_❚ このあと・・・

• 集計データをクラウドから閲覧する
  （時間単位、日単位、月単位、年単位の集計をグラフとともに閲覧できるようにする）
• 電源を充電したバッテリーからとり、独立した電力系にする
• バックパックキャリー に積んで持ち運べるようにする

などを計画していますが、レビューとしてはここで一区切りとさせていただきたいと思います。
当初計画していましたクラウドの部分は、引き続き別のレビューで実施してまいります。

そこで、これからの構想・・・

（2014/10/01 ここまで）

（自分用メモ）追記予定：

バッテリーの写真、仕様、セルあたりのこと

MPPTありなし測定

ソースコードについて： 

ソースコード、回路図データを公開することを拒むわけではありませんが、このレビューには、スペースがなく、ZIGSOWのサイトの作りもその目的には適さないので、ここには全ソースを掲載することは見送ろうと思います。

別途、GitHub などに公開することを検討しています。（需要があればｗｗ）

出典・参考・謝辞：

下記を参考にさせていただいています。ありがとうございます。

引用方法などに問題がございましたらお知らせください。いつでも訂正いたします。

・トランジスタ技術 2005年9月号「太陽電池応用製作への誘い」CQ出版

・エレキジャック No.10（2009）「太陽電池を使った電子工作」CQ出版

・「ＧＲＡＮＡＤＡの電子工作コーナー」のうち、MPPTに関するページ

  http://www.asahi-net.or.jp/~se1m-nitu/html/electro.htm

・「MPPT Solar Charge Controller #1 - Introduction and Voltage Measurement」

  https://www.youtube.com/watch?v=MSz4-cr3EJw&list=PLjzGSu1yGFjWv4KeN-7TSYeQIcicM9Ghl

・「最大電力点追従の基礎」ナショナル・インスルツルメンツ社

  http://www.ni.com/white-paper/8106/ja/

変更/更新履歴：

2014/07/27 一次公開～セットアップ、SQLサーバー・Webサーバーのインストールまで
2014/09/04 ハードウエア組み上がり、疎通チェックまで
2014/09/12 MPPT発電OK、操作画面作成中

2014/10/01 SQLデータ書き込み、グラフ描画、MPPTのアルゴリズムまとめ、全体仕様