Change pat #525
Change pat #525
Conversation
WalkthroughThis pull request implements a series of configuration updates and framework transitions. GitHub workflows now use a different secret token for authentication. Repository dependency versions are updated, and documentation clarifies configuration details (e.g., updating plugin names from Ignition to Gazebo). Remapping configurations in launch and URDF files have been modified, and numerous Gazebo-related files have been updated to switch dependencies, include paths, plugin registrations, and environment variable names. A new parameter ( Changes
Possibly related PRs
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
husarion_ugv_gazebo/src/led_strip.cpp (1)
98-99:⚠️ Potential issueLogging functions not updated from Ignition to Gazebo
Similar to the issue in e_stop.cpp, this file still uses Ignition logging functions (
igndbg,ignerr) despite the migration to the Gazebo framework.Also applies to: 150-152
🧹 Nitpick comments (3)
.github/workflows/release-candidate.yaml (1)
78-78: Consistent Formatting for Access Token:
In the "Create new branch" step, the token is specified as${{ secrets.GH_PAT}}. For consistency and readability, consider adding a space before the closing curly braces (i.e.,${{ secrets.GH_PAT }}).- access_token: ${{ secrets.GH_PAT}} + access_token: ${{ secrets.GH_PAT }}husarion_ugv_localization/config/enu_localization_with_gps.yaml (1)
51-53: Parameter Addition: stamped_control
The new parameterstamped_control: truehas been added immediately afteruse_control: truewhich is an appropriate placement. This flag should enable timestamped control inputs and appears consistent with the overall configuration design. Please verify that any downstream components that consume this parameter are updated accordingly.husarion_ugv_localization/config/enu_localization.yaml (1)
41-43: New Flag Integration: stamped_control
Thestamped_control: trueparameter has been inserted correctly into the control configuration block. This addition, placed directly afteruse_control: true, maintains consistency with the other localization configuration files. Consider updating the documentation or any relevant comments to reflect the behavioral change introduced by timestamped control.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (24)
.github/workflows/release-candidate.yaml(2 hunks).github/workflows/release-project.yaml(3 hunks)README.md(1 hunks)ROS_API.md(1 hunks)husarion_ugv/hardware_deps.repos(1 hunks)husarion_ugv/simulation_deps.repos(1 hunks)husarion_ugv_controller/launch/controller.launch.py(1 hunks)husarion_ugv_description/urdf/common/gazebo.urdf.xacro(2 hunks)husarion_ugv_gazebo/CMakeLists.txt(4 hunks)husarion_ugv_gazebo/config/gz_bridge.yaml(1 hunks)husarion_ugv_gazebo/config/teleop_with_estop.config(24 hunks)husarion_ugv_gazebo/hooks/setup_envs.sh.in(1 hunks)husarion_ugv_gazebo/include/husarion_ugv_gazebo/estop_system.hpp(2 hunks)husarion_ugv_gazebo/include/husarion_ugv_gazebo/gui/e_stop.hpp(2 hunks)husarion_ugv_gazebo/package.xml(1 hunks)husarion_ugv_gazebo/plugins.xml(1 hunks)husarion_ugv_gazebo/src/estop_system.cpp(6 hunks)husarion_ugv_gazebo/src/gui/e_stop.cpp(2 hunks)husarion_ugv_gazebo/src/led_strip.cpp(2 hunks)husarion_ugv_lights/src/lights_driver_node.cpp(1 hunks)husarion_ugv_localization/config/enu_localization.yaml(1 hunks)husarion_ugv_localization/config/enu_localization_with_gps.yaml(1 hunks)husarion_ugv_localization/config/relative_localization.yaml(1 hunks)husarion_ugv_localization/config/relative_localization_with_gps.yaml(1 hunks)
🧰 Additional context used
🧬 Code Definitions (1)
husarion_ugv_gazebo/src/gui/e_stop.cpp (1)
husarion_ugv_gazebo/include/husarion_ugv_gazebo/gui/e_stop.hpp (1)
EStop(35-35)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Run unit tests hardware build type
- GitHub Check: Run unit tests simulation build type
🔇 Additional comments (59)
README.md (1)
86-86: Update to battery_config_path description is clear and correct.
The new description clearly indicates that the configuration file is for the Gazebo LinearBatteryPlugin and is intended for simulation only. Ensure that similar updates (if any) across the documentation are also consistent with Gazebo usage.husarion_ugv_gazebo/hooks/setup_envs.sh.in (1)
1-2: Environment Variable Renaming is Correct and Consistent.The updated environment variable names correctly reflect the transition from Ignition to Gazebo. Both
GZ_GUI_PLUGIN_PATHandGZ_GAZEBO_SYSTEM_PLUGIN_PATHare assigned the expected value, preserving the original functionality while aligning with the updated framework naming conventions.husarion_ugv_lights/src/lights_driver_node.cpp (1)
71-72: Improved QoS specification using modern ROS 2 APIThe change from using the lower-level
rmw_qos_profile_services_defaultto the more idiomaticrclcpp::ServicesQoS()is a good modernization. This approach is more type-safe and better expresses intent while maintaining the same QoS characteristics for service communications..github/workflows/release-candidate.yaml (2)
27-27: Update PAT token in Docs build step:
The GitHub token is now set to${{ secrets.GH_PAT }}, which aligns with the new internal PAT requirements. Please verify that this updated secret is correctly configured in the repository settings.
85-85: Update PAT token for OS image build step:
The GitHub token in the "Build OS image" step is now correctly set to${{ secrets.GH_PAT }}, ensuring that the workflow uses the proper internal PAT..github/workflows/release-project.yaml (3)
68-68: PAT token update for repository release trigger:
The token for triggering the release of thehusarion-ugv-rpi-os-imgrepository is now updated to${{ secrets.GH_PAT }}. This change ensures that authentication now leverages the internal PAT as required.
85-85: PAT token update in the OS image build step:
Here, the token is updated consistently to${{ secrets.GH_PAT }}. Additionally, verify that the reference branch (${{ env.MAIN_BRANCH }}) is correct for your build process.
104-105: PAT token and workflow file update in documentation rebuild step:
The documentation rebuild step now uses${{ secrets.GH_PAT }}and references the workflow filebuild.yaml. Ensure that these changes align with the updated documentation build process and that all dependent configurations are consistent.husarion_ugv_localization/config/relative_localization_with_gps.yaml (1)
49-53: Consistent Parameter Update: stamped_control
The addition ofstamped_control: trueunder the control configuration section is consistent with similar changes in related configuration files. Ensure that usingodom1_relative: true(as seen in this file) is intentional and that the timestamped control behavior is correctly handled downstream.husarion_ugv_localization/config/relative_localization.yaml (1)
41-43: Parameter Inclusion: stamped_control
The new configuration parameterstamped_control: trueis now part of theekf_filtersection. Its placement appears appropriate and mirrors the changes made in other related YAML files. Make sure the system’s components that depend on time-stamped control inputs are verified to work with this new setting.husarion_ugv_gazebo/config/teleop_with_estop.config (18)
7-8: Main Window Dimension Update
The main window’s dimensions have been updated to 1920×1080. This increase in resolution should enhance the overall GUI display on high‐resolution screens.
16-21: MinimalScene Plugin – GUI Tag and Layout Properties
The plugin’s GUI configuration has been updated from an Ignition-specific tag to<gz-gui>. In addition, the width and available width values have been set to 1501, and the boolean properties for focus (focusandactiveFocus) as well ashoveredhave been explicitly defined. These changes promote consistency with the new Gazebo framework and improved layout control.Also applies to: 29-30, 38-38, 48-48
90-90: EntityContextMenuPlugin – Theme Consistency
The configuration now uses<gz-gui>, and the toolbar color properties (pluginToolBarColorandpluginToolBarTextColor) have been updated to “#bbdefb” and “#111111” respectively. This update ensures a unified visual appearance across plugins.Also applies to: 153-154
221-222: GzSceneManager Plugin – Toolbar Color Update
The toolbar color properties have been updated to “#bbdefb” and “#111111”. This simple change aligns the plugin’s appearance with the new visual guidelines.
289-290: Interactive View Control Plugin – GUI Color Theme
The change to<gz-gui>with updated toolbar color settings (“#bbdefb” and “#111111”) maintains a consistent UI theme.
357-358: CameraTracking Plugin – Updated Toolbar Color
The updated toolbar color values have been applied here as well to ensure the consistent look-and-feel across all plugins using<gz-gui>.
425-426: MarkerManager Plugin – Visual Consistency Adjustment
The toolbar color properties are now explicitly set to “#bbdefb” and “#111111”, aligning this plugin with the standardized theme.
493-494: SelectEntities Plugin – Theme Update
The updated<gz-gui>toolbar color settings have been applied, ensuring that the visual presentation conforms to the new UI standards.
629-631: VisualizationCapabilities Plugin – Consistent GUI Styling
The change to<gz-gui>along with the updated toolbar colors (“#bbdefb” and “#111111”) supports a cohesive visual appearance, matching the rest of the plugins.
643-643: WorldControl Plugin – Layout and Available Width Updates
The width property is now set to 1199, and the available width has been updated to match. These modifications should help align the plugin’s layout with the overall UI design. It’s advisable to review the anchoring and placement in case the new dimensions impact interaction.Also applies to: 660-660
711-711: WorldStats Plugin – GUI and Position Update
The switch to<gz-gui>(line 711) together with the updated x-position (1211 on line 717) and the consistent toolbar color settings (lines 779–781) ensures that this plugin adheres to the unified visual theme.Also applies to: 717-717, 779-781
788-788: Shapes Plugin – GUI Framework Transition
The Shapes plugin now uses<gz-gui>along with the new toolbar color settings. These changes contribute to a consistent and modernized look throughout the application.Also applies to: 851-853
856-856: Lights Plugin – Updated GUI Configuration
By transitioning to<gz-gui>(line 856) and updating the toolbar color properties (lines 919–921), the Lights plugin now matches the fresh visual style applied across the project.Also applies to: 919-921
924-924: TransformControl Plugin – Consistent Theme Application
The update to<gz-gui>along with the updated toolbar color values in TransformControl ensure a unified interface. It is recommended to verify that these dimension settings do not adversely affect control interactions.Also applies to: 987-989
992-992: Screenshot Plugin – GUI and Theme Enhancements
The Screenshot plugin now uses the updated<gz-gui>configuration and consistently applies the new toolbar colors. This change supports a harmonized user experience across all plugins.Also applies to: 1055-1057
1060-1060: CopyPaste Plugin – Visual Theme Standardization
The CopyPaste plugin has been updated to use<gz-gui>along with the new toolbar color settings, ensuring that its appearance is in line with the overall design language.Also applies to: 1123-1125
1129-1129: EStop Plugin – GUI Framework Modernization
The EStop plugin now adopts the<gz-gui>configuration. Please verify that the provided namespace placeholder ({namespace}) is resolved correctly at runtime.
1199-1199: Teleop Plugin – Enhanced Focus and Toolbar Settings
The Teleop plugin has been updated to use<gz-gui>. Notably, the focus properties have been set totrue(lines 1210–1211) and the toolbar color settings (lines 1261–1263) have been applied consistently. Ensure that enabling focus in this context does not interfere with other UI elements and that all interactive behaviors are as expected.Also applies to: 1210-1211, 1229-1229, 1261-1263
ROS_API.md (1)
61-61: Minor formatting improvement looks goodThe spacing around the
navsat_transformnode name has been adjusted for better consistency with other entries in the documentation.husarion_ugv_gazebo/package.xml (1)
20-20: Dependency correctly updated to use Gazebo frameworkThe switch from
ign_ros2_controltogz_ros2_controlaligns with the project's transition from the Ignition robotics framework to the Gazebo framework. This change ensures proper integration with the updated simulation environment.husarion_ugv_gazebo/include/husarion_ugv_gazebo/estop_system.hpp (3)
21-22: Include paths updated for Gazebo frameworkThe header includes have been correctly updated to reference the Gazebo framework libraries instead of Ignition.
38-39: Documentation updated to reflect framework changeThe class description has been properly updated to reference the new base class from the Gazebo framework.
41-41: Class inheritance updated for Gazebo frameworkThe
EStopSystemclass now correctly inherits fromgz_ros2_control::GazeboSimSysteminstead of the previous Ignition-based class, maintaining the same functionality while using the updated framework.husarion_ugv/hardware_deps.repos (1)
5-5:✅ Verification successful
Repository dependency versions updated
The versions for
behaviortree_ros2,husarion_controllers, andros_components_descriptionhave been updated to newer commits. This ensures compatibility with the Gazebo framework transition and likely includes bug fixes or improved functionality.Also applies to: 9-9, 13-13
🏁 Script executed:
#!/bin/bash # Verify that the same repository versions are used in simulation_deps.repos to maintain consistency echo "Checking for consistency between hardware_deps.repos and simulation_deps.repos..." if [ -f "husarion_ugv/simulation_deps.repos" ]; then echo "Versions in hardware_deps.repos:" grep -A 1 "version:" husarion_ugv/hardware_deps.repos echo -e "\nVersions in simulation_deps.repos:" grep -A 1 "version:" husarion_ugv/simulation_deps.repos else echo "simulation_deps.repos not found" fiLength of output: 1013
Repository dependency versions verified and consistent
I confirmed that the updated commits for
behaviortree_ros2(first listed dependency),husarion_controllers, andros_components_descriptionare identical in both the hardware and simulation dependencies files. This alignment ensures compatibility with the Gazebo framework transition as intended. Note that the simulation file now includes an additional dependency (husarion_gz_worlds) with commit97275568c34e6fe191ca34fa1c1c2b897faf9610—please confirm that this addition is deliberate.husarion_ugv/simulation_deps.repos (1)
5-5: Repository dependency versions updated for Gazebo framework transitionThese changes update the repository dependencies to specific commits that are compatible with the Gazebo framework transition throughout the project. This is consistent with the broader shift from Ignition to Gazebo seen in other files.
Also applies to: 9-9, 13-13, 17-17
husarion_ugv_gazebo/config/gz_bridge.yaml (2)
6-6: Namespace updated from 'ignition.msgs' to 'gz.msgs'The message type namespaces have been systematically updated from
ignition.msgs.*togz.msgs.*for several topics, which is consistent with the transition from Ignition to Gazebo framework.Also applies to: 12-12, 23-23, 29-29
16-17:❓ Verification inconclusive
Topic cmd_vel now uses TwistStamped instead of Twist
The
cmd_veltopic now uses a stamped message type that includes a timestamp header. This change has corresponding updates in the controller launch file remapping and potentially in other components that use this topic.You may want to verify that all components that publish or subscribe to
cmd_velnow handle the stamped message type correctly. This is particularly important for:
- Any navigation components
- Teleop nodes
- Custom controllers
🏁 Script executed:
#!/bin/bash # Find any code that might be using the old unstamped message type echo "Searching for potential cmd_vel Twist (unstamped) subscribers or publishers" rg -A 3 -B 3 "geometry_msgs/.+?Twist[^S]" --glob "*.{cpp,hpp,py}" echo "Searching for explicit cmd_vel_unstamped references" rg -A 3 -B 3 "cmd_vel_unstamped" --glob "*.{cpp,hpp,py,xml,launch}"Length of output: 409
CMD_VEL message type update looks correct—but please verify all subscribers handle stamped messages
- The configuration update in
husarion_ugv_gazebo/config/gz_bridge.yamlnow correctly usesgeometry_msgs/msg/TwistStampedfor the cmd_vel topic.- Our initial searches for outdated (unstamped) usage produced no matches, suggesting that references to the old type are not present.
- Given the low output quality from the search, please manually verify that all components (navigation, teleop nodes, and custom controllers) are updated and correctly handle this stamped message type before finalizing the merge.
husarion_ugv_controller/launch/controller.launch.py (1)
240-240: Updated remapping for drive_controller/cmd_velThis change correctly updates the remapping to match the transition to using stamped command velocity messages, removing the "_unstamped" suffix from the source topic name. This aligns with the changes in the bridge configuration file where the
cmd_veltopic now usesTwistStamped.husarion_ugv_gazebo/plugins.xml (1)
5-5:✅ Verification successful
Base class updated to GazeboSimSystemInterface
The plugin base class has been updated from
ign_ros2_control::IgnitionSystemInterfacetogz_ros2_control::GazeboSimSystemInterface, which is necessary for compatibility with the Gazebo framework. Ensure that any implementation that inherits from this interface has been updated accordingly.
🏁 Script executed:
#!/bin/bash # Verify that the EStopSystem implementation has been updated to use the Gazebo interface echo "Checking the EStopSystem implementation for interface changes" rg -A 5 "class EStopSystem" --glob "*.{cpp,hpp}"Length of output: 821
Review Update: Base Class Interface Change Verified
- The plugin file
husarion_ugv_gazebo/plugins.xmlnow correctly specifies the base class asgz_ros2_control::GazeboSimSystemInterface.- Verification of the EStopSystem implementation in
husarion_ugv_gazebo/include/husarion_ugv_gazebo/estop_system.hppconfirms it has been updated to inherit from the corresponding Gazebo class (gz_ros2_control::GazeboSimSystem), with no remnants of the oldign_ros2_control::IgnitionSystemInterface.- The changes are consistent and ensure compatibility with the Gazebo framework.
husarion_ugv_gazebo/include/husarion_ugv_gazebo/gui/e_stop.hpp (2)
20-20: Dependency migration from Ignition to Gazebo frameworkThe include path has been updated from Ignition to Gazebo (gz) namespace, which is consistent with the framework transition mentioned in the PR objectives.
29-29: Updated class inheritance to match framework changeClass inheritance has been correctly updated to use
gz::gui::Plugininstead of the previous Ignition equivalent.husarion_ugv_gazebo/src/gui/e_stop.cpp (4)
17-19: Dependency migration from Ignition to Gazebo frameworkThe include paths have been properly updated to their Gazebo (gz) equivalents, maintaining consistency with the framework transition.
24-24: Updated constructor initialization to match framework changeConstructor initialization has been correctly modified to use
gz::gui::Plugin()instead of the previous Ignition equivalent.
102-102: Updated plugin registration macro to match framework changePlugin registration has been correctly updated from
IGNITION_ADD_PLUGINtoGZ_ADD_PLUGINwith the appropriate parameter type.
59-61:❓ Verification inconclusive
Logging functions not updated from Ignition to Gazebo
While the framework has been migrated from Ignition to Gazebo, the logging functions (
ignwarn,ignerr,ignmsg) are still using the Ignition prefix. These should be updated to their Gazebo equivalents if available.Also applies to: 68-72, 89-89
🏁 Script executed:
#!/bin/bash # Check for logging function definitions in Gazebo rg --type cpp "namespace gz.*Console" -A 10 -B 10Length of output: 51
Update Logging Functions to Gazebo Equivalents
The code in
husarion_ugv_gazebo/src/gui/e_stop.cppstill uses Ignition logging macros (e.g.ignwarn) on lines 59–61 (and similarly at lines 68–72, 89). Our initial search for Gazebo logging patterns (using a lookup fornamespace gz.*Console) produced no output—which is inconclusive. To further verify whether Gazebo now provides replacement logging macros (such asgzwarn,gzerr, orgzmsg), please run additional checks or manually verify if such Gazebo logging functions are available. If they do exist, the Ignition logging calls should be updated accordingly; otherwise, consider either adopting Gazebo’s logging mechanism (if available) or documenting the choice to retain the Ignition macros.
- Affected File:
husarion_ugv_gazebo/src/gui/e_stop.cpp- Affected Lines: 59–61, 68–72, 89
Additionally, I recommend running the following shell script to search for any usage of Gazebo logging macros:
Once you’ve confirmed the availability (or absence) of a Gazebo logging replacement, please update the code and documentation accordingly.
🏁 Script executed:
#!/bin/bash # Search for potential Gazebo logging macros replacements for macro in gzwarn gzerr gzmsg; do echo "Searching for $macro usage:" rg --type cpp "$macro" -A 2 -B 2 || echo "No matches found for $macro" doneLength of output: 702
Manual Verification Required for Logging Update
Based on the verification steps:
- A search for potential Gazebo logging macros (e.g.,
gzwarn,gzerr,gzmsg) returned no results, suggesting that no direct replacements exist in the current codebase.- The file
husarion_ugv_gazebo/src/gui/e_stop.cpp(lines 59–61, 68–72, 89) still uses Ignition logging macros, which may not align with the framework migration if updated Gazebo logging functions are available.Next Steps:
- Verify with Official Gazebo Documentation: Confirm whether Gazebo provides updated logging macros (or an alternative logging mechanism) that should replace the Ignition macros.
- If Updated Macros Exist: Update the logging statements accordingly.
- If Not: Document the decision to retain the Ignition logging calls or consider integrating a custom mapping to the Gazebo logging system if desired.
Please review and consider these points carefully.
husarion_ugv_gazebo/src/led_strip.cpp (2)
34-34: Updated Model namespace to match framework changeThe Model class reference has been correctly updated from
gz::gazebo::Modeltogz::sim::Model, which is consistent with the framework transition.
280-282: Updated plugin registration macro to match framework changePlugin registration has been correctly updated from
IGNITION_ADD_PLUGINtoGZ_ADD_PLUGIN, maintaining consistent framework usage.husarion_ugv_description/urdf/common/gazebo.urdf.xacro (3)
13-14: Updated battery plugin filename to match framework changeThe plugin filename has been correctly updated from the Ignition to Gazebo naming scheme, while preserving the plugin name which already used the
gznamespace.
36-36: Updated controller plugin name and filename to match framework changeBoth the plugin filename and plugin name have been correctly updated to use the Gazebo equivalents.
40-46:❓ Verification inconclusive
Modified remappings for controller
The remapping for command velocity has been updated from
cmd_vel_unstampedtocmd_vel, and several e-stop related remappings have been removed. These changes align with the updated framework's parameter handling.
🏁 Script executed:
#!/bin/bash # Check for other references to cmd_vel_unstamped that might need updating rg "cmd_vel_unstamped" --type-not mdLength of output: 36
Attention: Confirm Remapping Updates in URDF File
The changes in
husarion_ugv_description/urdf/common/gazebo.urdf.xacrocorrectly update the controller remappings by replacing the outdatedcmd_vel_unstampedwithcmd_veland removing the now unnecessary e-stop remappings. An automated search for"cmd_vel_unstamped"produced no results, which aligns with the intended updates. However, given the limited output from the script, please perform a manual review of the entire codebase to ensure no residual references remain.
- File Affected:
husarion_ugv_description/urdf/common/gazebo.urdf.xacro(lines 40–46)- Key Update: Command velocity remapping changed from
cmd_vel_unstampedtocmd_vel- Action Required: Manually verify that no stray references to
cmd_vel_unstampedor removed e-stop remappings exist in other parts of the projecthusarion_ugv_gazebo/src/estop_system.cpp (8)
24-26: Switch to Gazebo includes looks correct.
These lines properly transition from Ignition to Gazebo includes for IMU messages and components. No issues spotted.
43-44: New fields for joints.
Defininggz::sim::Entityandgz_ros2_control::GazeboSimSystemInterface::ControlMethodwithin thejointDatastruct appears consistent with the rest of the Gazebo-based code.
60-65: IMU entity and callback signature updates.
Line 60 initializessim_imu_sensors_togz::sim::kNullEntity, and line 62 changes the parameter type inOnIMUtogz::msgs::IMU &. Implementation in line 65 is straightforward. Ensure that all existing call sites and message bindings are updated to use the newgz::msgs::IMUtype.
79-83: Renamed private class dedication.
Declaringclass gz_ros2_control::GazeboSimSystemPrivatewith default constructor and destructor aligns with the new Gazebo-based naming scheme. No further concerns.
90-92: Pointer to EntityComponentManager.
Storinggz::sim::EntityComponentManager *ecmin this private struct can be acceptable if the pointer is guaranteed to remain valid for the lifetime of the system. Verify that no dangling pointer scenarios arise when the plugin or simulation lifecycle changes.
135-135: Forwarding to base write method.
CallingGazeboSimSystem::write(time, period)whene_stop_active_is false is correct for bridging custom E-stop logic with the base behavior.
141-149: Topic naming alignment.
Swapping out~/e_stop,~/e_stop_reset, and~/e_stop_triggerfor"hardware/e_stop","hardware/e_stop_reset", and"hardware/e_stop_trigger"is fine so long as any external references are updated accordingly.
182-182: Updated plugin export macro.
Exporting the plugin withgz_ros2_control::GazeboSimSystemInterfaceis consistent with the rest of the Gazebo migration.husarion_ugv_gazebo/CMakeLists.txt (1)
11-15:❓ Verification inconclusive
Migration to Gazebo dependencies.
These changes replace Ignition libraries with the correspondinggzlibraries (gz-sim8,gz-msgs10,gz-plugin2,gz-transport13,gz_ros2_control) and update plugin export references. Verify that the specified versions are installed and properly satisfy your environment requirements (e.g., forgz-sim8).Also applies to: 35-35, 40-40, 50-51, 59-59, 83-83
🏁 Script executed:
#!/bin/bash # Example commands to verify presence of the required Gazebo libraries at the correct versions: dpkg -l | grep gz-sim8 dpkg -l | grep gz-msgs10 dpkg -l | grep gz-plugin2 dpkg -l | grep gz-transport13Length of output: 491
Dependency Migration Verification – Manual Check Required
The migration in
husarion_ugv_gazebo/CMakeLists.txt(lines 11–15 and corresponding locations) correctly replaces Ignition libraries with the updatedgzlibraries. However, the automated dependency check usingdpkg -ldid not execute because thedpkgcommand is unavailable in your current environment.Action Required:
- Please manually verify that the required Gazebo libraries (
gz-sim8,gz-msgs10,gz-plugin2,gz-transport13, andgz_ros2_control) are installed in the expected versions for your setup.- If needed, use alternative package management commands (e.g.,
apt list --installed) or any environment-specific verification method to confirm installation.
Description
Tests 🧪