Name each X500 instance once and put its topics and frames under it

[caguero]

This patch brings the X500 up to the line the Blue Robotics vehicles reached in HonuRobotics/bluerobotics_models#59 and HonuRobotics/bluerobotics_models#62: Sections 2 to 5 (Names and poses in Gazebo, Topics on both sides, ROS graph, TF frames) of the multi vehicle support plan (HonuRobotics/gz-maritime#28, HonuRobotics/gz-maritime#23).

One name per instance drives everything. configure_vehicle.py gets a --name option that writes a derived config and regenerates every artifact from it, refusing a name that cannot be a ROS name. The model is named after its topic namespace. Per part topic overrides go under the namespace unless they start with a slash, so two instances from one config never share a topic. Joint states are bridged as /<name>/joint_states and the sensors publish frame ids under the name, which is what TF has once robot_state_publisher prefixes the frames. The launch takes the full pose (x, y, z, roll, pitch, yaw), spawns under the name, and runs the state publisher with that prefix.

Tests cover the name in every artifact, per instance cache directories, two instances sharing no topic, refused names, the override rule and prefixed frames on TF. Docs: a launch argument table and a "Several vehicles" section.

How to test

colcon build --merge-install --packages-select x500_description x500_gazebo
colcon test --merge-install --packages-select x500_gazebo

The X500's own launch with a name and a pose:

ros2 launch x500_gazebo sim.launch.xml name:=uav_b x:=2 yaw:=1.57
gz model -m uav_b -p
ros2 topic list | grep uav_b
ros2 topic echo /uav_b/imu --once | grep frame_id

Two quads in one world through gz-maritime lyrical, on the X500 ground world so they have somewhere to land:

ros2 launch kai_bringup simulation.launch.xml world:=$(ros2 pkg prefix --share x500_gazebo)/worlds/x500_ground.sdf

then, one terminal each:

x500="$(ros2 pkg prefix x500_gazebo)/lib/x500_gazebo/configure_vehicle.py --config $(ros2 pkg prefix --share x500_description)/config/x500.yaml"
ros2 launch kai_bringup spawn_vehicle.launch.xml name:=uav_a y:=2 z:=0.25 generator:="$x500"
ros2 launch kai_bringup spawn_vehicle.launch.xml name:=uav_b y:=-2 z:=0.25 generator:="$x500"

Expected: every topic of each quad under its name on both sides, including /uav_a/joint_states and the motor bus /uav_a/command/motor_speed on the Gazebo side, a bridge and a state publisher per quad in its namespace, IMU messages in frame uav_a/base_link, and one /clock publisher.

Confirm it in RViz

rviz2 --ros-args -p use_sim_time:=true

Set the Fixed Frame to uav_a/base_link and add a RobotModel display with Description Topic /uav_a/robot_description and TF Prefix uav_a. The quad draws with its frames prefixed. The rotors only turn when something publishes on the motor bus, so expect a still model. The TF display warns about uav_b frames because nothing links the two quads to a common frame; that is expected.

[ahcorde]

Non blocking comments:

• extra_bridge_topics are shared between instances — appended verbatim (generate_bridge_config.py:134), so two instances of one config collide there. The sibling docs call this out; the new "Several vehicles" section doesn't.
• actuators.md:29 still presents /x500/command/motor_speed as a fixed string. sensors.md got a "rename the instance and the topic follows" paragraph; actuators didn't, though the motor bus follows the instance name. (Same gap in bluerobotics, so fix both or neither.)
• sim.launch.xml silently overrides a custom config's topic_namespace — it always passes --name $(var name) with default x500, so config_file:=custom.yaml with topic_namespace: foo yields x500. The doc line "By default the name is the config's topic_namespace, x500" holds only for the shipped config. Same in bluerobotics, so presumably intentional (launch arg is authoritative) — the sentence could just say so.