Is the realtime lost if I use ROS_INFO inside a ros_control controller update method or inside a ros_control hardware interface write/read method?
yes. It depends / probably.
In the end, ROS_INFO(..)
gets expanded to ROSCONSOLE_PRINT_AT_LOCATION_WITH_FILTER(filter, ...) which calls ::ros::console::print(..)
which in the end makes use of either printf(..)
, fprintf(..)
or a function in that group and/or calls upon one of the backends (glog
, log4cxx
) to do the work.
Unless a custom implementation of the printf(..)
family is used, calling it typically results in loss of determinism. Xenomai wraps printf(..)
and could work-around this. Not sure about RT-PREEMPT.
But apart from that there are multiple places where objects are instantiated and functions in various libraries are called. Those are also a bit suspect.
Btw: this is not specific to
ros_control
. Any deterministic context in which `ROS_* log macros are used would be affected similarly.Developing controllers or hardware nodes via ros_control is some kind of "standard approach" to interface hardware and develop your control algorithms.
I assumed here that in general for any controller is desirable to be real time.
I meant to say with my comment that even without
ros_control
, but in a general situation where deterministic execution is desired, usingROS_INFO(..)
or any of the other variants will probably have exactly the same effect.ros_control
is not special.We are in agreement, ros_control is not special.