Add force mode controller #1049
Conversation
|
Also this is dependent on PR for the service definitiion. |
Also add example of using force mode controller
Current ToDos:
|
|
Hello, exciting to see this work in progress, we from AICA have already achieved force mode through ros2_control. My question is why you are implementing this through the async IOs and not as a full command mode in the Also, this PR is missing the updates in the xacro macros for the relevant command interface of the Happy to have a discussion, if there is interest from your side |
Yes, exactly.
Yes, this is still active work. But thanks for the hint I'll add it to the list.
You don't happen to be at ROSCon next week? |
I've been thinking about this comment and in all honesty, I don't think there is a valid reason why communication is managed outside of |
Currently, this isn't working as expected and we don't really have a method to counteract the robot "jumping" back to the joint configuration without force mode.
Since it isn't compatible with streaming controllers, we deactivate it for now. It can be activated at runtime.
This should be more thread-safe, as the buffers are filled from the same thread as the write function is called.
I can't say about thread safety, but I guess at the end the question is what you want to achieve. Our main goal for a force controller was to run force mode with an impedance controller as a primary control mode, while the robot has no other setpoints. For that, definitely the write function is the right place since the AsyncIO runs at a fixed (?) lower frequency. If however, you have applications in mind where one just enables force mode in one axis once and then uses joint velocity setpoints to drive the robot, the asyncio approach could work as well. |
Since the force_mode controller should be able to run with that, we need to update resource checking.
Since those are now in the service interface, we can delete them.
| { | ||
| // Reject if controller is not active | ||
| if (get_lifecycle_state().id() == lifecycle_msgs::msg::State::PRIMARY_STATE_INACTIVE) { | ||
| RCLCPP_ERROR(get_node()->get_logger(), "Can't accept new action goals. Controller is not running."); |
There was a problem hiding this comment.
| RCLCPP_ERROR(get_node()->get_logger(), "Can't accept new action goals. Controller is not running."); | |
| RCLCPP_ERROR(get_node()->get_logger(), "Can't accept new requests. Controller is not running."); |
| }) || | ||
| std::any_of(control_modes[0].begin(), control_modes[0].end(), [this](auto& item) { | ||
| return (item == hardware_interface::HW_IF_VELOCITY || | ||
| item == hardware_interface::HW_IF_POSITION /*|| item == PASSTHROUGH_GPIO*/); |
There was a problem hiding this comment.
Shouldn't this be uncommented?
| item == hardware_interface::HW_IF_POSITION /*|| item == PASSTHROUGH_GPIO*/); | |
| item == hardware_interface::HW_IF_POSITION || item == PASSTHROUGH_GPIO); |
| robot.call_service( | ||
| "/controller_manager/switch_controller", | ||
| SwitchController.Request( | ||
| activate_controllers=["force_mode_controller", "scaled_joint_trajectory_controller"], |
There was a problem hiding this comment.
Why are they both in activate_controllers?
Added force mode arguments: damping and gain scaling to be usable with the force mode controller. damping and gain scaling will be changeable every time you start force mode when PR is implemented.
This is an update to PR