New frame format and interface

[sktometometo]

euslisp/jskeus#635
を受けての検討

[sktometometo]

パケットがどういうものであるかの説明の仕方には何があるか？

v0.0.2 でのやり方では、先頭の2byteを、フレームの構造を示す識別子としてもパケット説明としても使っていた。

他にはテキストで表記するとかもある？これはパースの仕方を知らない場合にどうパースするかでLLMに突っ込めるので以下のようなやりかたができる

The usecase of this packet is acceleralometer
DataField of this is 3.24 0.1 3.3

Parsed result of this data as float vector with 3 length is 

で text-davinci-003 で [3.24, 0.1, 3.3] が補完される。

[sktometometo]

The usecase of this packet is "emergency call with frame and x y z pos and x y z w quat information"
DataField of this is [73b2_front, 0.1, 1.0, 0, 0, 0, 0, 1.0 ]

I have recieved this packet from somewhere. It means  that the sender has issued an emergency call and is providing a frame, X Y Z position, and X Y Z W quaternion information.

So what I should do is

1. Analyze the data field given in the packet to ascertain what type of emergency it is.
2. Use the frame, position and quaternion information to determine the location of the sender.
3. Respond to the emergency call as appropriate.

[sktometometo]

I have received a packet from some smart device or robot.

The usecase of this packet is "emergency call with frame and x y z pos and x y z w quat information"
DataField of this is [73b2_front, 0.1, 1.0, 0, 0, 0, 0, 1.0 ]

This packet means  that the sender has issued an emergency call and is providing a frame, X Y Z position, and X Y Z W quaternion information.

So what I should do now is that 

I should analyse the data, using the frame, position and quaternion data to properly identify the location where the sender is located. With this information, I can better understand the situation and take appropriate action.

[sktometometo]

I am a Spot robot named BelKa. I can walk, see and fetch, manipulate.
I have several capabilities below

1. Move to specified location
2. Grasp object
3. Greeting to person
4. Take a photo and send it via e-mail

I have received a packet from some smart device or robot.

The usecase of this packet is "emergency call with frame and x y z pos and x y z w quat information"
DataField of this is [73b2_front, 0.1, 1.0, 0, 0, 0, 0, 1.0 ]

This packet means  that the sender has issued an emergency call and is providing a frame, X Y Z position, and X Y Z W quaternion information.

So what I should do now is that  I should process the packet immediately and act according to the instructions given. I will use the frame, position, and quaternion information to locate its sender, then I will move to the specified location and take appropriate actions to help the sender.

To do this, what I can do first from my capabilities is that move to the location specified by the data packet. Secondly, I can take pictures or videos of the sender and their surroundings and send it via email if necessary, as additional information. Finally, I can also greet the sender to make them feel comfortable and relaxed.

[sktometometo]

短くしたいので短くしてもらった

emergency call with frame and x y z pos and x y z w quat information

When rewirte this sentence to less than 64 characters, answer is

Emergency call w/frm & XYZ pos & XYZW quat.

[sktometometo]

これでパースしようとしてみると

I have received a packet from some smart device or robot.

The usecase of this packet is "Emergency call w/frm & XYZ pos & XYZW quat."
DataField of this is [73b2_front, 0.1, 1.0, 0, 0, 0, 0, 1.0 ]

Parsed result of this data as "header.frame_id" is: 

73b2_front 

The "0.1, 1.0, 0, 0, 0, 0, 1.0" indicates position (XYZ) and orientation (XYZW) of the smart device/robot that sent this packet. The data represents the x-position (0.1), y-position (1.0), x-orientation (0), y-orientation (0), z-orientation (0), w-orientation (1.0) of the device/robot. This data is sent as part of an emergency call, suggesting that the device/robot requires assistance and is providing its current position and orientation within this packet.

[sktometometo]

ROSの世界でのIDLはやはり ROS Message.

ただ、ESP_NOWの通信の仕方をROSにもってくるとちょっとそのままでは通信の仕方が合わないことがありそう？

[sktometometo]

この受け取り方・送り方は通常のROSとは異なるが....

1. 各ノードがこの受け取り方・送り方をできるようなラッパープログラムを書く。
2. 通常のROSの通信方式でのやり方でどうなるかを考える。

1だとすると、今の ESPNOWROSInterface のアプローチ、このやり方はパースを各ノードで行う必要があることだった。

2だとすると、あらかじめトピックをいくつか決めておいてその中でどうするかを決める話になる？
ブリッジ プログラムを立ち上げた段階でこういうESP-NOWパケットとROSのこのトピック+rosmsgとを相互に変換するということを決めておいて、これに対応するものを相互に送り合うみたいな

例えば、

[sktometometo]

変換の仕方は以前にLLMを使う方法について議論したけど、予め変換方法をハードコーディングして対応しておく方法もある? => 結局今の方法じゃん

[sktometometo]

LLM によって解決された問題は何?
これを使わないとすると、各ノードではプリミティブの並んだリストとしてのパケットを得ることになる?

このリストをどう使うかは任される形?

[sktometometo]

ROS側でのインターフェースは、

• 完全にROSのインターフェースに統一する (ESP-NOW上でのイベントはすべて何等かのトピックでのROSメッセージに返還される)
• 各ノードがESP_NOWをラップしたインターフェースを有する (今の形式 か 、各ノードではプリミティブの並んだリストとしてのパケットを得ることになる? か)

[sktometometo]

前者の方法をとるとすると、問題になるのは

1. ESP-NOW -> ROS通信 の変換方法
2. ROS通信 -> ESP-NOW通信 の変換方法

1の方法は、ブリッジノードに変換ポリシーというかルーティングテーブルというかみたいなものを用意しておく？

ESP-NOWの通信の構成要素は

• 送信元のアドレス
• データ
  • 説明子
  • データのシリアライズ形式の説明
  • データ本体
• 送信の仕方(P2Pかブロードキャストか)と宛先

ROSの通信の構成要素は

• トピック名
• トピックの型
• (publisher)
• メッセージ
• (subscriber)

ある説明子のメッセージがどのトピック名・型に対応するかは自明でない？
対応関係は人が定義するのか、自立でそれっぽいものを選ばせるのか
メッセージの内容はESP-NOWの内容と一対一に対応する？送信元の情報はそのままだと抜け落ちる

対応関係の定義方法案

a. 人は説明子がどのメッセージ型とトピック名に対応するかと、シリアライズ形式から特定のROSメッセージ型へどう変換するかを定義
b. 人は説明子がどのメッセージ型に対応するかと、シリアライズ形式(+説明子)から特定のROSメッセージ型へどう変換するかを定義、トピック名は /ブリッジノード/<説明子から生成されるsnake_case文字列>
c. 人は説明子がどのトピック名に対応するかと、シリアライズ形式(+説明子)から特定のROSメッセージ型へどう変換するかを定義、サポートする型がないか、トピックがあらかじめ存在しない場合は未定義？

[sktometometo]

シリアライズ形式をメッセージに埋め込む方法?

使うべき基本データ型は？

[sktometometo]

https://github.com/sktometometo/esp_now_ros/tree/v0.2.0 で使っているのは

• uint16
• int32
• uint32
• uint64
• float32
• string (16 bytes, 64bytes, any)

String だとすると長さの情報も必要? そうすると長さ情報は可変になりそう。長さに最大があるから固定にもできるか？
シリアライズ形式を表現する部分は可変長であるべきか固定長で十分か?

データ領域のうちのあるバイトがint, float, string, none の4つのうちのどれに入るかは 2bit で表現できる。
=> 250 bytes の各バイト は 500 bit あれば全部表現できる? 並んでいる長さで 精度を含めて表現?
=> 500 bit = 62.5 bytes それにつかうのはもったいない。かつ float が並んでるケースとかを表現できない(間にnoneを1bit挟めば表現できるが...)
精度は何通りもないからそんなに表現する必要なさそう

[sktometometo]

一つの形を表現するのに1bytes = 256通りはちょっともったいないような....

よくある表現方法は?

• c = char = int8
• s = short = int16
• i = int = int32
• l = long = int64
• f = float = 32bit float
• d = double = 64bit float

これにプラスしてstringであることと長さを示したい...

[sktometometo]

参考: struct の書式指定文字: https://docs.python.org/ja/3/library/struct.html#format-characters

unsigned もカバーしているので使える?

sは数値を入れて解釈するようにしているが、何種類かの長さだけ用意するなら

• s = 32 bytes
• S = 64 bytes
  とかでいいかも?

[sktometometo]

シリアライズ形式指定文字一覧 (ドラフト案)

バイトオーダーはLSB first

フォーマット	CでのType	意味
x	パディングバイト	値なし
c	char	長さ 1 のバイト列
b	int8	1バイトの符号付き整数
B	uint8	1バイトの符号なし整数
?	_Bool	1バイトの真偽値型(bool)
h	int16	2バイトの符号付き整数
H	uint16	2バイトの符号なし整数
i	int32	4バイトの符号付き整数
I	uint32	4バイトの符号なし整数
l	int64	8バイトの符号付き整数
L	uint64	8バイトの符号なし整数
f	float	4バイトの浮動小数点数
d	double	8バイトの浮動小数点数
s	char[]	16 bytesの文字列
p	char[]	32 bytesの文字列
S	char[]	64 bytesの文字列
P	char[]	128 bytesの文字列

[sktometometo]

フレーム構造案 (packet descriptor が自然言語の場合)

packet description text	format characters for data body	data body
64 bytes	10 bytes	rest ( ~ 176 bytes)