Skip to main content

RosMessage

Trait RosMessage 

Source
pub trait RosMessage:
    Sized
    + Serialize
    + Deserialize {
    const TYPE_NAME: &'static str;
    const TYPE_HASH: &'static str;
    const SERIALIZATION_FORMAT_ID: SerializationFormatId = nros_serdes::format::SerializationFormatId::Cdr;
    const STAMP_OFFSET: Option<usize> = None;
}
Expand description

Trait for ROS message types

Identifies a ROS message type by its DDS type name and RIHS hash. All message types implement Serialize and Deserialize.

Required Associated Constants§

Source

const TYPE_NAME: &'static str

Full ROS type name in DDS format

Example: "std_msgs::msg::dds_::String_"

Source

const TYPE_HASH: &'static str

RIHS (ROS Interface Hashing Standard) type hash

Used for type validation between publishers and subscribers. Format: 64-character hex string (SHA-256)

Provided Associated Constants§

Source

const SERIALIZATION_FORMAT_ID: SerializationFormatId = nros_serdes::format::SerializationFormatId::Cdr

RFC-0088 — the serialization format this message’s bytes are in.

Defaulted, on purpose. A required associated type here would force a line onto every hand-written message in every user crate, which is the decision phase-380 W4 already made and reverted once: tightening the message contract to serve a build assertion broke examples/native/rust/custom-msg, the documented hand-written-message pattern. A defaulted const costs existing implementors nothing and still answers at compile time, which is all the assertion needs.

It lives on RosMessage rather than nros_serdes::schema::Message because only this trait is universal: MessageForRmw requires a schema only under cfg(rmw_needs_type_descriptors) (Cyclone), so a check keyed on the schema would be absent under zenoh and XRCE — and absent under uORB, which is the one backend the check exists for.

Codegen emits an override only for a non-CDR format.

Source

const STAMP_OFFSET: Option<usize> = None

RFC-0052 / phase-296 W3a — byte offset of header.stamp.sec within this type’s serialized CDR payload (encapsulation header included), or None when the type has no leading std_msgs/Header / builtin_interfaces/Time. Codegen-const, never runtime introspection: CDR here is little-endian with a 4-byte encapsulation header and Time { i32 sec; u32 nanosec } is 4-byte aligned, so a Header-leading (or Time-leading) type carries sec at byte 4 and nanosec at byte 8. On-target max_age monitors peek these two words from the raw receive buffer before deserialization.

Dyn Compatibility§

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§