[PSUBS-MAILIST] Speed controllers

Sat Apr 23 16:50:46 EDT 2016

Regarding transducer accuracy, rarely does the accuracy specification correspond to variable short term drift. Usually it is the worst case scenario combining absolute accuracy, nonlinearity and hysteresis, but the transducer reading tends to be stable at a given temperature and pressure. In a depth keeping application, it actually isn't critical what the actual depth is unless you're making bathymetric charts or operating close to crush depth. You don't care what the absolute output of the transducer is - only that it is properly representative of changes so that a PID controller can respond appropriately to the error signal when excursions from the setpoint occur. That said, I'd still look at what the transducer cost is for such a critical measurement. Your 0.25% transducer may be fine if the drift is acceptable, and you can also lowpass filter the measurement and/or PID output signal to improve stability (at the expense of response speed). You don't necessarily have to respond to
errors rapidly, and your momentum will limit that anyway.  I would probably run a depth control loop at something like 20 Hz, versus the 300ish range that I use for things like proportional valve PWM.  Integrator resolution is less critical in sluggish systems. In fact, you could possibly get away with an even cheaper transducer if you can accept the response lag.  

I bought a Honeywell STJE (0.05%) last year for about $1500 CAD.  Expensive, but that was for an application where absolute accuracy was important, and you can't do much better in an industrially robust transducer. The standard TJE's are a bit less expensive, and of course there are all sorts of lower cost options available. Your 0.25% transducer might be a good tradeoff. I'd probably be hesitant to go much looser on accuracy though. 1% is probably not accurate enough.

Auto altitude is not something I know much about, other than operating by means of a sonar transducer or array / DVL. What sort of error is typical of such measurements? Can a siltout or fish swimming under the transducer cause an erroneous measurement?  Filtering could help with that too. I never considered auto altitude because it requires a flat-ish bottom to work - good for seafloor pipeline inspections, but not so much for flying over dropoffs and shipwrecks.  Large step changes in your process variable measurement are not good for PID loops.

As for tuning, you are correct that it wouldn't be easy. I'd probably shoot for an underdamped system with perceptible but slow integral correction, and forget about derivative entirely.

Sean

On April 23, 2016 12:19:54 PM MDT, Cliff Redus via Personal_Submersibles <personal_submersibles at psubs.org> wrote:
>Sean, I have also been toying with the idea of using a PID loop not for
>all
>my maneuvering but just for depth station keeping.  I may give this a
>try
>as an experiment.  My PLC has PID loops built in so it would be easy to
>try
>this with minimal ladder logic programming.  Initially I was thinking
>about
>establishing the depth set point via a user input through my HMI but I
>kind
>of like your idea of using joystick to drive to desired depth then
>taking
>this depth as the setpoint when the pilot lets the joystick reach its
>neutral position via spring return. With my two MK101s vertical
>thrusters,
>PID controller would pretty easily be able to automatically zero out
>difference between setpoint depth and measured depth.  One other point,
>if
>would be very in the PLC code to switch between depth stations keeping
>and
>altitude station keeping if bottom was not flat.  Two issues come to
>mind,
>first is it would not be easy to tune the PID controller and the second
>is
>if my ambient pressure gage is accurate enough.  I have a 0.25% gage
>now.
>I might need a more accurate gage.  For altitude PID control, the
>transmitter I have should work nicely.
>
>Cliff
>
>
>
>On Sat, Apr 23, 2016 at 8:00 AM, Sean T. Stevenson via
>Personal_Submersibles <personal_submersibles at psubs.org> wrote:
>
>> Part safety, part allowing for future upgrades. In my mind, if you
>let go
>> of the controls, the vessel should stop, period. If you have an
>alarm,
>> leak, fire or something else that demands your immediate attention,
>you
>> don't want to waste precious time having to null the thruster output
>before
>> dealing with the other problem. Having the stick(s) spring return to
>zero
>> output when you let go is just prudent, so you (hopefully) don't
>crash into
>> anything when you have to let go in an emergency, or when you drop
>your
>> pencil on the floor and throw your back out when you bend over to
>retrieve
>> it.  I would employ self nulling controls regardless of whether I was
>using
>> direct or indirect control.
>>
>> With the indirect scheme I proposed, there is an additional advantage
>to
>> be gained in the presence of sensing mechanisms for vessel motion
>(surge,
>> sway, heave, yaw, roll and pitch) such as the ubiquitous pressure
>> transducer for depth, gyro/fluxgate compass for heading, or e.g.
>Doppler
>> velocity log for over bottom motion. In these cases, a control loop
>> provides the ability to null vessel motion, as opposed to simply
>nulling
>> thruster output, so that if you let go of the controls, the system
>can
>> automatically apply reverse thrust to cancel headway or compensate
>for
>> slight currents etc. to keep the vessel where it was when you let go.
>>
>> This is particularly useful in the case of vertical motion. I intend
>to
>> implement such a depth controller so that I drive up / down with the
>stick,
>> with full range on the stick corresponding to 100% thruster output,
>but
>> when I let go, the current depth becomes the setpoint and the
>controller
>> takes over, commanding the vertical thrusters as appropriate to
>maintain
>> that depth. Furthermore, in the event that maintaining that depth
>then
>> requires a sustained thruster output in either direction, the
>variable
>> ballast system will automatically adjust in order to bring that
>necessary
>> thruster output down to zero and thus conserve power.
>>
>> Sean
>>
>>
>> On April 22, 2016 11:13:19 PM MDT, Alan James via
>Personal_Submersibles <
>> personal_submersibles at psubs.org> wrote:
>>>
>>> Not quite following that Sean,
>>> why not have a joystick without return to center function &
>>> leave it on that setting? I can see the sense in running the
>joystick
>>> through
>>> the PLC with an over-ride on the vertical thrusters when on the
>depth
>>> limit,
>>> I have seen commercial psubs with this feature.
>>> Alan
>>>
>>>
>>>
>>> ------------------------------
>>> *From:* Sean T. St! evenson via Personal_Submersibles <
>>> personal_submersibles at psubs.org>
>>> *To:* Personal Submersibles General Discussion <
>>> personal_submersibles at psubs.org>
>>> *Sent:* Saturday, April 23, 2016 4:31 PM
>>> *Subject:* Re: [PSUBS-MAILIST] Speed controllers
>>>
>>> Late to this thread, but I'll throw in my $0.02:
>>> I had envisioned a control scheme whereby the joystick inputs are
>>> decoupled from direct thruster / ballast control output. Instead,
>the PAC
>>> runs the thruster outputs on the basis of PID control loops, where
>the
>>> setpoints are adjusted by the pilot controls. Thus, the ramp rate of
>the
>>> target setpoint is dependent on how far e.g. the joystick is pushed
>or
>>> rotated, but on letting go, the stick springs back to center, and at
>that
>>> point the setpoint is overwritten with the current depth, heading or
>what
>>> have you, and the system automatically maintains that setting until
>you
>>> touch the controls again.  Manually commanded fully automatic.
>>> Sean
>>>
>>> _______________________________________________
>>> Personal_Submersibles mailing list
>>> Personal_Submersibles at psubs.org
>>> http://www.psubs.org/mailman/listinfo.cgi/personal_submersibles
>>>
>>>
>>> ------------------------------
>>>
>>> Personal_Submersibles mailing list
>>> Personal_Submersibles at psubs.org
>>> http://www.psubs.org/mailman/listinfo.cgi/personal_submersibles
>>>
>>>
>> _______________________________________________
>> Personal_Submersibles mailing list
>> Personal_Submersibles at psubs.org
>> http://www.psubs.org/mailman/listinfo.cgi/personal_submersibles
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Personal_Submersibles mailing list
>Personal_Submersibles at psubs.org
>http://www.psubs.org/mailman/listinfo.cgi/personal_submersibles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.whoweb.com/pipermail/personal_submersibles/attachments/20160423/79159639/attachment-0001.html>