what is expected from no_mode in ros?
I am firmware developer for motor control that supports DS 402.
My question is what is expected (in ros) from a motor when it is in operational state, and it's mode was changed from lets say Profile Position or Profile Velocity to so called "no mode". Here are two cases I would like to hear your opinion: 1. PDO 0x6060.0 = 0 (reserved) 2. PDO 0x6060.0 = -1 (no mode)
Thanks
This is a question about a rather specific and specialised topic, namely behaviour of CANopen devices which support profile DS 402.
Answers will therefore be limited to those situations where users have been exposed to these kinds of devices and by the package(s) they've used in those cases.
But you don't specify which package(s) you are targetting with your question.
Asking "what does ROS do" or "how does ROS do X" doesn't really work: ROS itself does nothing. Only nodes in packages do something.
As far as i know, in ROS, they are changing operation mode to "no mode" when they want to stop controlling the node (node is motor controller w/ DS402, they - software developers), and go to another node or do anything else. Does this makes any to use ROS in that way?
Are you saying that ROS has no knowledge about what is controlling the motor (DS402 or anything else, idk, gcode?), but it has some interface with external package that knows how to communicate with motors and ROS? Is there a lot of different packages with DS402 support?
who are they?
It's not really meaningful to say "they are", as personally I already know of 4 different packages to interface with CANopen networks.
You can't really say anything generically about ROS, unless you're referring to parts of the infrastructure (ie: the middleware).
All of the other functionality is provided by nodes (ie: executable binaries) in packages.
Edit: just noticed this:
"software developers" still doesn't tell us which packages you are referring to.
What I'm trying to get at is: the behaviour you're describing is likely specific to a package. It's not a generic usage pattern shared by "all CANopen pkgs in ROS that interface with DS 402 devices".
Without knowing which package you're seeing this behaviour in, it's not going to be ...(more)
this starts to go in the right direction, except that "ROS has no knowledge" would be a strange thing to say.
ROS is the name of a framework. There is no active entity here. Applications are built by combining components, one of which could be a component for interfacing with CANopen networks -- which happen to have devices on them which adhere to DS 402.
The rest of the application indeed doesn't necessarily need to know that.
Would ros_canopen perhaps be the package you're referring to with "node is motor controller w/ DS402"? It does have a canopen_402 package which provides basic functionality around that profile, and a specialised canopen_motor_node package which implements an abstract interface over that to actuators which can then be used by "any" other ROS node.
But as I wrote: there are quite a few other CANopen related packages, so perhaps you're referring to something else.
"ROS has no knowledge" would be a strange thing to say. - I sad this because ROS can work with different packages, so it works using some interface, and I assume ROS does not use canopen object dictionary entries to control ds402 node. Instead, the package knows about canopen object dictionary and knows how to control ds402 node. Thas said ROS has no knowledge about ds402 but it has its package that takes commends from ROS and uses those commands to control ds402 device. Or maybe application takes care of both ROS and the package. Either way ROS has no knowledge about ds402.
As I found out, thanks to you, it really is ros_canopen package. So I guess the question is not ROS related, it is ros_canopen package related which is a completely different software?