How Does Thruster Positioning Affect Rotational Motion in AUVs?

[e-dard]

Hi all,

this is my first post. Google has failed me, although i have learned a lot of physics in the meantime. I am not a physicist (am an evolutionary computation person). Anyway, i am building a physics simulator for an auv submersible and i wanted something cleared up :-)

http://www.edward-robinson.co.uk/mech.jpg"

the link above shows you a diagram of my auv, labelled are the two thruster, the centre of mass and the distance between the thrusters. I am having trouble understanding how to convert the thrusters into rotational motion (i.e. how much to rotate the vehicle (upon its centre) in each time slice (am using euler integration). the thrusters are always directed in the same place, and are parallel to each other.

is it this:?

drag:

 DRAG = 1/2 p v2 a dcoef

for each side, where area = surface area of auv and v2 relates to the velocity for each thruster point vl and vr.

rotational acceleration for each thruster point:

 F = ma --> Tao = I alpha -->  alpha = ( Tl + left_DRAG) * (d/2) / I
F = ma --> Tao = I alpha -->  alpha = ( Tr + right_DRAG) * (d/2) / I

where Tl and Tr are the thrusters on each side. d = distance between thrusters. Inertia is same for both sides?

then the velocities just equal:

vl = al * time_slice
 vr = ar * time_slice

where al and ar are the accelerations at each point.

For tangential velocityi just added these up since the force is in the same direction..

VX = vl + vr

then to calculate rotational velocity i used the 2nd part of the diagram.

ICR = (d/2) * ((  vr + vl) / (vr - vl))

the ICR (instantaneous centre rotation) is the point that the craft would move around in a circle at that instant if no changes to forces exerted on the craft occurred. To get the radius of the circle the craft is moving around, and since the rotational velocity of a line is the same at any point on it:

omega = VX / r

Ok, i don't think this is quite right, but it looks ok on screen. I am expecting parts of it to be wrong, so i just wondered what they were. The original method i tried was less successful because i was getting conservation of angular momentum after i stopped applying any force which is not what i expect. See the next link for a picture. The craft accelerates for a bit and then twice as much thrust is applied to one side, sending it into a turn (yaw). The power is then cut to both sides when the trail goes red. On the left of the picture, using a different method, i was getting conservation of momentum---so when i cut the power to the craft it carried on moving into a circle. What i am getting now is like on the right, which i think is right. Its just i don't think i the equations are right.

thanks a lot for looking, wow long post!

edd

http://www.edward-robinson.co.uk/rot.jpg"

 

[e-dard]

c'mon guys! surely this is not difficult for physicists! I am fairly sure it is basic mechanics, i just need the right things in the right places.

Please help!

thanks

 

[caslav.ilic]

I've just prepared a picture, but don't have time right now to write the story that goes along :) I'll get to that tonight.

(Um... I'm in CEST timezone, so you can calculate what "tonight" stands for :)

--
Chusslove Illich (Часлав Илић)

 

[e-dard]

ok, that would be brilliant, thanks a lot!

It may be worth pointing out that i am only interesting in the movement in the x,y plane and that the simulation will not include effects like currents etc.

thanks,

edd

 

[lpfr]

I think that you have already solved the problem for linear movements:
[tex] a_x= {\sum F_x\over m}[/tex]
[tex] a_y= {\sum F_y\over m}[/tex]
What is missing is the rotation aspect. As you said that all happens in x-y, the only rotation is about the perpendicular axis z. The equation is:
[tex] \alpha = {\sum F_i \cdot d_i\over I}[/tex]
Here [tex]\alpha={d\omega\over dt}[/tex] is the angular acceleration.
[tex]I[/tex] is the moment of inertia (see wikipedia) about the z axis of the object.
[tex]F_i[/tex] stands for each force acting on the object and [tex]d_i[/tex] for the distance form the center of mass to the straight line which contains the force. You can write this as vectorial product: [tex]\vec r_i\times \vec F_i[/tex] where Here [tex]\vec r_i[/tex] is the vector from the center of mass to the point where the force is applied.
For rotations, care must be taken with the signs. Angular acceleration and velocity are positive counterclockwise. All forces are considered positive if they make the object turn counterclockwise.

 

[e-dard]

I think that you have already solved the problem for linear movements:
[tex] a_x= {\sum F_x\over m}[/tex]
[tex] a_y= {\sum F_y\over m}[/tex]

hi, there are never any accelerations in the y-axis (in the frame of the vehicle) because the vehicle only ever moves forward. Of course, moving the actual vehicle in the global environment there are changes in displacement in the X and Y axis but as far as the vehicle is concerned it only ever moves forward in its x-axis and rotates about its z axis.

thus: [tex] a_x= {\sum F_x\over m}[/tex] may indeed hold true, however, since the thrusters have a distance away from the centre of mass they surely exert a torque upon the vehicle, so are you saying that i should apply a force (left + right) on the vehicle in a linear fashion, AND the difference in the force as a toque for rotational acceleration?

as in:

[tex] \alpha = {\sum F_i \cdot d_i\over I}[/tex]

one problem i have with this method is that you are going to conserve rotational velocity after the forces have been equalised. For example, supposing the vehicel acquires a rotational velocity of 4r/s and then the power is cut to the thrusters. In this example the vehicle should shoot of in a straight line, such as a hammer leaving a hammer thrower. However, as soon as the forces are equal (or cut to zero) the angular acceleration will be zero, but the rotational velocity will still be 4r/s... and it will stay that way too unless you bring drag into it, even then this is not what should happen. That's why i used the Instantanious centre rotation method, becuase as the velocities of the thruster reduce omega = vtot / r gets smaller, further, becuase the thruster that was providing more thrust and turning the vehicle has more velocity it will reduce quicker becuase of v2 in drag equation---which increases r towards infinity in omega = v/r which will quickly reduce the angular velocity.

edd

 

[lpfr]

The equations I gave you are the good ones for the general case and not specific to your simulation.
When I wrote sum of all the forces, I meant all, including water drag and water inertia.

Now, in your particular case you can approximate the drag forces by something proportional to the velocity and of opposite direction to velocity:
[tex] a_x= {\sum F_x\over m}-p v_x[/tex]
[tex] a_y= {\sum F_y\over m}-pv_y[/tex]
[tex] \alpha = {\sum F_i \cdot d_i\over I}-q \omega [/tex]
Here, p and q are constants which depend on the shape of the object. You must find them by trial and error.

By your writing I understand that you are maintaining the object fixed and moving the waterscape.
I think this is a very bad strategy because you are going to have a very hard time to add other moving thing on the water, and even to compute the projection of the waterscape as the object evolves.
Usually, the positions of objects are computed taking as reference frame something fixed, as the water or the bottom. Once you have the position of objects you compute the views from the point you want.

 

[e-dard]

By your writing I understand that you are maintaining the object fixed and moving the waterscape.
I think this is a very bad strategy because you are going to have a very hard time to add other moving thing on the water, and even to compute the projection of the waterscape as the object evolves.
Usually, the positions of objects are computed taking as reference frame something fixed, as the water or the bottom. Once you have the position of objects you compute the views from the point you want.

Apologies if my writing is not clear. I am not moving the water at all, i was mearly pointing out that as far as the AUV is concerned it moves in 2 axes: forward and a rotation upon the z axis, again you are still calculating the yvel for the auv which i don't understand. Of course, for the external frame (i.e from the point of view of an observer, there are x and y velocities -- i call these VX and VY.

here is how i move the auv :

the auv has two velocities present --> translational [tex]v[/tex] and rotational [tex]\omega[/tex]

supposing that 0.05 seconds passes, to calculate the new position of the auv in the water we do:

//update heading of auv.

[tex]\Delta heading = \omega \Delta t[/tex]//new x and y velocities for the external frame.

[tex]VX = v \sin heading[/tex]

[tex]VY = v \cos heading[/tex]

//finally calculate the displacement in the x and y directions.

[tex]\Delta X = VX \Delta t[/tex]

[tex]\Delta Y = VY \Delta t[/tex]edd

 

[denverdoc]

But either way, I believe LPFR's points are correct about the drag being more nearly proportional to v, not V^2 and in rotation its not drag that decellerates sub so much as inertial considerations, ie that of having to move the water with the sub like a spoon stirring a glass of water.

 

[e-dard]

But either way, I believe LPFR's points are correct about the drag being more nearly proportional to v, not V^2 and in rotation its not drag that decellerates sub so much as inertial considerations, ie that of having to move the water with the sub like a spoon stirring a glass of water.

ok

So in that case, suppose the sub is rotating at 4r/s and the power is cut
where does the force come from to reduce the subs rotational velocity to a negligible amount in a very short time?

supposing the craft moves with 0 rotational velocity for a while, then turns for a while then kills the power (red line) (with a current rotational velocity of 4 r/s) what stops the left side of the image happening and makes sure that the right side does?
http://www.edward-robinson.co.uk/rot.jpg

thanks for you help guys,

edd

 

[caslav.ilic]

Cautionary note: I'm an airplane-person, not a boat-person, so I'm discussing using airplane analogies. If someone therefore detects stupidities in my writing, I hearby license him to laugh and scold in public.

Regarding drag vs. velocity, I believe OP to be right when taking quadratic instead of linear dependency. From the point of interest here (incompressible viscous flow around a body), the fluid is represented by its Reynolds number. If a 10m long submersible travels at 5kts in 0°C water, the length-referent Reynolds number is about 15 million. That's quite in the range of aerodynamic applications, where it's square of velocity all the way.

Now on to the simulation.

It may be worth pointing out that i am only interesting in the movement in the x,y plane and that the simulation will not include effects like currents etc.

That's what I concluded from your original post, and drawn the sketch above to that setup. It will also cover the question of "what forces the reduction of rotational velocity" when the power is cut.

Given that you feel more at home with the velocity/heading and angular velocity variables, I'll use them too. But have in mind that x, y and angular velocity arrangement, that lpfr wrote equations for, are equivalent to your formulation. There is no external/internal frame distinction between them, both are external.

There is some difficulty with your setup of angular velocity though. Using the angular velocity around the ICR means that you track not the submersible itself, but precisely the ICR. This is unnecessary and will cause trouble when it comes to what kills the rotation when thrusters are off.

Instead (take a look at the sketch), let's track the CG (center of gravity) of the submersible. Then, you have the velocity of the CG, the heading, and the angular velocity around the CG. Furthermore, note (and this is critical) that the symmetry axis of the submersible does not, in general, coincide with the velocity vector (i.e. direction of motion of the CG). The angle between these two directions is [tex]\beta[/tex].

The red forces on the sketch are powerplant: port and starboard thruster given by [tex]T_{port}[/tex] and [tex]T_{star}[/tex]. Green are components of the response force of the environment: [tex]D[/tex] is drag component of the force (oposite to direction of motion), [tex]N[/tex] is component normal to the direction of motion; [tex]M_{yaw}[/tex] is a momentum that appears due to reducing the response force to a certain point, the HC on the picture (sth like "hydrodynamic center", but the name doesn't matter).

At this point, you may wonder why there are two points considered, both the CG and the HC? Well, thruth is that this is pretty arbitrary looking only at the present problem, there may very well be only the CG. But, in reality, whatever method you would use to determine the environment response components, would require fixing some point for the moment component, and this point would not have anything to do with the CG, only with the shape of the body. Hence, it's given in the image, with an arbitrary distance [tex]l_{cc}[/tex] to the CG (so you can put it to zero later if necessary).

Now, if [tex]v[/tex] is absolute translational velocity of the CG and [tex]\omega[/tex] is the angular velocity around the CG (z-axis), then the equations of the motion are:

[tex]m \dot{v} = (T_{port} + T_{star}) \cos\beta - D[/tex] [1] (in direction of travel),
[tex]m \frac{v^2}{R} = (T_{port} + T_{star}) \sin\beta + N[/tex] [2] (normal to direction of travel),
[tex]I \dot{\omega} = (T_{star} - T_{port}) l_{th} \cos\beta + M_{yaw} - N l_{cc} \cos\beta[/tex] [3] (angular motion around the CG),

where [tex]m[/tex] is submersible mass, and [tex]I[/tex] is submersible moment of inertia around z-axis in the CG; [tex]R[/tex] is the distance from CG to ICR. Of course, [tex]\omega = \dot{\beta}[/tex].

You can model all the environment response components similarly to that of drag:

[tex]D = q (K_{D_0} + K_D \beta)[/tex],
[tex]N = q {K_N \beta[/tex],
[tex]M_{yaw} = q K_M \beta[/tex],

where [tex]q = \frac{1}{2} \rho v^2[/tex], and coefficients [tex]K_*[/tex], are, well, something. The dependency on [tex]\beta[/tex] is somewhat logical: obviously, when [tex]\beta = 0[/tex], in head-on motion whith the least frontal area faced to the flow, the drag will be minimal ([tex]q K_{D_0}[/tex]) and there will be neither moment nor normal force due to symmetry of submersible.

Note the physical dimensions of coefficients: [tex]K_D[/tex] and [tex]K_N[/tex] are length squared, [tex]K_M[/tex] is length cubed. That's because I didn't want to split some stuff out of them, because I don't know how; you'd need a referent area for [tex]K_D[/tex] and [tex]K_N[/tex], and additionally a referent length for [tex]K_M[/tex]. This is actually needed only when you have some external data about non-dimensional coefficents, but not if you are just going to toy with them by hand.

Finally, (denoting heading with [tex]\theta[/tex]) your Euler integretion formulas are:

[tex]x_{k+1} = x_k + v_k \Delta t \cos\theta_k[/tex],
[tex]y_{k+1} = y_k + v_k \Delta t \sin\theta_k[/tex],
[tex]\theta_{k+1} = \theta_{k} + R \Delta t[/tex],
[tex]v_{k+1} = v_k + \dot{v} \Delta t[/tex],
[tex]\beta_{k+1} = \beta_k + \omega_k \Delta t[/tex],
[tex]\omega_{k+1} = \omega_k + \dot{\omega} \Delta t[/tex].

There is a problem though. I have no idea of what the [tex]K_*[/tex] coefficients should be, as well as no idea of value of [tex]l_{cc}[/tex]. These are physically critical: a vehicle moving through fluid may be unstable in some combinations of these, that is have a tendency to "reverse its ends". Equation [3] is what should kill the turn rate when the power is off: when [tex]T_*[/tex] terms are out, it becomes a free oscillatory equation, which should subside the turning motion in a stable vehicle. But it doesn't have to (*) :) In your Euler integration, this would manifest itself by the [tex]\beta[/tex] angle diverging.

(*) In fact, at least there are airplanes which are made unstable like this on purpose, so that thay need a constant power input (handled by the computer) in order not to go awol. If the computer control should fail, the pilot can only eject.

edit:

The above equation for heading update is wrong. It holds that [tex]R \dot{\theta} = v[/tex], hence:

[tex]\theta_{k+1} = \theta_{k} + \frac{v}{R} \Delta t[/tex]

--
Chusslove Illich (Часлав Илић)

 

[e-dard]

wow, thanks a lot for the post, i appreciate it! However, i think its a little complicated for what i want!

i am going to try and make head and tail of it and get back to you tomorrow,

thanks,

edd

 

[e-dard]

ok, well i guess the first thing i don't understand is why the vehicle's translational velocity would not be in the same direction as the two velocities produced by the thrusters? They are fixed in position and are parallel.

Also, i don't quite understand a lot of the points, mainly how they fit together, it would be cool if i could get them laid out step by step rather than lumped together:

i will begin with what i know:

first get drag..

[tex]D = 1/2 p v^{2} k[/tex]

then net force...

[tex]T_{net} = (T_{port} + T_{star}) - D[/tex]

then acceleration...
[tex]a = T_{net} / m[/tex]then translational velocity
[tex]v = a \Delta t[/tex]

then velocity in external reference
[tex] VX = v \cos \theta[/tex]
[tex] VY = v \sin \theta[/tex]

then displacement.
[tex] x_{k+1} = x_{k} + VX \Delta t[/tex]
[tex] y_{k+1} = y_{k} + YX \Delta t[/tex]

these things i fully understand, what i don't get is why the exists some [tex]\beta[/tex]. If the submersible is always moving forwards then how can it be moving in any other direction (in its own frame of reference)

It would be good if you could quickly re-arange the rotational steps like i have done, so that i can calculate [tex]\omega = [/tex] easily.

I really appreciate you taking your time to help me, but it's just too much to take in when i was just really looking to find the rotational velocity simply.

regards,

edd

 

[lpfr]

Sorry, Chusslove Illich, that you take as much efforts for nothing. At least, know that I appreciate you explanations and that I will store your post in my PC (you never know).

But you fail to realize that when someone limits the simulation of a 3-D object to
-D, it is just to have a little funny, but not to make a serious simulation.

ok, well i guess the first thing i don't understand is why the vehicle's translational velocity would not be in the same direction as the two velocities produced by the thrusters? They are fixed in position and are parallel.

The thrust of the rear tires of a car are always parallel to the cars heading. But sometimes, when the road is slippery the car advances sideways. It is the same for your object. If you turn its heading while it advances, its movement will change instantaneously. It will continue to advance in the same direction and then, it direction of movement will begin to change.

Then, if you want to make, not a thing as serious and pro as Chusslove Illich, told you, but a simulation that has something to do with reality, you must, at least, use the equations I gave you.
Forget what you call vx.
Use the components x and y of thrusters forces. Compute the accelerations in x and y using all the forces, including drag, and then integrate them to have the speeds in x and y, and then integrate the speeds to get the position.

Same thing for rotation: compute de angular acceleration using all torques and the drag. Integrate accelerations to obtain angular speed. Then, integrate speed to obtain heading.

You can also use a less primitive and imprecise way of integration to use a more precise one as, say, Runge-Kuta method. Try to find "Numerical recipes" Press, Flannery, Teukolsky and Vetterling. Cambridge University Press.

You must learn that just knowing a programming language is useless to solve a problem. To solve a problem, physics or accounting, you must first know the physics (or the accounting) and then you can learn one of the multiple programming languages to solve the problem.

 

[e-dard]

Sorry, Chusslove Illich, that you take as much efforts for nothing. At least, know that I appreciate you explanations and that I will store your post in my PC (you never know).

I don't think that's called for, do you? Who said i didn't appreciate his posts?

But you fail to realize that when someone limits the simulation of a 3-D object to
-D, it is just to have a little funny, but not to make a serious simulation.

when did i ever say i was trying to make a serious simulation? If i was, i would be spending months doing it, would probably be modeling fluid dynamics, and certainly not limiting things to 2 dimensions. As it happens i am not trying to make as perfect as possible a physics simulation, i am trying to make one that is realistic enough to the extent that the basic principles are there.

As i said, i study evolution, not physics. I am interested in the behaviours i can evolve inside neural controllers in the vehicles not the vehicles themselves.

regards,

edd

 

[caslav.ilic]

i will begin with what i know

Of course, what you wrote here is perfectly fine, but you too can see that one thing is missing: how to update the heading? Thus, the whole extra mumbo-jumbo in my post is exactly to establish the link between the thruster action and heading.

But, given that some coefficient guessing is anyway needed, it may indeed be fine to use much simpler way of updating the heading. More on that later, but let me clear some things first.

ok, well i guess the first thing i don't understand is why the vehicle's translational velocity would not be in the same direction as the two velocities produced by the thrusters? They are fixed in position and are parallel.

First, I don't quite get what you mean by "velocities produced by thrusters": the thrusters, or more precisely, some given point on each thruster, will indeed have different velocities due to being part of rigid body undergoing rotational motion. The thrusters themselves do not produce these velocities directly, but are being part of forces acting on the body as whole.

Now, imagine first a spacecraft , sailing through vacuum instead of fluid, but otherwise alike our submersible. It is accelerating in a straight line, with both thrusters firing with some force. At one point, one thruster reduces it force by [tex]\Delta T[/tex], and the other increases by the same [tex]\Delta T[/tex]. What happens then?

The net force is still same as before, so there is no change in the path of the spacecraft , it continues along a straight line. But, there is now a net moment around the CG of the spacecraft , which makes it spin around its CG as it still travels in a straight line. Obviously, the symmetry axis of the craft is no longer aligned with the direction of travel, i.e. velocity vector. The angle between these two directions is the angle [tex]\beta[/tex].

For a submersible, the situation is the same, except for the environment forces which will interfere, and, hopefully but not necessary, make the [tex]\beta = 0[/tex] again soon after the differential thruster action is cancelled.

[...]i don't get is why the exists some [tex]\beta[/tex]. If the submersible is always moving forwards then how can it be moving in any other direction (in its own frame of reference)

Submersible's CG has some path of motion, but the submersible's symmetry axis does not have to be tangential to this path at all times. So, if you define "always moving forwards" as the velocity vector being always in the direction of symmetry axis, then indeed the submersible is not always moving forwards. This effect is know as sideslip in airplane terminology, and [tex]\beta[/tex] is the sideslip angle.

Continuing with the resoning from the previous point, the spacecraft , it is obvious that this angle must exist when there is differential thrust. Its size may vary, but it cannot be that in vacuum it's there, and suddenly in fluid it's not there at all; the difference is only in environment density and viscosity, both continuous quantities, from zero in vacuum to given values in water.

It would be good if you could quickly re-arange the rotational steps like i have done, so that i can calculate [...]

This I can do, but let me first present the easier (but more approximate) way, and you tell me if it would be enough for your needs.

The approach from my previous post is a classical one: if you know how to compute the environment response forces, then you can simulate the motion in the way I described. But, we can look at it another way.

Imagine that you have the said submersible at hand, ready for live test driving, and you wan't to experimentally collect some data in order to be able to program an autopilot for it.

I'm now wild-guessing, but nevertheless: assume that the heading change acceleration rate, that is [tex]\ddot\theta[/tex], increases linearly with the thrust difference, and decreases linearly with dynamic pressure [tex]q = \frac{1}{2} \rho v^2[/tex] and heading change rate [tex]\dot\theta[/tex].

I assume this on the basis of equation [3] from my previous post, because it contains the linear term [tex](T_{star} - T_{port}) l_{th}[/tex], and linear [tex]M_{yaw}[/tex] and [tex]N[/tex], which both depened lineary on [tex]q[/tex] and [tex]\beta[/tex] (and [tex]\beta[/tex] is again somehow linked to [tex]\dot\theta[/tex]).

Hence, I write something like this:

[tex]\ddot\theta = K_T \left[ (T_{star} - T_{port}) - K_{q\dot\theta} q \dot\theta \right][/tex] [4]

with [tex]K_T[/tex] and [tex]K_{q\dot\theta}[/tex] being the experimentally obtained coefficients for a particular submersible (that is, you tweak them in the simulation :)

Physically, formula [4] seems appropriate. When the submersible is traveling in a straight line, both thrusters at same throttle, then [tex]T_{star} - T_{port} = 0[/tex] and [tex]\dot\theta = 0[/tex], hence heading change rate acceleration [tex]\ddot\theta = 0[/tex]. When the thrusters start differential action ([tex]T_{star} - T_{port} \neq 0[/tex]), [tex]\ddot\theta[/tex] will suddenly jump to non-zero, but will become zero again as the heading change rate [tex]\dot\theta[/tex] picks up. At that point, you'll have constant heading change rate. Then, the thruster stop differential action, the term [tex]T_{star} - T_{port}[/tex] vanishes, and the remaining [tex]\ddot\theta = - K_T K_{q\dot\theta} q \dot\theta[/tex] will kill out the heading change rate.

So, to the procedure that you outlined in the post above, you simply add the heading updates:

[tex]\ddot\theta_{k+1} = K_T \left[ (T_{star_k} - T_{port_k}) - K_{q\dot\theta} q_k \dot\theta_k \right][/tex]
[tex]\dot\theta_{k+1} = \dot\theta_k + \ddot\theta_k \Delta t[/tex]
[tex]\theta_{k+1} = \theta + \dot\theta_k \Delta t[/tex]

And now it's not that hard to play with the coefficients. At first, you put small [tex]K_T[/tex] and tweak [tex]K_{q\dot\theta}[/tex] so that the heading exhibist little or no oscillation when the thrusters are out. When the oscillatory motion is ok, you start increasing [tex]K_T[/tex] up to a point when the differential thruster action (difference + time of action) that you have in mind produces a reasonable total heading change (and possibly increasing [tex]K_{q\dot\theta}[/tex] along the way if oscillations get worse).

--
Chusslove Illich (Часлав Илић)

 

[caslav.ilic]

Then, if you want to make, not a thing as serious and pro as Chusslove Illich, told you, but a simulation that has something to do with reality, you must, at least, use the equations I gave you.

Jees, serious and pro... but thanks :)

Although it may not seem that way at first, I really tried to make it as simple as possible, but still preserving what e-dard needs: direction control by thrusters, including proper damping of turn rate when thrusters are out.

Writing out the more complicated original model [1][2][3], helped me formulate the more approximate model [4]. But there is no inherent difference in implementation between these two models, it's just the different number of out-of-the-blue coefficients and numerically-integrated quantities. In fact, the biggest problem with the original model would be, in my opinion, tweaking the coefficients to get sense out of it.

And please have in mind that it's fun for me too (I don't, like, do this stuff every day), otherwise I wouldn't be writing it :)

--
Chusslove Illich (Часлав Илић)

 

[caslav.ilic]

I am interested in the behaviours i can evolve inside neural controllers in the vehicles [...]

Well, true, I might have asked what you need the simulation for in the first place :) You don't even want to know what my brain short-circutedly decided "evolutionary computation" means.

So, you're indeed after the autopilot in a sense, that's quite interesting. For example, I mentioned that low value of [tex]K_{q\dot\theta}[/tex] coefficent in [4] will cause the vehicle to jinx around when differential thrusting starts and ends. You could then use this coefficient to make the life hard or easy on the controller :) You could, for example, try to make the controller not just cut differential thrust, but to slowly reduce it to zero in such a way that the heading shows no oscillation.

Assuming that [4] works out, that is :)

--
Chusslove Illich (Часлав Илић)

 

[e-dard]

Hi Chusslove,

thanks for taking the time to post again, this is beginning to make more sense to me now. I will probably implement the changes to my model tomorrow and let you know.

You don't even want to know what my brain short-circutedly decided "evolutionary computation" means.

:) I am not actually interested in controllers that can control a `difficult to control' submersible successfully. Indeed, this is why i am trying to simplify things as much as possible. I am actually interested in evolving collective behaviours in groups of auv's --- specifically schooling and leader following behaviours. Therefor i am looking for a simplified but abstractly plausible physics simulation so that the controllers don't have to learn how to control a very difficult sub, but can learn how to act in groups etc -- like biological submersibles, fish!

Regarding [4]:

First we work out the instanious acceleration [tex]\alpha[/tex], this is related to several things, the two K terms, drag on the vehicle (q) and the current rotational velocity [tex]\omega[/tex] (or [tex]\dot\theta[/tex]).

from there we can work out the new rotational velocity and heading change using Eulers Integration.

One thing, i always thought drag was [tex]\frac{1}{2} \rho v^2 a coef[/tex] where a = frontal area of craft and coef = drag coefficient of vehicle (the guessing bit!)

why is frontal area not being considered? For example, in the translational respect (i realize that if i was doing this properly the craft wouldn't be moving perfectly in line with its body axis) the frontal area could be say the area of half a sphere (like the front of a torpedo). and when rotating the area could be the frontal area of half a cylinder the length of the craft. But i guess these change depending on how the vehicle is turning!

edd

 

[caslav.ilic]

drag on the vehicle (q) [...] One thing, i always thought drag [...] why is frontal area not being considered?

[tex]q[/tex] in my formulas is only the dynamic pressure, [tex]q = \frac{1}{2} \rho v^2[/tex]. That is, in [4] drag is not used at all.

The drag you use for velocity update exactly as you have described previously, and [4] is only for heading update. (Except that now I see you put [tex]v = a \Delta t[/tex], whereas I guess you meant [tex]\Delta v = a \Delta t[/tex], or for the Euler step [tex]v_{k+1} = v_k + a \Delta t[/tex].)

You don't need to use any area in the drag formula, [tex]D = q K_D[/tex] is quite enough. That's because you can only choose some fixed area and then tweak another constant, which boils down to same if you lump it together into [tex]K_D[/tex] and tweak that.

I'd also give slightly upped formula [4], because I just realized that if the submersible is not moving translationaly, [tex]q = 0[/tex], the turn rate damping will also not be there. Which means that after little differential thrust while floating in place, the submersible would continue to turn around forever :) So, call this [4b]:

[tex]\ddot\theta = K_T \left[ (T_{star} - T_{port}) - (K_{\dot\theta} + K_q q) \dot\theta \right][/tex] [4b]

Though...

I am actually interested in evolving collective behaviours in groups of auv's --- specifically schooling and leader following behaviours.

...now I'm a bit confused :) If this is the goal, then why do you need to use this stuff with heading control by thrust at all? Units anyway have to input the differential thrust action, so if the control itself is not the point, why can't you just have them input heading directly?

--
Chusslove Illich (Часлав Илић)

 

[e-dard]

...now I'm a bit confused :) If this is the goal, then why do you need to use this stuff with heading control by thrust at all? Units anyway have to input the differential thrust action, so if the control itself is not the point, why can't you just have them input heading directly?

Because in real life they would have control of two things: thruster star and thruster port. This is all the neural networks will have control of too. Using evolution they will learn how to avid obstacles, follow way points and group together in the water. My point was that if it is a massive challenge in itself to learn how to control the submersible (e.g. if it is really hard to move in a straight line, or to quickly turn without loosing control) then it would be even harder to learn even more complex behaviours like obstacle avoidance etc.

That's why i keep going from thrust --> acceleration ---> velocity etc. because i always start from thrust the controllers are outputting.

edd

 

[caslav.ilic]

Ok, then you really do have nice handle on controller's job difficulty with coefficients [tex]K_{\dot\theta}[/tex] and [tex]K_q[/tex]. The higher they are the easier the heading change will be, almost directly proportional to duration and amount of differential thrust applied. The lower they are, the bigger the oscillating motion and phase difference between the differential thrust action and heading change.

--
Chusslove Illich (Часлав Илић)

 

[e-dard]

The higher they are the easier the heading change will be, almost directly proportional to duration and amount of differential thrust applied.

is it not possible to make it so that the heading change is directly proportional to the differential thrust? Indeed, isn't this what i was doing when i was using the ICR??

Also, why is it that none of the equations (i mean the ones you have formulated ) are not in the basic Newtonian mechanics books?? It's very annoying!

I have tipler (big physics book) and it treats rotational motion in a different way completely, i guess because it is only looking as rotational motion as a fixed system.

edd

 

[e-dard]

ok, well i have just realized i haven't asked a question that perhaps i should know the answer to.

we know that when both thrusters act on the vehicle their combined forces produce the linear acceleration through the centre of gravity a = ((tport + tstar) - Drag) / mass

we also know that the force giving rotation (when thrusters are not the same magnitude) is govenered by the difference in the forces (which creates a torque)

angular_acc = (torque - rotational_drag) / Inertia

we know that when we travel in a straight line and kill the thrusters the craft will gradually come to rest, this depends upon the drag acting on the craft etc.

i know, using the angular acceleration equation above the crafts rotational velocity will continue to gracefully degrade after the thrusters are cut (or equalised). This is obviously wrong, and not what happens in real life.

I realize you have already given me all the info i need, but i suppose that i still don't know what the difference is, that makes the craft shoot off in a straight line when the thrusters are equalised, i mean---this is what is supposed to happen isn't it...

edd

so, i guess my question is:

 

[caslav.ilic]

is it not possible to make it so that the heading change is directly proportional to the differential thrust? Indeed, isn't this what i was doing when i was using the ICR??

Well, you can make it so by taking those two coefficients in [4b] high enough.

Realistically, I think it's quite intutitive that the following is going on: as soon as thrusters engage differentially, the heading is going to start changing, and the turning rate will increase up to some constant value; when the thrusters cut off, the turning rate starts decreasing, down to zero, perhaps even oscillating a bit around zero. That's what [4b] is doing, and the transitory parts (increase and decrease of turning rate) you can control by the coefficients.

Also, why is it that none of the equations (i mean the ones you have formulated ) are not in the basic Newtonian mechanics books?? It's very annoying!

Equations [1][2][3] should be somewhere in those books -- they are 2D body motion in curvilinear coordinates. Except that their right hand sides will be in canonical [tex]\sum_i F_i[/tex] and [tex]\sum_i M_i[/tex] form; general mechanics books do not deal with origin of external forces, which in this case come from thrusters and fluid response. Aero- and hydrodynamics books deal with these forces, and flight (sailing?) dynamics books put all together.

The ICR view is just a different formulation: there you track ICR motion and instantanious body angular velocity around it (i.e. the heading change rate), whereas [1][2][3] track CG motion and angular velocity around it. Both are equivalent, the CG-centered equations are only easier for tracking forces acting on the body.

Now, equation [4b] is a simplified "model" of [1][2][3] (themselves simplified from what they could be), which I made up on the spot by observing relations in [1][2][3] and applying some engineering sense :)

I realize you have already given me all the info i need, but i suppose that i still don't know what the difference is, that makes the craft shoot off in a straight line when the thrusters are equalised, i mean---this is what is supposed to happen isn't it...

You could also think of it like this. In any direction in which the craft moves or rotates, there will be opposing drag force or moment component. Hence, once the thrusters start working symmetrically, they will balance only "frontal" drag (in the direction of travel). The momentum of rotation will be eaten up by rotation drag component (i.e. cannot be conserved), as there will be nothing to balance it, and the path of the submersible will straighten up.

--
Chusslove Illich (Часлав Илић)