Error Handling for Hardware Interface #69
Conversation
| robot_->stopRobot(); | ||
| } catch (const franka::Exception& e) { | ||
| RCLCPP_ERROR(getLogger(), e.what()); | ||
| return CallbackReturn::ERROR; |
There was a problem hiding this comment.
I guess when there is an error in this stage. HardwareInterface will go back to the on_configure() stage. Is it possible that the robot initializes itself after error is acknowledged. Or what exactly will happen when we are back in the on_configure() stage?
There was a problem hiding this comment.
@BarisYazici Thank you, sorry for the late reply. I am not sure how or when the robot initializes itself. Does that happen in firmware, or in libfranka, or both? I do not know much about Franka internals or libfranka, so I am probably not best equipped to write code which manages Franka's internal state.
There was a problem hiding this comment.
It was a question more on how you want to use this feature. Because if the robot goes in the reflex mode, by throwing an exception, the hardware interface will not be functioning. But the controllers will still be running without noticing that the hardware interface is in Error state.
It's mostly a question of how you wanna use this feature and how the ROS 2 hardware interface work. So with this change the hardware interface and the robot will not be updating but the controllers will continue to work. I don't think this is an expected behavior for the users. So unless we have a logic to recover the robot from the error state, I don't see the value of this feature. So maybe you can mention the use-case you have and we can try to suit the feature to your use-case. Maybe this involves going back to the configure stage or introducing a recovery state in the hardware interface. But in this current stage if we catch the exception we will not allow the exception to escalate, which might be misleading because they wouldn't understand why their controller stopped working.
|
Hey @jcarpinelli-bdai could you write the exact purpose of this PR for documentation purposes. |
Yes! Added to the description. |
… gripper Merge in MOCTRL/franka_ros2 from feature/PRCUN-3205-ik-example-works-without-hand to humble * commit 'bd03390ac9da75e561697947f3c327e0fafcd9b2': fix: joint_impedance_with_ik works with and without gripper
Like we talked about last week, @BarisYazici, this PR catches exceptions thrown by
Robotandlibfranka, and propagates these errors through thehardware_interface::return_typeand logging statements. Thank you for your time, and for considering this PR!Motivation
The
ros2_controlhardware and controller interfaces are managed nodes, with error-handling provided through therclcpp::node_interfaces::LifecycleNodeInterface. For this reason, the manager node (of typeControllerManager) does not anticipate managed nodes throwing exceptions. At this time,franka_hardware_interfacerelies onlibfrankaerror handling, which uses exceptions. When exceptions are thrown infranka_hardware_interface.cpp, theros2_control_nodeterminates due to the uncaught exception.This PR catches all internal
libfrankaexceptions, and reports each error through ROS logging and theCallbackReturntype that is anticipated byControllerManager. This will prevent theros2_control_nodefrom crashing when hardware errors occur.