-
Notifications
You must be signed in to change notification settings - Fork 67
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
Include ellipsoid as a math shape #182
Conversation
Signed-off-by: Stephen Brawner <[email protected]>
Codecov Report
@@ Coverage Diff @@
## ign-math6 #182 +/- ##
==========================================
Coverage 99.19% 99.20%
==========================================
Files 61 63 +2
Lines 5982 6024 +42
==========================================
+ Hits 5934 5976 +42
Misses 48 48
Continue to review full report at Codecov.
|
Signed-off-by: Stephen Brawner <[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.
looks straightforward; I just have a few minor comments
template<typename T> | ||
std::optional< MassMatrix3<T> > Ellipsoid<T>::MassMatrix() const | ||
{ | ||
if (this->radii.X() < 0 || this->radii.Y() < 0 || this->radii.Z() < 0) |
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 we want to use <=
for these comparisons, since the inertial properties are invalid if any radii are 0
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.
Completely reasonable and fixed, but then that begs another question. If 0 and negative values are invalid, should they be checked during construction/SetRadii()
? And an exception thrown in that case?
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.
If 0 and negative values are invalid, should they be checked during construction/
SetRadii()
? And an exception thrown in that case?
Currently the constructors and Get/Set methods act like plain old data structures, and there's only validity checking in the methods dealing with inertia computations. I'm inclined to keep it that way for ign-math6
so that the shape classes have the same exception behavior. I think we could consider that for ignition-math7
, but it would be good to consider the impact it would have on downstream code in libsdformat, ign-gazebo, etc.
Signed-off-by: Stephen Brawner <[email protected]>
Signed-off-by: Stephen Brawner <[email protected]>
Forgot to update a unit test for the stricter check that was added. |
Signed-off-by: Stephen Brawner <[email protected]>
396f673
to
941ea07
Compare
@scpeters Is there anything else you would like to see from this PR? |
include/ignition/math/Ellipsoid.hh
Outdated
namespace math | ||
{ | ||
// Foward declarations | ||
class EllipsoidPrivate; |
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.
Did you mean to create this class? I see the same thing sneaked into the Capsule
class.
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'll take the liberty of removing this so it can rerun the windows job
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.
there is no CapsulePrivate
, so that forward declaration could be removed as well
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 @scpeters. We can blame my gratuitous use of copy/paste.
Signed-off-by: Steve Peters <[email protected]>
Thanks again @scpeters for the review and quick fix. Looks like all checks now pass. |
This follows #163 pretty closely, but I'm happy to make changes where needed for this own class.
I noticed that the API for different shapes has diverged, and it may also be worth revisiting how bad parameters are dealt with across the different shapes.
Signed-off-by: Stephen Brawner [email protected]