ロボットとの通信の見直し

[HansRobo]

背景

ロボットの制御周りの基礎ができてきて、ロボットへのコマンド・ロボットからのフィードバックの送信周期を高めて性能向上を狙えるようになってきた

内容

今までは、制御方法によって少しずつ内容をスイッチングしてはいるものの、一つのパケットにすべてのコマンド・フィードバック情報を詰め込んでいた。
しかし、今後の送信周期の向上を考えると最低限低周期でも良いもの・高周期にしたいものの区別をして送り分けたい

関連：https://github.com/orgs/ibis-ssl/discussions/372

参考

現状のコマンドパケット

typedef struct
{
  uint8_t header;
  uint8_t check_counter;

  float vision_global_pos[2];
  float vision_global_theta;
  bool is_vision_available;
  float target_global_theta;
  float kick_power;
  float dribble_power;
  bool enable_chip;
  bool lift_dribbler;
  bool stop_emergency;
  float acceleration_limit;
  float linear_velocity_limit;
  float angular_velocity_limit;
  uint16_t latency_time_ms;
  bool prioritize_move;
  bool prioritize_accurate_acceleration;
  uint16_t elapsed_time_ms_since_last_vision;
  ControlMode control_mode;

  union {
    LocalCameraModeArgs local_camera;
    PositionTargetModeArgs position;
    SimpleVelocityTargetModeArgs simple_velocity;
    PolarVelocityModeArgs polar_velocity;
  } mode_args;
} RobotCommandV2;

[HansRobo]

現状のコマンドの再構成

ここでは

• 低周期：10Hz
• 中周期：30~60Hz
• 高周期：できるだけ高い周期を目指したい。100Hz~

くらいのイメージ

メンバー名	タイプ	コメント
header	uint8	絶対必要
check_counter	uint8	絶対必要
vision_global_pos	float[2]	低・中周期
vision_global_theta	float	低・中周期
is_vision_available	bool	低・中周期
target_global_theta	float	低・中周期
kick_power	float	低・中周期
dribble_power	float	低・中周期
enable_chip	bool	低周期
lift_dribbler	bool	低周期
stop_emergency	bool	低周期
acceleration_limit	float	低・中周期
linear_velocity_limit	float	低・中周期
angular_velocity_limit	float	低・中周期
latency_time_ms	uint16	起動時のみでもOK
prioritize_move	bool	低周期・使ってたっけ？
prioritize_accurate_acceleration	bool	低周期・使ってたっけ？
elapsed_time_ms_since_last_vision	uint16	低・中周期
control_mode	uint8	必ず必要

[HansRobo]

control_mode_argsの中身以外は現状必須メンバーになってしまっているのでいくつかにグループ分けしてcontrol_mode_argsの中に収めたい。（control_mode_argsの名前はおいおい改名するとして）

• vision系グループ
  • vision_global_pos
  • vision_global_theta
  • is_vision_available
• キッカー・ドリブラ系
  • kick_power
  • dribble_power
  • enable_chip
  • lift_dribbler
• 制御補助系
  • stop_emergency
  • acceleration_limit
  • linear_velocity_limit
  • angular_velocity_limit
  • latency_time_ms
  • prioritize_move
  • prioritize_accurate_acceleration
  • elapsed_time_ms_since_last_vision

[HansRobo]

そもそも気にしなくて良い説

UDPパケットはIPヘッダ20バイト＋UDPヘッダ8バイト=28バイトあるので、分割してパケット数増やしたほうがよくなさそうだし、
そもそも気にするほどの帯域に達しないのでは

現状の計算（AI->ロボット）

条件

• ロボット台数：6台
• コマンドパケットサイズ：64byte
• 送信周期：60Hz

UDPパケットサイズ

ヘッダ28byte + コマンドパケットサイズ64byte = 92byte

1秒あたりのパケット数

ロボット6台 × 周期60Hz = 360

帯域

92byte × 360 = 33120[ byte/second]

ビットに直して、
33120 * 8 = 264960 [bps]
つまり、265 kbps

将来の計算（AI->ロボット）

• ロボット台数：12台
• 送信周期：120Hz
• 送信周期（野心的）：240Hz

帯域

台数2倍、周期2倍なので、単純に4倍になる

33120 * 4 = 132480 [byte/second]

132480 * 8 = 1059840[bit/second]

つまり、ようやく1 Mbpsに到達する。

さらに野心的な240Hzにした場合は2倍の2 Mbps

現状の計算（ロボット->AI）

パケットサイズ

UART時点では内容自体は128byte
https://github.com/ibis-ssl/G474_Orion_main/blob/main/Core/Src/ai_comm.c#L28C18-L28C21

ここにUDPのヘッダ28byteがのって、156byte

帯域

パケットサイズ：156byte
ロボット台数：6台
送信周期：50Hz
https://github.com/ibis-ssl/G474_Orion_main/blob/main/Core/Inc/management.h#L75

156 * 6 * 50 = 46800 [byte/second]
46800 * 8 = 374400[bit/second]

つまり、374.4 Kbps

将来の計算（ロボット->AI）

帯域

パケットサイズ：156byte
ロボット台数：12台
送信周期：120Hz
送信周期(野心的)：240Hz

台数2倍、周期2.4倍で4.8倍

374.4 * 4.8 = 1797.12 [Kbps] = 1.79712 [Mbps]

となり、約1.8 Mbps

野心的な240Hz送信では2倍となり3.6 Mbpsである

結論

将来の想定でも、

AI送信：1.1 Mbps
ロボット送信：1.8 Mbps

なのでWiFiルーターで扱うUDPではあまり気にすることはない気がする。
野心的な周期設定でも、2倍にして上下合わせても5.8 Mbpsと数Mbpsの範疇に収まる。
これは世間ではかなり通信が悪い扱いになる区分なので、流石にそれ以上の通信品質は期待してよいだろう。

ただし、ロボット送信分はマルチキャストなので実際の負荷はもっと大きいものになるかもしれない。

ボトルネックはやはりCM4とマイコン間通信になりそう