Ros2_canopen shortcomings and improvements

ROS ROS General
1

During the integration of our hardware we (inmach.de) encountered some shortcomings in the ros2_canopen package which we worked around or fixed in our fork of ros2_canopen. We’d like to get these changes into the upstream repo so that everyone can profit from them.

The major shortcomings we found and think should and could be improved are:

  • The CIA402 Driver only supports 1 axle but the standard allows up to 8 axles (our hardware supports 4 axles)
  • The canopen_ros2_control systems can not handle different types of CAN devices on the same CAN bus so one has to write an own system in this case. This get’s even worse if a node with a custom api should be used.
  • Because ros2_control just reuses the normal Node implementation there are always also the ROS topics/services available which can easily bypass the ros2_control controllers.
  • The use of a template for ros2_canopen::node_interfaces::NodeCanopenDriver to handle the case of Node and LifecycleNode has probably historic reasons. The current proposed ROS way to handle this case is to use rclcpp::node_interfaces.

With this post I’d like to start a discussion with the ROS community and the maintainers of ros2_canopen about other possible shortcomings and what needs and can be done to improve the ros2_canopen stack. So that we together can make it even better in the years to come.

2 Likes
2

I am very glad you opened up the topic! I’ve been developing a robot using ros2_canopen for a little over a year, and have also hit my head on some of your points. Two items I would add to the list are:

  • SYNC transmission, and thus synchronous PDOs, run on an timer (managed by the lely lib) that is independent from ros2_control’s main controller_manger loop timer. This means that timestamps reported in ros2_control can be anywhere from 0 to 2 SYNC cycles out of phase with when the data was sampled (assuming SYNC rate matches ros2_control rate), and this all relies on the OS scheduler being nice. A feature I’m currently working on, which I hope to soon raise an RFC / PR for, allows for coupling the ros2_control loop to the CANopen SYNC loop, making both have coherent timestamps. My current design is to provide an alternative ros2_control_node that hooks onto the lely timer and passes appropriate timestamps to the read(), update(), write() ros2_control functions. I would absolutely appreciate any input on this topic.

  • documentation/examples: canopen_ros2_control RobotSystem and Cia402System seem to solve the same problem in slightly different ways, and have been developed concurrently (looking at the commit history & copyright statements). If they are each suited to a more narrow use-case, that’s not at all evident from the current docs, examples, and dependent projects. Having a clear recommendation for which one to use would help new robots adopting ros2_canopen. I myself have switched from RobotSystem to Cia402System and back, somewhat aimlessly.

1 Like
3

Hi @mwopfner @trupples

Did you open a pull request / file an issue against the repository? I am not seeing anything on the repo itself. It usually helps to have concrete artifact to get the conversation rolling. It might also help to tag the maintainers here (@c_h_s ) so they see the conversation.

4

My first point isn’t yet ready for a PR, and once it is, I’ll unfortunately also have to wait for approval from my almighty corporate overlords. :grimacing: I’ll write up a nice PR & forum post when the time comes (following weeks/months), I promise. :folded_hands: