Generic CANOpen Devices aka, non-motor support

[BenArtes]

We have a CANbus with some motors on it using ros_canopen; we're also starting to add non-motor devices (digital / analog inputs, video muxes, encoders etc) and looking to use the with ros_canopen. I had incorrectly read-between-the-lines of the canopen_master / canopen_chain_node wiki pages and code and thought that this was supported using the the 'publish' tag and get_object / set_object services. (Overall a more fully featured solution for generic can devices would be great, but I understand the focus of this project / package is on ros_control motor support). The devices I'm trying to integrate would be fine using these methods of communication for now.

It seems, I was hasty in my reading and this isn't supported. First I implemented a 'no_defaults' yaml tag in ros_canopen to get rid of pdo-mappings that apply for all the motors but don't make sense for non-motor devices. Then I was stuck because I tried to name the joints after non-joints. I tried optionally skipping the motor_node stuff out by creating non-motor tag but ran into other issues.

I just want to A) confirm that this isn't supported. And B) if I was to implement this feature, are there ways it would be best to implement or features that might seem important beyond my initial thoughts?

[mathias-luedtke]

Actually, one reason for writing ros_canopen was to address these use cases, which were not possible with our previous solution.

However, canopen_motor_node was not designed to be used with non-motor devices.
Instead, you should subclass canopen_chain_node and add a layer for your device profile (that's how canopen_motor_node worsk as well). As a first test you could just use canopen_chain_node as-is, but the object service are mostly meant for debugging.
You can run multiple processes in parallel, you just have to use the external sync feature (Example).

If you want to run everything in one process, you could subclass canopen_motor_node as well, but this might need some modifications. I have never tried this.

Another, much more flexible, way would be to add a plugin system to canopen_chain_node to load additional layers dynamically.

Overall a more fully featured solution for generic can devices would be great,

CAN or CANopen?
What is missing?