-
Notifications
You must be signed in to change notification settings - Fork 91
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
gz_ros2_control parameter files between separate filesystems #252
Comments
I think this is not possible. gz_ros2_control is a gazebo plugin, which loads an instance of the controller manager, which itself needs the ros2_control.yaml file to load the controllers etc. You will have to make that file available in the container where your simulation works. Amongst that I'm not sure what are the advantages of your approach of two separate containers. Consider that ros2_controllers share data via shared memory with the hardware components (which is gz_ros2_control in this case). How can you separate that in two containers? |
Ah that makes sense. I wasn't sure where exactly the controller manager is started. In my use case I have two containers that both mount /dev/smh so communication works without a problem. The separation would have been nice, since there is a third container that contains the perception pipeline (which needs a Nvidia GPU) that I essentially simulate with Gazebo (with the Bounding Box Camera for example). Separating the parts allows me to switch out the "perception" part (real or simulated) without ever touching the pipeline container. I currently have a hack to map the ros2_control.yaml into the container, but I was wondering if there is a better way to do that. Thanks for the answer! |
I personally never used shared memory of ros2_control across container boarders, good to hear that this works for you. |
Configuration:
Docker Ubuntu 22.04 on Ubuntu 22.04
ROS Iron + Harmonic
ros_gz (ros2), gz_ros2_control(main) built from source
Steps to reproduce:
Start a ros2_control stack on one host and Gazebo on another and try to spawn the robot.
Problem:
I am currently working on a ROS2 stack that is both used on a real robot and in the simulation. To make the dev experience better, I isolated the actual robotics pipeline with e.g. ros2_control and the simulation with Gazebo in two separate Docker containers. If I start the real robot everything is fine. If I start the robot with the simulation, the URDF description is send to Gazebo and gz_ros2_control tries to load the params file with the filepath from the other image (The same situation would appear if there would be separate hosts for example.) and fails consequently. Is there a known pattern or workaround that would either allow modifying the received URDF on the gz_ros2_control side or put all the parameters for gz_ros2_control into the parameter server? Is the param file import important at all for the spawning procedure in Gazebo?
The text was updated successfully, but these errors were encountered: