BlueBoat: assemble the chassis and props from the PR #83 Blender scene

[bsb808]

Overview

This PR modifies the URDF xacro assemble. Key parts of the work are

• De-scoped the Blue Boat assembly to just the chassis and two props for reasons already discussed. I added the ping sensor (without the bracket) and the IMU back in as functional sensors, but without th evisuals.
• Once Rslee/blueboat source assembly #83 is merged, this will use the new gltf-robotics compliant glb files
• All parts use their native coordinate systems (blender -> gltf -> {Gazebo, RVIZ} )
  • Applies the axes conventions from gltf-robotics coordinate orientation walkthrough
• Uses the Blender assembly from the artist to deterimine the assembly.
• Changed names of slots from motor_* to prop_*. The parts are propellers - the motors are in the hull. And this is consistent with the part names.
• Visual orientation in gz sim and RVIZ. Applies the coordinate conventions from gltf-robotics
• Slot joint axis: the scene mounts each prop with a 180° yaw, which points the prop's own +x, its spin axis 1 0 0, aft. Technically, we may want to have Ryan flip the axis of the prop models, but I'd like to leave that for future work.
• Updated docs to be consistent with the changes.
• worlds/parts_check.sdf regenerated; it was already stale before this branch. This is partially vestigial, but worth keeping around.
• This also clears the CI flag that was introduced when force merging Rslee/blueboat source assembly #83

Assembly geometry from Blender scene

Because this is not evident from the repo, here is how the offsets in blueboat_chassis.urdf.xacro, I added comments to the file on where the offsets came from.

Basically,

1. Ryan provided the .blend file for the assembly (boat and two props)
2. Exported via blender - the full assembly
3. Used gltf-summary from gltf-robotics extract the node transforms
4. Those offsets were then used in blueboat_chassis.urdf.xacro to position the parts relative to the chassis

This worked well, but isn't captured in the PR.

Tests

IMHO, main has/had quite a bit of test bloat. It appears that the tests were generated based on the one configuration with no affordance for the user configuation to change. So any change to the config, requries a change to the tests. Anything other that the full default blueboat config failed dozens of tests.

Looks like tests were written against the one vehicle the repo shipped and it captured that vehicle faithfully. Now that the configuration is meant to change, some of those tests were checking the example rather than the rules behind it. The changes, all in the three BlueBoat test files:

I supervised CC in modifying the tests:

• Removed: two tests and one assertion whose subject was the contents of the shipped config. The config is mutable, not static.
• Given their own vehicle: about a dozen tests whose subject is a rule (thrusters follow the propeller parts, sensor frames resolve in TF, ArduPilot channels follow topic overrides, slots chain through their parent part, the bridge and the model agree) built their vehicle by reading the shipped config, swapping its parts: or editing its text. They now build it from a fixture (make_config() / kit_config(): the shipped hull and namespace with slot_defaults: true), so the shipped config can change.
• Widened: the Ping below waterline check now runs on the kit and on the shipped config whenever it fits a Ping; the two visual rotation checks accept both the earlier and the profile glTF conventions.

Result: all 198 (!!) remaining tests pass across bluerobotics_parts, both BlueBoat packages, bluerobotics_teleop and both BlueROV2 packages, launch tests included.

For the reviewer: please verify visually

These checks are visual and require human judgement.

Follow the /bluerobotics_models/docs/vehicles/blueboat/running.md instructions. I added some images of the coordinate systems.

• Check assembly in both Gazebo and RVIZ
• The base_link frame is consistent with ISO 9787 / ROS REP 103 (x forward, y left, z up) relative to the chassis geometry in both Gazebo and RVIZ. I added example images to src/bluerobotics_models/docs/vehicles/blueboat/running.md.
• Check the details of the assembly - that the props are mounted in the correct location and orientation.
• Thrust direction. Publish data: 0.3 on /blueboat/prop_port/cmd and /blueboat/prop_stbd/cmd: the boat moves toward +X (measured at about 2 m/s). The reason to test this is the flip in axis noted above.

Known and open

• BlueROV2's tests use the same two patterns (snapshots of the shipped default, fixtures built from the shipped file). The tests currently pass, but will likely need to be modified when we re-configure the ROV.