Vosper Mini Fins Stabilisers retrofit on MiToS

[jrudge]

I understand your doubt, but that's exactly how old school fins stabilizers actually worked.
The so called HMG controller built by Naiad, which drove the stabs in my old boat, didn't rely on any kind of predictive algorithm or other sophistications, quite simply because it didn't have any onboard "intelligence". As soon as the gyroscope sensed a rolling motion, the fins were rotated as quickly and as much as necessary to correct it - as simple as that.
.

Interesting.

I do admit that in my mind I was only considering zero speed stabilisation ( maybe I am lucky but at planning speed I have never come close to needing it underway!).

Thinking again I can see how a "real time" system works under way as "all" you are trying to do it right the boat with the benefit of huge forces as you are underway and have water passing the fins.

In my mind I was thinking the boat is minding its own business and a wake comes along, but that is actually a very different scenario and suddenly it has to do something to correct the spill AND figure out what to do next. Phase 2 of the project no doubt!

 

[vas]

struggling with time and I should really type a long post with the pseydocode that does the fin movement, but I need to work it out in my head a bit more, and try it out again alone without another 7pax onboard wanting to go here or there...

P is right J, and you are right in that zero speed stab is phase 2, walk first and then run (actually phase 3!):

1. stabilise at D speeds: the easiest thing to do
2. stabilise at planning speeds: similar but faster response and shorter movements as well as consider info from the NMEA2K bus
3. stabilise at rest. I feel this last step will be another set of programming routines altogether whereas the first two will probably be the same thing with fin travel and limits of duration of travel altered on the planning case. Here I'll in theory need prediction and heavier programming.

Looks like I should be using a combo of Accelerometer and Gyroscope data for the decision making.
Definitely need to have the fins stop in the middle (whatever that is P, dynamic at the beginning and we'll see...) to help in low to minimum wake conditions
P., yours were driven with a system similar to the Vospers (ie. fully analogue), but I feel the point was rotate them as quickly (response) and fully. The "as much" you mention refers to duration not amplitude, correct? The only alternation you could do in the analogue box was the actual speed of the gyro inside the box that determined the "lazyness" of the response of the system.
I can have both which is a definite plus imho.

And to start all that I need to have my laptop with all the live data on the lower helm and NOT on the bunk on the stbrd cabin, so need to get a long decent quality USB cable to extend the arduino one up to the helm. Anyone care to recommend a decent 2m long USB extension? Don't want to burn the laptop's USB port and want the teensy to have enough juice to fire up and to communicate with the IDE...

Rafiki, correcting listing is not easy, batteries are on port, that's why I put the 7.5kW 3ph motor and pump for the fins also to port. However, generator is on stbrd and seems to be upsetting the lot. Jetrib motor is slightly to stbrd, and the 40lt fuel tank way off to strbrd and no I cannot turn the rib around
But even before the jetrib things were a bit strange, will have to investigate steering a bit more as well as flaps size and placement

waiting for JFMs views as well, but I guess I need to present more data and specific Qs.

cheers

V.

 

[MapisM]

P., yours were driven with a system similar to the Vospers (ie. fully analogue), but I feel the point was rotate them as quickly (response) and fully.
The "as much" you mention refers to duration not amplitude, correct?

Actually both. And also the speed of movement was variable.
Mind, I'm only saying this based on empirical evidence, i.e.:
1) looking at the movements of the analogue gauges while under way - arguably not a very accurate indicator, but that's all I had.
2) looking directly at the fins movements with the boat at anchor.
In fact, even if as you know my system wasn't zero speed, the gyro was totally unaware of the boat speed, and it just kept trying to stabilize the boat whenever it sensed a rolling movement also at rest, if the system was left on.
I tried that a couple of times, just out of curiosity, and it was rather evident that ALL the fins movements (amplitude, speed and duration) were variable. Don't ask me about the logic behind that, though...

 

[MapisM]

maybe I am lucky but at planning speed I have never come close to needing it underway!

Well, "need" is a strong word.
No fishing boat on this planet is equipped with stabs, they all roll like pigs, and they are out there also in conditions we wouldn't dream of affording voluntarily.
So, you can arguably say that stabs are not needed in any boat.

But trust me, in a D boat they are well above the "nice to have" ranking.
And while I agree that they aren't equally necessary in a P boat cruising at P speed, I can assure you that they can make a non irrelevant difference anyway.
Having now crunched a few miles (some of them together!) with the DP, I can tell for sure two things:
Firstly, she rolls much LESS than the old lady, whose pure D round hull (of very similar LWL) was very much prone to rolling with the stabs off, in spite of her very deep and long keel.
Otoh, even if at P speed the DP roll is definitely acceptable, I am pretty sure that stabilizers could still improve the onboard comfort.
Stabs are one of those things which you can really appreciate only after experiencing them, imho!

Anyway, fwiw I don't think I'll ever fit them to the DP, but only because of the usage I have in mind.
If I should consider to regularly use her for trips as long as the one I made this summer, I'd probably reconsider.

 

[kashurst]

Hi Vas, looking very good, seriously impressed. PM sent with some algorithm ideas.
(no problem sharing if any one is interested - its just a bit long winded)

 

[BartW]

Hi Vas, looking very good, seriously impressed. PM sent with some algorithm ideas.
(no problem sharing if any one is interested - its just a bit long winded)

yes pls, all VERY interesting !

 

[wakeup]

Can I suggest a 4th option, once you have conquered just run of the mill stabilisation

Can the fins be programmed to assist the boat to get on the plane?

In other words, accelerometer and software detect that you are in the climbing out of the hole phase and assist by generating equal and parallel lift during this phase and then revert to stabilisation whist underway.

Might get you on the plane a knot or two earlier and might save a little fuel. Or is this a b*ll*&ks idea?

 

[BartW]

here is my limited input to this extremely interesting project:
from what I know from the CMC stabs on Blue Angel,

during navigation the excursion of the fins is limited to +/-15°
while at zero speed the excursion can go up to +/-40°

during navigation, and no stab correction needed, the system nicely centers at 0°,
but while active, it doesn't stop around the zero position point.
(we can introduce a list ofcause)

we have been doing tests with the fins in a "free moving" mode, and the position with the least ristance didn't vary much at different speeds, (10..20kn)
our center position doesn't variate with speed, it is fixed at 4° out for each fin IIRC. (this position equals 0° on the controll panel)

we have the following modes:

Center
ancor
navigation
adaptive

actually we hardly ever tried the adaptive mode, and I have been told that navigation and adaptive mode are nearly the same in recent controll software versions

our system has a mechanical brake, sort of security system,
which engages when the system is centered and switched off

by its design the computer knows the "position" from the fins, (number of turns of the DC motor)
nevertheless, on top of that there is a small belt with a encoder on the stab shaft, that gives a "absolute" position of the fin,
this also functions as a backup sensor in case of a computer problem

the systems detects if we change gear, and knows the speed from its own gps,
and stops from a certain mode automatically when appropriate
ao it puts the fins automatically in center position during manouvring, ...
or when going from fwd to rev, ...

at univ I learned about controll systems but thats much too long ago...

 

[MapisM]

our center position doesn't variate with speed, it is fixed at 4° out for each fin IIRC. (this position equals 0° on the controll panel

Interesting to hear that the "neutral" fins position is practically unaffected through the normal speed range of BA.
I suppose that the difference might be more relevant on faster vessels, but I'm just guessing now.
Just one question: maybe I'm alone in being confused by your "4° out": you mean 4 degrees inward, I suppose?
I mean, with the forward side of the fins closer to the keel than the aft side, correct?
If it were the other way round, I would really struggle to understand why...

 

[BartW]

The fin tale is turned 4* “out from center..? Just how you look at it ...

You were onboard when we did that test iirc, with AC and the engineer from CMC..

 

[MapisM]

Aha, was that tested in that occasion?
Your memory is obviously better than mine!

 

[northwind]

Hi Vas

Ref your need for a longer usb cable, have you thought about using the serial tx/rx from this arduino to another one connected to your laptop? Length of cable would be less of an issue this way.

 

[vas]

thanks for the all the comments, some replies at the end of the post.

some thoughts on roll and subsequent fin movements.

First of all I understand that roll creates forces on the boat that have a sinusoidal form.
minimised/zeroed when the boat reaches both ends of the travel, maximum when boat passes the rest mid point.

Using the accelerator values of the 9DOF chip I was moving the fins from one end to the other when value was changing from plus to minus iow when boat was passing the rest/mid point. Obviously this is way too late.

In an ideal world, you'd like to have the fins move in an inverted sinusoidal maner (measuring amplitute of movement and hence forces induced by the fins) compared to the boat roll forces adding a bit of phase shift by moving fins just before things happen. On a sketch I did, I could have something like 6 fin position changes within a full roll movement (half, full, half again, straight, half, full the other way again, and all over again). I could also have 10 or a hundred, but even six is silly. Reason is that giving instructions to the fins, relays firing up, feedback loop working, sorting new placement etc will take some time. Banging the pressure up and down all the time wont be particularly good for the longevity of the system. A set of proportional valves would be nice, but they cost more than what I paid for the whole setup todate, so not rushing to get them as yet.

Considering the slight delay of the fins moving about, ver2 of the s/w will use both gyro and accel and effectively do the simple job of STARTING to change the fins at approx 3/4 + of the full end to end movement. This means that the fins will be in the NEW position (other end of their travel) after the boat reaches the end of the roll and starts rolling back. So WHEN it starts rolling back, the fins will be already creating full opposite forces.

I'm not particularly happy that the fins will be at full whack everytime boat is passing the rest/mid point but I imagine all systems do that.
However, a combo of gyro and accel data will help me reduce amplitude of fin movement when seas are flatter/flat and when the system effectively reduces roll, so that I wont get the effect shown on the last video. BTW, that's actually how I was altering and testing roll using the simple 1K pot wired to the arduino and linked to fin movement amplitude.

To recap, fins move just before the end of the roll on either side.
Speed, roll angle, roll accel data will help slowly reduce fin travel as roll is reduced, getting them to parked position when things are flat.

Any ideas or objections welcomed!

Kevin, please do post your PM to me to the thread. It wont harm anyone, just give the framework for controlling the movement of the fins.

wakeup, not a silly idea, but I'd guess by introducing more lift, by offsetting the fins say more than the 4degrees that Bart is setup as flat (haven't done such tests on mine yet) you'll be creating more drag. One must check what's the drag vs lift result will be. Put it at stage 4+ for now and we'll see

Bart the 4 degree offset (or toe-in to carspeak) is interesting. I'll do it as well and see where they self align when not in use and report. This way I'll be able to offset the 0 values accordingly and hopefully reduce some drag (and gain 0.5of a knot or so...)

P., I'm curious how the NAIADs could alter amplitude AND speed. They only way you'd be able to alter speed of fin movement would be via engine revs and speed through the water. Cannot imagine they had proportional valves on non STAR fins 20yrs ago. Not to mention an analogue box would have a hard time giving the granularity of data needed to control proportional valves.

northwind, that's a can of worms I don't want to deal with now. Plan is to have the teensy on the bilges running the 9DOF chip, the relays, feedback sensors, et al to communicate with another arduino (due probably) on a 7inch touch display which will be in the lower helm. Using I2C seems to be a complex task by itself, I better now just check the serial monitor on the laptop with the USB connected straight to the bilge teensy. That's a winter project by it's own!

cheers

V.

PS. in Denmark for a week, I'm not sure how much time I'll have to follow and reply.

 

[MapisM]

P., I'm curious how the NAIADs could alter amplitude AND speed. They only way you'd be able to alter speed of fin movement would be via engine revs and speed through the water. Cannot imagine they had proportional valves on non STAR fins 20yrs ago. Not to mention an analogue box would have a hard time giving the granularity of data needed to control proportional valves.

Well, based on the empirical evidence of both the analogue gauges and directly looking at the fins movements while anchored (as I said, if left on the fins did move as soon as the boat rolled, even if the system had no zero speed functionality at all), I can positively confirm you that their speed was NOT constant.
Whether that was handled by proportional valves or any other tricks, I have no idea, because I never investigated in detail the system technicalities, also because it's a bit of kit that always did its job without missing a beat.
But surely the speed didn't change just because of different flow rates from the pump depending on engine rpm, because when I looked at the fins while anchored, the engines were just running at idle in neutral.
If you have a look at the webpage I linked in my post #138, you can see that a "variable flapper-jet device" is mentioned, whatever that means.
Btw, the system worked at a very high pressure: 1200psi in its primary circuit, and 450psi on the two secondary pipes driving the fins.
And that remained steadily at these values, regardless of engines rpm.

All that aside, I don't think that data granularity could be an issue, because the system didn't handle any digital data at all: the gyroscope driven controller, which is by definition analogue, sent somewhat directly its signal to the fin actuator valves.
And that happened "instantaneously", according to Naiad - which is a bold claim for sure, because it's difficult to buy the idea of zero delay between the rolling sensed by the gyro and the actual fins movement.
Otoh, the system effectiveness was beyond belief, and turning the stabs on was akin to use a magic wand, which transformed the boat from a "normal" vessel into something as steady as a rock...

 

[jfm]

Pressure and flow do not vary with rpm if, as is invariably the case, a variable displacement pump is used. The normal PTO pumps used in stabs are swash plate variable displacement pumps where the swash plate angle (which varies the stroke (aka in this forum as excursion) of the pistons) is controlled in a closed loop feedback set up, via a small hydraulic hose from the pressure gallery. So changes to engine rpm in the normal operating range is irrelevant as long as the pump is correctly sized so that the swash plate isn't stuck on max angle (= max piston stroke) all the time. .
And for good measure you would usually have a pressure reservoir tank to keep the pressure and flow up for a fraction of a second if all the valves open suddenly and the swash plate is taking a few milliseconds to move and provide more flow.
I'll come back on some other things Vas but no time right now.

 

[kashurst]

As request edit (improved?) Pm to Vas - I think you are right its the gyros you are mostly interested in

algorithm for stabilisers.Its been a while since I used to do this sort of thing, and I know I have forgotten quite a lot but hopefully this will help. Obviously, any wiser/fresher minds here if you spot my errors here please point them out.

A closed loop feedback control system has a desired input value (ie no roll) and subtracts the actual situation (roll behaviour). The difference is the system error and that value is used by the control algorithm to produce an output signal that controls the motor/pump/fins etc. In order to do this mathematically properly, you need to know a great deal about the behaviour of the system components so you can describe a mathematical transfer function of the system and predict its behaviour. However we are just winging this as its a DIY project with a lot of unknowns, so some fudge factors are needed, (and I can’t remember how to do laplace transforms or Z transforms.)

Also I believe Vas now has a variable frequency motor drive to control the hydraulic pump. I think at this stage best thing to do is keep the motor speed constant until we can achieve basic elementary stabilisation.

A very common control algorithm is the PID method.
A typical PID control algorithm gives an output value to drive the mechanism based on the sum of three values: a Proportion of the error, the accumulation (or Integral) over time of the error and the rate of change in error (or Differential).

where : Error = actual - desired: or simply just the actual roll angle as desired is always zero in this case

So to (hopefully) to control boat roll:
PID output signal = A(roll speed) + B(roll angle) + C(rolled distance)

A,B and C are scale factors you choose to change the sensitivity of the algorithm to each of the three variables. Too much of any one and the fins will either be too slow to be useful or too fast and be a bit hyperactive and the roll will get worse/ new kind of rolling altogether. To tune the boat you need to be able to change the values of A,B and C easily and quickly - I like your use of potentiometers to give control inputs. Probably find you need different scale factors for cruising and another set at anchor
Because we don’t know any performance figures for the fins, momentum of boat etc etc to get it to work will need some trial and error. If you just use roll speed as an error signal to drive the fins the boat will roll worse and probably be erratic, unstable and cause oscillation (it will just keep rocking back and forth). If you just use roll angle the boat will roll out of phase with the waves/wake as the algorithm has no sense of urgency. If you just use the integral value the fins will go too slow and won’t do much. However the right amount of each part should, fingers crossed, show anticipation for rapid movement but not get carried away and make the boat oscillate.

The PS-MPU-9250A chip is amazing.

The gyro gives rate of change of angle as an output in degrees per second (roll speed)- how fast the boat is rolling. This is your differential value and your starting point - it’s why the chip works the way it does.
The integral of roll speed is degrees moved in a period of time (roll angle) - the angle the boat moved since last measured (not the same as actual angle)
The integral of roll angle is total degrees moved in a period of time (rolled distance) - how far the boat rolled. This is the integrated value.

The accelerometer outputs are also very useful as they tell you what angle the boat is actually at so you can check your integrals are working and when the boat is at zero roll.

Link to show simple numerical integration over time (just add up the numbers)
https://www.mathworks.com/help/matlab/math/integration-of-numeric-data.html
So pretty easy to generate an integral value over a fixed time. Take the various values, store them, then at the end of the time period just add them up.
If you sample roll rate and accelerometer angle at 20 times a second and do the two integrations every 0.5 second, your digital control algorithm will generate a new output value every 0.5 seconds. I think this should be fast enough - boats don’t roll that quickly. As its digitally controlled, you can later add non-linear functions to limit fin acceleration, speed, position, and a dead band close to zero roll to stop annoying hunting (basically tell the fins to do nothing for small roll angle)

What would be very useful is a set of values from the gyro outputs on the boat when its moving around to get a feel for the numbers involved. You can put these into a spreadsheet and simulate an error signal.

Hope this helps an fantastic project.

 

[Forty_Two]

Vas replying here rather than the pbo thread re touch screen.

This is my latest project using the Rpi official 7" touch screen. I thought I would mention it as it's nice & would fit your use especially if you are going to add other stuff for control later.

Pi screws to the rear & uses a second i2c for com's leaving the normal i2c free to use. I used PyGame for the screen display, i2c for the RTC & ADC's & multiple 1w busses for the temperature sensors.

 

[vas]

evening all,

slowly getting back to work pace, so time for an update!

After two weeks on and off working in the evenings on the stab control system, I'm very close to finalising and fitting the dash screen with all hardware and most of the functionality sorted.

To sum up the work:

Fin controller down in the bilges between the two stab units. Features the following
arduino teensy 3.5
MPU9250 9DOF controller
4X 25A DC solid state relays (25A is a gross overkill, signal to the fin solenoids is nothing like that but that's the only one I found on sale at a reasonable price on ebay )
DS18B20 temp controller (measuring hydraulic oil temp)
WIKA 2wire pressure sensor (measuring hydraulic oil pressure) That was the single most expensive part of the whole control/monitor setup at 120odd euro!

and bolted on the bulkhead:

Dash controller for both fins and generator (since Mase dash burnt out and had to redoit and at the same time I used the space of the Mase dash for the 7in touch display) featuring:

arduino Due R3
7inch dead cheap touch screen
LCD/touch screen shield on the arduino
4relay board to control mainly generator operation (need two relays to sort out fuel solenoid and start solenoid...) as well as 5.5kW inverter start/stop for STAR operation
beeper so that I get some feedback on the touch screen (talking posh here, took me a whole bloody evening to do it and tune the beep to the right length and tone!)
and a nice push button that I'm not sure what I'll do with it as yet

lasercut a nice fascia for the screen in two layers and fitted all nice and flush with hidden away screws to keep it all together

opened up the 195X75mm hole on the dash to 205X110 to fit the screen. Not an easy task as I had to remove all leatherette and lining and use my dremel carefully cutting 1mm thick galvanised sheet that was behind...

got all the screen bits working. Due to the nasty slow response rate of the screen and after lots of hacking to speed it up (unsuccessfully I should add!) I ended up with the only graphical element that does work on slow refresh rates and that's bar graphs that update reasonably well and with no flickering.

Communicating from bilge to dash (a 5m properly routed cable) was a big struggle. I2C never worked, so I had this bright idea of using the NMEA2000 bus that I already had around.
So a bit of help from Timo (the Fin that has built the libs we're using for N2K comms) I ended up with 3 custom sentences (messages if you wish) to help the two things communicate. Amazingly and after a bit of optimisation, things work as expected and delay is on par with the screen refresh
Had a bit of a struggle to get the touch signals working reasonably (at some point you had to press on the FINS button for 3-5secs before it would register the hit!) all seems to be working fine now.

Fin controller is complete and bolted down there in the bulkhead between cabins and e/r, wired and working
Dash screen is between home and MiToS testing - I have another teensy on a prototype board to test at home the response and code for the fin movement, so don't need to rip the proper controller and bring it home for testing

Only thing to do now is get the ranges of the sensors tuned a bit and work on the actual fin movement routine and integrate kashurst ideas as posted a few messages above.

Hope I'll be able to report with a video soonish only bleeding Mase wont start again so time to deal properly with the air leak on this yanmar gm20 (or whatever it's called)

On the screen:

FINS ON/PARKED/OFF
amplitude lets me alter how much they work
sensitivity hopefully will let me alter /phase shift the movement
Pitch/roll angles are self explanatory, actually I found out that there's proper NMEA2000 sentences for them so I'll broadcast them as well as my custom sentences so that the rest of the bus can present them.
Roll velocity is something I gathered from the MPU9250 sensor and helps me identify the point in the roll that changes direction of movement

the four radio buttons on top of the two fin angle values and bars tells me which of the four solenoid relays are activated (mainly a debug feature)
Oil pressure and temp as per the sensors output

In the pics above fin angles and some other data are random (pics taken at home)


cheers

V.

 

[vas]

Evening all,

have spent the last few afternoons playing with Fin software and have done some progress following last w/e outing, testing and data collection. So time for another long report as I'm using these posts to document what I've done and come back to them at a later point (Alzheimer slowly kicks in...) to remember what I've done and why

First dash is fitted in place, working just fine. Very happy with the way it all has turned out, ergonomically perfect, reasonably unobtrusive,

Second MASE generator (or rather the Yanmar 2GM20F) diesel leak was finally sorted (I think at least!) I had diesel dripping from the bottom of the CAV filter, initially thought it was the new CAV filter (that I replaced the pathetic original filter with), after a day checking, cleaning and swearing, it turned out that it wasn't the CAV but the hose going from the cav to the low pressure pump on the engine. For some odd reason this hose was slightly oversized and although it was clamped down reasonably well, it was leaking a bit. Swapped the hose with new clamps (destroyed the old ones trying to tighten them down more) and all's fine.
Still wont start at a 3.5sec cranking and will take usually 2 such tries (has taken up to 4 one day!) but not sure what to do, other than rebleeding the bleeding engine (and I don't want to do it now...)

Third point was that I looked again at the issue I had with the Inverter dying on me and disconnecting, killing the 5.5kW 3phase motor and the pump with it.
Checked the fault codes of the Schneider, and it was plain and simple that the Inverter was overloaded due to solenoids opening and driving all hydraulic oil to the rams and sticking there (due to coding errors - more to that later)
Trying to find out why it was doing that, I revisited the whole layout against the originally suggested one. And I found an elementary mistake I've made, bear with me:

Originally system was running with 2 X 7lpm constant displacement pumps. Each one was feeding one fin then on their return path were joining together, going through the cooler and back to the tank.
Now I was smart enough (or stupid...) to think I can use one pump for that job. A 16lpm one (larger than the two for good measure...) BUT I made an elementary mistake by routing the pipe from pump to port fin, then stbrd fin and THEN return, oil cooler and back to the tank.
Effectively this means that port fin moves slightly ahead of the stbrd one, no big deal you say, BUT the larger flow means that when the solenoid closes feeding the oil to the ram, the flow is that high that pressure builts up to over 110bar. Fair enough you think but system should run up to 1500psi or 103bar...
Now due to the higher flow I had to drop the 3p motor speed from 50Hz all the way down to 8Hz ffs! Going up to 12Hz kills the whole thing, as 110bar at 12Hz needs MORE than 5.5kW ffs...

Solution is a bit messy as I have to empty the hoses, and get a tee off the pump and get separate loops going to each fin, then join them back before going to the oil cooler. Maybe another 60euro in hoses, and a day messing with oils and hoses, not now, wait for the colder weather for it...

This way I should be able to up the speed close to 20Hz for the motor, have a bit more oomph from the motor and still be under 20A(240V, or 11A max on the 3p).
The seemingly odd approach of getting first the inverter, 3p motor and constant displacement pump was due to the ability to run the motor at different Hz and find what will be really right for the second pump I'll fit on the port engine-not planning to run the generator all the time to run the fins when the boat is moving, it's plain silly!

Now going to s/w, lots of errors to sort, fair amount of head scratching and lots of loling (alone in front of the laptop-sad I know) with some of my mistakes. Today reached a point that I'm close to having most variables sorted and fins moving nicely for longish periods of time without locking, missing their positioning, etc.
Instrumental to ironing out all problems was trying to induce roll simply by moving the fins from port to stbrd. Doing so I managed to fine tune amplitudes, and spot that the port feedback sensor wasn't tight enough and after an hour of fooling around, it missed 20degrees. Locktite to the rescue tomorrow!

A short video of MiToS rolling in the marina with flat seas. Not as impressive as Match, but I think I can improve that a fair amount:

Not bothering to install any s/w on wife's icrap and not having any decent app on my android, I'm going to have a go at finding roll period of MiToS with my favourite method: trial and error... JFM's Match IIRC has a full roll period of around 5secs, mine must be around 3.something. Problem is that seems that you dont do the induced roll simply with a timer, you have to have a feedback loop from the boat (and I haven't done that yet)

cheers

V.

 

[vas]

me again,

seems that I've managed to sort out most fin moving issues I had and therefore managed to get the fins moving more and upped the hydraulic pressure a bit.
Also after lots of trial and error I established that roll period for MiToS is v.close to 2.7seconds.

As a result, roll tests now have the boat moving much more and as much as the mess the liner cat does when it's doing it's handbrake turn/parking routine in the evening.
Unsurprisingly, run them last night when the cat was doing it's thing, and I'm happy to report that MiToS was stable, rolled very little but had to do with the sensitivity and when it's triggered to start the fins moving. Nothing like the hold for dear life situation I would get else...

So now I'm getting into the finetuing of the s/w, change fin amplitude according to roll (amplitude and period), boat speed and getting ready for some open water testing during the week.

latest video of fins moving:

and the stab assembly + bar gauge showing what's going on underneath:

cheers

V.