Ros2_canopen: EDS DefaultValue & Cache Mechanism Discussion
Introduction
In the realm of ROS2 (Robot Operating System 2) and CANopen communication, the ros2_canopen package plays a pivotal role in enabling seamless interaction with industrial devices, particularly motor drives. When delving into the intricacies of ros2_canopen, a pertinent question arises concerning the absence of certain features present in its ROS1 counterpart. This article aims to explore the missing EDS (Electronic Data Sheet) DefaultValue usage and cache mechanism in ros2_canopen, shedding light on the underlying reasons and potential implications. By understanding these aspects, developers and users can gain valuable insights into the design choices made in ros2_canopen and how they impact its functionality and performance. This discussion stems from observations made while comparing the ros_canopen (ROS1) source code with its ROS2 counterpart. In ROS1, an internal cache mechanism is present, allowing the retrieval of object dictionary values, including the DefaultValue from an .eds file, without requiring constant requests to the motor driver. However, this caching behavior appears to be absent in the ros2_canopen implementation. This article will explore the potential reasons for this omission and discuss the implications for users and developers working with ros2_canopen.
The Bug: A Deep Dive into Missing Features
The core issue at hand revolves around the observation that ros2_canopen does not seem to implement the caching behavior found in its ROS1 predecessor. Furthermore, it appears that the DefaultValue defined in the .eds file is not utilized in ROS2. This raises fundamental questions about the design choices made during the transition from ROS1 to ROS2. Let's delve deeper into the specifics of the issue. The original poster of the discussion noticed this discrepancy while reviewing the source code. The ROS1 version of ros_canopen includes an internal cache that allows retrieving specific object dictionary values, such as the DefaultValue from a .eds file. This cache mechanism optimizes performance by reducing the need to send frequent requests to the motor driver. In contrast, the ros2_canopen implementation does not appear to have this caching functionality. This means that every time a value is needed, a request must be sent to the driver, which can potentially increase latency and network traffic. The absence of DefaultValue usage is another critical point. In ROS1, the DefaultValue specified in the .eds file is used to initialize certain parameters or settings. This ensures that the system starts with a known and valid configuration. However, in ros2_canopen, it seems that these default values are not being utilized. This can lead to unexpected behavior or errors if the driver does not have a default value configured for a particular parameter. This issue is further highlighted by a specific scenario involving object 0x6502 (Supported Drive Modes). In this case, the motor drive was reporting only zeros for this object, even though it correctly switched modes when commanded. This discrepancy forced the user to bypass the
