Open tmayoff opened 2 months ago
So I implemented the service in ROS using pub/subs instead and it works with the same client code (with updated topic names). I guess there's something I'm missing when setting up the clients (or probably less likely there's a bug here?) any help would be great
@tmayoff could it be that your native DDS types don't account for the request/response headers that the Cyclone RMW layer injects?
The header type is
struct RequestHeader {
uint64_t guid;
int64_t seq;
};
The guid
and seq
just need to be unique.
That could be it, reverse engineering ROS topics/services is proving difficult (unless we're missing some tools we can use), we've been using an old repo that contains a bunch of ROS2 messages and services already converted to native .idl. There's no mention of RequestHeaders (and I'm assuming the Response ones are the same as the requests). I'll try adjusting our setup to include those.
Is there a reason this wouldn't cause an error or pub/sub mismatch if they're differing types
Bug report
Required Info:
Steps to reproduce issue
The native dds client code is a bit more scattered (wrapper around cyclonedds-cxx), I can provide it if required.
Expected behavior
The request object should contain the details sent by the client and respond accordingly.
Actual behavior
When sending a request to the service it's received in the node, but the request object is default initialized, none of the fields are field with the data that was sent. The service callback fails, and returns a not properly initialized response (transform output contains random values).
Additional information
These were grabbed off cyclonedds' cli tool once with just ROS2 running and the other with just the native dds application