shonigmann's profile - activity

If you have a robot composed of several sub-robots (e.g. a mobile base platform with a manipulator attached), each of which has its own independent controllers defined, is there a preferred approach to managing the controllers for the combination?

Are there reasons for or against either:

• aggregating the controllers for both the base and arm into a single controller_manager node, or
• running separate controller_manager nodes for each sub-robot (e.g. base_controller_manager and arm_controller_manager)?

I'd imagine the former might have a bit less overhead, but the latter might make lifecycle management a bit more flexible?

Would it be bad practice to cascade controllers using ros2_control?

For instance, if you had a legged robot, you may have a low level controller to command joint positions, and a higher level limb trajectory controller, and maybe an even higher level robot body controller.

+-----------------+             +-----------------+              +------------------+
| body controller | ----------->| limb controller | -----------> | joint controller | 
+-----------------+             +-----------------+              +------------------+

Would it be reasonable to have each of these controllers as separate ros2_controller interfaces, publishing updates to each other?

Or would the additional publish-subscribe interfaces add to the control latency/jitter, and would it instead be preferable to write a single node that does all 3?

(Adding an answer to summarize @gvdhoorn's response and some more recent context, to close this question out prior to th

Are there any downsides or pitfalls to using the --symlink-install option in when building a workspace with colcon in ROS2?

To me, it seems like a cross-the-board improvement; symbolic links instead of copies take less disk space, and make for faster development when using python, urdf, xacro, yaml, etc; and compiled language files are still handled as expected (to my knowledge). But I feel like I must be missing something, else I would expect colcon to enable --symlink-install by default if there weren't any downsides.

Is there a preferred way to concatenate a LaunchConfiguration with a string (e.g. a file extension, prefix, or suffix) that can be used in a similar way to PathJoinSubstitution?

e.g. given:

DeclareLaunchArgument('my_robot', default_value='my_robot_name')

a path could be made to my_robot using:

PathJoinSubstitution(['path', 'to', LaunchConfiguration('my_robot')])

which would evaluate as:

/path/to/my_robot_name

But what if I want to create a path to my_robot_name.config? Is there an equivalent way to combine strings and LaunchConfigurations?

As a workaround, I've used Command or PythonExpression substitutions, e.g.:

Command(['echo -n ', LaunchConfiguration('robot_name'), '.config'])  # or
PythonExpression(["'", LaunchConfiguration('robot_name'), ".config'"])

But I think it would be great if there was a cleaner, more readable alternative that I've completely overlooked.

@Fetullah Atas' answer got me most of the way there. Moving my comment to an answer to hopefully improve visibility. As

Disclaimer that I know this question strays from the typical ROS Answers format a fair bit. But I still think this is a better medium to have this discussion than, say, ROS Discourse.

I've looked around a fair bit, and have yet to see a single "definitive" and up-to-date discussion of the steps that you need to consider to successfully launch multiple robots in ROS2. There are a number of questions already on ROS Answers, and elsewhere, that discuss things like namespaces, frame_prefix (recently readded), GroupActions, remapping topics, gazebo plugin considerations, etc, as well as a number of examples that have been posted (e.g. by Nav2, theConstruct, and others), but I feel like they are often a bit light on the "why" aspect of what's going on. I think it would be valuable to have a single resource that includes an overview of all the aspects that need to be considered, particularly when moving from a single robot to multiple robots, and of any "best practices" that people have developed.

Some questions that I've come across that would be worth answering for new users:

• When to use namespaces vs remapping? When might you need to use both?
• When its worth using GroupAction
• When should you use frame_prefix? When should you add a prefix directly in your URDF/Xacro files?
• Where do you need to apply a frame_prefix or namespace? (Gazebo plugins, ros2_control config files, robot_state_publisher)?
• What are the best ways to avoid redundant definitions of robot parameters (e.g. in config files that could be identical except for a prefix or ID parameter)?
• When should you use fully qualified vs relative names? Are there any common cases other than /tf where you would not want to use relative topic names?
• When should you use a single tf tree for all robots, and when should you use a different tf tree for each robot?
• What considerations should you take when writing an Xacro file to ensure you can easily extend from single-robot to multi-robot use cases?
• What's the best way to spawn multiple robots in Gazebo?

I'd be happy to take a stab at answering some of these items myself, but really I'd like to hear from people with more experience to glean from their working experience. If anyone has any additional questions, please comment them below and I can add them to the list. I'd also be happy to compile feedback into a single wiki or tutorial type document.

Thanks in advance!

as a point of clarification - are you running nodes (ros2 run ...) or are you launching launch files (ros2 launch ...)?

Duplicate of https://answers.ros.org/question/417679/unable-to-properly-kill-nodes-launched-via-custom-ros-node/

I'm playing around with tf2 in ROS2 Foxy using a Gazebo simulated robot, and get warning messages regarding the tf2 "authority".

For instance, running ros2 run tf2_ros tf2_monitor, I can see that the static and dynamic transforms are being published by "<no authority available>", e.g.:

Frame: back_right_wheel_link, published by <no authority available>, Average Delay: 0.000709075, Max Delay: 0.0118647
Frame: base_link, published by <no authority available>, Average Delay: 1.62619e+09, Max Delay: 1.62619e+09

TF buffers also mention the undetectable Authority. E.g. RViz also gives TF related warnings mentioning the Authority

Warning: TF_OLD_DATA ignoring data from the past for frame right_rocker_link at time 7.421000 according to authority Authority undetectable

I haven't found much in terms of documentation or search results referring to the "authority", so I was hoping someone could give some insight into what it is, how it is typically set, etc.

Thanks!

There is no support for closed kinematic loops in URDF but there is in Gazebo/SDF, and presumably other simulation speci

There is no support for closed kinematic loops in URDF but there is in Gazebo/SDF, and presumably other simulation speci

what you currently have will fail because os.path.join has no knowledge of ROS 2 launch substitutions or the launch cont

It sounds like whatever is publishing your odometry is configured incorrectly, but its difficult to say without more inf

i seem to remember having this issue in Galactic but its been a while and I don't fully recall the root cause. It is a w

Gazebo only knows about meshes based on the filepath that is provided in the URDF/SDF file it receives. If that filepath

I'm not sure I understand your question... But if you are asking how you can apply color or texture to models in Gazebo

I only skimmed your question/code since there was a lot to unpack here, so apologies if I'm missing the mark (I'm also d

Please correct me if I'm wrong, but my understanding is that you want to modify and rebuild a specific package that you

duplicate of https://answers.ros.org/question/414235/arduino-cli/

You might find either of these interesting: https://github.com/UniversalRobots/Universal_Robots_ROS2_Gazebo_Simulation

You might find either of these interesting: https://github.com/UniversalRobots/Universal_Robots_ROS2_Gazebo_Simulation

the gazebo_ros2_control position control interface implementation sets joint positions directly. There's no underlying c

I suspect your ros2_control configuration may be inconsistent if things are out of order. Hard to say without seeing the

the gazebo_ros2_control position control interface implementation sets joint positions directly. There's no underlying c

I'm not familiar with Askbot, but my intent was always to help people coming to ROS Answers to answer questions more rea

I'm not familiar with Askbot, but my intent was always to help people coming to ROS Answers to answer questions find mor

There is a pause Launch Argument that you can set to true (defined here in the source) Your launch command could look s

duplicate of https://answers.ros.org/question/411752/newbie-question-first-robot-ufactory/. Closing.

the messages you quoted from the log are not referring to missing / unfound meshes and can safely be ignored in my exper

Assuming your drivers are installed correctly, you can (in Ubuntu at least) right click on the terminal icon from the ap

A binary .stl should certainly work. I do not believe RViz supports obj (unless that's changed somewhat recently). Gaze