Open mathias-luedtke opened 4 years ago
Are you intending this to be a "complete" port for Dashing? If so, we should consider using composable nodes.
This is only the non-ROS part, I might add canopen_master
and canopen_402
as well.
For the ROS-based packages, composable (and managed) nodes seem to be a very good option.
What type of testing do we need to do here? Just manually make sure everything works (with hardware?) or automated tests of some kind?
What type of testing do we need to do here?
Hardware tests (or just with vcan) are fine for now :)
@Rayman: Did this version work for you?
Yes, I've just re-verified this. It compiles. There are still some tests that fail (uncrustify), but that could also be fixed later.
There are still some tests that fail (uncrustify), but that could also be fixed later.
ROS crystal seems to have a different uncrustify version.. I will will rebase this PR and disable the tests for crystal later.
Crystal is EOL so I don't see any reason to have the Crystal builds included.
There seems to be a problem with the install command in CMakeLists.txt:
55 install(FILES socketcan_interface_plugin.xml DESTINATION share/${PROJECT_NAME}/socketcan_interface_plugin.xml)
At least for me it throws the following error:
Starting >>> socketcan_interface
[Processing: socketcan_interface]
--- stderr: socketcan_interface
CMake Error at cmake_install.cmake:41 (file):
file INSTALL destination:
/home/christoph/ws_ros2/install/socketcan_interface/share/socketcan_interface/socketcan_interface_plugin.xml
is not a directory.
---
Failed <<< socketcan_interface [54.9s, exited with code 1]
Summary: 0 packages finished [55.5s]
1 package failed: socketcan_interface
1 package had stderr output: socketcan_interface
Not sure if this is only throws an error for me. Simple fix is:
55 install(FILES socketcan_interface_plugin.xml DESTINATION share/${PROJECT_NAME}/)
Tested on Ubuntu 20.04, foxy. Everything else works fine.
Not sure if this is only throws an error for me. Simple fix is:
55 install(FILES socketcan_interface_plugin.xml DESTINATION share/${PROJECT_NAME}/)
You could also use pluginlib_export_plugin_description_file
(see this link
@ipa-mdl Please see https://github.com/ipa-mdl/ros_canopen/pull/6. Testing with vcan
now.
Last month I've run this branch on a robot that has a socketcan interface and it works quite well. It's now driving with with navigation2 stack on top.
I think this branch is ready to be merged.
As an alternative for anyone who just needs basic SocketCan functionality on ROS2, check out https://github.com/autowarefoundation/ros2_socketcan.
I think this branch is now ready for merge. Only the crystal CI is failing because the linter behaves differently. But crystal is not supported so it doesn't matter.
What's the status of this PR? I also ran this on an actual robot (in Foxy even) and it worked perfectly. It would be great if this could be merged and give some functionality to ros_canopen in ROS 2
ping. Can someone merge this?
Just wanted to mention, we have started an effort to create ros2_canopen. An alpha with service interface (no ros2_control) is planned in the next weeks. ros2_control integration will come soon.
Architecture has been restructured and lely_core's canopen stack was integrated. There is no direct can/ros bridge any more, only canopen.
Code is here: https://github.com/ros-industrial/ros2_canopen Documentation is here: https://ros-industrial.github.io/ros2_canopen Example is here: https://github.com/ipa-cmh/trinamic_pd42_can
mostly based on #359
ToDo: