Enhance: Added joint limit loader plugin - #2442
Conversation
…g of available classes Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
…ation limits Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #2442 +/- ##
==========================================
+ Coverage 86.83% 86.97% +0.13%
==========================================
Files 148 149 +1
Lines 16273 16615 +342
Branches 1368 1394 +26
==========================================
+ Hits 14131 14451 +320
- Misses 1635 1644 +9
- Partials 507 520 +13
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
type Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
Test Integrated
|
Moved joint limiter tests from `test_trajectory_controller.cpp` to a new `test_joint_limiter_jtc.cpp` file and added a helper function to provide default limiter parameters to reduce duplication. Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
Expanded the test suite to include long and short trajectories that exceed defined limits. Also replaced `std::abs` with `std::fabs` for floating-point comparisons in tests and marked helper function as inline. Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
|
This pull request is in conflict. Could you fix it @sachinkum0009? |
destogl
left a comment
There was a problem hiding this comment.
Please comment. It seems a bit trivial implemenation. Explain why you think it is correct.
| // Apply joint limiter to the next commanded state | ||
| if (joint_limiter_) | ||
| { | ||
| joint_limiter_->enforce(state_current_, command_next_, update_period_); |
There was a problem hiding this comment.
why is here the right place to enforce limits? Shouldn't we do this in before and after interpolation?
There was a problem hiding this comment.
I think the best place to enforce limits is after the interpolation. If appied limits before interpolation, it can produce inconsistent interpolation results.
There was a problem hiding this comment.
What happens than with the interpolation? Will we still have interpolated values?
There was a problem hiding this comment.
Thanks. Yes, we still have the interpolated values, as the joint limiter is applied before publishing the next cmd to hardware interface.
| // Apply joint limiter to the requested state | ||
| if (joint_limiter_) | ||
| { | ||
| joint_limiter_->enforce(state_current_, state_requested, update_period_); |
There was a problem hiding this comment.
Why this second call in the query state service?
There was a problem hiding this comment.
As the ~/query_state service (control_msgs::srv::QueryTrajectoryState) allows querying the expected state at a future time. I think if we have joint limiter plugin enabled then we should return the response with limits applied.
| EXPECT_NEAR(joint_vel_[0], 0.5, COMMON_THRESHOLD); | ||
| EXPECT_NEAR(joint_vel_[1], 0.5, COMMON_THRESHOLD); | ||
| EXPECT_NEAR(joint_vel_[2], 0.5, COMMON_THRESHOLD); | ||
| EXPECT_NEAR(joint_pos_[0], INITIAL_POS_JOINT1 + 0.5 * 0.01, COMMON_THRESHOLD); |
There was a problem hiding this comment.
I am not sure whether this is correct, as you are testing the limiter. What happens with interpolation in this case? Are we breaking it?
There was a problem hiding this comment.
Thanks, I have updated the tests to validate the interpolated values and make sure the position, velocity and acceleration remains within the limits.
updates Replace static initial positions with a trajectory containing three distinct waypoints. Adjust the update loop to step through each segment using constant 10ms intervals, ensuring verification covers the full duration of the published points up to t=0.6s. Use `limit_enforced_points` for assertions to account for clamped values at specific times rather than checking immediately after publishing a single point. Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
Replaced single-step snapshot assertions with a loop that advances the controller at 10ms intervals. This change verifies both velocity and acceleration limits across multiple interpolated points for each segment of the trajectory. Tests now iterate through all waypoints, ensuring constraints hold throughout motion rather than just after initial application. Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
Increase `max_velocity` for joint1, joint2, and joint3 from 0.5 to 2.0 radians/s in the unit tests configuration function. This adjustment reflects realistic actuator capabilities used during testing scenarios involving dynamic motion commands. Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
clamping - Remove unused `limit_enforced_points` vectors from velocity and acceleration tests. - Replace manual assertions with a loop stepping through the trajectory at 10ms intervals. - Verify that commanded velocities, accelerations, and positions respect all limits throughout execution. Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>
Signed-off-by: Sachin Kumar <sachinkum123567@gmail.com>


Description
This PR integrates the Joint Limiter using Plugin Loader to use Joint Saturation Limiter.
Fixes #2434
Is this user-facing behavior change?
Yes, with this PR, the JTC uses Joint Saturation Limiter to limit the pos, vel, acc, or jerk based on the configuration.
Did you use Generative AI?
Used OpenCode to understand the code and write tests.
Additional Information
TODOs
To send us a pull request, please:
colcon testandpre-commit run(requires you to install pre-commit bypip3 install pre-commit)