Adding cone primitives.

[bperseghetti]

🦟 Bug fix

Summary

This helps add the missing cone geometry for primitive/basic parametric shapes:

And is also valuable for visualizations of emitters/source that typically have conic-based spread as seen in this acoustic attack on an IMU by showing the affected area:

Associated PRs:

• Adding cone primitives. gz-gui#621
• Adding cone primitives. #594
• Adding cone primitives. gz-msgs#442
• Add Cone as a collision shape gz-physics#639
• Adding cone primitives. gz-rendering#1003
• Adding cone primitives. gz-sim#2410
• Adding cone primitives. sdformat#1418

Checklist

• Signed all commits for DCO
• Added tests
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

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.

[bperseghetti]

@scpeters thanks, with your help I finally figured out how to bump math7->math8 to get it past CI 🤦‍♂️... 🫠
One of those days....

[scpeters]

I checked out your code and reviewed a bit of it on a flight yesterday but didn't have a chance to post my comments until now. It looks like you've mainly copied the Cylinder class, which makes sense, but the Volume computation needs to be updated in a few places.

I haven't yet reviewed the moment of inertia calculations.

[bperseghetti]

I checked out your code and reviewed a bit of it on a flight yesterday but didn't have a chance to post my comments until now. It looks like you've mainly copied the Cylinder class, which makes sense, but the Volume computation needs to be updated in a few places.

I haven't yet reviewed the moment of inertia calculations.

@scpeters yeah, I think I did the volume properly everywhere except for some of the tests I had added around 4AM this morning while on "awake kiddo" duty.
According to wolfram here is the inertia we use for cylinder at center of mass: https://resources.wolframcloud.com/FormulaRepository/resources/Moment-of-Inertia-of-a-Cylinder

And according to wolfram here it is for the cone at center of mass that I added to the code:
https://resources.wolframcloud.com/FormulaRepository/resources/Moment-of-Inertia-of-a-Cone

[scpeters]

I checked out your code and reviewed a bit of it on a flight yesterday but didn't have a chance to post my comments until now. It looks like you've mainly copied the Cylinder class, which makes sense, but the Volume computation needs to be updated in a few places.
I haven't yet reviewed the moment of inertia calculations.

@scpeters yeah, I think I had did the volume properly everywhere except for some of the tests I had added around 4AM this morning while on "awake kiddo" duty. According to wolfram here is the inertia we use for cylinder at center of mass: https://resources.wolframcloud.com/FormulaRepository/resources/Moment-of-Inertia-of-a-Cylinder

And according to wolfram here it is for the cone at center of mass that I added to the code: https://resources.wolframcloud.com/FormulaRepository/resources/Moment-of-Inertia-of-a-Cone

Great those inertia values relative to the center of mass look good to me. The tricky thing about cone inertial properties compared to the other simple shapes that we support is that a cone's center of mass is not at the geometric center of the shape. So when we specify model properties and geometry in SDFormat, if a link has a single shape with uniform density, we can set the link pose and then can use the default identity poses for the collision, visual, and inertial tags. With a cone, we need to be explicit about where the shape origin is defined. If we use the geometric center, then a link with uniform density cone could still use the identity pose for collision and visual but would need the inertial pose to be set with the center of mass location.

Most of that is a concern for sdformat, which I will address in review of gazebosim/sdformat#1418, but I think the Cone class could use an additional API to help with this. All the other shapes have a MassMatrix() method to get inertial properties at the center of mass, but I think the Cone could additionally use an API that returns an Inertial object with the center of mass location encoded. I'm not going to block this PR on adding that API, but I think I will ask for it to get added to gz::math::Cone in the course of reviewing gazebosim/sdformat#1418.

[bperseghetti]

I checked out your code and reviewed a bit of it on a flight yesterday but didn't have a chance to post my comments until now. It looks like you've mainly copied the Cylinder class, which makes sense, but the Volume computation needs to be updated in a few places.
I haven't yet reviewed the moment of inertia calculations.

@scpeters yeah, I think I had did the volume properly everywhere except for some of the tests I had added around 4AM this morning while on "awake kiddo" duty. According to wolfram here is the inertia we use for cylinder at center of mass: https://resources.wolframcloud.com/FormulaRepository/resources/Moment-of-Inertia-of-a-Cylinder
And according to wolfram here it is for the cone at center of mass that I added to the code: https://resources.wolframcloud.com/FormulaRepository/resources/Moment-of-Inertia-of-a-Cone

Great those inertia values relative to the center of mass look good to me. The tricky thing about cone inertial properties compared to the other simple shapes that we support is that a cone's center of mass is not at the geometric center of the shape. So when we specify model properties and geometry in SDFormat, if a link has a single shape with uniform density, we can set the link pose and then can use the default identity poses for the collision, visual, and inertial tags. With a cone, we need to be explicit about where the shape origin is defined. If we use the geometric center, then a link with uniform density cone could still use the identity pose for collision and visual but would need the inertial pose to be set with the center of mass location.

Most of that is a concern for sdformat, which I will address in review of gazebosim/sdformat#1418, but I think the Cone class could use an additional API to help with this. All the other shapes have a MassMatrix() method to get inertial properties at the center of mass, but I think the Cone could additionally use an API that returns an Inertial object with the center of mass location encoded. I'm not going to block this PR on adding that API, but I think I will ask for it to get added to gz::math::Cone in the course of reviewing gazebosim/sdformat#1418.

I believe that for how cone is defined the center of mass is length / 4.0
If we measured the cone with length starting at the vertex to the flat large radius end then it would be 3 * lengh / 4.0 but our reference is +Z going to vertex.

[bperseghetti]

@scpeters @azeey @ahcorde Awesome! So I think the next one to go is gz-msgs? gazebosim/gz-msgs#442

And once that is in the nightlies should update for the others to start working in CI?