ROS2 migration

[samiamlabs]

Hi,

I want to use ros_canopen (402) with ROS2 and ros2_control for an upcoming project.

Thinking about migrating the parts of ros_canopen I need to ROS2 myself. Has anyone already started working on something similar? Are there any plans to migrate relatively soon?

[mathias-luedtke]

@JWhitleyAStuff already started to port the CAN-related packages.

IMHO the ros2_control proof-of-concept is not really suitable for porting right now.

[samiamlabs]

Great, I will take a look at that!

I agree that ros2_control is far from production ready. The project I want to use it for is also just a proof of concept. Was thinking that extending ros2_control for my specific use case makes more sense than building something custom from scratch. Have not decided yet.

Do you know of any better options @ipa-mdl?

[samiamlabs]

I have started porting some of the CANopen packages to ROS2 here.

[JWhitleyWork]

@ipa-mdl - I haven't been able to work on this for a while but @samiamlabs and I have done a good amount of work. Can you please create a dashing-devel branch so I can create a PR?

[mathias-luedtke]

@samiamlabs @JWhitleyAStuff: It seems that you ported all packages except canopen_motor_node... Wow!
I have created a dashing-devel branch.

[samiamlabs]

Thanks!

I also have a WIP for the motor node on the ros2_control branch.

We are using it with Technosoft iPOS drivers for a project and I have a web based dubug UI for it as well.

I took a lot of shortcuts to get something to work at all, and we are having stability issues and trouble getting the drivers to work again after e-stop has been toggled.
Planning a proper rewrite in the coming weeks.

Have been considering a fairly large redesign to add support for IOs (401) on the motor drivers and several different types or devices managed by the same canopen instance. Both motors and IOs for example, configurable by params. (We have 4 iPOS drivers and one sysWORXX CANopen IO-C12 in our setup now and need two separate nodes atm.)

[jLepers]

Hi,

I'm also interested in using ros_canopen with ROS2. I see that there is already a branch dashing-devel, but I would like to know how far this migration is at this moment.
If this is already functioning, is it possible to install it like this :
apt-get install ros-dashing-ros-canopen ? (not working at this moment)

[samiamlabs]

Are you interested in using it for 402 profile motor controllers or something else?
I have a version for crystal with motor control that is a bit of a hack to get something temporarily up and running for one of our projects here: https://github.com/samiamlabs/ros_canopen

I'm working on a new implementation of the ROS2 layer right now (with features like lifecycle). https://github.com/samiamlabs/ros_canopen/tree/dashing-experimental

We plan to use it for some of our own new autonomous systems, but I'm not sure if the fork will be a good candidate for the official ros2 branch any time soon. There are quite a few changes from the ROS1 version already, and it's not really a straightforward port anymore.

Haven't added support for motors to my experimental dashing branch yet, but hoping to get that done before Christmas :)

Here is a little video that demonstrates how the web-based debug/configuration interface works.
https://www.youtube.com/watch?v=P1imv620lKc&feature=youtu.be

[mathias-luedtke]

I would like to know how far this migration is at this moment

The migration is progressing slowly.
#359 contains a prototype, but it needs some updates.
#364 is the first step towards ROS2 packages, but needs testing.

[jLepers]

@samiamlabs I understand that the change to ROS2 is quit big. Instead of using the motor_node (402), I should be able to do the same with the chain_node(301), it is just not the smoothest way. I checked your repo but didn't find the GetObject.srv and SetObject.srv in the chain_node. I see that you all already did a great job, but is there already 1 version of ros2_canopen that is stable enough to use ? I checked your dashing-experimental branch, should I use the chrystal branch instead ? Or should I use this repo (branch dashing-devel) Thanks a lot

[samiamlabs]

Not sure what you mean by the GetObject and SetObject services. The callbacks are here: https://github.com/samiamlabs/ros_canopen/blob/0ab10ce21433de962634cc61afa73d3107aa5db9/canopen_chain_node/src/canopen_chain_component.cpp#L205

The dashing-experimental branch is a lot further ahead in terms of functionality than the other ones.
I would not consider it stable the way that the ROS1 repository is, but most of the features are there and I don't know of any bugs.

Use at you own risk :)

[jLepers]

OK thanks. I have a working melodic node that uses the GetObject and SetObject services:
https://github.com/ros-industrial/ros_canopen/tree/melodic-devel/canopen_chain_node/srv

The code I use is completely based on getting and setting the motor: (example)
set.request.object = "0x6081";
set.request.value = "200";

I'm a beginner so I'm having troubles understanding the working of your dashing branch, that explains the level of my questions :)

[jLepers]

@samiamlabs what could be the couse of following error ?
https://github.com/samiamlabs/ros_canopen/blob/dashing-experimental/canopen_chain_node/src/canopen_chain_component.cpp#L572
The CAN device is connected in my case.

[samiamlabs]

Are you sure that your can interface shows up as a socketcan network device with the correct name? The default should be "can0". One way to check is to run candump can0 in a terminal.

[jLepers]

@samiamlabs fixed the error, still not able to init CAN ...
https://github.com/samiamlabs/ros_canopen/blob/dashing-experimental/canopen_chain_node/src/canopen_chain_component.cpp#L577
No error messages anymore, candump works fine, the output gets stuck at "Activating canopen_chain".
Is it possible to open an issue on your repo ? I don't think that this is the correct place for those kind of questions.

edit: the node doesn't get past here https://github.com/samiamlabs/ros_canopen/blob/dashing-experimental/canopen_chain_node/src/canopen_chain_component.cpp#L570