Electroharmonix フォントが何故、日本人に読めないのかを Tesseract-OCR で紐解く

日本人にだけ読めないという Electroharmonix というフォントが話題なので、どうして読めないのか?というのを OCR を使って解説します…と言いますか、理由は日本はカタカナを知っているけど、欧米人はカタカナが解らないから字形を見てアルファベットにしか見えない(という似た感じの文字を探す)というだけなんですけど、そのあたりを OCR を使って動作確認をしてみようという話。

日本人にだけ読めないフォント「Electroharmonix」が面白いと話題に! | netgeek
http://netgeek.biz/archives/53486

font_confuse (1)

ちなみに、Electroharmonix フォントは 1985年にできたのでフォント的には古いものです。なので、あちこちのゲームやポスターに使ってあるみたいです。

Tesseract-OCR

OpenCV 3.0 に入りましたが、もともとは Google Code にあります。tesseract-ocr – An OCR Engine that was developed at HP Labs between 1985 and 1995… and now at Google. – Google Project Hosting 1995年という結構古いものですが、アルファベットと数字だけなど字形を限って使えば認識率は高くなります。ざっと確認すると、Microsoft OCR よりも認識率が高かったので、なんだろうな、という感じなんですが。

最新のコードは Github に移っています。tesseract-ocr

Tesseract-OCR の学習データを作る

Tesseract-OCRの学習 – はだしの元さん
http://hadashi-gensan.hatenablog.com/entry/2014/01/15/135316

を参考にすると、OCR に学習データが作れます。結構手順がややこしいので後できちんとまとめますが、英語版(eng)と日本語版(jpn)の2つを作りました。

英語版の文字セットは、アルファベットと数字のみで構成

image

日本語版の文字セットは、アルファベットに加えて、カタカナを入れます。

image

image

これをもとに学習データを作成して、

  • アルファベットしか理解しない 英語 OCR
  • アルファベットとカタカナを理解する日本語OCR

ができます。

そこで、例の Electroharmonix フォントで作った文字を与えてやって、どのように認識するのか?を調べればよいわけです。

image

アルファベットを OCR 認識させる

最初に「MASUDA TOMOAKI」のアルファベットを認識させてみます。

image

認識対象のフォントが Broadway のため、若干ずれていますが、まあまあアルファベットとして認識されてますよね。

image

同じものを日本語OCRで認識させると、「A」の箇所が「ム」に誤認されています。英語OCRは「ム」という文字を知らないので、そのままアルファベットに割り当てますが、日本語OCRの場合はカタカナを知っているので「A」に似た「ム」の文字に割り当てます。

例のフォントを OCR 認識させる

今度は Electroharmonix フォントを使った認識させてみます。

image

思ったほど、正確には認識できていませんがw、まあ、無理矢理アルファベットと数字に割り当てて読み解こうとしています。文字数が異なるのは、隣あう文字をひとつの文字にしたり、逆にふたつの文字として誤認しているからです。このあたりは学習データのバリエーションを増やすとか、フォントの間を開けるとかで避けられる問題です。

まあ、なんとなく英語圏の人はこんな感じで認識しているんじゃないかな、という想像ができますね。

今度はカタカナを知っている日本語OCRで試してみましょう。

image

やたらに四角がありますが、「ロ」(ろ)です。Oの部分がロに見えているという訳です。先の英語OCRがアルファベットに割り当てているのと違って、日本語OCRは主にカタカナに割り当てていますよね。もともと、Electroharmonix フォントがカタカナを意識しているので、そちらに引っ張られて、日本人の場合はもともとの読み方ができないわけです。

単純なカタカナならば?

逆にカタカナだけだったどうだろうか?というと、

 

image

英語圏の人には、数字とアルファベットの組み合わせにしか読めないけど、

image

カタカナを知っている日本人には、普通に読めますね、という具合です。

結論…ってほどではないけど

そんな訳で、Tesseract-OCR を使って、日本人だけが読めない理由(実験的にはアルファベット圏の人にも読めませんがw)が実証できたと思います。

具体的なコードは後からまとめましょう。

このあたりを応用して、k近傍法の IkaLog も試してみたいと思う…のですが、スプラトゥーンは持ってないし、Wii U は持ってないし…というわけで、Youtube あたりの動画か認識させればよいかと思案中。

カテゴリー: 開発 | Electroharmonix フォントが何故、日本人に読めないのかを Tesseract-OCR で紐解く はコメントを受け付けていません

割り箸でロボットアームを作ってみる(中編)

既に支柱を LEGO で作ってるので割り箸ではないのですが、タイトルはそのままで。

 

8個のサーボを使って、同時に動かそうと思ったのだけど、実に面倒くさい。デモっぽく動かしたり、最終的には画像認識を使ったりするのだが、その途中で挫折しそうになる…ので、もうちょっと手軽方法を考えていました。

確か、人形を使って三次元映像を作る製品があったはずで、同じようなことはロボットアームでもできるでしょう、ってことです。7Bot: a $350 Robotic Arm that can See, Think and Learn! by 7Bot — Kickstarter の映像で出て来る、手でロボットアームを動かしてやって、それと同じ動きを実現するというものですね。安川電機の居合切りの映像も似たようなことをやっているはずです。

image

要は、ポテンショメーター( potentiometer 回転式の可変抵抗器)をぐるぐる回したときにアナログ値を取ってきて、それをパルスに直してサーボに送ればよい。この場合は、ポテンショメーターとサーボが別々になっているけど、同じ構造のロボットアームを2台用意してやって、片方はモーション入力専用、片方は出力専用にすればok。そもそも、高いサーボだと角度を取得できる(内部的にはポテンショメーターで角度を判断しているので、それを取り出す機能が入っていればよい)ので、同じアームを使っても動作ができる、ってわけですね。

でもって、私の場合は安価なサーボを使っているので、ここの入力と出力は分けないといけない。そのあたりは、別々のものを使ってコントロールすることの具合の良さが実現できればよいかな。

image

可変抵抗からの値は、analogRead で取れるので、それを 180 度に直してやればよい。似たようなことはモーター制御でもできるので、自作のラジコンコントローラを作るのにいいかもしれない。スマートフォンのほうが手軽だけど、専用コントローラー/インターフェースのほうが使い勝手は良さそう。

カテゴリー: Arduino, ロボットアーム | 割り箸でロボットアームを作ってみる(中編) はコメントを受け付けていません

割り箸でロボットアームを作ってみる(前編)

mDrawBot のロボットアームで iPad をすりすりしてみたら結構うまくいったので、唐突にロボットアームを自作したくなって作ってみる。Kickstarter にもロボットアームがあって、それなりの値段(5万円位)で買えるようになったのが(以前は10万円以上したので)、そこはもうちょっと勉強も兼ねて構成を考えてみよう。

3D 関係のソフトウェアが苦手なので、LEGO を使って試作する。この日の午前中に、歯車を使ってギアボックスを作ったりピストンを使って練習した後で、これを作ってみている。関節部分を2軸にするという非常に冗長な構成なんだが、こうするとアーム自体がぐにゃぐにゃと自由に動く。構成が簡単になるので初手としてはこれで十分。

自由度が高ければいいというものではないだろうが、手元にある10個ぐらいのマイクロサーボを全部使ってもいいかなという贅沢な構成にしてみる。富豪的プログラミングと同じですね。

昼にこれを作った後で、どうやって実現しようと思って午後いっぱい悩んでいたのだが、ふとどうせならば割り箸でいいじゃないか、夜中に思い立って作ってみたのがこれ。

割り箸を適当に切って、手芸用のマスキングテープでサーボを止めてしまう。強度的には心もとないけど、アイデアを現実にするための試作としてはこれで十分なはず。…が、ちょっと動かしてみると、やっぱり強度が足りないので不安が出てきて、この支柱の部分をレゴで置き換えてみた。

LEGO マインドストームの支柱を使うと軽いので、マイクロサーボでも十分に支えられる。最終的にはアルミフレームを考えるんだろうけど、これまた、途中の段階では試行錯誤するために LEGO が有効だ。まあ、LEGO とはいえサーボの接続部分はマスキングテープで止めてあるので LEGO っぽい使い方は全くしていない。

そして、1本の支柱では強度的に足りないので、2本以上の支柱を考えたのがこれ。

https://pbs.twimg.com/media/CRNT5N3UwAA4E3s.jpg

これだとギアを支柱で挟む形になるので強度が保てる。が、それをどうやって実際のサーボにつなげるかよく分からずにいたのがこの状態。ひとまず、マスキングテープで形だけ作ってみる。

https://pbs.twimg.com/media/CRNT5N5UsAAyPa4.jpg

さらにバリエーションとして1本支柱でサーボの接続の向きを変えてみる。台座はカメラ撮影でつかうものを流用している。台座自体は2点支持なのでしっかりしているが、腕の部分は1点支持のためゆらゆら揺れてしまう。

じゃあ、台座のように二点支持にすればよいだろう。その場合、アルミフレームをまげて作るのが定番だろうと再び悩んだのだが、この段階でその工作は避けたい。トライ&エラーのサイクルがのろくなってしまうからね。で、何とかならないだろうかと思って作ったのがこれ。

普通はサーボの脇の部分にU字型のフレームを置いて二点で支持することになるのだが、直接サーボのお尻の部分にねじを埋め込んでしまった。安価なサーボなのでこれで十分だし、試作なのでこのほうが取り外しが利いてよい。サーボの回るところにも二本のビスをつけて LEGO の支柱を支えられるようにしてある。

2つのサーボを2本の支柱でつなげるので強度が増している。ただし、サーボから直接動力を得るスタイルなので関節部分が大きくなってしまうが、まあ、これはこれで良しとする。

https://pbs.twimg.com/media/CRQ3_0lVAAAngoL.jpg

肩が台座に相当して、肘に当たる部分が2つある。冗長ではあるけど、これだと動きがスムースになりそうなのでこれで試作していく予定。肩に近い1つめの肘の負担が大きい(左の2つ目の肘と手を支えることになる)ので、ここの関節は梁を使って台座のほうから引っ張るようにしないとダメかなと思っている。

ひとまずは Arduino Uno で適当に動かしてみよう…という訳で続く。

カテゴリー: Arduino, ロボットアーム | 割り箸でロボットアームを作ってみる(前編) はコメントを受け付けていません

TiddlyBot を組み立てる

mDrawBot に引き続き、TiddlyBot も組み立ててしまいます。TiddlyBot は Kickstarter で買ったもので、約1年遅れで出荷されてきたものです。途中に Raspberry Pi  が新しくなってしまったり、資金が足りなくなったり、ソフトウェア制作に苦心していたりして、遅れていたわけですが無事届きました。

おととしの夏に自分で Raspberry Pi で自走ロボットを作ろうと思ったときに、ちょうど参考になるので買ったんですよね。今だと、ほどほどにはモータードライバの使い方も分かったし、無線のやり方もわかった、Windows IoT Core を使うこともできるようになったので、それほど必要ではないのですが、でも「何よりも真似から始める」ことで学習はスタートするものですから、真似られるところは真似ていきます。

見栄え的には mBot よりも見劣りがしますが、Raspberry Pi Model A を使っていて、モータードライブのハット&充電池を使っているところがミソです。久々に Rasbian を扱います。あと、Raspberry Pi なのでカメラと WiFi の扱いが楽になります。TiddlyBot の制御も WiFi 経由で行う(内部的は Apache 待ち受けで Python 動作かも)ので、ブラウザやスマートフォンから操作ができます。

WiFi はホスティング機能で動いています。どうやって、無線LAN に参加させようかと思ってあれこれ見ていのですが違いました。起動時に内部で 192.168.42.1 固定でホスティングを行い、SSIDのパスワードは Raspberry になっています。ホストに接続したら SSH で接続できるので、raspi-config 等で設定ができます。Rasbian が入っている micro SD カードは同梱されていて、起動時の設定もされた状態になっています。カメラ機能もすでに有効な状態です。

カメラのエラーに対応する

が、カメラを使おうと思うと、なぜか表示ができない。Tera Term で接続して raspistill -o test.jpg してもエラーを出しています。raspistill は、カメラで写真を撮って JPEG に落とすコマンドです。おかしいなぁ、と思っていろいろ調べれみると、

BABUKUMA (^(工)^): Raspberry Piで専用のカメラを試してみてる時にエラーが。。
http://blog.babukuma.com/2014/02/raspberry-pi.html

な感じで SUNNY っていうラベルの部分が外れていることが分かりました。ソケット形式になっているので、小さなカチッと音がするまではめ込んでやります。そうすると、うまくつながるります。

で、テスト用にもう一度 raspistill -o test.jpg を動かしてみたのですが、やっぱりエラーがでます。先のエラーとは違うエラーなので見ていたのですが、これは TiddlyBot のデーモンプロセスのほうでカメラ機能を使っているからです。なので、TiddlyBot のブラウザで見るときちんと画像が撮れいていることが解ります。

Scratch 風のプログラム

TiddlyBot は2つの動かし方があります。あらかじめ Scratch 風のプログラムで動作を決めてやって動かす方法と、ブラウザや(たぶんスマートフォン)で直接操作してやる方法です。

ブラウザ上で Scratch 風なプログラムが作れます。Scratch で良かったのでは?と思うのですが、どうもこの部分に手間が掛かりすぎたのではと想像しています。ぽちぽちとブロックをつなげて作ることができます。mBot のパンダ Scratch は Arduino の C に直してファームにアップロードしますが、TiddlyBot Scratch は Python に変換して送信しています。面倒な場合は、Python で直接書くことができます。

ラインセンサーとか超音波距離センサーを利用して自動制御ができるという仕組みです。

直接操作する

いわゆるリモコン的な操作もできます。TiddlyBot にブラウザで接続して、モーターを前後に動かしたり、カメラのサーボを動かしたりします。カメラで撮影した映像は随時画像ファイルで送らてきているようです。

たぶん、内部的に Python で送っているだろうから、似たようなプログラムを自前で書くこともできますよね。たぶん、コードを Python に貶すればよいだけなので F# や C# でクライアントを書いて送信することも可能なはずです。ストアアプリにしてタブレットからも送信でいるんじゃないでしょうか。

実は、Raspberry Pi のカメラモジュールは高かったので手を出さなかったんですよね。買うと 3,500円ぐらいして、RasPi 自体と同じ値段になってしまうので躊躇していました。が、これだけ小さくて、さっくりと動くのだったら USB カメラと同じように考えてもいいかなと思い始めています。そうそう、Orange Pi PC 専用のカメラもあって、そちらのほうは 1,000円ぐらいなのでちょっと手を出してみてもよいかなと。

カテゴリー: RaspberryPi, TiddlyBot | TiddlyBot を組み立てる はコメントを受け付けていません

mDrawBot と mBot を組み立てる

Makeblockのお絵描きロボット「mDrawBot」が日本に上陸! | クラウドファンディング - Makuake(マクアケ)
https://www.makuake.com/project/mdrawbot/

で、支援した mDrawBot が届いたので組み立ててみました。サポータは180名ほどいるので、ぼちぼちとアップされるでしょう…とか思ってたら、誰もアップしないのでさっくりと紹介しておきます。

ちなみに、私の場合は Makuake で買ったものですが、本家 からも買えます。$230 程度なので 3,000円ぐらい高い感じですね。Makeblock のシリーズは LEGO のようにパーツを別々に変えます。基本のパーツを買って、それを増やすパターンで少しずつ増やしていくということが可能です。パーツ自体は、金属(アルミ?)なのでねじ止めでしっかりと作ることができます。塗装は剥げやすい感じなので注意が必要(ドライバーとかで擦ると落ちそう)なのですが、まあ、遊びの範疇だし、それはそれで ok です。

ざっと組み立てるとこんな感じです。ねじ止めをしながらやるので、2時間弱ぐらいかかりました。なぜか、上に乗っかるパーツのねじ位置がずれていて(設計ミス?)はまらないのですが、特にはずれることもないのでそのままです。駆動系は、ステッピングモーターが2つと、サーボモーターが1つになります。どちらも既存のもので、ねじ穴さえ合えばきっちりと固定ができます。このあたりは、LEGO Mindstorms で部品を揃えるよりも安く手に入りそうです。秋月の ステッピングモーターST-42BYG0506H と同型のような気がします。

絵を描かせるアプリがあって、SVG や BMPを書かせることができます。こんな風に、付属のアプリをダウンロードして、SVG 画像を読み込ませて描きます。SVG の Path を読み取っているので、Inkscape などを使って自前で作ることもできます。

image

mDrawBot 自体の頭は Arduino なので、プログラムを組んで2個のサーボを動かすこともできますよね。そうすると、水平移動のアームとしても使えるわけで、水性ペンの部分をタブレット用のすたライスに変えると iPad に書くこともできるかなと。無理矢理ですが、こんな感じ。

ペン先の上げ下げはサーボモーターで制御するので、うまくやればタップとかスワイプができるはずです。マルチタップとピンチや二本指が必要なので、もうひとつアームを作るか指先を作るか考えていきます。まあ、そんな妙なことをしなくても、mDrawBot が絵を描いているのを見るのは結構楽しいですよ。もうちょっと本格的に絵をかかせようと思ったら、XY-Plotter Robot Kit | Makeblock のほうがいいのですが、これはこれで 3万円以上かかりそうなのでお財布と検討が必要です。あと場所を取りそうだし。
XY プロッターのほうは、ABU ロボコンのロボミントンで使われていた機構と同じです。ラケットを XY の平行軸を高速移動させるには、このプロッタ方式が有効です。あと、基板実装のチップマウンターも同じ方式ですよね。

私としては、このアーム部分に Web カメラを取り付けて物体認識に使う予定です。吸引モータが届いたら実験していこうかなと。

実は mDrawBot の前に mBot も購入しています。こっちのほうはもっと安くて、Kicksterter で $49 でした。本家のほうでは $75 ですね。この mBot のほうは、Scratch 2.0 を使って制御ができます。赤外線のコントローラのボタンを押すと、モーターや LED を動作させることができます。ボード自体に IR 発信/受光 がついて、スピーカーもついます。モータードライバーも載っているので、実は結構お手軽に使える便利ボードだったりします。

Bluetooth の拡張チップも一緒に購入したので BLE で接続ができるので、適当な iPhone アプリを作れば mBot を動かすことができます。

というわけで、足回りが結構揃ってきたので本格的に作品制作に入ろうかというところ。頭(RasPi/Arduino)、通信(Bluetooth/IR/WiFi)、駆動系(ブラシモーター/ステッピングモーター/サーボモーター)、構造系(mBot/タミヤ/LEGO)を組み合わせていきます。あと、Webカメラ、9軸センサーの類も。

カテゴリー: Arduino, mBot | 1件のコメント

Comm Tech Festival で Windows IoT Core の発表

09/26 の Comm Tech Festival で Windows 10 IoT Core の話をしてきたので、その補足をつらつらと書いておきます。

発表スライドは、こちらから。

何を話したかというと、Windows 10 IoT Core を Raspberry Pi に乗せて、Tamiya の Boxing Fighter を動かすというデモです。前半を Windows 10 IoT の概要(かつ、裏事情など諸々)と、後半が Boxing Fighter を動かすデモになっています。発表でも強調しましたが、Boxing Fighter も戦車も、2個のブラシモーター&ギアボックスという組み合わせなので、動作させる部分は切り替え可能です。戦車の場合は本格的に動かそうと思うと、キャタピラで動いてしまうので戦車自体に Raspberry Pi と電源を積まないといけない制限が出てきてしまいますが、Boxing Fighter の場合は、あまりあちこち動かないので線が出てても結構見栄えがします。どっか行っちゃうことがないので、モーターを動かす学習とかにちょうどいいのです。

埋め込み画像への固定リンク

デモのコード

デモで使ったコードは、github の RPiBoxing からダウンロードできます。MS 品川の会場では Wi-Fi がうまくつながらない可能性があったので、

  • 通常のマウス操作のデモ
  • SenserTag を使って Bluetooth 経由で操作するデモ
  • Windows IoT 側に簡易 HTTP サーバーを起動させて、ブラウザから操作するデモ

になっています。3つ目の HTTP サーバーを起動させるパターンは、クライアント側を iPhone などで作ることも可能です。実際、iPhone 用に Swift で作って持って行ったのですが、Wi-Fiが繋がらないので断念。簡易サーバーへは Web API を利用した GET コマンドを送信するパターンで作って理ます。

以下、ちょっとコードの補足をしておきます。

モータークラスを作る

モーターを正逆で動かすためには、GPIO を2本用いる必要があります。モーターを動かすたびに2本の GPIO を制御してもよいのですが、適当な Motor クラスを作っておきます。

public class Motor
{
    GpioPin out1 { get; set; }
    GpioPin out2 { get; set; }
    public Motor(int pin1, int pin2)
    {
        this.out1 = RPi.gpio.OpenPin(pin1);
        this.out2 = RPi.gpio.OpenPin(pin2);
        this.out1.Write(GpioPinValue.Low);
        this.out2.Write(GpioPinValue.Low);
        this.out1.SetDriveMode(GpioPinDriveMode.Output);
        this.out2.SetDriveMode(GpioPinDriveMode.Output);
        _dir = 0;
    }
    int _dir = 0;
    /// <summary>
    /// 回転方向を変える
    /// </summary>
    public int Direction
    {
        get { return _dir; }
        set
        {
            if (_dir != value)
            {
                _dir = value;
                if (_dir == 0)
                {
                    this.out1.Write(GpioPinValue.Low);
                    this.out2.Write(GpioPinValue.Low);
                }
                else if (_dir > 0)
                {
                    this.out1.Write(GpioPinValue.High);
                    this.out2.Write(GpioPinValue.Low);
                }
                else
                {
                    this.out1.Write(GpioPinValue.Low);
                    this.out2.Write(GpioPinValue.High);
                }
            }
        }
    }
}

 

BLE を利用する

リモート制御をするときには、Bluetooth か Wi-Fi を使うとよいのですが、Bluetooth の場合は、ちょっと手順がややこしくなっています。もっと手軽に使えるクラスにすればいいんですけどね。BluetoothGATT から該当箇所を抜き出して使っています。iOS や Android の場合は、特定の BLE デバイスを使うときにはそれを利用するライブラリもワンセットになることが多いので、それを使えばいいのですが、Windows IoT の場合は当然のことながら提供されないので自前で作ることになります。

サンプルコードでは、画面でボタンを押して BLE デバイスを探すことになっていますが、アプリの起動時に自動的に探しに行って接続してもよいですね。

BLE を使うときにはコツがあって、

  • Package.appxmanifest に <DeviceCapability Name=”bluetooth.genericAttributeProfile” /> を追加する。
  • あらかじめ、該当する BLE デバイスをペアリングしておく。
  • BLE のイベントから UI を扱うときは、Dispatcher.RunAsync を使ってスレッドを変える必要がある。

ということになります。実は、3つめの UI スレッドのところが曲者で、確かに BLE などのイベントから UI スレッドにアクセスする(画面表示をさせる)ときには Dispatcher.RunAsync を使ってスレッドを切り替えることは忘れないのですが、MVVM を使って INotifyPropertyChanged で UI アクセスをするときにも Dispatcher.RunAsync  が必要です。

具体的には以下のように、ViewModel を媒介するときにも Dispatcher を効かせないといけないってことです。ふつうのストアアプリを使っているときは分からない落とし穴ですが、デバイス系は UI スレッドではないので、見えないところでアクセスすると落ちるってことになります。まあ、これはストアアプリで作ったときにもスレッドで動かすときには注意するわけですが。

await Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, () =>
{
    if ((data & 0x01) == 0x01)
    {
        _model.BLETap = &quot;Right F&quot;;
        KeyRFront.Background = new SolidColorBrush(Colors.Green);
        motorRight.Direction = 1;
    }
    else
    {
        _model.BLETap = &quot;&quot;;
        KeyRFront.Background = new SolidColorBrush(Colors.Red);
        motorRight.Direction = 0;
    }
    if ((data & 0x02) == 0x02)
    {
        _model.BLETap = &quot;Left F&quot;;
        KeyLFront.Background = new SolidColorBrush(Colors.Green);
        motorLeft.Direction = 1;
    }
    else
    {
        _model.BLETap = &quot;&quot;;
        KeyLFront.Background = new SolidColorBrush(Colors.Red);
        motorLeft.Direction = 0;
    }
});

 

簡易 HTTP サーバーを作る

System.Net.HttpListener がないので、StreamSocketListener を使って自作をします。サンプルとしては、Blinky WebServer を参考にすればよいでしょう。私のデモコードもここから引っ張ってきています。単純な Web API を作りたいときに、こうやっていちいち簡易サーバーのコードを作らないといけないのは面倒なのでライブラリしたいところですね。本来ならば標準で用意してほしいところなのですが、AllJoyn 関係とダブってしまうのか割愛されています。

ただし、ここをクリアすると、ブラウザから制御ができるようになるので是非おさえておきたいところです。ブラウザだけでなくスマートフォンを使っての呼び出しも楽になります。

そんな訳で、このあたりは少しまとめて、近々 hacker.io にアップする予定です。

カテゴリー: RaspberryPi, Win IoT | Comm Tech Festival で Windows IoT Core の発表 はコメントを受け付けていません

永青文庫 春画展に行く

と、闇嶽さん と、永青文庫 春画展に行ってきました。まあ、春画展がおまけで闇嶽さんとくだ巻くというのが目的だった訳ですが、宮武外骨 FAN としては春画は外せないし、芸術的な版画という見方と、当時の風俗(世間という意味で)の春画があるので一見しておくのが良いでしょう。知らなかったのですが、テレビで宣伝されていたらしく連休中は混み混みでまともに見られませんでした。有名な「蛸と美女」の現物があるのと、布に書いた一品もの、版画、豆版(戦時中に兵員が持って行った春画)と揃えて会って、小さなイベント会場ではありますが歴史的にも見ておくとよいでしょう。ちなみに、うちの奥さんは国文科で黄表紙で、この手の風俗画のくずし字のところを読んで研究をしておりました。黄表紙に書いてある文章を読むと当時の風俗(一般生活という意味で)がよくわかるので、必須な科目なんですね。版画のほうのくずし字は読みやすいそうなので1年も経たずに読めるようになるそうです。

弾圧されてから華開く

一般に春画といえば、現在でいうエロ本/エロビデオの類が対象にされますが(まあ、実際にそうなわけだし)、春画の変遷を見ていくと単純に性欲を満たすために行った発展ではありません。まあ、版画の12刷の技術は他に解説を譲るとして、本来の発祥を考えてみましょう。ちょうど、今回の春画のそれの構成になっています。

初期のころ、春画自体は自由に描かれていました。版刷で大量にばらまくのではなく、貴重な本として公家あたりの上流階級で使われていたものです。絵なり本なりは希少品ですからね。このあたりの時期には布に手色彩で描いてあるので、きれいではあるのですが一品ものですし、精細を欠いています。芸術品といえば芸術品だし、競合がいないといえばいないという状態ですね。これ4階の展示になります。

享保の改革があって、春画が弾圧されたのは、きれいな政治だったのか整然とした政治改革だったのかはわかりませんが、一方で公家なり武家階級を猥雑に描いた春画がそれを理由に発禁になったのではないかと私は考えています(なんかそういう話もあったような気がする)。絵を描く側からいえば、ちょうどいい侮蔑/反骨の仕方でもあったし、体制側からいえばそういうのを許しておく余裕はなかった時代ではなかったかと思われます。そういう訳で、一見おおぴらに開かれていた春画が、一遍して地下に潜るわけです。

で、地下に潜った場合にはアメリカの禁酒法時代と同じで、手に入らないからこそ高値で取引されます。高値だからこそこぞって絵師が手をつけるし、こぞって手をつけるからより手の込んだものが生まれるわけですね。西洋ジャポニズムの評価を待つまでもなく、ふつうの版画とは桁違いに手を尽くした版画が作られます。これが3階の展示ですね。

たくさんの絵師がかかわれば、単純なな春画では売れなくなってしまいます。何か趣向を凝らせないといけないわけで、そは閻魔大王の春画であったり、屋形船の春画であったり、ピーピングトム(のぞき見の小さなおじさん)の趣向であったり、蛸と美女であったり、するわけです。一方で同時期に妖怪画もあるわけで、カンブリア紀的に組み合わせが爆発するのがこの時期です。

そうこうしてるうちに、春画を描いている絵師は年老いてばたばたと死んでいく。幕末の戦乱に向かっていく、西洋に対抗するために清い日本を演出するため春画を無視していくという時代に突入します。絵師/彫師/擦師の家内手工業的な匠の技が失われたころに生まれたのが、2階展示にある豆版ですよね。戦地にもっていくお守り(かつ気晴らし)として小さな春画を持っていきます。水木しげる著の漫画にも出てきたような気もするのですが、まあそういうものが流行ったわけです。このあたり慰安所も同じかと。

そのあとに、現在のエロ漫画/エロ映像が続くのかどうかは分かりませんが、皆さまが知っている蛸と美女の絵を伝承する日本のエロ漫画業界においては、そういう精神も低音ではあるのかなと、期待したり期待しなかったりする訳です。

外骨と春画

宮武外骨が様々な新聞を発表していった背景には、彼の嗜好も多いに含まれていたと思いますが、多くはその批判精神が言動力です。官吏に盾ついたり、権力志向を揶揄したする中でミニコミ誌的な自費出版を続けています。単につむじまがりだったのかもしれませんし、なんらかの反骨精神があったのかもしれません。ただ、こういう人が歴史的にいるという事実自体が「社会の縁」にいるひとにとっては非常な安らぎになるんですよね。赤瀬川原平、南伸坊という系列で現在に至ります。

こういう変わったところを許容する社会が重要であって、なにかきな臭いときにはこの手の「許容」がなくなってきます。社会の縁を排除して、中央値に寄ろうという圧力がかかってくるわけです。

これをまともに取り扱うと、あれこれ馬鹿らしいことが起こるので(いや、斜めに扱ってもえらいことが起こってしまうのが常なのですがw)、外骨は春画の稀有な組み合わせの下流に猥雑なものを置きます。「猥雑風俗辞典」を紐解いたり、滑稽新聞を取り出したりすればいいのですが、このあたりの全方位的な批判精神(ともすれば、悪漢小僧的な揶揄でしかないかもしれませんが)が必要だったりします。どうせならば、楯の会のパロディのような極右翼から極左翼に一周/一蹴してしまうような「面白がり方」が必要ではないか、と思ったりするわけです。それはさておき、体制側が真面目に取り締まれば取り締まるほどばかばかしくなるような春画とパロディの組み合わせが面白味の境地です。そのあたりの面白味がなくて、なんぞ人生か、というところです。

早稲田の学祭から池袋へ

そんな訳で、つらつらと春画を見た後は(あまりに混んでいたので後日に平日に行きたいと思っています)、なぜか早稲田の学際(音楽祭?)っぽいもので、早稲田の地ビールを飲みながら、AKB もどきの予備軍を眺めつつ(一生懸命に応援する学生が3名ほど、追っかけ?)。同世代(2つ違い)と分かった闇嶽さんとは、10年以上の付き合い(ネット上だけではありますが)で、話の内容的には以心伝心、ネット上の話の素直に延長になります。それぞれの仕事振り、生活振りはさておき、と言いたいものの、「生活する」という点は一致するし、まあそういう世代なのかもしれません。ただ、本質的に「体制側万歳」にならないのが、性といいますか、そうじゃないから外骨に傾倒するわけですし、まあ、そんなところですよね。お互い爆死/憤死することは避けたいものです。

ひとり考えていたり、ツイッター上の情報を集めてみたり、あれこれと日本の行く末を考えてみたりすると、自分がなんぞ加担できることはないかと考えたりしますが、まずは目の前の「仕事」をきっちりとやるというのが自然な態度でしょう。なんか、遊んでいる人があれこれと意見を言ったり、意見がころころ変わる人が「絶対、大丈夫です。私を信じてください」と言ったりしてても、信用されませんよね。実例も実績もないのに、年収を語/騙ったり、超自然現象やらねつ造やらゴッドハンドやらスタップ細胞は絶対ありますやらと一緒なのですよ。うまく見えない場合は見えないなりに、自分で判断すればよいし、妄信/猛進するのではなくてちったあ自分の頭で考えた故の結果を自分の人生で責任を取ればそれで良しでしょう。そんなことをつらつら考えて、ビールを飲みつつ、最後はねむくなって居眠りしてしまいましたが(もうなんか、酒に弱くなって無理)、そういう時間を過ごしてまいりましたし、また、そういう時間も引き続き過ごしたいものです、という一日でありましたとさ。

カテゴリー: 雑談 | 永青文庫 春画展に行く はコメントを受け付けていません

多数決という非民主的な暴力の裏

タイトルは「多数決という非民主的な暴力」と銘打ってみたけれど、それほどセンセーショナルなものにはしたくはないので、後で考え直そう…と思ったけど、このままで。

安保改正法案の発端から考えてはいたけれど、特にブログに書くことはありませんでした。私としては発端の違憲状態からの法案提出の時点で、成立してしまった場合かなりリスクがあることを懸念しているわけですが、それはさておき、ディベートの手順に従って議論の相手にエールを送るところから始めてみましょう。ちなみに、公聴会の翌日の参議院委員会の裁決のスタイルは時間稼ぎであれ法案を通そうとする強行採決であれ、あまりにも「雑」ではなかったかと思います。その雑さがあまりにも低俗なため低俗のまま議論しても始まらないし、将来を憂うのであればきちんとしてた論議のスタイルを守るのが必要ではないでしょうか。とは言え、デモを否定するわけでもなく、意味のないハンガーストを肯定するわけでもなく、違法逮捕を肯定するわけでもないのですが、賛否両論が意見を交わしている間は「平和」であることは確かなことです。そうそう、国会内で議員さまが殴り合いするのは彼らの権利だし仕事(パフォーマンスという意味で)なので、おおいにやってください。議会内は治外法権ですからね。

以下、エールを込めて、賛成案から考察していきます。

集団的自衛権を行使して平和を守るということ

政府与党から意見がもろもろありますが、それを通り過ごして民意として考えていきましょう。

集団的自衛権を行使して日本の平和を守ること、仮想敵国から自国を守る準備をすること、一国では対抗できないので陣営を組んで仮想敵国と対峙することは、何ら悪いことではありません。仮想敵国である中国・韓国の都合もあれば、東南アジアの先兵(地理的に日本が前面になる)という主張もあれば、アメリカ軍のバックを得るという利点もあります。そのためには、軍備を放棄する憲法のまま、軍備らしきものを装備せねばならず、さきゆきは改憲を見越して現時点の安保法案を通します。これは、尖閣諸島、竹島の問題を守ることでもあり、民主党政権で培ってしまった中国寄りの政治的判断を正常に(中立に)戻す意味もあります。

このために、自衛隊とアメリカ軍が組むときに(自衛権を発揮しなければいけないときに)、海外派兵なり物資供給なり再軍備なりをすることは国としての安全を保障するための急務です。いままで、多少足かせになってしまった憲法第9条の精神を尊重しつつ、日本の平和を守るという点で一国の軍備だけでは仮想敵国(中国と韓国)に対抗することはできず、話し合いによる外交を進めると同時に相応に対抗するための武力装備をしていきます。これからは、いままでの単純な「武力放棄」という架空な平和主義ではなく、現実的に対抗できる武力を以ってしてしか均衡を保つことができない現実解になります。

戦争を回避するための再軍備であり、とある未来の危機に対抗するための集団的自衛権の行使と安保改正による強化であるのですから、即戦争になることはありません。逆に言えば、いざ戦争になってしまったときに軍備も集団的自衛権も行使できない状態で日本の安全を確保することはできません。そういう不測の事態に対応するためにも、安保改正を成立させることが必要になります。

安保改正の反対するということ

これもプロ市民、韓国籍等もろもろありますが、平易な反対する理由を考えていきましょう。

第一に、憲法を勝手に「解釈」した上での安保法案は違憲であると考えます。立憲主義が立憲であるこということは、政府、閣僚、国会の多数に関係なく「憲法に従う」ことが重要です。憲法第9条の「放棄」に対しての意見は多々あるでしょうが(GHQの押しつけ、アメリカの都合など)、それを以ってして日本の平和が守らて来たことは事実です。それが仮初のものであったとしても。なので、そこの「解釈」を現時点の閣議を以って、勝手に決められては困る。自民党が圧勝したのは、民主党政治の反動もであり(あのぐだぐだ感は相当ひどい)、この「安保改正」を推進する意見ではない。

また、再軍備をしたとき、集団的自衛権を行使してアメリカ軍と組んだときには、日本では徴兵制が始まるのではないだろう?現実、社会保障(年金、介護、少子化)の問題が山積みしているところに、軍事費にお金を大量投入する意味があるのか。軍備を強化する前に、国力を保つことが大事ではあるし、大本が崩れてしまっては元も子もないのではないだろうか。中国と韓国の脅威は、確かにあるだろうけれども、これほど急がないといけない訳ではないだろう。まずは、外交からスタートしなければいけないし、経済制裁等、軍備ではない方法を模索するのが第一ではないだろうか。

憲法第9条を守ってきた日本の立場を崩さないためにも、急速に再軍備を進める必要はない。かつての戦争の道筋をまた繰り返すのだろうか。

両論あるということ

これを多数決で決めろというのが、無理でもあり。多数で決めたいというのが多数決という民主主義(と思われるもの)であったりする訳です。世論、デモ、マスコミ、新聞、ツイッターのリツイート数などを見ると、賛成が多いような気もするし、反対意見が強いような気もします。ただし、絶対的な真実としては、国会内の与党数が過半数を超えているということですね。ここだけは動かせない現実です。

じゃあ、「多数決という民主的な方法をとって、賛成を通せばいいんじゃないか」という意見もあるでしょうし、実際そういう意見はツイッターで多く見かけます。ただし、「多数決で決めること」が民主主義的ではないのは、絶対的な少数派が常に弱者の立場に追いやられてしまうことです。民主主義の基本(軍国主義や全体主義の対抗として)理念としては、民衆の総意を以って政治なり法案なりを決めていくことで、その議論は代議制によって行われます。代議制は民衆の代表であるから、多数であれば代議士が多く、少数であれば数は少ないでしょう。しかし、少数意見を捨てない方法が常に取られます。それは偽善かもしれませんが、ボランティア活動であったり、ユニバーサルデザインであったり、老人/女性/子供(あえて女性を入れます)への配慮であったりします。これらの弱者配慮というポリシーは、いわば「余裕」でもあります。逆に言えば、今、多数決で無理やり決めようとしているところには、とある「余裕」が無くなっているのでしょう。

何故、来年ではダメなのですか?

ま、レンホー語を借りれば「何故、来年の成立ではダメなのですか?」、「何故、憲法の改正をしてからではダメなのですか?」と聞きたいところですよね。中国・韓国の危機が迫っているという意見もありましょうが、中国経済が暴落等で減衰しつつあるし内部で手一杯でしょう、韓国は北朝鮮との緊張状態もあり竹島問題も放置しつつあります。尖閣諸島問題も放置されています。ガス田は掘り続けてはいますが。

シリアの問題もあり、ISISなどのテロ活動もあり、のんべんだらりとした平和主義を貫くには難しい状態にはなってきました。ならばこそ、それなりに準備をして「憲法を改正」した上で、現政権にて国民投票をした上で改正すれば良いでしょう。安保条約は、今年だけの問題ではないでしょう。ならば、今回のような強行採決を疑われるような場面を国会にて演じるのではなく、来期に持ち越してはどうでしょうか?

利得者がいる

既に、だいぶん透けて見えていると思いますが、利得者がいます。「余裕」があればこそ、来期でもよいし、年末でもよいわけですが、夏のおわり秋のはじめに決めなくてはいけない理由があります。基本的に、現A首相は胃弱なので強烈なストレスに耐えられません。逆に言えばストレスを掛ける相手には非常に弱く、なんらかの精神的ストレスを避けるように動き始めます。人間も動物なので、これらの行動原理は仕方がありません。個人的に強硬策ができるタイプでもない場合、何かの後ろ盾が必須です。

まあ、安保を破棄してしまうとアメリカに捨てられる日本という構図があり、日本は孤立してしまうのではないか、という恐怖があります。実際、孤立したときに中国・韓国に攻められるのか、東南アジアの各国から逆襲を受けるのかはさだかではありませんが(こわくてシミュレーションできないのではないか、という噂もあります)、この国際情勢でいきなり戦闘状態になるとしたら北朝鮮からのミサイルなので、それくらいを気を付ければよいでしょう。

そういう意味で、大国アメリカに寄りかかってしまっている日本ではありますが、アメリカから見れば中国・韓国への防壁としての日本ですよね。そういう立ち位置にいて、アメリカの防衛費の一部を日本が負担する(日本に負担させる)のは、アメリカとしてはまっとうな戦略かもしれません。日本としてはたまったものではありませんよね。そういう軍事費/防衛費の予算組が、今月末にアメリカであるのだから、関連がないとは言えないんじゃないでしょうか。

軍備を売る、武器を輸出するというのは、人道的にはどうあれ非常に儲かるものです。なぜかというと、軍備/武器自体は常に壊れることを前提としているので、常に新しいものを供給する必要あります。サイボーグ009にも死の商人が両陣営に武器を輸出して儲けるという話が何度も出てきます。不思議ですが、仮面ライダーのショッカーはこの方式はとらないんですよね。それはさておき、常に作る/壊れる/作るという循環があるがゆえに、兵器というものは生産として儲かるのです。なので、武器を輸出するという(壊れるものを輸出する)というのは是非ともやりたいことではあるんですよね。利得者が。

政治的な信条のあれこれの前に、経済界にべったりの政権があります。これは自民党が培ってきた族議員とか利権の話になります。民主党政権でも似たことをやったので、どっちもどっちです。また企業のほうも、自民党から民主党に乗り換えたり、再び自民党に乗り換えたりするので、法人税の減税もあわえて経済界にべったりなのは確かです。

そんな話を前提として

そんな話を前提として、わたくし的には、「憲法の改正手順を踏んで、憲法第9条を改正する」「その上でならば、自衛隊の軍化もありだろうし、検討の余地はある」というところです。徴兵制や軍事費や安保改正のあれこれは、これの先の話です。でもね、たぶんA首相にはこれができません。そういう話です。

カテゴリー: 雑談 | 多数決という非民主的な暴力の裏 はコメントを受け付けていません

Raspberry Pi で Android を動かそう

10/3(土) の 第6回 Japan Xamarin User Group Conference 東京 – connpass のライトニングトークスネタ的に、Raspberry Pi で Android を動かしています。事例スペシャルだしLT枠の10分程度だし、当日はさくっと RPi2 で Android デモをしておしまいな感じ。Xamarin ですから、Visual Studio 2015 から Xamarin.Android を使ってデプロイ&デバッグぐらいなスタイルで行きます。普通は Android/iPhone のスマートフォンを使ってやる話ですから、異例といえば異例な気もしますが、実は、このネタ自体は、組み込みシステムのカンファレンスあたりから考えていたものです。

Android ボードというものがある

5月あたりに ホーム – 組込みシステム開発技術展 | ESEC があったわけですが、その中で Android ボードをいくつか見てきました。戦車なりロボットアームなりを動かそうとすると、Raspberry Pi に Rasbian(Linux) を入れて使うか、Arduino などを使った直接制御をするか、ってのが定番だと思います。そんな中で、以前は ARM で動く Java CPU だったり、Java の組み込みシステムという分野があって、そうなると色々見ているうちに Android の組み込みボードというのがありました。Android と言えば、スマートフォン/タブレットを使うのに特化したようなイメージがありますが、ノート PC に直接入れたって良いし(使い勝手はどうなのか知りませんが)、中身はれっきとした Linux なのだから、そのまま GPIO をつなげて制御ができたってよいのです。実際 ESEC では、組み込み Android ボードがあって、定番的には 5万円ぐらい、安いところで 2,3万円というものがありました。遊びにはちょっと高いものだし、そのままだと Android スマートフォンを買っても良い値段なぐらいで、どんなものかな、と思っていたのですが、その事例の中に Android IDE を使って GUI 部分と機器制御(券売機)を行っていた会社さんがありました。なるほど、GUI を組み合わせるのだったら、Android IDE みたいなのがいいですよね。ってことは、Xamarin.Android を使えば C# で書けるのではないか?と思ったわけですが、聞いてみるとグラフィック部分は外部ライブラリを使っていて、特殊な形で呼び出しているとのこと。うーむ、そうなると Android ボードを買っても動かない、

Banana Pi で Android が動く

さて、そうなると、ひょっとすると Raspberry Pi で Android を動かしているものがあるのではないかと調べてみると、一応、非常に遅いのですが Android が動くという噂を見つけました。なにやら、ややこしくてインストールも大変そうだし、Android 自体も 2.3 という古いバージョンだったので(BLEを使いたいので、4.4以降がいいのです)探すのをやめてみたのですが、Banana Pi – Product – LeMaker | The Open Source SBCs Community という Raspberry Pi 互換ボードがあるのを見つけました。 すでに手元に Raspberry Pi が 5台(!)もあるので、互換ボードであっても Linux が動くだけではつまらないのですが、Raspberry Piを模した「Banana Pi」が発売–中国の教育機関が開発 – ZDNet Japan の記事を見ると「Android 4.4」という単語がはいっています。なるほど、ならば買ってみて、Android を動かしてみよう、というのがスタートです。ちなみに Banana Pi の Android イメージは Banana Pi – LeMaker | The Open Source SBCs Community からダウンロードができます。

ちなみに、実際に動かすとこんな感じになります。WiFi, Bluetooth のドングルが認識しないので、有線LANでつないていますが、マウスを使ってアプリを動かすことができますね。左上に「ねこあつめ」のアイコンがあるのでわかるように Google Play からアプリをダウンロードできます。

手元の 5インチモニタで動かしてみたのですが、解像度の設定がうまくいかなくて場所がずれてしまっています。/boot/config.txt で解像度を変えられるはずなのですが、Android の場合はどうやるんでしょうね。

Resolutions supported by Android on Banana Pi – Android – LeMaker | The Open Source SBCs Community あたりで DragonFace program を使うようなことが書いてあるのですが、これはあとで調べてみます。

BerryBoot で Android を起動させる

Raspberry Pi というと公式の NOOBS をダウンロードして Raspbian を入れるのが定番だと思っていたのですが、一方でマルチーブートが使える BerryBoot v2.0 というのもがあるのを知りました。Raspberry Piで遊ぼう [No.23:BerryBootでRaspberry Piのマルチブートをやってみよう(SDカード作成)]:アシマネくんのほんわか日記:So-netブログ な記事を見ると、2013年頃からあるもので、その中に Android 4.4 のイメージをダウンロードできる項目があります。

じゃあ、やってみよう、ということで Android 4.4 を Raspberry Pi2 にインストールしたのがこれです。こっちのほうは、マルチブートの設定で config.txt を書き換えることができるので、解像度を 800×480 に設定しています。

config.txt の設定

hdmi_group=2
hdmi_mode=1
hdmi_mode=87
hdmi_cvt 800 480 60 6 0 0 0

hdmi_modeがダブって書かれているのですが、そのまま書いています。Raspberry Pi Config | Adafruit 5″ and 7″ 800×480 TFT HDMI Backpack | Adafruit Learning System 私が使っているモニタは Adafruit のものとは違うので完全に設定は同じではないのですが、互換はあるでしょう。タッチパネルなので、タッチもできるはずなのですが、こっちのほうはまだ動いていません。仕方がないのでマウスでアプリを起動させます。例によって、Wifi も Bluetooth のドングルも認識しないので、Android スマートフォン以下です。当初のもくてきの BLE も使えないので、なんともやりようがないのですが、そのあたりはもうちょっと頑張ってみる予定です。なんせ、Android 組み込みボードを買うと 3万円ぐらいするのに、この組み合わせだと Raspberry Pi2 が5千円ちょっと。5インチモニタや BLEドングルと合わせても1万円弱ぐらいで済みますからね。

Android スマートフォンで単体で動かすと GPIO 制御はできないし、BLE経由でロボットを動かすことになります。Raspberry Pi + Android だと、直接モーター制御とかができそうですよね。アプリ自体は Google Play に載せることも可能なので、なんかいいかもってな感じです(誰が注目するのか?というは謎ですが)。まあ、素直に Raspbian でやったほうが早いと思いますが(苦笑)

中身は Android なので、Xamarin.Android が使えます。後ろに見えているのが Visual Studio 2015 でデプロイ&デバッグができます。BerryBoot の Android は既に 5555 のデバッグポートで動いているらしく、adb connect <IPアドレス> でコネクトができます。バッテリは試しにスマートフォンの急速バッテリを使って動かしてみました。例によって、タッチパネル機能が動かない(ここももうちょっと頑張ってみる予定)ので、マウスで動かすというなんとも変な感じですが、モニタリングとしてはいけますよね。先日出た Raspberry Pi の公式タッチパネル Raspberry Pi:Raspberry Piにマルチタッチ対応の公式7インチタッチパネル – MONOist(モノイスト) を使うと動くのかどうかは謎です。$60 ということなので、手元のほうは半額。ただし、公式のほうは既に売り切れ状態なので、まあ手元のもの頑張るしかないわけですが。

Xamarin.Android のほうはもうちょっとデモっぽいものを作って持っていく予定です。できれば GPIO を制御するところまでやりたいのですが、時間的にそこまで行けるかどうか不明。途中に 9/26(土) Comm Tech Festival が挟まっているので。.NET のほうは、Windows IoT Core on Raspberry Pi ということで、戦車かサーボモーターで動くおもちゃの予定です。

と、Orange Pi に Android を入れる補記

書き忘れていたので追記しておきましょう。Orange Pi という Raspberry Pi 互換機があります。これが非常に安価で、Aliexpress で $15 だったりします。公式サイト を見るといくつかあり、私が手元に持っているのは Orange Pi Mini 2 です。それぞれ、どのような違いがあるのか一見してわかりませんが(苦笑)、ひとまず Mini 2 は WiFi なし版ですね。WiFi が乗っている Orange Pi Plus を買うほうがいいかもしれません。ちなみに $15 のほうは、Orange Pi PC ですね。USB が一個少ない(3つになってる)けど、これで十分でしょう。Android を入れて、モニタをくっつけて並列で動かしてみたいな、と思ったりしたのですが…Android に関しては、ちょっと手間取って躊躇しているところです。普通に Linux マシンとして動かすほうがよいでしょう。

Orange Pi のイメージは Orange Pi から適切な種類のものをダウンロードしていきます。このなかで Android の書き込みには、Win32DiskImager が使えなくて、PhoenixCard で書き込みをします。書き込みの手順は、Install Android OS image に従っていけばよいでしょう。

image

ここで、かなりはまったのですが、micro SDカードを差し込む場所は、PC に直差しにしたほうがよいです。最初、HUB を通して書き込んでいたのですが、書き込み時にエラーが頻発します。なぜか、SDカードリーダーの調子も悪くて、暫くは SD カード自体が壊れてしまったのかと思っていました。たぶん、書き込みスピードの問題もあるのでしょう。PhoenixCard を使う場合は、PC に直差しで書き込んでください。

その後、micro SD カードを Orange Pi で動かすと、こんな風に Android が起動できます。残念ながらモニタの解像度はあっていないらしく 5inch モニタでは動いていないのですが。

初期状態の Android は中国語になっているので、設定の言語で「日本語」を選びます。ちなみに、USB OTG インターフェースがあるので、Android に USB 接続して adb で、と思ったのですが認識しませんでした。仕方がないので、Xamarin.Android アプリは USB メモリ経由で送っています。これは、ボードの問題なのか、インストールした Android の問題なのかは不明です。

そんな訳で3機種(Raspberry/Banana/Orange)が動いたので、今度は Lemon Pi を買って試してみようかなと。もともと Banana Pi の購入目的が Android を動かすことだったので、Raspberry Pi 上で動けばそれで十分なんですけどね。Raspberry Pi 上の Android は GPU の関係は 800×480 の解像度でも結構遅いです。フルHD だと全然ダメなので、実用的に使うのであればもう少し画像回りのスピードがあがるボードじゃないと辛いと思っています。

 

 

カテゴリー: Android, RaspberryPi, Xamarin | 1件のコメント

Windows IoT Core では Win2D が使えるよ

Unity, UE4 とグラフィック界の華やかな技術を使わずに(苦笑)、Windows IoT Core ではちまちまと DirectX を使う…のは結構大変なので、ひょっとしたら Win2D を使ってみたらそのまま使えるのでは?と思っていたら、使えました、の話です。下記は、Windows IoT Core on Raspberry Pi で Win2D の Effect のサンプルを動かしているところです。ディスプレイは先日買った5インチのHDMI接続のディスプレイ。通常の PC で動かすよりは遅くなりますが、まあ静止画とか、ちょっとしたエフェクトをかける程度ならばこれで十分動きます。

https://pbs.twimg.com/media/COJk5joUAAA67VG.jpg

Win2D とは何か?

単純に言えば、ストアアプリ用のDirectXラッパーなのですが、Windows 10 のユニバーサルアプリに対応したものを使うと、PC/Mobile/IoT と同じものを使うことができます。

多分、PC/Mobile は、そのまま動くのでしょうが、IoT の場合はすべてが動くかどうかは解りません。Microsoft/Win2D にあるサンプルを ARM でコンパイルするとリモートマシンへの配置ができなくて、Raspberry Pi に配置ができないのです。

NuGet で取得する

中身のコードとサンプルは Microsoft/Win2D にありますが、Visual Studio 2015 からは NuGet を通してダウンロードができます。

image

以前の「Wi2D」のほうは、古いバージョンになるので、

  • Windows 8.1 の場合は、Win2D.win81
  • Windows 10 の場合は、Win2D.uwp

で使い分けます。

Hello World を書く

Hello World を書くのは非常に簡単です。XAMLに CanvasControl を貼り付けて、Draw イベント時に描画を行います。これは通常の Win2D と同じ書き方でいけます。

■XAMLのコード

<Page
    x:Class=&quot;Win2DSample.MainPage&quot;
    xmlns=&quot;http://schemas.microsoft.com/winfx/2006/xaml/presentation&quot;
    xmlns:x=&quot;http://schemas.microsoft.com/winfx/2006/xaml&quot;
    xmlns:local=&quot;using:Win2DSample&quot;
    xmlns:d=&quot;http://schemas.microsoft.com/expression/blend/2008&quot;
    xmlns:mc=&quot;http://schemas.openxmlformats.org/markup-compatibility/2006&quot;
    xmlns:canvas=&quot;using:Microsoft.Graphics.Canvas.UI.Xaml&quot;
    mc:Ignorable=&quot;d&quot;>

    <Grid Background=&quot;{ThemeResource ApplicationPageBackgroundThemeBrush}&quot;>
        <canvas:CanvasControl x:Name=&quot;canvasControl&quot; ClearColor=&quot;CornflowerBlue&quot; />
    </Grid>
</Page>

■Drawイベント

namespace Win2DSample
{
    /// <summary>
    /// それ自体で使用できる空白ページまたはフレーム内に移動できる空白ページ。
    /// </summary>
    public sealed partial class MainPage : Page
    {
        public MainPage()
        {
            this.InitializeComponent();
            this.canvasControl.Draw += CanvasControl_Draw;
        }

        private void CanvasControl_Draw(CanvasControl sender, CanvasDrawEventArgs args)
        {
            args.DrawingSession.DrawEllipse(155, 115, 80, 30, Colors.Black, 3);
            args.DrawingSession.DrawText(&quot;Hello, world!&quot;, 100, 100, Colors.Yellow);
        }
    }
}

実行すると、こんな風に楕円と「Hello World」が表示されます。

https://pbs.twimg.com/media/COJoHlyUwAAHMdC.jpg

Effect を移植してみる

Win2D のサンプルにある EffectsExample をコピペして移植します。これも Hello World と同じように XAML に CanvasControl を貼り付けて Draw イベントで各種の描画をします。

うまくビルドが通ると、Raspberry Piにアプリを転送させてエフェクトの画面を描画することができます。

https://pbs.twimg.com/media/COJk5joUAAA67VG.jpg

移植したときのサンプルコードは、github からダウンロードできます。

Win2DSample

からダウンロードができます

カテゴリー: 開発 | Windows IoT Core では Win2D が使えるよ はコメントを受け付けていません