The Message-Type Concept

The M type parameter on nros::Publisher<M>, nros::Subscription<M>, etc. must satisfy the following concept (provided automatically by code generated via nano_ros_generate_interfaces(... LANGUAGE CPP)):

struct M {
    // ROS 2 fully-qualified type name, e.g. "std_msgs::msg::Int32"
    static constexpr const char* TYPE_NAME = "...";
 
    // RIHS01 type hash (Iron+) or "TypeHashNotSupported" (Humble)
    static constexpr const char* TYPE_HASH = "...";
 
    // Maximum serialised size for static pool sizing.
    static constexpr size_t SERIALIZED_SIZE_MAX = ...;
 
    // Generated FFI helpers: serialise + publish, take + deserialise.
    static int32_t ffi_publish(void* publisher_storage, const M* msg);
    static int32_t ffi_take(void* sub_storage, M* out);
    // ... per-service variants for service/action types.
};

Likewise service types S expose nested Request and Response types (each itself satisfying the message-type concept) plus S::TYPE_NAME and S::TYPE_HASH. Action types A expose nested Goal, Feedback, and Result.

You should never write these by hand. The codegen tool emits conformant C++ headers from .msg / .srv / .action files.