[PSUBS-MAILIST] Speed controllers

Sat Apr 23 11:52:16 EDT 2016

Your point about manual backups is spot on. As things get more complex, the failure probability increases unless specifically designed to provide component, system and/or mission failure redundancy. I'm not going quite that far (not designing the space shuttle), but will have manual overrides and backups - often low tech - in place for all critical functions. You have to be able to get yourself home assuming a complete loss of power, loss of lighting / visibility, etc. Being able to bypass computer control and go to direct proportional control wouldn't be a bad idea if only the controller had failed.

Sean

On April 23, 2016 9:21:11 AM MDT, Alec Smyth via Personal_Submersibles <personal_submersibles at psubs.org> wrote:
>That's an interesting concept and has merit, but the question for me is
>whether the need is important enough to justify additional complexity.
>I'm
>trying to follow a very deliberate philosophy of extreme simplicity.
>The
>idea is for Shackleton to be shipped around the world to interesting
>spots,
>and because I'll be far from my workshop or supplies, absolutely
>everything
>has to be simple, field replaceable, and with spares on hand. So for
>example, I really like the environment monitoring package Jon's been
>developing. Originally I was doing something similar, and the sub had a
>touchscreen and everything controlled by a PLC. I still have a box full
>of
>all the necessary parts, the ladder logic program I wrote for it, etc.
>It
>was done, but I removed it because diving Snoopy changed my mind about
>the
>feature/complexity balance. Which is not to say in the future I would
>never
>ad any automation back in, particularly since I have all the stuff on a
>shelf. It's just that if I ever do it would probably be as a redundant
>ad-on, so that the boat could continue operating if the automation
>fails.
>The other option is to build simple redundancy into the design.
>Whatever my
>electronic controls and speed controllers end up as, they are going to
>have
>a manual bypass that relies on nothing but switches. I was interested
>to
>see the Triton subs do that as well, they have a PLC but also a switch
>labeled "bypass" that turns the whole lot off and returns things to
>manual
>control.
>
>As an example of the feature/complexity balance, consider the compass.
>I've
>got an off the shelf liquid-filled compass mounted outside a viewport,
>that's it. In my box of automation parts I have a fluxgate compass with
>a
>remote sensor that would go outside the hull. There are also way cooler
>three-axis sensors available, like Cliff uses. But if I went the
>automation
>route I would have failure points in the sensor, the cabling, the
>through-hull, the PLC, the display, and the power supply. I'd need
>spares
>on hand for all of those. My objective is to know my heading, but I
>can't
>say I have any critical need for roll and pitch, for an autopilot, for
>course-deviation alarms, or whatever else I could implement taking the
>automation route. Don't get me wrong, they would be great fun to
>implement
>and I encourage it! It's just that the simple solution has more utility
>for
>the intended use of my boat. Shackleton's hull is currently being
>painted,
>and it took only three hours working alone to take the entire boat
>apart
>down to the bare pressure hull for sandblasting. If I went the
>automation
>route, much as I'd enjoy it, I'm pretty sure that would not be
>possible.
>
>
>Best,
>
>Alec
>
>
>
>On Sat, Apr 23, 2016 at 9: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/c03919a0/attachment-0001.html>