-
Notifications
You must be signed in to change notification settings - Fork 2
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
Adding Hydraulic Pneumatic Friction plugin #100
Conversation
Signed-off-by: Dharini Dutia <dharini@openrobotics.org>
Nice job Dharini making a clean and simple plugin to address this need. I have a few suggestions for checking/consideration. The friction force versus speed interpolation defined by: pistonSpeed{-0.4F, -0.3F, -0.2F, -0.1F, 0.0F, 0.1F, 0.2F, 0.3F, 0.4F}, probably needs a larger extend, in the paper tests were done up to these speeds (+/- 0.4 m/s) but in actuality the piston could go quite a bit faster. I'd say to be sure of covering the possibilities, the chart should go up to +/- 2m/s. Because this interpolation consists of just a few straight lines, it may not be necessary to include points in the intermediate parts of the straight sections, which could speed up the interpolation some. I believe splinter may be configured to use the highest values in the interpolation table when independent variables greater than the defined extent are used, this would be good to include if it's possible. @andermi knows what's possible I believe. Also, in what's sure to be a continual source of confusion, the internal gazebo model uses and opposite sign for the position of the ram extension compared with the paper and actual system at sea. So we need to swap the sign of the velocity relative to the paper. For now I suggest we keep this annoyance as we've addressed it throughout the code in a number of places, if we decide to change it to match, we can do it once and hopefully find all places to fix it. Finally, I will suggest a simpler name for this plugin. I think PTO_Friction or similar is fine, the friction being simulated here is a combination of a lot of contributions, from the hydraulic ram, from the pneumatic part, from extraneous other seals, etc. So avoiding the specificity of HydraulicPneumatic might be a good idea. Not too important if it's challenging to change. |
That's exactly the feedback I was looking for, thanks Andy!
|
I think it's OK to just linearly extrapolate the lines we have out to +/-3m/s or thereabouts. No harm in going further and that reduces the issue with things being out of bounds. +/-5m/s would be way faster than we ever expect to see... |
Michael is out on the boat today, so here's an example of splinter use from elsewhere that returns the endpoints when an out of bound request is made: I haven't tested this carefully, (in michael we trust...:), but in the friction case we'd still want a wide expanse and only count on this for the unexpected case of a higher speed than expected. Otherwise I'm not sure what spinter returns when the argument is out of bounds, perhaps it extrapolates, or returns dragons... |
Update the plugin as per feedback.
What's our tolerance? |
I'm going to open a PR in a moment to add a different interpolator. We have found issues with splinter not doing the right thing, unfortunately. Edit: here's the interp PR: #101 |
Pending removing splinter. |
Signed-off-by: Dharini Dutia <dharini@openrobotics.org>
osrf/mbari_wec_utils#36 has been merged, so you should be able to update accordingly here. |
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 once splinter is replaced 👍
Signed-off-by: Dharini Dutia <dharini@openrobotics.org>
Signed-off-by: Dharini Dutia <dharini@openrobotics.org>
Replaced splinter, but the build will totally fail without the motor mode PR. Shall I wait for it to be merged or change base and get this in? |
Sorry, I didn't quite think that one through. The issue is that |
Agreed, I am running down a couple of test issues with motormode but let's aim to get that merged this week so we can have a buildable main again. |
Signed-off-by: Dharini Dutia <dharini@openrobotics.org>
buoy sc tests are failing since buoy position is now different with the friction added, working on updating the numbers. |
Signed-off-by: Dharini Dutia <dharini@openrobotics.org>
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.
I just caught a couple more things
buoy_gazebo/CMakeLists.txt
Outdated
) | ||
endif() | ||
if(gz_add_test_ROS) | ||
set(ROS_PKGS rclcpp simple_interp ${gz_add_test_EXTRA_ROS_PKGS}) |
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.
simple_interp
should be added as an argument to the gz_add_gtest
function after EXTRA_ROS_PKGS
instead of explicitly adding it here.
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.
In order to use your include files for the friction plugin in the test in buoy_tests
, copy the pattern here to install your include files
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.
Sorry, I was wrong about copying that pattern to use the includes. (I wasn't thinking quite clearly!)
You need to export the friction plugin library
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.
but that's only if you want to use the class directly to recreate the test you made...
Or, you could just use the gz_sim test fixture and load the plugin that way for other testing
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.
Either way works for me. I'l follow the pattern of other tests by using the gazebo test fixture
class PTOFrictionTest : public ::testing::Test | ||
{ | ||
public: | ||
const std::vector<double> speed; // m/s | ||
const std::vector<double> force; // N | ||
simple_interp::Interp1d friction_model; | ||
|
||
PTOFrictionTest() | ||
: speed{-5.0, -0.4, -0.1, -0.05, 0.0, 0.05, 0.1, 5.0}, | ||
force{12750.0, 1200.0, 700.0, 400.0, 0.0, -750.0, -1000.0, -32033.0}, | ||
friction_model(speed, force) | ||
{ | ||
} | ||
}; |
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.
Try including your plugin class rather than recreate here so we test the values in used in the plugin.
} | ||
}; | ||
|
||
TEST_F(PTOFrictionTest, ModelAccuracy) |
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 good test for the interpolator.
I wonder if it would be good to add a test like:
- run the sim without the friction plugin disabled and measure settling time
- run the sim with the friction plugin enabled and the settling time should be faster
Signed-off-by: Dharini Dutia <dharini@openrobotics.org>
Signed-off-by: Dharini Dutia <dharini@openrobotics.org>
Changing absement values is not affecting the piston motion |
…ed negative sign on friction and added comment Signed-off-by: Michael Anderson <anderson@mbari.org>
…into quarkytale/friction Signed-off-by: Michael Anderson <anderson@mbari.org>
fixed with 1ebd6c6 |
Signed-off-by: Michael Anderson <anderson@mbari.org>
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
Getting this in, working on adding a launch test Michael suggested, in another PR |
A new plugin and test framework is ready. Need to work on model accuracy.