-
Notifications
You must be signed in to change notification settings - Fork 2
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 mooring #107
Add mooring #107
Conversation
Signed-off-by: Mabel Zhang <[email protected]>
Signed-off-by: Mabel Zhang <[email protected]>
Signed-off-by: Mabel Zhang <[email protected]>
|
@mabelzhang Here's a wheel file (in a zip since github doesn't like .whl extension) for a mooring catenary calculator in python I whipped up. We can chat about it at the 2pm, or sooner if you'd like. unzip and then pip3 install Then, you can run the gui calculator on the command line: or, import the function: input:
solve:
output:
|
Signed-off-by: Mabel Zhang <[email protected]>
Signed-off-by: Mabel Zhang <[email protected]>
I added the first pass of the catenary solver based on Slack discussions. Not sure if I did it correctly. |
Signed-off-by: Mabel Zhang <[email protected]>
I went back to reread the Python diagram and the code. That made me fix a few things in the C++ solution class that I had misunderstood before. It doesn't give me NaNs anymore, so I probably fixed something. VSolver (in CatenarySoln.hpp. I think the fvec[0] here is supposed to be the x=H that is solved):
This solverInfo looks okay. HSolver (in MooringForce.cpp) just keeps printing the same thing:
This solverInfo is 5, which I think means it didn't find a solution? So maybe I have something else wrong. Performance is very very slow. Other than I might be doing something wrong, maybe b can be incremented faster. |
There's an example of solver parameters to modify in |
Try |
With these lines locally
It didn't seem to make a difference to the results or the speed. I think I must be doing something wrong in the HSolver, for it to always get solverInfo = 5... maybe I need to check my operator() again. Tell me if this sounds wrong. The inner optimization wants y(H)-V, where y is the cosh function, so it sets fvec[0]=y(H)-V at the end. The outer optimization wants y_B(B)=H, so it first calls the inner class with initial guess x0=H, and once the inner optimization is done, it uses whatever x that is found, and just returns that? Or should it be returning y_B(B)-H (I thought that was what I was doing in f6fb01a in this line, but that was giving NaNs. Maybe I wasn't returning what I thought I was returning? |
possibly because the initial guess of
this ^^. it should be finding the B that makes the assumptions are that we can use this calculation when the mooring line is pulled sufficiently taut such that the section of the line on the floor, B, is basically pulled straight with no loops/bights. Also, the catenary equation is only valid when H > B, otherwise the line just makes a straight line starting from B up to the buoy. This all means there's some radius around the anchor where we can start to use this solution. |
does it still work with the old effectiveRadius code? |
Yeah 7e79a40 (right before removing The test breaks starting from the merge from Maybe the test just needs to be loosened, or we can set the forces to be smaller, so that the test stops before it explodes. If I just run the simulation, it doesn't crash. Only the test crashes. Maybe decreasing the force in the test would help. I'd have to play with it more next week. |
Signed-off-by: Mabel Zhang <[email protected]>
1 million is too big in the force in the test. Playing with the numbers to find a small enough number of iterations so that the buoy is pushed to near 160 without wasting too much test time:
10,000 iterations at 155.119:
8000 iterations at 155.103:
5000 iterations at 153.577:
So I think 100,000 force and 8000 iterations is a stable place to leave the test. |
Signed-off-by: Mabel Zhang <[email protected]>
I'm not sure why one test was missing the log, and the other test was timing out. Hard to see what's happening with a lot of printouts from Added SDF parameter to disable plugin by default. Might as well see if the tests pass with the plugin disabled. |
Signed-off-by: Mabel Zhang <[email protected]>
This is weird. I commented out the mooring test, and the CI is still missing logs. I don't see this happening to other PRs. Have we seen this elsewhere? |
No, I haven't seen that, although github has been acting strangely the last couple days... |
I reran the test and I noticed it was running for >5hrs before it was cancelled |
Yeah I saw that. Locally, there's a lot of printouts from |
those printouts are already masked as Debug... did you enable debug printing? |
I tried levels 1-4 in the first line of the mooring test that sets them, but running the test still prints all the debug printouts. I mean, the mooring printouts are debug too, and I want to see those. |
osrf/mbari_wec_utils#51 should fix CI test issue |
Signed-off-by: Mabel Zhang <[email protected]>
Signed-off-by: Mabel Zhang <[email protected]>
aff4053 should fix the test now, and a few bugs I found... The plugin now has an That way this PR can be merged without affecting other things. |
Signed-off-by: Mabel Zhang <[email protected]>
Signed-off-by: Mabel Zhang <[email protected]>
Signed-off-by: Mabel Zhang <[email protected]>
Signed-off-by: Mabel Zhang <[email protected]>
Signed-off-by: Mabel Zhang <[email protected]>
Signed-off-by: Mabel Zhang <[email protected]>
Wow, CI is finally green. |
Recap:
|
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.
LGTM! :)
Addresses #15
Opening for visibility. Test isn't complete yet.
Adds mooring line, chain, and seafloor.
2022-11-12-01-30_chainOnSeafloor_scale_4x.mp4
Test WIP
The test isn't able to push the buoy all the way to the bounds to test the bounds yet. Because the heave cone is so heavy, a very large force has to be applied to move the buoy just a few meters. After some iterations, an out of bounds error happens, seeming to do with collision, and the pose values go haywire.
3000 iterations of 10,000 N (is that the unit?) in x:
Note how the pose jumps from (12, 0, -2.4) to something huge. That's not the actual test failing (looks for < 60 m from anchor), that's values going out of bounds.
There are a few things I can try:
ServerConfig
that we can pass to the server.My main uncertainty is that, since I'm not seeing the GUI, even before it goes out of bounds, I don't know if the buoy is moving to the force correctly.