bdaiinstitute · mhidalgo-bdai · Jan 29, 2025 · Jan 29, 2025
@@ -8,13 +8,13 @@ labels: bug
 ## Bug description
 
 **Platform**:
-- OS [e.g. Ubuntu Jammy]: 
-- ROS [e.g. Humble]: 
+- OS [e.g. Ubuntu Jammy]:
+- ROS [e.g. Humble]:
 - `proto2ros` version [e.g. ag, commit sha]:
 
 ### How to reproduce
 
-<!-- 
+<!--
   A step-by-step procedure to reproduce this bug
   i.e. the associated minimum reproducible example
   (https://stackoverflow.com/help/minimal-reproducible-example).

@@ -1,7 +1,7 @@
 ## Proposed changes
 
-<!-- 
-    A brief description of the changes you are making. 
+<!--
+    A brief description of the changes you are making.
     Make sure to refer to the issue that explains and
     motivates this patch.
 -->

@@ -24,10 +24,11 @@ repos:
   -   id: check-added-large-files
       args: ['--enforce-all', '--maxkb', '200']
   -   id: check-toml
-  -   id: end-of-file-fixer
   -   id: check-merge-conflict
   -   id: check-executables-have-shebangs
   -   id: check-shebang-scripts-are-executable
+  -   id: end-of-file-fixer
+  -   id: trailing-whitespace
 - repo: https://github.com/ssciwr/clang-format-hook.git
   rev: v14.0.0
   hooks:

@@ -68,7 +68,7 @@ We use GitHub issues to track bugs and errors. If you run into an issue with the
 Once it's filed:
 
 - The project team will label the issue accordingly.
-- A team member will try to reproduce the issue with your provided steps. 
+- A team member will try to reproduce the issue with your provided steps.
 - If the team is able to reproduce the issue, it will be confirmed as a `bug` and the issue will be left to be [addressed by someone](#your-first-code-contribution).
 
 ### Requesting Features
@@ -95,7 +95,7 @@ Feature requests are tracked as [GitHub issues](https://github.com/bdaiinstitute
 
 ### Your First Code Contribution
 
-- Install a suitable [ROS distribution](https://docs.ros.org/en/humble/Installation.html). 
+- Install a suitable [ROS distribution](https://docs.ros.org/en/humble/Installation.html).
 
 - Fork this repository on GitHub.
 
@@ -107,7 +107,7 @@ Feature requests are tracked as [GitHub issues](https://github.com/bdaiinstitute
   git clone https://github.com/user-name/proto2ros.git
   cd -
   ```
-  
+
 - Install `pre-commit` hooks for it:
 
   ```sh

@@ -37,7 +37,7 @@ simplify bridging Protobuf and ROS 2 message code.
 
 Protobuf enumeration and message definitions are translated to equivalent ROS 2 message definitions.
 Protobuf definitions, including comments, are extracted from Protobuf descriptor sets, as generated by
-[`protoc`](https://protobuf.dev/programming-guides/techniques/#self-description). More than one ROS 2 
+[`protoc`](https://protobuf.dev/programming-guides/techniques/#self-description). More than one ROS 2
 message definition may be necessary to represent a given Protobuf definition, as explained in the
 [map types](#map-types) and [one-of fields](#one-of-fields) subsections.
 
@@ -84,7 +84,7 @@ following rules, on first match wins basis:
 - A user-defined message mapping in `proto2ros` configuration matches.
   Fully qualified message names are used verbatim.
 - A user-defined or implicit package mapping in `proto2ros` configuration matches.
-  If multiple matches are found, the longest match applies. Fully qualified message 
+  If multiple matches are found, the longest match applies. Fully qualified message
   names are [camel-cased](https://en.wikipedia.org/wiki/Camel_case).
 - Passing unknown Protobuf messages is allowed by `proto2ros` configuration.
   Then `proto2ros/AnyProto` is used.
@@ -298,7 +298,7 @@ uint8 VALUE_FIELD_SET=1
 
 string value
 
-uint8 has_field 255 
+uint8 has_field 255
 ```
 
 </td>
@@ -308,7 +308,7 @@ uint8 has_field 255
 
 Note that, to match ROS 2 message semantics, the bit mask is fully set by default. That is, all fields are assumed to be present by default.
 
-**Implementation note**: bit masks can be 8, 16, 32, or 64 bit long, depending on the number of optional fields. Protobuf messages 
+**Implementation note**: bit masks can be 8, 16, 32, or 64 bit long, depending on the number of optional fields. Protobuf messages
 with more than 64 optional fields are therefore not supported.
 
 ##### Repeated fields
@@ -376,7 +376,7 @@ equivalence is shown below.
 message Timestamp {
   oneof value {
     uint64 seconds_since_epoch = 1;
-    string datestring = 2; 
+    string datestring = 2;
   }
 }
 ```
@@ -536,7 +536,7 @@ string location
 ### Code generation
 
 To simplify conversion from Protobuf messages to equivalent ROS 2 messages and back, `proto2ros` generates conversion code,
-nicely wrapped around `convert(from, to)` function overloads (i.e. type dispatched). Note, however, that conversion code is 
+nicely wrapped around `convert(from, to)` function overloads (i.e. type dispatched). Note, however, that conversion code is
 only generated for message equivalences that `proto2ros` itself generated in full. For ad-hoc equivalences, as specified using
 message mappings, the user must implement the corresponding overloads. For auxiliary messages underpinning enums, map types,
 one-of fields, and the like, no overloads are generated at all (as there is no Protobuf message to convert to/from).
@@ -556,7 +556,7 @@ type annotated, under a unique name. This name is derived from argument type nam
 - `convert_{ros_package_name}_{ros_message_name}_message_to_{proto_package_name}_{proto_message_name}_proto` for ROS 2 message
    to Protobuf message conversion
 - `convert_{proto_package_name}_{proto_message_name}_proto_to_{ros_package_name}_{ros_message_name}_message` for Protobuf message
-   to ROS 2 message conversion 
+   to ROS 2 message conversion
 
 All message names above are [snake-cased](https://en.wikipedia.org/wiki/Snake_case). Note that user-defined overloads for ad-hoc
 equivalences must follow the same pattern.
@@ -581,7 +581,7 @@ Note that user-defined overloads for ad-hoc equivalences must follow the same pa
 
 ## Configuration
 
-Both message and code generation are configured by a number of settings, listed below. 
+Both message and code generation are configured by a number of settings, listed below.
 
 | Name | Description | Default value |
 |---|---|---|
@@ -592,7 +592,7 @@ Both message and code generation are configured by a number of settings, listed
 | `any_expansions` | A mapping from fully qualified Protobuf field names (i.e. a fully qualified Protobuf message name followed by a dot "." followed by the field name) of `google.protobuf.Any` type to Protobuf message type sets that these fields are expected to pack. A single Protobuf message type may also be specified in lieu of a single element set. All Protobuf message types must be fully qualified. | `{}` |
 | `allow_any_casts` | When a single Protobuf message type is specified in an any expansion, allowing any casts means to allow using the equivalent ROS message type instead of a dynamically typed, `proto2ros/Any` field. For further reference on any expansions, see `Any types` section below. | `True` |
 | `known_message_specifications` | A mapping from ROS message names to known message specifications. Necessary to cascade message generation for interdependent packages. | `{}` |
-| `cpp_headers` | Set of C++ headers to be included (as ``#include <{header}>``) in generated C++ conversion headers. Typically, Protobuf and ROS message C++ headers. | `[]` | 
+| `cpp_headers` | Set of C++ headers to be included (as ``#include <{header}>``) in generated C++ conversion headers. Typically, Protobuf and ROS message C++ headers. | `[]` |
 | `inline_cpp_namespaces` | Set of C++ namespaces bearing conversion overloads, for which unqualified lookup (``using {namespace}::Convert``) is necessary in generated C++ conversion sources. | `[]` |
 | `python_imports` | Set of Python modules to be imported (as `import <module-name>`) in generated conversion modules. Typically, Protobuf and ROS message Python modules. | `[std_msgs.msg, proto2ros.msg, builtin_interfaces.msg, google.protobuf.any_pb2, google.protobuf.duration_pb2, google.protobuf.struct_pb2, google.protobuf.timestamp_pb2, google.protobuf.wrappers_pb2]` |
 | `inline_python_imports` | Set of Python modules to be imported into module scope (as `from <module-name> import *`) in generated conversion modules. Typically, conversion Python modules. | `[proto2ros.conversions.basic]` |
@@ -636,7 +636,7 @@ protobuf_generate(
 
 # Build generated C++ code
 add_library(${PROJECT_NAME}_proto SHARED ${proto_cpp_sources})
-target_include_directories(${PROJECT_NAME}_proto PUBLIC 
+target_include_directories(${PROJECT_NAME}_proto PUBLIC
   "$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}>"
   "$<INSTALL_INTERFACE:include/${PROJECT_NAME}>"
 )
@@ -679,7 +679,7 @@ target_link_libraries(${PROJECT_NAME}_conversions
 ament_target_dependencies(${PROJECT_NAME}_conversions builtin_interfaces proto2ros rclcpp)
 
 # Install generated Python _pb2 and conversion code to the
-# Python package that is implicitly defined and installed by the 
+# Python package that is implicitly defined and installed by the
 # rosidl pipeline
 rosidl_generated_python_package_add(
   ${PROJECT_NAME}_additional_modules
@@ -698,7 +698,7 @@ install(
 
 # Install C++ Protobuf messages and conversion libraries
 install(
-  TARGETS 
+  TARGETS
     ${PROJECT_NAME}_proto
     ${PROJECT_NAME}_conversions
   EXPORT ${PROJECT_NAME}