You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
because (i) "a specific time" will never be reached exactly so the value should be given with a certain "tolerance", and (ii) there should be some "memory" about how long the event of the transform becoming available will remain "visible", since not all users of the event will have been listening to the event at the time of sending it. (E.g., listeners could be created as a reaction to such events.)
And (ii) events when certain transforms have changed.
Same remarks as above: the "change" has to have a "tolerance" and a "memory".
Based on these two events in the core tf library, you could implement any type of constraint checking outside of the core library.
I think you miss one fundamental other "event": a constraint can have "softness", and subscribers to the event can be interested in (i) knowing the current value of how much the constraint is violated, and (ii) getting events (as above) when specified levels of violation have been reached. (The latter thing might result in the same solution as the "tolerance" suggestion in the previous paragraphs...)
The text was updated successfully, but these errors were encountered:
* Only print out the LOOPING message every 30 seconds.
Signed-off-by: Chris Lalancette <clalancette@osrfoundation.org>
* Switch to using RCUTILS_LOG_* macros.
These already have the ability to print only at specified
times, so just use that.
Signed-off-by: Chris Lalancette <clalancette@osrfoundation.org>
Originally here: https://code.ros.org/trac/ros-pkg/ticket/4422
A way to generate events when relative/absolute constraints between frames are violated/reached/broken/....?
This would be the next generation of MessageFilter?
Likely register a callback on a precondition.
We need to be careful of the threading model and not cross threads.
Other suggestions from Herman on the email thread,
Suggestion: make this "level-triggered events" and not "edge-triggered"
< http://en.wikipedia.org/wiki/Edge_triggered_interrupt#Types_of_Interrupts>
because (i) "a specific time" will never be reached exactly so the value should be given with a certain "tolerance", and (ii) there should be some "memory" about how long the event of the transform becoming available will remain "visible", since not all users of the event will have been listening to the event at the time of sending it. (E.g., listeners could be created as a reaction to such events.)
And (ii) events when certain transforms have changed.
Same remarks as above: the "change" has to have a "tolerance" and a "memory".
Based on these two events in the core tf library, you could implement any type of constraint checking outside of the core library.
I think you miss one fundamental other "event": a constraint can have "softness", and subscribers to the event can be interested in (i) knowing the current value of how much the constraint is violated, and (ii) getting events (as above) when specified levels of violation have been reached. (The latter thing might result in the same solution as the "tolerance" suggestion in the previous paragraphs...)
The text was updated successfully, but these errors were encountered: