This issue tracks the progression of packages in common_interfaces that have been deemed necessary for Quality Level 1 and a 1.0 version level. It follows the outline described in REP 2004.

The packages slated for Quality Level 1 for ROS 2 Foxy are:

• diagnostic_msgs
• geometry_msgs
• nav_msgs
• sensor_msgs
• shape_msgs
• std_msgs
• stero_msgs
• trajectory_msgs
• visualization_msgs

Excluded for Quality Level 1 at this time:

• actionlib_msgs (set for deprecation)
• common_interfaces

Progress common to all packages:

• Version Policy
  • Follows ROS Core Quality Declaration
• Version >= 1.0.0
• Change Control Process
  • Follows ROS Core
• No testing required because these packages just define messages and services

Documentation

• Declared set of licenses
• Copyright statement in each source file
  • Copyright statements aren't needed in msg/srv files

Dependencies:

• non-ROS dependencies are equivalent level 1

Platform Support

• Supports all tier 1 platforms

Progress of specific packages

diagnostic_msgs

Documentation

• Per-feature documentation.
• Per-item documentation in public API.
• Quality Declaration document

Dependencies:

• Runtime "ROS" dependencies are level 1
  • rosidl_default_runtime
  • builtin_interfaces
  • unique_identifier_msgs
• non-ROS dependencies are equivalent level 1

geometry_msgs

Documentation

• Per-feature documentation.
• Per-item documentation in public API.
• Quality Declaration document

Dependencies:

• Runtime "ROS" dependencies are level 1
  • rosidl_default_runtime
  • std_msgs
• non-ROS dependencies are equivalent level 1

nav_msgs

Documentation

• Per-feature documentation.
• Per-item documentation in public API.
• Quality Declaration document

Dependencies:

• Runtime "ROS" dependencies are level 1
  • rosidl_default_runtime
  • builtin_interfaces
  • geometry_msgs
  • std_msgs
• non-ROS dependencies are equivalent level 1

sensor_msgs

Documentation

• Per-feature documentation.
• Per-item documentation in public API.
• Quality Declaration document

Testing:

• Missing tests for distortion_models.hpp, fill_image.hpp, point_field_conversion.hpp

Dependencies:

• Runtime "ROS" dependencies are level 1
  • rosidl_default_runtime
  • builtin_interfaces
  • geometry_msgs
  • std_msgs
• non-ROS dependencies are equivalent level 1

shape_msgs

Documentation

• Per-feature documentation.
• Per-item documentation in public API.
• Quality Declaration document

Dependencies:

• Runtime "ROS" dependencies are level 1
  • rosidl_default_runtime
  • geometry_msgs
• non-ROS dependencies are equivalent level 1

std_msgs

Documentation

• Per-feature documentation.
• Per-item documentation in public API.
• Quality Declaration document

Dependencies:

• Runtime "ROS" dependencies are level 1
  • rosidl_default_runtime
  • builtin_interfaces
• non-ROS dependencies are equivalent level 1

std_srvs

Documentation

• Per-feature documentation.
• Per-item documentation in public API.
• Quality Declaration document

Dependencies:

• Runtime "ROS" dependencies are level 1
  • rosidl_default_runtime
• non-ROS dependencies are equivalent level 1

stereo_msgs

Documentation

• Per-feature documentation.
• Per-item documentation in public API.
• Quality Declaration document

Dependencies:

• Runtime "ROS" dependencies are level 1
  • rosidl_default_runtime
  • std_msgs
  • sensor_msgs
• non-ROS dependencies are equivalent level 1

trajectory_msgs

Documentation

• Per-feature documentation.
• Per-item documentation in public API.
• Quality Declaration document

Dependencies:

• Runtime "ROS" dependencies are level 1
  • rosidl_default_runtime
  • std_msgs
  • geometry_msgs
  • builtin_interfaces
• non-ROS dependencies are equivalent level 1

visualization_msgs

Documentation

• Per-feature documentation.
• Per-item documentation in public API.
• Quality Declaration document

Dependencies:

• Runtime "ROS" dependencies are level 1
  • rosidl_default_runtime
  • std_msgs
  • geometry_msgs
  • builtin_interfaces
• non-ROS dependencies are equivalent level 1

This is a follwup to the pre Foxy Message API review

There were multiple comments about differentiation and clarity. Along the lines of the MultiDOFJointState represents the same information as the JointState for Multi Degreee of Freedom Joints as such the naming is specifically following the same pattern for a similar class of joints.

This is a follwup to the pre Foxy Message API review

Buttons seem to be bools. Are there buttons which have different values? Will the bools make API easier? Will the bool reduce content on the wire?

https://github.com/ros2/common_interfaces/pull/86/files#r392501587

Feature request

Feature description

Does it make sense to fill out the set of std_srvs to match the set of std_msgs? For example, there is a SetBool.srv now that takes a bool and returns a bool success and string message, it would be nice to also have a SetFloat64.srv that takes a float64 and returns a bool success and string message.

Implementation considerations

This would be easy to implement, just copying the pattern of the SetBool.srv, with a matching srv file for each msg in std_msgs or at least some or most of them. I am happy to add these and submit a pull request if others think this is appropriate.

There has been a commit to master to disable all linters on the sensor_msgs package (a0234f2).

There may have been some offline discussion about this already, but if not then @clalancette could you please re-enable linters on this package and only disable the copyright? I have seen that you've opened ament/ament_lint#72 in the meantime 👍

In 5240924 I just copied them over 1 for 1, only removing trailing whitespace and ensuring a newline at the end of the files. You mentioned that there would be some changes that need to be made to the fields? What additional things should I check? Some things I plan to do currently:

• Replace instances of time and duration with builtin_interfaces/Time and builtin_interfaces/Duration.
• Clean up comments where appropriate, e.g. Header still refers to conventions about numeric frame_id's.

I'll also propose pr's for some more substantial changes which I think we'll have to discuss before committing.

Is it required to always use <package_name>/<msg_name> now? Or is just the <msg_name> allowed within the same package? I think it's the former, and if so, I think we'll need to fix that in a few places as well.

@ros2/owners

Is there any way to print the entire message as String as ROS does with stringstream?
Example:

std_msgs::msg::String msg;
std::stringstream ss;
ss << msg;
RCLCPP_INFO(node->get_logger(), "%s\n",ss.str().c_str());

Feature request

Feature description

PoseWithCovariance msg has wide usage in localization based applications. Systems offering multi-robot pose estimation, or even localization systems like the AMCL package implemented in the ROS Navigation stack with multiple particle clusters end up estimating multiple pose values with some degree of uncertainty attached to each such pose. Currently, there's no way to publish such pose estimates while keeping the covariance information intact.

Adding a PoseWithCovarianceArray msg, similar to PoseArray msg, will also enable visualization of such messages in RViz with the addition of a plugin based on the rviz plugins of PoseArray and PoseWithCovariance will provide a good debugging tool.

Implementation considerations

The following msg definition should work:

# This represents an array of poses in free space with uncertainty with a header for global reference.

std_msgs/Header header

PoseWithCovariance[] poses

Feature request

Feature description

Most popular USB cameras that are used in mobile/hobby robots, such as the Logitech C9xx cameras, provide images in YUV 4:2:2 format in YUYV order.

There is a YUV422 encoding defined in image_encodings.hpp but that is defined to be in UYVY order.

With an encoding constant defined for YUYV order we can then go on to handle that format in e.g. cv_bridge to convert it to other formats so there are no custom solutions needed like done in the ROS 1 usb_cam driver.

Implementation considerations

The implementation will be almost the same as for YUV422. The main consideration I think is the naming. Looking at https://www.fourcc.org/yuv.php the canonical name for this format seems to be YUY2, with YUYV being a synonym. OpenCV indicates the same in its conversion codes (e.g. COLOR_YUV2RGB_YUYV = COLOR_YUV2RGB_YUY2).

With that I'd propose either:

1. YUY2
2. YUV422_YUY2 <-- seems best to me
3. YUV422_YUYV

I'd be happy to make a PR for this if this is accepted and a name is decided, and I then plan to add handling of it in cv_bridge as I'd like to use that in our V4L2 camera driver.

This is a follwup to the pre Foxy Message API review

https://github.com/ros2/common_interfaces/pull/86/files#r392491840

This is a follow up to the Aggregate Foxy Message API Review

The DisparityImage has a header that's documented as it will likely be removed in a future release.

Since that was several years ago are we ready to remove it now? The one question is whether the TimeSynchronizer can support introspecting into the internal image headers.

Bug report

Required Info:

• Operating System:
  • Ubuntu 20.04
• Installation type:
  • from source
• Version or commit hash:
  • 7597e72
• DDS implementation:
  • N/A
• Client library (if applicable):
  • N/A

Steps to reproduce issue

$ colcon build

Expected behavior

No warnings

Actual behavior

Following warnings

/usr/local/lib/python3.8/dist-packages/setuptools/dist.py:634: UserWarning: Usage of dash-separated 'script-dir' will not be supported in future versions. Please use the underscore name 'script_dir' instead
  warnings.warn(
/usr/local/lib/python3.8/dist-packages/setuptools/dist.py:634: UserWarning: Usage of dash-separated 'install-scripts' will not be supported in future versions. Please use the underscore name 'install_scripts' instead
  warnings.warn(

Additional information

Feature request

PR: https://github.com/ros2/common_interfaces/pull/167/files

Feature description

This feature adds a geometry_msgs::msg::Polygon field to the shape_msgs/msg/SolidPrimitive.msg in order to represent PRISM primitive too.

Implementation considerations

Another way would be to make this its own separate message, since the other shapes (BOX, SPHERE, CYLINDER, CONE) don't use the polygon field. But since it doesn't use any bandwidth if not used, I thought it'd be ok.

The prism would be constructed from the polygon and the dimensions[PRISM_HEIGHT].

• The polygon would be extruded on Z+ and Z- by half of the height.
• Only x and y fields of the points (geometry_msgs/Point32 type) are used
• Points of the polygon are ordered counter-clockwise.

This is a follwup to the pre Foxy Message API review

Path message is stamped, but each individual pose is also stamped. It's unclear what each stamp means. Is the stamp in each individual pose for the time the robot needs to be at that location? If so, the frame_id that's in each individual header is still redundant with the frame_id on the Path message itself. However, stamping each individual pose seems inflexible to the robot being delayed. If it's slowed down mid path, should it target the pose at the current time, or the next closest to it's current location? This seems hard to answer if the path makes a loop such that two points on the path are physically close but far apart in time. For a little while nav2 had it's own version of Path which had non-stamped poses, though they removed it: https://github.com/ros-planning/navigation2/pull/1107/files#diff-2d8dabb75c11aa980f6c2629eba1e75f

Iterate with navigation to improve documentation of semantics of timestamps. Note that there are multiple valid behaviors for any given path representation.

This is a follwup to the pre Foxy Message API review

The deprecation in ROS 1: ros/common_msgs#130

This is a follwup to the pre Foxy Message API review

https://github.com/ros2/common_interfaces/pull/86/files#r392502848

When will more messages be uncommented? It would be nice if the following specific messages were uncommented in the next release:
geometry_msgs/Pose2D
geometry_msgs/PoseArray
nav_msgs/MapMetaData
nav_msgs/OccupancyGrid
nav_msgs/Path

In the pre Foxy API review it was flagged that these services appear to be named the opposite of what would be semantically expected.

Bug report

Required Info:

• Operating System:

Ubuntu 20.04LTS

• Installation type:
  • binaries
• Version or commit hash:
• DDS implementation:
• Client library (if applicable):

Steps to reproduce issue

Expected behavior

I have pulled ros2/common_interfaces into my workspace and edited sensor_msgs to adapt it to NV21 and NV12 pixel formats. However, when I go to build cv_bridge it uses the ROS2 installed version of sensor_msgs vs the adapted one in the workspace. This causes failure. However, in ROS1 this would not happen with catkin, it would default to the package in the workspace. How can I change colcon to behave like it did in ROS1?

i.e., when I build cv_bridge it should use the latest build of sensor_msgs in my work space. Instead of defaulting to the underlayed ROS2 binary sensor_msgs

I would submit a pull-request because I know it works in ROS1 but there are other packages like image_pipeline and cv_bridge that would also need pull request so that the rest of ROS is functional.

Is there a reason these aren't included?

More importantly, is there a reason why we shouldn't make these for ourselves and start using them in our API?

Is there an official place that they exist elsewhere?

Change request

In the Image, CompressedImage, and PointCloud2 messages there are data fields that have type uint8[]. I suggest these are chaged to byte[].

Change description

According to the wiki, uint8 is interpreted as a python int, whereas byte is interpreted as a python byte. For the messages where arrays of uint8 are used, it's normally because the data is some arbitrary binary format. Currently, it seems that rclpy takes this binary data, copies it out into a list[int], which client code then normally converts back to some collection of byte types for use. This is much more processing and copying than is necessary.

This should also somewhat mitigate this issue, as no range check will be necessary.

Implementation considerations

I can think of no cons of this change

connects to ros2/rosidl#190

This is a follwup to the pre Foxy Message API review

When reviewing the messages this was not fully clear.

This is a follwup to the pre Foxy Message API review

In a comment is said that full size of data array is step*rows. But there is already rows and columns defined as height and width, not sure if there could either a little mistake in the comment description or a extra variable on the usage

Feature request

Related to: #3, created via ros2/ros2#641

Port sensor_msgs/point_cloud_conversion.h and sensor_msgs/point_field_conversion.h

Feature description

sensor_msgs should contain utility methods for working with PointClouds and PointFields as it did in ROS1

Implementation considerations

Generally follow the process used in #58, by copying the ROS1 equivalent file and updating accordingly.

Bug report

Required Info:

• Operating System:
  • Ubuntu Focal (20.04)
• Installation type:
  • From source
• Version or commit hash:
  • a3a0dde
• DDS implementation:
  • N/A
• Client library (if applicable):
  • N/A

Expected Behavior

std_srvs would successfully build on the build farm in the packaging job.

Actual Behavior

It failed to build once in the nightly packaging job. I ran a manual packing job, that by luck ran on the exact same agent, and it successfully built std_srvs and then failed for unrelated reasons. This may be a flaky issue affecting all interface packages, or it may be a flaky machine specific issue.

https://ci.ros2.org/view/packaging/job/packaging_linux/2409

--- output: std_srvs
Not searching for unused variables given on the command line.
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/lib/ccache/cc
-- Check for working C compiler: /usr/lib/ccache/cc -- broken
CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

    "/usr/lib/ccache/cc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/jenkins-agent/workspace/packaging_linux/ws/build/std_srvs/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/usr/bin/make cmTC_0517d/fast && /usr/bin/make -f CMakeFiles/cmTC_0517d.dir/build.make CMakeFiles/cmTC_0517d.dir/build
    make[1]: Entering directory '/home/jenkins-agent/workspace/packaging_linux/ws/build/std_srvs/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_0517d.dir/testCCompiler.c.o
    /usr/lib/ccache/cc    -o CMakeFiles/cmTC_0517d.dir/testCCompiler.c.o   -c /home/jenkins-agent/workspace/packaging_linux/ws/build/std_srvs/CMakeFiles/CMakeTmp/testCCompiler.c
    Bus error (core dumped)
    make[1]: *** [CMakeFiles/cmTC_0517d.dir/build.make:86: cmTC_0517d] Error 135
    make[1]: Leaving directory '/home/jenkins-agent/workspace/packaging_linux/ws/build/std_srvs/CMakeFiles/CMakeTmp'
    make: *** [Makefile:121: cmTC_0517d/fast] Error 2
    
    

  

  CMake will not be able to correctly generate this project.
-- Configuring incomplete, errors occurred!
See also "/home/jenkins-agent/workspace/packaging_linux/ws/build/std_srvs/CMakeFiles/CMakeOutput.log".
See also "/home/jenkins-agent/workspace/packaging_linux/ws/build/std_srvs/CMakeFiles/CMakeError.log".
Call Stack (most recent call first):
  CMakeLists.txt:3 (project)


---
--- stderr: std_srvs
CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

    "/usr/lib/ccache/cc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/jenkins-agent/workspace/packaging_linux/ws/build/std_srvs/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/usr/bin/make cmTC_0517d/fast && /usr/bin/make -f CMakeFiles/cmTC_0517d.dir/build.make CMakeFiles/cmTC_0517d.dir/build
    make[1]: Entering directory '/home/jenkins-agent/workspace/packaging_linux/ws/build/std_srvs/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_0517d.dir/testCCompiler.c.o
    /usr/lib/ccache/cc    -o CMakeFiles/cmTC_0517d.dir/testCCompiler.c.o   -c /home/jenkins-agent/workspace/packaging_linux/ws/build/std_srvs/CMakeFiles/CMakeTmp/testCCompiler.c
    Bus error (core dumped)
    make[1]: *** [CMakeFiles/cmTC_0517d.dir/build.make:86: cmTC_0517d] Error 135
    make[1]: Leaving directory '/home/jenkins-agent/workspace/packaging_linux/ws/build/std_srvs/CMakeFiles/CMakeTmp'
    make: *** [Makefile:121: cmTC_0517d/fast] Error 2
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:3 (project)


---

I assume, based on the name, that there is a convention of only using sensor_msgs for feedback from sensors.

There are times, though, when it would be nice to set a sensor value as a goal or target to use for control. Would it be considered bad form to use a sensor_msg for a control topic? There would be a name mismatch, but it might be nice to have the goal data in exactly the same form as the feedback data.

Using control_msgs for control topics would be a better fit, but as control_msgs and sensor_msgs are in separate repositories, they seem to diverge in places in the latest releases or at least have that potential.

Would it be better to just use a sensor_msg for a control topic and not worry about the name mismatch or would it be better to work with the maintainers of the control_msgs repository to make sure it more closely follows sensor_msgs? Or could it make sense to add a message category to common_interfaces that mirrors sensor_msgs but is used for goal or target topics rather than feedback topics?

This is a follwup to the pre Foxy Message API review

From:

This is a follwup to the pre Foxy Message API review

GridCells
Are the points in cells the center point? It could use some documentation?

MapMetaData:
Is origin the center point of the (0,0) cell? Which direction do cell coordinates increase? Is (0,0) x,y in a right handed coordinate system such that (0,0) is the bottom right cell, or is it row,col such that (0,0) is the top left cell?

Feature request

Feature description

Hello there! Is it possible to include the moveit_msgs as an interface in the next release?

Feature request

ros_msgs/point_cloud2.py from here: http://docs.ros.org/jade/api/sensor_msgs/html/point__cloud2_8py.html is not yet in ROS2.

Feature description

This is needed to extract field information from subscribed PointCloud2 messages. I think anyone wanting to subscribe to PointCloud2 messages with a Python ROS2 node will need this.

This is a follwup to the pre Foxy Message API review

• Comment: Consider replacing NavSatFix with gps_common/GPSFix or add some of the fields from GPSFix (the orientations specifically).
  This better supports dual antenna gps setups where an accurate heading can be provided and synced with the position fix.
• Suggested Action:
  Consider a extending the message with an optional orientation. Or consider a new extended message with orientation added. This message is specifically generic to all GNSS systems versus the GPS one has GPS specific data so is not suitable to be replaced.

Hi,

I'm trying to compile ROS2 Alpha4 from it sources in armhf. Before trying to compile in armhf I have compiled in my x86 and everything works fine.

The issue is in the package builtin_interfaces during the installation process. It looks like the python msgs are not generated.

CMake Error at ament_cmake_symlink_install/ament_cmake_symlink_install.cmake:155 (message):
ament_cmake_symlink_install_files() can't find
'/home/erle/ros2_ws/build/builtin_interfaces/rosidl_generator_py/builtin_interfaces/msg/_duration.py'
Call Stack (most recent call first):
ament_cmake_symlink_install/ament_cmake_symlink_install.cmake:344 (ament_cmake_symlink_install_files)
cmake_install.cmake:36 (include)

Feature request

Feature description

• homologate the Transform and Pose message composed types so its easier to convert between them (which is very common within Nav2 / mobile robotics users).

E.g.

# Pose
        Point position
        Quaternion orientation

# Transform
        Vector3 translation
        Quaternion rotation

Change both to use either Point or Vector3 such that:

pose.position = transform.translation

is possible without having to specify each field:

pose.position.x = transform.translation.x
pose.position.y = transform.translation.y
pose.position.z = transform.translation.z

Its a little strange we have both Vector3 and Point containing the exact same fields (3 float64 x,y,z).

Implementation considerations

• Breaks ABI for the message, but shouldn't involve many, if any, code changes since the field are are exactly the same

Feature request

Feature description

There actionlb_msgs defined in this repository appear to be a duplicate of the action_msgs defined in rcl_interfaces: https://github.com/ros2/rcl_interfaces/tree/master/action_msgs

It is confusing having both of these as it isn't clear which one should be used and may cause fragmentation going forward. If possible one of these should be deleted or at the very least renamed.

Implementation considerations

I assume that one of these is here for some historical reason. If there are dependency reasons that one of these cannot be deleted yet then it would be good to at least mark them as deprecated and document what should be used. If someone knows which of these should actually be kept going forward it would be nice to have that information added to this issue.

Now that ament/ament_lint#73 has been merged, we should be able to re-enable copyright linting in the sensor_msgs package. It is probably just a one line change.

This is a follwup to the pre Foxy Message API review

Comment: probability being 0-100 doesn't take advantage of all the bits the int8 type offers. 0-255 where 255 is 100% probability would have slightly better resolution.

Bug report

It looks like I've found one more conflict with Windows SDK 8.1.
Windows SDK defines DELETE macro in winnt.h.
src\ros2\common_interfaces\visualization_msgs\msg\Marker.msg uses
uint8 DELETE=2

Required Info:

• Operating System:
  Win 8.1
• Installation type:
  source
• Version or commit hash:
  beta3-release
• DDS implementation:
  RTI Connext
• Client library (if applicable):
  rmw_connext_cpp

Steps to reproduce issue

ament build

Expected behavior

compile sucesss

Actual behavior

compile fails

Additional information

@serge.nikulin

Bug report

Required Info:

• Operating System:
  • Ubuntu 20.04
• Installation type:
  • Debians
• Version or commit hash:
• DDS implementation:
• Client library (if applicable):
  • ros 1

Steps to reproduce issue

I'm doing something like this:

sensor_msgs::PointCloud2ConstIterator<T> iterX(rosMsg, fieldNames[0]);
sensor_msgs::PointCloud2ConstIterator<T> iterY(rosMsg, fieldNames[1]);
sensor_msgs::PointCloud2ConstIterator<T> iterZ(rosMsg, fieldNames[2]);

for (size_t i = 0; i < pointCount; ++i, ++iterX, ++iterY, ++iterZ)
{
  view(0, i) = *iterX;
  view(1, i) = *iterY;
  view(2, i) = *iterZ;
}

In the above code snippet, view is a block of an Eigen matrix, pointCloudMsg is a ROS message of type sensor_msgs/PointCloud2. I'm filling the data from the buffer into the matrix.

Note that even though the above code uses the * operator to access the value, I have also used the [ ] operator, and the results are requite similar.

Expected behavior

I would expect the above loop to be auto-vectorized by my compiler (gcc 9.3.0). However, it seems to be running in scalar mode. I'm building in RelWithDebInfo with O3.

The iterator is a really cool component that is shipped with sensor_msgs, but I might be using it wrong, or there might be some element in the code that makes it difficult for the compiler to figure out how to simplify the above construct and vectorize it.

Actual behavior

The loop presented above runs in scalar mode, it's fast. But I would still like to still try to vectorize it, because I have to fulfill a resource limit.

Additional information

Another issue related: microsoft/Azure_Kinect_ROS_Driver#56 (comment)

And some questions:

1. Am I using the iterator in the right way?
2. Why are there so many casts in the operators from the iterator?
3. Am I traversing the msg buffer in the most efficient way? Should I re-think the loop?

I propose that we merge builtin_interfaces with std_interfaces, primarily because I don't see why Time and Duration are "different enough" to justify their own interface package.

People will be typing those identifiers enough that having them in an "obvious" place next to other "obvious" lowest-level types seems valuable.

This is a follow up to the Aggregate Foxy Message API Review

Followup to: https://github.com/ros2/common_interfaces/pull/86/files#r392505128

We should look at moving any of the messages that are not actually standard to something more like example_msgs this will set expectations more clearly.

This could have wide ranging effects and it might be worth adding explicit warnings into the generators to help with the migration process.

This is a follwup to the pre Foxy Message API review

After validating that there's minimal usage of the original PointCloud we should hard deprecate it and plan for removal in ROS 2 G.

https://github.com/ros2/common_interfaces/pull/86/files#r392503804

Feature request

Add a message with JointStates and the root translation/orientation with respect to world.

Feature description

To get an atomic representation of the robot state, without the delay of waiting for a TF2 message, it would be nice to have a single message that includes both the joint states as well as the root joint transform to world.

Implementation considerations

Several solutions come to mind

• A merger between MultiDoFJointState and JointState, were you can freely specify a combination of JointStates with 1 or 6 DoF's.

• Adding a single Transform to JointState. However, this will not be useful for robotic systems with multiple free floating root joints that are controlled by a single monolithic controller.

A solution could be to use MultiDoFJointState for 1 degree of freedom joints, however it can be tricky to extract the joint angles from quaternions and there is a large overhead in data usage.

This is a follwup to the pre Foxy Message API review

Any reason in particular for the service this includes the extra initial_pose field? (in comparison to the getMap.srv that only returns a map)

When I build my overlay workspace with cmd:
ament build --cmake-args -DCMAKE_BUILD_TYPE=Debug

It shows:

-- Found ament_cmake: 0.4.0 (/media/nvidia/data/code/ros2_workspace/install/share/ament_cmake/cmake)
-- Using PYTHON_EXECUTABLE: /usr/bin/python3
-- Found rclcpp: 0.4.0 (/media/nvidia/data/code/ros2_workspace/install/share/rclcpp/cmake)
-- Found rmw_implementation_cmake: 0.4.0 (/media/nvidia/data/code/ros2_workspace/install/share/rmw_implementation_cmake/cmake)
-- Found std_msgs: 0.4.0 (/media/nvidia/data/code/ros2_workspace/install/share/std_msgs/cmake)
-- Found geometry_msgs: 0.4.0 (/media/nvidia/data/code/ros2_workspace/install/share/geometry_msgs/cmake)
CMake Error at /media/nvidia/data/code/ros2_workspace/install/share/rosidl_cmake/cmake/rosidl_generate_interfaces.cmake:129 (message):
  Packages installing interfaces must include
  '<member_of_group>rosidl_interface_packages</member_of_group>' in their
  package.xml
Call Stack (most recent call first):
  CMakeLists.txt:58 (rosidl_generate_interfaces)


-- Configuring incomplete, errors occurred!
See also "/media/nvidia/data/code/ros2_overlay_workspace/build/adlink_ddsbot/CMakeFiles/CMakeOutput.log".

However, I can find <member_of_group>rosidl_interface_packages</member_of_group>
on package.xml of /media/nvidia/data/code/ros2_workspace/src/ros2/common_interfaces/geometry_msgs package.

Why it can not detect <member_of_group>rosidl_interface_packages</member_of_group> line?
And how to solve it?
Thank you~

I was not able to locate the sensor_msgs/BatteryState msg anywhere in the ros2 repo. However I did notice that all the other messages from sensor_msgs have been ported. Am I missing something?

This is a follwup to the pre Foxy Message API review

If the point cloud is unordered, is row_step the length of data?

Comment: point_step seems to assumes a fields for a point are adjacent. What if the source data actually has each channel adjacent (all x values, then all y values, then all z values, then all intensities, etc)? Does the data need to be reordered to fit in this message?

What are the possible names of point field? I've seen x, y, z, xyz before, but I don't know of any documentation about those being standard.

https://github.com/ros2/common_interfaces/pull/86/files#diff-4fa5d39b533930879a61949f36d238cbR231

Feature request

Feature description

zero copy is a shm based transport layer of ros2 that can reduce cpu usage and latency, especially for large size of data like pointcloud or image.

the mainstream of zero copy of ros2 is cyclonedds+iceoryx, see apex's ros2_shm_demo

I have created a repo ros2_shm_msgs and give some pointcloud msg definitions and an early demo.

The problem is there will be a lot of definitons according to the size of pointcloud.

see 2021-08-05-Eclipse-iceoryx-developer-meetup for details.

So is there a method to define a parameterization of msg definition?

Or is there any way to workaroud?

Thanks.

This is a follwup to the pre Foxy Message API review

Create new Covariance representation (3x3 upper triangle and 6x6 upper triangle) as well as potential helper functions. Identify areas to leverage it and then determine a migration path. New messages can leverage it, but existing ones will have a long migration.

They can likely be also reduced to floats to cut the size of the message as well.

ROS 1's sensor_msgs contains C++ headers and Python modules that provide some utilities for the generated message code data types, e.g. filling an image message or iterating over a point cloud.

I avoided bring that with the current migration effort. We should decide if we want to host those utilities elsewhere of if we want them in the sensor_interfaces package, similar to how it is laid out in ROS 1. It seems like it would be best if those things were in a sensor_interfaces_utilities package instead, but maybe there is a good reason for the current colocation in ROS 1.

TODO: update these entries in the migrated messages once this is done:

• common_interfaces/sensor_interfaces/msg/CameraInfo.msg

  Line 14 in 7bcca49

  # detail at http://www.ros.org/wiki/image_pipeline/CameraInfo.

• common_interfaces/sensor_interfaces/msg/CameraInfo.msg

  Line 58 in 7bcca49

  # sensor_msgs/distortion_models.h. For most cameras, "plumb_bob" - a

• common_interfaces/sensor_interfaces/msg/Image.msg

  Line 22 in 7bcca49

  # taken from the list of strings in include/sensor_msgs/image_encodings.h

Also look into avoiding things like valid encoding values being captured in C++ headers and instead capture them in constants in the messages. Again, there might be a good reason for this, but it smells to me.

Feature request

add sensor_msgs_py to Foxy

Feature description

Foxy will be the default distro for awhile now and the sensor_msgs_py has already been merged into the master branch for this repo. I was just wondering if it would be possible to also release it for the foxy branch as well.

Implementation considerations

should just be a PR/merge I think. ive tested it and it compiles just fine