Bump 1.4.11

[Woojin-Crive]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @Woojin-Crive, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the dynamixel_hardware_interface by introducing firmware version-aware model file selection. This change allows the system to adapt to different Dynamixel firmware versions by loading the appropriate control table definitions, improving compatibility and robustness. It also includes several corrections to existing model files and a new utility script to maintain model file formatting consistency.

Highlights

• Firmware Version-Aware Model File Selection: Implemented logic to dynamically load Dynamixel model files based on the motor's firmware version. This ensures the correct control table is used, addressing potential inconsistencies between different firmware versions of the same model, particularly for XC330/XL330 series where control table addresses changed.
• New Firmware-Specific Model Files: Added new .model files (e.g., xc330_m181_fw52.model) for several Dynamixel models to specifically support firmware version 52, which has different control table addresses for indirect data compared to newer firmware versions.
• Model File Corrections and Enhancements: Corrected control table addresses in existing XC330/XL330 series model files, fixed a typo ('Hybrid Saveve' to 'Hybrid Save') in YM series models, and added missing 'Error Code History' entries in ym080_230_b001.model.
• Model File Formatting Script: Introduced a new Python script (scripts/check_model_file_formatting.py) to automatically check and fix common formatting issues (like trailing spaces, missing EOF newlines, and excessive empty lines) in all .model files, promoting consistency.
• Package Version Update: The package version has been bumped from 1.4.10 to 1.4.11 to reflect these new features and improvements.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a valuable feature for firmware-aware model file selection, allowing for different control tables based on the device's firmware. The implementation is generally well-structured, including new C++ logic and a helpful Python script for formatting checks.

I've identified a few areas for improvement, primarily a bug in the firmware update notification logic and a potential correctness issue in the Python script. I've also provided suggestions to enhance code clarity and efficiency.

[gemini-code-assist]

This block for selecting the firmware file and notifying the user has a couple of issues:

1. Inefficiency: ExtractFirmwareVersionFromFilename(selected_file) is called repeatedly inside the loop. It's more efficient to store the version of the currently selected file in a variable.
2. Bug: The logic for printing the "firmware outdated" notice is incorrect. It prints the notice even when the device has the latest available firmware (i.e., firmware_version == highest_fw_version). The notice should only be shown if firmware_version < highest_fw_version.

Here's a suggested refactoring that addresses both points and improves clarity.

  // Find the best matching firmware version file
  std::string selected_file = base_model_name;
  uint8_t selected_fw_version = 0;
  int highest_fw_version = -1;

  for (const auto & fw_file : available_firmware_versions) {
    uint8_t fw_version = ExtractFirmwareVersionFromFilename(fw_file);
    if (fw_version > highest_fw_version) {
      highest_fw_version = fw_version;
    }
    if (fw_version <= firmware_version && fw_version > selected_fw_version) {
      selected_file = fw_file;
      selected_fw_version = fw_version;
    }
  }

  // If device FW is greater than the highest available firmware-specific file, use base model
  if (highest_fw_version != -1 && firmware_version > highest_fw_version) {
    return base_model_name;
  }

  // If an older firmware is used, print a notice to update.
  if (highest_fw_version != -1 && firmware_version < highest_fw_version) {
    fprintf(
      stderr,
      "[NOTICE] Your DYNAMIXEL is not using the latest firmware."
      " For full performance, please download the latest DYNAMIXEL Wizard 2.0"
      " and update your DYNAMIXEL firmware."
      " See: https://emanual.robotis.com/docs/en/software/dynamixel/dynamixel_wizard2/\n");
  }

  // Log the selected model if a firmware-specific one was chosen
  if (selected_fw_version > 0) {
    fprintf(
      stderr, "[Firmware Version Selection] Device FW: %d, Selected Model: %s (FW: %d)\n",
      firmware_version, selected_file.c_str(),
      selected_fw_version);
  }

  return selected_file;

[gemini-code-assist]

The docstring claims this script checks for "Consistent line endings", but the implementation does not enforce a specific line ending (e.g., LF vs. CRLF). It relies on Python's default behavior for writing, which is OS-dependent and can lead to mixed line endings in the repository if the script is run on different operating systems.

[gemini-code-assist]

To ensure consistent line endings (LF), as mentioned in the docstring, you should specify newline='\n' when opening the file for writing. This prevents Python from using OS-specific line endings (like CRLF on Windows) and ensures all files formatted by this script have consistent LF line endings.

Suggested change

	with open(file_path, 'w', encoding='utf-8') as f:
	with open(file_path, 'w', encoding='utf-8', newline='\n') as f:

[gemini-code-assist]

Using filename.find() for prefix and suffix checks is functional, but less expressive than dedicated functions. Since boost/algorithm/string.hpp is already included, you could use boost::starts_with() and boost::ends_with() for better clarity and intent.

      if (boost::starts_with(filename, prefix) && boost::ends_with(filename, suffix))
      {
        available_firmware_versions.push_back(filename);
      }