Add instruction executor for high-level robot control #242
+898
−3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #242 +/- ##
==========================================
+ Coverage 71.71% 72.93% +1.21%
==========================================
Files 71 75 +4
Lines 2786 2889 +103
Branches 353 360 +7
==========================================
+ Hits 1998 2107 +109
+ Misses 596 591 -5
+ Partials 192 191 -1 ☔ View full report in Codecov by Sentry. |
The times are only rough and should reflect the trajectory time plus some overhead.
This was changed during development, but should not get merged.
urfeex
force-pushed
the
motion_commands
branch
from
7f9a1c4 to
ff9d90e
Compare
Estimating the exact execution time in CI is very hard, so we restrict it by bounds to check whether the right parameters are actually being used. This could be greatly improved by faking / mocking the actual execution for a unit test instead of using URSim in an integration test.
urfeex
force-pushed
the
motion_commands
branch
from
ff9d90e to
38543e6
Compare
| // time parametrization below with a motion time of 2.5 seconds, so this is the upper bound to | ||
| // distinguish between the two. This large range is necessary, as the actual overhead is not | ||
| // known. | ||
| ASSERT_GT(duration.count(), 1400); |
There was a problem hiding this comment.
Shall we add some failures to test if the error codes match?
EXCEPTIONS maybe?
That was commented out for local testing and should never have ended up in the PR.
urfeex
force-pushed
the
motion_commands
branch
from
a111409 to
37e20c3
Compare
Otherwise the hardware will send a result that we will never read and this will bleed into next excution.
SarveshMalladi
approved these changes
Jan 22, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the trajectory point interface there is a method of executing motions with only the urcl present as shown in https://github.com/UniversalRobots/Universal_Robots_Client_Library/blob/master/examples/trajectory_point_interface.cpp
However, usage is a bit cumbersome, we might want to support a one-liner for executing ptp motions, instead.
This PR adds the
InstructionExecutor, a high-level module that uses existing functionality to provide simple-to-use interfaces, currently to execute MoveJ, MoveL and sequences of the two. In future, we might extend that to other instructions such as other motion types, but possibly also other functionality, hence the more general name.