|
nros C API
Lightweight ROS 2 client for embedded real-time systems
|
Service client API. More...


Go to the source code of this file.
Functions | |
| static rcl_ret_t | rclc_client_init_best_effort (struct rcl_client_t *client, const struct rcl_node_t *node, const struct rclc_service_type_t *type_info, const char *service_name) |
| rclc's best-effort preset constructor for a service client. | |
Service client API.
Create a service client with rclc_client_init_default(), add it to an executor with rclc_executor_attach_client(), and call services with rclc_client_call() (blocking). The executor arena owns the client; a response callback is set on the ADDED client with rclc_client_set_response_callback() (phase-487 W2).
The non-blocking paths take the reply: rclc_client_take_response() after rclc_client_send_request_async(), and rclc_polling_client_take_response_raw() on a client of the separate polled type rclc_polling_client_t, created with rclc_polling_client_init().
All four are BYTES. For a typed reply — a deserialised response struct rather than a CDR buffer — the generated per-service header emits <Srv>_client_send_request(), <Srv>_client_take_response(), <Srv>_client_call() and the callback trio <Srv>_client_handler_t / <Srv>_client_handler_init() / <Srv>_client_set_response_callback() (phase-417 W5.e). They are static inline forwarders onto the entry points named above — the same transport, the same timeout, one CDR implementation — so nothing here is superseded, and the raw path stays the one to reach for when the payload is not a generated type.
The typed send/take helpers take a CALLER-SUPPLIED scratch buffer. That is deliberate: the service pack emits no _MAX_SERIALIZED_SIZE constants yet (the message pack does, issue 0896), so a static inline with a hidden fixed-size array would reintroduce the silent cliff that work removed. An explicit buffer has no cliff, and no allocator on the delivery path.
|
inlinestatic |
rclc's best-effort preset constructor for a service client.
phase-417 W5.d; the client-side sibling of rclc_service_init_best_effort(), sharing its profile through rclc_qos_services_best_effort() so the two cannot drift — rclc's client.c and service.c build the same value the same way, and one place to read it here is what keeps that true.
static inline: no symbol, no writable data.
| [out] | client | Zero-initialised client to fill in. |
| [in] | node | An initialised node. |
| [in] | type_info | Generated service type descriptor. |
| [in] | service_name | Service name, null-terminated. |