rosp_canopen canopen_motor_node fails to compile / needs code edit to compile

asked 2015-07-21 09:16:43 -0500

190 ●20 ●29 ●37

updated 2015-07-21 11:04:49 -0500

Hi guys,

I want to catkin_make the recent version of ros_canopen, but this appears:

[100%] Building CXX object ros_canopen/canopen_motor_node/CMakeFiles/canopen_motor_node.dir/src/control_node.cpp.o
/home/marcel/ros/powerball_ws/src/ros_canopen/canopen_motor_node/src/control_node.cpp: In member function ‘virtual bool RobotLayer::canSwitch(const std::list<hardware_interface::ControllerInfo>&, const std::list<hardware_interface::ControllerInfo>&) const’:
/home/marcel/ros/powerball_ws/src/ros_canopen/canopen_motor_node/src/control_node.cpp:432:17: error: ‘canSwitch’ is not a member of ‘hardware_interface::RobotHW’
     (void) &hardware_interface::RobotHW::canSwitch; // compile-time check for recent ros-controls version of ros_control
             ^
make[2]: *** [ros_canopen/canopen_motor_node/CMakeFiles/canopen_motor_node.dir/src/control_node.cpp.o] Fehler 1
make[1]: *** [ros_canopen/canopen_motor_node/CMakeFiles/canopen_motor_node.dir/all] Fehler 2
make: *** [all] Fehler 2
Invoking "make -j4 -l4" failed

When removing line 432 -

(void) &hardware_interface::RobotHW::canSwitch; // compile-time check for recent ros-controls version of ros_control

from control_node.cpp it compiles and this seems not to affect the program at runtime. There is even this comment, suggesting, this is just a compile-time check.

Is this intended behaviour?

This seems to be intended behaviour. Although I could not see any difference while using ros_canopen package from when having to remove this one line of code to the situation where I did not. ros_canopen 0.6.4 compiles fine when having ros_control version 0.9.3.

edit retag flag offensive close merge delete

add a comment

1

answered 2015-07-21 15:00:41 -0500

Mathias Lüdtke

1596 ●2 ●26 ●26

updated 2015-07-21 15:03:29 -0500

This behaviour is intended and should prevent you from chasing version incompatibilities for several hours.

canopen_motor_node features the switching between the different CANopen operation modes (wiki) at run-time. For this to work a new interface was added to ros_control (#200) and finally got released with version 0.9.2/3.

This interface uses virtual methods and will therefore compile even if the base class does not have these methods. Of cause it will not work as expected, since the device will never switch to the required mode. In addition the new version of canopen_402 will not forward commands if no mode was selected and stops all motion by setting the halt bit in the control word.

By the way, ros_canopen 0.6.4 and ros_control 0.9.3 are available from the ROS repo and do not have to be built from source.

edit flag offensive delete link

add a comment

0

answered 2015-07-21 09:32:08 -0500

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

updated 2015-07-21 09:33:44 -0500

This would seem to be a good candidate for an issue on the ros_canopen issue tracker. Most likely your version of ros_control is not recent enough, and that statement is actually meant to trigger a compiler error in that case.

Which version of ros_control do you have installed? The debians (ros-DISTRO-ros-control) are most likely not recent enough.

edit flag offensive delete link

Comments

ros_canopen: 0.6.4 (cloned ros-indigo-devel today)

ros_control: 0.9.1

Marcel Usai ( 2015-07-21 10:11:54 -0500 )edit

Probably a good idea to open an issue to ask which specific version of ros_control is supposed to work with the ros_canopen pkg. That check was introduced in 4ef781, about a month ago.