wjwwood
Port to ROS2
I'd like a version of serial for ROS2. I've already made changes so it builds under Colcon but there's no branch to submit a pull request. Could you create such a branch?
https://github.com/RoverRobotics/serial-ros2.git
Depends on how you look at it I guess. I just have lots of things to do and this is not very high on my priority list. Your fork seems like an ok workaround for now.
I can make you a branch to which you can make a pull request, but I don't really have time to review it or release it at the moment.
Hi, I tried your repo @rotu : https://github.com/RoverRobotics/serial-ros2.git It works well, many thanks.
Any way we can get that merged back here and released? Or move serial to a ros-* org for Rover to potentially help maintain given their depencency on it (the best maintainers are users :smile: ).
+1 on the request. Is there a maintained ROS2 version? The branch in Rover reverted the ROS2 changes to support ament instead of catkin. It's also 8 commits behind.
There is also this PR #242 which is related.
Hey @wjwwood, I noticed you were able to do a quick noetic release today (even if it wasn't quite what you had planned), is there any progress on a ROS 2 binary release?
From memory I have been using one of the following forks/branches (I can't remember which and I'm not on my development machine at the moment) with no issues and it would be great to make it more widely available.
- https://github.com/cottsay/serial/tree/ament_cmake
- https://github.com/cottsay/serial/tree/pure_cmake
It looks like the Rover branch incorporated some of these changes, but as per the last comment, then reverted some?
Anyway, thanks for a great library :D
I have a functional version building in Galactic should you need it. It's frozen where it's at, but if there's a need to update it, just submit an issue or PR. Not sure how to contribute that upstream because it would break existing usage.
Long term I'm planning to use asio instead because it supports async and this doesn't. I'll happily share the ROS2 version here whenever that happens.
https://github.com/RFRIEDM-Trimble/serial-ros2
I have a functional version building in Galactic should you need it. It's frozen where it's at, but if there's a need to update it, just submit an issue or PR. Not sure how to contribute that upstream because it would break existing usage.
Long term I'm planning to use
asioinstead because it supports async and this doesn't. I'll happily share the ROS2 version here whenever that happens. https://github.com/RFRIEDM-Trimble/serial-ros2
Just an update to the above, in relation to #168:
I am working on an async ROS2 serial library, the start of which is here: https://github.com/RFRIEDM-Trimble/serial-port The above library can be compiled with straight CMake. I will probably have another branch or repo which acts as the ROS2 wrapper for it. Further discussion will be in the issues on that repo.
I'll leave my serial-ros2 fork of wjwwood up regardless, but the asio seems to be working much better for our application.
Looking for contributors.
Hi Any plan for debian release? Looking forward to have this awesome serial package to be installed via
sudo apt install ros-foxy-serial
Best, Samuel
This is also available as an alternative. I've tested, it works well. https://github.com/ros-drivers/transport_drivers/tree/main/serial_driver
@RFRIEDM-Trimble i saw that driver create a ros2 interface with topic for in and out bound message, but i am not so sure how to use it, does that mean I have to pack my payload into a array and publish to that topic if I want to send it out via serial COM?
@RFRIEDM-Trimble i saw that driver create a ros2 interface with topic for in and out bound message, but i am not so sure how to use it, does that mean I have to pack my payload into a array and publish to that topic if I want to send it out via serial COM?
That is correct. Side note - my previous work account, @RFRIEDM-Trimble, is now inaccessible.
@Ryanf55 Thanks for the reply! I will try using this instead of using rclpy with pyserial for now...
btw for the data payload, do I have to write it in forms of 0x10 0x11, or using decimal is also fine.
@Ryanf55 Thanks for the reply! I will try using this instead of using rclpy with pyserial for now...
btw for the data payload, do I have to write it in forms of 0x10 0x11, or using decimal is also fine.
It's language dependent. Usually, I'd be using a library to write the actual bytes. Unless you are doing some really low level stuff, I wouldn't be directly pushing single hex digits of data. It's out of the scope of this issue though to learn to pack binary data. I suggest looking up for whatever language you are writing your node in. Packing a buffer of data isn't within the realm of responsibility of this library.
To get you started: https://docs.python.org/3/library/struct.html https://www.geeksforgeeks.org/cpp-bit-fields/
I tried to use transport-driver and it works well, for those who is interested feel free to browse my repo ros2_serial_motor, but one thing I still haven't figured it out is that when sending its totally fine, I first pack all the byte to a list and send it to the topic, the data field is a list of byte.
But when receiving the serial data back... the data present in a single byte by byte.. not in a list of byte. for example [ 01 10 00 02], it will show as 01, 10, 00, 02 (break into 4 message with only one byte in data field). I am not sure is it a normal behavior or not...