-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serial (Dependency Missing) [Meta Issue] #21
Comments
This branch is for testing with `libcxx-serial-dev` See #21 This may be more out of date than the upstream Signed-off-by: Alex Moriarty <[email protected]>
Let me know how I can help. The asio version worked well in a few vehicles I used. Considering that the STL's upcoming support of networking is modeled after asio, I recommend trying to go that route. Many people start with |
@Ryanf55 did you use this version: https://github.com/ros-drivers/transport_drivers/tree/main/serial_driver I did start going down that path, I'll see if I still have the branch around locally. As I mentioned above, we've been using this branch: https://github.com/tylerjw/serial/tree/ros2 and know works and hadn't planned all the extra testing if we do swap to serial... I have a robotiq gripper on an arm and I need to ask a colleague with the serial adaptor to run hardware tests for me... but it does seem that we should be moving away from the https://github.com/wjwwood/serial dependency if wjwwood/serial#284 is not addressed or if wjwwood/serial#285 merged |
I've used both, deployed both libraries in the field, ran at 115k and 230k baud rates. Both worked. I was chasing down some communication issues with the other device, which turned out to be a fault in the embedded device. I know this one works: https://github.com/iwelch82/serial-ros2 It's interesting, I already add PIC, the commit here: tylerjw/serial@d8d1606 This just shows the need to consolidate efforts and stop forking basic drivers like serial. The nice thing about having it communicate over ROS transport for the read/write bytes means you can now use ROSbag to log raw data. Unlike CAN or ethernet which have nice tools (candump and tcpdump), there doesn't seem to be a good way to capture serial traffic due to exclusive ownership when opening the port. |
Using asio might be a bit tricky. With asio taking on the approach to use C++20 for the features like coroutine in their 1.17.0 release, which seem really great to use, since ROS 2 humble is on C++17, I don't know if the ROS organization would allow a bump to C++20 minimum for the serial driver. Perhaps we could have a chat, next week, to determine an approach? I'm on the ROS discord as |
- Run the same script that packages in ros-controls github org use - https://rtw.stoglrobotics.de/master/use-cases/ros_packages/configure_repository.html These will likely fail due to serial not being released for ROS2 - see #21 - wjwwood/serial#204 - wjwwood/serial#283 Signed-off-by: Alex Moriarty <[email protected]>
- we would prefer not to use the fork but we need to turn on CI - when wjwwood/serial#204 or wjwwood/serial#283 are closed we can switch - related to #21 Signed-off-by: Alex Moriarty <[email protected]>
This is a quick work around to unblock releasing robotiq_description - PickNikRobotics/ros2_robotiq_gripper#21 - serial has not been released since melodic Will update the robotiq_driver to use alternative and release Signed-off-by: Alex Moriarty <[email protected]>
This vcs step is no longer required because the robotiq_description package has been released. This vcs step causes confusion because it pulls in all of the robotiq repository and part of it depends on serial which hasn't been released for ROS 2. See this issue: PickNikRobotics/ros2_robotiq_gripper#21 Signed-off-by: Alex Moriarty <[email protected]>
Hi all, I see this is still an open issue. Is there a proposed workaround for getting this repo to build for use in ROS2? I'm definitely hitting the wall of build failures since there's no serial package that seems valid? |
I see this issue as well |
i also suffer from this, still no fix? |
Creating one top issue to track this and Closing #3 & closing #9 Which were duplicates for Foxy and Humble.
Unfortunately Foxy reaches EOL next week, so I do not expect serial will not be available in time for the last sync.
The underlying Issue is the same, the dependency https://github.com/wjwwood/serial has not been released to ROS 2.
See wjwwood/serial#204 and wjwwood/serial#209 and wjwwood/serial#209 (comment)
@wjwwood has mentioned wjwwood/serial#133 (comment) and wjwwood/serial#231 (comment) that he would like to move serial to a pure CMake package, there is a branch here cottsay/serial@4d5be00 which does this. I've tried to collect these issues here wjwwood/serial#283
There was a request from @SteveMacenski wjwwood/serial#204 (comment) to move the serial repo to it's own location, which I've opened as an issue here wjwwood/serial#284
The Robotiq gripper isn't the only package which has been using serial, @tonybaltovski pointed out here wjwwood/serial#209 (comment) that they're working on porting some other packages to ROS 2
There are several branches and forks which can be found from going through the above issues.
Currently we've been using this package with this branch, on this fork https://github.com/tylerjw/serial/tree/ros2 which was started off of this open PR wjwwood/serial#209 which is pretty close to this https://github.com/RoverRobotics-forks/serial-ros2
There alternative mentioned here: wjwwood/serial#204 (comment) is not a drop in replacement, it uses boost asio which throws different exceptions.
Another alternative is to use the debian which is released as
libcxx-serial-dev
which comes from this PR wjwwood/serial#231 on this fork & branch https://github.com/leamas/serial/tree/prBut all the different branches and forks are slightly diverging and we'll need to inspect the commit history and test.
We know the branch we've been using is pretty well tested.
The text was updated successfully, but these errors were encountered: