ros2 / rosidl Goto Github PK

View Code? Open in Web Editor NEW

74.0 29.0 124.0 2.58 MB

Packages which provide the ROS IDL (.msg) definition and code generation.

License: Apache License 2.0

CMake 7.03% Python 19.04% C 27.02% EmberScript 12.60% C++ 33.91% Shell 0.40%

rosidl's Introduction

rosidl

rosidl is one of the ros_core packages. See documentation for details of this package.

Packages

rosidl_adapter
- API and scripts to parse .msg/.srv/.action files and convert them to .idl
rosidl_cmake
- CMake functionality to invoke code generation for ROS interface files
rosidl_generator_c
- Generate the ROS interfaces in C
rosidl_generator_cpp
- Generate the ROS interfaces in C++
rosidl_generator_type_description
- Generate SHA256 hash values and ROS 2 interface descriptions for use by other generators
rosidl_parser
- Parser for .idl ROS interface files
rosidl_runtime_c
- Provides definitions, initialization and finalization functions, and macros for getting and working with rosidl typesupport types in C
rosidl_runtime_cpp
- Provides definitions and templated functions for getting and working with rosidl typesupport types in C++
rosidl_typesupport_interface
- Interface for rosidl typesupport packages
rosidl_typesupport_introspection_c
- Generate the message type support for dynamic message construction in C
rosidl_typesupport_introspection_cpp
- Generate the message type support for dynamic message construction in C++

rosidl's People

Contributors

Stargazers

Watchers

Forkers

blink1073 ernestmc imohame jemmy655 esteve dhood erlerobot firesurfer meyerj k-okada ros2-tw yamokosk asirobots nuclearsandwich astralien3000 reed-lau tusimple yechun1 borjaouterelo sloretz apojomovsky clearpathrobotics gonzodepedro aws-ros-dev seanyen malsbat cho3 theseankelly roverrobotics-forks tsc21 bpwilcox rotu dongheeye zhouchengming99 shashankmravindra kylemarcey j-rivero tsukuyomih2 ahcorde richiware carlossvg wesleyyue mauropasse hmhan1236 jzhang-work atyshka iuhilnehc-ynos reubenyuhe dawonn cqhan777 shonigmann pablogs9 mvukov enzobrancaccio traversaro apiyap tobias-fischer eboasson jonselling aposhian gbiggs ibnhatab hidmic stokekld tsungchent jhdcs nnmm aacex ottojo anbajwa russkel greenroom-robotics r7vme ijnek stefanfabian yashi traclabs loyvanbeek fofolevrai mjbogusz emersonknapp aditya2592 sgf201 tharinduishans duanchengwen ahans danmesh james-rms jwcs acuadros95 alexistm michaelorlov ryanf55 ashishd lianwenliangleon jmachowinski srmainwaring eprosima patrick-forks patrick-ros2

rosidl's Issues

Fix rosidl_generator_py imports

http://ci.ros2.org/job/ci_linux/1018/

configure target language

At the moment the cmake call rosidl_generate_interfaces(...) generated files for c and c++.
As far a I can see the c files aren't needed in case all projects using the generated files are written in c++.
How about adding an option to set the targeted languages? This would decrease the processing time.

Support placing message files in subfolders of "msg"

Hi,
I wanted to structure my messages in subfolders like this:

package
    |-CMakeLists.txt
    |-msg
            |-message1.msg
            |-subfolder1
                 |-message2.msg

My CMakeLists for generating the messages looks like this:

file(GLOB_RECURSE MESSAGE_FILES msg
    "*.msg"
)

rosidl_generate_interfaces(${PROJECT_NAME}
  ${MESSAGE_FILES}
  DEPENDENCIES builtin_interfaces ros2_components_msg
)

When calling ament build it fails with the error message:
Interface file with unknown parent folder:

[rosidl_generator_c] fails on static array of non-primitive type

[rosidl_generator_cpp] Use known patterns instead of random ones for reproducability

see #179 (comment)

Memory leak in nested messages

This is really a continuation of issue ros2/rclpy#79. I am just continuing to go through top offenders reported by valgrind. I'm still using a simple pub/sub in Python and valgrinding the publisher. This is what I see:

==21797== 1,153 (1,152 direct, 1 indirect) bytes in 36 blocks are definitely lost in loss record 848 of 956
==21797==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21797==    by 0xFBD4DC7: std_msgs__msg__MultiArrayDimension__create (multi_array_dimension__functions.c:43)
==21797==    by 0xF7B3457: std_msgs_multi_array_dimension__convert_from_py (_multi_array_dimension_s.c:15)
==21797==    by 0xF7B4423: std_msgs_multi_array_layout__convert_from_py (_multi_array_layout_s.c:50)
==21797==    by 0xF7ADF6F: std_msgs_float64_multi_array__convert_from_py (_float64_multi_array_s.c:37)
==21797==    by 0x9CF4B6A: rclpy_publish (_rclpy.c:282)
==21797==    by 0x4E9B9E: PyCFunction_Call (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)
==21797==    by 0x524413: PyEval_EvalFrameEx (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)
==21797==    by 0x528813: PyEval_EvalFrameEx (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)
==21797==    by 0x528813: PyEval_EvalFrameEx (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)
==21797==    by 0x52D82E: ??? (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)
==21797==    by 0x529331: PyEval_EvalFrameEx (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)

...

==21797== 1,408 (1,056 direct, 352 indirect) bytes in 33 blocks are definitely lost in loss record 866 of 956
==21797==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21797==    by 0xFBD516F: std_msgs__msg__MultiArrayLayout__create (multi_array_layout__functions.c:41)
==21797==    by 0xF7B3DA3: std_msgs_multi_array_layout__convert_from_py (_multi_array_layout_s.c:18)
==21797==    by 0xF7ADF6F: std_msgs_float64_multi_array__convert_from_py (_float64_multi_array_s.c:37)
==21797==    by 0x9CF4B6A: rclpy_publish (_rclpy.c:282)
==21797==    by 0x4E9B9E: PyCFunction_Call (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)
==21797==    by 0x524413: PyEval_EvalFrameEx (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)
==21797==    by 0x528813: PyEval_EvalFrameEx (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)
==21797==    by 0x528813: PyEval_EvalFrameEx (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)
==21797==    by 0x52D82E: ??? (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)
==21797==    by 0x529331: PyEval_EvalFrameEx (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)
==21797==    by 0x52D2E2: ??? (in /home/yamokosk/ros2_ws/ros2_env/bin/python3)

...

==21797== LEAK SUMMARY:
==21797==    definitely lost: 2,287 bytes in 111 blocks
==21797==    indirectly lost: 393 bytes in 13 blocks
==21797==      possibly lost: 16,552 bytes in 26 blocks
==21797==    still reachable: 5,028,151 bytes in 3,504 blocks
==21797==         suppressed: 0 bytes in 0 blocks
==21797== Reachable blocks (those to which a pointer was found) are not shown.
==21797== To see them, rerun with: --leak-check=full --show-leak-kinds=all

My test code is using the leak fixes I have submitted in other PR's. So first on the destruction stack is the new generated destroy function I added:

void std_msgs_float64_multi_array__destroy_ros_message(void * raw_ros_message)
{
  std_msgs__msg__Float64MultiArray * ros_message = (std_msgs__msg__Float64MultiArray *)raw_ros_message;
  (void)ros_message;

  std_msgs__msg__Float64MultiArray__destroy(ros_message);
}

Which then calls:

void
std_msgs__msg__Float64MultiArray__destroy(std_msgs__msg__Float64MultiArray * msg)
{
  if (msg) {
    std_msgs__msg__Float64MultiArray__fini(msg);
  }
  free(msg);
}

Obviously the problem here is that Float64MultiArray is a nested message and its destroy function does not reflect this. I don't mind wading through one of the other code generators to fix this, but I wanted some feedback about where to put the fix. Does this go into msg__functions.c.em?

Clean up import logic in rosidl_generator_py

See #83 #90 #91

Debug builds fail on windows due to missing python debug symbols

On windows we as missing a file python43_d.lib needed to build in Debug

http://ci.ros2.org/job/ci_windows/1127/console

An example error:

03:49:38   LINK : fatal error LNK1104: cannot open file 'python34_d.lib' [C:\J\workspace\ci_windows\ws\build\rosidl_generator_py\_various_s.ep.rosidl_typesupport_opensplice_c.c__pyext.vcxproj]

static_assert fails on test_interfaces.cpp

I am playing around with ROS2 and it seems that the static assertion check on line 107 fails on my machine (x86, 14.04, 32bit)

primitive_size = 48
primitive_static_array_size = 140

any ideas on that?

Tracking bug for message initialization in C

In porting efforts we've run into several bugs where the zero initialized behavior is relied upon, causing bugs. Having a zero initialization method as a way to make porting less fragile would be valuable. And likely can be used in other cases when the optimization of using uninitialized constructors are not as important.

