What is considered low speed here?

[rdesc]

Hi, thank you for all the great open-source resources!

I had a question regarding your code for the supply vessel. I would like to implement some simple path following and was hoping to use your supply vessel model so that I can use DP. I am also looking at your python toolbox here. Can you comment on the changes that would be necessary in order for this to work? My scenario of interest is a supply vessel moving at 4-6 m/s (see attached video) through an ice field where the ship needs to follow a path through the ice field as closely as possible.

In your code here it says 'low speeds'. What is considered a low speed? https://github.com/cybergalactic/MSS/blob/2f46412d960d2d339640e3572b9f4ef844cab0ea/VESSELS/supply.m#L6-L7

https://github.com/cybergalactic/MSS/assets/39059473/7cb020db-a627-44c0-8ee6-09e0ebb89716

Thank you! Rodrigue

[cybergalactic]

Low speed for DP vessels is typically less than 2 m/s (4 knots). The supply.m model is a linearized state-space model intended for stationkeeping and speeds below 2 m/s. It is a very basic model. If you want to simulate the nonlinear equations of motion (stationkeeping and maneuvering), you can use the new offshore supply vessel (OSV) model osv.m. I uploaded the model today, including a script called SIMosv.m for time-series simulation and plotting. This model is based on my Wiley2021 textbook, where the nonlinear equations of motion are derived. The model is controlled using the MIMO nonlinear PID controller from my textbook. In addition, the two azimuths and two tunnel thrusters are operated using a nonlinear constrained dynamic optimization algorithm (SQP) for control allocation. This requires the Matlab optimization toolbox. You can also run the model with fixed azimuth angles by setting a flag in SIMosv.m. This solution is the unconstrained control allocation algorithm (pseudoinverse). In the unconstrained case, you do not need the optimization toolbox.

Concerning the path-following problem, I recommend you study the ALOS guidance law as described in my recent publications and lecture notes available at

https://www.dropbox.com/scl/fi/n9j5tmdnq0c1pky4cf6wy/Lecture-notes-on-Adaptive-Line-of-Sight-Guidance-Laws-for-3-D-Path-Following-of-Underwater-Vehicles.pdf?rlkey=2lmp12jsggdhwt58vfcr77kdr&dl=0

You can also find the implementation of the ALOS algorithm for the Otter USV and Remus100 AUV in the MSS toolbox. Both Simulink and m-files are available, see mssHelp for example files and vessel models.

[rdesc]

Thanks for the quick response! Okay in that case I will see if I can get the supply.py (I'm using python) to follow a path at 2 m/s. I don't really need a complex / high-fidelity model at this point and will likely ignore the environment disturbances (e.g. ocean currents) for now.

I will however take a look at the mentioned osv.m and SIMosv.m scripts. Are there versions for these in python? I will also take a look at ALOS.

[cybergalactic]

There is no Python version of osv.m for the moment. The supply.m/supply.py model is a linear model, where the three control inputs are surge/sway forces and yaw moment. The osv.m file is much more advanced. It is a nonlinear model that includes models for two azimuth thrusters and two tunnel thrusters with two azimuth angles and four propeller RPMs as control inputs (a total of six control inputs). This of course requires that you design a control allocation algorithm (fixed angles or dynamic optimization) as outlined in SIMosv.m. I will migrate this to Python later this year, but you can do this yourself by using chatGPT or other AI tools.

[rdesc]

Ok noted. If I stick to the simpler fixed angle for the osv.m, would I still be able to do path following? In the code it says two constant azimuth angles: alpha0 = deg2rad([-28 28]) so is this the sort of picture then?

Also, can you confirm how to interpret this from supply.py. These are coordinates for the 4 thrusters correct? But unsure since there seems to be 3 coordinates for each thruster..

        T = np.array(
            [[0, 0, 1, 1], [1, 1, 0, 0], [30, 22, -self.L / 2, self.L / 2]], float
        )

Thanks!

[cybergalactic]

The OSV thruster configuration in your drawing is correct.

For supply.py, four thrusters produce three controls (surge force, sway force, and yaw moment). The thruster configuration matrix is defined by

T = [ 0 0 1 1 1 1 0 0 30 22 -L/2 L/2 ]

Here, you recognize two tunnel thrusters with x-coordinates (moment arms) 30 and 22 and two main propellers located in the stern with y-coordinates +- L/2. However, the y-coordinates (moment arms) should be close to +-B/2, not +-L/2. This is a bug. Unfortunately, changing the moment arms from L/2 to B/2 will reduce controllability significantly. In my paper

Fossen, T. I., S. I. Sagatun and A. J. Sørensen (1996). Identification of Dynamically Positioned Ships. Control Engineering Practice 4(3), 369-376. https://www.fossen.biz/publications/1996%20Fossen%20et%20al%20CEP.pdf

there are 6 thrusters instead of 4. The quick fix is to add two more tunnel thrusters to improve controllability. The new thruster configuration matrix becomes

T = [ 0 0 0 0 1 1 1 1 1 1 0 0 30 22 -22 -30 -8 8 ]

Of course, you can add as many thrusters as you like or change their locations.

The file supply.py has been updated according to this on GitHub.

[cybergalactic]

You should download new versions of supply.py and control.py. The setpoint was not low-pass filtered in the DP control law (called 'DPpolePlacement'), which caused steps in the control signals. The new version fixes this, and the saturation problem is also removed.

[rdesc]

I will take a look, thank you!

[rdesc]

Hi, so I think I have a better idea on the details of the LOS and the extension ALOS for path following.

I guess my one remaining question is this, all of the examples with LOS/ALOS assume the output will be a desired course/heading angle (psi_d or chi_d) which will then be used as input to an autopilot (e.g. course or heading autopilot). In the case for the osv and supply code they have the MIMO nonlinear PID controller which, in addition to the setpoint in yaw, has setpoints in surge and sway.

So, how should these 2 additional setpoints be determined in the case for path following? Should it just be based on the position a lookahead distance away from the vessel on the path?

[cybergalactic]

• A DP system is a trajectory-tracking control system using ( x_d(t), y_d(t), psi_d(t)) as TIME-VARYING references. You observe this when you run 'SIMosv.m' and the DP control system.

• You must distinguish between trajectory-tracking and path-following control. The latter is just a geometric path without time information. You can move along the path with a time-varying speed (speed controller), but following the path is achieved using a heading/course autopilot (no time information and no x_d(t), y_d(t), psi_d(t) requirements). You represent the path by waypoints and lines/splines through the 2-D waypoints. You can see how this works if you download the new version of 'SIMotter.m' (and associated m-file updates on GitHub). I finished coding ALOS with straight lines and Hermite splines in 2-D today. You can change a flag in 'SIMotter.m' to test the different implementations.

[rdesc]

Ahh right ok, I see my confusion now! I will take a look at the new code.

[rdesc]

Hi Prof. Fossen, so I think I'm getting close to my envisioned setup. I have setpoint regulation code which moves the setpoints (x_d, y_d, psi_d) along a target path at 2 m/s which is the trajectory I want the ship to track. I am using your updated supply.py code and it seems like tracking is working ok, however, the controller doesn't seem to apply much yaw rate and instead seems to rely more on sway. Could you point to me where I can tune this slightly to improve tracking? A gain in the gain matrix maybe or saturation limits?

See also attached video (note ice physics have been turned off for debugging).

https://github.com/cybergalactic/MSS/assets/39059473/b5530565-1cd7-4e99-882d-843cc94c0829

[rdesc]

Maybe these plots will add more context. So I'm defintiely hitting saturation especially on that turn towards the end of the video

[rdesc]

I figured it out!!! It was a dumb rad vs. degree mixup in my code.... tracking seems to work ok now! Maybe as a final comment, any way I can tune to improve tracking?

https://github.com/cybergalactic/MSS/assets/39059473/93eec4e6-02f0-483d-9dde-d08d6bf91548