[FEATURE] Robonix and Its Interface: A Rust and ROS2 approach

[enkerewpo]

I'm experimenting writing the cap/skill/task concept of Robonix in Rust(https://github.com/Atostek/ros2-client), along with interface definitions derived from the ROS2 ecosystem: topics, actions and services.

Some reason for using Rust:

1. To achieve performance, memory safety and multithread ability. Python cannot handle these well.
2. Python dev dependency management and Python project depolyment are being somewhat hassle. Binary distribution as an OS is difficult.

Proposals:

1. Robonix uses ROS2 IDL for data definition. see https://github.com/ros2/rosidl and https://github.com/ros2-rust/ros2_rust/blob/main/docs/message-generation.md
2. Robonix uses the ROS topic/action/service abstraction to provide interfaces: e.g. /rbnx/sys/register_cap (service)
3. Nav2 and MoveIt2 are Robonix "skills", and we should find a way for them to use Robonix Sensing Abstraction and Robonix Controlling Abstraction.

some beginning drafts (cap definition e.g.):

capability_id: lidar
model_type: env.perception.lidar
provided_topics:
  - /lidar/lidar_front/scan # from driver and SDK code
frame_id: base_link
rate: 10.0

and since nav2 and moveit2 uses some config files to specify its input and output topics, Robonix should provide the abstraction:

1. we have two lidar(1 and 2) that provide the above lidar cap, and Robonix choose lidar1 for some skill instance that runs Nav2 to use
2. Robonix first collect data and process it in Sensing Module, and provide some abstract topic like /rbnx/virtual/scan under some exclusive ROS DOMAIN (for isolation) and write it into Nav2 config
3. we boot the Nav2 Skill instance according to some skill specification (like it requires the "lidar" cap), and since we already provided the virtual topic and added it the the Nav2 config, then Nav2 should work as expected, without attaching to specific lidar SDK (/lidar/lidar_front/scan)

[enkerewpo]

@lhw2002426 @ken4647 @KouweiLee