-
Notifications
You must be signed in to change notification settings - Fork 197
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
Every call to canTransform implementation throws Warning message print until transform is received. #358
Comments
Can you be more specific about which error message you are getting that you would like to be more quiet? (I think I know which one, but I want to be sure) Changing the error message to only be printed after the timeout expiration would be a change to the semantics of If you really just want the print to be quieter, we could instead throttle how often the error message is printed without changing the semantics. A PR to do either would be welcome. |
Thank you for the quick response! Would validateFrameId somehow need to be updated to throttle? geometry2/tf2/src/buffer_core.cpp Line 166 in 1574a6e
|
Yeah, that's the kind of thing I'm thinking about. However, thinking about it further, this could get a little complicated. We want to throttle the printout so that it only prints for the same frame once a second (or whatever), but if a different frame fails to be validated, we want to print that right away. So we would need to remember which frames we printed out before, but also make sure that we don't "leak" memory for every single frame. It is doable, but tricky. @tfoote Do you have any thoughts on what we might want to do here? The "simplest" solution is to make |
At this level there is no sense of time for which to "timeout" the API is designed to be as low overhead as possible. The best solution I see for this is to pass in an error string pointer that will then be filled by the lower level functions. It sends out the warnings because otherwise the error will never be debuggable. In the loop you can then choose to use the error string or to ignore the error string.
The problem with this is that it will then trigger all other error cases to generate error strings. The next escalation is to pass through another argument that suppresses the logging. One potential solution I could see would be to adjust this to be a debug level log. Unfortunately I don't think that console_bridge directly supports a THROTTLED version of the logging macros which would likely be the simplest solution to slow it down. Hopefully this is only an issue at startup, but we do want to avoid spamming a lot at startup. |
Related: ros/geometry2#468 |
I would be good with the simple case of switching it to a debug log. The spamming of the log window is killing me! lol. ;) It fills my console buffer in seconds since a few nodes use this function. Sometimes it's because I am debugging a module that is delaying the TF publisher...and especially then I am trying to watch the log output for other stuff. I've found a work-around is to inverse-grep the log-spam. |
Updated fillOrWarnMessageForInvalidFrame log level to Debug for ros2#358.
Can this be updated so that it only prints the Warning after the complete timeout expiration?
geometry2/tf2_ros/src/buffer.cpp
Line 171 in 1574a6e
The text was updated successfully, but these errors were encountered: