-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added service to enable and disable tool contact #940
base: main
Are you sure you want to change the base?
Conversation
Split this pull request into two. This PR now only implements the tool contact functionality and testing of that (Will only work on E-series robots). The get_version service implementation has been moved to PR. |
64d0b35
to
d825856
Compare
Also added service to get robot software version.
This reverts commit f6bf8c6.
I've tested this today and while it seems to be working well, I think the interface should be improved:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #940 +/- ##
========================================
+ Coverage 3.59% 3.78% +0.18%
========================================
Files 13 395 +382
Lines 947 43518 +42571
Branches 152 6404 +6252
========================================
+ Hits 34 1645 +1611
- Misses 843 41730 +40887
- Partials 70 143 +73
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Removed tool contact functionality from GPIO controller.
…till untested. I have not done anything with starting and stopping the controller yet.
This exposes an action to execute a trajectory, either until the trajectory is finished or until the "until" condition is met.
Depends on ur_msgs PR for the action definitions |
Also fixed some little bugs
… motion controllers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a first review. I haven't reviewed the move_until node in detail. Maybe we can move that to a separate PR for now and only concentrate about force mode in here? Should make it faster to get that one in. And they can be split into two separate problems with ease.
ur_controllers/CMakeLists.txt
Outdated
# | ||
# trajectory_until_node | ||
# | ||
add_executable(trajectory_until_node | ||
src/trajectory_until_node.cpp | ||
) | ||
ament_target_dependencies(trajectory_until_node ${${PROJECT_NAME}_EXPORTED_TARGETS} ${THIS_PACKAGE_INCLUDE_DEPENDS}) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Debatable, but in my opinion this would belong into the driver's package. We have most other utilities over there, as well.
// template <typename action_type> | ||
class TrajectoryUntilNode : public rclcpp::Node | ||
{ | ||
private: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please have public sorted before private.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There could be other parameters rather than hard-coded values. e.g. the action monitor rate.
cancel_res = self._tool_contact_interface.cancel_goal(goal_handle) | ||
self.assertEqual(cancel_res.return_code, 0) | ||
|
||
def test_trajectory_until(self, tf_prefix): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
def test_trajectory_until(self, tf_prefix): | |
def test_trajectory_until_tool_contact_without_obstacle_results_in_SUCCESS_and_NOT_TRIGGERED(self, tf_prefix): |
change interface between hardware interface and controller Intermediate commit
Also added service to get robot software version.