平たく言って、世界が変わる

なんと言うか、生成AIがすごい勢いで変化している。よく言われるが「寝て起きたら世界が変わっていた」。本当にそんな感じがする。

これだけ精度が高い応答をしてくると、コンピュータの使い方がおそらく変わる。なんでもAIに聞けばいいということでもないが、とりあえずAIに聞いてみるようになる。ググるのも技術だったが、プロンプトる（まだこんな言葉は生まれていないが）のも技術になりそうだ。

例えばこんなことを聞いてみた。

example.comなどで動くサービスの死活監視をするプログラムを作ってください。

１．ドメイン名とポート番号はSharePointに格納されたExcelファイル「サービス.xls」のそれぞれ1列目と2列目にあるものとします。空白行があるまでを処理対象としてください

２．ただし手作業でドメイン名とポート番号を指定できるようにもしたいです。

３．死活監視の間隔は10分に1回とします。

４．応答で得られたバナーを表示してください。

５．GUIで表示するようにしてください。

これに対するChatGPTの回答は以下の通りだ。

GUIを使用したプログラムを作成できないとな。

しかし、よく見ると「SharePointで」というのがまるっと無視されていた。そこで追加でリクエストを送る。

ExcelファイルはSharePointに格納されているのですが。

回答はこうだ。

実のところこの対話をしたときはChatGPTはご機嫌斜めで、何度もエラーが出た。エラーで記録されなかった回答の中にはPyQtを使ってGUIを作りかけた回答もあった。

そういうわけでまだまだ完成度は低いが、なんだかんだで使えそうなプログラムができてしまっている（使えるかどうかまでは確認していない）。自力でライブラリ探して一歩一歩進めるよりも、ずっと開発効率が上がっているのは確かだろう。

今までのコンピュータの使い方って、「調べて理解して実践する」という感じだった。これが「聞いてみて実践する」に変わるような気がする。冷静に考えるとこれは大きな変革であるように思う。

よく「創造的な仕事はAIに奪われない」というが、まったくの創造的な仕事って意外と少ない。そして「言葉を紡ぐ」という能力の大半は、一見創造的であるが実はこういう過去の経験の組み合わせで表現できてしまうということがChatGPTによって示されたような気がする。

いろいろな仕事のやり方というか、位置づけが根本的に変わってくるような気がしてならないのだ。

某社からもらったアレを分解してみた

4月に某社社長が就任してご挨拶状として配っていたのが結構面白そうだったのでバラしてみようと思って早数カ月。今日は一日雨だったのでまあちょっといい機会だと思って取り組んでみた。

ご挨拶状はコレ。

某社とか言っていたが、もう明らかにSAPジャパンであることが丸わかりだ。これを開くと、

画面に電源が入り、メッセージが動画で表示される。ちなみに下の部分にUSBのmicro-B端子があり、ここで充電ができるようだ。

推測すると、光センサーか磁気センサーがスイッチになっていて、マイコンが起動すると自動的に動画を再生する仕組みになっているのだろう。汎用性の高いマイコンボードを使っていたりすると、後々なにかの役に立つかもしれない。動画の再生なんで、まあそれなりの性能は必要なのでは？という期待もある。

あとたぶん充電池としてLi-Poがついていて、液晶パネルのコントローラーがついているのは確定だ。制御ボタンはタクトスイッチがそこに置いてあるパターンだろう。それこそラズパイとかArduinoとかであれば用途は広がるが、この厚さだとまんまそれ、ということはありえないのでそこまで期待はしていない。

というわけでガワをはがしてみた。

まあ概ね予想通りの構成。そりゃそうだ。スピーカーも付いているよな。さてボードは何だろうとクッションを剥がしてみると、

謎の赤外線体温計の説明書が出てきた。適当にもほどがあるというべきか、それとも「どうせこんなところ誰も見やしないのだから余った同一スペックの紙を使えばいい」という合理性を褒めるべきか。

で、まあボードである。

むーん。iPhoneの写真だとhynixのチップ以外よくわからない。HY50U5616はFlashメモリーか？この写真だとわかりにくいが、hynixのチップの下のテープは液晶とつながったケーブルの保護用なので、位置的にはLCDコントローラーかもという気もする。

と思ったらこっちはMicronか。型番で引くとこっちがフラッシュメモリーで確定。HynixはどうやらDRAMみたいだ。で、もうひとつがこれ。

うーむ。V100で検索してもNVIDIAしか出てこない。こいつがマイコンなのはほぼ間違いないと思うのだが。このリボンみたいなロゴはXかKか。もうちょっと調べてみよう。

（後日談）

Fbにこのプロセッサーの写真を投稿したら、某大学のセンセイが調べてくれた。こちらのマイコンのようだ。単にRISCとしか書いてないのでアーキテクチャーはよくわからない。イマドキならRISC-Vだろうけどちょっと古そうなので、MIPSあたりのアーキテクチャーを使ったパチもの系あたりだろうか。

用途は「DPF Player」や「Player application」とあるので、今回のような動画再生向けの組み込み用には適しているものなのだろう。

Machinistにデータを送ってみるテスト

某紙のコラムのネタにするので、IIJの「Machinist」をちょいと使ってみた。データロガー的な使い方が簡単にできるサービスだ。

簡単に言ってしまえば、IoTデバイスなどのデータをJSONのパケットに組み立てて、Machinistに対してHTTPSでPOSTしてやればずんずん積もっていくというもの。基本は時間ごとのデータしか取れないのでまあ何でも格納できるというわけではないが、センサーが発したデータや機器のステータスなどを放り込んでおくにはいいのではないかと思う。

普通ならまあ、ラズパイあたりを使うところなのだろうが、これくらい単純なものならむしろESP32を使うくらいのほうがリアルだし実践的だろうと思ったので試してみた（あ、そもそもWindows 10のbashからは試していたんだった）。

用意したのは適当にAliExpressかeBayかで購入した、Node-32コンパチの安物。今はArduinoで使えるようにしているので、そのままArduinoでスクリプトを組むことにした。一応ESP32には内蔵の温度センサーがあるらしいので、これを送ればそれなりになるかという目論見で本体のみである。

まず調べるのは温度のとり方だが、どうやら怪しいようではあるがこういうところがあったのでそれを使って動かしてみた。OK。値はベロベロでようわからんが、まあ動いている。

次はそれをJSONのパケットにするのだが、ヒアドキュメントが使えないのでだるい‥と思って一瞬microPythonに乗り換えようかとも思ったが、考えてみればJSONくらいArduinoでも扱う方法があるだろうと探したら、やっぱりあった。いくつかあるようだが、とりあえず今回使ったのはArduinoJsonである。

これでゴリゴリ組み立ててシリアライズすればいいわけだが、意外と面倒なのが本当に正しくできているのかの検証。ArduinoJsonの場合、いろいろと見ていたらAssistantというページがあって、サンプルのJSONを放り込んだらシリアライズするプログラムを自動生成してくれる。これがありがたかった。

おかげで温度チェックのあと、HTTPとJSONを入れ込んだスクリプトが一発で動いた。正確にはArduinoJsonのページで警告しているように、標準のライブラリアンでデフォルトを使うとベータ版が入ってしまうこと。Assitantのページで生成するのはその前の安定版用なので、ライブラリの入れ替えは必要だった。あと相変わらずプログラムの転送が安定していないので３回くらいやり直したのが面倒だった。

というわけでコードはこんな感じ。なんかインデントが変だけどわかるでしょ。

#include <WiFi.h>
#include <HTTPClient.h>
#include <ArduinoJson.h>

const char SSID[] = “<Your Wi-Fi SSID>”;
const char PASSWORD[] = “Wi-Fi PWD”;
const char URL[] = “https://gw.machinist.iij.jp/endpoint&#8221;;

extern “C” {
uint8_t temprature_sens_read();
}

void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
pinMode(LED_BUILTIN, OUTPUT);
WiFi.begin(SSID, PASSWORD);
Serial.print(“WiFi connecting”);

while (WiFi.status() != WL_CONNECTED) {
Serial.print(“.”);
delay(100);
}
Serial.println(” connected”);
}

void loop() {
if(WiFi.status()== WL_CONNECTED){ //Check WiFi connection status

HTTPClient http;

http.begin(URL); //Specify destination for HTTP request
http.addHeader(“Content-Type”, “application/json”); //Specify content-type header
http.addHeader(“Authorization”, “Bearer <Your API Key>”);

char buffer[256];
const size_t bufferSize = JSON_ARRAY_SIZE(1) + JSON_OBJECT_SIZE(1) + 2*JSON_OBJECT_SIZE(2) + JSON_OBJECT_SIZE(3) + JSON_OBJECT_SIZE(4);
DynamicJsonBuffer jsonBuffer(bufferSize);

JsonObject& root = jsonBuffer.createObject();
root[“agent”] = “ESP32”;

JsonArray& metrics = root.createNestedArray(“metrics”);

JsonObject& metrics_0 = metrics.createNestedObject();
metrics_0[“name”] = “temperature”;
metrics_0[“namespace”] = “Environment Sensor”;
JsonObject& metrics_0_tags = metrics_0.createNestedObject(“tags”);
metrics_0_tags[“FLOOR”] = “1F”;

JsonObject& metrics_0_data_point = metrics_0.createNestedObject(“data_point”);
metrics_0_data_point[“value”] = temperatureRead();

root.printTo(buffer, sizeof(buffer));
Serial.println(buffer);

int httpResponseCode = http.POST(buffer); //Send the actual POST request

if(httpResponseCode>0){
String response = http.getString(); //Get the response to the request
Serial.println(httpResponseCode); //Print return code
Serial.println(response); //Print request answer
}else{
Serial.print(“Error on sending POST: “);
Serial.println(httpResponseCode);
}
http.end(); //Free resources

}else{
Serial.println(“Error in WiFi connection”);

}
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
delay(500);
digitalWrite(LED_BUILTIN, LOW); // turn the LED on (HIGH is the voltage level)

delay(1000);
}

Moode Audio 4.0正式版公開記念：ビルド方法の超絶粗っぽい説明

昨年はいろいろあってアレだったが、ものづくり趣味はいくつか続いていたりする。最近になって始めたのがラズパイオーディオだ。別にどうということはないのだが、古いラズパイの活用法として始めたものだ。Raspberry Pi 1 Model Bでもちゃんと動くのがうれしい。

ハードは2つ用意した。ラズパイ1＋USBDACアンプ＋スピーカーという構成と、ラズパイZero＋I2S接続DAC＋アンプ＋スピーカー。どちらも「買ったけど使い途ないな～」と思っていたものを再利用できてうれしい。ただ設置場所の関係で、無線LANドングルをそれぞれ追加する必要があった。

ラズパイオーディオ関連のWebサイトを見ていると、ベースOSとしては「Volumio」と「Moode Audio」が双璧のようだが、やや後者のほうが高機能らしい。そこでMoode Audioのサイト（http://moodeaudio.org）に行ってみると、イメージが公開されていない。4.0ベータの途中から、公開ポリシーを変えたらしい。お金取ろうとして批判がきて失敗した、というところか。

そこで4.0版のビルド方法をさらっと。まず適当なラズパイで公式サイトからイメージビルダー「mosbuild.sh」をダウンロードする。ボクはPi-top Ceedを持っているのでこれを使った。こいつを実行すると、最初に聞かれるのが「ブートSDカードを更新するか」だ。これをやってしまうと適当な実行環境がおそらくなくなってしまうのであまりおすすめはしない。ただ考え方次第で、素のstretch-liteをMacやPCでSDカードに焼いておいて、そこにmosbuild.shを入れて実行する手もある。むしろそっちが普通のやり方という気はしないでもない。

スクリプトを続けると、まずUSBデバイスを全部はずせ、はずしたら「y」を入力しろと言われる。言われたとおりにしたら、今度はインストールしたいUSBデバイスを入れたら「y」を入力しろという。どうやらこの状態の差分から、インストールメディアの入ったデバイスを認識しているのだろう。SDカード用のUSBアダプターを使って装着し、さらに処理をすすめる。

こうするとあとは、私の記憶が正しければ

• ネットワーク環境がproxyを使っていないか
• Wi-Fi経由でインストールするか
• （もし前のビルドをしていたなら）残されているイメージを利用するか

くらいを聞かれるだけだ。最後のヤツはstretch-liteをダウンロードするかしないかだけかと思ったら、どうやらMoode Audioの環境自体も残されたヤツを利用したみたいで、一度失敗してしまった。

これらオプションを選択してビルドの続行を指示すると、勝手にstretch-liteをダウンロードしてSDカードに書き込み、インストール用の設定をしてくれる。

しばらく待つとこの作業は完了する。次がOSビルドの本番だ。

作成したSDカードをラズパイに入れて起動すると、スクリプトが自動実行してMoode Audio環境を実装してくれる。時間はそこそこかかるのでノンビリ行こうと言いたいところだが、実は結構失敗した。

まずホスト環境であるラズパイ1で実行したが、どうも何か変なところで止まってしまった。本来は再起動すれば処理を続行してくれるのだが、ログ（/home/mosubuild.log）を見るとどこかわけのわからない途中で止まっていた。

次にラズパイZeroでやってみたが、これも途中で失敗。ログを見るとrc.localのロードに失敗しているっぽい。ラズパイZeroがインストーラーの想定より遅いためだろう。本来は再起動すると、失敗していてもそこからインストールを再開してくれるのだが、それがうまく行かなかったようだ。

なのでラズパイ3でイメージだけは作ってしまうことにした。しかしこいつも途中で止まっていた。

////////////////////////////////////////////////////////////////
//
// COMPONENT 8 – Local UI display
//
////////////////////////////////////////////////////////////////

** Install Local UI packages
E: dpkg was interrupted, you must manually run ‘sudo dpkg –configure -a’ to correct the problem.
** Error: install failed
** Error: image build exited
** Error: reboot to resume the build
** Fri 2 Feb 12:23:02 UTC 2018

ログによるとdpkgの操作が必要、ということだ。ビルドプロセスは再起動すると再開する、とも書いてある。dpkgを指示通り実行してから再起動しようかと思ったが、考えてみれば/etc/rc.localのスクリプトを実行すればいいわけなので、その場で処理を実行。無事インストール作業の続きが完了して、イメージを作成できた。

しかしこれだと作れないというユーザー多いだろうな、というのが正直な印象である。

Bluetooth Developer Studioの利用例

Bluetooth Developer Studio（BDS）でAndroidのプログラムを作ったら超絶簡単だったので記録しておく。

最初にAndroid Clientのプラグインをインストールする。といっても、BDSの「Plugin」フォルダーに、Pluginのサンプル（ここにあったヤツを使ったけど、そもそもBDSのExamplesに入っているヤツでもよさそう）をフォルダーごと放り込んであげればいい。

まずAndroidのプロジェクトを先に作っておこう（後でもいいけど）。ポイントはここでPackage名につける名前。ドメイン名識別という例のアレだが、これをBDSと同じにしておくと何も考えなくてよくて便利。

ということでBDSで新規プロジェクトを作成する。

で、先ほども言ったけどNAMESPACEに同じ名前を入れるのがポイント。今回はAndroidアプリ側なので、UUIDとかはきっとつなぐ相手が存在するはず。その相手のUUIDとかを入れておく。本当はBASE UUIDはあんまり意味ないのかもしれないが、おまじないだと思ってやった。

OKをクリックすると「New Profile」というしごくシンプルな画面が出てくる。何もないとつながりようがないので、「CUSTOM SERVICE」をクリックする。

順番が逆だったかもしれない。ちょっと記憶をたどりながらなのであやふやだけど、いろいろと「へぇここクリックするんだ」みたいなところがある。例えばこの画面で「New Profile」をクリックすると、プロファイルを編集できる。上の画面で「New Profile」をクリックしてもきっといいはず。

で、プロファイルの編集画面が出てくる。BASE UUIDはさっきのものが入っているはず。プロファイル名を編集して、BASE UUIDとNAMESPACEを確認したら「SAVE」をクリックする。

で、次にサービスを定義する。「NEW PROFILE NEW SERVICE」をクリックすると、サービスの編集画面になる。今回はLightBlue Beanにつなぐために作ったので、サービス名は敬意を表して「LightBlue Service」としたが、名前は何でもいいだろう。またここで、該当するBLEデバイスのサービスのUUIDを入力すること。このUUIDはBASE UUIDから勝手に生成してくれるのだが、当然正しいとは限らない（というか、クライアント作成用としては違っている可能性が高い）ので、よく確認すること。なまじ末尾とか合っているので、気づかず進めたこと2回くらいあった。

サービスの定義が済んだら、今度は個別のCharactersiticを定義する。まずは「＋」ボタンをクリック。

名前とかもろもろ編集。まあ最初に名前をScratch1とか（LightBlue Beanの呼び名）、役割とかで適当に。またUUIDも、サーバーによって定義されているだろうから正しく入力する。

同じ画面の下の方に移ると、その属性が定義できる。ここで「READ」とか「WRITE」とかはクライアントから見た時の役割。つまり、AndroidからそのCharactersiticに書き込みたいときは「WRITE」を「MANDATORY」にする。読みだしたいときは「READ」を「MANDATORY」に。OPTIONALにするとコードを生成してくれないからEXCLUDEから変える必要もないのだけど、まあそこは気は心というか。で、値の読み書き設定を加えると、下の「ADD FIELDS」というのが出てくるので、こいつをクリックする。

フィールドを追加したいので、「ADD」をクリックする。

Characteristicを通じてやり取りするデータの型などを入れる。LightBlue Beanだと基本8ビットの配列で定義していたから、そうしておいた。ただこれ、コードで型チェックを生成してくれたりするので、もっと詳細なプロトコルを定めている場合はそれに従ってちゃんと記述するとよいように思う。VALUEも1個じゃないので、複数個を並べてもよさそうだ。まあ今回はこれでやったので。

で、正しくCharacteristicを定義したら、TOOLメニューの「GENERATE」でコードを生成する。最初はServerだけど、Clientのコードも生成できる。

Clientを選んで「ANDROID CLIENT PLUGIN」を選択して、GENERATEをクリックすればコードを生成してくれる。

最後に、生成したコードの中にバッチファイル「copy_to_android_studio.bat」があるので、こいつを実行してアタマで作成したAndroid Studioのプロジェクトに放り込んであげれば完了。とりあえず一通り、Characteristicを通じてBLEデバイスと値をやり取りするアプリが作成できる。

そういえば、そもそも日本語環境だとBluetooth.comのサイトがまともに表示されないという問題があるんだった。ボクは英語版のブラウザー環境を一つ用意しているので、そっちを使ってアクセスしたらあっさり問題が解消したのだった。どうでもいいが、早く直せよ。

マイルストーン：スマホでカメラ台を制御

Project Chasing Moonとか言ってしまったが、そのマイルストーンその1。

スマートフォンのアプリで、指定した角度に首を振り、チルトさせるというもの。コントローラーは例によってLightBlue Beanにした。今回は細かく指定できることを確認するため、専用のアプリも作成した。

基本はBluetooth Low EnergyのCharacteristicに角度（アジマスとチルト）を書き込むと、それに応じてカメラ台のサーボが対象の角度に動く。サーボの制御はArduinoのServoライブラリ任せなので、本当にどの角度なのかは確認していない。が、まあそれらしい角度には動いている。後々のために、LightBlue Beanから加速度センサーの値をCharacteristic経由で取得できるようにもしている。

動かすとこんな感じだ。

ポイントはサーボが5V、LightBlue Beanが3Vで動作するのを整合させることくらい。もしかしたらサーボの制御ピンはCMOSロジックだったのかもしれないけど、SG90の説明はなんにも書いてないのでまあレベル変換は入れておいた。CMOSロジックで動いているといいな。何となく、ちょっと動作が不安定な感じがあるので。本当は波形の確認とかしなきゃいけないんだけど、まあそれも次のステップかな。