This is a tracking bug to deal with field initialization of generated message code in C (originally discussed in ros2/geometry2#25).

build fails when only building FastRTPS

http://ci.ros2.org/job/ci_windows/1092/

@esteve Can you please take a look at this since it seems to be related to the Python message generator.

Add Python generator

rosidl_generator_py build flaky on the farm

See: http://ci.ros2.org/job/ci_linux/1077/console

It looks like there is a missing make dependency, so sometimes when building in parallel you get an out of order build which fails.

[rosidl_generator_py] Support packages with only services but no messages

Currently the generated library can't be loaded in that case since a required symbol isn't available. See ros2/examples#154.

Generated C source code files from rosidl_generator_py are installed

The install directory should only contain .py files and native extensions

ROS2 message format should support enums

From @calvertdw on January 8, 2018 16:53

You guys know what this means.

Constants aren't good enough. They don't constrain you to the range of values and you are able to set the field to any number you want.

// Current way

int16 FOO=0
int16 BAR=1
int16 value

// Proposed way

enum foo_bar { FOO, BAR }

Copied from original issue: ros2/ros2#447

Usage examples for introspection

Are there any usage examples for rosidl_typesupport_introspection_cpp? I managed to call rosidl_typesupport_introspection_cpp::get_message_type_support_handle<my_package::msg::MyMessage>();. But I'm not sure how to extract the IDL information. I could reverse-engineer my way through the generated *__type_support.cpp file. But that might lead to some brittle/unsafe code.

rosidl_generator_py: add array support

add message data type string to message traits

As was possible in ROS 1 (http://wiki.ros.org/roscpp/Overview/MessagesTraits) it should be possible to get the type name for a message with a template function, e.g. something like:

#include <sensor_msgs/msg/image__traits.hpp>

const char * message_type_name = rosidl_generator_traits::data_type<sensor_msgs::msg::Image>();

#include <sensor_msgs/msg/image__traits.hpp>

const char * message_type_name = sensor_msgs::msg::Image::data_type();

which would be a alias to the other one.

I'm copying the namespace in this file which is where I would add it:

https://github.com/ros2/rosidl/blob/master/rosidl_generator_cpp/resource/msg__traits.hpp.em

Which uses the rosidl_generator_traits namespace for all traits, but I think that might be better changed to rosidl_generator_cpp or something similar which is rosidl and cpp specific.

We need this in rviz (ros2/rviz#164).

On windows single element constructor lists fail to compile

The error is

"C:\Jenkins\workspace\ros2_batch_ci_windows\build\userland\userland.sln" (default target) (1) ->
"C:\Jenkins\workspace\ros2_batch_ci_windows\build\userland\ALL_BUILD.vcxproj.metaproj" (default target) (2) ->
"C:\Jenkins\workspace\ros2_batch_ci_windows\build\userland\publisher.vcxproj.metaproj" (default target) (60) ->
"C:\Jenkins\workspace\ros2_batch_ci_windows\build\userland\publisher.vcxproj" (default target) (61) ->
(ClCompile target) -> 
  C:\Jenkins\workspace\ros2_batch_ci_windows\install\include\simple_msgs/AllDynamicArrayTypes_Struct.h(35): error C2668: 'std::vector<int8_t,std::allocator<_Other>>::vector': ambiguous call to overloaded function [C:\Jenkins\workspace\ros2_batch_ci_windows\build\userland\publisher.vcxproj]
  C:\Jenkins\workspace\ros2_batch_ci_windows\install\include\simple_msgs/AllDynamicArrayTypes_Struct.h(35): error C2668: 'std::vector<uint8_t,std::allocator<_Other>>::vector': ambiguous call to overloaded function [C:\Jenkins\workspace\ros2_batch_ci_windows\build\userland\publisher.vcxproj]

At issue is the constructor lists:

  AllDynamicArrayTypes_()
  : my_bool({true, false, true})
  , my_byte({23, 42})
  , my_char({-2, 3})
  , my_float32({})
  , my_float64({-3.14l, 23.42l})
  , my_int8({-5})
  , my_uint8({5})
  , my_int16({1, 2, 3})
  , my_uint16({2, 3, 4})
  , my_int32({3, 4, 5})
  , my_uint32({4, 5, 6})
  , my_int64({5, 6, 7})
  , my_uint64({6, 7, 8})
  {
  }

The failing lines are int8 and uint8. Making them non-one length makes them pass. And making float32 one length causes the same failure.

Relevant Knowledgebase article for the error

It works fine to pass the same initializer list as an argument in the constructor. ala

my_int8 = { -5 };

This is observed on or CI machine running Windows 2012 server, but not on Windows 8. Both running VS2015 Preview.

Building multiple interfaces in the same CMake context messes up the build order

Bug report

Required Info:

Operating System:
- Ubuntu 16.04
Installation type:
- binary
Version or commit hash:
- release-ardent-20180307
DDS implementation:
- Fast-RTPS
Client library (if applicable):
- rclcpp

Steps to reproduce issue

testBuild.tar.gz

See attached test project. Build the attached test project in /testBuild with

mkdir build
cd build
cmake .. -DAMENT_CMAKE_UNINSTALL_TARGET=OFF 
make

The testproject contains two message packages which each build on their own, but when build in combination (via add_subdirectory) produce the error mentioned below.

Expected behavior

Interfaces get generated.

Actual behavior

Build order is messed up, this is the output when the test project is built:

Scanning dependencies of target matrix2_ros
[ 2%] Building CXX object CMakeFiles/matrix2_ros.dir/src/main.cpp.o
[ 4%] Linking CXX executable matrix2_ros
[ 4%] Built target matrix2_ros
Scanning dependencies of target matrix2_msgs__py
[ 6%] Generating Python code for ROS interfaces
[ 6%] Built target matrix2_msgs__py
[ 8%] Generating C code for ROS interfaces
Scanning dependencies of target matrix2_msgs__rosidl_generator_c
[ 8%] Generating C code for ROS interfaces
[ 10%] Building C object implementation/CMakeFiles/matrix2_msgs__rosidl_generator_c.dir/rosidl_generator_c/matrix2_msgs/msg/mat__functions.c.o
cc: error: /home/uidq3479/Jenkins/workspace/XCitDevelopment_PR-164-OI7ZPASJZEV3XGQWBFQY2PEQXIELKYENI5G6JZQZXQR3CPC6F5NA/tests/eclipseProject/algos/matrix/testing/testbuild/build/implementation/rosidl_generator_c/matrix2_msgs/msg/mat__functions.c: Datei oder Verzeichnis nicht gefunden

Apparently necessary source files are not generated prior to compilation.

Additional information

I understand that building multiple packages in the same context is suboptimal, but feel like I am still within the bounds of what should work. If not, please advise me on how to properly implement multipackage builds that also need to work with non-ament parts of the build.

[rosidl_parser] Parse strings default values in .msg files

Context:
The ROS 2 interface definition has more features than the ROS 1 one. Setting default values for your message fields directly in the .msg files is one of them. For now the parser doesn’t parse/escape default values for strings fields, so strings that contain escape sequences, character substitution will cause bugs.

For example:

'foo\nbar'
'foo%sbar'
'foo'bar'
'foo{}bar'

So the goal is to escape every combination of characters using an additional \ in front to prevent any breakage.

Task:

Add an escape_string function to rosidl_parser
Call the escape_string function if the field type is a string here
Extend the parse value test to test default values for all field types including strings with a set of known escape sequences

related to #206

Make diff minimal when migrating msg packages from ROS1 to ROS2

When porting message packages from ROS1 to ROS2 recently I noticed that the CMake diff is so important that it's hard to see the relevant bits (how to use rosidl API and export dependencies).
It would be great to make the diff minimal for at least the message listing part.
Several possibilities:

modify ROS1 "add_message_files"/"add_service_files" to take accept an empty DIRECTORY and to be passed a relative path for messages (MyMessage -> "msg/MyMessage")
provide a utility in ROS 2 to concatenate a subdirectory string (eg msg) to each a list of message names

Both these options should allow to use the same list of messages and reduce the diff to how this list is passed to the message generation API.
There may be other alternatives, these 2 are the first ones that came to mind

[rosidl_generator_cpp] ZERO initialization of messages

I think it's a bug but would like to confirm:

If I define foo.msg:

bool[] foo [true, false, true]

And chose MessageInitialization::ZERO, foo should be allocated and populated exactly the same way as if I had

bool[] foo

right ?

Currently I get a vector of size 3 populated with zeros (same thing for bounded vectors)

Resolve dependencies correctly

Remove the temporary hack from #58 and come up with the "correct" fix for the problem.

Look into generating only one Python library per message package

This may reduce compilation time and also simplify our CMake scripts.

'Support for non-ASCII strings in python talker/listner messages

from https://discourse.ros.org/t/ros-2-alpha8/548/13

publishing multibyte message from cpp publisher is ok

I heard: [Hello World: 130]
I heard: [Hello World: 131]
I heard: [Hello World: 132]
I heard: [こんにちは: 1]
I heard: [こんにちは: 2]
I heard: [こんにちは: 3]

But python publisher is not working

user@ubuntu-16:~/ros2_ws$ listener
I heard: [S0�0k0a0:]
I heard: [S0�0k0a0:]
I heard: [S0�0k0a0:]
^Csignal_handler(2)
user@ubuntu-16:~/ros2_ws$ listener_py 
python3: /home/user/ros2_ws/build/std_msgs/rosidl_generator_py/std_msgs/msg/_string_s.c:54: std_msgs_string__convert_to_py: Assertion `pydata != NULL' failed.
Aborted

I'll look into this but if this is very urgent, please feel free to take over

[rosidl_generator_c] Size of a ros_message (for memory allocation)

Hello,

I would like to understand how we can get the size needed for memory allocation of a ros message from rosidl_generator_c generated code.
Indeed, when dealing with rclcpp, the size (and type) of the message is transmitted by template.
But in C, this information can only pass by the type_support.

I don't know how to allocate an empty message (for use by rcl_take) with only the type_support of rosidl_generator_c. Here is my use-case. I'm currently using an over-sized block of memory to do the job, but this is very bad.

Does someone have a solution for that ?
If not, I guess it may be a feature request ?

Cheers

rosidl_generator_py is exporting invalid library

Working on the compile from source checklist and I"m getting the error below.

It looks like a forwarded library is getting incorrectly prefixed with the package name.

+++ Building 'builtin_interfaces'
Running cmake because arguments have changed.
==> '. /root/ros2_ws/build_isolated/builtin_interfaces/cmake__build.sh && /usr/bin/cmake /root/ros2_ws/src/ros2/common_interfaces/builtin_interfaces -DAMENT_ENABLE_TESTING=1 -DAMENT_CMAKE_SYMLINK_INSTALL=1 -DCMAKE_INSTALL_PREFIX=/root/ros2_ws/install_isolated/builtin_interfaces' in '/root/ros2_ws/build_isolated/builtin_interfaces'
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found ament_cmake: 0.0.0 (/root/ros2_ws/install_isolated/ament_cmake/share/ament_cmake/cmake)
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.4.3", minimum required is "3") 
-- Using PYTHON_EXECUTABLE: /usr/bin/python3
-- Override CMake install command with custom implementation using symlinks instead of copying resources
-- Found rosidl_default_generators: 0.0.0 (/root/ros2_ws/install_isolated/rosidl_default_generators/share/rosidl_default_generators/cmake)
-- Found OpenSplice: /usr/lib/libcmxml.so;/usr/lib/libcommonserv.so;/usr/lib/libdcpsgapi.so;/usr/lib/libdcpssac.so;/usr/lib/libddsconfparser.so;/usr/lib/libddsconf.so;/usr/lib/libddsdatabase.so;/usr/lib/libddsi2.so;/usr/lib/libddskernel.so;/usr/lib/libddsosnet.so;/usr/lib/libddsos.so;/usr/lib/libddsserialization.so;/usr/lib/libddsuser.so;/usr/lib/libddsutil.so;/usr/lib/libdurability.so;/usr/lib/libspliced.so;/usr/lib/libdcpsisocpp.so;/usr/lib/libdcpssacpp.so  
-- Found PrismTech OpenSplice: /usr/share/opensplice/cmake
-- Found OpenSplice: /usr/share/opensplice/cmake/../../../include/opensplice;/usr/share/opensplice/cmake/../../../include/opensplice/sys;/usr/share/opensplice/cmake/../../../include/opensplice/dcps/C++/SACPP  
-- Found OpenSplice: /usr/lib/libcmxml.so;/usr/lib/libcommonserv.so;/usr/lib/libdcpsgapi.so;/usr/lib/libdcpssac.so;/usr/lib/libddsconfparser.so;/usr/lib/libddsconf.so;/usr/lib/libddsdatabase.so;/usr/lib/libddsi2.so;/usr/lib/libddskernel.so;/usr/lib/libddsosnet.so;/usr/lib/libddsos.so;/usr/lib/libddsserialization.so;/usr/lib/libddsuser.so;/usr/lib/libddsutil.so;/usr/lib/libdurability.so;/usr/lib/libspliced.so;/usr/lib/libdcpsisocpp.so;/usr/lib/libdcpssacpp.so  
-- Found PrismTech OpenSplice: /usr/share/opensplice/cmake
-- Found OpenSplice: /usr/share/opensplice/cmake/../../../include/opensplice;/usr/share/opensplice/cmake/../../../include/opensplice/sys;/usr/share/opensplice/cmake/../../../include/opensplice/dcps/C++/SACPP  
CMake Error at /root/ros2_ws/install_isolated/rosidl_generator_py/share/rosidl_generator_py/cmake/ament_cmake_export_libraries-extras.cmake:42 (message):
  Package 'rosidl_generator_py' exports the library
  'rosidl_generator_py__rosidl_typesupport_introspection_cpp' which couldn't
  be found
Call Stack (most recent call first):
  /root/ros2_ws/install_isolated/rosidl_generator_py/share/rosidl_generator_py/cmake/rosidl_generator_pyConfig.cmake:30 (include)
  /root/ros2_ws/install_isolated/rosidl_default_generators/share/rosidl_default_generators/cmake/ament_cmake_export_dependencies-extras.cmake:21 (find_package)
  /root/ros2_ws/install_isolated/rosidl_default_generators/share/rosidl_default_generators/cmake/rosidl_default_generatorsConfig.cmake:30 (include)
  CMakeLists.txt:10 (find_package)


-- Configuring incomplete, errors occurred!
See also "/root/ros2_ws/build_isolated/builtin_interfaces/CMakeFiles/CMakeOutput.log".

type support structure and dependencies

Currently there is a single "type support" type for messages and a single one for services, rosidl_message_type_support_t and rosidl_service_type_support_t respectively. This structure is used to avoid introducing message type information into the majority of the rmw functions. For example there is one function which takes the message type and returns an instance of this type support structure, but the publish call does not need to have any information about the message type. It normally would, but instead it takes the type support structure and a void * pointing to the message. This is a very similar strategy to how DDS's API operates and allows us to a simpler rmw API with less code generation from macros, templates, or otherwise.

These types are currently defined in rosidl_generator_c, but used in both that package and the rosidl_generator_cpp package. This introduces a dependency on rosidl_generator_c for the rosidl_generator_cpp package. This bothers me a bit, but I'm not whether or not this actually matters. It seems cleaner to not have the C+ generator depend on the C one, but they might be so closely related that is doesn't actually matter.

I think that in the ideal situation, these type support types would be specified somewhere neutral and then the two generator packages could depend on the neutral package. One candidate would be in the rmw package, but then the namespace should probably change and it further couples rmw and the idl generators even more than they already are.

Another option would be to have a C++ version of these types and then both rosidl_generator_c and rosidl_generator_cpp will each define types for message and service type support. I think in this case it would make sense for them to be idiomatic and have different symbols so they are not used interchangeably. However, the problem with this approach is that you would then need C++ versions of any rmw function which takes the type support type as an argument.

Personally, I'm leaning towards doing nothing and leaving the dependency between the C and C++ generator packages, but I would also be ok with moving the type declaration to a neutral package.

Thoughts?

Improve validation and error message when parsing invalid srv

When I had a typo in a service referencing an non-existant message as a subtype, it made it all the way through the generation and failed on missing include directories when actually trying to compile the c++ type support.

We should find a way to validate this earlier and catch that it's referencing a message which does not exist and provide an error message to that effect before running generation for n languages and trying to compile some of them.

For the moment this is a low priority but should be fixed before release.

For reference this is the error shown for an invalid reference to Parameters which should be Parameter

In file included from /home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_generator_cpp/rcl_interfaces/GetParametersResponse.h:4:0,
                 from /home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_generator_cpp/rcl_interfaces/GetParameters_Service.h:5,
                 from /home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_typesupport_introspection_cpp/rcl_interfaces/GetParameters_ServiceTypeSupport_Introspection.cpp:10:
/home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_generator_cpp/rcl_interfaces/GetParametersResponse_Struct.h:12:39: fatal error: rcl_interfaces/Parameters.h: No such file or directory
 #include <rcl_interfaces/Parameters.h>
                                       ^
compilation terminated.
[  7%] Generating C++ type support for PrismTech OpenSplice
make[2]: *** [CMakeFiles/rcl_interfaces__typesupport_introspection_cpp.dir/rosidl_typesupport_introspection_cpp/rcl_interfaces/GetParameters_ServiceTypeSupport_Introspection.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/rcl_interfaces__typesupport_introspection_cpp.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
INFO com.rti.ndds.nddsgen.Main Running rtiddsgen version 2.2.0.0, please wait ...
WARN com.rti.ndds.nddsgen.antlr.auto.IdlLexer ParameterDescription_.idl line 35  preprocessor directive not supported. It will be ignored
WARN com.rti.ndds.nddsgen.antlr.auto.IdlLexer Parameter_.idl line 30  preprocessor directive not supported. It will be ignored
INFO com.rti.ndds.nddsgen.Main Done
Generating: /home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_typesupport_connext_cpp/rcl_interfaces/dds_connext/ParameterDescription_.h/cpp
INFO com.rti.ndds.nddsgen.Main Running rtiddsgen version 2.2.0.0, please wait ...
WARN com.rti.ndds.nddsgen.antlr.auto.IdlLexer ParameterDescription_.idl line 35  preprocessor directive not supported. It will be ignored
INFO com.rti.ndds.nddsgen.Main Done
Generating: /home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_typesupport_connext_cpp/rcl_interfaces/dds_connext/ParameterEvent_.h/cpp
"/home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_generator_dds_idl/rcl_interfaces/dds_opensplice/GetParametersResponse_.idl", line 7: can't find include file rcl_interfaces/dds_opensplice/Parameters_.idl
***DDS parse error Parameters_ undefined at line: 20 (searching from scope 'dds_')
Traceback (most recent call last):
  File "/home/tfoote/work/ros2/parameters/install/lib/rosidl_typesupport_opensplice_cpp/rosidl_typesupport_opensplice_cpp", line 68, in <module>
    sys.exit(main())
  File "/home/tfoote/work/ros2/parameters/install/lib/rosidl_typesupport_opensplice_cpp/rosidl_typesupport_opensplice_cpp", line 54, in main
    args.idl_pp,
  File "/home/tfoote/work/ros2/parameters/install/lib/python3.4/site-packages/rosidl_typesupport_opensplice_cpp/__init__.py", line 50, in generate_dds_opensplice_cpp
    subprocess.check_call(cmd)
  File "/usr/lib/python3.4/subprocess.py", line 557, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/idlpp', '-I', '/home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_generator_dds_idl', '-S', '-l', 'cpp', '-o', 'dds-types', '-d', '/home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_typesupport_opensplice_cpp/rcl_interfaces/dds_opensplice', '/home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_generator_dds_idl/rcl_interfaces/dds_opensplice/SampleGetParametersResponse_.idl']' returned non-zero exit status 255
make[2]: *** [rosidl_typesupport_opensplice_cpp/rcl_interfaces/dds_opensplice/Parameter_.h] Error 1
make[1]: *** [CMakeFiles/rcl_interfaces__dds_opensplice_cpp.dir/all] Error 2
INFO com.rti.ndds.nddsgen.Main Running rtiddsgen version 2.2.0.0, please wait ...
WARN com.rti.ndds.nddsgen.antlr.auto.IdlLexer ParameterDescription_.idl line 35  preprocessor directive not supported. It will be ignored
WARN com.rti.ndds.nddsgen.antlr.auto.IdlLexer Parameter_.idl line 30  preprocessor directive not supported. It will be ignored
WARN com.rti.ndds.nddsgen.antlr.auto.IdlLexer ParameterEvent_.idl line 28  preprocessor directive not supported. It will be ignored
INFO com.rti.ndds.nddsgen.Main Done
Generating: /home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_typesupport_connext_cpp/rcl_interfaces/dds_connext/GetParametersRequest_.h/cpp
INFO com.rti.ndds.nddsgen.Main Running rtiddsgen version 2.2.0.0, please wait ...
WARN com.rti.ndds.nddsgen.antlr.auto.IdlLexer ParameterDescription_.idl line 35  preprocessor directive not supported. It will be ignored
WARN com.rti.ndds.nddsgen.antlr.auto.IdlLexer GetParametersRequest_.idl line 25  preprocessor directive not supported. It will be ignored
INFO com.rti.ndds.nddsgen.Main Done
Generating: /home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_typesupport_connext_cpp/rcl_interfaces/dds_connext/GetParametersResponse_.h/cpp
INFO com.rti.ndds.nddsgen.Main Running rtiddsgen version 2.2.0.0, please wait ...
/home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_generator_dds_idl/rcl_interfaces/dds_connext/GetParametersResponse_.idl:6:54: fatal error: rcl_interfaces/dds_connext/Parameters_.idl: No such file or directory
 #include "rcl_interfaces/dds_connext/Parameters_.idl"
                                                      ^
compilation terminated.
ERROR com.rti.ndds.nddsgen.Main Fail:  Error executing cpp preprocessor
INFO com.rti.ndds.nddsgen.Main Done (failures)
Traceback (most recent call last):
  File "/home/tfoote/work/ros2/parameters/install/lib/rosidl_typesupport_connext_cpp/rosidl_typesupport_connext_cpp", line 75, in <module>
    sys.exit(main())
  File "/home/tfoote/work/ros2/parameters/install/lib/rosidl_typesupport_connext_cpp/rosidl_typesupport_connext_cpp", line 61, in main
    service_specs,
  File "/home/tfoote/work/ros2/parameters/install/lib/python3.4/site-packages/rosidl_typesupport_connext_cpp/__init__.py", line 74, in generate_dds_connext_cpp
    subprocess.check_call(cmd)
  File "/usr/lib/python3.4/subprocess.py", line 557, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/rtiddsgen2', '-I', '/home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_generator_dds_idl', '-d', '/home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_typesupport_connext_cpp/rcl_interfaces/dds_connext', '-language', 'C++', '-namespace', '-replace', '/home/tfoote/work/ros2/parameters/build/rcl_interfaces/rosidl_generator_dds_idl/rcl_interfaces/dds_connext/GetParametersResponse_.idl']' returned non-zero exit status 255
make[2]: *** [rosidl_typesupport_connext_cpp/rcl_interfaces/dds_connext/Parameter_.h] Error 1
make[1]: *** [CMakeFiles/rcl_interfaces__dds_connext_cpp.dir/all] Error 2
make: *** [all] Error 2

<== Command '. /home/tfoote/work/ros2/parameters/build/rcl_interfaces/ament_cmake__build.sh && /usr/bin/make -j8 -l8' failed with exit code '2'

Add tests to [rosidl_generator_c]

Write some tests to check the types in the generated headers for different messages.
Similar to https://github.com/ros2/rosidl/blob/master/rosidl_generator_cpp/test/test_interfaces.cpp

[rosidl_generator_py] Can bypass setter checks by setting individual list elements

We currently define custom setters in Python to enforce the validity of the data being stored (type/range)

When we use static size array. Users can bypass these checks by setting list element directly.
e.g. using test_msgs/StaticArrayPrimitives:

Default initialized:
test_msgs.msg.StaticArrayPrimitives(bool_values=[False, False, False], byte_values=[b'\x00', b'\x00', b'\x00'], char_values=['\x00', '\x00', '\x00'], float32_values=[0.0, 0.0, 0.0], float64_values=[0.0, 0.0, 0.0], int8_values=[0, 0, 0], uint8_values=[0, 0, 0], int16_values=[0, 0, 0], uint16_values=[0, 0, 0], int32_values=[0, 0, 0], uint32_values=[0, 0, 0], int64_values=[0, 0, 0], uint64_values=[0, 0, 0], string_values=['', '', ''])

Setting the field through custom setter:

a.bool_values = [True, False, 42]

results in:

AssertionError: The 'bool_values' field must be a set or sequence with length 3 and each value of type 'bool'

Setting individual fields:

a.bool_values[0:] = [42, 43, 44]

results in:

test_msgs.msg.StaticArrayPrimitives(bool_values=[42, 43, 44], byte_values=[b'\x00', b'\x00', b'\x00'], char_values=['\x00', '\x00', '\x00'], float32_values=[0.0, 0.0, 0.0], float64_values=[0.0, 0.0, 0.0], int8_values=[0, 0, 0], uint8_values=[0, 0, 0], int16_values=[0, 0, 0], uint16_values=[0, 0, 0], int32_values=[0, 0, 0], uint32_values=[0, 0, 0], int64_values=[0, 0, 0], uint64_values=[0, 0, 0], string_values=['', '', ''])

Using C / C++ keywords as package name / field names results into compilation error

I realised today that using C++ keywords as fieldnames results into a compilation error.
Example:

bool delete false

Will result into:

rosidl_generator_cpp/iboss_msgs/msg/request_stored_data__struct.hpp:90:16: error: expected member name or ';' after declaration specifiers
  _delete_type delete;

It would be great if either the message generator would throw an error like: Don't use c++ keywords or
the message generator would somehow escape these fields.
If this is not a viable solution for you I think a hint in the documentation would be useful:
https://github.com/ros2/ros2/wiki/About-ROS-Interfaces

Register msg and srv with the ament_index

Generate MISRA compatible constants

Feature request

Feature description

It has been brought to our attention that the message constants that are generated for ROS2 are not compatible with writing MISRA-compliant code.

Let's consider a ROS2 message file PointBlock.msg that apart from other things containing a constant:

...
uint32 CAPACITY=256
...

One of resulting generated files is PointBlock.msg point_block__struct.hpp:

...
  // constants
  enum { CAPACITY = 256u };
...

Now because of CAPACITY is a class-less enumeration and is not signed, we can't use it in assignments to and comparisons with uint32_t variables.

implicit conversion from 'unsigned int' to 
'enum apex_app_msgs::msg::PointBlock_<std::allocator<void> >::(anonymous at point_block__struct.hpp:113:3)'
changes signedness of underlying type

Python generator called repeatedly in message interface packages

The message "Generating Python code for ROS interfaces" is printed repeatedly during compilation of message interface packages. It seems the Python generator is being called repeatedly when it should only be called once.

[rosidl_generator_py] Provide field type in the generated message classes

Feature request

Feature description

If a message has fields that are arrays (Bounded or Unbounded), there is no way for an external tool to get the relevant information as of what type the fields of this array are supposed to be.

Implementation considerations

A suggested approach is to extend the generated message class to provide the type of the various fields. This information could then be leveraged by a higher level function/utility (in rclpy ?) that could fill a message based on user specified values.

connects to ros2/ros2cli#59
necessary to fix ros2/ros2cli#59

Add Instrumentation to Generated Msg Code

It would be useful to have some kind of optional instrumentation on the generated messages so that we could more easily track things like construction, destruction, and coping of the messages. Other kinds of data might be useful as well, but I can't think of any off the top of my head.

AC:

Messages generate optional (compile time enabled) mechanism for tracking calls to the message's constructor, destructor, and any copy/move constructors.

Ideally this could be disabled/enabled by the consuming package (like with a #define before including the message's header), and that if you do not use the instrumentation then it does not affect performance at all. But importantly, the enabling/disabling of the instrumentation cannot affect the behavior of the message class.

Default values for all defined types

Numeric types:
- add testing for existing default values supported #165
Strings:
- design doc ros2/design#110
- implementation in parser e43a73f #205
Primitive arrays:
- design doc ros2/design#111
- implementation #197
Complex types:
- design doc
- implementation (parser + generators)

Review primitive types

This is a meta-ticket for type deprecationg and primitive types supported is ROS 2 IDL.

decide what types to support and update design documents accordingly
update parsers and generators to match these types
update code and example to use the new supported types

[rosidl_generator_py] fix how generated python files are installed

See: #88 (comment)

is there any complete name rules for name of .msg file and variable in .msg file when building msg idl ?

when I build my msg file, I found some name rules of creating msg file, such as :
rule 1: there should't be any upper-case characters in varialbe name in msg file. for example,
"string abc" is valid, and "string aBc" in invalid.
rule 2: the name of msg file should begin with upper-case characters. for example, msg file name
"Tmpmsg.msg" is valid, but "tmpmsg.msg" is invalid.
so I wonder whether if any complete rules for msg naming which will make me do less trying work when I want to build a correct msg ?

We should provide a <<operator like in ROS 1 to ease printing to streams. Some places in the codebase print manually message content to stream in the meantime, e.g. https://github.com/ros2/demos/blob/144fb6d80810f149fa2457ae8542b332a6497674/demo_nodes_cpp/src/parameters/parameter_events.cpp#L26

ros2 / rosidl Goto Github PK

rosidl's Introduction

rosidl

Packages

rosidl's People

Contributors

Stargazers

Watchers

Forkers

rosidl's Issues

Bug report

Steps to reproduce issue

Expected behavior

Actual behavior

Additional information

Feature request

Feature description

Feature request

Feature description

Implementation considerations

Recommend Projects

Recommend Topics

Recommend Org