-
Notifications
You must be signed in to change notification settings - Fork 45
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
Add docs to wheel_slip_parameters_cmd.proto #227
Add docs to wheel_slip_parameters_cmd.proto #227
Conversation
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Codecov Report
@@ Coverage Diff @@
## ign-msgs7 #227 +/- ##
==========================================
Coverage 85.60% 85.60%
==========================================
Files 9 9
Lines 924 924
==========================================
Hits 791 791
Misses 133 133 Continue to review full report at Codecov.
|
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.
Thanks for adding docs!
@@ -31,9 +31,29 @@ message WheelSlipParametersCmd | |||
/// \brief Optional header data | |||
Header header = 1; | |||
|
|||
/// \brief Name of the model we want to modify the wheel slip parameters. |
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.
It would be nice to clarify if it's the scoped name (i.e. parent_model::model
) or not
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 think that I'm not using scoped names in the current implementation (gazebosim/gz-sim#1241), should I be?
If it's common to reuse model names but have different parents for each model, maybe I should be using scoped names.
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.
Yup, it looks like you're treating them as unscoped names.
I think it would be good to support nested models in some way. I can imagine creating a single wheel model that's repeated multiple times inside the same vehicle, for example, and they all may end up with the same name. I can't think of a clean way to do it with just model_name
and link_name
. Maybe if model_name
accepts scoped names, but the implementation will need to be updated. My suggestion would be to remove string model_name
and string link_name
in favor of Entity link_entity
.
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.
My suggestion would be to remove string model_name and string link_name in favor of Entity link_entity.
That sounds good to me.
Is name in that case scoped?
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.
Ha I thought that message was better suited to work with nested models but looking at it now I think it isn't. Just saw this bit of code used to get "top-level" (i.e. children of the world) entities using the message.
Now I can't think of a clean way of using the Entity
message for nested models unless the name
is scoped. So it ends up not being too different from what you have here, except that the user can alternatively pass the ID, or make the type explicit.
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.
except that the user can alternatively pass the ID
Yes, this might be useful in some cases.
or make the type explicit.
I think it's always going to be a link, so that's maybe not needed (?).
In the current approach, you can use the same link name in different models, and distinguish them using the model name.
Would that be possible if I start using msgs::Entity
?
e.g. https://github.com/ignitionrobotics/ign-gazebo/blob/f5bb284884de9c5d4d7fa5614e53b528654b6611/examples/worlds/trisphere_cycle_wheel_slip.sdf#L283 and https://github.com/ignitionrobotics/ign-gazebo/blob/f5bb284884de9c5d4d7fa5614e53b528654b6611/examples/worlds/trisphere_cycle_wheel_slip.sdf#L685.
Ideally, I agree that supporting nested models would be the best.
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 think it's always going to be a link, so that's maybe not needed (?).
I think it's mostly useful if there's a generic way to handle the Entity
message which multiple systems can use. This plugin could handle an error in case the user specifies a joint, for example.
It would be helpful to distinguish between links and other entities, in case there are name overlaps. For example, it's common to have links and joints with the same name (i.e. right_wheel
).
Would that be possible if I start using msgs::Entity?
Only if the name
is scoped, I believe. I think it would be reasonable to use the Entity
message this way. By the way, the entitiesFromScopedName helper function should help.
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.
Only if the name is scoped, I believe. I think it would be reasonable to use the Entity message this way. By the way, the entitiesFromScopedName helper function should help.
Sounds good, I can try that.
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 got that working, see 7c15ad8 and gazebosim/gz-sim@2d98ab9.
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
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.
Thanks for iterating, LGTM!
Merging with a failing ABI checker because the first version of the message hasn't been released yet. |
This pull request has been mentioned on Gazebo Community. There might be relevant details there: https://community.gazebosim.org/t/new-ignition-releases-2022-03-25-fortress-edifice-citadel/1343/1 |
🦟 Bug fix
Fixes #205 (comment).
Summary
Add docs to
wheel_slip_parameters_cmd.proto
.Checklist
codecheck
passed (See contributing)Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining
Signed-off-by
messages.