もう一つポイントだったのはアプリの方だけど、今回はBluetooth Developer Studio（BDS）を使ったら簡単にできた。基本はLightBlue BeanのCharacteristicをやり取りするサービスのUUIDを使ってBDSでプロジェクトを立ち上げる。これで標準のプラグインを使って、Androidのクライアントコードを生成させる。同じ名前、名前空間でAndroid Studioのプロジェクトを作っておけば、BDSで生成した中に入っているバッチファイルがソースを放り込んでくれる。Javaのソースコードだけではなく、XMLのデザインファイルなども入れてくれるので、実行可能なアプリがその場でできてしまう。

あとはデータをやり取りする構造（プロトコル）を決めて適切に処理させればいい。

 

Metaware Cを使う（その1）

Android版SDKに意外とアンドキュメントなことが多かった。つか、まだできてないから「多い」か。いずれにせよ、後の自分のためにメモ。

• 「Library Setup」のセクション。Android Studioとgraidleの仕組みを知っていればどうってことないんだろうけど、「ivy」リポジトリの指定はRootのbuild.gradleに記述。「compile」の記述は「app」フォルダーのbuild.gradleに記述する。
• Binding the Serviceのサンプルコードに間違いというか、キャストを要求される。これ、ほかのサンプルとかで通っているみたいなんだけど、何か違うのかなぁ。
• 「MetaWareBoard」のセクション。binder.getMetaWareBoardはたぶん間違っている（その場で書いていないので記憶違いかも）。
• なんか「Scanner」というのが使えるみたいだけど、何も書いてない。

というわけで、まだ自前のMetaware Cを見つけてデータを取るところまですらたどり着いていない。先は長い。

プロジェクト「Chasing Moon」始動

などと大袈裟なタイトルを付けてしまった。

何をしたいかというと、要は超絶チープでかつ、楽ちんな自動導入なんてできないか、ということだ。組立式望遠鏡が意外に性能が高く、月などを見る分には十分すぎるくらい使えるのだが、導入が面倒。いや、これはどんな天体望遠鏡でもそうなのだろうけれど、それ自体がファインダーのような存在である組立式望遠鏡の場合、導入は素で見えている星でないと難しい。そもそもターゲット部分は光学系は存在せず、望遠鏡の先端と終端にあるマーカーが対象となる星に重なるように向けなければならない。ちゃんと見えている星ならば狙えるが、「だいたいあのへんにあるはず」で狙ってもなかなか当たらない。そのうち腰か首が疲れてきてあきらめることになる。

しかしボクが住んでいるここ東京は、星を見る環境としてはろくでもないところだ。最近ではこちらの目も悪化しているので、オリオン座のベルトの三ツ星（2等星）ですら、怪しいくらい。一方でこんな環境だからこそ、高額な光学系に投資する意味を持たない。そんな爆発的によく見えるわけはないが、これくらいなら見えるかも、というのは見てみたいのが人情だ。

セレストロンの「COSMOS90」が年末に意外に安売りしていたので、結構ほしいとか思っていたが、どう考えても普通には使うとは思い難い。こいつの売りは自動導入で、明るい星を1つ導入すれば、あとは勝手にやってくれるという。今までは3つ必要だったのだから、かなり楽なはずだ。

そこで少し考えてみた。星の位置に応じた水平方面の角度（方角）と、高度角の2つが求まれば本来は導入できるはずだ。それ自体は、理論上現在地の場所（経緯度）と時刻がわかれば算出できる。問題はそれを現実に設置した望遠鏡の角度に落としこむ部分だ。セレストロンが導入に3つの星を指定していたのは、これから考えればよくわかる。つまり水平方向の角度の誤差と、高度角方向の誤差の2つを算出するために、3つのデータが必要になるからだ。

だがこのIoTの時代である。まず水平方向の回転軸のズレは、加速度センサーを使えば求められる。静止状態で唯一発生している方向が地球中心の方向なので、要は天頂方向の逆だ。次が方位。これも方位センサーがあれば、理論的には北の方向がわかるので、そこから算出すればまあ、なんかちゃんと導入できるんじゃない？

基本的なアイデアとしては、スマートフォン＋制御側の2段構成にする。制御側はArduinoクラスのハードウエアで十分。基本は指定した方向を入れてやったら、それに応じた動作をすればよい。誤差の補正をどちらに持たせるかは議論の余地があるので、まだ決定していない。スマートフォンで基本的に制御するのであれば、時刻や位置も取得できるので都合がよい。惑星の位置情報なども取得できそうだ。

制御側とスマートフォンはまあ、Bluetooth LEで接続するだろう。というわけで、制御側のハードウエアはとりあえず手持ちの「Metaware C」（mbientLab製）を使うことに決定。制御用のサーボは手持ちのSG90でまずはいろいろ試そう。とにかく安いし。あれ？でも出力系統足りるかな？そこは少しチェックしておこう。これがRaspberry Piクラスのハードなら、それ自体に通信機能とUIを持たせてもよいのだろうけれど、そこを作るのはソフト的にも面倒な感じがする。

なので、まずはフェーズ1としてスマートフォンで角度を指定して制御できるようにすることを目指す。次にフェーズ2として、設置誤差の修正をできるようにする。フェーズ3がちゃんとしたUIだ。できるならば星の名前を指定しただけで導入できるようにしたい。

いろいろと構造を考えてみたが、どうせサーボはSG90を少なくとも試験段階では使うので、カメラキットをeBayで買ったりした。

PowerShellを初期設定に使ってみた

某雑誌のセミナーでハンズオンをやるので、ときどき大量のパソコンの初期設定をしなければならなくなる。PowerShellのスクリプトは、クライアントWindowsだと実行ポリシーで制限がかかっているので、まあムリだろうとあきらめていた。

しかしWindows 8.1にしたら、今まで使っていたVBSのスクリプトがまともに動かない。しかたがないので慌てて代替手段を探した。条件としては、（1）管理者権限で動作する（いろいろと管理者での操作が必要なのだ）、（2）コンソールによる対話処理は極力なくす（手間軽減と誤り軽減のため）、（3）PowerShellの実行制限はいじらない（正確に言えば実行後元に戻ればOK）。

某雑誌の連載の樋口さんに書いていただいた記事で、PowerShellスクリプトのファイルを右クリックして「PowerShellで実行」とすると、Windowsの実行制限に引っかからないで実行できるというのを教えてもらっていた。これが管理者権限で実行できればいいわけなので、まずはPowerShellで実行権限をエスカレーションする方法を探した。そこで見つけたのが、牟田口さんのブログで「スクリプトを管理者権限で実行する」。これで管理者権限が必要なスクリプトが素直に動いてくれたら、もはやそれで完了だったのだが、残念ながらなかで管理者にエスカレーションしたところでスクリプトを実行しようとして、結局実行制限に引っかかる。

さてどうしよう、と探していたら、ここにバッチで実行ポリシーを変更するという記述を見つけた。よく読んでみると、ふむ。なんだ。PowerShellで1行実行しているだけじゃん。

ということでこういうバッチを作って、バッチを右クリックして「管理者権限で実行」すればいいということがわかった。「setuppc1.ps1」がメインの設定スクリプト。

powershell.exe -Command "Set-ExecutionPolicy Remotesigned -Scope LocalMachine -Confirm"
powershell -File %~dp0setuppc1.ps1
powershell.exe -Command "Set-ExecutionPolicy Restricted -Scope LocalMachine -Confirm"

USBメモリーで指してそこでバッチを実行させるので、実行フォルダーを取得するため「%~dp0」を付けているくらいで、あまり特殊なことはしていない。と思って改めて探したらここにちゃんとした説明があったのだった。

VBSとPowerShellだと、スクリプトの開発効率は結構違う。試しに実行しても、VBSだと結構手探りでデバッグしなきゃならない。PowerShellならISE使えるので全然楽。これで管理者権限の必要なスクリプトをISE使ってデバッグできるようになったので、今後楽になるなぁと期待している。

 

FreeSoC2とかいう開発キットでLチカまでの道

ETでCypress Semiconductorが配っていたSparkFunのPSoC5LP開発ボード。日本語の情報はあんまりないみたいだし、意外と動かすまでに手間だったのでメモ。まあぶっちゃけSparkFunが公開している文書を読めばわかるっちゃわかる。英語だけど結構丁寧に書いてあるし。

Arduino IDEの準備をする

まずArduino IDEが1.6.4以降が必要。とりあえず今ダウンロードすると、1.6.6になる模様。ウチのMac/PCには1.0.6までしか入れてなかったので、入れ替える必要があった。

それからハードウエア情報の追加。ARMプロセッサー対応を取り込む必要がある。まずArduino IDEのコンパイラーでCortex-M3のコードを生成できるようにする。これは比較的簡単で、「ツール」メニューの「ボード」項目を選ぶとリスとされるボードの中にある、「ボードマネージャー」を選ぶ。そうすると、使うボードのグループみたいなものだなこれは。Cortex-M0のコンパイラーとかボードとかもここで追加できる。本来はこのリストの中に「FreeSoC2」というのがはいるべきだし、そうしたいみたいだが、まだそこまではできていないという状況だ。

次に、githubのリポジトリから、PSoCのサポートファイルをダウンロードする。zipファイルなのでこれを展開して、そのなかにある「Hardware」フォルダーをArduino IDEの「スケッチブックの保存場所」にコピーする。Hardwareフォルダーがすでにある場合は、中身を追加すればよい。これでようやく、ボードとしてSparkFunの「PSoC Dev Board」が選択できるようになる。

Arduinoのブートローダーを書き換える

さて、ここからが問題だ。ここで試しにUSBケーブルを「Target」に指してみても、シリアルポートドライバーが認識してくれない。「USBUART」という謎のデバイスがつながっていることになっている。

まあまずは、こいつをダウンロードしておく。Windowsのドライバーとか入っているくさいのでインストール。しかしCypress PSoC Programmerをインストールしてもとりあえずドライバーは認識しない。ドキュメント通りに「Debugger」ポートにつないでみるが、こちらもいろいろと謎のデバイス状態になっている。

これはとりあえずドライバーをインストールしてしまおう。C:\Program Files (x86)\Cypress\Programmer\driversフォルダーにインストール用のバッチファイルがあるので、これを実行してみる。これでDebuggerポートに接続した状態では謎デバイスがなくなったが、相変わらず「Target」は認識しない。

たぶんここが問題で、Arduino用のBootloaderを書き換えてやらなければいけないのだろう（と、この時点では思っていた。実際は違うことが後から判明した）。

ドキュメントに従い、ここで「PSoC Programmer」を起動する。あれ？認識してない。起動する前に接続していたせいかもしれないので、一度USBケーブルを抜いてから挿し直す。これで認識した。

これで「File」－「Open」でPSoCのサポートファイルにある「D:\Documents\Arduino\Hardware\SparkFun\psoc\bootloader.hex」を開く。ファイルを開くアイコンの隣にある「Program」ボタンをクリックすると、ブートローダーが書き込まれる。

これで認識するかと思いきや、「ドライバーはD:\Documents\Arduino\Hardware\SparkFun\psocにある」ときたもんだ。なので、このブートローダー更新作業をしなくてもホントは認識して作業できんじゃね？みたいなことは試していない。

さてドライバーをインストールしてめでたしめでたし…かと思いきや、落とし穴が待っていた。Arduino IDEが「コンパイルエラー」となる。

arm-none-eabi-gcc: error: C:\Temp\build9c9ef3bdfe2fccb480bc6e4bac749e41.tmp/core.a: No such file or directory

確認すると、確かにそこに「core.a」ファイルはない。テンポラリフォルダーの「core」フォルダーの下になら存在する。しかたがないので、ハードウエア情報の定義ファイルというか、platform.txtを書き換えた。D:\Documents\Arduino\Hardware\SparkFun\psoc\platform.txtを開いて「core」を検索すると、1カ所見つかる。その「core.a」を「core/core.a」と書き換えたら、無事コンパイルできて、スケッチもアップロードできた。これは定義ファイルだからとりあえず処置としては正しいのだけど、なんかそのうち引っかかるかもしれないので、備忘録としても公開しておこう。