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.

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

Fix time behavior #691

Merged
merged 5 commits into from
Feb 18, 2022
Merged

Fix time behavior #691

merged 5 commits into from
Feb 18, 2022

Conversation

kenji-miyake
Copy link
Contributor

@kenji-miyake kenji-miyake commented Dec 10, 2021

Public API Changes

To be discussed.

Description

Split from #646.

Since the current code doesn't pass the tests, I fixed it.
However, this deletes a lot of code, so should be discussed carefully.

How to test

Time Array

Before(upstream/ros2)

$ # Terminal 1
$ ros2 run rosbridge_server rosbridge_websocket
[ERROR 1639116972.608771088] [rosbridge_websocket]: [Client 0] [id: publish:/time:3] publish: The 'times' field must be a set or sequence and each value of type 'Time'
[ERROR 1639116973.613656065] [rosbridge_websocket]: [Client 0] [id: publish:/time:4] publish: The 'times' field must be a set or sequence and each value of type 'Time

$ # Terminal 2
$ curl -sL https://github.com/tier4/rosbridge_suite/raw/add-test-scripts/test_scripts/time_array.py | python
publish: {'times': [{'sec': 1, 'nanosec': 2}, {'sec': 3, 'nanosec': 4}]}
publish: {'times': [{'sec': 1, 'nanosec': 2}, {'sec': 3, 'nanosec': 4}]}

After(this PR)

$ # Terminal 1
$ ros2 run rosbridge_server rosbridge_websocket
// No error

$ # Terminal 2
$ curl -sL https://github.com/tier4/rosbridge_suite/raw/add-test-scripts/test_scripts/time_array.py | python
publish: {'times': [{'sec': 1, 'nanosec': 2}, {'sec': 3, 'nanosec': 4}]}
subscribe: {'times': [{'sec': 1, 'nanosec': 2}, {'sec': 3, 'nanosec': 4}]}
publish: {'times': [{'sec': 1, 'nanosec': 2}, {'sec': 3, 'nanosec': 4}]}
subscribe: {'times': [{'sec': 1, 'nanosec': 2}, {'sec': 3, 'nanosec': 4}]}

Time (new format of sec/nanosec)

Before(upstream/ros2)

$ # Terminal 1
$ ros2 run rosbridge_server rosbridge_websocket
// No error

$ # Terminal 2
$ curl -sL https://github.com/tier4/rosbridge_suite/raw/add-test-scripts/test_scripts/time_new_format.py | python
publish: {'sec': 1, 'nanosec': 2}
subscribe: {'sec': 1, 'nanosec': 2}
publish: {'sec': 1, 'nanosec': 2}
subscribe: {'sec': 1, 'nanosec': 2}

After(this PR)

$ # Terminal 1
$ ros2 run rosbridge_server rosbridge_websocket
// No error

$ # Terminal 2
$ curl -sL https://github.com/tier4/rosbridge_suite/raw/add-test-scripts/test_scripts/time_new_format.py | python
publish: {'sec': 1, 'nanosec': 2}
subscribe: {'sec': 1, 'nanosec': 2}
publish: {'sec': 1, 'nanosec': 2}
subscribe: {'sec': 1, 'nanosec': 2}

Time (old format of secs/nsecs)

Before(upstream/ros2)

$ # Terminal 1
$ ros2 run rosbridge_server rosbridge_websocket
[ERROR 1641824688.064981748] [rosbridge_websocket]: [Client 2] [id: publish:/time:3] publish: 'Time' object has no attribute 'secs'
[ERROR 1641824689.066817317] [rosbridge_websocket]: [Client 2] [id: publish:/time:4] publish: 'Time' object has no attribute 'secs'

$ # Terminal 2
$ curl -sL https://github.com/tier4/rosbridge_suite/raw/add-test-scripts/test_scripts/time_old_format.py | python
publish: {'secs': 1, 'nsecs': 2}
publish: {'secs': 1, 'nsecs': 2}

After(this PR)

$ # Terminal 1
$ ros2 run rosbridge_server rosbridge_websocket
[ERROR 1641824706.049035256] [rosbridge_websocket]: [Client 0] [id: publish:/time:3] publish: Message type builtin_interfaces/Time does not have a field secs
[ERROR 1641824707.049698653] [rosbridge_websocket]: [Client 0] [id: publish:/time:4] publish: Message type builtin_interfaces/Time does not have a field secs

$ # Terminal 2
$ curl -sL https://github.com/tier4/rosbridge_suite/raw/add-test-scripts/test_scripts/time_old_format.py | python
publish: {'secs': 1, 'nsecs': 2}
publish: {'secs': 1, 'nsecs': 2}

@kenji-miyake
Copy link
Contributor Author

@jtbandes Should I change the code to support the old format?

My concern is that the output from rosbridge will be the new format, so anyway the clients should upgrade the interfaces if they not only publish but subscribe Time data.
Am I right?

@kenji-miyake kenji-miyake marked this pull request as ready for review January 10, 2022 14:28
Copy link
Member

@jtbandes jtbandes left a comment

Choose a reason for hiding this comment

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

Thanks and sorry for the delay. From your examples in the description, it looks like the main change is to fix the handling of time[] arrays. Do you think it would be better to leave the other features as-is and focus on only fixing time arrays?

Comment on lines 300 to 310
if rostype == "time" and msg == "now":
return ROSClock().now().to_msg()
Copy link
Member

Choose a reason for hiding this comment

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

Looks like this is removing a feature where the string "now" will be translated to the current time. I guess this feature was not documented, so it's ok to remove? Is that what you're thinking too?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, I didn't care about that, sorry. Will confirm the reason why this was added!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Introduced here: 8e3eb96

Comment on lines 311 to 326
# Copy across the fields, try ROS1 and ROS2 fieldnames
for field in ["secs", "nsecs", "sec", "nanosec"]:
try:
if field in msg:
setattr(inst, field, msg[field])
except TypeError:
continue
Copy link
Member

@jtbandes jtbandes Jan 20, 2022

Choose a reason for hiding this comment

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

What's the impact of removing this? Does it mean a client publisher might need to change their code if they are still using the old values?

It's not necessarily bad to remove, but technically we should bump the package version to 2.0.0 if we remove features.

On the other hand, since some of the changes from #692 are significant to clients, I wonder if we should bump the version to 2.x anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Does it mean a client publisher might need to change their code if they are still using the old values?

Yes, if this part is removed, they should change their code that uses secs/nsecs.

But I believe they should do so because they must update their subscriber-side code in any case, since rosbridge outputs Time data in the sec/nanosec format.
What do you think about it?

It's not necessarily bad to remove, but technically we should bump the package version to 2.0.0 if we remove features.

I see, I agree with you!

On the other hand, since some of the changes from #692 are significant to clients, I wonder if we should bump the version to 2.x anyway.

Yes, I think it's a good idea.

@kenji-miyake kenji-miyake marked this pull request as draft January 21, 2022 01:12
@kenji-miyake
Copy link
Contributor Author

Do you think it would be better to leave the other features as-is and focus on only fixing time arrays?

@jtbandes Yes, I agree. I changed this to draft and will update the code at a later date.

Kenji Miyake added 4 commits February 12, 2022 17:32
@kenji-miyake
Copy link
Contributor Author

@jtbandes I'm sorry to be late. Since I've fixed the code, could you review this again, please?

FYI, Related PRs/commits:

return {"sec": inst.sec, "nanosec": inst.nanosec}
except AttributeError:
return {"secs": inst.secs, "nsecs": inst.nsecs}
return {"sec": inst.sec, "nanosec": inst.nanosec}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since rostype is ROS 2 type, I guess there is no need to use the secs/nsecs format.

from rcl_interfaces.msg import Parameter
from rclpy.clock import ROSClock
from rclpy.time import Duration, Time
Copy link
Contributor Author

Choose a reason for hiding this comment

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

By import rclpy, I couldn't access to rclpy.time.

In [1]: import rclpy

In [2]: rclpy.time
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Input In [2], in <module>
----> 1 rclpy.time

AttributeError: module 'rclpy' has no attribute 'time'

if rostype == "builtin_interfaces/Time":
inst = Time().to_msg()
elif rostype == "builtin_interfaces/Duration":
inst = Duration().to_msg()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think these ("time/duration") are probably ROS 2 porting mistakes.

setattr(inst, "sec", msg[field])
for field in ["nanosec", "nsecs"]:
if field in msg:
setattr(inst, "nanosec", msg[field])
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since inst is ROS 2 type, I believe we must force converting to ROS 2 fields here.

@kenji-miyake kenji-miyake marked this pull request as ready for review February 12, 2022 09:17
Copy link
Member

@jtbandes jtbandes left a comment

Choose a reason for hiding this comment

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

Thank you!

@jtbandes
Copy link
Member

I'm not sure about the CI failure on Rolling, I'll investigate it separately. It looks like the same failure is happening on the ros2 branch right now.

@jtbandes jtbandes merged commit cdaa0d9 into RobotWebTools:ros2 Feb 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants