ROS2: Add base class for Node in gazebo plugins #771
Conversation
| namespace gazebo_ros | ||
| { | ||
|
|
||
| /// Executor run in a seperate thread to handle events from all #gazebo_ros::Node instances |
| /// Create an instance and start the internal thread | ||
| Executor(); | ||
|
|
||
| /// Stops the internal exeuctor and joins with the internal thread |
|
|
||
| private: | ||
| /// Thread where the exeuctor spins until destruction | ||
| std::thread spin_thread_; |
There was a problem hiding this comment.
Style nitpick: members should come after functions, see guide
| * \param[in] node_name Name for the new node to create | ||
| * \return A shared pointer to a new #gazebo_ros::Node | ||
| */ | ||
| static SharedPtr Create(const std::string& node_name); |
There was a problem hiding this comment.
I believe the pointer style rule here also applies in this case, i.e. std::string & node_name. I also looked through existing ROS2 code and that seems to be the case.
There was a problem hiding this comment.
Addressed by adding the linters
| template <typename ...Args> | ||
| Node::SharedPtr Node::Create(Args && ...args) | ||
| { | ||
| // Throw exception is Node is created before ROS is initialized |
| return node; | ||
| } | ||
|
|
||
|
|
|
How do you recommend this PR to be tested manually? Also, ideally we would start writing automated tests for all new functionality. This PR seems like a good place to start. |
|
I have an example plugin using this in kev-the-dev#2, I'll try to convert that into a test |
kev-the-dev
force-pushed
the
ros2-devel-node
branch
from
a7af591
to
cd236f7
Compare
|
@ironmig , heads up, while you work on a test, I'm enabling linters and fixing linter issues 😉 |
|
Check out dee249e for the linters, feel free to pull the changes into this PR. |
|
|
||
| /// Create a #gazebo_ros::Node and add it to the global #gazebo_ros::Executor. | ||
| /** | ||
| * \todo Implement |
There was a problem hiding this comment.
How about we only add the declaration once the function is implemented? It can be mentioned on the design document so that we don't lose it.
|
This is looking good, @ironmig ! I have some suggestions on d34452a, could you take a look and let me know what you think? The main ideas are:
|
|
Appreciate the additional test cases. I have two thoughts on the init change:
|
|
That's a good point about concurrency. But in any case, the Node's mutex can't protect from init calls coming from outside the class, right? I'm working right now on calling the init function from within the node without any arguments in case it hasn't been called yet and I can wrap that in a mutex. I think from our end, that's the most we can do for now. Once we move on to |
|
@ironmig , check out the latest version of branch |
|
Looks good to me, integrated your changes |
Adds a class gazebo_ros::Node, which is a child of rclcpp::Node but manages a rclcpp::exeuctor among all it's instances. This allows gazebo plugins to create ROS nodes without worrying about setting up a thread to spin, like in the ros1 version of this package. It also handles ROS initialization and shutdown.