tocinc / rmw_coredx Goto Github PK

This has been a problem since before the bouncy release. Coredx seems to know the types of messages that it sees, but when it needs to use that type on the fly it doesn't seem to work. The easiest example of that is with ros2 topic echo. I should be able to do the following and see the messages echoed out.

• ros2 run demo_nodes_cpp talker in one terminal
• ros2 topic echo chatter in another terminal
  ros2 topic list -t does seem to correctly show the types, but for some reason we have to specify the when we call ros2 topic echo. ros2 topic echo chatter std_msgs/String`. This works on other middlewares and used to work on coredx.

We experience the same kind of issue with the dynamic bridge. I'm not sure if they're related. If you run ros2 run ros1_bridge dynamic_bridge, it should be able to dynamically bridge topics into ros1 only if a ros1 node is trying to subscribe to them. Instead, nothing gets through. We have to run ros2 run ros1_bridge dynamic_bridge -- --bridge-all-topics in order to get anything across. The problem with using that method, is that we get more traffic than we actually wanted going across the bridge.

Services are not interoperating with other middlewares (fastrtps) because there are underscores being inserted before Reply and Request. See the screenshot below from dds spy. The top domain participant is coredx and the bottom one is fastrtps

What works:

• run ros2 run demo_nodes_py talker on one computer
• run ros2 run demo_nodes_py listener on another computer
  This seems to work because talker publishes as reliable and listener subscribes as reliable

What doesn't work:

• run ros2 run demo_nodes_py talker on one computer
• run ros2 topic echo /chatter std_msgs/String on another computer
  It seems like this not working is related to the fact that topic echo subscribes as best effort. If this is run on a single computer, everything works fine, but something about best effort subscription isn't working between computers.

This is a major roadblock that will keep us from updating to bouncy.

The API has changed on some things and if you try to compile this rmw_coredx with the new Beta2 release, it fails to build.

I'm opening this for local tracking of the issue here: ros2/ros2#352

I'm not sure if it concerns rmw_coredx or not; I'm not sure how the subscription array is being managed.

When I run the ros1 dynamic bridge and then run a ros1 node that has a service, the bridge crashes.

Steps to reproduce:
Terminal 1 -
source /opt/ros/kinetic/setup.bash
roscore

Terminal 2 -
source /opt/ros/kinetic/setup.bash
source ros2 bouncy
ros2 run ros1_bridge dynamic_bridge -- --bridge-all-2to1-topics

Terminal 3 -
source /opt/ros/kinetic/setup.bash
rosrun turtlesim turtlesim_node

Another option for terminal 3, which is the ros1 node that has a service, is to run rviz (this is how this bug was originally discovered.

The failure mode is for the terminal running the dynamic_bridge to output something as follows:

ros2 run ros1_bridge dynamic_bridge -- --bridge-all-2to1-topicsCreated 2 to 1 bridge for service /clear
Created 2 to 1 bridge for service /reset
Created 1 to 2 bridge for service /clea
Created 1 to 2 bridge for service /rese
Created 1 to 2 bridge for service /cle
Created 1 to 2 bridge for service /res
Created 1 to 2 bridge for service /cl
Created 1 to 2 bridge for service /re
Created 1 to 2 bridge for service /c
Created 1 to 2 bridge for service /r
terminate called after throwing an instance of 'rclcpp::exceptions::InvalidServiceNameError'
what(): Invalid service name: topic name must not end with a forward slash:
'/'
^

This is high priority, as we require the dynamic bridge for key functionality. Our only workaround currently is to not use coredx.

I recognize that it is typical to require the same QoS settings on both subscriber and receiver. However, I believe some forgiveness is in order in this regard. DDS and ROS's QoS support the idea of publishers that send their most-recent data to each new subscriber automatically. The ROS QoS uses "durability" for the name of this feature. You can set your QoS to a durability of "transient local" to keep data in RAM for sending it to each new subscriber. When using CoreDX, I'm required to specify "transient local" on the receiver as well. I find that somewhat annoying. I can understand why a "reliable" connection would need to be specified on both ends, and with the rolling history setting it seems you would need to just use the smallest value from either end. "Durability", though is all about what the publisher does with new connections. Thoughts?

I get a crash when running dynamic_bridge (only) with the coredx middleware. It appears to be an overrun of an array of strings. Not-so-helpful stacktrace:

Backtrace:
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f79cfd58428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f79cfd5a02a]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x16d)[0x7f79d039184d]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x8d6b6)[0x7f79d038f6b6]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x8d701)[0x7f79d038f701]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x8d919)[0x7f79d038f919]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZSt20__throw_length_errorPKc+0x3f)[0x7f79d03b826f]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x11f099)[0x7f79d0421099]
dynamic_bridge(_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIN9__gnu_cxx17__normal_iteratorIPcS4_EEEEvT_SA_St20forward_iterator_tag+0x9e)[0x433cf0]
dynamic_bridge[0x43011c]
dynamic_bridge[0x42ae14]
dynamic_bridge(_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1IN9__gnu_cxx17__normal_iteratorIPcS4_EEvEET_SA_RKS3_+0x52)[0x426caa]
dynamic_bridge[0x41fc08]
dynamic_bridge[0x422d9c]
dynamic_bridge[0x422c4b]
/home/asi/coredx/ros2_ws/install/lib/librclcpp.so(_ZN6rclcpp8executor8Executor13execute_timerESt10shared_ptrINS_5timer9TimerBaseEE+0x23)[0x7f79d5d9577f]
/home/asi/coredx/ros2_ws/install/lib/librclcpp.so(_ZN6rclcpp8executor8Executor22execute_any_executableESt10shared_ptrINS0_13AnyExecutableEE+0xac)[0x7f79d5d9527e]
/home/asi/coredx/ros2_ws/install/lib/librclcpp.so(_ZN6rclcpp8executor8Executor9spin_onceENSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEE+0xd8)[0x7f79d5d9500c]
/home/asi/coredx/ros2_ws/install/lib/librclcpp.so(_ZN6rclcpp8executor8Executor26spin_node_once_nanosecondsESt10shared_ptrINS_15node_interfaces17NodeBaseInterfaceEENSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEE+0x84)[0x7f79d5d94a66]
dynamic_bridge[0x427b31]
dynamic_bridge[0x421359]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f79cfd43830]
dynamic_bridge[0x4194e9]

I have a simple ros2 node that is listening for a parameter to be set by another node, and when it gets set, it prints out the value and closes.

#include <string>
#include "rclcpp/rclcpp.hpp"

int main(int argc, char **argv)
{
    rclcpp::init(argc, argv);
    auto node = rclcpp::Node::make_shared("demo");
    auto param_service = std::make_shared<rclcpp::parameter_service::ParameterService>(node);

    std::string param = "";
    auto set_parameters_results = node->set_parameters({ rclcpp::parameter::ParameterVariant("param", ""), });
    for (auto & result : set_parameters_results)
    {
        if (!result.successful)
        {
            std::cerr << "Failed to initialize parameter: " << result.reason << std::endl;
        }
    }

    while (rclcpp::ok() && param.empty())
    {
        std::cout << "Waiting for params...\n";
	rclcpp::sleep_for(std::chrono::milliseconds(1000));
	
        rclcpp::spin_some(node);
	param = node->get_parameter("param").as_string();
    }

    std::cout << "Got param: " << param << std::endl;

    return 0;
}

I use a separate node to set it, which is part of ros2: ros2param

It is not working use this rmw. The same node does work when using fastrtps. The ros2param tool just prints Failed to set parameter.

When using fastrtps for the server, and using coredx for the ros2param tool, the server prints out a bunch of these error messages:
[RTPS_MSG_IN Error] (ID:140484578068224) Bad encapsulation for KeyHash and status parameter list -> Function proc_Submsg_Data

I am using evaluation version 4.0.14 with gcc43. I have my ros2 compiled with gcc 5.4

I'm seeing an issue with a simple ros node that tries to send two string messages to a simple listener that just listens for the messages and prints them out. The messages are each being sent on a separate topic. I have found that the only somewhat reliable way to see the listener get both messages is to sleep before sending the first, then sleeping again before sending the second. This seems like a brittle, unreliable way to have to work. Is there a better way? I'm using default qos, which is supposed to be reliable delivery. My concern is that we are having packets get dropped.

Sender node:

#include "rclcpp/rclcpp.hpp"
#include <iostream>
#include "std_msgs/msg/string.hpp"

using std_msgs::msg::String;

int main(int argc, char** argv)
{
    rclcpp::init(argc, argv);
    auto node = rclcpp::Node::make_shared("string_sender");

    auto pub1 = node->create_publisher<String>("topic1");
    auto pub2 = node->create_publisher<String>("topic2");

    String msg;
    msg.data = "my data";

    rclcpp::sleep_for(std::chrono::milliseconds(500)); //shouldn't have to do this
    std::cout << "sending 1..." << std::endl;
    pub1->publish(msg);

    rclcpp::sleep_for(std::chrono::milliseconds(500)); //shouldn't have to do this
    std::cout << "sending 2..." << std::endl;
    pub2->publish(msg);

    std::cout << "done sending" << std::endl;

    return 0;
}

Listener node:

#include <iostream>
#include "rclcpp/rclcpp.hpp"
#include "std_msgs/msg/string.hpp"

using std_msgs::msg::String;
using std::cout;
using std::endl;

int main(int argc, char** argv)
{
    rclcpp::init(argc, argv);
    auto node = rclcpp::Node::make_shared("string_listener");

    auto sub1 = node->create_subscription<String>("topic1",
                                                  [](std::shared_ptr<String> msg)
                                                  {
                                                      cout << "got msg on topic1" << endl;
                                                  });
    auto sub2 = node->create_subscription<String>("topic2",
                                                  [](std::shared_ptr<String> msg)
                                                  {
                                                      cout << "got msg on topic2" << endl;
                                                  });

    std::cout << "Listening..." << std::endl;
    rclcpp::spin(node);
    std::cout << "Done listening" << std::endl;

    return 0;
}

With the bouncy bolson release (https://github.com/ros2/ros2/wiki/Release-Bouncy-Bolson), there have been changes in the way namespaces are done.

The ROS topic names containing namespaces are mapped to DDS topics including their namespaces. DDS partitions are not being used anymore for this.

Will you be making an update to support the new release?

When following the source building instructions for ros2 (https://github.com/ros2/ros2/wiki/Linux-Development-Setup), I am unable to get this to build successfully without also building rmw_opensplice. I would like to build with only coredx, to speed up the build, and to guarantee we are only using coredx. rmw_opensplice is not currently being supported, and issues result when trying to use master with rmw_opensplice.

I do have opensplice installed.

I have made the mods that the attached file COREDX_INTEGRATION.txt told me to do, except for the mod to rosidl_generator_py/package.xml, because the other rmw implementations are no longer in there either. I have placed AMENT_IGNORE files in ros2/rmw_fastrtps, ros2/rmw_connext, and ros2/rmw_opensplice, as well as eProsima.

This happened with version coredx-4.0.14-Linux_2.6_x86_64_gcc43-Evaluation.tgz and with the latest ros2 master as of 5/1/2017.

Even when putting the <test_depend> into the rosidl_generator_py's package.xml for coredx, it has the same error.

Error messages:
_Scanning dependencies of target examples_rclcpp_minimal_client_main
[ 50%] Building CXX object CMakeFiles/examples_rclcpp_minimal_client_main.dir/main.cpp.o
[100%] Linking CXX executable examples_rclcpp_minimal_client_main
/home/platform/coredx/ros2_ws/install/lib/libexample_interfaces__rosidl_typesupport_coredx_cpp.so: undefined reference to DDS::rpc::RequesterParams::service_name(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /home/platform/coredx/ros2_ws/install/lib/libexample_interfaces__rosidl_typesupport_coredx_cpp.so: undefined reference to DDS::rpc::ReplierParams::service_name(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)'
collect2: error: ld returned 1 exit status
CMakeFiles/examples_rclcpp_minimal_client_main.dir/build.make:131: recipe for target 'examples_rclcpp_minimal_client_main' failed
make[2]: *** [examples_rclcpp_minimal_client_main] Error 1
CMakeFiles/Makefile2:99: recipe for target 'CMakeFiles/examples_rclcpp_minimal_client_main.dir/all' failed
make[1]: *** [CMakeFiles/examples_rclcpp_minimal_client_main.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

<== Command '. /home/platform/coredx/ros2_ws/build/examples_rclcpp_minimal_client/cmake__build.sh && /usr/bin/make -j16 -l16' failed in '/home/platform/coredx/ros2_ws/build/examples_rclcpp_minimal_client' with exit code '2'
<== Command '. /home/platform/coredx/ros2_ws/build/examples_rclcpp_minimal_client/cmake__build.sh && /usr/bin/make -j16 -l16' failed in '/home/platform/coredx/ros2_ws/build/examples_rclcpp_minimal_client' with exit code '2'_

If I place an AMENT_IGNORE in the ros2/examples dir also, it will fail with different errors:

_[ 81%] Linking CXX executable static_transform_publisher
[ 90%] Linking CXX executable tf2_echo
/home/platform/coredx/ros2_ws/install/lib/libtf2_msgs__rosidl_typesupport_coredx_cpp.so: undefined reference to DDS::rpc::ReplierParams::service_name(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /home/platform/coredx/ros2_ws/install/lib/libtf2_msgs__rosidl_typesupport_coredx_cpp.so: undefined reference to DDS::rpc::RequesterParams::service_name(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)'
collect2: error: ld returned 1 exit status
CMakeFiles/static_transform_publisher.dir/build.make:350: recipe for target 'static_transform_publisher' failed
make[2]: *** [static_transform_publisher] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/static_transform_publisher.dir/all' failed
make[1]: *** [CMakeFiles/static_transform_publisher.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
/home/platform/coredx/ros2_ws/install/lib/libtf2_msgs__rosidl_typesupport_coredx_cpp.so: undefined reference to DDS::rpc::ReplierParams::service_name(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /home/platform/coredx/ros2_ws/install/lib/libtf2_msgs__rosidl_typesupport_coredx_cpp.so: undefined reference to DDS::rpc::RequesterParams::service_name(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)'
collect2: error: ld returned 1 exit status
CMakeFiles/tf2_echo.dir/build.make:350: recipe for target 'tf2_echo' failed
make[2]: *** [tf2_echo] Error 1
CMakeFiles/Makefile2:136: recipe for target 'CMakeFiles/tf2_echo.dir/all' failed
make[1]: *** [CMakeFiles/tf2_echo.dir/all] Error 2
[100%] Linking CXX executable tf2_monitor
/home/platform/coredx/ros2_ws/install/lib/libtf2_msgs__rosidl_typesupport_coredx_cpp.so: undefined reference to DDS::rpc::ReplierParams::service_name(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /home/platform/coredx/ros2_ws/install/lib/libtf2_msgs__rosidl_typesupport_coredx_cpp.so: undefined reference to DDS::rpc::RequesterParams::service_name(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)'
collect2: error: ld returned 1 exit status
CMakeFiles/tf2_monitor.dir/build.make:350: recipe for target 'tf2_monitor' failed
make[2]: *** [tf2_monitor] Error 1
CMakeFiles/Makefile2:173: recipe for target 'CMakeFiles/tf2_monitor.dir/all' failed
make[1]: *** [CMakeFiles/tf2_monitor.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

<== Command '. /home/platform/coredx/ros2_ws/build/tf2_ros/cmake__build.sh && /usr/bin/make -j16 -l16' failed in '/home/platform/coredx/ros2_ws/build/tf2_ros' with exit code '2'
<== Command '. /home/platform/coredx/ros2_ws/build/tf2_ros/cmake__build.sh && /usr/bin/make -j16 -l16' failed in '/home/platform/coredx/ros2_ws/build/tf2_ros' with exit code '2'_

When I compile with version coredx-4.0.12-Linux_2.6_x86_64_gcc43-Evaluation.tgz, it does the same things.

@ClarkTucker I'm trying to build the rmw layer for CoreDX following your update to Dashing.

The build breaks on rosidl_generator_py for coredx in the following files:

build/rosidl_generator_py/rosidl_typesupport_coredx_cpp/rosidl_generator_py/msg/Constants_.hh in line 47 static const fixedstring3_t const FOO_ = "foo";
build/test_msgs/rosidl_typesupport_coredx_cpp/test_msgs/msg/Strings_.hh in line 43 static const fixedstring12_t const STRING_CONST_ = "Hello world!";

the problem is the duplication of const. Can you check in the CoreDX ddl generator?

Thanks!

I'm using a source installation of ROS2 from tip of master on Ubuntu Bionic (mostly equivalent to Crystal in terms of API compatibility).

Ran CoreDX's scripts/cdxenv.sh, then cloned this repo into the src/ros2/ dir and ran colcon build --symlink-install --cmake-force-configure, which failed.

Seeing as the last commit was a while ago, I'm wondering whether this is still supposed to be compatible with the latest ROS2 and RMW interface?

Build log:

--- stderr: rmw_coredx_cpp
/ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/custom_listeners.cpp: In member function ‘virtual void CustomDataReaderListener::trigger_graph_guard_condition()’:
/ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/custom_listeners.cpp:77:70: error: ‘rmw_get_error_string_safe’ was not declared in this scope
     fprintf(stderr, "failed to trigger graph guard condition: %s\n", rmw_get_error_string_safe());
                                                                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/rmw_create_guard_condition.cpp: In function ‘rmw_guard_condition_t* rmw_create_guard_condition()’:
/ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/rmw_create_guard_condition.cpp:42:1: error: conflicting declaration of C function ‘rmw_guard_condition_t* rmw_create_guard_condition()’
 rmw_create_guard_condition( )
 ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/rmw_create_guard_condition.cpp:20:0:
/ros2_clean/install/rmw/include/rmw/rmw.h:528:1: note: previous declaration ‘rmw_guard_condition_t* rmw_create_guard_condition(rmw_context_t*)’
 rmw_create_guard_condition(rmw_context_t * context);
 ^~~~~~~~~~~~~~~~~~~~~~~~~~
/ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/custom_listeners.cpp:77:70: note: suggested alternative: ‘rmw_get_error_string’
     fprintf(stderr, "failed to trigger graph guard condition: %s\n", rmw_get_error_string_safe());
                                                                      ^~~~~~~~~~~~~~~~~~~~~~~~~
                                                                      rmw_get_error_string
/ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/names.cpp: In function ‘bool rmw_coredx_process_service_name(const char*, bool, char**, char**)’:
/ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/names.cpp:98:5: error: expected ‘;’ before ‘success’
     success = false;
     ^~~~~~~
/ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/names.cpp:107:5: error: expected ‘;’ before ‘success’
     success = false;
     ^~~~~~~
/ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/rmw_create_node.cpp: In function ‘rmw_node_t* rmw_create_node(const char*, const char*, size_t, const rmw_node_security_options_t*)’:
/ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/rmw_create_node.cpp:73:1: error: conflicting declaration of C function ‘rmw_node_t* rmw_create_node(const char*, const char*, size_t, const rmw_node_security_options_t*)’
 rmw_create_node (
 ^~~~~~~~~~~~~~~
In file included from /ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/rmw_create_node.cpp:20:0:
/ros2_clean/install/rmw/include/rmw/rmw.h:166:1: note: previous declaration ‘rmw_node_t* rmw_create_node(rmw_context_t*, const char*, const char*, size_t, const rmw_node_security_options_t*)’
 rmw_create_node(
 ^~~~~~~~~~~~~~~
/ros2_clean/src/ros2/rmw_coredx/rmw_coredx_cpp/src/rmw_create_node.cpp:128:55: error: too few arguments to function ‘rmw_guard_condition_t* rmw_create_guard_condition(rmw_context_t*)’
   graph_guard_condition = rmw_create_guard_condition( );

Hi,
First of all congrats for the great work! nice to see a new rmw_implementation that works out of the box!

While playing around with this in my ros2 workspace I identified a few interoperability failures with other rmw_implementations.

CoreDX <=> Fast-RTPS: unable to transfer static arrays
Can be reproduced by runnint in a sourced workspace:

• Terminal 1:
  RMW_IMPLEMENTATION=rmw_fastrtps_cpp python3 src/ros2/system_tests/test_communication/test/subscriber_py.py StaticArrayPrimitives
• Terminal 2:
  RMW_IMPLEMENTATION=rmw_coredx_cpp python3 src/ros2/system_tests/test_communication/test/publisher_py.py StaticArrayPrimitives

CoreDX <=> RTI Connext static: it seems that any message are unable to be transfered and cause segmentation faults, even the talker/listener example.

This may be related to #6

I set the RMW_IMPLEMENTATION env var to rmw_coredx_cpp before building ros2 so that it will build rmw_implemenation with coredx set as the default. I am also building fast_rtps because of related issue cited above (issue 6). When it gets to build rmw_implementation, it fails to build with these errors:

+++ Building 'rmw_implementation'
Running cmake because arguments have changed.
==> '. /home/platform/coredx/ros2_ws/build/rmw_implementation/cmake__build.sh && /usr/bin/cmake /home/platform/coredx/ros2_ws/src/ros2/rmw_implementation/rmw_implementation -DBUILD_TESTING=0 -DCMAKE_INSTALL_PREFIX=/home/platform/coredx/ros2_ws/install' in '/home/platform/coredx/ros2_ws/build/rmw_implementation'
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- 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
-- Detecting C compile features
-- Detecting C compile features - 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
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found ament_cmake: 0.0.0 (/home/platform/coredx/ros2_ws/install/share/ament_cmake/cmake)
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3")
-- Using PYTHON_EXECUTABLE: /usr/bin/python3
-- Found rcutils: 0.0.0 (/home/platform/coredx/ros2_ws/install/share/rcutils/cmake)
-- Found poco_vendor: 1.0.0 (/home/platform/coredx/ros2_ws/install/share/poco_vendor/cmake)
-- Searching for Poco library...
-- Found Poco!
-- components found: Foundation.
-- Found rmw_implementation_cmake: 0.0.0 (/home/platform/coredx/ros2_ws/install/share/rmw_implementation_cmake/cmake)
CMake Error at /home/platform/coredx/ros2_ws/install/share/rmw_implementation_cmake/cmake/get_default_rmw_implementation.cmake:62 (message):
Could not find ROS middleware implementation 'rmw_coredx_cpp'. Choose one
of the following: rmw_fastrtps_cpp
Call Stack (most recent call first):
CMakeLists.txt:23 (get_default_rmw_implementation)

-- Configuring incomplete, errors occurred!
See also "/home/platform/coredx/ros2_ws/build/rmw_implementation/CMakeFiles/CMakeOutput.log".

<== Command '. /home/platform/coredx/ros2_ws/build/rmw_implementation/cmake__build.sh && /usr/bin/cmake /home/platform/coredx/ros2_ws/src/ros2/rmw_implementation/rmw_implementation -DBUILD_TESTING=0 -DCMAKE_INSTALL_PREFIX=/home/platform/coredx/ros2_ws/install' failed in '/home/platform/coredx/ros2_ws/build/rmw_implementation' with exit code '1'
<== Command '. /home/platform/coredx/ros2_ws/build/rmw_implementation/cmake__build.sh && /usr/bin/cmake /home/platform/coredx/ros2_ws/src/ros2/rmw_implementation/rmw_implementation -DBUILD_TESTING=0 -DCMAKE_INSTALL_PREFIX=/home/platform/coredx/ros2_ws/install' failed in '/home/platform/coredx/ros2_ws/build/rmw_implementation' with exit code '1'

Perhaps there is some config file that I need to change that will allow this rmw_coredx_cpp to be recognized by the build as a possible rmw implementation to be provided as default?

I have seen recent work done to get the middleware complying with the new Ros2 release (ardent).

We tried building with this version and everything compiles. When we run python nodes they work fine. But when we run cpp nodes we get a runtime linker error no matter which node we try to run. The error is:

platform@beast2:~/ros2_with_new_coredx_src$ ros2 run demo_nodes_cpp talker
/home/platform/ros2_with_new_coredx_src/install/lib/demo_nodes_cpp/talker: symbol lookup error: /home/platform/ros2_with_new_coredx_src/install/lib/librcl_interfaces__rosidl_typesupport_coredx_cpp.so: undefined symbol: _ZN3DDS3rpc15RequesterParams12service_nameERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

Perhaps this is a nonissue though if things just aren't ready yet, which is fine. Is everything in this rmw_coredx implementation ready? Or is there still some work in progress to get it ready?

There are some Linux-specific time function calls that prohibit operability on Windows and potentially OSX. (I'm not sure on OSX since I didn't test it.)

struct timespec now;
clock_gettime(CLOCK_REALTIME, &now);

stl has a good time library which should provide a bit more os-independence. It's the std::chrono library.

performance of message traffic using ROS2 on CoreDX is poor.
see this thread for some details: https://discourse.ros.org/t/astra-driver-for-ros2/1894/13

With the latest rmw_coredx_cpp, we aren't seeing services working correctly.

If we run ros2 run demo_nodes_cpp add_two_ints_server and ros2 run demo_nodes_cpp add_two_ints_client, the client never finds the server.

When we run ros2 topic list, we see services as well as regular pub/sub topics. We've also seen that get_service_names_and_types is not implemented, which makes ros2 service list fail. Normal ros2 behavior is that ros2 topic list would list pub/sub topics only, and ros2 service list lists services only.