-
Notifications
You must be signed in to change notification settings - Fork 568
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
Node logging in moveit_core #2503
Conversation
57ced77
to
6e1f7f4
Compare
6358f2e
to
886a724
Compare
This one is still not ready... seeing weird test failures locally, will resume working on this tomorrow. |
a1a2eda
to
4929a9d
Compare
This pull request is in conflict. Could you fix it @tylerjw? |
4929a9d
to
01b21f0
Compare
This pull request is in conflict. Could you fix it @tylerjw? |
01b21f0
to
bd7dbba
Compare
This pull request is in conflict. Could you fix it @tylerjw? |
8f942af
to
239c933
Compare
This pull request is in conflict. Could you fix it @tylerjw? |
29b959f
to
aa250dc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Things look good, except I have a question about the mix and match of PascalCase
and snake_case
in all the new logger names that were added. Is there a pattern I missed here for deciding which goes where?
Besides that, a sprinkling of minor comments, some of them not even due to the PR but things I noticed.
moveit_core/collision_distance_field/src/collision_env_distance_field.cpp
Show resolved
Hide resolved
moveit_ros/move_group/src/default_capabilities/clear_octomap_service_capability.cpp
Show resolved
Hide resolved
moveit_ros/move_group/src/default_capabilities/clear_octomap_service_capability.cpp
Outdated
Show resolved
Hide resolved
The snake case are functions from ROS where they use the style god intended. The pascal case is from moveit's clang-tidy rules because we match ROS 1 style. |
1433e80
to
b5ad365
Compare
Signed-off-by: Tyler Weaver <[email protected]>
Signed-off-by: Tyler Weaver <[email protected]>
Signed-off-by: Tyler Weaver <[email protected]>
Signed-off-by: Tyler Weaver <[email protected]>
Signed-off-by: Tyler Weaver <[email protected]>
b5ad365
to
3e3a622
Compare
Once you have a child logger you can use it in logging macros: | ||
```C++ | ||
RCLCPP_INFO(logger_, "Very important info message"); | ||
RCLCPP_INFO(moveit::getLogger("my_namespace"), "Very important info message"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly very stupid question:
RCLCPP_INFO(moveit::getLogger("my_namespace"), "Very important info message"); | |
moveit::logInfo("my_namespace", "Very important info message"); |
or
RCLCPP_INFO(moveit::getLogger("my_namespace"), "Very important info message"); | |
MOVEIT_INFO("my_namespace", "Very important info message"); |
do read loads better, right?
I would clearly support a readable wrapper over an awkward combination of MoveIt internal static magic (definitely not what god intended) TOGETHER with C macro magic (which was clearly invented by demons).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the issues I see with those two approaches.
functions
The macros capture the file, function, and line number from the place where the macro is called. If we wrapped the ros logging system in our own functions we would loose that.
our own macros
This is a more ergonomic solution but would require me to write macros that wrap the ros macros. That would be a lot of code to write, test, and maintain. I think this approach is better given that tradeoff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. We could probably limit a convenience macro wrapper to the plain variants for almost all uses. That approach works well in OMPL and surely others. But then the question would be whether stream or printf-style and combinations might quickly blow up again if people disagree.
Still, an argument slot that only ever contains one generic term in correct usage should not exist either.
Between a rock and a hard place by design.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, I think in this case the ROS 2 logging interface is just worse from a usability standpoint. I want to reduce the amount of abstractions I maintain so I don't want to maintain a set of wrapper logging macros. For that reason I think what is in this PR is the best compromise for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just found 1 thing
moveit_ros/move_group/src/default_capabilities/state_validation_service_capability.cpp
Outdated
Show resolved
Hide resolved
…n_service_capability.cpp Co-authored-by: Sebastian Castro <[email protected]>
Description
fixes #2502