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

Set latch param false by default #184

Conversation

efernandez
Copy link
Collaborator

Set latch param to false by default in fuse_publishers::SerializedPublisher.

The motivation is the same one that is described in #183

If we want to record graph and transaction messages and play them back, we likely need to throttle recording the graph messages because it'd take too much disk and BW to record all.

Therefore, when playing things back, we don't want to have the throttled graph played back as latched, because then the node is ignited/started at time when the transaction that happened right after the graph was likely published too long ago.

Consider this example:

  • The graph is throttled so only one message is recorded every 10.0s
  • We play back a bag file at time t_b = 170.0
  • If the recorded graph message was published by a latched topic, then it'd be published latched by rosbag play. So we get the graph from time t_g < t_b published, e.g. t_g = 165.0.
  • The next transaction that could be published would be at time t_t >= t_b, e.g. t_t = 170.1, which is way after the graph.

This means the transaction cannot be applied to the graph from t_g because it'd likely reference non-existent constraints or variables.

I can certainly set the latch param to false in my config, but it took me some time to figure this out, so I believe the default value should be false.

... in serialized publisher
@svwilliams svwilliams merged commit 92cd0f5 into locusrobotics:devel Apr 30, 2020
@efernandez efernandez deleted the serialized-publisher-latch-false-default branch May 22, 2020 08:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants