Improve tether physics and add playground world

[chapulina]

Addresses

• Add tether cable #14

Builds on top of

• Add tether to model #22
• Update inertias #35
• Move joint to world out of model #36

No longer needed

• (Citadel) Polyline geometry DOM gazebosim/sdformat#1000
• (Fortress) [sdf12] Polyline geometry DOM gazebosim/sdformat#1003
• (Citadel, needs forward-port after merged) Extruded 2D polyline geometries gazebosim/gz-sim#1456

---

Summary

This is outdated, see comments below

Change the PTO link from a solid cylinder to a hollow cylinder using extruded polylines. This results in a sharp 90 degree corner at the end of the tether guide, as opposed to the round end that we see on the actual hardware.

I added the buoy_playground.sdf world that has joint controllers to be able to shake the model a bit and see how it behaves with movement. It took some tweaking here and there to prevent the simulation from crashing or collapsing 🙃 The current numbers are just the first combination that worked for me but I'm sure that we can optimize these a bit more (and probably other properties too):

• What collision detector to use (ode, bullet, fcl or dart)
• What solver to use (dantzig or pgs)
• The dynamics and kinematics of the tether joints, links and guide
• The surface properties of the tether guide and links

Another optimization that I tried a bit was to use collide_bitmasks on the collisions we expect to collide instead of enabling self_collide for the entire model. I have to play a bit more with this, I may need to enable self_collide and explicitly disable collisions for the parts that shouldn't collide.

Try it out

ign gazebo buoy_playground.sdf

TODO

• Try collide_bitmask again
• Move the joint to the world to each world file instead of the model file, so mbari_wec can keep the prismatic joint and the playground uses the revolute joint - Move joint to world out of model #36
• Tweak parameters mentioned above

[hamilton8415]

Looks like you're making progress on this. You're trick of driving the ram out quickly is relevant, in the real situation the tether is likely to go slack and you can start to see that's happening. To accentuate this in your testing, you could increase the drag on the heave-cone, if we have drag there, or just drive the ram out very quickly as you are. This is actually where the large added mass of the heave-cone become relevant. Without that contribution, adding inertia also adds weight, which keeps the tether tight. With the added mass inclusion, there's an enormous amount of additional inertia, without any added weight, promoting the slack tether condition...

It'll be interesting to hear the computational load this introduces.

[andermi]

This is awesome!

Are you going to use the stl collision mesh in place of the polyline guide?

[chapulina]

Are you going to use the stl collision mesh in place of the polyline guide?

Yes, I think that should be better because of the smooth curve and because it matches the hardware.

I'm rebasing this branch soon.

[chapulina]

@andermi , this branch is now using the STL meshes. It's a bit tighter than the polylines I had before, so the cable gets stuck more often. We may need to tweak the number of sausage links. On the bright side, the physics seemed stable with the current parameters.

I still need to clean up this branch a bit, that's why it's still in draft.

[hamilton8415]

Sure looks good. The fact the cable appears to get a little kinky when it goes slack isn't a big deal from the simulation accuracy point of view, once it's that slack it doesn't have much impact on the bodies. Of course, when it re-tensions it's position matters, but not for long as it pulls straight pretty quickly (and violently as we've seen in underwater videos...). Presumably the rendering could add some smoothing there, but that sounds to me like a lot of work so I'm not bothered with the kinks.

[andermi]

this branch is now using the STL meshes

It looks like I forgot to fill the holes in the visual mesh like I did with collision. Can I update the mesh and push to #26 ?

[chapulina]

Can I update the mesh and push to #26 ?

Yeah go for it, thanks!

[andermi]

the cable appears to get a little kinky when it goes slack

I was playing around with this PR a bit (I can't help myself; it's really fun! :-D ). It looks like when trying to retract the piston (which should apply tension), it also gets kinked below the guide as it's trying to pull the tether up through. I'm not sure why this would be. Also, once it gets kinked, it doesn't seem to go slack again (friction/damping too high? Could use a bit of spring as well). It also seems to break out of collision bounds which might be solved by decreasing physics step. I started messing around with a few knobs, and it all seems to do a bit better when I add more top tether links, add a spring stiffness to the links, and decrease the physics step size. Obviously, this makes the sim run slower... I suppose it comes down to tuning/tradeoffs :)

Looks good so far! This is really cool!

[chapulina]

Thanks for testing it, @andermi ! I'm going to spend some time playing with the parameters now and see if I can make things behave a bit better. I don't have a good intuition for the behaviour of this specific tether as you folks may have though. I'll try to make it at least behave a bit more like "a cable", and then I can use some help with the fine tuning.

[andermi]

Thinking about it more, while I don't see why the tether would kink when being pulled by the JointPositionController, I see why @hamilton8415 is saying he's not worried about it. In the retract mode, the cable could kink like that because the buoy may be falling (and hence passively driving the piston up) causing slack. The issue of the cable kinking when commanding the piston with the JPC may just be irrelevant from conop.

[chapulina]

re: collision with PTO

I figured out that the problem was with the self_collide option in a nested model. We may not need to change the STL, @andermi , sorry for the noise.

[andermi]

@chapulina I reduced polygons, updated normals, and fixed some non-manifolds for the pto tether guide

[chapulina]

That's great, thanks @andermi ! I've been iterating on this slowly. It looks to me that we may need to make the top-tether thicker to prevent it from penetrating into the PTO wall, the thinner it is, the smaller we need the time steps to be.

[andermi]

I can also increase the diameter of the guide per @hamilton8415 to accommodate a thicker tether

[chapulina]

I can also increase the diameter of the guide per @hamilton8415 to accommodate a thicker tether

Thanks! For now, I updated the script to scale the PTO collision to accommodate the tether in 4cebfc3. This should be quicker to iterate, and then we can update the mesh itself as needed.

[chapulina]

Status update as of 8e1278a

It'll be interesting to hear the computational load this introduces.

The playground world is currently set to run as fast as possible, and the simulation runs on my computer at ~220% real time, which is not great.

once it gets kinked, it doesn't seem to go slack again (friction/damping too high? Could use a bit of spring as well)

I think it's a bit better with the current combination of friction, damping and springiness. Let me know what you think.

break out of collision bounds

These seemed to help:

• Low res STL with outward facing normals
• Thicker tether and PTO
• Keeping 1ms time steps

I'm still able to break through the collision in some extreme conditions. It would help to have a sense of:

• how fast the piston can move
• how far does the tether usually get bent at the end of the PTO - is it within the 20 degree range, or does it get closer to 45... or even to 90 with some currents?

[andermi]

Let me know what you think.

This is my favorite GIF 😆 I love this! very cool! I'll try it out today.

[andermi]

This is super cool! I would like to see what happens if you remove the joint controller on the piston (let the spring/pto plugins run free) and figure out how to excite the buoy link in some way with a momentary force up or down.

[chapulina]

I would like to see what happens if you remove the joint controller on the piston (let the spring/pto plugins run free)

The mbari_wec world loads the buoy without the position controller, and with the spring / PTO plugins.

The buoy_playground world loads the buoy without the spring / PTO plugins, but with the joint controller.

figure out how to excite the buoy link in some way with a momentary force up or down.

This could be a great opportunity to work on this feature:

• Mouse interaction with simulated models gazebosim/gz-sim#306

Another thing I do is slightly change the buoy's position either from the component inspector or using the translate rotate tool.