Device Type verification fails due to strict hex formatting/padding in EDS DefaultValue [0x1000]

[freezeLUO]

Issue Title

Device Type verification fails due to strict hex formatting/padding in EDS DefaultValue [0x1000]

Description

I encountered an issue where the node startup fails during the Device Type verification phase (0x1000).

The issue arises when the DefaultValue in the EDS file is written as a hex string without full 32-bit padding (e.g., 0x420192), while the driver expects a fully padded format (e.g., 0x0420192 or 0x00420192) or strictly matches the string representation.

Even though 0x420192 and 0x0420192 represent the exact same numeric value, the driver treats them as a mismatch (or fails to parse the shorter one correctly against the UINT32 type), preventing the motor from initializing.

Environment

• OS: Linux (Ubuntu 24.04)
• ROS Distro: ROS 2 Jazzy
• Package: ros2_canopen
• Device Object: [1000] Device Type (DataType 0x0007 - UINT32)

Steps to Reproduce

1. Use a CANopen device where index 0x1000 returns the value 0x420192 (CiA 402 Servo Drive usually involves specific bits, this is an example value).
2. Modify the EDS file [1000] section to use a short hex format:

   [1000]
   ParameterName=Device Type
   ObjectType=0x7
   DataType=0x0007
   AccessType=ro
   DefaultValue=0x420192  <-- Short hex format (6 digits)
   PDOMapping=0

3. Launch the lifecycle manager/driver.

Current Behavior

The driver reports a mismatch or consistency error regarding the Device Type and fails to reach the configured state.
(If you have the specific error log, paste it here, e.g., "Device type mismatch", otherwise keep this generic description)

Expected Behavior

The verification logic should compare the numeric values of the Device Type, not the string representation or strict byte padding.
0x420192 should be considered equal to the value read from the device (typically returned as a standard UINT32), and the node should start successfully.

Possible Fix

Ensure that the DefaultValue parsed from the EDS is normalized to an integer before comparing it with the value uploaded from the device via SDO. If the check is currently doing a string comparison or strict byte-array comparison, it should be relaxed to allow equivalent numeric values.