バイト列の扱い方について

[sktometometo]

euslisp で Python3 の bytes 型のようにバイト列を扱う場合、どのような表現方法があるでしょうか?

また、バイト列をパースして数値や文字列へパースしたり、また数値や文字列をバイト列へエンコードする際に、Pythonでのstructモジュールに当たるようなユーティリティ関数やライブラリがあれば使いたいです。

[sktometometo]

数値のlistとしてのバイト列表現 <-> 文字列 の変換としては以下のようにかける

$ (coerce "あいう" cons)
(227 129 130 227 129 132 227 129 134)
$ (coerce '(227 129 130 227 129 132 227 129 134) string)
"あいう"

[sktometometo]

文字列のバイト列が所定の長さになるように0パディングするには以下のようにかける

4.irteusgl$ (setq byte-array (coerce "あいう" cons))
(227 129 130 227 129 132 227 129 134)
5.irteusgl$ (setq target-length 64)
64
6.irteusgl$ (concatenate cons byte-array (make-list (- target-length (length byte-array)) :initial-element 0))
(227 129 130 227 129 132 227 129 134 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)

[sktometometo]

rosのmessage型でuint8[]に渡す場合、stringで渡すようになっている。
たとえば audio_common_msgs/AudioData のような場合、 data フィールドは string で渡されるし、msg を作るときに cons でなくて string で渡さないと適切にパースされなさそう。

[sktometometo]

@k-okada Is there any files related to byte array parsing and generating? If so, I would like to add some utility functions to there like

(defun padding-byte-array (byte-array target-length)
  (concatenate cons byte-array (make-list (- target-length (length byte-array)) :initial-element 0)))

according to the review in jsk-ros-pkg/jsk_robot#1830

[k-okada]

最初のコメントしか見ていないけど，こういうこと？

$ setq s "    "
"    "
$ setq b 12.34
12.34
$ (sys::poke b s 0 :float)
12.34
$ (dotimes (i (length s) (format t "~%")) (format t "~x" (elt s i)))
a4704541

use https://www.scadacore.com/tools/programming-calculators/online-hex-converter/ to convert hex to float

[sktometometo]

そんな感じのことがしたいのですが、バイト列をパースする際にバイトオーダー(LSBかMSBか)やsigned or unsigned, 精度等を指定してパースをしたいと考えていて、かつこのようなバイト列と数値との変換はeuslispの数値表現とは必ずしも一致しないために何らかのパース処理が必要かと考えています。

バイナリデータの読み込みを行う際にはファイルからにせよ他のプロセスからにせよこのような類の処理が必要になるのでなにかしらすでに実装されていればその部分の処理を利用したり、追加・変更したいと思っていて、既存のeuslispにはそのようなライブラリが存在するでしょうか？

あと、この例における 12.34 のバイト列表現である "\244" はjmanual の 二章に以下にあるバイトにおける表現という理解で正しいですか?

他の Lisp と同様に、型の決まったデータオブジェクトは変数ではない。どの変数もその値として、どんなオ
ブジェクトも持つことができる。変数にオブジェクトの型を宣言することが可能であるが、一般的にコンパイ
ラで高速なコードを生成するための情報としてのみ使用される。数値は、ポインタの中で直接値として表現さ
れ、そのほかは、ポインタにより参照されるオブジェクトにより表現される。 Sun4 で実行する場合、ポイン
タおよび数値は図 2 で描かれているように long word で表現される。ポインタの LSB の 2 ビットは、ポイン
タ・ integer ・ float を識別するための tag ビットとして使用されている。ポインタは tag ビットが全てゼロであ
り、オブジェクトのアドレスとして 32 ビット全て使用できるので、 EusLisp は 4GB 以上のアドレス空間を利
用することができる

[k-okada]

% ２個上の例題間違えていたので直しました．
これは，
https://github.com/euslisp/EusLisp/blob/9b1a896af3dad4a245d97d745130939ca2814f6b/lisp/c/sysfunc.c#L642-L676
なので，普通にCPU上のバイト列なんだとおもいます．jmanual の記述はC言語内でLispオブジェクトの表現の説明なので，CPU上のバイト列とは違うのかな．

で，peek/poke は結局eusの型でしか出てこないので，float/double やbyte/int/long は対応できるけど，singned / unsigned は対応出来なそうですね．またバイトオーダもCPU依存になりそう．

とは言え，バイトオーダはLSBでsigned で，と運用する（少なくともeusが絡む場合は）としちゃえば，問題ないんじゃない．と思うのと，このパースするための情報はどうやって渡すの？別途２つのシステム間でフォーマット情報を受け渡しするの？

[sktometometo]

これは，
https://github.com/euslisp/EusLisp/blob/9b1a896af3dad4a245d97d745130939ca2814f6b/lisp/c/sysfunc.c#L642-L676
なので，普通にCPU上のバイト列なんだとおもいます．jmanual の記述はC言語内でLispオブジェクトの表現の説明なので，CPU上のバイト列とは違うのかな．

なるほど、理解しました。smart_device_ros (まだ名前変えてない) で絡むマシンは ESP32 も x86_64 も LSBっぽいので結局そのままでいいかもです。

パース情報はこのリポジトリでは C用、Python用で パーサ/シリアライザ を個別に書いています。十分にながければStringでJSONみたいなやつ渡してしまいたいのですが組み込み側で簡単なふうに処理を書いてしまいました。

[k-okada]

ちなみにrosserial はどうしているのかな。

…

-- ◉ Kei Okada 2023年6月28日(水) 9:30 Koki Shinjo ***@***.***>:

これは， https://github.com/euslisp/EusLisp/blob/9b1a896af3dad4a245d97d745130939ca2814f6b/lisp/c/sysfunc.c#L642-L676 なので，普通にCPU上のバイト列なんだとおもいます．jmanual の記述はC言語内でLispオブジェクトの表現の説明なので，CPU上のバイト列とは違うのかな． なるほど、理解しました。smart_device_ros (まだ名前変えてない) <https://github.com/sktometometo/esp_now_ros> で絡むマシンは ESP32 も x86_64 も LSBっぽいので結局そのままでいいかもです。 パース情報はこのリポジトリでは C用、Python用で パーサ/シリアライザ を個別に書いています。十分にながければStringでJSONみたいなやつ渡してしまいたいのですが組み込み側で簡単なふうに処理を書いてしまいました。 — Reply to this email directly, view it on GitHub <#635 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADYNXFNJXHD63DWGXXPLXLXNN3IPANCNFSM6AAAAAAZU54WKY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sktometometo]

ここでは ros-drivers/rosserial#569 は使用していないです。ESP32は本体と優先で接続して、ESP32が他のデバイスと無線通信するインターフェースになっているので、

イメージ的には

PC -- USB -- ESP32 interface デバイス (このスケッチ を書き込んだM5Stack) .... ESP_NOW ... ESP32 other device

みたいな接続になっています。

[k-okada]

あ，そこではなくて，rosserial はマイコンとPCの間の通信はどうしているか？ということでした．
https://github.com/ros-drivers/rosserial/blob/noetic-devel/rosserial_client/src/rosserial_client/make_library.py
とかみると，ROSのシリアライズを行っているね．

手書きでパーサを書いてよいのは，基本は送られるデータ型が決まっている場合で，それ以外は使わないで運用してください．という場合が良いです．手書きでバーサを書くけど仕様を決めてあるので後はユーザで任意のデータの送受信をしてください，は結局使われないです．
なので，ROSのメッセージなりJsonなりで書いておくのが良いです．

あるいは，std_msgs だけは対応します，とか，自分で簡易的なフォーマット決めて最大4個のリストで，ネストは許さなくて，文字列は255固定，とか，で，"isfd"+binary(123)+string("hello")+binary(123.4)+binary(24555.4544) みたいなストリングを送るとか，

と思ったけど，使っているのは
https://github.com/sktometometo/esp_now_ros/blob/c0807250bfb6671aa8d5045378820ea451a5c7dc/python/esp_now_ros/packet_parser.py
なのかな．ここでパースしていれば，eusとepsの通信はrosのメッセージ経由でbinaryをパースする必要はないのでは．

ちなみに，こういう風にパケットのデザインをしている場合はちゃんとその情報をhttps://tldp.org/LDP/tlk/net/net.html みたいに図解しておきましょう．

[sktometometo]

JSONか所定のフォーマットを前に記述するやり方でやってみます。
以下はESP_NOWのフレームを説明する図なのですが（公式ページ をもとに作成）、bodyの先頭2bitを https://github.com/sktometometo/esp_now_ros/blob/master/msg/Packet.msg で定義されたパケットタイプにしていて、その後のbitをどうパースするかはREADME.mdに記述したフレームの定義にしたがってパーサ/シリアライザを実装していました。

データフィールドの並びだけでなく、そのパケットが何用途向けなのかがわからないと、float x 3 の並びのセンサデータがセンサの認識したオブジェクトの位置なのか、加速度センサの出力した三軸加速度なのかがわからなくて、パケットのデータが何であるかを説明するフィールドそのものは必要かと思うので、そうなるとフレームの構成としては

| パケットの説明を示すフィールド | データ部分の構造を示すフィールド | データ部分 |

のような構成にしてみようと思います。

[sktometometo]

ただ、シリアライザやパーサの実装そのものは共通化できる一方で、パース後のデータを利用するプログラムは自分の使いたいパケットの説明に対応したパース後のデータ構造を知っている必要がある気がしていて、それは結局README.mdに今記述しているフレームの構造そのものではないかと思いました。

そう考えるとフレームのうちデータフィールドの構造を記述している部分は冗長で、その結果いまのような形をとっている部分はありました。

フレームの説明とパース結果のなんとなくのデータから自分が使いたいデータ形式への一般的な変換方法があれば、プログラム側で詳細なデータ構造について知っている必要はないのかな