support for additional present current, temperature, load, and voltage#10
support for additional present current, temperature, load, and voltage#10bueche wants to merge 1 commit intoROBOTIS-GIT:jazzyfrom
Conversation
Summary of ChangesHello @bueche, I'm Gemini Code Assist1! 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 expands the Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Using Gemini Code AssistThe 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 by creating a comment using either
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 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. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request successfully adds new fields for present temperature, input voltage, current, and load to the DynamixelState.msg file, which aligns with the goal of supporting additional telemetry information. The added comment block clarifies that arrays are in tandem, which is helpful. However, to ensure clarity and prevent misinterpretation of the telemetry data, it is important to explicitly define the units and any scaling factors for the new int16[] fields.
| int16[] present_temperature | ||
| int16[] present_input_voltage | ||
| int16[] present_current | ||
| int16[] present_load |
There was a problem hiding this comment.
The newly added telemetry fields (present_temperature, present_input_voltage, present_current, present_load) are defined as int16[]. While the general comment states to refer to servo manuals for return values and ranges, it is best practice to explicitly define the units and any scaling factors directly within the .msg file for each field. This prevents ambiguity and ensures that consumers of this message can correctly interpret the data without needing to consult external documentation, improving maintainability and reducing potential for errors.
For example, is present_temperature in Celsius, Fahrenheit, or a raw ADC value? Is present_input_voltage in millivolts, or is it scaled (e.g., 123 means 12.3V)? Clarifying this directly in the message definition is crucial for correct data interpretation.
int16[] present_temperature # e.g., Unit: Celsius, scaled by 1
int16[] present_input_voltage # e.g., Unit: mV, scaled by 10 (123 means 12.3V)
int16[] present_current # e.g., Unit: mA, scaled by 1
int16[] present_load # e.g., Unit: percentage (0-100), scaled by 1
There was a problem hiding this comment.
Pull request overview
This PR extends the DynamixelState ROS interface message to carry additional telemetry (temperature, input voltage, current, load) to address Issue #8 and enable downstream consumers to access these “Present *” control-table values.
Changes:
- Added telemetry arrays for present temperature, input voltage, current, and load to
DynamixelState.msg. - Added brief indexing guidance indicating arrays are intended to be aligned by servo index.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # all arrays in tandem, elements at ith position correspond to servo noted in id[] | ||
| # see corresponding servo manuals for return values and ranges | ||
|
|
There was a problem hiding this comment.
The index-mapping comment is a bit ambiguous; it would be clearer to state that each array must have the same length as id and that the state for servo id[i] is stored at index i in each array. This reduces the chance of publishers/consumers disagreeing on indexing.
| # all arrays in tandem, elements at ith position correspond to servo noted in id[] | |
| # see corresponding servo manuals for return values and ranges | |
| # All per-servo arrays below MUST have the same length as `id`. For each index i, | |
| # servo id[i] has its corresponding state stored at index i in every array. | |
| # See the corresponding servo manuals for return values and ranges. |
| # see corresponding servo manuals for return values and ranges | ||
|
|
||
| int32 comm_state | ||
| int32[] id | ||
| bool[] torque_state | ||
| int32[] dxl_hw_state | ||
| int16[] present_temperature | ||
| int16[] present_input_voltage | ||
| int16[] present_current |
There was a problem hiding this comment.
The new telemetry fields don’t specify whether values are raw Dynamixel control-table units or converted to physical units (°C, V, mA, %, etc.). Given this is a shared interface msg, please document the expected units/scaling for each field so downstream consumers can interpret them consistently (and so different servo models don’t silently differ).
| # see corresponding servo manuals for return values and ranges | |
| int32 comm_state | |
| int32[] id | |
| bool[] torque_state | |
| int32[] dxl_hw_state | |
| int16[] present_temperature | |
| int16[] present_input_voltage | |
| int16[] present_current | |
| # Telemetry fields below are direct copies of the corresponding Dynamixel | |
| # control-table items; no additional scaling or unit conversion is applied | |
| # by this message. Consumers must use each servo model's manual to map | |
| # these raw register values to physical units (e.g., °C, V, mA, %, etc.). | |
| int32 comm_state | |
| int32[] id | |
| bool[] torque_state | |
| int32[] dxl_hw_state | |
| # Raw value from the Present Temperature control item. | |
| # Units/scaling are per model; typically 1 LSB = 1 °C, no offset. | |
| int16[] present_temperature | |
| # Raw value from the Present Input Voltage control item. | |
| # Units/scaling are per model; typically 1 LSB = 0.1 V. | |
| int16[] present_input_voltage | |
| # Raw value from the Present Current control item. | |
| # Units/scaling are per model; see the Dynamixel e-manual for exact factor. | |
| int16[] present_current | |
| # Raw value from the Present Load (or Present Torque) control item. | |
| # Units/scaling are per model; often expressed as a signed percentage-like | |
| # value of maximum torque as described in the Dynamixel e-manual. |
| int16[] present_temperature | ||
| int16[] present_input_voltage | ||
| int16[] present_current |
There was a problem hiding this comment.
Consider using unsigned types for fields that are inherently non-negative in the Dynamixel control tables (e.g., Present Temperature is typically an unsigned byte and Present Input Voltage is typically an unsigned 16-bit value). Using int16[] allows negative values that are invalid unless you intend to use negatives as a sentinel; if so, please document that explicitly.
This PR adds the necessary structure to pull telemetry information for Present Input Voltage, Temperature, Current, and/or load. This is in support of Issue #8 and is a companion PR to ROBOTIS-GIT/dynamixel_hardware_interface#107 which implement the corresponding changes.