先週、nRF5 SDK v12.0.0がリリースされた。
今回は、かなり大規模な改修になっている模様。
リリースノート
「Overall」が目立つので、v11とは互換性がなくなっているんじゃなかろうか。
まだ試してないけど。
細かく見るよりは、こういうニュース記事の方が雰囲気をつかみやすいかも。
Nordic Semiconductor、最新版nRF5 SDKを発表、署名付きのセキュアなOTAファームウェア・アップデートを導入し、デバイスのセキュリティ向上を支援 - BIGLOBEニュース
Bluetooth v4.2よりもSecure DFUの方を推しているようだ。
まあ、DFUは確かに怖かったので、しくみを用意してくれるのはうれしい。
Arduino Primoのことも書いてあるし、Keilのこともかいてある。
PrimoはKeilで開発しますよ、という流れになって、STM32F1みたいにKeilが自由に使えるようにします！とかなるとうれしいのだがなぁ。
すごく気が向けば、試してみよう。
最初に手を出すのに、勇気がいるのよね。
久々に、Ubuntuを仮想環境ではなくインストールした。
14.04のDVDしかなかったので、インストールして、アップグレードしてもらった。
ときどきなぜか固まることがあるのだが、まあよかろう。
GeForce GT710という古いグラフィックスボードだが、これでもCPUで計算するよりも速い(はず)。
CaffeとCUDA8.0RCなどをインストールした。
もう使い方を覚えていないから、ネットで見ながら動作確認を行った。
CaffeでDeep Learning (2) - 桜朔
[deep learning] caffeとCIFAR-10を使って画像判別テスト(詳細) - 脳汁portal
動いたのだが、どちらの人もclassify.pyを使っていない。
io.pyを修正しても、なんかちゃんとした結果を出していないような気がするのだが、そもそも何なのかがよくわかっていないので、推測ができん。
まず思ったのは、classify.pyで省略した引数が影響しているのではないか、ということだ。
"--mean_file"があやしい。
デフォルトでは、'caffe/imagenet/ilsvrc_2012_mean.npy'を使っているのだが、これはILSVRC2012用だろう。
cifar10は、CIFAR-10のmean_fileを指定すべきではなかろうか。
ただ、python/caffeの下にはCIFAR-10用と思われるファイルがない。
このnpyファイルは、numpy array形式のファイルらしく、"data set image mean of [Channels x Height x Width]"と説明があるから、平均画像なのだろう。
CIFAR-10サンプルの平均画像は、mean.binaryprotoというファイルになるようだ。
これを指定すればよいかと思ったが、エラーになった。
形式が違うようだ。
Convert binaryproto to npy | Rachel's Memo
Pythonのコードが載っているが、open/readはしているが、writeはしていないから、arrという変数がnpy形式ということになるのか。
最後に「np.save(ファイル名, arr)」とすると、arrの内容をファイル保存するようだ。
これをclassify.pyの--mean_fileに指定すると、ずいぶん進むようになったが、今度は次元数が違っているというような感じがする。
いや、ndimじゃなくてlen()だから、次元ではないか。
io.pyでは、2か3(2だったら1足している)を通すようなのだが、変換したデータは4になっている。
変換データのshapeは(1, 3, 32, 32)だから、これが4つあるからlen()が4なのか。
最初にmean.binaryprotoを作る場合は、コマンドbuild/tools/convert_imagesetを使っている。
lmdbとあるから、lmdbフォーマットがbinaryproto形式ということか。
(1, 3, 32, 32)のうち、最後の2つはデータのWidth x Heightだろうし、その手前はRGBの3 layerだろう。
classify.pyがほしいのは"[Channels x Height x Width]"ということだから、最初の"1"がいらないだけなのかな。
「arr = np.reshape(arr, (3, 32, 32))」とすると、(3, 32, 32)になった。
import caffe
import numpy as np
import sysparam = sys.argv
blob = caffe.proto.caffe_pb2.BlobProto()
data = open( param[1] , 'rb' ).read()
blob.ParseFromString(data)
arr = np.array( caffe.io.blobproto_to_array(blob) )
arr = np.reshape(arr, (3, 32, 32))
np.save(param[2], arr)
わざわざparamに移したり、arrに2回代入したりと格好は悪いが、ネットで調べながらだから許しておくれ。
これで(3, 32, 32)になったし、classify.pyの--mean_fileに指定してもエラーにならなかったが、show_result.pyで見てもパーセントが0だ。
何か違うのか。。。
ああ、--model_defと--pretrained_modelも指定しないといかんのか。
2番目のサイトのスクリプトをまねしよう。
$ python python/classify.py ./car.jpg ./result.npy --mean_file=cifar10.npy \
--model_def=examples/cifar10/cifar10_quick.prototxt \
--pretrained_model=examples/cifar10/cifar10_quick_iter_4000.caffemodel.h5$ python python/show_npy.py result.npy
#1 | dog | 42.7%
#2 | cat | 31.8%
#3 | airplane | 11.0%
数字は出たのだが、結果がおかしいな。。。
2番目のサイトにある、猫がアップになった画像だと、こうなった。
#1 | bird | 29.0%
#2 | airplane | 20.9%
#3 | cat | 13.8%
全然違うなぁ。
同じスクリプトをうちでも動かしたが、数値は異なるもののネコが一番高くなるところは同じだ。
====================================
possibility of each categoly
0(airplane): 0.184532
1(automobile): 0.000219549
2(bird): 0.0134824
3(cat): 0.539376
4(deer): 0.0715057
5(dog): 0.021061
6(frog): 0.0255798
7(horse): 6.09221e-07
8(ship): 0.136054
9(truck): 0.00818893
====================================
I guess this image is [cat]
数字が違うというのも気にはなるのだが、半年違いがあるからネットワークが少し変わったのかもしれない、と勝手に思うことにしよう。
載っているスクリプトもmean.binaryprotoをreshape()しているから、意味として同じようなことをやってるんだと思う。
なにが、何が違う。。。。
あー、images_dimだ。
classify.pyはデフォルトだと256,256なのだが、載っているスクリプトでは省略していて、caffe/classifier.pyのデフォルトは画像サイズ、つまり32,32になっていたのだ。
なんだー、じゃあ、そこも指定して動かしておしまい。。。と思ったら、Ubuntuが死んでしまった。。。
メモリテストも正常だったし、インストールも新規だったし、あとはnVIDIAのドライバか、AMDのドライバか？
リセットして動かしたが、まだ合わない。。。
ここまで指定して、ようやく結果が一致した。
$ python python/classify.py ./cat.jpg ./result.npy --mean_file=cifar10.npy \
--model_def=examples/cifar10/cifar10_quick.prototxt \
--pretrained_model=examples/cifar10/cifar10_quick_iter_4000.caffemodel.h5 \
--images_dim=32,32 --center_only --channel_swap=0,1,2$ python python/show_result.py data/cifar10/batches.meta.txt ./result.npy
#1 | cat | 53.9%
#2 | airplane | 18.5%
#3 | ship | 13.6%
こういう目にあうと、DeepLearningはともかく、Pythonには少し近づけたかもしれない。
Facebookで、IC運転免許証の仕様書が更新されていることを教えてもらった。
いやあ、まったく気付いてなかったですわ。
運転免許証及び運転免許証作成システム等の仕様の改正について(PDF)
仕様書V7になったようなのだけど、2016/07/15に施行された道路交通法の変更が理由らしい。
たぶん、これじゃなかろうか。
道路交通法の一部を改正する法律の施行に伴う交通警察の運営について(PDF)
車を持ってないので、どうも疎いのよねぇ。。
免許更新に行くと説明してくれるからわかるのだが、PDFを読んでもよくわからん。
免許で乗ることができる車種が変わったりするけど、あの区分が変わったとかか？
そもそも、どこで更新されているのかを把握すればよいのかわかっていなかったのだが、警察庁の運転免許課というところに出るようだった。
検索だと、新しい情報は出てきにくいのだ。
警察庁の施策を示す通達（交通局）｜警察庁
つらつらと見ていくと、免許証以外にも気になるものがあった。
運転免許証の記載事項変更の届出手続における個人番号カード及び通知カードの取扱いに関する留意事項について(PDF)
これは2ページぐらいだから、すぐに読める。
大ざっぱに言うと、免許の住所変更のときにはマイナンバーカードで住所変更されているかも確認しなさいよ、ということだ。
だったら、マイナンバーカードの更新時に免許の方も同時にやってくれたらいいんだけどねぇ。
「管轄が違う」ってやつですか。
こんなのもあった。
ＩＣカード免許証の暗証番号の運用に係る留意事項について
こっちは、なんか愚痴っぽい。
「暗証番号1を忘れている人が多いので、IC運転免許証の民間での使用普及が広間欄じゃないか！」みたいな。
で、暗証番号1を使って読込を行っても免許証を見てわかることしかわからないので、じゃあ免許証を見てわかるものを暗証番号1にしてもいいんじゃないか、という提案みたい。
以下、スクリーンショットはPDFから取ったものだ。
へー。
一番最後に検討したときの結果が書いてあって、結局「暗証番号1で読み取れる内容での本人確認は確実じゃないし、使っている民間企業も今のところ確認できない」ということらしい。
暗証番号1で読み取ることができる情報は、こうなっている。
暗証番号無しだと、たとえばポケットに入れているカードから情報を吸い上げられる可能性があるから、少なくとも暗証番号の設定は必要だ、ということになっている。
どっちかといえば、カードの券面にこういう情報を載せないようにして、暗証番号1を打ち込まないと読めない、という運用の方がいいんじゃなかろうか？
まあ、暗証番号1を忘れてしまっているからそういう運用ができない、ということなんだろうけど。。。
それに、そうしてしまったら、拾ったカードを交番に届けても、カードを読めないと誰のかわからないが、誰のかわからないとカードを読めないことになるのか。。。
難しいねぇ。
今回、公的個人認証の公開鍵を読んだが、PaSoRiを使ったりしたものの、基本的にはAAA Blogさんの記事をなぞっただけだ。
特別に解析などはしていない。
苦労したのは、ASN.1がわからんとか、opensslのコマンドがわからんとか、Type-Bのアクセス方法がわからんとか、直接カードとは関係がないところだった。
省略して「マイナンバーの公開鍵」と書いたりもしたが、公的個人認証の部分だけしかアクセスしていないし、そこにはいわゆる4情報も入っていなかった。
文字で見てわかる情報は、こんなところだ。
この情報は、JPKI利用者ツールで取得できるものとだいたい同じだ。
誕生日はバレるが、生年月日はわからないからセーフなのかな？
一応、個人番号で取得したデータを検索してみたが、正順、逆順、ASCII変換で探しても出てこなかったから、少なくとも素のままでは入ってないだろう。
まあ、ファイル構造がわからないから、他がどうなっているかは知らないけど、入れる意味はないと思う。
そんな感じだ。
自分で調べたところがあまりないので、他人のふんどしで相撲を取ったような感じもするが、夏休みの自由研究だからよいのだ。
マイナンバーカードから公開鍵を読めたとしよう。
そこからどうしたらよいのだ？
ここからは、私の知らない世界だ。
私の中では、こういうRSAとかはopensslを使うものだろう、というイメージがあるので、それでやってみた。
が・・・、openssl rsaでもopenssl rsautlでも、公開鍵として読めない、と言われる。
openssl asn1parseをDERオプション指定では読めるので、ASN.1としては正しいはず。。。
RSA公開鍵のファイル形式とfingerprint - Qiita
こちらを見ると、取得した公開鍵の形式はpkcs#1のような気がする。
サイズが同じだし、タグがSEQUENCE-INTEGER-INTEGERの構成だから、というだけの根拠だが。。。
ssh接続用の公開鍵( ssh-rsa public key )をopensslで使える形式( X.509 PEM )にshellscriptで変換する Mac OS X ( Convert ssh-rsa public key to pem )
なんと、pkcs#1はopensslでは使えないようだ、との記述が。
でも、opensslの-informの説明では、"DER"はPKCS#1フォーマットと互換のあるASN1エンコード、と書いているのだが、実際使えないから、何か違うのかもしれん。
openssl - How can I transform between the two styles of public key format, one "BEGIN RSA PUBLIC KEY", the other is "BEGIN PUBLIC KEY" - Stack Overflow
お、こちらの2番目の回答者は、rsaEncryptionだけじゃなくて、もうちょっと上の方から、データに含めているようだ。
さっきまで試していたのは、図で言えば赤線で囲んだ枠の中だけのデータだったのだが、回答者は青線で囲んだ枠の部分をデータにしているのだ。
$ openssl rsautl -encrypt -pubin -inkey file.bin -keyform DER -in
mine.txt -out mine.enc
$
おー、通った。
file.binが青枠の部分をファイルにしたもので、mine.txtは符号化用に作った短いテキストファイルだ。
実際は、mine.txtのダイジェストを取って、それを符号化するんだったような。
じゃないと、長い文章なんかはそのまま符号化できないからだ。
復号するところも試してみたいが、秘密鍵は持っていないのでできない。
実際は、符号化するのはカード側で、opensslで行うのは復号の方だ。
カードには、暗号化したいデータを書けばよいのかな。
マイナンバーカードでSSHする - AAA Blog
"PKCS1形式のハッシュ値"と、また聞いたことのない形式が出てきた。。。
単に符号化するだけだったら、データ形式は関係ないのでは？と思いたいのだが、今までがASN.1というかpkcs#1形式だっただけに、ちゃんとINTEGERとか付けないとだめなのかもしれん。
こういうのは、OpenSCのソースを見るのがよいのだろうが・・・。
sc_pkcs15_compute_signature()をpkcs15-crypt.cなどが呼んでいるところまではわかったのだが、深入りしない方がよい感触だ。
では、気にせず適当に値を投げてみればよかろう。
暗証番号が間違えばカウントが減りそうだけど、ここで間違っていても減らないだろう。
よくわからない0x2AコマンドはType-BのCase4Shortなので、ヘッダと、Lc、データ、Leで構成される。
Lcはデータのサイズで、Leは2048bitということで00にしておけば256バイトになるだろう。
あ・・・256バイトのレスポンスなんて対応してないぞ。
Normalフレームでの送受信しかやっていないのだ。
Extendedフレームにした場合は265バイトまでいけるんだけど、入るのか？
レスポンスが256バイト、それにInDataExchangeのレスポンスコード、ステータスフラグで3バイト、SWで2バイト。
261バイトだから、収まるのか。
PN532のドキュメントでは、R-APDUは258バイトまでとなっているが、APDUの部分だったら満たしているから大丈夫か。
今までExtendedフレームなんて対応したことないから、参ったな。。。
あ、昔の私偉い！対応してた！！
では、やってみて、受信したデータを公開鍵で復号してみよう。
$ openssl rsautl -verify -pubin -inkey file.bin -keyform DER -in
sig.bin -out sig.txt
$ cat sig.txt
my number card!
おー、出た出た、やりおったわ。
カードの方に「my number card!」というデータを書いて、それによって戻ってきたデータをsig.binに保存して、それを先ほどの公開鍵で復号したのだ(公開鍵でやるときは、-decryptじゃなくて-verifyなのだね)。
夏休みの自由研究は、これで終わりにしよう。
やれやれ。
前回の続き。
公開鍵などが入ったファイルをdumpasn1とaatool2の両方で解析した結果を見比べて、ようやくわかった。
ASN.1には、object identifier(OID)というものがあり、それを見てどういうデータなのかを判断すればよいのだろう。
おそらくRSA公開鍵は、1.2.840.113549.1.1.1だ。
検索すると、JPKIの資料にも出ていた。
OIDが1.2.840.113549.1.1.1で、NULLで、BIT STRINGがあれば、BIT STRINGのところが公開鍵だと思っていいんじゃなかろうかね。
あー、でもこれをデータの頭から見て行くには、ASN.1を自前で解析できないといかんのか。。。
少なくとも、サイズ分スキップしたり、構造型オブジェクトで入れ子になったものを判断したりできないといかんな。
こっから先はNFCと関係ないので、ひとまず公開鍵が読めたし、解析方法もわかったということで満足しよう。
夏休みの自由研究も最後だ。
なんで公開鍵でNFCなのかというと、以前中断したマイナンバーカードだからだ。
マイナンバーカードでSSHする - AAA Blog
こちらのアプリで動かせればよかったのだが、うちのPaSoRiでは動かなかったので、しょうがなくソースを読んで、SELECT FILEとREAD BINARYした。
動かしている方の情報を見ていると、公開鍵を取得するときには暗証番号の入力をしていないようだったから、きっとREAD BINARYしてるだけだろう、と当たりを付けて、コミット履歴から探していった。
・・・というのは結果の話で、そこに行き着くまでがかなり大変だったのだ。
自由研究にふさわしいのだけど、書いてよい情報かわからんので、書かない。
公開鍵を読む、といっても、どうやって読んだデータが公開鍵か判断するんだ？と思われるかもしれんが、それはJPKI利用者ソフトという公的なツールがあって、それが公開鍵情報も出力するのだ。
だから、読み出したバイナリデータを検索して、一致するデータを探していったのだ。
実のところ、データは読み出せたものの、他にもいろいろデータが入っているので、公開鍵だけを抜き出す、というところまではできていない。
がさっとバケツで水をすくったような形だ。
バイナリデータは、ASN.1という形式のようだ。
たぶん、うまく抜き出してOpenSSLなどを使えば、他でも使える形式に変換できるんだろう。
そして、カードには秘密鍵で符号化する装置が入っているから、電子署名として使うことができるというわけだ。
総務省の資料を見ていると、何のアクセスか忘れたが、1件あたりいくらにしようか、というような検討が行われていたけど、この部分は問い合わせがいらないから、きっと無料で使えるんだろう。
まあ、5年ごとに更新する必要はあるんだろうが。。。
あれ、5年経ったからってカードが読めなくなるわけじゃないよね？
ならば、失効を気にしなければずっと使えるのか。。。
夏休みの自由研究、第2弾だ。
サーボモータを動かそう。
Arduinoスターターキットを購入したとき、サーボモータも一緒に入っていた。
SM-S2309Sと書いてある。
http://descargas.cetronic.es/microservo.pdf
PWMを入れることで動かすらしいのだが、PDFにはその仕様が書かれていないな。。。
ということは、単なるアナログ入力で、それをPWMで代替えしているということか。
前回作ったブザーを鳴らすアプリを変更することにした。
PWMの停止ができるし、PWMの調整するところまで実装しているから、Duty比を変えるだけでよいはず。
その前に、電圧のことを考えねば。
NUCLEOは3.3Vだけど、サーボモータは5Vなのだ。
アナログ電圧で制御するなら3.3Vでも動くのかもしれんが、よくわからんのに冒険はしたくない。
幸い、ロジックレベルの変換ができるチップを持っていた。
TXB0104搭載4CH双方向レベルコンバータ - スイッチサイエンス
上が3.3.V側、下が5V側。
オシロじゃないから電圧が変わったかわからんが、電気的に変換しているから時差はないのだな。
制御のさせ方は、こちらを参考にした。
サーボモータの制御
Arduinoスターターキットの本には、map()で制御する、しか書かれていないのでわからんのだ。
波長は15m～20msecらしいので、10msecにしてみよう。
以前計算した式から、
tick = APB1 / (Prescaler+1) = 84MHz / 8400 = 10kHz
PWM = tick / (Counter Period+1) = 10kHz / 100 = 100Hz
周期 = 1 / 100Hz = 10msec
Duty比 = Pulse / (Counter Period+1)
上記のページでは、13msecに対して1～2msecで動かしているから、Duty比は10～20%か。
100HzだとPulseはちょうどDuty比と同じだから、これでは10段階程度しか動かせんな。
まあいいや。
ソースを載せるほどではないので省略するが、動いた。
サーボ側の5VとGNDは、スターターキットの本に100uFの電解コンデンサでつないでおくように書かれていたから、まねした。
回転するときに電圧が下がるからかな？
しかし、Arduinoとは直接接続しているから、モータの時みたいにドライバを挟むほどではないようだ。
電源は別に取っているからそうなるのか。
うちのサーボさんは、Pulseを5～24の間で動いた。
4とかだと、少しうなるような音が聞こえたので、動くか動かないかのところで震えたのだろうか。
180度を10段階だから、18度ずつ動いたことになるだろう。
多少粗いが、そういうのはPreScaleを小さくして、tickが大きい値になるようにすればよかろう。
意外と、3.3VでもDuty比を上げれば動くんじゃなかろうか、とつないでみたが、90にしても動かなかった。
3.3Vを挿しても動かないので、やはりPWMじゃないとダメなのか？
まあ、あまり深くは考えまい。
[2016/09/02 21:41追記]
もう少し細かい情報が書かれているサイトがあった。
ブックマークまでしていたのに、なぜ見ていなかったんだ。。。
Arduinoで学ぶ基礎からのモーター制御：基礎からのマイコンモーター制御（6）：PWMを使ったサーボモーターの制御 (1/3) - MONOist（モノイスト）
これの2ページ目に、波長が20msecで、H区間を1～2msecで変化させる、と書いてあった。
1msecが0度、2msecが180度になるとのこと。
やってみよう。
tick = APB1 / (Prescaler+1) = 84MHz / 8400 = 10kHz
PWM = tick / (Counter Period+1) = 10kHz / 200 = 50Hz
周期 = 1 / 50Hz = 20msec
Duty比 = Pulse / (Counter Period+1)
これで、Pulseを9～19にすればよいはず。
・・・ダメだ、そんなに精度がよくないんだった。
手作業で調整したときの波形を計測した。
うーん、単にパルスの幅だけで動いているとしたら、500us～2300usくらいになってるんじゃないか？
こちらを見ると、同じSG90を使っているのだが、動作パルス幅が500us～2400usになっていた。
Netduino： サーボモーターをコントロールしよう - Build Insider
波長はそのままで、パルス幅を500us～2400usになるように値を変えると、同じように動いた。
だから、パルス幅を見てるんだな。
ようやく10回目を迎えた。
別に回数をどうこうという訳ではないのだがね。
このシリーズを書き始めたのは、ネットで検索した情報を見て、「組み込みって、なんかルールがきつそうだからやりたくない」と思われるんじゃなかろうか、と勝手に思ったので、「分野によってはそうでもないのだよ」ということを言いたくて始めたような気がする。
私は、けっこうリソースに余裕がある組み込みをやることが多い。
LinuxのようなOSが動く場合はもとより、ARMだったら32bitだし、RL78は16bitだったのできつかったなぁ、とか、そういう感じだ。
また、nRF51822やESP8266のように機能とセットになったマイコンを使うことも多い。
そうなると、載せ替えるとしても同じマイコン系列になるため、移植性を考えても仕方がないので、そこに時間を割くよりは、さっさと実装してしまおう、となっている。
そこら辺の事情があるから、値がだいたい収まるならintで済ますし、変数宣言の順番も数バイトくらいなら空きがあってもいいや、と思ってわかりやすい順に並べている。
たぶん、そういうのを気にする人と一緒にコーディングしていたら、相手はかなりイライラするんじゃなかろうか。。
本題に戻る。
今回はLinux限定かもしれんが、C11ではスレッドが使えるらしいので将来的にはわからんが、まあLinux限定としよう。
いつからか忘れたが、POSIXスレッドを使ってコンパイルするときのオプションとして「-pthread」があるのに気付いた。
たぶん、どこかの記事を見たのだと思う。
「この人、"l"を忘れてるやん」と思っていたのだが、ライブラリのリンクではなくてオプションだったのだ。
multithreading - Difference between -pthread and -lpthread while compiling - Stack Overflow
どうも、プリプロセスの段階で違いがあるようだ。
確かに私が持っている古いLinuxの本でも「-D_REENTRANT」を指定するように書かれている。
もしかしたらコンパイル段階でも違うかもしれん誌、GCCのバージョンによっても変わってるかもしれんね。
まあ、カバレッジも--coverageオプションになったようだし、コンパイル時点で働きかけるというのは流行りなのかもしれん。
FeliCa Linkが出てきたので、FeliCa Plugは使ってないなあ、という方も多かろう。
それなら、搬送波検出器にしてしまえば、何かと役に立つかもしれない。
FeliCa Plugとピン番号の関係は、こうなっている。
コネクタ側を下にしたら、左側が1番ピンだ。
搬送波が出ているところにかざすと、光る。
右上にあるのは、microUSBからの5Vを3.3Vに変換するものだ。
電池で動くのだけど、電池フォルダを持ってなくてね。。
さあ、夏休みの自由研究に困っていたら、使ってもよいのだぞ？
