Development of software for dynamic positioning control systems

(1)

Publisher’s version / Version de l'éditeur: Student Report, 2010-12-01

READ THESE TERMS AND CONDITIONS CAREFULLY BEFORE USING THIS WEBSITE. https://nrc-publications.canada.ca/eng/copyright

Vous avez des questions? Nous pouvons vous aider. Pour communiquer directement avec un auteur, consultez la première page de la revue dans laquelle son article a été publié afin de trouver ses coordonnées. Si vous n’arrivez pas à les repérer, communiquez avec nous à PublicationsArchive-ArchivesPublications@nrc-cnrc.gc.ca.

Questions? Contact the NRC Publications Archive team at

PublicationsArchive-ArchivesPublications@nrc-cnrc.gc.ca. If you wish to email the authors directly, please see the first page of the publication for their contact information.

Archives des publications du CNRC

For the publisher’s version, please access the DOI link below./ Pour consulter la version de l’éditeur, utilisez le lien DOI ci-dessous.

https://doi.org/10.4224/17210707

Access and use of this website and the material on it are subject to the Terms and Conditions set forth at

Development of software for dynamic positioning control systems

Gash, Robert

https://publications-cnrc.canada.ca/fra/droits

L’accès à ce site Web et l’utilisation de son contenu sont assujettis aux conditions présentées dans le site LISEZ CES CONDITIONS ATTENTIVEMENT AVANT D’UTILISER CE SITE WEB.

NRC Publications Record / Notice d'Archives des publications de CNRC: https://nrc-publications.canada.ca/eng/view/object/?id=31ebc598-eaf1-49ed-99f8-2d8ebf04c9ea https://publications-cnrc.canada.ca/fra/voir/objet/?id=31ebc598-eaf1-49ed-99f8-2d8ebf04c9ea

(2)

REPORT NUMBER NRC REPORT NUMBER DATE

SR-2010-21 December, 2010

REPORT SECURITY CLASSIFICATION DISTRIBUTION

UNCLASSIFIED UNLIMITED

TITLE

Development of Software for Dynamic Positioning Control Systems AUTHOR(S)

Robert Gash

CORPORATE AUTHOR(S)/PERFORMING AGENCY(S)

Institute for Ocean Technology (IOT)

PUBLICATION

N/A

SPONSORING AGENCY(S)

IOT PROJECT NUMBER NRC FILE NUMBER

KEY WORDS PAGES FIGS. TABLES

Dynamic Positioning, Control System, Software De-velopment, Visual Basic, C++, C#, Aerotech, Motion Controllers, Kinect, Arctic, D.P.I., Computer Vision

31 12 0

SUMMARY

The National Research Council of Canada’s Institute for Ocean Technology is cur-rently expanding its Dynamic Positioning (D.P.) capabilities. Due to recent interest in oil and gas exploration in the Arctic, IOT looks to extend its D.P. capabilities to include the ability to perform D.P. in Ice. Older software used in past applications required upgrading in preparation of an upcoming D.P. in Ice demonstration. Effort was under-taken to upgrade this software for a new environment, as well as to improve its future development. With software development now well underway and various key com-ponents of the software environment now developed, the main D.P. control software has been passed to IOT’s Software Engineering group for completion.

ADDRESS National Research Council Institute for Ocean Technology Arctic Avenue, P.O.Box 12093 St. John’s, NL A1B 3T5

(3)

Ocean Technology technologies oc ´eaniques

Development of Software for Dynamic

Positioning Control Systems

SR-2010-21

Robert Gash

(4)

List of Figures

1 Block diagram of a DP control system. . . 4

2 Model test of an FPSO and tanker using D.P. . . 6

3 A Master doControl function and its supporting subroutines. 8 4 D.P. GUI showing the six required elements. . . 9

5 Communications layout for D.P.I. Model . . . 12

6 Creating an API for MATLAB Functions . . . 15

7 Various Thruster Software Properties . . . 18

8 Common Thruster Class Inheritance . . . 20

9 RGB/Depth Camera shots from Kinect Using OpenCV . . . 23

10 “Level” Model Ice in IOT’s Ice Tank . . . 24

11 Using a Joystick To Provide Demand Offsets . . . 25

(7)

1 INTRODUCTION

Dynamic Positioning (D.P.) refers to the use of electronic and computerized controls which allow for a vessel to perform station-keeping operations. The National Research Council of Canada’s Institute for Ocean Technol-ogy (IOT) has performed many D.P. tests in the past, and is currently look-ing to extend their D.P. system capabilities given heightened interest in oil and gas exploration in the Arctic.

1.1 Previous IOT Dynamic Positioning Software

The dynamic positioning control systems used by IOT on model-scale ves-sels are implemented using computer software written for Microsoft Win-dows. The software that has been used (previous to this report) in the facility was originally designed to run on Windows NT 4.0 and was written in Microsoft Visual Basic 6.0 by Dr. James Millan.

The most recent version of this software, internally named ‘DP3’, con-sisted of two major components. The ﬁrst component, the ‘client’, was a software program which ran onshore during a model test. The client re-ceived feedback from sensors regarding the current location of the vessel, as well as feedback about the vessel’s environment. The control system loop was executed in the software which calculated the appropriate thrust demand for each thruster. This thrust information was then sent, via a

(8)

TCP/IP Ethernet socket network connection in the form ASCII text, to the ‘server’ component. The server component was the second component of the DP software and executed on a PC located within the model vessel. The server was responsible for receiving the ASCII commands. It cali-brated analog signal boards which commanded Aerotech U500 multi-axis motion controllers. The server software processed the commands sent from the client software and determined the appropriate signals to be sent to the motion controllers.

This software used commercial ActiveX Common Object Controls as part of its core functionality (most of which are now either unsupported, unli-censed, or will not execute on modern PCs). The software was designed to interface with motion controllers and hardware no longer supported by Aerotech or IOT. This software was designed for an individual vessel (no longer being tested), and contains many hard-coded calibrations and thruster arrangements.

1.2 Upgrading Existing Software

Given the inﬂexibility of the previous software, as well as new interest in expanding current D.P. capabilities within IOT, this software needs to be updated to support new hardware and different models. A new model is being developed at IOT to test these new capabilities. Model tests are

(9)

scheduled for late January and mid February of 2011, and the software must be functional by this time.

2 DYNAMIC POSITIONING CONTROL SYSTEMS

2.1 Overview

As stated in the introduction, Dynamic Positioning (D.P.) refers to the use of electronic and computerized controls which allow for a vessel to perform station-keeping operations. These systems monitor information about a vessel’s current position and heading relative to a deﬁned reference point. They also monitor environmental loads on a vessel including, but not lim-ited to, wind, current, and hydrodynamic forces. Using this information, dynamic positioning systems are able to allocate the thrust required for a vessel to keep location in its environment.

D.P. is used to position vessels whenever mooring1 is either impossible or impractical to implement. This is often the case in offshore oil explo-ration, for example. Mooring can be difﬁcult in these environments as the vessel may be required to keep location in deep water, or in areas where production equipment (e.g. pipelining) is lying on the seaﬂoor. As such, D.P. is often used in many areas of the ocean industry.

(10)

Figure 1: Block diagram of a DP control system.

As each vessel differs in hull-shape, size, and thrust capability, there is great interest in performing D.P. functions at model-scale. This allows re-searchers, designers, and clients to demonstrate and test various D.P. per-formance aspects.

2.2 D.P. Control System Loop

Figure 1 shows a block diagram of a D.P. control system. A “setpoint”, or point of reference, refers to a physical position of a vessel in (x,y) coordi-nates as well as heading angle. This coordinate frame is usually deﬁned with reference to a vessel’s physical location with respect to another phys-ical location on earth (Millan, 2008). This setpoint location is compared to

(11)

that of an estimate of the vessel’s current location (state). The difference in these two locations (the error) is then fed into a coordinate transforma-tion. This transforms the error into body coordinates, a reference frame in respect to the vessels center of movement. Appropriate gains are then applied to this error to determine the appropriate demands required to overcome it. These demands (usually a force in the surge, a force in the sway, and moment about the yaw axes) are then combined with a “feed-forward” demand. This feedforward demand results from the need to over-come the environmental conditions to which the vessel is subjected. This can include, but is not limited to, demands from wind conditions, current conditions, and other hydrodynamic forces. The gain and feedforward de-mands are then summed, producing a total demand vector. As stated by Dr. James Millan in Thrust Allocation Techniques for Dynamically

Posi-tioned Vessels:

The controller demand vector is deﬁned as follows:

τ_c ₌

F_x F_y M_z T

(1)

where Fxand Fy are respectively, the controller demand forces in the surge

and sway body axes and Mz is the demand moment in the yaw axis.

(12)

Figure 2: Model test of an FPSO and tanker using D.P.

the demand vector is allocated in parts to each of vessel’s physical thrusters (in the most efﬁcient manner possible). This total demand is then fed into a state estimator2_{along with feedback from various sensors. This produces}

a good estimate for the vessel’s current state, and is then fed back into the control loop.

2.3 D.P. Control Systems in Model Scale

When testing D.P. in model-scale, the environment tends to be very con-trolled. When using the model-testing tank facilities at IOT, for example, use of position feedback systems (such as Qualisys) and known environ-mental conditions allow for ease of D.P. control implementation. Figure 2 shows a model test of a Floating Production Storage and Ofﬂoading

(13)

(FPSO) operation in IOT’s Offshore Engineering Basin (OEB). The FPSO ship (front) is turret moored3 _{and is using D.P. assist for keeping heading.}

The tanker (back) is in full D.P. mode.

Models designed and fabricated within IOT are usually fitted with model thrusters. These thrusters, much like in full-scale operations, typically consist of either fixed propulsion (a fixed propeller usually positioned on the bow, stern, or both), or “Azipods” (podded 360-degree azimuthing thrusters). These thrusters are controlled by single-axis motion controller hardware. Rudder propulsion may be modeled as well, but usually aren’t due to complicated drive designs as well as additional rudder lift/drag con-siderations.

3 SOFTWARE IMPLEMENTATION OF D.P.

CON-TROL

As seen in Figure 3, the software implementation of a D.P. control system follows directly from the original control diagram (see Figure 1). Typically, the software is designed in such a way as to present an end-user with a Graphical User Interface (GUI) in which they can control all aspects of a test. One such aspect, the core of the control system, is the ability to

(14)

Figure 3: A Master doControl function and its supporting subroutines.

start and stop the control loop. This is usually carried out by calling one major function in software. For purposes of this section, this function will be referred to as doControl(). The doControl() function contains many supporting subfunctions which are called in the process of executing this loop. Each function (shown in Figure 3) executes its stage of the control loop and feeds its results onto the next function. doControl() is typically implemented as either a control timer in some high-level languages, or a while-loop in a separately executed thread in memory. The GUI presented to the user must contain several elements including:

1. Communication channel conﬁgurations 2. Thruster / drive calibrations

3. Reference point input 4. Control System Start/Stop

(15)

Figure 4: D.P. GUI showing the six required elements.

5. Emergency safety control 6. Feedback displays

The ﬁrst element refers to the user’s ability to manually conﬁgure the chan-nel of communication to either the motion controllers or another PC which controls the motion controllers. The communication channel, for exam-ple, could be TCP/IP and require settings such as IP address and port. It could also be a serial connection requiring parameters for baud-rate, par-ity, and command-length. The second element refers to the user’s ability

(16)

to change calibrations on the thrusters or other parameters for analog-to-digital or digital-to-analog conversions. The third element is required for the user to input (in a relative earth-coordinate system) the required position and heading for the desired station-keeping. The fourth element is required to allow for the start and stop of the control loop (mentioned above). The ﬁfth element, one of the most important, refers to the ability for the user to automatically and safely abort the motion of the system in case of control loss or unpredictable incidents such as loss of communi-cation or human endangerment. The last element refers to the ability to monitor feedback about the control to allow a user to observe the perfor-mance of the system. This can be seen in the example GUI given in Figure 4.

As shown in Figure 3, after a thruster allocation is calculated, the the al-location must be converted (via a calibration) into a command to be sent to the motion controller. In terms of general-purpose D.P. software (to be discussed in the next section), this is one of the biggest obstacles to over-come. Given the vast array of available motion controllers (and ways of communicating with them), it is very difﬁcult to generalize this function.

(17)

3.1 Design for Upcoming IOT D.P. Tests

Design began in September 2010 on a D.P. software implementation in-tended for use on a model ship for Oceanic Consulting Corporation (OCC). The model was to use one fixed bow thruster as well as two rudder/thruster combinations totalling five axes of motion control. Software was written for five Aerotech Soloists (single-axis motion controllers) to provide this con-trol. The software received commands in the form of ASCII strings sent from the D.P. Control software, and performed the command on the con-troller. It was determined in October, however, that performing D.P. on the model would be impractical due to time constraints. In November 2010, it was determined that a new project (to be carried out by the IOT Facilities Group) specifically for Dynamic Positioning in Ice (D.P.I.) would require this software. The model being designed for this project contains six Azipods (and thus requires 12-axis motion control). The software that was originally being designed for the OCC project is now being redesigned for IOT’s D.P.I. project as both hardware configurations are very similar.

The physical shape of the D.P.I. Model is a so-called “Classic Ship-Shape”. That is, the overall shape of the boat is mostly rectangular in fashion with the bow slightly pointed outward above the hull. The six Azipods are lo-cated such that there are three in front and three in back. Each Ensemble motion controller controls a single axis (either a propeller’s rotation or an

(18)

Figure 5: Communications layout for D.P.I. Model

azimuthing drive’s angle).

3.2 Communication Channel for D.P.I Model

As shown in Figure 5, the proposed method for communicating from the main D.P. Control System to the motion controllers is as follows:

1. An onshore PC performs the control loop and generates ASCII string commands to be sent to the motion controllers.

2. A wireless bridge is used to pass the string over TCP/IP to a LAN onboard the ship.

(19)

3. A Pico-PC runs a TCP server which accepts the commands and sends them to the Aerotech Ensembles, while also monitoring con-nection.

4. The Aerotech Ensembles receive their individual motion commands and process them accordingly.

It is important to note that the Pico-PC (a very small-form factor PC) is required to act as a “server server”. Each Ensemble runs its own TCP server within scripts and so, in theory, they could communicate directly to the onshore PC. In practise, however, the wireless channel often incurs in-terference from the testing tank environment. It is possible that connection to the Ensembles could be lost. Given that it is often difﬁcult for Ensembles to re-establish connection once this occurs, a more reliable communication channel to the Ensembles should be used. Thus, a Pico-PC with a wired connection to the Ensembles should act as a buffer to receive commands from the onshore PC and send them along to the Ensembles. Should the wireless link be lost, the Pico-PC could send an immediate “Abort Motion” command to the Ensembles to safely shut down the motion.

With assistance from IOT Electronics Technical Ofﬁcer James Williams, a TCP/IP server script was designed and written to run on Aerotech Soloists. This script is capable of receiving formatted string commands from a client and executing them on the desired axis. This script is included as Ap-pendix A. Given a very similar command structure, little effort will be re-quired to move this script to the Aerotech Ensembles.

(20)

3.3 Mathematical Processing for Control System

As mentioned in Section 1.1 within the introduction of this report, the pre-vious D.P. software developed by Dr. James Millan relied on deprecated Active X controls. More speciﬁcally, much of the mathematics performed in the control loop (e.g. coordinate transforms, thruster allocation, Kalman ﬁltering, etc.) were performed by MATCOM, a compiler used to compile MATLAB functions into VB 6.0 ActiveX controls. This was particularly use-ful in the past as much of Millan’s control code was written in MATLAB. Since this product is no longer supported or licensed, the Matlab C Com-piler (MCC) must be used to bring MATLAB-designed functions into current programming environments.

This is non-trivial, however. The MCC produces libraries along with gen-erated C code (a library wrapper) to interface with them (Refer to Figure 6). The libraries do not use a “friendly” .DLL calling protocol4_{, and thus the}

wrapper is required to expose the compiled functions.

As the wrapper must be used to call the functions of the shared library, only software written in C (or C superset languages) can utilize it. In order to use them in other languages (such as Visual Basic), the most convenient way is through the use of a so-called “driver5_{”. The driver, written in C++,}

4_{There exists no “standard” library calling protocol in Windows. As such, there are}

multiple known (and unknown) calling methods.

(21)

(22)

includes the header of the MATLAB function wrapper code. It contains ac-cessor functions which directly call the wrapper functions. These acac-cessor functions then use the Windows “ stdcall” calling convention (which is not a standard but is utilized by most Microsoft development environments) to expose themselves. These exposed functions are included in an

“ex-ports.def ” ﬁle which will be linked at compile-time. When compiled as a Win32 shared library, the exposed functions will be callable from any

lan-guage that allows the inclusion of shared libraries. An example wrapper and driver conﬁguration can be found as Appendix B in this report.

3.4 Main D.P. Control Program and GUI

The main program for this D.P. control system has been updated in its orig-inal language (Microsoft Visual Basic 6.0). Although there is a movement away from this language, the choice has been made to continue its use in the upcoming model test. Work has already been done to move the exist-ing GUI into Microsoft Visual C#, but will not be utilized in this test due to time constraints. The GUI in its current state can be seen in Figure 4.

This software directly implements the control loop as shown in Figure 3. The software is currently being converted into a 12-axis motion control system for the upcoming D.P.I. project in February 2011. Due to the time constraint imposed by this term, the software currently being developed

(23)

has been passed to IOT’s Software Engineering Group (As of December 2010) for completion.

4 MAINTAINING D.P. SOFTWARE

One of the biggest issues surrounding the design of software for Dynamic Positioning control systems is the inherent issue of non-generality. In each new D.P. application, software must be re-coded to match the new applica-tion. This is due in part to hard-coded thruster types, calibrations, and ar-rangements. In the developing of D.P. software over the past four months, some design strategies have been developed in an attempt to assist in generalization.

4.1 Generalizing Software for Propulsion Units

As mentioned above, each D.P. application will usually involve the coding of a new set of properties for a vessel. One method for generalizing the software, as proposed by Dr. James Millan, would be to make it possible to dynamically add or change a thruster configuration at run-time. A major challenge in implementing this concept is the fact that there are an infi-nite number of thruster configurations possible for any vessel. This can, however, be simplified by viewing a thruster in a general manner from the perspective of the controller(s) that will drive each individual thruster. As

(24)

Figure 7: Various Thruster Software Properties

seen in Figure 7, the assumption can be made that a thruster can be sim-plified into one of three types6: a rudder, an azimuthing propeller, or a fixed propeller. Properties of interest from a software control viewpoint are shown. Since an azimuthing propeller is similar to a fixed propeller (with an additional drive to change the azimuth angle), many properties can be shared between them. Since rudder propulsion is accomplished similar

(25)

to a ﬁxed propeller (with an additional drive to change the rudder angle and additional calibrations for drag and lift properties), many properties can be shared between these as well. This greatly simpliﬁes how we can represent any thruster type within software.

4.2 Design of a Common Thruster Object

The ultimate goal of generalized D.P. would be the ability to dynamically create a thruster conﬁguration for any vessel at run-time. As mentioned above, if it is assumed that any thruster can be modeled as one of three possible types, many properties can be shared between them. Since a hierarchy of properties can be seen between the three possible types, and given the need to instantiate these thrusters at run-time, a base/child class structure with inheritance would be an ideal way of representing these thrusters within software7_{. The creation of these classes would allow their}

objects to be created at run-time and carry all of the information which was previously hard-coded. A proposed way of organizing these classes is shown in Figure 8. Starting with the FixedPropulsion class, the class contains all of the properties and methods necessary to interface a ﬁxed thruster to software. This includes information about the communication protocol used to communicate with the motion controller (the channel), its position (x,y) in body-coordinates relative to the vessel’s center of

move-7_{Based on a C++ class inheritance structure. See Data Structures and Algorithms in}

(26)

Figure 8: Common Thruster Class Inheritance

ment (as well as it’s angle), the min and max moving shaft speeds that drive the spinning propeller, and the corresponding shaft-speed-to-thrust calibrations. Since, as stated earlier, an azimuthing thruster shares many of the properties of a ﬁxed thruster, the AzimuthPropulsion class inher-its all of the properties and methods of the FixedPropulsion class, plus adds the additional properties for the additional communication channel, the min and max angles of the azimuth, the min and max shaft speeds of the azimuth drive, and the corresponding calibrations for each. Similarly, the RudderPropulsion class inherits all of the properties and methods of the AzimuthPropulsion class plus the additional calibration properties of the rudder (the lift and drag).

4.3 Implementing a Common Thruster Object

Given that the class structure above needs to be very ﬂexible, it should be implemented in a language that is as ﬂexible as possible. Also, since the D.P. software may exist across multiple language platforms, a language that is easily integrated into most other programming languages should be

(27)

used as well. Since the C++ programming language accomplishes this, it should be used. The C++ inheritance model lends itself directly to the inheritance model discussed in the above class structure. For most popu-lar programming languages, there often exists ways of directly interfacing with C++ code. A sample C++ header ﬁle showing an implementation of these classes is given as Appendix C at the end of this report.

5 FURTHER APPLICATIONS OF D.P. SOFTWARE

The software developed for D.P. here at IOT has been designed primar-ily for the use of station-keeping at model-scale as well as full-scale in the North Atlantic seas. The same design principles and software could be fur-ther applied to ofur-ther D.P. applications, and even ofur-ther marine or aerospace applications that involve similar controls. The following sections outline a few key D.P. applications that are currently being explored at IOT.

5.1 Arctic Exploration and D.P. in Ice

Interest in exploring the Arctic for natural oil and gas reserves has been growing in the past year. Given this, there is also increased interest in equipping drilling vessels with D.P. control which are can operate in pack ice (as well as so-called “managed8_{” ice).}

(28)

One of the biggest challenges to implementing a D.P.I. control system is the estimation and prediction of ice loads. According to Dr. James Millan, there is statistical evidence to support the notion that ice loads on a vessel will vary rapidly and in a non-Gaussian way. As traditional Kalman ﬁl-ter models for state estimation require Gaussian-like distributions for such loads, they may not be applicable in D.P.I. applications. In order to estimate an ice load, the estimate must be produced from either a numerical model, or a measurement-derived “feedforward” (See Section 2.) As shown in Fig-ure 1, the thrust demands9 _{of the control system are generated from both}

the gain applied to the position error, as well as the environment feedfor-ward terms. In addition to usual terms (such as wind loads), an ice-load feedforward term would allow for a great improvement in the D.P. control system for ice applications.

5.1.1 Computer Vision and Machine Learning for D.P.I.

In the case of estimating ice-loads through a measurement-derived feed-forward, one method proposed involves the use of optical equipment (e.g. cameras, depth sensors, lasers, etc.) combined with powerful computer vision software. Optical equipment would image ice (particularly managed ice) while computer vision software detected various properties about it. Combining this detection with so-called “Machine Learning” techniques, it is possible for software to dynamically “learn” about how certain shapes

9_{Commonly denoted as τ}

(29)

Figure 9: RGB/Depth Camera shots from Kinect Using OpenCV

and sizes of ice in a particular environment affect thrust and expected er-ror corrections. Using this information, the control model could tune itself automatically to adjust for the difference in expected error, thus producing an ice-load feedforward.

Effort is underway to validate whether or not Computer Vision and Ma-chine Learning techniques could be used to assist the current D.P. control model. Using a Microsoft XBOX Kinect10 _{for imaging, along with a Linux}

computer equipped with the OpenKinect driver11 _{and software written in}

OpenCV12, tests are currently underway with their results to be seen (see Figure 9). In an early test, it was determined that thin “level” model ice

al-10_{An inexpensive 3-D imaging device with useful range useful capabilities for}

model-scale testing; sold as a gaming console peripheral.

11_{OpenKinect or “freenect” is a computer hardware driver written by the open software}

community to allow the Kinect to be used as a USB imaging device. See References.

12_{A powerful open community-driven computer vision library which originated from Intel}

(30)

Figure 10: “Level” Model Ice in IOT’s Ice Tank

lows for too much of the Kinect’s projected IR light pattern to pass through its surface (see Figure 10) to allow for good imaging. Further tests will have to be completed with thicker level model ice as well as “bubbled” model ice.

5.2 Fixed Degree-of-Freedom (D.O.F) Path Tracking

The D.P. control model used at IOT has been mostly used in a so-called “Heading Priority” manner. This refers to the idea that, at any given mo-ment, the majority of a vessel’s installed thrust will be directed towards keeping the vessel’s heading. The remaining thrust is then used to posi-tion the vessel in the desired (x,y) coordinates.

(31)

Figure 11: Using a Joystick To Provide Demand Offsets

but to change either while keeping the other. In other words, it is pos-sible to directly implement portions of the D.P. control software to create path tracking software. For example, if a vessel used for acoustic imag-ing required the ability to keep headimag-ing (a simag-ingle Degree-of-Freedom) but navigate around an area in a deﬁned pattern autonomously, the usual D.P. control loop (Figure 1) could be implemented while keeping the heading set-point ﬁxed. Then, the (x,y) set-points could be automatically changed such that the vessel could travel its path (so long as the set-points change gradually to prevent thruster saturation13_.)

In another thruster control oriented application, one or two Degrees-of-Freedom could be ﬁxed to allow direct control over the remaining ones.

13_{If a set-point is positioned too far away from the vessel’s current position, the thruster}

gains could saturate to the thruster max resulting in instability and loss of control over the vessel.

(32)

0° 15° 30° 45° 60° 75° 90° 105° 120° 135° 150° 165° ±180° −165° −150° −135° −120° −105° −90° −75° −60° −45° −30° −15° 10 20 30 40 50 0.5 knots 1 knot 2 knots 3 knots 4 knots

Figure 12: Software-Generated Capability Plot

This could be done by opening the control loop on whichever D.O.F. one would want to control manually, and by manually inputting the demands. A human interface device, such as a Joystick (see Figure 11), could be used along with a calibration to feed force and/or moment demands into the opened loop.

5.3 Capability Plotting and the Common Thruster Object

Capability plots are used to graphically represent a vessel’s thrust capa-bility given various environmental conditions (see Figure 12). Given that a Common Thruster Object (See Section 4.2) list would already contain all relevant information pertaining to thruster capabilities, the addition of

(33)

some known vessel characteristics14 _{would allow for all of the information}

needed to perform capability plotting. As IOT already has software de-signed to perform capability plotting, integration with the Common Thruster Object design would be relatively simple.

Combined with D.P.I. software (see Section 5.1, capability plots could be updated with data from ice-loads, a parameter currently not accounted for in capability plotting. There is growing interest in plots incorporating ice-load data given new interests in Arctic oil and gas exploration.

14_{Important capability characteristics usually include wind, current, and wave-drift load}

(34)

6 CONCLUSIONS

The National Research Council of Canada’s Institute for Ocean Technol-ogy (IOT) has begun to extend their Dynamic Positioning (D.P.) Control System capabilities for the upcoming D.P. in ice demonstrations in Febru-ary 2011. Previous D.P. software designed for older hardware and past vessel thruster conﬁgurations needed to be upgraded for this demonstra-tion. The design for a new software implementation of the D.P. control system for this test is well underway, and work has been done to allow the software to interface with the new motion controllers and new mathemat-ical libraries. The software designed this term has been passed to IOT’s Software Engineering Group as of December 2010.

In addition to this, a new D.P. software GUI has been designed in C# for further development of D.P. software. A proposed method of D.P. soft-ware generalization, the so-called “Common Thruster Object”, has been designed in C++. Effort has begun in testing computer vision techniques for improving the existing D.P. control algorithms for prediction of ice-loads. As well, designs for future applications of D.P. control such as path-tracking and capability plotting are currently under investigation.

(35)

7 RECOMMENDATIONS

To continue the development of IOT’s Dynamic Positioning capabilities, the following points must be addressed.

• Development of software for the upcoming test in February 2011 should take priority. All effort should be made to allow the model ship to be under basic D.P. control by mid January, with focus then switching to additional D.P. in ice concerns.

• The software developed for D.P. should be moved to C# with support-ing control classes created in C++. C# is a more current language which is not only better supported, but allows the Software Engi-neering Group to continue development without the need to consider various backward compatibility issues.

• Further investigation as to whether or not computer vision techniques can be used as an ice-load detection method is required. Further testing with the Kinect and other camera equipment (e.g. stereo-scopic imaging) should be carried out.

• Further reﬁnement of the “Common Thruster Object” design is needed and effort should be made to implement it into IOT’s D.P. software by 2012.

With these items addressed, IOT will continue to have one of the world’s most mature and ﬂexible dynamic positioning control systems.

(36)

References

[1] A. Drozdek, Data Structures and Algoritms in C++. Course Technology, 2004.

[2] G. Bradski and A. Kaehler, Learning OpenCV: Computer Vision with

the OpenCV Library. O’REILLY, 2008.

[3] J. Millan, “Research Ofﬁcer.” IOT Research Group, 2010. Personal Correspondence.

[4] J. Millan, “Thrust Allocation Techniques for Dynamically Positioned Vessels,” tech. rep., NRC-IOT, 2008.

[5] J. Williams, “Technical Ofﬁcer.” IOT Electronics Group, 2010. Personal Correspondence.

[6] MathWorks, “C Shared Library Target.” Web Resource, 2010. http://www.mathworks.com/help/toolbox/compiler/f2-972343.html. [7] OpenKinect.org, “About OpenKinect.” Web Resource, 2010.

(37)

(38)

(39)

1 ' −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

2 ' −−−−−−−−−−−− TCPAxisControl . ab −−−−−−−−−−−−−−−−−

3 ' −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

4 '

5 ' T h i s program uses t h e COM command i n t e r f a c e

6 ' t o p e r f o r m TCP / IP s e r v e r communications

7 ' w i t h a remote c l i e n t .

8 '

9 ' T h i s program t a ke s s t r i n g i n p u t from a c o n t r o l

10 ' PC and processes i t i n t o motion c o n t r o l l e r

11 ' commands . T h i s s o f t w a r e was designed u si n g t h e

12 ' AeroTech sample f i l e s ' TCPServer . ab ' and ' S e r i a l

13 ' A x i s C o n t r o l . ab ' f o r t h e use o f DP2010 s o f t w a r e .

14 '

15 ' S p e c i a l Thanks t o James W i l l i a m s f o r h i s

16 ' a s s i s t a n c e i n t h i s m a t t e r

17 '

18 ' Robert Gash − September 2010

19 ' (C) NRC−IOT . A l l r i g h t s re se rve d .

20 '

21 ' E x t r a S t u f f :

22 ' The parameter s e t t i n g s on E t h e r n e t Socket 2 are :

23 '

24 ' S o cke t 2 P o r t = 8000

25 ' Socket2Setup = 0x1 (TCP s e r v e r )

26 ' S o cke t 2 T r a n sm i ssi o nSi ze = 0

27 ' −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

28

29 HEADER

30

31 DEFINE CommChannel 2 ' D e f i n e f o r channel − 2 = ←֓ E t h e r n e t Socket 2 32 DEFINE AckOkayChar 37 33 DEFINE AckUnreqChar 63 34 DEFINE AckIncompChar 33 35 36 END HEADER 37 38 DECLARATIONS 39

(40)

40 ' G l o b a l v a r i a b l e s f o r s t r i n g s .

41 GLOBAL CommandLineString AS STRING( 1 0 0 ) ' Maximum o f 100←֓ c h a r a c t e r s

42 ' per command .

43 GLOBAL CommandLabel AS STRING( 3 )

44 GLOBAL CommandArg1 AS STRING( 4 0 )

47 GLOBAL CommandLinePointer AS INTEGER

48 GLOBAL StatusString AS STRING( 4 0 )

49

50 END DECLARATIONS

51

52 PROGRAM

53

54 DIM ReceivedStringLen AS INTEGER

55 DIM DoubleValue1 AS DOUBLE

56 DIM DoubleValue2 AS DOUBLE

57 DIM IntegerValue1 AS INTEGER

58 DIM IntegerValue2 AS INTEGER

59 DIM Arg1Valid AS INTEGER

60 DIM Arg2Valid AS INTEGER

61

62 DIM DataString AS STRING( 2 0 )

63 DIM tempInSize AS INTEGER

64 DIM ExitFlag AS INTEGER = 0

65

66 DWELL 3 ' I f t h i s program i s autorun , you must p r o v i d e

67 ' t i m e f o r t h e E t h e r n e t code t o s t a r t . 68 69 OPENCOM CommChannel 70 71 WHILE ExitFlag = 0 72 73 ' As p r o t e c t i o n a g a i n s t m i ssi n g data , c l e a r o u t ←֓ t h e s t r i n g s . 74 ' 75 CommandArg1 = "" 76 CommandArg2 = "" 77 CommandArg3 = ""

(41)

78

79 ' Wait u n t i l data i s r e c e i v e d .

80 tempInSize = READCOMCOUNT ( CommChannel )

81

82 ' I f data i s r e ce i ve d , echo i t back .

83 IF tempInSize > 0 THEN

84 ' Echo back any s t r i n g s t h a t are r e c e i v e d .

85 READCOM CommChannel , CommandLineString , ←֓ tempInSize

86

87 CALL ReadCommandLabel ( )

88

89 ' Note : The l i n e feed c h a r a c t e r a l s o shows up i n t h e ←֓ b u f f e r .

90 ' Compare i t t o + 1 .

91 IF tempInSize > ( CommandLinePointer +1) THEN

92 CALL RemoveSeparateChars ( )

93 CALL ReadCommandArgument ( 1 )

94 END IF

95

99 END IF

100

104 END IF

105

106 Arg1Valid = LEN( CommandArg1 )

107 Arg2Valid = LEN( CommandArg2 )

108

109 ' Parse t h e command code , and p e r f o r m necessary ←֓ a c t i o n s .

110 ' Note : T h i s program l o o k s f o r o n l y uppercase ←֓ commands .

111 IF CommandLabel = " EN" THEN ' Enable .

112 ENABLE

(42)

114 ELSEIF CommandLabel = " DI" THEN ' D i s a b l e .

115 DISABLE

116 'WRITECOMCHAR 0 , AckOkayChar

117 ELSEIF CommandLabel = " AB" THEN ' A b o r t .

118 ABORT

120 ELSEIF CommandLabel = " FA" THEN ' ←֓ Acknowledge f a u l t s .

121 FAULTACK

123 ELSEIF CommandLabel = " HO" THEN ' Home .

124

125 HOME

126 ' Note : The f o l l o w i n g AckOkayChar

127 ' i s n o t r e c e i v e d u n t i l t h e HOME

128 ' command i s completed .

130 ELSEIF CommandLabel = " RA" THEN

131 ' Set ramp r a t e , and use r a t e−based .

132

133 IF Arg1Valid <> 0 THEN

134 DoubleValue1 = CDBL( CommandArg1 )

135 RAMP RATE DoubleValue1

136 RAMP MODE RATE

138 ELSE

139 ' M i ssi n g parameter va l u e causes an e r r o r←֓ .

140 'WRITECOMCHAR 0 , AckIncompChar

141 END IF

142 ELSEIF CommandLabel = " RT" THEN

143 ' Set ramp time , and use time−based .

146 RAMP TIME DoubleValue1

147 RAMP MODE TIME

149 ELSE

(43)

152 END IF

153 ELSEIF CommandLabel = " RD" THEN

154 ' Set ramp d i s t a n c e , and use d i s t a n c e−based .

155

158 RAMP DIST DoubleValue1

159 RAMP MODE DIST

161 ELSE

164 END IF

165 ELSEIF CommandLabel = " FR" THEN ' Freerun .

168 FREERUN F DoubleValue1

170 ELSE

173 END IF

174 ELSEIF CommandLabel = " MV" THEN ' ←֓ I n c r e m e n t a l move .

175 IF Arg1Valid <> 0 AND Arg2Valid <> 0 THEN

178 LINEAR D DoubleValue1 F DoubleValue2

180 ELSE

183 END IF

184 ELSEIF CommandLabel = " DO" THEN ' Set ←֓ d i g i t a l o u t p u t s .

(44)

186 IntegerValue1 = CINT( CommandArg1 )

188 DOUT IntegerValue1 , IntegerValue2

190 ELSE

193 END IF

194 ELSEIF CommandLabel = " AO" THEN ' Set ←֓ analog o u t p u t s .

195 IF Arg1Valid <> 0 AND Arg2Valid <> 0 THEN

198 AOUT IntegerValue1 : IntegerValue2

200 ELSE

203 END IF

204 ELSEIF CommandLabel = " RR" THEN

205 ' Read r e g i s t e r ( many o p t i o n s ) .

206 ' T h i s i s t h e o n l y command t h a t sends back ←֓ data .

207 ' Note : The ACK c h a r a c t e r i s se n t a f t e r t h e ←֓ data .

210 ' Use I n t e g e r V a l u e 1 as a lookup i n t o a 211 ' t a b l e o f va l u e s t o be read . 212 IF IntegerValue1 = 0 THEN ' P o s i t i o n←֓ command . 213 DoubleValue1 = PCMD ( ) 214 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1 215 'WRITECOM 0 , S t a t u s S t r i n g 216 'WRITECOMCHAR 0 , AckOkayChar

217 ELSEIF IntegerValue1 = 1 THEN ' P o s i t i o n←֓ feedback .

(45)

218 DoubleValue1 = PFBK ( )

219 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1

220 WRITECOM 0 , StatusString

222 ELSEIF IntegerValue1 = 2 THEN ' P o s i t i o n←֓ e r r o r . 223 DoubleValue1 = PERR ( ) 224 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1 225 'WRITECOM 0 , S t a t u s S t r i n g 226 'WRITECOMCHAR 0 , AckOkayChar

227 ELSEIF IntegerValue1 = 3 THEN ' V e l o c i t y←֓ command . 228 DoubleValue1 = VCMD ( ) 229 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1 230 'WRITECOM 0 , S t a t u s S t r i n g 231 'WRITECOMCHAR 0 , AckOkayChar

232 ELSEIF IntegerValue1 = 4 THEN ' V e l o c i t y←֓ feedback . 233 DoubleValue1 = VFBK ( ) 234 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1 235 'WRITECOM 0 , S t a t u s S t r i n g 236 'WRITECOMCHAR 0 , AckOkayChar

237 ELSEIF IntegerValue1 = 5 THEN ' V e l o c i t y←֓ e r r o r . 238 DoubleValue1 = VERR ( ) 239 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1 240 'WRITECOM 0 , S t a t u s S t r i n g 241 'WRITECOMCHAR 0 , AckOkayChar

242 ELSEIF IntegerValue1 = 6 THEN ' C u r r e n t ←֓ command . 243 DoubleValue1 = ICMD ( ) 244 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1 245 'WRITECOM 0 , S t a t u s S t r i n g 246 'WRITECOMCHAR 0 , AckOkayChar

(46)

247 ELSEIF IntegerValue1 = 7 THEN ' C u r r e n t ←֓ feedback . 248 DoubleValue1 = IFBK ( ) 249 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1 250 'WRITECOM 0 , S t a t u s S t r i n g 251 'WRITECOMCHAR 0 , AckOkayChar

252 ELSEIF IntegerValue1 = 8 THEN ' C u r r e n t ←֓ e r r o r . 253 DoubleValue1 = IERR ( ) 254 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1 255 'WRITECOM 0 , S t a t u s S t r i n g 256 'WRITECOMCHAR 0 , AckOkayChar

257 ELSEIF IntegerValue1 = 9 THEN ' E x t e r n a l←֓ p o s i t i o n . 258 DoubleValue1 = EXTPOS ( ) 259 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1 260 'WRITECOM 0 , S t a t u s S t r i n g 261 'WRITECOMCHAR 0 , AckOkayChar

262 ELSEIF IntegerValue1 = 10 THEN ' A xi s ←֓

s t a t u s .

263 IntegerValue2 = AXISSTATUS ( )

264 FORMAT StatusString , "%d", INTV :←֓ IntegerValue2

265 'WRITECOM 0 , S t a t u s S t r i n g

267 ELSEIF IntegerValue1 = 11 THEN ' A xi s ←֓

f a u l t s .

268 IntegerValue2 = AXISFAULT ( )

272 ELSEIF IntegerValue1 = 12 THEN ' A l l ←֓

d i g i t a l i n p u t s .

273 IntegerValue2 = DIN ( ALL )

(47)

277 ELSEIF IntegerValue1 = 13 THEN ' Analog ←֓

I n p u t 0 . 278 DoubleValue1 = AIN ( 0 ) 279 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1 280 'WRITECOM 0 , S t a t u s S t r i n g 281 'WRITECOMCHAR 0 , AckOkayChar

282 ELSEIF IntegerValue1 = 14 THEN ' Analog ←֓

I n p u t 1 . 283 DoubleValue1 = AIN ( 1 ) 284 FORMAT StatusString , "%g", DBLV :←֓ DoubleValue1 285 'WRITECOM 0 , S t a t u s S t r i n g 286 'WRITECOMCHAR 0 , AckOkayChar 287 ELSE 288 ' Unrecognized r e g i s t e r causes an ←֓ e r r o r . 289 'WRITECOMCHAR 0 , AckUnreqChar 290 END IF 291 ELSE

294 END IF

295 ELSE

296 ' Bad command code causes an e r r o r .

297 'WRITECOMCHAR 0 , AckUnreqChar 298 END IF 299 300 ' WRITECOM CommChannel , D a t a S t r i n g 301 302 ' Watch f o r t h e e x i t s t r i n g .

303 IF CommandLineString = "EXIT " THEN

304 ExitFlag = 1

305 END IF

306

307 ' I F D a t a S t r i n g = ”HOME” THEN

(48)

309 ' E x i t F l a g = 1 310 'END I F 311 312 313 314 315 316 317 END IF 318 319 WEND 320

321 CLOSECOM CommChannel ' Close communications p o r t .

322 323 END PROGRAM 324 325 ' T h i s f u n c t i o n e x t r a c t s t h e command l a b e l . 326 FUNCTION ReadCommandLabel ( ) 327 CommandLabel ( 0 ) = CommandLineString ( 0 ) 328 CommandLabel ( 1 ) = CommandLineString ( 1 ) 329 CommandLabel ( 2 ) = 0 330 CommandLinePointer = 2 331 END FUNCTION 332 333 FUNCTION RemoveSeparateChars ( )

334 DIM FoundChar AS INTEGER

335 DIM TestChar AS INTEGER

336

337 FoundChar = 0

338

339 WHILE FoundChar = 0

340 TestChar = CommandLineString ( CommandLinePointer )

341 IF TestChar <> " " AND TestChar <> " ," THEN

342 FoundChar = 1 343 ELSE 344 CommandLinePointer = CommandLinePointer + 1 345 END IF 346 WEND 347 348 END FUNCTION

(49)

349

350 ' T h i s f u n c t i o n e x t r a c t s t h e n e xt parameter value , by ←֓ l o o k i n g

351 ' f o r t h e f i r s t s e p a r a t o r c h a r a c t e r a f t e r t h e va l u e .

352 ' Use a space o r a comma as a s e p a r a t o r c h a r a c t e r .

353 FUNCTION ReadCommandArgument ( BYVAL ArgNum AS INTEGER)

354 DIM FoundSepChar AS INTEGER

355 DIM TestChar AS INTEGER

356 DIM CommandArgStr AS STRING( 4 0 )

357 DIM CharsRead AS INTEGER

358

359 FoundSepChar = 0

360 CharsRead = 0

361

362 WHILE FoundSepChar = 0

363 TestChar = CommandLineString ( CommandLinePointer )

364 IF TestChar = " " OR TestChar = "," OR TestChar

365 = "\ x0A" THEN

366 FoundSepChar = 1

367 ELSE

368 CommandArgStr ( CharsRead ) = CommandLineString (←֓ CommandLinePointer ) 369 CommandLinePointer = CommandLinePointer + 1 370 CharsRead = CharsRead + 1 371 END IF 372 WEND 373 CommandArgStr ( CharsRead ) = 0 374 ' Add n u l l c h a r a c t e r t o end o f s t r i n g . 375 376 IF ArgNum = 1 THEN 377 CommandArg1 = CommandArgStr

378 ELSEIF ArgNum = 2 THEN

379 CommandArg2 = CommandArgStr 380 ELSE 381 CommandArg3 = CommandArgStr 382 END IF 383 384 END FUNCTION

(50)

(51)

The following code shows a header ﬁle generated by the MATLAB Compiler. It exports MATLAB Engine and framework start/stop functions as well as two user-deﬁned functions.

1 / /

2 / / MATLAB Compiler : 4.11 ( R2009b )

3 / / Date : Tue Sep 21 1 2 : 0 8 : 5 7 2010

4 / / Arguments : ”−B” ” m a c r o d e f a u l t ” ”−W” 5 / / ” c p p l i b : r o o t L i b ” ”−T ” ” l i n k : l i b ” 6 / / ” r o o t O f .m” ” matMul .m” 7 / / 8 9 # ifndef r o o t L i b h 10 # define r o o t L i b h 1 11

12 #if d e f i n e d ( c p l u s p l u s ) && ! d e f i n e d ( m c l m c r r t h ) &&

13 defined ( __linux__ ) 14 # pragma i m p l e m e n t a t i o n " mclmcrrt.h" 15 # endif 16 # include " mclmcrrt.h" 17 # include " mclcppclass .h" 18 # ifdef c p l u s p l u s 19 extern "C" { 20 # endif 21 22 #if d e f i n e d ( SUNPRO CC ) 23

24 # ifdef EXPORTING rootLib

25 # define PUBLIC rootLib C API g l o b a l

26 #else

27 # define PUBLIC rootLib C API _{/ * No import statement}

28 needed . _{* /}

29 # endif

30

31 # define L I B r o o t L i b C A P I PUBLIC rootLib C API

32

33 #elif d e f i n e d ( HPUX SOURCE)

34

(52)

36 # define PUBLIC rootLib C API __declspec(dllexport)

37 #else

38 # define PUBLIC rootLib C API __declspec(dllimport)

39 # endif

40

41 # define L I B r o o t L i b C A P I PUBLIC rootLib C API

42 43 44 #else 45 46 # define L I B r o o t L i b C A P I 47 48 # endif 49 50 # ifndef L I B r o o t L i b C A P I

51 # define L I B r o o t L i b C A P I _{/ * No s p e c i a l import / export}

52 _{declaration * /} 53 # endif

54

55 extern LIB_rootLib_C_API

56 bool MW_CALL_CONV rootLibInitializeWithHandlers (

57 mclOutputHandlerFcn error_handler ,

58 mclOutputHandlerFcn print_handler ) ;

59

61 bool MW_CALL_CONV rootLibInitialize (void) ;

62

64 void MW_CALL_CONV rootLibTerminate (void) ;

65 66 67

69 void MW_CALL_CONV rootLibPrintStackTrace (void) ;

70

72 bool MW_CALL_CONV mlxRootOf (int nlhs ,

73 _{mxArray * plhs [ ] ,} 74 int nrhs ,

(53)

76

78 bool MW_CALL_CONV mlxMatMul (int nlhs ,

79 _{mxArray * plhs [ ] ,} 80 int nrhs ,

81 _{mxArray * prhs [ ] ) ;} 82

84 long MW_CALL_CONV rootLibGetMcrID ( ) ;

85 86 87 # ifdef c p l u s p l u s 88 } 89 # endif 90 91 # ifdef c p l u s p l u s 92

93 #if d e f i n e d ( MSC VER ) | | d e f i n e d ( BORLANDC )

94

95 # ifdef EXPORTING rootLib

96 # define PUBLIC rootLib CPP API __declspec(dllexport)

97 #else

98 # define PUBLIC rootLib CPP API __declspec(dllimport)

99 # endif

100

101 # define L I B r o o t L i b C P P A P I PUBLIC rootLib CPP API

102 103 #else 104 105 #if ! d e f i n e d ( L I B r o o t L i b C P P A P I ) 106 #if d e f i n e d ( L I B r o o t L i b C A P I ) 107 # define L I B r o o t L i b C P P A P I L I B r o o t L i b C A P I 108 #else 109 # define L I B r o o t L i b C P P A P I _{/ * empty ! * /} 110 # endif 111 # endif 112 113 # endif 114

(54)

116 rootOf (int nargout , mwArray& Ans , const mwArray& num←֓ ) ;

117

118 extern LIB_rootLib_CPP_API void MW_CALL_CONV

119 matMul (int nargout , mwArray& R , const mwArray& A , const←֓

mwArray& B ) ;

120

121 # endif

(55)

The following code shows a .DLL Driver which essentially wraps the wrapper code and provides an interface to the engine start/stop functions, as well as the user-deﬁned functions.

1 / / T h i s DLL p r o v i d e s an API t o t h e MATLAB run−tim e engine←֓ as w e l l as a sample 2 / / MATLAB f u n c t i o n 3 4 # include " stdafx.h" 5 # include " mefapi.h" 6

7 / / S t a r t t h e Matlab Compiler Runtime Environment

8 void __stdcall runtimeStart ( ){

9 mclmcrInitialize ( ) ;

10 }

11

12 int __stdcall appStart ( ){

13 if ( ! mclInitializeApplication ( NULL , 0 ) ){

14 std : : cerr << " Could not initialize the application ←֓ properly." << _{std : : endl ;} 15 return −1; 16 } 17 return 0 ; 18 } 19 20 / / S t a r t t h e l i b r a r i e s t o be used 21

22 int __stdcall rootLibStart ( ){

23 if( ! rootLibInitialize ( ) ){

24 std : : cerr << " could not initialize the rootlib ←֓ library properly" << std : : endl ;

25 return −4;

26 }

27 return 0 ;

28 }

29

30 / / Stop l i b r a r i e s and engine once f i n i s h e d ; r e q u i r e d f o r ←֓ memory r e l e a s e

(56)

32 int __stdcall everythingStop ( ){ 33 rootLibTerminate ( ) ; 34 mclTerminateApplication ( ) ; 35 return 0 ; 36 } 37 38 39 / / U s e f u l f u n c t i o n s t o be e xp o r t e d go here 40

41 int __stdcall vbRoot (double vbIn , double& vbOut ){

42 try {

43 mwArray Ans ( vbOut ) ;

44 mwArray Num ( vbIn ) ;

45 rootOf ( 1 , Ans , Num ) ; / / p e r f o r m s q u a r e r o o t

46 vbOut = Ans ( 1 , 1 ) ; / / r e t u r n t h e va l u e

47 return 0 ;

48 }

49 catch (const mwException& e ){

50 std : : cerr << e . what ( ) << ": vbRoot" << _{std : : endl ;}

51 return −2;

52 }

53 catch ( . . . ){

54 std : : cerr << " Unexpected error thrown on vbRoot←֓ " << std : : endl ;

55 return −3;

56 }

57 }

58

59 void arrayFill ( mwArray &fillMatrix , double input [ ] , int ←֓ rows , int cols ){

60

61 for(int i = 0 ; i<rows ; i ++){

62 for(int j = 0 ; j<cols ; j ++){

63 _{/ / f i l l M a t r i x ( i +1 , j +1) = * ( i n p u t + i * cols + j ) ←֓}

;

64 _{fillMatrix ( i +1 , j +1) = input [ i * cols + j ] ;}

65 }

66 }

67 68 }

(57)

69

70 void arrayFill2 ( mwArray &fillMatrix , double input [ ] , int ←֓ rows , int cols ){

71

72 for(int i = 0 ; i<rows ; i ++){

73 for(int j = 0 ; j<cols ; j ++){

74 _{/ / * ( i n p u t + i * cols + j ) = f i l l M a t r i x ( i +1 , j +1)←֓}

;

75 _{input [ i * cols + j ] = fillMatrix ( i+1 ,j+1) ;}

76 }

77 }

78 }

79

80 void __stdcall vbMul (double vbOut [ ] , double matA [ ] , short←֓

& rowsA , short& colsA , double matB [ ] , short& rowsB , ←֓

short& colsB ){

81

82 mwArray mwA ( rowsA , colsA , mxDOUBLE_CLASS ) ;

83 mwArray mwB ( rowsB , colsB , mxDOUBLE_CLASS ) ;

84 mwArray mwR ( rowsA , colsA , mxDOUBLE_CLASS ) ; / / Assume←֓ i t w i l l be t h e same f o r t e s t purposes

85

86 arrayFill ( mwA , matA , rowsA , colsA ) ;

87 arrayFill ( mwB , matB , rowsB , colsB ) ;

88

89 matMul ( 1 , mwR , mwA , mwB ) ; / / Perform M a t r i x ←֓ M u l t i p l i c a t i o n .

90

91 arrayFill2 ( mwR , vbOut , rowsA , colsA ) ; / / r e t u r n a r r a y ←֓ o f va l u e s along w i t h m a t r i x

92 / / dimensions

93 colsB = 4 ;

94 95 }

(58)

(59)

1

2 _{/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *} 3 _* A c t u a t o r − R . Gash 2010

4 _*

5 _{* T h i s p r o j e c t was designed as a way t o i n c r e a s e t h e} 6 _{* p o r t a b i l i t y and m o d u l a r i t y o f code designed t o i n t e r f a c e} 7 _{* w i t h Dynamic P o s i t i o n i n g C o n t r o l Systems . W r i t t e n i n C←}֓

++ ,

8 _{* i t} i s e a s i l y wrapped i n a l m o st any language . T h i s

9 _{* p a r t i c u l a r i n c a n t a t i o n o f t h e code i s designed t o i n t e r −} 10 _{* f a ce w i t h an A ct i ve X COM O b j e ct (MFC) f o r use i n VB6 /C# .} 11 _*

12 _{* A l l code used here i s t h e i n t e l l e c t u a l p r o p e r t y o f} 13 _{*NRC−IOT . A l l r i g h t s r e se r ve d .} 14 _* 15 _* 16 _{* a u t h o r : rmgash@gmail . com} 17 _{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ←}֓ * / 18 19 20 21 # ifndef ACTUATOR H 22 # define ACTUATOR H 23 24 # endif _{/ * ACTUATOR H * /} 25 26 # include <s t d l i b . h>

27 # include <c a s s e r t > / / should n o t i n c l u d e i n non−t e s t i n g ←֓

r e l e a s e

28

29 # include <winsock2 . h> / / may be r e p l a c e d by t h e BSD so cke t

30 / / i m p l e m e n t a t i o n on UNIX p l a t f o r m s

31

32 # include <w s2 t cp i p . h>

33 # include <s t d i o . h>

34

35 # pragma comment ( l i b , " Ws2_32. lib")

36 37

(60)

38 _{/ * * * * FixedPropulsion * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *} 39 _*

40 _{* Designed f o r i n t e r f a c i n g a s i n g l e p r o p u l s i o n u n i t} 41 _{* which i s non−a z i m u t h i n g ( s i n g l e −a x i s ) t o a c o n t r o l}

42 _{* system . T h i s i s a l s o a t h e base c l a s s on which t h e o t h e r} 43 _{* p r o p u l s i o n c l a s s e s i n h e r i t} t h e i r base p r o p e r t i e s . 44 _* 45 _{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /} 46 47 class FixedPropulsion { 48 public: 49 50 / / C o n s t r u c t o r 51 FixedPropulsion ( ) ; 52

53 / / accessor and m o d i f i e r f u n c t i o n s f o r X and Y body−←֓ frame

54 / / c o o r d i n a t e s o f prop . u n i t

55 double getXPos ( ) ;

56 double getYPos ( ) ;

57 void setXPos (double pos ) ;

58 void setYPos (double pos ) ;

59

60 / / accessor and m o d i f i e r f u n c t i o n s f o r min / max s h a f t

61 / / speed o f prop . u n i t ( d e f i n e d i n rad / sec ) .

62 double getMinShaftSpeed ( ) ;

63 void setMinShaftSpeed (double speed ) ;

64 double getMaxShaftSpeed ( ) ;

65 void setMaxShaftSpeed (double speed ) ;

66

67 / / accessor and m o d i f i e r f u n c t i o n s f o r c o r r e s p o n d i n g

68 / / channel on motion c o n t r o l l e r ( m u l t i−a x i s / analog o n l y )

69 int getChannel1 ( ) ;

70 void setChannel1 (int channel ) ;

71

72 / / Connection s e t t i n g s i f TCP / IP communication i s t o be ←֓ used

73 void setDeviceIP1 (const char_{* myIP ,} unsigned short size←֓ ) ;

(61)

74 void setDevicePort1 (const char_{* port ,} unsigned short ←֓ size ) ;

75 char_{* getDeviceIP1 ( ) ;}

76 int getDevicePort1 ( ) ;

77 void TCPconnect ( ) ;

78 short TCPsendTest (char _{* sendbuf ) ;}

79 void TCPclose ( ) ; 80 81 82 83 / / D e s t r u c t o r 84 ˜ FixedPropulsion ( ) ; 85 protected: 86 char_{* ip1 ;} 87 char_{* testPort ;} 88 _{/ / char * sendBuffer ;} 89 WSADATA wsInst1 ;

90 struct _{addrinfo * result ,}

91 _{* ptr ,} 92 hints ; 93 SOCKET ConnectSocket ; 94 95 96 double xPos ; 97 double yPos ; 98 double minShaftSpeed ; 99 double maxShaftSpeed ; 100 int channel1 ; 101 int ipLength1 ; 102 int port1 ; 103 104 } ; 105 106 107 _{/ * * * * AzimuthPropulsion * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *} 108 _* 109 _{* Designed f o r i n t e r f a c i n g a s i n g l e p r o p u l s i o n u n i t} 110 _{* which i s a z i m u t h i n g . Basic i n f o r m a t i o n about t h e ←}֓

t h r u s t e r

(62)

112 _{* c l a s s adds t h e i n f o r m a t i o n r e q u i r e d f o r a secondary} 113 _{* s i n g l e −a x i s motion c o n t r o l l e r ( o r a n o t h e r channel o f a} 114 _{* m u l t i −a x i s motion c o n t r o l l e r ) t o c o n t r o l t h e a z i m u t h i n g} 115 _{* p r o p e r t i e s o f t h e prop . u n i t .} I t a l s o p r o v i d e s t h e

116 _{* i n h e r i t a n c e t o t h e d e r i v e d c l a s s R u d d e r P r opul si on .} 117 _*

118 _{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /} 119 class AzimuthPropulsion : public FixedPropulsion {

120 public:

121

122 / / accessor and m o d i f i e r f u n c t i o n s f o r min / max angles

123 / / o f a z i m u t h i n g prop . u n i t ( d e f i n e d i n degrees ) .

124 double getMaxAngle ( ) ;

125 double getMinAngle ( ) ;

126 void setMaxAngle (double angle ) ;

127 void setMinAngle (double angle ) ;

128

129 / / accessor and m o d i f i e r f u n c t i o n s f o r min / max s h a f t

130 / / speed o f azimuth d r i v e o f prop . u n i t ( d e f i n e d

131 / / i n rad / sec ) .

132 double getMinAzShaftSpeed ( ) ;

133 double getMaxAzShaftSpeed ( ) ;

134 void setMaxAzShaftSpeed (double speed ) ;

135 void setMinAzShaftSpeed (double speed ) ;

136

137 / / accessor and m o d i f i e r f u n c t i o n s f o r c o r r e s p o n d i n g

138 / / channel on motion c o n t r o l l e r ( m u l t i−a x i s / analog o n l y )

139 int getChannel2 ( ) ;

140 void setChannel2 (int channel ) ;

141

142 / / Connection s e t t i n g s f o r TCP / IP communication t o be

143 / / used i f d i f f e r e n t from p r e v i o u s used f o r t h r u s t e r

144 / / a x i s ( e . g . S i n g l e−A xis motion packs )

145 void setDeviceIP2 (char[ ] , int size ) ;

146 void setDevicePort2 (int port ) ;

147 char getDeviceIP2 ( ) ;

148 int getDevicePort2 ( ) ;

149 150 151

(63)

152 protected: 153 154 double maxAngle ; 155 double minAngle ; 156 double minAzShaftSpeed ; 157 double maxAzShaftSpeed ; 158 int channel2 ; 159 int ipLength2 ; 160 char ip2 ; 161 int port2 ; 162 163 } ; 164 165 _{/ * * * * RudderPropulsion * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *} 166 _* 167 _{* Designed f o r i n t e r f a c i n g a s i n g l e p r o p u l s i o n u n i t} 168 _{* which uses a r u d d e r . Basic i n f o r m a t i o n about t h e ←}֓

t h r u s t e r

169 _{* i s i n h e r i t e d from t h e base c l a s s ( F i x e d P r o p u l s i o n ) . T h i s} 170 _{* c l a s s adds t h e i n f o r m a t i o n r e q u i r e d f o r a secondary} 171 _{* s i n g l e −a x i s motion c o n t r o l l e r ( o r a n o t h e r channel o f a} 172 _{* m u l t i −a x i s motion c o n t r o l l e r ) t o c o n t r o l t h e p r o p e r t i e s} 173 _{* o f t h e r u d d e r u n i t . D e r i ve d from t h e A zi m u t h P r o p u l si o n} 174 _{* cl a ss ,} i t assumes many o f t h e same p r o p e r t i e s o f an

175 _{* a z i m u t h i n g d r i v e i n a d d i t i o n t o drag and l i f t} c o e f f s . o f

176 _{* t h e r u d d e r .} 177 _*

178 _{* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /} 179 class RudderPropulsion : public AzimuthPropulsion {

180 public:

181

182 / / accessor and m o d i f i e r f u n c t i o n s f o r drag / l i f t

183 / / c o e f f s . o f r u d d e r d r i v e o f prop . u n i t

184 double getLiftCoef ( ) ;

185 double getDragCoef ( ) ;

186 void setDragCoef (double coef ) ;

187 void setLifCoef (double coef ) ;

188

189 protected:

(64)

191 double liftCoef ;

192 double dragCoef ;

193 194 } ;

Development of software for dynamic positioning control systems

Archives des publications du CNRC

Development of software for dynamic positioning control systems

Gash, Robert

Development of Software for Dynamic

Positioning Control Systems

Contents

List of Figures

1

INTRODUCTION

1.1

Previous IOT Dynamic Positioning Software

1.2

Upgrading Existing Software

2

DYNAMIC POSITIONING CONTROL SYSTEMS

2.1

Overview

2.2

D.P. Control System Loop

2.3

D.P. Control Systems in Model Scale

3

SOFTWARE IMPLEMENTATION OF D.P.

CON-TROL

3.1

Design for Upcoming IOT D.P. Tests

3.2

Communication Channel for D.P.I Model

3.3

Mathematical Processing for Control System

3.4

Main D.P. Control Program and GUI

4

MAINTAINING D.P. SOFTWARE

4.1

Generalizing Software for Propulsion Units

4.2

Design of a Common Thruster Object

4.3

Implementing a Common Thruster Object

5

FURTHER APPLICATIONS OF D.P. SOFTWARE

5.1

Arctic Exploration and D.P. in Ice

5.2

Fixed Degree-of-Freedom (D.O.F) Path Tracking

5.3

Capability Plotting and the Common Thruster Object

6

CONCLUSIONS

7

RECOMMENDATIONS

References