Add tether to model

[chapulina]

Addresses

• Move buoy model to buoy_description #4
• Add tether cable #14

Requires

• Ignition Fortress rosdep keys for Jammy ros/rosdistro#32838

Summary

Moved the buoy model from the mbari_wec.sdf world file to the buoy model. The model.sdf.em file is an EmPy template that's converted into a model.sdf model at compile time.

The tether is parametrized so we can easily change the number of links in it, its mass, diameter, etc. The template uses Gazebo Math to calculate each link's mass and moment of inertia . As a placeholder, I used 100 kg/m^3 as the rope density.

This is what it currently looks like, with 10 links:

CI

CI is currently failing with

 /github/home/ws/src/buoy_sim/buoy_description/models/buoy/model.sdf.em:22: error: <class 'ModuleNotFoundError'>: No module named 'ignition'

Because the rosdep key for python3-ignition-math6 is not available yet. That just needs this PR to go in: ros/rosdistro#32838

Up next

Make the PTO into a hollow cylinder so that the tether links can slide into it. I'm thinking of using polylines for this so we don't need to create a fixed mesh and instead can parametrize it. This will require addressing these upstream issues, I think I can get a prototype out within a week.

• Support polylines gazebosim/gz-sim#186
• Load polylines into SDF DOM gazebosim/sdformat#296

[hamilton8415]

