import time, os
import cv2
from pyzbar.pyzbar import decode, ZBarSymbol

camera = cv2.VideoCapture(0)
code = ''

while True:
    ret, frame = camera.read()
    if not ret:
        break

    decode_list = decode(frame)

    if decode_list:
       code_new = decode_list[0].data.decode('utf-8')
       if code != code_new:
           print('found ', code_new)
           code = code_new
           out_file = os.path.join('img', code + '.png')
           cv2.imwrite(out_file, frame)

    cv2.imshow('barcode', frame)
   
    key = cv2.waitKey(1)
    if key == 27:
        break

print('finish')    
camera.release()
cv2.destroyAllWindows()

読めたバーコード

なんか自分の手が入っていて気持ち悪かったので、画像の一部だけ。こんな感じでカメラにバーコードが入ると、自動で見つけて値を読み取ります。

4910015780148

9784040751160

9784434311017

2023-11-14

Planning Algorithm Steven M. LaValle

Steven M. LaValle先生のPlanning Algorithmを読みした。

書籍は結構値段がしますが、ここからpdfがダウンロードできます。感謝しかない。

lavalle.pl

経緯

Robotic Grasping from Classical to Modern: A Survey を読んでいたら、軌道生成に関してはPlanning Algorithm読めって書いてあったのがきっかけです。このSurvey自体も読み物としては面白く、把持可能かどうかを従来の二値分類を使った機械学習から、Deep Learningへ変わっていく様子が分かります。紹介されている論文の量が多いので、実際の所はDeep Learning以前の物は無視しても良いかなと思いました。

arxiv.org

内容

ロボの軌道生成で論文書く人は必読かなと。数学的な問題の定義から始まって、手法の紹介、簡単な例が載っています。数学も工学書にしては厳密に感じました。例えば、何かの区間を処理するのに境界を含むか含まないかで、数学的なアプローチが全然違うといったことが書いてありますが、実務だとそこはあまり気にしない気がします。

ボリュームは1000ページあって、参考文献だけでも50ページ以上あり、実質は900ページくらい。各章の最初で問題の定義を行い、解説があり、章末に大量の練習問題があります。

全体としては大きく4つに別れていて

Introducton Material　離散系のパスプランニングを中心に基本の解説
Motion Planning 連続系やサンプリングベースの軌道の話
Decision-Theoretic Planning 確率を使ったプランニングの話（SLAMとか）
Planning Under Differntial COnstrains 速度の制約などが入るプランニングの話

という構成になっています。

どれも最初に数学から入るので、知っていれば飛ばせるし、知らなければ別の本で勉強してから戻ってくるようにすれば理解が深まると思う。なんでこういう手法が出てきたのかという説明が簡潔に書いてあって助かりました。

確率を使ったプランニングはよく分からなくて、別の本で基礎を固めてからもう一度読み直したい。

KOF2023楽しかった

先週末は関西オープンフォーラムKOFやってましたね。

https://www.k-of.jp/2023/

二日目南港まで行きたかったけど、咳が酷かったのでオンライン参加でした。次回はちゃんと参加したい。

史上初の「ＡＩ倫理」論争を追って

藤田先生のAIの歴史的な話。第二次世界大戦のナチスやベトナム戦争の話もあって面白かったです。

以下、メモ書き。

今のAIの対応は国によって対応が違う。同じように反対に見えても国によって反対の仕方が変わる。日本はノールールなのでいろいろやりやすい。
過去のAIブームも人間の仕事を奪うのかという論争があり、それらを踏まえて今のLLMと向き合わないと行けない。
よく分からない人がわーわー言うのが困るが、Web3.0の時よりマシ。
ビッグデータを使わない技術がでてくると課題をクリアーできる。集合知と機械学習を分離する。
アトムや火の鳥に関しては、元ネタがアメリカにもあり手塚フィルターを通っている。ロボットやAIとの共存は日本固有のアイデアではない。

来年度から大学入試に「情報I」が入ります

元官僚の方の話で、途中からやもやして聞いてました。

最初の方は、大学入試で情報をやるから企業はそれ前提で求人や新人研修をしないといけないとか、入試の内容と情報処理検定は内容を寄せているとかは面白かった。

ただ、高校に求める話になると、大分違うんじゃないかと思いました。例えば、学校によって情報の勉強に差があるから保護者から学校にプレッシャーを変えて欲しいとか、情報の先生が足りていないから自習できるテキストが大事とか。そういう課題を解決するのが官僚の役目では。現場丸投げ意識を感じました。高校の先生が聞いていたら怒りそうだった。

Python 3.12の新機能紹介

こういう話を聞くのが久しぶりだなとテンション上げて聞いてました。

dis Disassembler for Python bytecodeでByte codeの中身が見れる
sys.monitoringでプロファイルが取りやすくなった

この辺の低レイヤー寄りの話が面白かったです。

ホビーロボット最前線2023

今、仕事でロボやってるからこれが一番聞きたかったのですが、ホビーロボット＝役に立たないロボットということで、初手から違ったーって笑ってました。

大阪の飲み屋で隣のグループの話題がめちゃ楽しそうみたいな感じでした。司会者っぽい人の突っ込みとその返しがキレキレで台本無しでやってるならすごいなーと。

大阪って感じでした。

IT男子に送る婚活大作戦！マル秘情報伝授致します! vol.7

こっちも飲み屋ネタっぽい。話術がすごくて勢いで押されたけど、冷静になるとそれってどうなん・・・ってのもある。冷静に聞いてはいけない発表だった。

こっちも大阪って感じでした

ITエンジニアにおすすめのFactorioご紹介

これもよう分からんかった。どう聞いても、このゲーム仕事やん・・・って感想しかなく、仕事じゃないからって言われても、実質仕事やん・・・て感想でした。でも発表している人が楽しそうでうらやましかったです。

時間が無限にあっても足りなそうで、逆に近寄っては駄目そうなゲームでした。

2023-11-03

実践プロパティベーステスト

実践プロパティベーステストをさっと読んでみた。

『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』www.lambdanote.com

この感想を読んでみて、実際のテストのイメージがわかない（だけどテスト全般には興味がある）人は対象読者です。買いましょう。

最初の方を読んでの感想

結局流し読みになってしまったのですが、せっかくなので感想を書きます。流し読みになった理由の一つはWindowsでのErlangの動かし方が分からなかった事。Eralng自体はインストールできたのだけど、最初に出てくるコマンドrebar3から見つからなくて諦めてしまった。もう一つは、意外にも知ってることが多かったから。

プロパティベーステストとは、特定の処理に対して絶対守られるルールをプロパティとして記述し、それに違反しないかどうかをテストする手法です。本書によると「どのような入力値を与えても常に同じであるような振る舞い」をコードとして書くとプロパティになります。ここだけ読むと、静的なテストのように感じますが中身はランダム検証です。

最初の方を読んだ感想。「おつりの合計額は、常に払った金額から請求額を引いた額に等しくなる」というプロパティについて、intで表せるようなプロパティは普通にassert入れれば十分な気がする。Erlangもそうだけど、型に厳しい言語であればコンパイラの型チェック通った時点である程度のチェックは通ってる。少なくともお釣りの金額を期待するところで顧客名のリストが返ってくるようなことはない。そういうのも期待して型も設計しているはず。

もうちょっと抽象的なリストのソートみたいな奴はどうテストするんだろうと思って読んでいくと、同じ関数を別の人が実装すると書いてあって、この辺で半導体の検証手法を思い出しました。

半導体の検証手法

検証手法に関しては、半導体の検証はロジカルな部分だけでもお金が突っ込まれていて実践投入されてます。例えば、Fomalityといった静的検証ツールがあって、大元のソースコードの修正と、別のフェーズで入れるパッチを入れた結果が、論理的に等価ですよねみたいな静的なチェックをやってくれます。

SystemCとかSVA(SystemVerilog Assertion)等、本番の半導体で動く記述よりも抽象度の高い（開発効率が高い）記述で、同じ挙動を別々に書くこと＋ランダム検証で本書のプロパティチェックと同等の事が実施されています。ある条件を満たしてから、2CLK以内にこの状態にならないとエラーのような記述も普通に使います。これはステートに対するプロパティに相当します。ステートのassertionもand, orで簡単に組み合わせて複雑なシーケンスも記述可能になっています。

複雑なステートが入ってくるとそのプロパティが正しいのかどうかも問題になってきて、PCIとかUSB等の規格物については規格にあっているかどうかをチェックする専門家が作ったライブラリ（assertionの塊）が有償で売られてます。これも普通に使われていると思います。

本書でも取り上げられてますが、普通にランダム検証を使うと乱数が偏らないのでエッジケースをつきにくく、制約付きランダムで乱数を偏らせてエッジを狙ったり実動作に近づけたりします。例えばメモリアクセスに必要な時間を正確に見積もることができないので、アクセスのタイミングをランダムにしてシミュレーションするというのはどこでもやってると思います。

プログラマーのためのCPU入門 ― CPUは如何にしてソフトウェアを高速に実行するかwww.lambdanote.com

ラムダノートさんのプログラマーのためのCPU入門にを読むと、最近のCPUがどのタイミングでメモリにアクセスするかを事前に予測する難しさが分かります。

Encode->Decodeの対称プロパティは、僕が関係した画像系のプロジェクトでは非可逆の事が多く使えるケースは無かった気がします。

こう書くと半導体検証は恵まれているような気がしますが辛い話もいっぱいあります・・・

プロパティベースの検証に興味を持ったら、半導体の検証手法を調べてみると面白いです。普通に探すとデバイス（半導体そのもの）の検証やテストが出てくるので、Logic検証とかSystem検証で調べてみると良いです。

プロパティベースの使い道

本を読んでみて、C++で自分のプロジェクトに使えないかなと思ったところです。

Design Patternの実装のチェック

Strategyパターンのような複数の実装を同じように扱うようなライブラリを作ったとき、どの実装が来ても共通の振る舞いをプロパティにしたい。

移植ライブラリの等価チェック

今風の課題ですが、PyTorchの関数と同じ動きを関数をC++で作らないといけないとき、正解値をPyTorchで作って自作の関数を検証する。ただのランダム検証といわれたらそれまでか。

やはり、今の僕には文法や検証の概念よりは上手い使い方が知りたい。特に小さいプロジェクトでも、上手く使ってコスパ良い検証ができる手法を知りたいですね。

この後読みたいのは、n月刊ラムダノートの検証特集かな。大規模検証事例から個人プロジェクトまで。もしくは半導体で使われる検証手法（でソフトウェア設計にも応用が利きそうな物）の特集を、現役引退した半導体検証エンジニアの方々が書いてくれないかなと期待しています。

2023-10-18

コンフィグレーション空間での可動範囲

ロボティクスの勉強、3周目くらいに入ってます。

ロボットを可動範囲内でどう制御するかの話で、xyz空間での制約ではなくコンフィグレーション空間での制約を使う方法があります。

Modern Robotics: Mechanics, Planning, and Controlから

2軸のロボットの場合、姿勢としてθ1とθ2があります。そのθで可動範囲を決めることができれば、その中でpath planningをすれば、障害物にぶつかることなくロボを制御できます。左の図のxyで問題を解かなくても、右側のθ1、θ2で問題を解けばOK。

ロボの制御プログラムとしては、右側で解けるのは非常に魅力的なのですが、じゃ右の図はどうやって作るの？というのがずっと分かりませんでした。

Principles of Robot Motion: Theory, Algorithms, and Implementations に右の図の作り方が載ってました。まず、θ1とθ2が決まれば、ロボの姿勢が一意に決まります。障害物が既知であれば、その姿勢が衝突するかどうかが分かる。後は、θ1、θ2をgridに区切って、全領域でぶつかる、ぶつからないをプロットすれば右の図ができる。なるほど。

柱とか床とか絶対に動かない障害物に対しては有効な気がします。

コンフィグレーション空間からxyz空間の変換って何回か行列かけたり足したりするだけだから、今の姿勢から一定の範囲のコンフィグレーション空間についてGPU使って一気にベクトル演算して、リアルタイムに点群と衝突判定するとかできないのかな。

2023-09-10

ソフトウェア設計のトレードオフと誤り

ソフトウェア設計のトレードオフと誤りを読みました。

www.oreilly.co.jp

