ros-drivers/transport_drivers

A set of ROS2 drivers for transport-layer protocols.

transport_drivers

A set of ROS2 drivers for transport-layer protocols. Currently utilizes the stand-alone ASIO library for most transport-layer functionality.

Supported Drivers:

• UDP Driver

A package which encapsulates basic receving and sending of udp data.

Provided within this package are the following executabes:

• udp_receiver_node_exe: can receive UDP data
• udp_sender_node_exe: can send UDP data asynchronosouly
• udp_bridge_node_exe: combined both receiver and sender nodes into one

Provided within this package also is a udp_driver library without the ROS2 dependencies which could be used elsewhere.

• Serial Driver

A package which which encapsulates basic receiving and sending of serial data.

Provided within this package is the following executabe:

• serial_bridge: combined both receiver and sender nodes into one

Provided within this package also is a serial_driver library without the ROS2 dependencies which could be used elsewhere.

• IO Context

A library to write synchronous and asynchronous networking applications.

Quick start

Clone the repo into your workspace, normally with the structure workspace/src/<clone-repo-here>:

git clone https://github.com/ros-drivers/transport_drivers.git

Install dependencies using rosdep from your top-level workspace directory:

rosdep install --from-paths src --ignore-src -r -y

Once you have the repository cloned and dependencies installed, you can now go ahead and compile:

colcon build

After successful compilation, you should be able to source your newly built packages:

source install/setup.bash

...and now you should be able to run your newly built executables. Here is how you would launch the udp_driver bridge node:

ros2 run udp_driver udp_bridge_node_exe --ros-args --params-file ./src/transport_drivers/udp_driver/params/example_udp_params.yaml

Testing

Comprehensive unit tests have been written for every package within this repository.

To run them yourself, use the normal command from your top-level workspace directory:

colcon test

transport_drivers's Issues

Examples

I'm really struggling to get a basic example working with this.

Would it be possible to add a few examples for serial and UDP that show how this package is supposed to be used?
Something as trivial as an echo/publisher would be super useful in my opinion.

Warnings in console while not activated

1. Run remote udp sender
2. Run udp_receiver_node
3. Configure udp_receiver_node
   Got multiple warning in console until not activated

[WARN] [1647610867.318857689] [LifecyclePublisher]: Trying to publish message on the topic 'udp_read', but the publisher is not activated

Error with udp_bridge

hi, i have an issue with running the udp_bridge ex'.
i get the following error:

[ERROR] [1657181403.652255563] [rcl]: Failed to parse global arguments
terminate called after throwing an instance of 'rclcpp::exceptions::RCLInvalidROSArgsError'
  what():  failed to initialize rcl: Couldn't parse params file: '--params-file ./src/transport_drivers/udp_driver/params/example_udp_params.yaml'. Error: Error opening YAML file, at /tmp/binarydeb/ros-galactic-rcl-yaml-param-parser-3.1.3/src/parser.c:270, at /tmp/binarydeb/ros-galactic-rcl-3.1.3/src/rcl/arguments.c:406

moreover when i check the unit tests with colcon test i get that all methods break:

Summary: 4 packages finished [3min 13s]
  4 packages had stderr output: asio_cmake_module io_context serial_driver udp_driver
  4 packages had test failures: asio_cmake_module io_context serial_driver udp_driver

udp_driver tests failing on unify-msg-converters branch

so I went ahead and added some debug prints for the udp_driver tests that were failing. you can see the results below.

digging into it now but I wanted to ask @JWhitleyWork if it mattered that the udp_msgs we are using here are not "plain" messages with only a data member. it has [some other members]...but looking at the converters function it looks like it only uses the data member...which should make this ok then.

[==========] Running 2 tests from 2 test cases.
4: [----------] Global test environment set-up.
4: [----------] 1 test from UdpSenderNodeTest
4: [ RUN      ] UdpSenderNodeTest.RosMessageToRawUdpMessageSharedContext
4: [INFO] [1619905813.391303792] [IoContext::IoContext]: Thread(s) Created: 8
4: [INFO] [1619905813.406117574] [udp_sender_node]: ip: 127.0.0.1
4: [INFO] [1619905813.406243372] [udp_sender_node]: port: 8000
4: [INFO] [1619905813.515385792] [udp_sender_node]: to be sent msg size: 2
4: [ io_context::converters::from_basic_msg ] msgtype.data size: 24
4: [INFO] [1619905813.515630193] [udp_sender_node]: to be sent msg size: 4
4: [ io_context::converters::from_basic_msg ] msgtype.data size: 24
4: [INFO] [1619905813.515711127] [udp_sender_node]: to be sent msg size: 6
4: [ io_context::converters::from_basic_msg ] msgtype.data size: 24
4: [INFO] [1619905813.515817287] [udp_sender_node]: to be sent msg size: 8
4: [ io_context::converters::from_basic_msg ] msgtype.data size: 24
4: [INFO] [1619905813.515889290] [udp_sender_node]: to be sent msg size: 10
4: [ io_context::converters::from_basic_msg ] msgtype.data size: 24
4: [INFO] [1619905813.515980311] [udp_sender_node]: to be sent msg size: 12
4: [ io_context::converters::from_basic_msg ] msgtype.data size: 24
4: [INFO] [1619905813.516043226] [udp_sender_node]: to be sent msg size: 14
4: [ io_context::converters::from_basic_msg ] msgtype.data size: 24
4: [INFO] [1619905813.516097337] [udp_sender_node]: to be sent msg size: 16
4: [ io_context::converters::from_basic_msg ] msgtype.data size: 24
4: [INFO] [1619905813.516204706] [udp_sender_node]: to be sent msg size: 18
4: [ io_context::converters::from_basic_msg ] msgtype.data size: 24
4: [INFO] [1619905813.516258949] [udp_sender_node]: to be sent msg size: 20
4: [ io_context::converters::from_basic_msg ] msgtype.data size: 24
4: /home/flynn/code/ros/rolling/src/transport_drivers/udp_driver/test/test_udp_driver_nodes.cpp:117: Failure
4: Expected equality of these values:
4:   rclcpp::spin_until_future_complete( node, future_1, std::chrono::milliseconds(4000))
4:     Which is: TIMEOUT (2)
4:   rclcpp::FutureReturnCode::SUCCESS
4:     Which is: SUCCESS (0)
4: [ERROR] [1619905817.523445123] [UdpSocket::asyncReceiveHandler]: Operation aborted.
4: [  FAILED  ] UdpSenderNodeTest.RosMessageToRawUdpMessageSharedContext (4140 ms)
4: [----------] 1 test from UdpSenderNodeTest (4140 ms total)

replace MutBuffer with std::vector<uint8_t>

referenced on #40 comments since #40 begins to migrate towards std::vector<uint8_t> to fix some race conditions. lets go ahead and replace the rest of the MutBuffers with std::vector<uint8_t> to keep it all consistent.

New release breaks builds in Autoware.Auto

Seems like the new release is causing the pipelines to fail. See example: https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/jobs/1561321563

I can already see that the udp_driver_node.hpp has been removed. Do you guys think it warrants to have a list of breaking changes for the release? Ideally, also a transition guide.

Issue with socket parameters

void UdpReceiverNode::get_params()
{
try {
m_ip = declare_parameterstd::string("ip", "");
} catch (rclcpp::ParameterTypeException & ex) {
RCLCPP_ERROR(get_logger(), "The ip paramter provided was invalid");
throw ex;
}

try {
m_port = declare_parameter("port", 0);
} catch (rclcpp::ParameterTypeException & ex) {
RCLCPP_ERROR(get_logger(), "The port paramter provided was invalid");
throw ex;
}

RCLCPP_INFO(get_logger(), "ip: %s", m_ip.c_str());
RCLCPP_INFO(get_logger(), "port: %i", m_port);
}

this does not pass a string and an int as expected? I hard coded the ip and port and got it to work. Did anyone face the same issue?

serial_driver: SerialPortConfig and SerialPort missing character_size parameter

The SerialPortConfig and the SerialPort class in the serial_driver package should also provide the asio::serial_port_base::character_size option of asio::serial_port

Supported platforms

Can it be used with an Arduino Nano CH340?

Add support for UDP multicast

Some sensors publish UDP data to multicast addresses (e.g. 224.0.2.2). It would be nice if the udp_driver could intercept multicast traffic and forward it to topic /udp_read.

Example implementation:
https://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/example/multicast/receiver.cpp

switch to more standard default branch setup

right now the default branch for this repo is set to ros2. as far as I know this repo is only meant for ROS2....so to me there might be a better name for the default branch.

I really like the standard develop and main or master setup, where develop is where active development happens & main or master has the most recent tested & released code.

what do you think?

udp beta testers?

would be great to get some people to try out this package on a variety of udp devices to test it. would it be worth posting on ROS discourse for a call for beta-testers before releasing the package officially?

Make Nodes Component-Compatible

The SerialDriverNode and UdpDriverNode, as currently designed, do not pass an rclcpp::NodeOptions object and they also (unnecessarily) take in namespace data. Additionally, there are constructors which will not be necessary once the constructors which take an rclcpp::NodeOptions object are created.

Release new version of the drivers

The version of the packages available on the buildfarm is lagging behind the current version on master.

Make downstream drivers component-able

It should be possible to create downstream drivers as components, i.e. registered in the component registry, no main function, etc.

This ticket is part of https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/277

update serial_driver and udp_driver binaries that are released

the currently released serial_driver and udp_driver's do not include executables or launch files and can only really be used within code.

could we tag and release both packages so we can push a new release? @JWhitleyWork @esteve

serial_driver only supports one type of message

Similar to #3 but for serial_driver. See

transport_drivers/serial_driver/include/serial_driver/serial_driver_node.hpp

Line 64 in 7660c2a

/// \tparam OutputT The type a packet gets converted/deserialized into. Should be a ROS 2 message

.

For some sensors, it'd be useful to be able to generate messages of different types

Release for Foxy

After the current Dashing sync, the master branch should be renamed to main and it should target Foxy. dashing-devel will then target Dashing and an update must be made to rosdistro.

[general] why the `autoware` namespace?

just for sanity sake, is there a reason why these are in the autoware namespace or is it just legacy?

SerialPort tries to close port a possible second time in destructor

In #85, the port gets closed in case of an error but inside the constructor, close() is called a second time, which leads to errors.

udp_driver only supports one type of message

udp_driver only accepts one type of output, see

transport_drivers/udp_driver/include/udp_driver/udp_driver_node.hpp

Line 40 in 7660c2a

/// \tparam OutputT The type a packet gets converted/deserialized into. Should be a ROS 2 message

For some sensors, it'd be useful to be able to generate messages of different types

UDP Bridge Node is not working

Hello Community and @flynneva,
I have a problem while running the bridge node. I can see ip address and port but cannot see message in terminal after
running this terminal code:

ros2 run udp_driver udp_bridge_node_exe --ros-args --params-file ./src/transport_drivers/udp_driver/params/example_udp_params.yaml

The figure about this problem is below. Can you help me about this?

Pc: Msi gs66 stealth
Os: Ubuntu 20.04
Ros Distribution: Ros2 foxy

Thanks and regards.

How to open the serial port to read serial data through the serial package

Hello, I installed the serial driver through the command sudo apt-get install ros-foxy-serial-driver in the environment of ubuntu20.04+foxy, but I don’t know how I can open the serial port to read through the serial package Serial data. can you help me? Thank you~

Improve CI so that it checks doxygen

The current CI infrastructure does not check doxygen (unlike the Apex CI), which may cause packages to not be released into the ROS buildfarm, see #7

Find a bug when the received message exceeds 32 bytes, the received data is wrong

