Convert to ROS2 Logging

[davetcoleman]

My understanding of the situation: logging in ROS2 is different than ROS1 due to the lack of a singleton (the assumption that there is one ROS node per process). In ROS2 each call to the logger requires you pass in a logger handle, or the node handle. See this discussion to get the full background.

In order to achieve the MVP of moveit2, I recommend we create the ROS2 node as a global variable, or at least the logger handle as a global variable. This will limit moveit2 from having more than one instance in the same process, but we can fix that in the future.

So, in MoveGroup main function we'll need to create this singleton.

This issue is to track the modification of logging in moveit2. @wjwwood is the lead contact for us who is expert on this issue.

[wjwwood]

That sounds right to me. I imagine something like moveit_core::get_logger() -> rclcpp::Logger which can be called from anywhere to get a logger to be used locally and a way to set that from something ros specific in main function or core constructor, e.g. moveit_ros::set_logger(my_node->get_logger()) which internally might call moveit_core::set_logger().

[vmayoral]

Thanks for the input @wjwwood.

@davetcoleman as pointed out at #7 (comment), I think we should address this issue in a separate PR since it'll touch submodules of several of the packages. I presume that changes will need to be made in moveit_ros package, right?

It'll be really helpful to get the logging somewhat addressed before we port the rest of the code. @davetcoleman since you know best the code, can you make an initial prototype extending MoveGroup main function while following the guidelines of @wjwwood? That'll speed things up significantly on our side.

[davetcoleman]

I don't think I'll be able to get to this in the next week due to travel, and I don't think I'm the most qualified to prototype this for ROS2.

[vmayoral]

@davetcoleman, we finished a prototype in the kinematic_contraints submodule available at https://github.com/AcutronicRobotics/moveit2/blob/master/moveit_core/kinematic_constraints/src/kinematic_constraint.cpp#L52 and used across the code as https://github.com/AcutronicRobotics/moveit2/blob/master/moveit_core/kinematic_constraints/src/kinematic_constraint.cpp#L131.

We are systematically porting packages while verifying that things compile (as opposed to porting changes across all moveit2 packages, we don't know the code well enough to be doing so confidently and such ).

Given the discussion above where you'd like to have a global variable (I guess in MoveGroup from what's been discussed in other threads), this approach won't the final however it'll be easily changed in the future and makes now use of RCLPP APIs which will hopefully unblock several PRs which are pending such as #7 or #9.

Let me know if that's acceptable and we'll get it done.

[davetcoleman]

Thanks for putting together this prototype! I'd like some level of buy in from @wjwwood but it seems good to me.

To keep our style guideline roughly the same in moveit2 (see the ROS section of that page), I'd like to keep the namespace variable the same name of LOGNAME. Its also more space efficient.

In this new approach you're proposing, I assume you'll also delete your logging.h ? I was actually a fan of that approach as it would minimize the diff, for now, between ROS1 & 2. Though that isn't super important to me.

Rather than links to lines of code, it's easiest to discuss the proposed change in a PR that targets logging, could you all do that please?

[wjwwood]

Looks fine to me, only thing I'd say is that the global logger may also be static and const.

[mlautman]

(copied and heavily modified from #12 )

According to the ROS/Google style guides, "Objects with static storage duration are forbidden unless they are trivially destructible." It would seem that a global logger like the one in the kinematic_constraints example would violate that. (see: http://wiki.ros.org/CppStyleGuide#Globals,
https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables)

I think we can still use constexpr and store the name as char*'s at the top of the cpp's and create loggers as needed.

I think a good rule would be to use class variables for loggers whenever possible. When this is not possible, we should be generating the logger on the fly from c-style strings with eg RCUTILS_LOG_INFO(LOGNAME, "....");.

[vmayoral]

I finished changing all the submodules of moveit_core in our master branch to the logging primitives recommended by @wjwwood. Changes follow from the prototype presented before at #21 (comment).

This took quite a bit of time and effort.

To keep our style guideline roughly the same in moveit2 (see the ROS section of that page), I'd like to keep the namespace variable the same name of LOGNAME. Its also more space efficient.

I went through the style guide and will keep it in mind. Do you intent do have a const variable only used once to define the logger? Even if that complies with the current style, I'd argue that it can probably change as well. Specially, given the fact that the whole logging structure (and how it's used) has also changed. Maybe I'm missing something and I don't quite see how you'd like to have this so I leave it up to you.

I can see @mlautman has further ideas and change suggestions however I don't think we'll be able to put more time into this in the short term since we want to move forward. I let @mlautman, @davetcoleman and others submit further improvements if you consider them necessary. Upcoming submodules ported will include the changes discussed above.

[wjwwood]

From the style guide:

As a rule of thumb: a global variable satisfies these requirements if its declaration, considered in isolation, could be constexpr.

This implies to me that std::string and therefore rclcpp::Logger should be ok to have static storage. It would be possible to make it constexpr if you were allowed to allocate memory for constexpr expressions (something that is being worked on, see: https://github.com/ldionne/wg21/blob/master/generated/p1004r1.pdf / https://www.youtube.com/watch?v=CRDNPwXDVp0&feature=youtu.be&t=3080).

At any rate, I think it's safe and more efficient to statically create the logger object rather than statically store a char * and create a logger each time you need it (each time you create a logger from a char * a memory allocation may need to occur). However, in practice the SBO for std::string may save you most of the performance cost.

It's up to you guys.

[davetcoleman]

I'm frustrated by the lack of tangible PRs to have these discussions on - links to code is much more difficult to iterate on and discuss inline. I re-reviewed all the discussions so far on logging am proposing a simple example that I believe scales easily to the whole code base:

#33

Feel free to comment inline there if you see issues with it. Or make a new PR with an alternative suggestion.

[mlautman]

I can see @mlautman has further ideas and change suggestions however I don't think we'll be able to put more time into this in the short term since we want to move forward. I let @mlautman, @davetcoleman and others submit further improvements if you consider them necessary. Upcoming submodules ported will include the changes discussed above.

@vmayoral I may have been being overly critical. I think the prototypes at #21 (comment) and #33 offer a good path forward and if the logging infrastructure changes in the future, we can reassess.

[wjwwood]

Including it causes the following error which I haven't spent time debugging:

I think that's a bug in our template magic that supposed to detect when you're passing something other than a logger and instead should give a better error.

It needs to be updated to remove const-ness before comparing with std::is_same.

I just made a new issue for it here: ros2/rclcpp#679

It would be a good first contribution to rclcpp if anyone has time for it :)

[vmayoral]

ros2/rclcpp#680 fixes it. Thanks @wjwwood.

[henningkayser]

Added migration instructions to https://github.com/ros-planning/moveit2/blob/master/doc/MIGRATION_GUIDE.md