業務用のソフトウェアを設計するときに検討すべき事をコードと共に説明してあります。立ち位置が業務用のソフトウェアで一貫しており、SLA（Service Level Agreement）やメンテナンスという言葉が目立ちます。SLA無しではいろんな事決まらないよねというスタンスはあまり他の本ではみないので貴重な本です。

ソースコードはJavaでライブラリ等もJava関係が多くです。Web系の開発メインで書かれていることもあり、僕の仕事とは7割くらいは関係無いのですが残りの3割がとても面白く読めました。

ただ、関係のない7割の部分のように経験していないところはあまり頭に入ってこず、経験しているところはまあそうだよねとなるので、これを読んで一気に視野が広がるかどうかは業務と自分の立ち位置によるかなと思います。人は経験から学ぶことが大半だなと感じました。

仕事する上で関係無いなと思った箇所は、データベースとメモリ、APIの同期非同期、エラー処理、分散システムと一貫性、ネットワークがからむパフォーマンス等です。本来の想定読者はここだと思う。

面白かったところを紹介していきます。

継承とコンポジションのトレードオフ

本の最初にGoFのデザインパターンが出てきたのが30年前という話から入り、デザインパターンがの整理が始まります。その中で継承とコンポジションのトレードオフについても説明があります。Javaのソースコードを例に課題と解決策が紹介されていて、その瞬間の課題が解決できるかどうかよりも、間違った継承を使う事で一般化されたクラスがそうでなくなったり、継承をした目的からずれているぞといった指摘があります。筆者の立ち位置がこれからメンテし続けるコードだぞって所が面白いです。

僕は継承とコンポジションだとコンポジションの方が良いと思っていて、「継承のために設計し、文書化する。そうでなければ継承を禁止する」の言葉通り、継承して使われるなら最初からそう設計すべきだと思う派です。（C++限定で。Pythonだと雑に継承する）

日付

ここは仕事と関係無いところだったが読み物として面白かったです。いくつか紹介

国内に置いて年齢の解釈は法律で決まっているが、道路交通法は別の解釈をしている
2035年以降100年はうるう秒が廃止される
日付を扱うアプリケーションのチェックリストの最初が「あなたのアプリケーションは相対性理論を扱う必要がありますか？」
1月31日に一ヶ月を足して一ヶ月を引いたとき、1月31日に戻るライブラリは無い

Version管理

適当につけがちなバージョン番号にちゃんと意味を持たせる話が良かった。1.12.3-betaみたいな表記のそれぞれと、互換性との関係を文章化できていて、これは早速仕事に導入したい。初めて聞く話では無いんですが、自社のバージョン管理で悩んでいるとよく考えられているなと感じました。

シリアライズ

ここは仕事ではまりかけたところ。C++の列挙体をそのままシリアライズすると、列挙体が変わった時お手上げになる。面倒でも文字列にした方が良い。これと同じ事をProtcol Buffersを使って説明してあります。後から追加になっても、互換性を保つための工夫も書いてありました。

ただ、こういうのは一回はまると気がつくけど、はまる前にこういう本で知るのは難しいと思うんだ・・・。

API

ユーザーに公開するAPIについても、結構多くの所で説明されています。APIを内部の関数を外向けに公開します程度に考えてしまってぐだぐだになることがありますが、APIはそのアプリケーションの顔なので専門家がレビューすべきだと思う。

僕はAPIを「サービスを提供する起点だけでなくプロダクトをメンテする起点」と考えています。APIを変えずにどう中身をよくしていくか、またAPIを返るとしたらどういう戦略で変えていくのかそういう観点からの説明が多くあり、考え方は間違って無くてもっと良いAPIはどうあるべきを考えないといけないなと思いました。

アプリの設定（付録A）

アプリの設定をどうするかのトレードオフについてのまとめ。付録だけど良くまとまってました。

ソースコードに入れてコンパイル
コマンドライン引数
環境変数
設定ファイル

等など。

ぱたへね

はてなダイアリーはrustの色分けができないのでこっちに来た

2023年読んで良かった本

High Output Management

プログラマのためのCPU入門

エンジニアのためのドキュメントライティング

離散数学入門

ロボット

Raspberry Piでバーコードリーダーを作る

ハードウェア

設定

ソースコード