Very nice. Looks good for the straight tether and I can't wait to see that heave-cone swinging around down there. Regarding the hollowing of the PTO and simulating the "tether guide" portion, I don't know how the polylines features work and perhaps that will address the following issue, but in the collection of rigid links approach it seems like the point at which the tether pulls on the PTO body will change a bit as each link slips through the tether guide (the white plastic bushing at the end of the PTO in the photo below). Some change in this "pull point" isn't too big a problem, but the effect should be minimized. Perhaps it's an option to use more links up in this section if the links slip through reasonably (the piston has a about a 2m stroke, so that's the amount of tether that would need to be more finely discretized to address this issue.

Also challenging, the friction between the tether and the PTO tether guide isn't entirely negligible (although it could be neglected as a first pass). We don't have good measurements of this, and it's a bit complicated in that the tether puts a force on two different rigid bodies, the PTO housing, and the piston. Friction between the tether and the PTO bushing reduces the force on the piston... Free body diagram needed! :). I will check with Dom Forbush to see if he's addressed this complication in his simulink model, which I understand also uses a collection of rigid sausage links for the tether.

Although I am not suggesting we pursue this at this time as I think we will benefit from a simple solution implemented quickly, I did mention this c++ library designed to solve the generic mooring line problem. I have not had a chance to study it, and guarantee the computer run times will be long (they always are with cable dynamics solvers), but it could be interesting.

Finally, the tether is heavy in water, so more dense than 1025kg/m^3, probably by a factor of two at least. I will check with francois for the exact weight/meter and diameter.

[hamilton8415]

Darn, I forgot to include the link to moordyn. https://moordyn.readthedocs.io/en/latest/

[chapulina]

I don't know how the polylines features work

I should have added more context, here it goes. Gazebo and SDF don't support a hollow cylinder as a shape primitive. So our options are:

• Create a rigid mesh on a software like Blender and import it into the simulation as an STL / DAE / OBJ rigid body. Once that mesh is made, we can scale uniformly it as a whole, but we don't have any control over each of its parameters, like the internal diameter.
• Use a polyline geometry, which can be parametrized directly on the SDF.

Polyline is one geometry type supported by the SDF spec. It consists of various <polyline> elements, each with various <point>s and a <height>. When one polyline is enclosed by another, it defines a hole. For example, this defines a hollow square collision shape:

        <collision name="collision">
          <geometry>
            <polyline>
              <point>-0.5 -0.5</point>
              <point>-0.5 0.5</point>
              <point>0.5 0.5</point>
              <point>0 0</point>
              <point>0.5 -0.5</point>
              <height>1</height>
            </polyline>
            <polyline>
              <point>-0.3 -0.3</point>
              <point>-0.3 0.3</point>
              <point>0.3 0.3</point>
              <point>0 0</point>
              <point>0.3 -0.3</point>
              <height>1</height>
            </polyline>
          </geometry>
        </collision>

That's supported on Gazebo classic, but we haven't ported it to Fortress yet. I hope all that's missing is the glue code to load the SDF and generate the mesh. All the triangulation logic is already on Gazebo Common.

in the collection of rigid links approach it seems like the point at which the tether pulls on the PTO body will change a bit as each link slips through the tether guide

The hollow cylinder will be a rigid body, so I expect that point of contact to be handled by the physics engine. We may need to tweak the surface parameters until we get contacts that are stable enough and provide the expected friction.

Perhaps it's an option to use more links up in this section if the links slip through reasonably (the piston has a about a 2m stroke, so that's the amount of tether that would need to be more finely discretized to address this issue.

Great idea, I'll make that change on this PR.

c++ library designed to solve the generic mooring line

Thanks! Added the link to #15

the tether is heavy in water, so more dense than 1025kg/m^3, probably by a factor of two at least.

Thanks! I changed to 2000 kg/m^3 for now: fbda82d

[chapulina]

As of 3efabae, the tether has 2 sections that can be parametrized separately. Each section has 10 links. The current parameters are:

tether_radius = 0.01
tether_density = 2000 # kg/m^3
tether_length = 20.3

num_tether_top_links = 10
tether_top_length = 2.0

num_tether_bottom_links = 10

But the logic could easily be modified if we'd rather parametrize by the length of each link, for example.

[hamilton8415]

What would not be unreasonable here is to artificially increase the bend radius of the tether guide bushing in the model to some value that is large enough compared to the link lengths that a couple of tether links lie across the surface. The bend radius of the actual tether guide is rather small (say 8 inches), which could mean too many links, but it can be increased for the modeling purpose... That's it for me, I'm out now until Monday. Have a great weekend and see you monday afternoon.

[andermi]

Create a rigid mesh on a software like Blender and import it into the simulation as an STL

I'll have visual/collision meshes for our specific buoy in an SDF by the end of the day. If we care about parameterizing the inner diameter of the collision cylinder for the PTO, I have code I wrote an for an stl cylinder generator. Wouldn't be hard to modify.

I think I might want to use a URDF for RVIZ (when viewing the real buoy feedback), but I think we can just have the SDF be the master file and use an sdf->urdf conversion tool?

the friction between the tether and the PTO tether guide isn't entirely negligible

@hamilton8415 Is it possible to move this friction to an equivalent on the piston prismatic joint instead?

[chapulina]

I'll have visual/collision meshes for our specific buoy in an SDF by the end of the day.

Thanks!

If we care about parameterizing the inner diameter of the collision cylinder for the PTO, I have code I wrote an for an stl cylinder generator.

I have a prototype on the chapulina/tether_guide branch using polylines, but that has a flat brushing. I'm going to strain it a bit by pulling the piston while the buoy is in different positions and see how it behaves. I'm also thinking of tweaking the surface properties to see if that can behave reasonably well.

In any case, we may end up needing a round brushing. Or in the worst case, we may not be able to rely on the physics engine to manage the interaction between the tether and the guide and may need to resort to a plugin that applies forces as needed.

I think I might want to use a URDF for RVIZ (when viewing the real buoy feedback), but I think we can just have the SDF be the master file and use an sdf->urdf conversion tool?

Yeah we can try using sdformat_urdf to view the buoy on RViz, ticketed #25

[andermi]

Yeah we can try using sdformat_urdf to view the buoy on RViz, ticketed #25

I noticed a limitation is that it cannot handle ball joints 👎 . So, I'm not sure what the solution is there.

[andermi]

looks good!

Should I merge the stl branch first (before this)?

[chapulina]

I noticed a limitation is that it cannot handle ball joints

Ouch, I hadn't realized that. For the tether, I changed to universal joints on #26, because those seemed to be more stable.

Should I merge the stl branch first (before this)?

Yup, that's merged. I'll fix conflicts here.

[chapulina]

Ok, I rebased this branch and updated the template to use the new meshes and offsets from #27 .

Here's the tether + STL meshes:

Close up on where the tether meets the heave cone:

And where it meets the piston: