Comments (11)
Would Duration
do for your use case? My understanding is that a point in time is a duration of time since an epoch. If there's no clock then it would just be a duration.
from rclpy.
Would
Duration
do for your use case?
Currently our operators don't work for that:
- No + or - operators defined for Duration
- But Time offers:
- Time + Duration = Time
- Time - Time = Duration
Also the to_msg
/ from_msg
methods map to the same named builtin_interface
.
So using Duration for a Time doesn't sounds viable to me (at least at the moment).
from rclpy.
I agree with @sloretz, a time point without a clock doesn’t have meaning since you don’t know the epoch. For from_msg it is implicitly going to use a clock with a Unix epoch.
from rclpy.
For from_msg it is implicitly going to use a clock with a Unix epoch.
Currently the from_msg function chooses ROS_TIME
- not Unix epoch.
The point is when receiving a timestamp e.g. in the header field of a message which clock can we assume? There seems to be at least a mismatch atm.
from rclpy.
pitching in here that in the implementation (as of today), time points created from messages are going to default to ROS Time as the clock type (in rclcpp and in rclpy).
When I was writing tests such as this one I wondered if there should be an additional field in the Time message for the clock type. Without it, if you have a time point with, say, steady time, that info is lost when converting it to a message and sending it to someone else. (I imagine that @dirk-thomas may have been on the receiving end of this message in the use case that prompted this -- it is not so much that there isn't an clock type associated with it, but that it is unknown). I reasoned, however, that in that situation the clock type would be communicated out-of-band, so it wasn't necessary to add the field. But adding it explicitly to the message definition could be another approach to addressing this.
from rclpy.
adding it explicitly to the message definition could be another approach to addressing this.
This would result in diverging from the DDS builtin Time_t structure definition, that I think was the original motivation for not modifying the message definition (not saying it shouldn't be done, just writing down my recollection)
from rclpy.
Currently the from_msg function chooses ROS_TIME - not Unix epoch.
ROS Time uses the Unix epoch.
from rclpy.
The point is when receiving a timestamp e.g. in the header field of a message which clock can we assume?
In ROS 1 we assume ROS Time which assumes Unix Epoch, so I think that's appropriate for our time message in ROS 2 as well:
# * stamp.sec: seconds (stamp_secs) since epoch (in Python the variable is called 'secs')
-- https://docs.ros.org/kinetic/api/std_msgs/html/msg/Header.html
If we wanted to represent a different epoch (like for steady time) then I think we should have a SteadyTime.msg
type. Similar to how we have both Vector3 and Point, same data structure but different semantic. We could also include the clock type as a data field in the message but that seems less efficient in my opinion since it usually would not change.
from rclpy.
ROS Time doesn't always use the unix epoch. It defaults to system time if sim time isn't active, but if sim time is active it may, for example, start at 0s and count up from that if the /clock is being published by e.g. Gazebo.
from rclpy.
ROS messages with the timestamps are implicitly using ROS Time. This is the time of the ROS system that's expected to be synchronized between nodes. Whether it's a realtime system which is passing through the wall clock, or running in simulation with a stepping /clock
topic or any other clock synchronization method. We could easily define the other time types as @wjwwood suggests both steady time and system time to support sending them around. But so far we generally haven't had a strong need for sending times around explicitly.
from rclpy.
If we are fine with builtin times always being interpreter as ROS_TIME
the snippet I recommended in ros2/ros2cli#139 (comment) should be sufficient. Thank you for the discussion.
I will go ahead and close this request then.
from rclpy.
Related Issues (20)
- KeyError in ActionServer._execute_goal HOT 5
- [Feature] Static Type Checking With ament_mypy HOT 1
- Added optional TimerInfo to timer callback HOT 1
- :farmer: `test_guard_condition` failing consisntent in CycloneDDS HOT 2
- Add utility function to get datetime.datetime from Time HOT 1
- Decode ROS2 raw byte data using rclpy.serialization.deserialize_message HOT 3
- Rate object's destroy() does not destroy the underlying Timer object, leading to CPU usage explosion HOT 6
- Update the executor to not throw ExternalShutdownException
- Make nodes, publishers, subscriptions, services, clients, action servers, action clients Python context managers HOT 1
- aarch64 cross compiling HOT 9
- Executors mishandle invalid waitables HOT 4
- context.on_shutdown is never called HOT 7
- Bad interaction between `torch.compile` and `MultiThreadedExecutor` HOT 1
- First Time Contributors Documentation (CONTRIBUTING.md) HOT 2
- Python message with uint32 Assertion `PyLong_Check(field)' failed HOT 2
- Memory leak in ActionServer. ```taken_data = self._handle.take_goal_request``` HOT 4
- [Bug] error when node created with rclpy.node.Node HOT 1
- Async tasks are processed in LIFO not FIFO HOT 4
- Incompatibility with calling spin_until_future_complete while in callback HOT 11
- Logging with `rclpy` to file misses messages unless accompanied by a consistent stream HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rclpy.