grouchy's profile - activity

I guess I wanted to show I'd searched for similar questions before posting a new one. I should have said: "Here is a sim

Thanks for the extra info @gvdhoorn. I didn't want to include too many links to ROS1-specific solutions in my question,

Thanks for the extra info @gvdhoorn. I didn't want to include too many links to ROS1 in my question, because this questi

ROS2 disable logging to file On ROS2 Foxy, it seems rclcpp nodes create log files in ~/.ros/log. Is there any way to dis

Why do roscpp publishers and subscribers take so much longer to connect than their rospy counterparts? When a roscpp sub

Why do roscpp publishers and subscribers take so much longer to connect than their rospy counterparts? When a roscpp sub

I reckon option 2 fits best my understanding of how ros_control works, though most likely its my understanding that's wr

I reckon option 2 fits best my understanding of how ros_control works, though most likely its my understanding that's wr

controller_manager behaviour when a hardware error occurs I'm integrating ros_control and thus controller_manager with a

It's been three months so I figured I'd give an update on where I got to with this. Based on gvdhoorn's et al suggestio

Why is my node not logging to a file? The roscpp logging documentation states: Everything enabled goes into the log

Is there a way to prevent multiple publishers simultaneously publishing messages to the same topic? I think I'm looking for a way for a node to lock access to a topic and release it when it's done. While a node holds the lock, no other nodes should be able to publish to this topic and their requests to lock the resource should fail. I realize this idea contradicts the principles of pub-sub, so perhaps I'm thinking about this in the wrong way.

The cmd_vel (geometry_msgs/Twist) topic is a pertinent example as interleaving messages from multiple publishers containing drastically different velocities could cause rather undesirable vibrations in the robot.

The obvious solution is to simply not run multiple nodes that can publish to the same topic, but I would like to run multiple nodes that could publish this topic at any time depending on user input. E.g. the operator could nudge a joystick while a trajectory planner is running.

I was wondering if anyone else had thought of an elegant solution to this problem or approached the problem differently before I reinvented the wheel. remote_mutex looks promising, but there is precious little information about it, and no mention of a repository as far as I can tell.

Thanks for turning me onto vapour_master, it's pretty interesting for plenty of reasons. Otherwise as you say running a

Thank you for taking the time to carefully consider my question. I had considered this issue orthogonal to security. Fo

Thank you for taking the time to carefully consider my question. I had considered this issue orthogonal to security. Fo

Mechanism to prevent multiple publishers simultaneously publishing contradictory messages to a topic? Is there a way to