Request: Separate the simulation packages into another repository.

[RobertBlakeAnderson]

Please separate the panther_gazebo and any other simulation-specific components into another repository. This allows the user to clone the specific configuration they need and eliminates the need for the HUSARION_ROS_BUILD_TYPE environment variable. That environment variable specifically is a problem because we have to specially accommodate it our automated build and deployment tools. It is best practice to avoid requiring manufacturer-specific environments at compile-time.

[KmakD]

Separating simulation would complicate our setup, especially that there's shared code in both hardware and simulation. In our experience working with multiple repos makes deployment more complex causing a lot of pain and we would like to avoid this.

Could you let me know how the HUSARION_ROS_BUILD_TYPE variable is causing issues? Also, which tools are you using for automated deployment? Adding custom env variables seems like a standard feature and most tools should support this.

[RobertBlakeAnderson]

To be specific, we have our own standard automations that compose lists of repository URLs based on desired features and platforms, then clones those repository lists via VCS and containerizes the application. Ideally we wouldn't have to modify the automation with packages-specific rules. As a general rule for ROS packages, the package.xml should encapsulate all the information needed by a client process to build that package. There's a big difference between using environment variables at runtime (because clients have to specially compose their application launch files anyway) versus requiring them at build-time. Please consider!

[RobertBlakeAnderson]

Similarly, your intended build method (in the ros2-devel branch) includes the command colcon build --symlink-install --packages-up-to husarion_ugv --cmake-args -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF. The --packages-up-to husarion_ugv part is problematic as well, since an automation doesn't have a way to know that only some parts of the repos that it just cloned are meant to be build.

[KmakD]

As for now what I can suggest is to move/copy packages that you want to build and remove the rest. We ourself use this approach to avoid installing unnecessary ros2_controllers packages: see here.
Packages you would need for simulation can be found here.

Regarding the HUSARION_ROS_BUILD_TYPE env, I will rise this issue but I can't promise anything.

If you are using Docker, you can use our images as a standalone containers. They are already built which should speed up the process.

[RobertBlakeAnderson]

I was also going to suggest that since you have already gone to trouble of forking ros2_controllers, that you reduce your fork to only the packages you need (at least on a particular branch) to eliminate the need for post-clone manipulations.

Ed: Alternatively, perhaps move your custom imu_sensor_broadcaster package into your husarion_controllers repository, so that you no longer need the fork at all.