NETWORKED ARCHITECTURE FOR A CONTROL SYSTEM FOR A STEERABLE THRUSTING DEVICE

Abstract

A control system for a steerable thrusting device is disclosed comprising a mobile device and application which interface with an electronic controller to command the output power and directional heading of the steerable thrusting device. In at least one embodiment, the mobile device serves the functions of a mapping and input device that communicates bi-directionally with a Global Navigation Satellite System (GNSS) and direction device-equipped electronic controller, which in turn controls the power and heading of the thrusting device on a marine vessel. Data can be stored on the mobile device or procured in real-time via network access to a dedicated database and communicated to the electronic controller in order to execute specific functions of the thrusting device control system. The data created can be shared over a cloud network. A feature control system is introduced for alternately enabling and disabling features of the steerable thrusting device control system.

Claims

1. A method of controlling enablable features of an electronically controlled steerable thruster system of a vessel comprising the steps of: establishing a wireless network communication between a peripheral input device and the internet; starting a mobile controller application on said peripheral input device; establishing communication between said peripheral input device and an electronic controller; obtaining a software key from a location on the internet; authenticating the software key using an authentication program; using the authenticated software key to activate one or more unlockable features of the mobile controller application; establishing communication between the electronic controller and the steerable thruster device; sending thrusting device magnitude and direction control signals from the electronic controller to the steerable thruster device resulting in consequent control of the steerable thruster device and consequent movement of the vessel towards one or more of: a predetermined waypoint and a predetermined route.

2. The method of claim 1 further comprising the step of utilizing a smart phone as the peripheral input device.

3. The method of claim 1 further comprising the step of utilizing a tablet as the peripheral input device.

4. The method of claim 1 further comprising the step of utilizing a chart plotter as the peripheral input device.

5. The method of claim 1 further comprising the step of generating a software key consequent at least one of: making a payment, and entering a unique coupon code.

6. The method of claim 1 further comprising the step of generating a valid software key based on a serial number from the electronic controller.

7. The method of claim 1 further comprising the step of utilizing a location on the internet to confirm the software key is a valid software key.

8. The method of claim 1 further comprising the step of utilizing a location on the peripheral input device to confirm the software key is a valid key.

9. The method of claim 1 further comprising the step of utilizing a location on the electronic controller to confirm the software key is a valid key.

10. The method of claim 1 further comprising the step of downloading the software key from a site on the internet.

11. The method of claim 1 further comprising the step of obtaining the software key from one or more of: a cached, and a locally stored data source on the peripheral input device.

12. The method of claim 1 further comprising the step of obtaining the software key from one or more of: a cached, and a locally stored data source on the electronic controller.

13. The method of claim 1 further comprising the step of utilizing a wireless connection to download the software key from a site on the internet.

14. The method of claim 1 further comprising the step of utilizing the software key to enable the use of one or more of: a map, and a specific map type.

15. The method of claim 1 further comprising the step of utilizing the software key to enable the use of a multiple-point route.

16. The method of claim 1 further comprising the step of utilizing the software key to enable use of a GPS position hold.

17. The method of claim 1 further comprising the step of utilizing the software key to enable downloading one or more of: new software, and firmware for the steerable thruster system.

18. The method of claim 1 further comprising the step of determining the validity of a user through the use of a database entry.

19. The method of claim 1 further comprising the step of determining the validity of a user using a login and authentication token.

20. The method of claim 1 further comprising the step of activating the authentication program on the peripheral input device.

21. The method of claim 1 further comprising the step of activating the authentication program on a server on the global internet.

22. The method of claim 1 further comprising the step of utilizing the authenticated software key to activate the use of point to point routing.

23. The method of claim 1 further comprising the step of utilizing the authenticated software key to activate the use of one or more of: a satellite map, and a contour map.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0114] These and other features and advantages of the present invention will become more readily appreciated when considered in connection with the following detailed description and appended drawings, wherein:

[0115] FIG. 1 is a perspective view illustrating one form of the control system utilized on a medium sized fishing boat for control of an attached bow mounted trolling motor;

[0116] FIG. 2 are perspective views illustrating components of the control system that are utilized with the bow mount trolling motor of FIG. 1;

[0117] FIG. 3 is a perspective view illustrating the bow mounted trolling motor of FIG. 1 with the installed hardware;

[0118] FIG. 4 is a close-up perspective view illustrating the enclosure assembly that houses the electronic controller as well as the mounting configuration of the preferred embodiment;

[0119] FIG. 5 is a perspective view illustrating an electrical junction box for mating the controller to the bow mounted trolling motor, and power source in the preferred embodiment;

[0120] FIG. 6 is a front view illustrating a sample mobile application interface screen on the peripheral mobile networked input device for manual control mode of the electronic control system in the preferred embodiment;

[0121] FIG. 7 is a front view illustrating the mobile application interface screen on the peripheral mobile networked input device for anchor mode of the electronic control system in the preferred embodiment;

[0122] FIG. 8 is a front view illustrating the mobile application interface screen on the peripheral mobile networked input device for anchor live view control mode of the electronic control system in the preferred embodiment;

[0123] FIG. 9 is a front view illustrating the mobile application interface screen on the peripheral mobile networked input device for vector live view control mode of the electronic control system in the preferred embodiment;

[0124] FIG. 10 is a front view illustrating the mobile application interface screen on the peripheral mobile networked input device for route live view control mode of the electronic control system in the preferred embodiment;

[0125] FIG. 11 illustrates a flow diagram of the architecture of the preferred embodiment of an electronic control system of the present invention;

[0126] FIG. 12 illustrates a flow diagram of the architecture of an alternate embodiment of the electronic control system in which a single electronic controller is used for motor thrust, motor steering, motor positioning and motor orientation control;

[0127] FIG. 13 illustrates a flow diagram of the architecture of an alternate embodiment of the electronic control system in which the peripheral input mobile networked device is mounted directly to the thruster and peripheral input device's GNSS sensor is used for motor positioning control;

[0128] FIG. 14 illustrates a flow diagram of the architecture of an alternate embodiment of the electronic control system in which the peripheral input mobile networked device is mounted directly to the thruster and peripheral input device's GNSS sensor and magnetic compass are used for motor positioning and orientation control;

[0129] FIG. 15 illustrates a flow diagram of the architecture of an alternate embodiment of the electronic control system in which the peripheral input mobile networked device is mounted directly to the thruster and peripheral input device's control system is used as the system controller and it's GNSS sensor and magnetic compass are used for motor positioning and orientation control;

[0130] FIG. 16 illustrates the state flow diagram of the preferred embodiment of the present invention;

[0131] FIG. 17 illustrates the electronic controller algorithm software flow diagram of the main functions of the control system of the preferred embodiment of the present invention.

[0132] FIG. 17 through FIG. 30 describe algorithms which implement the preferred embodiment electronic controller.

[0133] FIG. 18 illustrates the electronic controller algorithm software flow diagram of the initialization sequence of the preferred embodiment of the present invention.

[0134] FIG. 19 illustrates the electronic controller algorithm software flow diagram of the heartbeat signal sent from the electronic controller to the peripheral input device in the preferred embodiment of the present invention.

[0135] FIG. 20 illustrates the electronic controller algorithm software flow diagram of sensor data acquisition within the electronic controller in the preferred embodiment of the present invention.

[0136] FIG. 21 illustrates the electronic controller algorithm software flow diagram of the foot pedal reversion or alternative input polling sequence of the preferred embodiment of the present invention.

[0137] FIG. 22 illustrates the electronic controller algorithm software flow diagram of the manual control function of the preferred embodiment of the present invention.

[0138] FIG. 23 illustrates the electronic controller algorithm software flow diagram of the go to function of the preferred embodiment of the present invention.

[0139] FIG. 24 illustrates the electronic controller algorithm software flow diagram of the go from function of the preferred embodiment of the present invention.

[0140] FIG. 25 illustrates the electronic controller algorithm software flow diagram of the route routine function of the preferred embodiment of the present invention.

[0141] FIG. 26 illustrates the mobile application software flow diagram of the application route interface on the peripheral input device function of the preferred embodiment of the present invention.

[0142] FIG. 27 illustrates the electronic controller algorithm software flow diagram of the heading lock function of the preferred embodiment of the present invention.

[0143] FIG. 28 and FIG. 28B illustrates the electronic controller algorithm software flow diagram of the turn control function of the preferred embodiment of the present invention.

[0144] FIG. 29 and FIG. 29B illustrates the electronic controller algorithm software flow diagram of the speed control function of the preferred embodiment of the present invention.

[0145] FIG. 30 illustrates the electronic controller algorithm software flow diagram of the receive command function of the preferred embodiment of the present invention.

[0146] FIG. 31 illustrates the mobile application software flow diagram for the main application function of the preferred embodiment of the present invention.

[0147] FIG. 32 illustrates the mobile application software application pages for the main application of the preferred embodiment of the present invention.

[0148] FIG. 33A, FIG. 33B, FIG. 33C and FIG. 33D illustrate the methodology to implement communication in the mobile application to the electronic controller of the preferred embodiment of the present invention.

[0149] FIG. 34 illustrates the mobile application software algorithm to implement communicating control signals to the electronic controller.

[0150] FIG. 35 illustrates the mobile application software algorithm to access network or cloud data of the preferred embodiment of the present invention.

[0151] FIG. 36 illustrates the mobile application and electronic controller software flow diagram of firmware updates of the preferred embodiment of the present invention.

[0152] FIG. 37 illustrates graphically the algorithm utilized for the go-to function of the preferred embodiment of the present invention.

[0153] FIG. 38 illustrates graphically the algorithm utilized for the go-from function of the preferred embodiment of the present invention.

[0154] FIG. 39 illustrates graphically the algorithm utilized for the routing through points function of the preferred embodiment of the present invention

[0155] FIG. 40 illustrates graphically the algorithm utilized to correct the heading between the measured magnetic pole, and the global reference pole.

[0156] FIG. 41 depicts a graphical view of a preferred embodiment of the overall system architecture of a steerable thruster system according to one or more embodiments shown and described herein.

[0157] FIG. 42 depicts a graphical view of an organization of components in a feature control system that is peripheral input device authenticated according to one or more embodiments shown and described herein.

[0158] FIG. 43 depicts a graphical view of an organization of components in a feature control system that is server authenticated according to one or more embodiments shown and described herein.

[0159] FIG. 44 depicts a graphical view of an organization of components in a feature control system that is peripheral input device authenticated and where a software key resides on an electronic control device according to one or more embodiments shown and described herein.

[0160] FIG. 45 depicts a graphical view of relationships between cloud software components of a feature control system according to one or more embodiments shown and described herein.

[0161] FIG. 46 depicts a graphical view of processes in a feature control system using a software key according to one or more embodiments shown and described herein.

[0162] FIG. 47 depicts a graphical view of a sub-process used for software key acquisition according to one or more embodiments shown and described herein.

[0163] FIG. 48 depicts a graphical view of a sub-process used for determining validity according to one or more embodiments shown and described herein.

[0164] FIG. 49A depicts a graphical view of a sub-process for obtaining a software key according to one or more embodiments shown and described herein.

[0165] FIG. 49B depicts a graphical view of a sub-process for obtaining a software key on an electronic controller according to one or more embodiments shown and described herein.

[0166] FIG. 50 depicts a graphical view of a process of a feature control system utilizing a server based authentication according to one or more embodiments shown and described herein.

[0167] FIG. 51 depicts a graphical view of a sub-process for acquiring authorization in feature control system according to one or more embodiments shown and described herein.

[0168] FIG. 52 depicts a graphical view of a sub-process for acquiring autorization in a feature control system according to one or more embodiments shown and described herein.

[0169] FIG. 53 depicts a graphical view of a process for obtaining a software key according to one or more embodiments shown and described herein.

[0170] FIG. 54 depicts a graphical view of the connection to, and basic hardware of a cloud computing source according to one or more embodiments shown and described herein.

[0171] FIG. 55 depicts a graphical view of a preferred method of operation of a feature control system for an electronically controlled steerable thruster system of a vessel according to one or more embodiments shown and described herein.

DETAILED DESCRIPTION OF THE INVENTION

[0172] Referring to the Figures, several views related to the preferred embodiment of a networked steerable thruster control system are illustrated. The physical device, screen shots of the controlling software application, flow diagrams of the system architecture, and flow diagrams of the application software are included.

[0173] In the preferred embodiment, a steerable thruster control system 10 is utilized to control a trolling motor 22 mounted to the bow of a boat as illustrated in FIG. 1. A mobile or wireless networked device 19 such as a Smartphone or tablet is used as the remote control for the steerable thruster control system as illustrated in FIG. 2. An application (App) based control system is utilized on the mobile app to input commands to the steerable thruster control system. A screen shot from the App is illustrated on the screen of device 19. An electronic controller 11 is utilized to receive remote input signals from the mobile device and to control the heading and speed of the steerable thruster. In this embodiment, the electronic controller stores the current route or waypoint and operational mode. A mobile application remote is used alone or in conjunction with an additional manual controller such as a foot pedal control 23. The mobile device has an integrated wireless system such as Wireless, Bluetooth or other similar system to send input signals to the electronic controller from the mobile device.

[0174] The mobile application is utilized for selection of a single GNSS coordinate point for anchoring or as navigation reference or for creation of a route using multiple GNSS coordinate points. These mobile applications comprise single or multiple online or application based mapping or nautical charting software including but not limited to; Google maps, Satellite imaging, and NOAA charts. The system utilizes mobile or wireless networks to communicate with an online server device for manual or automatic upload and download of information and other data including data and information relative to the control of the steerable thruster. The information and data transferred and stored on the online server device for control of the steerable thruster is in the form of GNSS waypoint coordinates or a series of GNSS coordinates creating a route or other forms capable of establishing a waypoint or route. Additional information or data relative to the waypoints or routes such as, but not limited to, weather (i.e. temperature, pressure, wind speed and direction, cloud cover) or water (depth, temperature, current speed) conditions, boat speed, solunar information, pictures, videos, and notes is transferred to the online server device either manually or automatically. Additional meta data such as weather and water conditions and solunar data is entered manually or automatically collected by the control system from including, but not limited to, online sites, other mobile applications, accessory devices and stored with the route or waypoint.

[0175] The route, waypoint and additional information is sent as individual data or is collected and automatically saved by the system in either a universal or custom file format for transfer into a single file to the online device. It may then be sent individually or collected through a communication network in the form of email, mobile text messages, social media or other networks.

[0176] The system includes a trolling function operable along a curved path by selecting multiple waypoints. The control system automatically creates a curved path such as but not limited to a splined or sinusoidal curve in between or through the chosen points. The electronic controller continuously calculates updated control parameters along a curved path for the steerable thruster.

[0177] The generated curve and trolling path is modified by including, but not limited to, dragging or moving the original points and or modifying the parameters of the shaped route such as, but not limited to, the amplitude and frequency of the sinusoidal curve.

[0178] The electronic control system for a steerable thruster comprises of a mobile networked peripheral input device, a mobile application (App) installed on a mobile networked device, and an electronic control unit and multiple sensors. The mobile networked device, in the form of a smartphone or tablet, functions as a remote control and input device. The electronic control unit is utilized for controlling the speed and heading of a steerable thruster based on mode and target values from the input device. Sensors that are utilized in this arrangement include GPS, a form of GNSS, and magnetic compass. In this embodiment, the steerable thruster is a bow mount electrically steered trolling motor.

[0179] In this embodiment, the control system comprises an application installed on the mobile device sending input signals and commands to an electronic controller device which detects and controls the heading of the steerable thruster. The electronic control module in this embodiment is wired directly to the steerable thruster via a cable in line with an existing input device (i.e. the foot pedal or other input device already belonging to the motor) to control the speed and heading. Conventional controllers already belonging to the motor include a foot pedal 23 and handheld remote. The electronic controller may be placed either in between the conventional controller and the steerable thruster's existing control board or be used in place of the conventional controller, though not recommended. The conventional controller may still be used to provide commands to the thruster that can override the claimed electronic controller for operator safety and/or convenience.

[0180] The heading of the vessel is determined via use of a compass mounted on the steerable thruster. The heading information is communicated to the App. Communication between the input device and electronic controller provide the control signals for the controller and additionally provide feedback from the electronic controller to the input device. The input device is used to set the mode of operation and send control commands to the electronic controller through electronic serial software commands. In this embodiment, the user may choose between manual, anchor, vector, and routes modes. A corresponding App screen is illustrated in FIG. 6 in Manual mode wherein the user can touch the screen to activate functions such as turning the motor to the left or right or to adjust the thrust. The electronic controller processes control commands and sensor data through use of algorithms to vary the outputs to change the direction or vary the speed of the thruster or both, and sense the current state of the motor. Actuation commands are sent to the thruster via serial commands or discrete electronic commands such as ground/open/high or analog level, depending on the existing architecture of the steerable thruster being controlled. FIG. 7 illustrates a sample screen in Anchor mode to instruct the trolling motor to maintain the current position or to move to a preloaded anchor point a user chooses by selection from the screen as illustrated in FIG. 8.

[0181] Configuration 1 represents a preferred embodiment and is illustrated in FIG. 11. In this configuration, the electronic controller includes a GPS position receiver device, a direction sensing device, and the necessary control for the algorithms and the outputs. The required circuitry to enable the invention in the preferred embodiment includes a power source, which is capable of providing power to the microcontroller, sensors, communications devices and the output controls. This power source is implemented as being able to condition a full range of input power typical of electric trolling motors, which include voltage levels from 12 up to 36 volts direct current. This is implemented as a step-down power supply to provide a constant 5 volts DC to run the necessary devices for operation. To accommodate the wide input range, a buck mode switching supply has been implemented. In the preferred embodiment, the electronic controller actuates the control inputs on the motor controller. To implement, electronic switches have been utilized providing a grounding control signal when a turn or enabling signal is required, and by utilizing a filtered pulse width modulated (PWM) signal to provide a speed control signal to the motor controller. This implementation is limited to one applicable interfaced product; however, by activating the control signals in any form, whether serially, wirelessly or by a control signal, many other configurations can be realized.

[0182] The peripheral Input Device includes the application and the user input. In this configuration, residing in the electronic controller are the position sensing and directional information. Not all components shown in the Figures are required for the minimum configuration but are illustrated for reference of location in the preferred embodiment.

[0183] Any data or information collected by the system or retrieved via network connection that can be physically associated with points or routes is stored with the route or waypoint and automatically saved by the system in either a universal or custom file format such as XML, JSON or CSV for transfer into a single file to the online device. In some embodiments, the system has the ability to collect and or obtain data described, either in real time or from a database source, and would perform the function of attaching gathered data to the physical location (i.e. coordinates, points, and routes) at which said data is relevant. Once the location information is paired with other collected data, the composite result could then be saved and stored as a new data set in either a universal or customer file format. The composite result may be stored on the mobile device or online on a virtual server to preserve space and memory on the mobile device. In some embodiments, the mobile device caches certain data for remote access or access any of the non-cached data real-time time via a network connection in order to display this data in various ways. The benefit of this approach is that large amounts of gathered data are conveniently associated with a physical location in the form of a unique route or point and can be used for navigation via the steerable thruster.

[0184] Networks utilized for connectivity to the server or for cloud computing includes cellular networks such as GSM, 3G, 4G, and LTE.

[0185] The collection of data and information saved with the route in a universal or custom file format may be sent as a single file through an electronic communication network, such as but not limited to, email, mobile text messages, and social media networks. Data may be saved in a relational database (examples include MySQL, PostgreSQL, MySQL) in a custom or universal file format or saved in memory. The data and information related to the route as referred to above would be shared by sending through an electronic communication network, such as but not limited to email, mobile text messages, and social media networks.

[0186] The individual data or collected information of a recognized format may be sent or shared through communication networks of the compatible mobile application of another user and could likewise be utilized by their respective control system. This sharing is via HTTP Based Request. HTTP requests are sent per API guidelines and can be saved to web DB from any device. HTTP responses are formatted in a way that can be recognized and saved to local DB no matter what device it is sent from.

[0187] In a preferred embodiment the electronic controller is housed inside an enclosure (FIG. 4) and mounted to the shaft 21 of the bow mount trolling motor below the motor head 20. The enclosure 11 may have a fixator, illustrated in FIG. 2 and FIG. 4, in the form of a clamping mechanism 12 to clamp the enclosure to the shaft 21 to fix alignment between the electronic controller, housed inside the enclosure 11, and the thrust motor 22. In this embodiment the clamping opens similar to a clam shell wherein each half of the clamp moves about a pivot joint. A thumb screw 13 tightens and secures the clamping mechanism about the shaft 21. Fixed alignment between the controller and thruster ensures accurate directional heading as the electronic controller automatically determines thruster heading from alignment with the electronic compass. The clamp mechanism 12 may use a tool less mounting method such as a thumb screw 13 for attachment to the shaft.

[0188] Electrical connection to the system is achieved through a connection in-line between the foot pedal 23, and the trolling motor controller, utilizing connectors 15 and 17, and a junction box 16. Power is connected to the vessel through a wire 14. Signals and power are routed to the controller 11 through a cable 18. Connectors 15 and 17 in this embodiment are commonly used connectors which are matched to interface to the existing motor. The cable is a type which is watertight and has sufficient ratings to carry the signal currents and withstand the signal and power voltages. The junction box contains signal routing between the connectors and a wide input voltage range power supply to condition the power to that which is usable by the control electronics. The input is capable of voltages typical of electric trolling motors and vehicles which here is 12 volts but typically ranges between 12 and 36 volts.

[0189] In a preferred embodiment, the electronic controller is controlled by a peripheral input device such as a mobile phone smartphone with a touch screen display. An application (App) loaded on the smartphone provides portable operation of the control system as the user moves about the boat. From this application, a variety of functions such as manual control of the motor speed thrust and direction and an overview of the location and available anchor points and routes using the map views are available as the user interfaces with the smartphone application.

[0190] In preferred embodiments a foot pedal controller 23 is used in conjunction with the smartphone or tablet to control the electronic controller. The foot pedal may be used to abort autopilot mode or to work in conjunction with autopilot mode. As a safety feature the foot pedal may be used to abort the mobile device auto pilot mode by activating any control on the foot pedal including direction or speed changes. As an alternate control the foot pedal works simultaneously with the mobile device to make adjustments to autopilot or manual modes. It may also be used to make speed or direction changes in manual mode or change an autopilot function such as vector heading or vector speed. The foot pedal may also be used by the control system to execute certain autopilot functions such as a double tap of a foot pedal to set the autopilot anchor. In another embodiment a small remote configured for mounting to a fishing rod may be used in conjunction or in replacement of the manual foot pedal to provide added versatility to the operator.

[0191] In another embodiment, a tablet or remote touchscreen computing device is utilized for control and provides the benefit of large screen display of mapping or other functions. The tablet provides portability as the user moves about the boat or may be mounted in one location as a display.

[0192] In a preferred embodiment, the peripheral input device(s) such as the smartphone, tablet or others aforementioned preferably have built in storage capabilities such as flash, ROM, RAM, EEPROM or expandable memory capability such as SD, Micro SD, or hard disk. This may be used for storage of routes, waypoints, maps or other information related to the control of the trolling motor control system. By utilizing a current mobile device the storage capability for routes and waypoints is nearly unlimited for the average user. This storage can be used for caching of maps, routes, anchor points in the event the user plans to operate in an area without global network connectivity. This data may be downloaded to the device prior to entering an area without connectivity. If the mobile device encounters memory limits for storage of all the data such as maps, routes or anchor points for all areas or locations a user wants to access, the user could select an area of interest and the system could either automatically or manually selectively load the aforementioned data from the virtual/network/cloud source for these areas.

[0193] The user may utilize an automatic update of the peripheral device's memory of data based on current location, as determined by the mobile device's GPS, to automatically update the memory with data from the cloud around a set radial distance, or geographically similar area from the current location. Storage on the mobile device may be utilized for storage of all data such as anchor points and routes and cached maps required for full functionality of the operating system. This method assumes the amount of storage on the device is sufficient and there is either no desire by the user to connect to an internet cloud or the internet cloud is not available because of the lack of a mobile or wireless network in some locations or the inability to access a mobile or wireless network. These embodiments may be used in any combination for storage of data on the peripheral input device.

[0194] To enable this invention, an electronic controller is described, having algorithms that have been developed to provide the necessary control to achieve the desired architecture and functionality. These algorithms are provided as programmable embedded firmware located within the electronic controller in an on-board Microcontroller, Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), or other programmable memory capable of execution. The algorithms described herein are set up to provide the minimum required control, and can be expanded to enhance control where described.

[0195] The electronic controller of the embodiment illustrated here receives a command message from the peripheral input device and stores the information for use in the control algorithms. Stored in memory on the electronic controller are several pieces of information including the current operating mode that determines a specified control loop for device operation.

[0196] Some embodiments include a first mode to operate in a GNSS position hold function (anchor) to hold the current point. This function operates by acquiring the positional data at the time of selecting the hold position command, and actuating the control outputs to turn and power thrust the motor as needed thereby holding the vessel in a generally fixed location on the body of water. Alternatively, the hold function may receive a set of coordinate points for the command message to use as target coordinates. As yet another alternative, a command to move the vessel in a direction by a predetermined distance is another function of GNSS position holding. This function is useful for anchoring a boat in a location without the use of traditional anchoring provisions such as an anchor, rope, chain, etc.

[0197] Some embodiments also include an operational second mode utilizing a GNSS direction hold function or vector over coordinates. This function creates a vector away from the current point using starting position, current position and direction. This function does not require a point to be targeted as moving toward, but instead uses the initial starting point and directs the vector, calculating at each sample the error associated relative to a lateral permissible dead-band, where adjustment is not required along the vector desired. Directing away from the point allows for simplistic control, as additional points do not need to be created arbitrarily along the vector. To calculate the deviation from the desired vector, trigonometry is used, where a value for the maximum permissible heading angle is calculated, based on the distance from the original set-point. Additionally, virtual points can be added a predetermined distance from the thruster. This is done by choosing coordinates ahead of the current point, and navigating to each point by turning the steerable thruster to the location along the path.

[0198] Some embodiments comprise a third mode function utilizing a Magnetic Heading hold function (heading lock) which utilizes the direction device in the electronic controller to maintain the direction of thrust, and would allow for deviation from a vector as is described above in the second mode.

[0199] Various embodiments may include a fourth mode that can be navigating along a user defined/preplanned route, as the App on the mobile networked peripheral input device may have capability to display a map, and thus provide a method for which the user can create a route. With a route consisting of points to traverse, the control system utilizes any one or combination of the GNSS go-from point (vector direction hold from start), as described in the second mode, or the GNSS go-to point (control to next point), as described in the first mode, or both. An example of sharing the go-to and go-from modes is as follows: Point # n is received and is targeted as a go-to point; Point # n+1 is received, and cued for go-from. Once within a pre-defined circle radius, a go-from is calculated by creating the heading between n and n+1, and a go-from point n is performed, directed to point n+1. Once a second radius or a threshold is reached relative to point n+1, the mode changes again to go-to, and the point is targeted, and point n+2 is cued. The process then repeats.

[0200] The electronic controller also embodies a feature to provide manual control of speed up, speed down, turn left, turn right, and motor permitting to operate, by commands received from the peripheral input device. With manual control it may be desirable to also use a manual control device separate from the peripheral input device. The manual control devices may be a foot petal or handheld remote for example. The devices may be wired or wireless or a combination of the two.

[0201] For all modes, the electronic controller may store at minimum 1 point for control, and store up to the entire route or multiple routes of points information. The controller handles the messages using a few different methods in order to send successive commands. In one configuration: The message is transmitted to the electronic controller from the peripheral input device and is configured such that once the message has been verified as received the peripheral input device no longer is required to continue sending the data. The electronic controller maintains the last command. This can be used to set a command. It also allows for the peripheral input device to be powered down or the connection link severed or both while the electronic controller maintains its control function. In a second configuration: The message is continually transmitted to the electronic controller from the peripheral input device and the electronic controller determines whether to store the new information. The electronic controller may also determine to go to a safe mode in the event of control severance identified by loss of receiving data.

[0202] FIG. 17 describes the overall program architecture of the electronic controller of the preferred embodiment. While the software described herein is representation of method for the implementation of the overall system, other methods of implementation may be devised from both a global architecture and from individual routines. Within this controller embodiment, a routine initializes as shown in FIG. 18, then repeatedly loops as in FIG. 17. The electronic controller acquires commands from the peripheral input device, sensor data, and optionally alternative inputs such as the described foot-pedal control. The system then selects the motion control and speed algorithm, providing the control signals to the motor control part of the system, and provides feedback data as shown in FIG. 19 to the peripheral input device. Within this system, a series of data registers are available for storing the information relative to the control of the vessel. Upon start-up of the system, initialization is performed to enable the various sensors and to set up communication to the peripheral input device.

[0203] FIG. 20 describes the acquisition of sensor data of the preferred embodiment. Information acquired through use of commercially available sensors is decoded by the processor and placed into registers for global use by the algorithm. Position determination is acquired through the use of a GNSS receiver, and transmitted serially to the processor. The processor parses the information, and stores the received data in the position registers. The orientation is determined through use of the magnetic compass described herein. Due to the nature of magnetic heading sensing, the sensor may require calibration due to factors outside of the user's control. For use in the embodied algorithms, the position is based upon latitude and longitudinal coordinates, and the orientation is based upon the measured magnetic direction. The mapping direction for control desired to be calculated is relative to global direction based upon position of the controller on the globe. Due to the location of the magnetic pole not being fixed over the long term, and not being fixed at true north, the current location of the magnetic pole can be updated from the networked/web service, and an adjustment can be applied to the magnetic heading to give a global heading to the true north pole. A graphic example is shown in FIG. 40.

[0204] FIG. 21 describes the method for determining changes from the alternative input, such as a foot pedal, and describes how the system reads and interacts with the alternate input system. To achieve integrating the alternative input to the overall control system, an initial state of the alternative input is determined when a new control is actuated, and the state of the alternative input is monitored while under any of the modes of control.

[0205] FIG. 22 describes operation for manual control. In order to enable this feature, inputs are received from the peripheral input device then processed to provide the output directly to the motor control system. To prevent out of range or impossible values for the motor controller, limits such as a maximum motor speed are imposed. The resulting signals are sent to the motor control, whether through discrete actuation of signals, by providing an analog level for the motor controller, or alternatively, through the use of a serial bus, and dedicated signals.

[0206] To enable the automatic motion control, two primary modes have been conceived to achieve the desired motion path for thruster angle, and the speed is varied depending on the selected mode of operation of the thruster (manual, anchor, vector, routes). Anchor control uses the Go-To algorithm, as described in FIG. 23, whereas Vector control uses the Go-From algorithm, as described in FIG. 24. When using a route of multiple points, the electronic controller is enabled to navigate from one to another by utilizing the Go-To and Go-From motion algorithms as described in FIG. 25.

[0207] To further describe the go-to algorithm, the controller will first determine the go-to point, by either selecting the current point, or a defined point received from the peripheral input device. This point is then stored in the control register for navigation. The controller will then receive position data and perform error calculation from the control point, based on spherical distance on the earth, and heading calculated using the haversine formula. Based upon the error calculated, the controller will activate the thruster turn circuitry to point the motor thrust in the direction of the control point. FIG. 37 shows a graphic depiction of the control regions described in the software flow diagram of FIG. 23.

[0208] Describing further the go-from mode, the differences from the go-to mode must be understood. Whereas go-to utilizes a control point being targeted as moving toward (at any heading), the go-from mode, utilizes an initial point (control point), and utilizes a direction to be targeted to be moving in. This enables a few desirable control performance aspects. One, by moving away from a single point, multiple points along a straight path do not need to be calculated in order to track a particular direction. To achieve this result, the basic control parameters of the algorithm must be understood and described as to how they influence the control output. FIG. 24 describes the software flow of the algorithm, and FIG. 38 shows a graphic depicting the control from a particular control point. When the go-from mode is first enabled, the electronic controller determines its location, and stores in memory the control point or starting point. The controller then directs the thruster in the control/desired direction and calculates the positional difference between the control point and the currently sensed position from GNSS. As a part of the control algorithm, a dead-band around the desired heading is established, the lateral error is calculated, and the electronic controller calculates where it is relative to the desired heading based upon a trigonometric calculation. Of the parameters available, knowing the distance between the control point and the current point, the heading angle from the control to the current point, and the desired heading angle, the electronic controller can calculate the lateral error, by using a sine function, where (lateral error)=sine (desiredactual heading)*(distance from control to current point). A few things must be appreciated to realize the relationships between the control parameters. As the distance grows very large, the heading angle error becomes very small for the same lateral error. At small distances, it should be noted that the angle will change very quickly relative to position change. This is addressed by utilizing the dead-band width, and when the system is within this range, the electronic controller reverts to using only the electronic compass until the controller is outside of this window.

[0209] FIGS. 25 and 26 show the software flow of the routing mode, and FIG. 39 shows a graphical depiction of navigating a route. To implement a route in the described control system, it is desirable to minimize the data required to be stored in the control system. This allows for longer routes (more points) since the control system can access the points on a device having much higher capability. An example is the peripheral input device when in the form of a smart-phone or a tablet computer. To describe the parameters of interest in the controller, the target point is described as the point which the controller is actively using for control. The queued point is described as the next point in the route, and the second queued point is the point thereafter. Each point in a route has a sequential unique number associated with it. Each point has associated with it a region surrounding it at which the control system will make adjustments and which determine the mode for which the controller operates. To implement the control system, the peripheral input device sends a command to start a route, and provides the first point for control. The electronic controller begins navigation to this point using the go-to function, and broadcasts to the peripheral input device the control point, and the queued point, which is established on the first run as the same as the control point. The application running on the peripheral input device reads the control and queued points, and when they are detected as being equal, will send the next point, setting it up in the queue. To transfer control to a different point, the electronic controller detects the position relative to a control point, and changes modes. When approaching a point, the controller will change to go-to mode, and navigate to the point. Once the point is reached, noted by a minimum distance to achieve, the controller switches modes to go-from, and calculates a desired heading based on the heading between the control point reached, and the next point in the route. The controller then navigates using the go-from setting, until it reaches a threshold, either a distance from a point, or by crossing a threshold line calculated by determining the heading from the queued point to the current location. Once the threshold is reached, the controller increments the control point to being the queued point, and changes mode to go-to, if within the threshold distance (circle C), or on the outside of the curve (shown as region E), If in region F, the controller would switch to go-from mode and navigate toward the subsequent point. This process then repeats for all points in the route. At the end of the route, the control system would stop navigation, and indicate to the user that the route has been completed.

[0210] In addition to providing a vectored direction, as is provided in the go-from mode of operation, a function to hold a particular direction of the thruster is also implemented, as is shown in FIG. 27. This will enable the user to hold a heading for the thruster, and allow external influence of wind, waves and currents to permit drift in the direction held.

[0211] FIGS. 29 and 29B describe the speed control. Because of the several modes using the go-to and go-from control algorithms, different speed profiles may be desired for different uses. For instance, as can be seen in the anchor mode of the application, the go-to algorithm is used, and the speed control is performed to stop the vessel once in the window. Alternatively, the routes mode will also utilize the go-to algorithm, however, will maintain a speed through the point, shifting modes once the point has been reached. For this application, 3 modes of operation for speed are desired. In one, the speed control is performed by setting the thrust. In the second, the speed is set based upon an anchoring point. In the third, the speed is controlled based upon feedback from the GNSS system. In this mode, the error is calculated and a control signal is generated based upon controller gain settings. In one form, a proportional control is used, where the changes to the control signal are proportional to the speed error. In a dynamic system such as a boat with the steerable thruster, this may not be sufficient, as the momentum of the boat can cause the control system to overshoot the target point. To address these shortcomings, additional gain parameters can be introduced. This may include integral control, which will accumulate error, and increase the accordingly. For example, if low velocity error has existed for a period of time, the integral controller will increase the thrusting output to compensate, thus reducing the error by increasing the speed. Additionally, derivative control can be implemented, which will calculate the changes to the error, and with rapid changes, will produce a control signal accordingly. For example, if the speed is increasing quickly, an overshoot of the speed target may be imminent due to inertia in the system. To compensate, derivative control can be used to reduce the control, and thus slow down the speed increase. These additional gains are desired to prevent overshoot of the control, as well as prevent oscillations in the system. In the system, a control speed is calculated based upon the thrust in the expected direction. In some cases, the thruster has not yet achieved the desired heading, and thrust contrary to that heading may cause instability in the system leading to oscillations and turn overshoot. To compensate for this, the control speed is reduced relative to the thruster angular error and control mode. An example of this would be where the speed is reduced to no thrust at 90 degrees to the target direction, and is increased to 100 percent thrust to be maintained within a dead band surrounding the target direction.

[0212] A strong connection between the peripheral input device and the electronic controller ensures integrity of the link. FIG. 30 describes the receive command of the electronic controller. New messages are not received continuously because the architecture uses the last known command, thus the electronic controller only parses a command when there is a new message present from the peripheral input device. Once it is recognized that a message is present, the message is stored to a buffer, and a checksum or hashing operation is performed. The calculated value is then compared against the received checksum or hashing value and determined whether the message that has been received is valid. Once determined to be valid, the message is parsed into its components, including one or more of the following: control mode, target latitude, target longitude, target speed, target direction and control speed mode. The controller then provides a flag to the system that a new message is present, and to act on it. For example, if an anchor is commanded, the electronic controller would save the current latitude and longitude to the command register, and would begin controlling the go-to function to the command point, and the speed control function to the anchor mode.

[0213] As a separate software routine from the electronic controller, the application running on the peripheral input device performs a specified set of tasks in order to enable the invention disclosed. In the preferred embodiment, this is an application running on a smartphone or tablet computer. FIG. 31 shows the high level program sections for the application, which perform the tasks of the peripheral input device, and FIG. 32 shows the included functions on each of the specific pages of the application, which are shown in FIG. 6 through FIG. 10.

[0214] To implement control, a communication medium is required. In the preferred embodiment shown, Bluetooth communication was established to accomplish this task for the communication technology, of which four modes of operation are shown in FIGS. 33A, 33B, 33C and 33D, illustrating multiple types of communication strategy (Bluetooth 2.1 versus Bluetooth 4.0). In addition to the physical layer of Bluetooth communication, a strategy for control from the application to the electronic controller is implemented, and shown in FIG. 34. This strategy utilizes the feedback from the electronic controller through the use of its heartbeat, and continues to send the command message until the desired mode of operation is implemented, and broadcast to the peripheral input device.

[0215] To implement the sharing aspects of the device, a method to read and write to an online database was developed, and is described in FIG. 35. This method utilizes a token system and a login to gain secure access to a user's cloud network information. To transfer data an HTTP request is used to transport the information from the cloud to the user, and vice-versa.

[0216] With the connection to a global network, the ability to upgrade the application is possible, and additionally, a method can be utilized to upgrade the firmware of the electronic controller, which can now be enabled as an interface connection is available. FIG. 36 illustrates this capability, and a method to implement, by use of the Bluetooth connection in the preferred embodiment. The system can be configured to automatically determine whether the firmware is up-to-date by comparison of the version numbers with the current release of firmware, or manually selected to update the firmware. The ability to update firmware is most desirable, as this allows changes to the algorithms, refinement of gains, and fixing of software bugs all while the electronic controller is in its installed location.

[0217] Methods for use or operation of the system may be manifested in a variety of forms drawing from the numerous disclosures and alternative disclosures described herein. Steps within a particular method example may be reordered. One example of a method for use of one embodiment of the control system is now described. The method comprises the steps of the user establishing a form of control application described herein on a smartphone or tablet as previously disclosed. A connection between the smartphone and the electronic controller is established wirelessly, and the user may provide manual inputs in the application, actuating for example a turn command, or increasing the speed of the thruster. The user may then achieve a desired location for fishing, and actuate the anchor function in the application of the control system. The electronic controller would operate in the go-to command state, and anchor speed mode. The electronic controller would automatically maintain the global position, based on the GNSS data from the position sensor, and when adjustment is needed, use the direction device to direct the thrust in the proper direction. The outputs to the thruster would be actuated to provide the proper heading and thrust level to maintain the control parameters.

[0218] Another example of a method the user may use is creation of a route. For this application, creation of the route is aided by the use of maps or chart-plotting capabilities. When a network exists, the user would navigate the maps, which would be downloaded as they are being used for reference navigation. If a network were not available, the user may have maps locally cached, by pre-planning their trip, and obtaining the specific geographic areas being used. Once control data has been established for the route, the user would commence the route, and the electronic controller and peripheral input device would provide the automatic navigation. To achieve the navigation, the electronic controller indicates the points at which it is controlling to, and the peripheral input device monitors. When a control point has been reached, the peripheral input device would send the next point in the route for navigation control.

[0219] In the above methods, the user may find the anchor location favorable, or the route productive, and may save the control point. The saving would occur locally, when no network exists, and when a network exists, it would also sync the control point information to a cloud network server. With the data in a cloud location, the user may analyze the information at a later time, or, may send the information to another user, by providing the second user a key to obtain the information.

[0220] The control system for a steerable thrusting device comprises in some embodiments a feature control system (FCS) 51 for alternately enabling and disabling (locking and unlocking) premium features of the steerable thrusting device control system 10. The FCS utilizes software keys, that are transferred through the use of the networked system. A software key 66 is a unique identifying key, typically generated by a hosting service or as a result of a transaction event. Software keys are sometimes referred to as an authorization key or unlock key.

[0221] In a basic form, the FCS 51 utilizes a data connection between a system user (i.e. a customer), and a server hosted on the global internet using the global internet as a connection medium. Utilizing the FCS provides for premium features of the control system for a steerable thrusting device to be enabled for users by the use of specific software or software keys without the requirement of different hardware or hardware updates.

[0222] A feature control system (FCS) may be based on a plurality of methods operable to provide features of the control system for a steerable thrusting device to be enabled or disabled for a discrete user of the system. In one embodiment of a FCS method, provisions are embedded in the hardware that enable/disable the use of the features through a software key 66. Utilizing this method, a connection is established to the global network to download a key generated when a transaction event occurs (i.e credit card payment, coupon). The transaction event (an event where exchange of goods or services occur) may automatically generate the key as a result of a payment or a coupon being processed, or may be generated manually and sent to the system user. In some embodiments, the software key is perpetual in that there is not defined expiration for the key, or alternatively, the software key could expire after a period of time. In one embodiment, the software determines the time based on the system clock (in the preferred embodiment, the clock of the mobile device) to acquire the current time for use with a time expiration mode, or alternatively the time could be acquired from a GNSS signal. In any time-based validation of the software key, the FCS could be exploited to set a different time for the system clock. In the preferred embodiment, this could be abated through the use of the GNSS signal, as the system requires accurate timing to properly determine the location, thus, if the GNSS signal were faked, the system would not behave as intended, thus defeating the purpose of spoofing the signal. In the preferred embodiment, the time validation using GNSS resides in the hardware portion of the system.

[0223] The software key in preferred embodiments is stored and used locally by the system user. In the preferred embodiment, the hardware would determine if a valid key existed, and if so, would provide authorization to the program to execute. In various embodiments of control systems for steerable thrusting devices, one or combination of unlockable features may be included. Examples of individual features or combination of features available to be enabled include: any GPS related control, specific GPS, mapping operations, cloud storage, gain determination from field acquired data, aggregated data useable for data analytics to set gain and for system optimization, automatic gain adjustments, boat size and type data gathering, and external cloud/global network based data conditions related to such factors as weather and tides.

[0224] FIG. 41 illustrates a general description of a preferred embodiment of the overall architecture of a steerable thruster control system 10B as disclosed earlier with steerable thruster 22B. A peripheral input device 19B that is a mobile networked device utilizes a global network link 30B to connect to the global network 32b otherwise known as the cloud. In addition, the peripheral input device 19B is connected using a wired or wireless link 34B to electronic control device 11B. Electronic control device 11B is powered in most cases by battery or equivalent power source 36B such as a power system on a vessel. In some embodiments, electronic control device 11B utilizes input from a foot operated control 38C. A wired or wireless connection 40B links the electronic control device 11B to steerable thruster 22B for the transfer of control signals.

[0225] FIG. 42 illustrates one embodiment of an organization of components in a feature control system 51C that is peripheral input device authenticated whereby a software key 66C resides on the peripheral input device 19C and is activated through the cloud 32C. Operating through the cloud 32C is a server based user data and account information 54C module associated with a particular user. This data may include for example routes and waypoint data associated with a particular user and available to the user at virtually any time. A complementary client based user data and account information 72C module is stored on a peripheral input device 19C used in the system. In this embodiment, the client based and server based user data accounts 54C, 72C maintain copies of each other through the cloud 32C. Server based login/authentication 50C module communicates through the cloud 32C with client based login/authentication module 58C for user authentication 64C to verify the user attempting to log in the system should be granted access.

[0226] A peripheral input device 19C based authorization service 60C module communicates through the cloud 32C with a server based payment and coupon processing 52C module to authorize use of premium features in the system. Once payments or coupons or both are provided by the user through the PID 19C based authorization service 60C, the payments/coupon is processed in a server based payment and coupon processing 52C module after which an authorization token 62C is sent back to the PID 19C whereby a software key 66C module on the PID 19C is activated. A user system functions 76C module on the PID 19C is then activated to provide access for use of select unlockable features of the system. A cloud communication module 70C, and a global network communication module 68C located on the PID 19C are utilized to communicate through the internet and the cloud. A PID 19C based local communication to the electronic controller 74C module is utilized to provide wired or wireless communication with the electronic control device 110 as needed for activation of new features as they are purchased. Also available through the cloud 32C are system and firmware update files 56C to provide the latest software updates to the system.

[0227] FIG. 43 illustrates one embodiment of an organization of components in a feature control system 51D that is server authenticated whereby a software key 66D is transferred through the cloud 32D to the peripheral input device 19D for activation of select features. Unlike the previous peripheral input device authentication, in this embodiment the user uses a client based login and authentication 58D module which communicates through the cloud 32D with a server based login and authentication 50D module for user authentication 64D to verify the user attempting to log in the system should be granted access. Operating through the cloud 32D is a server based user data and account information 54D module associated with a particular user. This data may include for example routes and waypoint data associated with a particular user and available to the user at virtually any time. A complementary client based user data and account information 72D module is stored and operates on peripheral input device 19D. In this embodiment (FIG. 43), the client based and server based user data accounts maintain copies of each other through the cloud 32D.

[0228] As illustrated, an authorization service 60D module communicates through the cloud 32D with a server based payment and coupon processing 52C module to authorize use of premium features in the system. Once payments or coupons or both are provided by the user, the payments/coupon is processed in a server based payment and coupon processing 52D module after which authorization service 60D releases software key 66D to the PID 19D. A user system functions 76D module on the PID 19D is then activated to provide access for use of select features of the system. A cloud communication module 70D, and a global network communication module 68D located on the PID 19D are utilized to communicate through the internet and the cloud. A PID 19D based local communication to the electronic controller 74D module is utilized to provide wired or wireless communication with the electronic control device 11D as needed for activation of new features as they are purchased. Also available through the cloud 32D are system and firmware update files 56D to provide the latest software updates to the system.

[0229] FIG. 44 illustrates one embodiment of an organization of components in a feature control system 51E that is also peripheral input device authenticated but whereby a software key 66E resides on the electronic control device 11E and is activated through the cloud 32E. Operating through the cloud 32E is a server based user data account information 54E module associated with a particular user. This data may include for example routes and waypoint data associated with a particular user and available to the user at virtually any time. A complementary client based user data and account information 72E module is stored on a peripheral input device 19E used in the system. In this embodiment, the client based and server based user data accounts maintain copies of each other through the cloud 32E. Server based login/authentication 50E module communicates through the cloud 32E with PID 19E based login/authentication module 58E for user authentication 64E to verify the user attempting to log in the system should be granted access.

[0230] An electronic control device 11E based authorization service 60E module communicates through wired or wireless link 34E and through PID 19E to provide authentication 64E through cloud 32E with a server based payment and coupon processing 52E module to authorize use of premium features in the system. Once payments or coupons or both are provided by the user, the payments/coupon is processed in a server based payment and coupon processing 52E module after which an authorization token 62E is sent back to the PID 19E and then through wired or wireless link 34E to the electronic control device 11E whereby a software key 66E module is activated to in turn activate a user system functions 76E module on the PID 19E to provide access for use of select features of the system. A cloud communication module 70E, and a global network communication module 68E located on the PID 19E are utilized to communicate through the internet and the cloud. A PID 19E based local communication to the electronic controller 74E module is utilized to provide wired or wireless communication 34E with the electronic control device 11E as needed for activation of new features as they are purchased. Also available through the cloud 32E are system and firmware update files 56E to provide the latest software updates to the system. Other modules on the electronic control device 11E include communication 80E, sensors 78E, processor 76E, and outputs 82E. The processor 76E determines available functions provided by the FCS through the authorization service 60E by enabling a boolean to be enabled based upon a valid software key 66E. When a valid software key 66E exists, the processor will allow processing of functions received from communication 80E, and cause the Outputs 82E to provide the enabled feature to be exercised.

[0231] FIG. 45 illustrates an architecture embodiment of the relationships with different software modules in the feature control system and represents software interactions while FIGS. 41-44 illustrate device level embodiments. The software processes described are managed by a main process 89F, which accesses an authorization service 60F which utilizes a payment or coupon processing service 52F. Additionally, main process 89F accesses a database access server 54F, which accesses a database 55F, with regards to proper authorization. Additionally, the main process 89F accesses an action process 88F, which enables an output to occur based on proper authorization. The main process 89F also will access an input process 87F which allows for specific inputs based on proper authorization. The processes described may be distributed throughout the overall system, as described in FIGS. 41 through 44. While each embodiment shows the processes occurring on specific pieces of hardware, the processes can be distributed throughout the system, as the devices are communicatively coupled, and can share information through the cloud. So although the main process may reside on a PID for example, other process components in the relationship may reside elsewhere yet still cooperate through the cloud. The electronic control systems described in FIGS. 11 to 15 are equipped in some embodiments with a Feature Control system (FCS). Processes in the various FCS software modules are processed on hardware components of the electronic control systems. Each hardware component contains at minimum a processor with firmware configured to run the software modules as they are distributed with communication between the hardware components and memory. Additionally, the components may also include sensors, display or indication devices, input means for user interaction, software applications and output means to provide an action for the system to take.

[0232] FIG. 46 illustrates one embodiment of a software algorithm of a feature control system utilizing a software key to activate features. The process is started (90C). A user starts a service (such as Login/authentication service) on their peripheral input device (step 92C). The user then provides input through their PID requesting use of a desired unlockable feature (94C). A process determines whether the unlockable feature requires uses of a software key (96C). If the feature does not require unlocking, the user proceeds with use of the function (98C). If the feature requires unlocking, a sub-process is initiated to determine validity (100C) of the software key. If the sub-process determines the software key is invalid, the user may proceed with the function remaining disabled (104C). If the sub-process determines the software key is valid (100C) a process is run to determine if a valid software key license exists (102C), if so, the user may once again proceed with use of the function (98C). If the sub-process determines the software key is valid, and a process determines a valid software license key does not exist (102C), a process is run to ask the user whether they would like to obtain a valid software key (106C). If the user does not wish to obtain a valid software key, they once again may proceed with the function disabled (104C). If the user does wish to obtain a valid software key (106C), a sub-process begins for key acquisition (108C) whereas at this step the user is reverted back to to a process determining whether a valid software license key exists (102C).

[0233] FIG. 47 illustrates one embodiment of a key acquisition sub-process (108C) as used in the algorithm of FIG. 46 whereby each step is identified as C. FIG. 47 also illustrates one embodiment of a key acquisition sub-process (108E) as used in the algorithm of FIG. 53 whereby each step is identified as E. The key acquisition sub process is started at step 110C, 110E. Next a process to establish a connection between the PID and the server (112C, 112E) is used. The user logs into their account and a process providing an authentication token is provided to the server (114C, 114E). The system checks whether a valid license exists for the user (116C, 116E). If the process determines a valid license does not exist, the user is prompted for payment or coupon in exchange for a valid license (118C, 118E) which afterwards a license key file or value is sent from the server to the user peripheral input device (120C, 120E). If the process determines a valid license already exists, a license key file or value is sent from the server to the user peripheral input device (120C, 120E). The process continues (122C, E) as illustrated respectively in FIG. 46 and FIG. 53.

[0234] FIG. 48 illustrates one embodiment of a determine validity sub-process (100C) as used in the algorithm of FIG. 46. The determine validity sub-process is started at step 120C. The authorization service is started (122C) and the user is checked if they are logged in (124C). If the user is not logged in, they are prompted for login (126C) and if the login fails they are denied access (134C) to functions of the software. If the process determines the user is logged in (124C), a sub-process runs to obtain a software key (128C). A process checks the software key for expiration (130C). If the software key is expired, the user is again denied entry to the system (134C). If the software key is not expired, a process is run to confirm the software key allows access to the desired feature (132C). The user continues (136C), proceeding to use the desired feature.

[0235] FIG. 49A illustrates one embodiment of a sub-process for software key acquisition (108C) whereby the software key is located on the peripheral input device (PID). In this configuration, the sub-process for obtaining a software key (128C1) is started and the memory on the PID is accessed (129C1) to obtain the software key. Once the software key is obtained, the routine continues (140C1) circling back to determine a valid software license key exists (102C). FIG. 49B illustrates one embodiment of a sub-process for software key acquisition (108C) whereby the software key is located on the electronic controller. In this configuration, the sub-process for obtaining a software key begins (128C2) and a request is sent to the electronic controller for the saved software key (142C2). A check process determines whether a software key exists on the electronic controller (144C2). If the software key does not exist on the electronic controller, a response is sent indicating no software key exists (146C2) then a check is implemented to determine if a software key is available to send from the peripheral input device to the electronic controller (148C2). If the process determines a software key is not available from the PID, the desired features cannot be activated as no valid key exists (152C2). If a software key is available from the PID, the key is sent from the PID and received (150C2). In the event that the earlier check determines the software key does exist on the electronic controller (144C2), the software key value 154C2 is returned and consequently the routine continues (156C2), a valid software license key exists (102) thus permitting the user to proceed with use of the feature (98C).

