On Jun 1, 9:56�am, Tim Wescott <t...@seemywebsite.com> wrote:> On 06/01/2011 09:27 AM, vbplaya wrote: > > > > > > > On May 30, 12:23 am, Rune Allnor<all...@tele.ntnu.no> �wrote: > >> On May 27, 7:00 pm, Scott Hansen<shansen....@gmail.com> �wrote: > > >>> I am about to start working on a control problem that involves > >>> azimuthal thrusters such as the ones on a tugboat. �The boat will have > >>> one forward and one aft and I need to figure out how to write a > >>> control loop (in this case I'm using Simulink) to control the boat. > >>> This boat will be able to move exactly like a tugboat (in the surge > >>> and sway directions ... including spinning in one spot). > > >>> I have done pretty basic control of platforms in the past and I'm > >>> having a bit of a hard time determining how to approach this since > >>> both motors can vary thrust and have a full 360 degree rotation. > > >>> Anyone have any ideas on how to start and/or can point me in a > >>> direction of some useful articles? �Thanks for the help... > > >>> S > > >> Sounds like a 'standard' positioning task. If you want to > >> *implement* the thing (as opposed to merely understanding > >> how it works) then the first place to start is > > >>http://www.amazon.com/Guidance-Control-Ocean-Vehicles-Fossen/dp/04719... > > >> and then fill up with a ton of books on linear algebra and > >> Kalman filters. > > >> Rune > > > Rune ... > > > You hit it right on the button ... I actually have that book and I am > > using it as much as I can. �The issue is that the control that Fossen > > deals with is when using a rudder only. �The rudder is one control > > component and the other is a main screw. �This however has two > > thrusters which can be adjusted 360 degrees and each has variable > > thrust. �Therefore, to turn port you could position the front thruster > > to push directly port and the aft to push directly starboard. �But to > > turn port you could also have the forward push port and the aft > > off ... or have the port push at a 45 degrees off port and have the > > aft push 45 degrees off starboard ... all of these (and more) > > accomplish a turn port. �This is my dilemma ... because in a normal > > vessel control you simply use the main screw to go forward and the > > rudder to turn port ... this has many more variations. �Fossen's book > > is very helpful and I have already modeled the complete kinematic/ > > kinetics model of the vessel but now I'm at the control portion of the > > design and I'm a little lost on how to start the approach. > > This is exactly why I suggested that you use some sort of a cost > function as a tie breaker. �There is a reason that you have two > thrusters, or folks wouldn't be going to the expense of installing the > second one. �After all, one directional thruster at the stern would > serve the same function as a rudder and a screw. > > So I'm assuming that for the most part you'll be functioning in some > sort of "rudder and screw" mode where the turns are mild, but that the > craft needs to be able to thrust sideways, or turn around its axis, or > do other things that can't be done with screw and rudder alone. > > So: what's wrong with assigning costs to certain motions of the parts, > and attempting to find the thruster settings that attain your control > goals and minimize the costs? > > (drawing snipped) > > -- > > Tim Wescott > Wescott Design Serviceshttp://www.wescottdesign.com > > Do you need to implement control loops in software? > "Applied Control Theory for Embedded Systems" was written for you. > See details athttp://www.wescottdesign.com/actfes/actfes.html- Hide quoted text - > > - Show quoted text -Tim ... Ok so I think I am getting a better idea of what you originally meant when you said "cost" in your earlier post. I was looking at it literally as how much the items cost financially (as in what are the cost benefits of installing one forward and aft as opposed to just forward ... or just aft ... and so forth ... and we had already done that analysis) ... but you are referring to a ranking system (I believe). That is an interesting approach and I will have to look more into that. This system is meant to give the vessel more manueverability ... and YES that added manueverability includes spinning on a point and lateral movements ... all other movements that allow for forward movements can be accomplished using the rudder. S
Control Approaches for Tugboats
Started by ●May 27, 2011
Reply by ●June 1, 20112011-06-01
Reply by ●June 1, 20112011-06-01
On 06/01/2011 10:54 AM, vbplaya wrote:> On Jun 1, 9:56 am, Tim Wescott<t...@seemywebsite.com> wrote: >> On 06/01/2011 09:27 AM, vbplaya wrote: >> >> >> >> >> >>> On May 30, 12:23 am, Rune Allnor<all...@tele.ntnu.no> wrote: >>>> On May 27, 7:00 pm, Scott Hansen<shansen....@gmail.com> wrote: >> >>>>> I am about to start working on a control problem that involves >>>>> azimuthal thrusters such as the ones on a tugboat. The boat will have >>>>> one forward and one aft and I need to figure out how to write a >>>>> control loop (in this case I'm using Simulink) to control the boat. >>>>> This boat will be able to move exactly like a tugboat (in the surge >>>>> and sway directions ... including spinning in one spot). >> >>>>> I have done pretty basic control of platforms in the past and I'm >>>>> having a bit of a hard time determining how to approach this since >>>>> both motors can vary thrust and have a full 360 degree rotation. >> >>>>> Anyone have any ideas on how to start and/or can point me in a >>>>> direction of some useful articles? Thanks for the help... >> >>>>> S >> >>>> Sounds like a 'standard' positioning task. If you want to >>>> *implement* the thing (as opposed to merely understanding >>>> how it works) then the first place to start is >> >>>> http://www.amazon.com/Guidance-Control-Ocean-Vehicles-Fossen/dp/04719... >> >>>> and then fill up with a ton of books on linear algebra and >>>> Kalman filters. >> >>>> Rune >> >>> Rune ... >> >>> You hit it right on the button ... I actually have that book and I am >>> using it as much as I can. The issue is that the control that Fossen >>> deals with is when using a rudder only. The rudder is one control >>> component and the other is a main screw. This however has two >>> thrusters which can be adjusted 360 degrees and each has variable >>> thrust. Therefore, to turn port you could position the front thruster >>> to push directly port and the aft to push directly starboard. But to >>> turn port you could also have the forward push port and the aft >>> off ... or have the port push at a 45 degrees off port and have the >>> aft push 45 degrees off starboard ... all of these (and more) >>> accomplish a turn port. This is my dilemma ... because in a normal >>> vessel control you simply use the main screw to go forward and the >>> rudder to turn port ... this has many more variations. Fossen's book >>> is very helpful and I have already modeled the complete kinematic/ >>> kinetics model of the vessel but now I'm at the control portion of the >>> design and I'm a little lost on how to start the approach. >> >> This is exactly why I suggested that you use some sort of a cost >> function as a tie breaker. There is a reason that you have two >> thrusters, or folks wouldn't be going to the expense of installing the >> second one. After all, one directional thruster at the stern would >> serve the same function as a rudder and a screw. >> >> So I'm assuming that for the most part you'll be functioning in some >> sort of "rudder and screw" mode where the turns are mild, but that the >> craft needs to be able to thrust sideways, or turn around its axis, or >> do other things that can't be done with screw and rudder alone. >> >> So: what's wrong with assigning costs to certain motions of the parts, >> and attempting to find the thruster settings that attain your control >> goals and minimize the costs? >> >> (drawing snipped) >> >> -- >> >> Tim Wescott >> Wescott Design Serviceshttp://www.wescottdesign.com >> >> Do you need to implement control loops in software? >> "Applied Control Theory for Embedded Systems" was written for you. >> See details athttp://www.wescottdesign.com/actfes/actfes.html- Hide quoted text - >> >> - Show quoted text - > > Tim ... > > Ok so I think I am getting a better idea of what you originally meant > when you said "cost" in your earlier post. I was looking at it > literally as how much the items cost financially (as in what are the > cost benefits of installing one forward and aft as opposed to just > forward ... or just aft ... and so forth ... and we had already done > that analysis) ... but you are referring to a ranking system (I > believe). That is an interesting approach and I will have to look > more into that. > > This system is meant to give the vessel more manueverability ... and > YES that added manueverability includes spinning on a point and > lateral movements ... all other movements that allow for forward > movements can be accomplished using the rudder.Sorry about that -- yes, I meant 'cost' in the mathematical optimization sense, not the beancounter-with-a-spreadsheet sense (although he's trying to optimize things according to his training, too). In the systems world it's a common way of letting the math do the heavy lifting for you -- you decide what you like and don't like, assign a cost to what you don't like, and let the math take over. At least that's the theory. In reality it's more like you do the above, then find out that you're making the mathematics choke (even when you're using an automatic optimizer), then twiddle with your cost functions to make things tractable or just start throwing darts at the problem and seeing what the resultant cost is. The extreme case of making the math easy is basic optimal control, where systems are assumed to be linear and costs are assumed to be a weighted sum of squares of the error terms -- then you get a problem that is (a) solvable and (b) calls out a linear controller. Communications theory has a similar trick where you assume a linear channel, additive Gaussian noise and a weighted sum of squares of the error terms. Again, the answer is solvable and linear. Kalman filters lie at this intersection of control and comms theory, and in their 'pure' form they are (a) solvable, and (b) linear (if not time invariant). The extreme hard case is that the math just isn't very tractable at all, and the only thing that assigning costs does for you is to give you an intellectual framework within to think, and a way of comparing competing control rules in various situations, to see which ones look best given a set of assigned costs. As I mentioned, in your case those thrusters are pretty highly nonlinear, so I suspect the math will be fun and exciting, rather than easy. About the only thing that'll prevent that from happening is if the transit speed of the thrusters is so fast that you can always rotate 180 degrees (or 90, if you can reverse thrust) in less time than the boat can do anything significant. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●June 1, 20112011-06-01
On Wed, 01 Jun 2011 11:10:29 -0700, Tim Wescott wrote:> On 06/01/2011 10:54 AM, vbplaya wrote:>>>>>> I am about to start working on a control problem that involves >>>>>> azimuthal thrusters such as the ones on a tugboat. The boat will >>>>>> have one forward and one aft and I need to figure out how to write >>>>>> a control loop (in this case I'm using Simulink) to control the >>>>>> boat. This boat will be able to move exactly like a tugboat (in the >>>>>> surge and sway directions ... including spinning in one spot). >>> >>>>>> I have done pretty basic control of platforms in the past and I'm >>>>>> having a bit of a hard time determining how to approach this since >>>>>> both motors can vary thrust and have a full 360 degree rotation. >>> >>>>>> Anyone have any ideas on how to start and/or can point me in a >>>>>> direction of some useful articles? Thanks for the help...>>> This is exactly why I suggested that you use some sort of a cost >>> function as a tie breaker. There is a reason that you have two >>> thrusters, or folks wouldn't be going to the expense of installing the >>> second one. After all, one directional thruster at the stern would >>> serve the same function as a rudder and a screw. >>> >>> So I'm assuming that for the most part you'll be functioning in some >>> sort of "rudder and screw" mode where the turns are mild, but that the >>> craft needs to be able to thrust sideways, or turn around its axis, or >>> do other things that can't be done with screw and rudder alone. >>> >>> So: what's wrong with assigning costs to certain motions of the parts, >>> and attempting to find the thruster settings that attain your control >>> goals and minimize the costs? >>>>> >> Ok so I think I am getting a better idea of what you originally meant >> when you said "cost" in your earlier post. I was looking at it >> literally as how much the items cost financially (as in what are the >> cost benefits of installing one forward and aft as opposed to just >> forward ... or just aft ... and so forth ... and we had already done >> that analysis) ... but you are referring to a ranking system (I >> believe). That is an interesting approach and I will have to look more >> into that. >> >> This system is meant to give the vessel more manueverability ... and >> YES that added manueverability includes spinning on a point and lateral >> movements ... all other movements that allow for forward movements can >> be accomplished using the rudder. > > Sorry about that -- yes, I meant 'cost' in the mathematical optimization > sense, not the beancounter-with-a-spreadsheet sense (although he's > trying to optimize things according to his training, too).In this case, isn't the cost to be minimized the total energy (~fuel) required to complete a maneuver in the alloted time or at the commanded rate? Since the thrusters should be most efficient at lower speeds, sharing the load equally between them except when rotation and lateral translation are required at the same time (such as move the bow sideways while holding the stern stationary) might be a good start.
Reply by ●June 1, 20112011-06-01
On 06/01/2011 02:08 PM, Glen Walpert wrote:> On Wed, 01 Jun 2011 11:10:29 -0700, Tim Wescott wrote: >> On 06/01/2011 10:54 AM, vbplaya wrote: > >>>>>>> I am about to start working on a control problem that involves >>>>>>> azimuthal thrusters such as the ones on a tugboat. The boat will >>>>>>> have one forward and one aft and I need to figure out how to write >>>>>>> a control loop (in this case I'm using Simulink) to control the >>>>>>> boat. This boat will be able to move exactly like a tugboat (in the >>>>>>> surge and sway directions ... including spinning in one spot). >>>> >>>>>>> I have done pretty basic control of platforms in the past and I'm >>>>>>> having a bit of a hard time determining how to approach this since >>>>>>> both motors can vary thrust and have a full 360 degree rotation. >>>> >>>>>>> Anyone have any ideas on how to start and/or can point me in a >>>>>>> direction of some useful articles? Thanks for the help... > >>>> This is exactly why I suggested that you use some sort of a cost >>>> function as a tie breaker. There is a reason that you have two >>>> thrusters, or folks wouldn't be going to the expense of installing the >>>> second one. After all, one directional thruster at the stern would >>>> serve the same function as a rudder and a screw. >>>> >>>> So I'm assuming that for the most part you'll be functioning in some >>>> sort of "rudder and screw" mode where the turns are mild, but that the >>>> craft needs to be able to thrust sideways, or turn around its axis, or >>>> do other things that can't be done with screw and rudder alone. >>>> >>>> So: what's wrong with assigning costs to certain motions of the parts, >>>> and attempting to find the thruster settings that attain your control >>>> goals and minimize the costs? >>>> > >>> >>> Ok so I think I am getting a better idea of what you originally meant >>> when you said "cost" in your earlier post. I was looking at it >>> literally as how much the items cost financially (as in what are the >>> cost benefits of installing one forward and aft as opposed to just >>> forward ... or just aft ... and so forth ... and we had already done >>> that analysis) ... but you are referring to a ranking system (I >>> believe). That is an interesting approach and I will have to look more >>> into that. >>> >>> This system is meant to give the vessel more manueverability ... and >>> YES that added manueverability includes spinning on a point and lateral >>> movements ... all other movements that allow for forward movements can >>> be accomplished using the rudder. >> >> Sorry about that -- yes, I meant 'cost' in the mathematical optimization >> sense, not the beancounter-with-a-spreadsheet sense (although he's >> trying to optimize things according to his training, too). > > In this case, isn't the cost to be minimized the total energy (~fuel) > required to complete a maneuver in the alloted time or at the commanded > rate? Since the thrusters should be most efficient at lower speeds, > sharing the load equally between them except when rotation and lateral > translation are required at the same time (such as move the bow sideways > while holding the stern stationary) might be a good start.Fuel, wear and tear, noise, readiness for some emergency maneuver -- I'd take all of that into account with 'cost'. Certainly, if fuel use is the only consideration, it gets easier to compute costs. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●June 1, 20112011-06-01
On Wed, 01 Jun 2011 14:55:28 -0700, Tim Wescott wrote:> On 06/01/2011 02:08 PM, Glen Walpert wrote: >> On Wed, 01 Jun 2011 11:10:29 -0700, Tim Wescott wrote: >>> On 06/01/2011 10:54 AM, vbplaya wrote: >> >>>>>>>> I am about to start working on a control problem that involves >>>>>>>> azimuthal thrusters such as the ones on a tugboat. The boat will >>>>>>>> have one forward and one aft and I need to figure out how to >>>>>>>> write a control loop (in this case I'm using Simulink) to control >>>>>>>> the boat. This boat will be able to move exactly like a tugboat >>>>>>>> (in the surge and sway directions ... including spinning in one >>>>>>>> spot). >>>>> >>>>>>>> I have done pretty basic control of platforms in the past and I'm >>>>>>>> having a bit of a hard time determining how to approach this >>>>>>>> since both motors can vary thrust and have a full 360 degree >>>>>>>> rotation. >>>>> >>>>>>>> Anyone have any ideas on how to start and/or can point me in a >>>>>>>> direction of some useful articles? Thanks for the help... >> >>>>> This is exactly why I suggested that you use some sort of a cost >>>>> function as a tie breaker. There is a reason that you have two >>>>> thrusters, or folks wouldn't be going to the expense of installing >>>>> the second one. After all, one directional thruster at the stern >>>>> would serve the same function as a rudder and a screw. >>>>> >>>>> So I'm assuming that for the most part you'll be functioning in some >>>>> sort of "rudder and screw" mode where the turns are mild, but that >>>>> the craft needs to be able to thrust sideways, or turn around its >>>>> axis, or do other things that can't be done with screw and rudder >>>>> alone. >>>>> >>>>> So: what's wrong with assigning costs to certain motions of the >>>>> parts, and attempting to find the thruster settings that attain your >>>>> control goals and minimize the costs? >>>>> >>>>> >> >>>> Ok so I think I am getting a better idea of what you originally meant >>>> when you said "cost" in your earlier post. I was looking at it >>>> literally as how much the items cost financially (as in what are the >>>> cost benefits of installing one forward and aft as opposed to just >>>> forward ... or just aft ... and so forth ... and we had already done >>>> that analysis) ... but you are referring to a ranking system (I >>>> believe). That is an interesting approach and I will have to look >>>> more into that. >>>> >>>> This system is meant to give the vessel more manueverability ... and >>>> YES that added manueverability includes spinning on a point and >>>> lateral movements ... all other movements that allow for forward >>>> movements can be accomplished using the rudder. >>> >>> Sorry about that -- yes, I meant 'cost' in the mathematical >>> optimization sense, not the beancounter-with-a-spreadsheet sense >>> (although he's trying to optimize things according to his training, >>> too). >> >> In this case, isn't the cost to be minimized the total energy (~fuel) >> required to complete a maneuver in the alloted time or at the commanded >> rate? Since the thrusters should be most efficient at lower speeds, >> sharing the load equally between them except when rotation and lateral >> translation are required at the same time (such as move the bow >> sideways while holding the stern stationary) might be a good start. > > Fuel, wear and tear, noise, readiness for some emergency maneuver -- I'd > take all of that into account with 'cost'. > > Certainly, if fuel use is the only consideration, it gets easier to > compute costs.All of your other considerations except possibly readiness for some emergency maneuvers have the same minimum as fuel; lowest power is also lowest noise, wear, and probability of mechanical failure. I can imagine some maneuvers where it might be advantageous to waste energy, such as ramping RPM to max while slewing thruster direction for an emergency reversal (assuming slewing direction is faster than changing shaft speed), but running out of fuel is really bad for readiness. Mention of emergency maneuvers reminds me of pulling an emergency back on one shaft while leaving the other full ahead, with full rudder of course, followed by an emergency full ahead at the end of the turn. The only engineroom operation less boring than watching paint dry, since you get to put the plant partly in manual and kick it harder than the PID controls can, 35,000 horsepower both directions makes the entire ship shake at the blade passing frequency, wakes up the entire crew and probably every sonar operator in the area :-).
