ros_canopen
ros_canopen copied to clipboard
ros-industrial
ROS2 migration
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?
@JWhitleyAStuff already started to port the CAN-related packages.
IMHO the ros2_control proof-of-concept is not really suitable for porting right now.
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?
@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?
@samiamlabs @JWhitleyAStuff: It seems that you ported all packages except canopen_motor_node... Wow!
I have created a dashing-devel branch.
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.)
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)
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
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.
@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
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 :)
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 :)
@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.
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.
@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
You are right that this issue is not the best place for questions like this. It's likely that there is some issue with the .eds or .yaml files you are using. We just set up discourse forum here: https://forum.dynorobotics.se/ for questions like this.
@samiamlabs / @jLepers - I would suggest that you use either the ROS discourse or ROS answers for these types of long-running discussion just so that it's accessible to everyone.
I'd like to strongly echo @JWhitleyWork's comment.
@samiamlabs: why "hide" these discussions by distributing them across many different fora?
I'm not suggesting we move any part of the discussions about the official repository to a separate forum. The questions @jLepers asked were very specific to my experimental branches that are quite different from the official ros_canopen branches at this point in terms of API.
I actually think is reasonable to separate or "hide" this from discussions about the official repo to avoid confusion. If some of the changes I made end up in the official ROS2 branches with a more stable API, ROS answers or the ROS discourse make more sense of course.
I have been answering some questions over direct email up to now, which I don't like for several reasons.
@ipa-mdl What is the current status of the ROS2 migration? How far long is the dashing-devel branch? Are there plans to release for foxy?
I have now released can_msgs for foxy and rolling.
Migration is stuck with https://github.com/ros-industrial/ros_canopen/pull/364, which needs testing and should be updated to contain #362
@ipa-mdl #362 introduces XMLRPC which is the ROS1 communication mechanism. This seems counter to porting the node to ROS2.
introduces XMLRPC which is the ROS1 communication mechanism. This seems counter to porting the node to ROS2.
Yes, it was the only common place to put it for now.
But it does not block any ROS2 porting, because it was carefully designed to not interfere.
The xmlrpc interface is only used in a single header file, which is not used by socketcan_interface, and xmlrpc is only declared as a test dependency.
Hi All,
I'm also interested in using ros_canopen (402) with ROS2 (foxy) and ros2_control. What is the current status of ROS2 migration?
Hi guys,
I'm also interested in this ROS2 migration. I'm using galactic and I need to communicate using ros_canopen(301). What is the current status of ROS2 migration?
Hi @afonsofonbraga and @ThinkENG!
I have an experimental branch that I made a while back with support for 402 (motion control) and 401 (I/O modules).
I have tested the branch in a couple of in-house projects that use Nanotec and Technosoft motors. It also worked with a sysWORXX I/O module.
I made quite a lot of changes and probably a bunch of mistakes... I think it's a bad idea to just use that branch as the ros2 migration of ros_canopen.
The ROS interface in my branch is mostly a placeholder for ros2_control which was not in a state to be used back when I worked on this. ros2_control is pretty stable and works well now, and I would finish the migration in my own branch if I was not so pressed for time at the moment.
If anyone here wants to discuss the state of my branch I'm totally up for an online meeting next week. :)
Would be good to discuss if any of the changes I made should end up in the official ros2 release of this repo as well.
Hi @samiamlabs , I'm also interested in getting ros_canopen working with ROS2 and willing to test the current state of development. I there a testing package with configuration and launch file available for your migration package of ros_canopen (eloquent-experimental branch) ?
Hi @CyrilJourdan,
I only had the launch and param files in the actual project where I was using it.
These are the relevant files, but they need some modification to work outside of the project. launchfile params
Thank you @samiamlabs . I'm trying it and will give you feedback on your github page to avoid any confusion with the official package.
Hi @ipa-mdl, Regarding the official ROS2 migration of ros_canopen, how is it coordinated, is there a development roadmap made by some partners or consortium ? Or is it more done based on community's work without particular time-frame ?