What do we know about our sub's acceleration?

[Chris Hyde]

So I'm trying to devise a way to determine our subs momentary acceleration. (or at least acceleration over a small time step (~0.1 seconds or less)

So, given the state of all 6 thrusters and current velocity, can we calculate our acceleration?  Will it be accurate enough to factor into any estimations?  Do we know this much about our props?

At any given moment, we should know about:
- Current Velocity in 3D vector (in meters/sec)
- Percent Thrust on all 6 props
- Some Idea of global position in 3D Vector

Basically, can we predict our velocity if all we know is what velocity we started at, and then our thrust conditions afterwards?


PS:  It would also be nice to know what our Buoyancy Acceleration constant might be.  I probably called it the wrong thing, but falling objects have Acceleration of -9.8 m/s/s.  But our sub will be +2.5 m/s/s or something like that.


THANKS!

[Chris Hyde]

Now that I'm really getting into this, i'm becoming a much confused shibe.  Anyone familiar with fluid resistance would be much appreciated and i would love to chat!

[prat2932]

At least all the U of I ME's have taken classes that involve finding drag forces on objects, that might be true with the WSU ME's also. Drag force can be model mathematically, though its usually a bit inaccurate if you don't go out and test things (especially since the cross section of the sub is odd). But basically the equation used is:

Drag Force = Cd * rho * Ap * v^2 / 2

Where Cd is the coefficient of drag (calculated using the current velocity and the kinematic viscosity of water)

rho is the density of water

Ap is the projected area of the sub (otherwise known as the cross sectional area)

v is the velocity (relative to the surrounding fluid)

[James Irwin]

At the very least we should be able to get a decent amount of data from out next water test to answer a lot of the questions you are asking. The accelerometer plus the depth sensor data logs should be able to help you calculate maximum values for velocity and acceleration.

[Korey Holmstrom]

Chris,

You should be able to get acceleration from the accelerometer sensor on the sub. 
Percent thrust on each of the 6 thrusters is controlled by the computer, so you should be the one keeping track of that.
Global position will be a difficult thing to do, that would almost require mapping out the pool ahead of time and might be a poor way of approaching the problem.

As for maintaining depth, you really should not need to worry about what the sub's buoyancy is.  You should construct your system like a feedback control system.  By this I mean, you pick a depth that you wish to maintain, which can be checked by the depth sensor, and if the current depth is above the level, you increase the dive thrust percentage.  If it is below, then decrease the depth thrust percentage.  In this way, you really don't need to know anything about the specifics about how the sub moves.  This will allow you to create a control system that can be ported between the current sub and a new sub without having to get exact values for buoyancy and all sorts of other factors just to maintain depth.

The tricky part in this is just to write it in a way that it makes its changes somewhat gradually so that it does not stutter up and down.  The way I think would be the best to approach it would be a comparison between the current and desired depth level.  The farther away from the target, the faster you should change the thrust percentage, and the closer you get, the more fine tuned you can make your adjustments.

If you need more clarification, I can describe it more in detail.

[James Irwin]

Yeah Chris basically you want to create a PID (proportional/integral/derivative) control system, or perhaps just a PI (proportional/integral) system. Korey has taken control systems, which deals with mechanisms for solving problems exactly like this. I would highly recommend that you talk to him.

[luke.renaud]

@James, a controller still usually necessitates a mathematical model of the sub before performance can be determined or design parameters can be set. I will say that based upon David's indication and my observations, the sub's response is so heavily damped with regard to it's depth response, that you can model it as a single or double low frequency pole.

Back to the core topic though, we can gather enough experimental data to tune our controller by simply setting our depth thruster velocity, and recording depth vs time given different thruster values. To be specific, we'll start with the sub on the top, dive until we either hit bottom (according to our depth sensor) or until the sub stops diving (again according to our depth sensor) then bring the sub to the surface and repeat with a different dive strength. We should be able to use this to build a rough experimental controller model of the sub. Similar tests can be run using lateral and longitudinal thrust to get rough models for the subs main movement if we find they are truly needed.

To do analysis after the fact, duty cycle driven to each thruster, current ACL readings and depth readings, along with timestamp information should be enough for us to develop a first order model.

-Luke

[prat2932]

Do we know if we access to some sort of water speed gauge we could temporarily attach to the sub? That could offer more accurate data (I think...) with more data points.

[metaylor]

In case this hasn't already been resolved:
The better we can estimate the sub's response, the better controller we can
make (and the better we can model it in the simulator). A PI or PID
controller would work, but if I understand correctly,  a predictive
controller would do a much better job.

Best,
Matt

[Korey Holmstrom]

Regardless of the model we choose, we need to take data.  For now a simple greater than, less than comparison to the depth sensor readings should be sufficient for testing the AI component.  From talking to Luke, this is all they did for maintaining depth last year and due to how damped the sub's response was, they did not need any kind of complicated controller.  As Luke put it, the simple controller was "Dead accurate".

[Chris Hyde]

The goal of this question is to have a good idea of where the sub will be rather than wait until the sub is out of whatever bounds are set.  Chris Pratt has the right idea.  Chris, do you think you could do the work for me to get some of those constants, and possibly explain what's going on like I am 5?  The math is a bit over my head.  I am just a peasant CS major and don't know how physical objects work.

I also emailed one of our WSU Profs, who said this:

Chris,

You need to know acceleration, then multiplying it by the time step, you will find an update for the velocity.
To determine acceleration, you need to use dynamics equations, such 2nd Newton's law (and similar equation for angular motion).
In these equations, you need to know forces (and their moments) and mass (and inertia moments). Force include weight, thrust, hydrostatic force and hydrodynamic force.
Hydrodynamic force can be approximated as a function of velocity and acceleration (via damping coefficients, added masses and hydrodynamic drag).
You can stop by at my office Sloan 225C to chat about this problem at 1-2:30 tomorrow (Wed) or Friday.

Konstantin

[luke.renaud]

We aren't saying that you can't know what it will be, I'm personally just of the opinion that trying to analytically build a model of the sub directly and expecting it to have any degree of accuracy is unrealistic. Fluid flow problems are incredibly complex, one of the MechE's I did undergrad with talked about how in the history of mankind only a handful of highly specific problems have ever been modeled fully analytically. Typically these systems are entirely analyzed numerically.

I just want to break down the math because I think that what Korey and I are proposing will still fit your goals. Ultimately the sub will be modeled (realistically) by some high order non-linear differential equation. We can probably break this down (due to the low speeds we're expecting to operate at) into a approximation of a nth order (say second or third order) linear partial differential equation. This not only simplifies the model greatly, but it allows us to use classical control theory to develop controllers to deal with drift, sensor error, and certain degree's of interference and environmental offsets in our plant/system. Knowing that our sub will be modeled by an approximation, we can take the approach of avoiding the derivation of the non-linear model altogether. In our next water test, let us implement the accelerometers and measure the response of the sub to various inputs. From the response to these inputs we can then fit a linear model of the sub's response to our commands and develop a differential equation that describes the physical response of the sub. From here, the development of a controller and simulation of the sub's performance later on will match just as well (and actually probably better) than our analytical model of the sub. This is actually the way that most machine learning algorithms develop their controller models.

My suggestions are as follows:

0. Measure 10 seconds of data with the sub sitting still (the drift in the ACL is negligible over a short duration, so this will help us calibrate offset of the sensor for our test)

1. Measure acceleration response to inputs. (Cycling power on the system and repeating the tests might help us to gather more information to overcome any possible offset errors).

1a. A step input in each direction for up to ten seconds (i.e. zero throttle to say 80% throttle)

1b. A ramp input in each direction

1c. A spin in each direction using a step control

1d. A pin in each direction using a ramp control

2. Take the acceleration data and integrate it to produce velocity and position data.

3. Using the response fit the response to that of a 3rd or 4th order linear system and compare results.

As the physical response of any linear system is fully contained in the information of it's step response, we can directly use this to develop a mathematical model of the sub. With this in hand, we can provide you with a differential equation for the simulator (and controller) for discrete time step approximations of the continuous model. Currently I'm assuming that we won't bother moving in two axis at once (although we could if desired), in the even that we do want to do that, we should also  expand the measurements to include steps in both axis simultaneously to help refine our model with cross terms as needed.

[prat2932]

Chris Hyde, I think Luke has the right Idea with this. I didn't review his suggestions for tests, but assuming the accelerometer is accurate enough they should tell us what we need to know, you get you some constants. We might also want to test how thruster output varies as the battery loses its power (or is this handled by a transfer function?).
Also, apologies if I and telling you something you already know, but a PID controller (or transfer function) is a fancy way of telling the computer "the thrusters aren't moving fast enough, give them more power" or "the thrusters are moving too fast, give them less power".