zerodds-spatial-ros2
DDS profiles and add-ons. Semantic mapping between the SpatialDDS profile types of
zerodds-spatial-ddsand ROS 2 common-interfaces messages.
- Source: crates/spatial-ros2
- API docs: docs.rs/zerodds-spatial-ros2
zerodds-spatial-ros2 converts SpatialDDS values to ROS 2 messages and back.
The ROS 2 message types are generated at build time from the vendored
idl/ros_msgs.idl, a subset of the ROS 2 common-interfaces .msg
definitions transcribed to IDL (builtin_interfaces, std_msgs,
geometry_msgs, tf2_msgs, sensor_msgs,
vision_msgs, geographic_msgs); according to its header, field order
and types follow the ROS 2 rolling .msg files. The pipeline is the
one used for the SpatialDDS types (idl-parse with the ROS 2 dialect,
idl-lower, lang-rules). Each generated type gets an XCDR2 codec
and, next to it, encode_xcdr1/decode_xcdr1 for XCDR1
(CDR_LE), the form in which ROS 2 middlewares put messages on the wire.
| SpatialDDS | ROS 2 |
|---|---|
spatial::core::FramedPose | geometry_msgs/PoseStamped |
spatial::core::FrameTransform | geometry_msgs/TransformStamped, tf2_msgs/TFMessage |
spatial::core::GeoPose | geographic_msgs/GeoPoseStamped |
spatial::semantics::Detection3D | vision_msgs/Detection3D |
spatial::semantics::Detection3DSet | vision_msgs/Detection3DArray |
spatial::vio::ImuSample | sensor_msgs/Imu |
The module convert provides each mapping in both directions
(*_to_ros, *_from_ros); tf2_msgs/TFMessage is built in
one direction only, from a slice of FrameTransform
(tf_message_from). The direction SpatialDDS → ROS also has From
implementations. The conversions are not lossless. Fields without a ROS counterpart are
dropped towards ROS and set to defaults on the way back:
FramedPose↔PoseStamped:CovMatrix.FrameTransform↔TransformStamped:transform_id,CovMatrix.GeoPose↔GeoPoseStamped:frame_kind,CovMatrix.Detection3D↔vision_msgs/Detection3D:track_id,attributes,visibility, point-count evidence,tile_key,source_id. The 3×3 position and 3×3 rotation covariances go into the block-diagonal 6×6 pose covariance of ROS.ImuSample↔sensor_msgs/Imu:source_id,seq; the orientation is marked as unknown (orientation_covariance[0] = -1).
The module naming provides the DDS names used by the ROS 2 rmw
implementations: ros_topic (prefix rt/),
ros_type_name (pkg::msg::dds_::Type_) and the enum
RosMessage with dds_type().
The crate is a type and conversion layer, not an RMW implementation and not a running
bridge. rmw-zerodds-shim runs it as a
bridge in its opt-in ros2.spatial_bridge mode.
Consumers
rmw-zerodds-shim, for its opt-inros2.spatial_bridgemode.
Status
std,#![forbid(unsafe_code)]. Safety classification in the crate docs: STANDARD.- Library with build script, no binary, no cargo features.
- 7 test functions in
tests/mapping.rs.
zerodds-spatial-ros2
DDS-Profile und Erweiterungen. Semantische Abbildung zwischen den SpatialDDS-Profiltypen aus
zerodds-spatial-ddsund Nachrichten der ROS 2 common interfaces.
- Quelle: crates/spatial-ros2
- API-Docs: docs.rs/zerodds-spatial-ros2
zerodds-spatial-ros2 wandelt SpatialDDS-Werte in ROS-2-Nachrichten um und
zurück. Die ROS-2-Nachrichtentypen werden zur Build-Zeit aus der mitgelieferten
idl/ros_msgs.idl erzeugt, einer nach IDL übertragenen Teilmenge der
.msg-Definitionen der ROS 2 common interfaces (builtin_interfaces,
std_msgs, geometry_msgs, tf2_msgs,
sensor_msgs, vision_msgs, geographic_msgs); laut
Dateikopf folgen Reihenfolge und Typen der Felder den .msg-Dateien von ROS 2
rolling. Die Verarbeitung ist dieselbe wie bei den SpatialDDS-Typen
(idl-parse mit dem ROS-2-Dialekt, idl-lower,
lang-rules). Jeder erzeugte Typ erhält einen XCDR2-Codec und daneben
encode_xcdr1/decode_xcdr1 für XCDR1 (CDR_LE), die
Form, in der ROS-2-Middlewares Nachrichten auf die Leitung legen.
| SpatialDDS | ROS 2 |
|---|---|
spatial::core::FramedPose | geometry_msgs/PoseStamped |
spatial::core::FrameTransform | geometry_msgs/TransformStamped, tf2_msgs/TFMessage |
spatial::core::GeoPose | geographic_msgs/GeoPoseStamped |
spatial::semantics::Detection3D | vision_msgs/Detection3D |
spatial::semantics::Detection3DSet | vision_msgs/Detection3DArray |
spatial::vio::ImuSample | sensor_msgs/Imu |
Das Modul convert bietet jede Abbildung in beide Richtungen
(*_to_ros, *_from_ros); tf2_msgs/TFMessage entsteht
nur in einer Richtung, aus einem Slice von FrameTransform
(tf_message_from). Für die Richtung SpatialDDS → ROS gibt es zusätzlich
From-Implementierungen. Die Umwandlungen sind nicht verlustfrei. Felder ohne
Gegenstück in ROS entfallen in Richtung ROS und werden auf dem Rückweg mit Standardwerten
belegt:
FramedPose↔PoseStamped:CovMatrix.FrameTransform↔TransformStamped:transform_id,CovMatrix.GeoPose↔GeoPoseStamped:frame_kind,CovMatrix.Detection3D↔vision_msgs/Detection3D:track_id,attributes,visibility, Angaben zur Punktanzahl,tile_key,source_id. Die 3×3-Kovarianzen von Position und Rotation gehen in die blockdiagonale 6×6-Kovarianz der Pose in ROS ein.ImuSample↔sensor_msgs/Imu:source_id,seq; die Orientierung wird als unbekannt markiert (orientation_covariance[0] = -1).
Das Modul naming liefert die DDS-Namen, die ROS-2-rmw-Implementierungen
verwenden: ros_topic (Präfix rt/), ros_type_name
(pkg::msg::dds_::Type_) und das Enum RosMessage mit
dds_type().
Die Crate ist eine Schicht für Typen und Umwandlungen, keine RMW-Implementierung und keine
laufende Bridge. rmw-zerodds-shim betreibt
sie als Bridge im optional einschaltbaren Modus ros2.spatial_bridge.
Konsumenten
rmw-zerodds-shim, für den optional einschaltbaren Modusros2.spatial_bridge.
Status
std,#![forbid(unsafe_code)]. Einstufung in der Crate-Dokumentation (safety classification): STANDARD.- Bibliothek mit Build-Skript, kein Binary, keine Cargo-Features.
- 7 Testfunktionen in
tests/mapping.rs.