[0236] FIG. 50 illustrates one embodiment of a software algorithm of a feature control system utilizing a server based authentication. The process is started (90D). A user starts a service (such as Login/authentication service) on their peripheral input device (step 92D). The user then provides input through their PID requesting use of a desired unlockable feature (94D). A process determines whether the unlockable feature requires authorization (160D). If the feature does not require authorization, the user proceeds with use of the function (166D). If the feature requires authorization, a process is run to check the database to determine if the user is authorized to use the system. If the user is authorized, the user may again proceed with use of specified functions (166D). If the user is not authorized to use the system, a sub-process is run to acquire authorization (164D) as illustrated in the embodiment examples of FIG. 51 and FIG. 52. Once the sub-process is complete, the routine circles back again checking if the user is authorized to use the system (162D).

[0237] Illustrated in FIGS. 51 and 52 are two example sub-process embodiments for acquiring authorization (164D) in the server based authentication embodiment illustrated in FIG. 50. In each embodiment, the sub-process is started respectively at (168D1) and (168D2). At (170D1, 170D2) a routine is initiated to connect the peripheral input device to the server. Once connected, a routine is initiated for user log-in to the user's account authenticating the user and sending a token to the server (172D1) and (172D2). At this point, in the embodiment of FIG. 51, a routine is initiated to determine whether the user has a valid authorization in the database (174D1). If there is not a valid authorization, the user is prompted for payment or coupon in exchange for a valid license (178D1) wherein the database is then updated on the server and client to reflect authorization. The sub-routine continues (182D1) such that the processes in FIG. 50 carries on to the routine of (162D). If the user does have a valid authorization in the database (174D1), the database is then updated on the server and client to reflect the authorization. Again, the sub-routine continues (182D1) such that the processes in FIG. 50 carry on to the routine of (162D). Alternatively, referring to the sub-process of the embodiment of FIG. 52 and after the routine of (172D2), a process is initiated to determine whether the user has a valid authorization to use a predetermined function (176D2). If there is not authorization to use the function, the user is prompted for payment or coupon in exchange for a valid license (178D2) whereby a process is run wherein an authentication token is sent to the client (184D2). The sub-process continues (186D2) such that the processes in FIG. 50 continues on to the routine of (162D). If the user does have authorization in the database (176D2), a routine is run for an authentication token to be sent to the client. Again, the sub-routine continues (182D1) such that the processes in FIG. 50 carry on to the routine of (162D). The user now authorized to use the system, proceeds with the use of the desired function (166D).

[0238] FIG. 53 illustrates yet another embodiment of a software algorithm of a feature control system that is similar to the FIG. 46 embodiment as it also checks for a software key to activate features. The process is started (90E). A user starts a service (such as login/authentication service) on their peripheral input device (92E). The user then provides input through requesting use of a desired unlockable feature (94E). A process then determines whether the unlockable feature requires uses of a software key (96E). If the feature does not require activation from a software key, the user proceeds with use of the function (98E). If the feature requires activation from a software key, a routine is run to determine if a valid software key exists on the peripheral input device (102E) and if it does exist, the user may proceed with use of the function (98E). If the routine determines a valid software license key does not exist on the PID (102E), the user is asked whether they would like to obtain a valid software key (106E). If the user does not wish to obtain a valid software key, they once again may proceed but with the function disabled (104E). If the user does wish to obtain a valid software key (106E), a sub-process begins for key acquisition (108E) as illustrated in FIG. 47. Upon completion of the sub-process (108E), the user is reverted back to determining whether a valid software license key exists (102E) and the routine completes as previously described.

[0239] FIG. 54 illustrates the connection to, and basic hardware of a cloud computing source 41F. The cloud computing source 41F comprises a networked computing device 42F and at least a processor, memory, and networked connection to the global internet 32F. Additionally, the cloud computing source 41F may also comprise one or more display and input components. Cloud computing source 41F contains sufficient memory to store database information that is utilized by the FCS and Networked system to authorize, obtain and ultimately communicate information that is utilized by the peripheral input device 19F and electronic controller 11F. The Cloud Computing source 41F may be geographically located in any location that can receive a communication link, and various software modules may be distributed between a one or more cloud computing sources, the peripheral Input device and the electronic controller 11F described herein. The network between the cloud computing source 41F and the peripheral input device 19F is commonly known as the internet, which is performed using any commonly understood methods, such as through a cellular network, WiFi network, Satellite network, each which may rely at least partially on wired, fiber optic or wireless communication mediums.

[0240] As illustrated in FIG. 55, a preferred method of operation of a feature control system for an electronically controlled steerable thruster system of a vessel is as follows. Establishing a wireless network communication between a peripheral input device such as a tablet or smart phone and the internet 200. Starting a mobile control application on the peripheral input device 202 and establishing communication between the peripheral input device and an electronic controller 204 having control over the steerable thrusting device of a marine vessel. A software key is then obtained from a location on the internet 206. Authenticating the software key using an authentication program 208 (FIG. 51-52). Using the authenticated software key to activate one or more unlockable features of the mobile controller application 210. Establishing communication between the electronic controller and the steerable thruster 212. Sending thrusting device magnitude and direction control signals from the electronic controller to the steerable thruster device 214 resulting in consequent control of the steerable thruster device and consequent movement of the vessel towards one or more of: a predetermined waypoint and a predetermined route.

[0241] There are a variety of methods for obtaining a software key, some of which are also illustrated in FIG. 55. For example, one step of generating a software key is consequent a user making a payment or entering a unique coupon code 216. In some embodiments, obtaining a software key involves downloading the key from an internet site 226. In other embodiments, obtaining a software key involves generating a valid software key based on a serial number from the electronic controller 218. In some embodiments, the software key is obtained from cache or locally stored on the PID or both 228. In some embodiments, the software key is obtained from cache or locally stored on the electronic controller or both 230. In some embodiments, the software key is downloaded wirelessly 232.

[0242] Once the software key is obtained, there are a variety of methods for authenticating the software key to assure it is a valid key and not expired or bogus. In some embodiments, a location on the internet 220 is utilized to confirm the software key is a valid software key. For example the user may be directed to a particular web address. In some embodiments, authenticating the software key involves the step of utilizing a location on the peripheral input device to confirm the software key is a valid key 222. In other embodiments, authenticating the software key involves the step of using a location on the electronic controller to authenticate the software key 224.

[0243] Further, authenticating a software key in some embodiments comprises activating an authentication program on a peripheral input device 234, whereas in other embodiments it involves activating an authentication program on the global internet 236. In some embodiments, determining the validity of a user is completed using a login and authentication token 238, whereas in other embodiments a database entry is utilized 240.

[0244] The software key may be used to unlock a variety of features in a feature control system of a steerable thruster system. For example, in one embodiment the software key is utilized to enable the use of one or more of: a map, and a specific map type 242. The software key may alternatively be used to enable the use of a multiple-point route 246. In some embodiments, the software key is utilized to enable use of a GPS position hold 248. In other embodiments, the software key is utilized to enable downloading one or more of: new software, and firmware for the steerable thruster system 250. In yet other embodiments, the software key is utilized to activate the use of point to point routing 252. In other embodiments, the software key is utilized to activate the use of one or more of: a satellite map, and a contour map.

[0245] The foregoing invention has been described in accordance with the relevant legal standards, thus the description is exemplary rather than limiting in nature. Variations and modifications to the disclosed embodiment may become apparent to those skilled in the art and fall within the scope of the invention.