-
Couldn't load subscription status.
- Fork 300
[force mode controller] Fix the task frame orientation #1379
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
[force mode controller] Fix the task frame orientation #1379
Conversation
Before, we were using a RPY notation. Chaning that to an angle-axis notation should fix things.
…one of the main axes
3c8223c to
638ab3f
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1379 +/- ##
========================================
+ Coverage 3.59% 5.06% +1.47%
========================================
Files 13 33 +20
Lines 947 3438 +2491
Branches 152 424 +272
========================================
+ Hits 34 174 +140
- Misses 843 3262 +2419
+ Partials 70 2 -68
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This should avoid a coincitental overlap if the transformation is wrong.
638ab3f to
81a2282
Compare
* [force mode controller] Fix the task frame orientation Before, we were using a RPY notation. Chaning that to an angle-axis notation should fix things. * Update force_mode example to include a pose that is not in line with one of the main axes * Make test use an arbitraty orientation This should avoid a coincitental overlap if the transformation is wrong. (cherry picked from commit 8eb4288) # Conflicts: # ur_robot_driver/test/integration_test_force_mode.py
|
@Mergifyio backport jazzy |
✅ Backports have been created
|
* [force mode controller] Fix the task frame orientation Before, we were using a RPY notation. Chaning that to an angle-axis notation should fix things. * Update force_mode example to include a pose that is not in line with one of the main axes * Make test use an arbitraty orientation This should avoid a coincitental overlap if the transformation is wrong. (cherry picked from commit 8eb4288)
…1379) (#1381) * [force mode controller] Fix the task frame orientation Before, we were using a RPY notation. Chaning that to an angle-axis notation should fix things. * Update force_mode example to include a pose that is not in line with one of the main axes * Make test use an arbitraty orientation This should avoid a coincitental overlap if the transformation is wrong.
Before, we were using a RPY notation. Chaning that to an angle-axis notation should fix things. * Update force_mode example to include a pose that is not in line with one of the main axes * Make test use an arbitraty orientation This should avoid a coincitental overlap if the transformation is wrong. (cherry picked from commit 8eb4288) # Conflicts: # ur_robot_driver/test/integration_test_force_mode.py
… (#1380) Before, we were using a RPY notation. Chaning that to an angle-axis notation should fix things. * Update force_mode example to include a pose that is not in line with one of the main axes * Make test use an arbitraty orientation This should avoid a coincitental overlap if the transformation is wrong. (cherry picked from commit 8eb4288) # Conflicts: # ur_robot_driver/test/integration_test_force_mode.py * [force mode controller] Fix the task frame orientation (#1379) Before, we were using a RPY notation. Chaning that to an angle-axis notation should fix things. * Update force_mode example to include a pose that is not in line with one of the main axes * Make test use an arbitraty orientation This should avoid a coincitental overlap if the transformation is wrong. (cherry picked from commit 8eb4288) # Conflicts: # ur_robot_driver/test/integration_test_force_mode.py --------- Co-authored-by: Felix Exner <feex@universal-robots.com>
…ersalRobots#1379) (UniversalRobots#1380) Before, we were using a RPY notation. Chaning that to an angle-axis notation should fix things. * Update force_mode example to include a pose that is not in line with one of the main axes * Make test use an arbitraty orientation This should avoid a coincitental overlap if the transformation is wrong. (cherry picked from commit 8eb4288) # Conflicts: # ur_robot_driver/test/integration_test_force_mode.py * [force mode controller] Fix the task frame orientation (UniversalRobots#1379) Before, we were using a RPY notation. Chaning that to an angle-axis notation should fix things. * Update force_mode example to include a pose that is not in line with one of the main axes * Make test use an arbitraty orientation This should avoid a coincitental overlap if the transformation is wrong. (cherry picked from commit 8eb4288) # Conflicts: # ur_robot_driver/test/integration_test_force_mode.py --------- Co-authored-by: Felix Exner <feex@universal-robots.com>
Before, we were using a RPY notation. Changing that to an angle-axis notation should fix things.
This should fix #1375
@bsolon-tri would you like to try that locally?
I want to add a test checking further orientations and an updated example before merging this, but testing things locally seem to have resolved the issue.