-
Notifications
You must be signed in to change notification settings - Fork 333
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
Jtc sum periods #1395
Jtc sum periods #1395
Conversation
The generated period was more of an uptime
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1395 +/- ##
==========================================
+ Coverage 83.56% 83.57% +0.01%
==========================================
Files 122 122
Lines 10987 10991 +4
Branches 937 936 -1
==========================================
+ Hits 9181 9186 +5
Misses 1492 1492
+ Partials 314 313 -1
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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.
LGTM
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.
Looks good to me.
Doing this way, we are kinda doing it open loop with the time. Am I right?
Co-authored-by: Sai Kishor Kothakota <[email protected]>
Yes, that is true. That requires correct period times without missing or skipping a period. Which is why we recently found issues with that and fixed them. From what I can draw from the design concepts this is an assumption we can make here, though. |
Got it. Thanks for the explanation. |
Semi-binary builds should now also succeed, now that ros-controls/ros2_control#1898 is merged. I cannot restart the checks, though. |
f64c964
into
ros-controls:master
Sample trajectory based on the sum of periods instead of the absolute time.
This is basically the second part of #1191. In the long run I want to be able to scale the period with a scaling factor in order to artificially slow down / speed up progression in the trajectory. This PR is there to separate the necessary time counting change from the scaling functionality to make things more contained and easier to review.