Perhaps there is a problem with the subsrciber function in serial_bridge_node.cpp file in the 79~80 lines:
auto qos = rclcpp::Qos(rclcpp::KeepLast(32).best_effort();
auto callback = std::bind(&SerialBridgeNode::subscriber_callback, this, std::placeholders::_1);

Wish to keep the interface for developers to change the receive bytes.

first release?

would it be worth while to try and get at least the udp_driver package released to foxy and rolling this week since next week (I think) is when rolling will be frozen for the first galactic release?

[Jazzy] Could not find a package configuration file provided by "asio_cmake_module"

In io_context the asio_cmake_module is listed as buildtool_depend:

transport_drivers/io_context/package.xml

Line 14 in 9fff59f

<buildtool_depend>asio_cmake_module</buildtool_depend>

So probably the buildfarm doesn't add this as dependency so it's not installed on a users system which only has io_context as dependency.

However it should be find_packaged as seen here:

transport_drivers/io_context/io_context-extras.cmake

Line 17 in 9fff59f

find_package(asio_cmake_module REQUIRED)

I don't think it's required in io_context-extras.cmake, what do you think?

No sending/receiving data on serial_driver_bridge

Hi,
I wasn't able to neither send nor receive anything with launching the serial_driver_bridge_node.launch.py
I'm trying to execute the launch file using the configurations of my device:

/**:
  ros__parameters:
    device_name: /dev/ttyUSB0
    baud_rate: 115200
    flow_control: none
    parity: none
    stop_bits: "1"

I'm using ros2 galactic in docker. I'm sending the following message to my device :

echo -ne '\x00\x00\x45\x44\x76\x00\x00\x36\xFF\x4F' > /dev/ttyUSB0

and I'm receiving back a message (using hexdump):

0000000    0000    0000    0076    3600    4eff    0000    0000    0000
0000010    0000    0000    0000    0000    0000    0000    0000    0000
*
0000060    0000    0000    0000    0000    0000    0000    0000    b578

Is there any other special config to make it work?
Thanks

Consumers of udp_driver Fail to Link

Downstream packages which use udp_driver fail to link after 7660c2a because the dependency on libboost-dev is no longer there. On Ubuntu, the asio package only exists in libboost-dev.

Bug in Converter between `std_msgs::msg::UInt8MultiArray` and `std::vector<uint8_t>`

The method vector::reserve() only change its capacity, not its size, which causes the out data to be empty.

The above result shows that the size of out data's size hasn't been changed, which occurs a bug in serial_driver that the msg published in /serial_read has no data in it.

And the bug is the same with /serial_wirte, as the convertion using the same method.

transport_drivers/io_context/include/msg_converters/example_interfaces.hpp

Line 34 in 0140e5e

out.reserve(in.data.size());

Rolling bloom-release to 1.0.1

Currently Galactic is on 1.0.1 but rolling is on 0.0.6.

I'd prefer the rolling release to be equal or ahead of galactic.

Could a new release be triggered?

recent commit to add linters didnt actually add linters

just something to note here that each runner in the CI is actually running all the default linters for ROS 2....see here on the copyright linter is still running the xmllint check as well. So now each distro is being tested for every linter 3 times I think (copyright, xmllint and lint_cmake runners all run all the linters)

Did you mean to also switch the action used over to action-ros-lint where you can specify the linter being run?

cc @esteve

update CI to standard ros-tooling github actions

the current CI strategy for this repo looks pretty custom (straight up bash commands in a list).

would we be able to switch over to the more standard ros-tooling/setup-ros and ros-tooling/actions-ros-ci.

ive went ahead and made these changes on my fork of this repo if you'd like to check it out.

Add ability to send UDP/Serial data

The current implementations in udp_driver and serial_driver only support receiving data.

serial_driver to be removed from Dashing due to removed dependency.

The removal of Autoware.Auto (which included autoware_auto_cmake) in ros/rosdistro#23937 has caused a regression of the serial_driver package in Dashing due to the dependency on autoware_auto_cmake.

There is currently a Dashing sync scheduled for this week. The current plan is to proceed with the sync and allow the package to be removed but if it's possible to work around the dependency it's possible to reintroduce the package in a future release / sync.

building shared lib on windows

I ran into this issue while trying to write a similar package that uses a shared lib like io_context. In order to get the lib to build on Windows I needed to add the following to the beginning of the shared lib CMakelists.txt file.

## needed to build on windows
if(MSVC)
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS TRUE)
set(BUILD_SHARED_LIBS TRUE)
endif()

not sure if anyones tried to compile this on windows yet....but we might need to add this to the io_context/CMakelists.txt file to do so.

update transport_drivers README to give an overview of all packages

Would be nice to update the README after the recent flurry of development. some quick things I'd like to see in it:

Each package:

• one-liner purpose
• published topics/subscribed topics
• parameters
• quick-start

Transport driver:

• quick-start/how-to
• supported distros/OS's
• contributing instructions
• CI overview

Stop applying topic names with parameters

Following the general consensus, stop applying topic names with parameter files and use remapping to change the topic names. For more information, please refer to this issue on Autoware.Auto.

See also: https://github.com/ros-drivers/transport_drivers/blob/master/udp_driver/include/udp_driver/udp_driver_node.hpp#L93

Add exception-safe version of serial_driver

As found during my implementation of serial_break in serial_port.hpp, I found that many of the asio functions used can throw, unless they are supplied an optional error code by reference.

The problem:

1. The current documentation does not indicate which functions are exception safe. As a consumer of the SerialPort class, I have to look through the source code to see what throws and then add explicit catch statements.
2. The coding standards I use recommend catching exceptions early by instead bringing them up to the higher layers (ie, ROS logger or ROS diagnostics) through the use of error codes. For a real-time system, not throwing exceptions could make it more deterministic timing-wise.

The proposal:

I am happy to help with design and implementation for this and contribute the changes open source, but could use some guidance. Key things to me:

1. Clarify through the code comments on which functions can throw in the current serial_port.hpp file.
2. Create a design (separate driver, separate function calls) to support an exception-safe version of the driver or modify the current classes to support this.
3. Design appropriate unit tests to ensure all calls to asio functions that can throw are appropriately protected.
4. At this point, it may be worth focusing on run-time exceptions rather than exceptions during the bring-up of the port, such as trying to open a port that doesn't exist versus reading from a port that was just disconnected during runtime.

can't read from the serial port. Publsiher is not activated.

I am trying to read from the serial port but after running the launh file , terminals outputs Publisher is not activated. I tried to check that port is available and about the permissions too using sudo dmesg | grep ttyACM0, but still the same. However, I oberved that whenever i run the dmesg command the terminal console outputs he same port /dev/ttyACM0 comes listed 5-6rows, which means that the serial port previously when the normal test script ran is not cleaned after terminating or remianed block. I have been looking and trying to find the solution but hard luck. It would be great if any could help with this. @sven-hoek

serial receive data only 1 byte instead of a list of byte

When receiving the serial data back... the data is present in a single byte by byte.. not in a list of bytes. for example [ 01 10 00 02], will show as 01, 10, 00, 02 (break into 4 messages with only one byte in the data field). I am not sure if it is normal behaviour or not...

For sending, as I pack the payload as a list first, when echoing the /serial_write, the data field shows all the bytes in a list.

How can I also achieve this on the receiving side? otherwise, it is pretty hard to determine the feedback signal

Windows Build

main...genevanmeter:transport_drivers:Windows

I made a few changes to build for Windows and Humble (see above link) While it appears to be working I'm not confident it's the "proper" ROS way to do it. Originally I attempted use the visibility_control.hpp documented here but was unsuccessful.

About Serial Drivers

When using serial driver to communicate with device, after driver launch, if plug out the device, the driver->is_open() still return True

Support serial break

Can support be added to send a break sequence to the serial device using asio's send_break?

For example, I'd like to call SerialPort.send_break()

My embedded device has a special sequence that relies on sending a break command.

I am happy to do the implementation, just wanted to pass it over here before writing the PR.