Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Initialize service timestamps to 0 and test. #642

Merged
merged 1 commit into from
May 5, 2020
Merged

Initialize service timestamps to 0 and test. #642

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions rcl/src/rcl/client.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -303,6 +303,8 @@ rcl_take_response_with_info(
RCL_CHECK_ARGUMENT_FOR_NULL(ros_response, RCL_RET_INVALID_ARGUMENT);

bool taken = false;
request_header->source_timestamp = 0;
request_header->received_timestamp = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to have in rmw a rmw_get_zero_initialized_service_info function, though I don't mind strongly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This suggestion can be done in a follow up, for now let's go ahead with this and ros2/rmw_fastrtps#378.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to have in rmw a rmw_get_zero_initialized_service_info function,

Would this still be acceptable now, i.e. after the API freeze? I can easily add it, just wondering whether it would be taken.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this still be acceptable now, i.e. after the API freeze? I can easily add it, just wondering whether it would be taken.

In general, new API isn't accepted after the freeze. But in this case, it seems to be trivial enough (for me) and it will avoid future errors. @jacobperron do you think it's ok to add that now?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather not change/add any new API now, unless there is really good reason to do so.

if (rmw_take_response(
client->impl->rmw_handle, request_header, ros_response, &taken) != RMW_RET_OK)
{
Expand Down
22 changes: 20 additions & 2 deletions rcl/test/rcl/test_service.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -182,6 +182,9 @@ TEST_F(CLASSNAME(TestServiceFixture, RMW_IMPLEMENTATION), test_service_nominal)
client_request.uint8_value = 1;
client_request.uint32_value = 2;
int64_t sequence_number;
rcutils_time_point_value_t start_timestamp;
// take timestamp before sending request
EXPECT_EQ(RCUTILS_RET_OK, rcutils_system_time_now(&start_timestamp));
ret = rcl_send_request(&client, &client_request, &sequence_number);
EXPECT_EQ(sequence_number, 1);
test_msgs__srv__BasicTypes_Request__fini(&client_request);
Expand Down Expand Up @@ -211,8 +214,22 @@ TEST_F(CLASSNAME(TestServiceFixture, RMW_IMPLEMENTATION), test_service_nominal)

EXPECT_EQ(1, service_request.uint8_value);
EXPECT_EQ(2UL, service_request.uint32_value);
#ifdef RMW_TIMESTAMPS_SUPPORTED
ivanpauno marked this conversation as resolved.
Show resolved Hide resolved
EXPECT_GE(header.source_timestamp, start_timestamp);
#ifdef RMW_RECEIVED_TIMESTAMP_SUPPORTED
ivanpauno marked this conversation as resolved.
Show resolved Hide resolved
EXPECT_GE(header.received_timestamp, start_timestamp);
EXPECT_GE(header.received_timestamp, header.source_timestamp);
#else
EXPECT_EQ(0u, header.received_timestamp);
#endif
#else
EXPECT_EQ(0u, header.source_timestamp);
EXPECT_EQ(0u, header.received_timestamp);
#endif
// Simulate a response callback by summing the request and send the response..
service_response.uint64_value = service_request.uint8_value + service_request.uint32_value;
// take new timestamp before sending response
EXPECT_EQ(RCUTILS_RET_OK, rcutils_system_time_now(&start_timestamp));
ret = rcl_send_response(&service, &header.request_id, &service_response);
ASSERT_EQ(RCL_RET_OK, ret) << rcl_get_error_string().str;
test_msgs__srv__BasicTypes_Request__fini(&service_request);
Expand All @@ -229,9 +246,10 @@ TEST_F(CLASSNAME(TestServiceFixture, RMW_IMPLEMENTATION), test_service_nominal)
EXPECT_EQ(client_response.uint64_value, 3ULL);
EXPECT_EQ(header.request_id.sequence_number, 1);
#ifdef RMW_TIMESTAMPS_SUPPORTED
EXPECT_NE(0u, header.source_timestamp);
EXPECT_GE(header.source_timestamp, start_timestamp);
#ifdef RMW_RECEIVED_TIMESTAMP_SUPPORTED
EXPECT_NE(0u, header.received_timestamp);
EXPECT_GE(header.received_timestamp, start_timestamp);
EXPECT_GE(header.received_timestamp, header.source_timestamp);
#else
EXPECT_EQ(0u, header.received_timestamp);
#endif
Expand Down