Vosper Mini Fins Stabilisers retrofit on MiToS

[vas]

belated reply, too busy doing all sorts of other things as well as eating and drinking...

It's a couple of years ago I was playing with an MPU 6050, and recalled that being referred to. I didn't get to the point of investigating how to make it work that way, and I don't know whether any of the available open source libraries access those functions. I think it is that sort of functionality that enables the nav systems of all the drones people like to play with.

thanks for that, I wasn't aware of this function, don't remember seeing any mention in any of the libs I tried, so probably not implemented. Will try again at some point!

I think I have missed where you explained how you calculate "mid-point curve of roll rate values", and what you use it for. I guess it has some "numerical" lag built in to it as it is probably based on history.

If you check the pics I posted in my last post, note that one before the last has the whole rate of roll sinusoidal curve shifted up by a unit (more or less) hence, I need to have a reliable midpoint of this curve to check against in order to calculate the point where roll accel zeroes itself and boat starts rolling the other way. That's all.
in the meantime I tried a combo of algorithms to smooth this midpoint curve and the results I'm showing below are much better, so looks like I'm ok for the time being.

Once I had kept reminding myself that your graphs were all at rest, it looks like they are pretty good. It looks as though the system response is fast enough, and that they are being moved at about the right time.

I'm looking forward to the in-motion stages later too.

thanks, actually by checking this and that, rethinking optimising, removing unnecessary code and ifs fins now don't miss any flaps and by analysing the printouts of the teensy plot response and general performance looks v.good.
Now new set of pics taken on the lovely evening of the 23rd, too bloody cold now to do more testing let alone the fact that I've not improved anything since then and yanmar 2GM20F decided it had enough, so about to take it apart next week onwards, so no testing for a month I recon unless I bother to connect to the shore power and test it.


First graph shows fins on, boat rolling v.little (just before the liner wake hits MiToS):

preliminary wave comes, fins start moving. Note we have three parallel lines running, that's the midpoint/average call it as you like of the roll accell value, and the shifted up and down curve. Once roll accell peaks reach outside these two limits, fins are triggered and move (on the next half roll as this calc is a trigger point and and fins cannot move before the next loop check. Note I started with smallish fin movement and then I manually uped it up to max where I did most testing on the day iirc.

That's the MAX wake, would be a 10-11 in my scale now you see that although fins don't miss a beat and get to work as soon as they can (well according to my programming at least...) roll accel goes to 7+ before dropping to a 3.0 in around 7 fin manic flapping period
I'd really like the fins to be able to keep roll accel to 4 at max and then drop to 2-.
Could be the size of fins, the pressure and hydraulic routing to blame. I'll do the hydraulics again, up pressure and test before deciding that I need to up the fin size (which is a possibility), or add winglets and increase the aft section of them, we shall see.

now roll is vastly reduced, fins are on or off and on again. Note that I had another clear mind moment and realised that I can simply bring the fins back to centre when roll accel is less than 1.5 and still only do it at the right time to balance even that little roll, not whenever roll drops below the limits. This worked absolutely fine, with fins coming to midpoint rest without overshooting roll correction and more often than not staying like that for a few periods. That's instrumental on getting a reasonable system while on the way.

some testing with varying amplitudes, not bad, simple fact, at rest you MOSTLY move the fins as far as they go

and now fins off, boat rolling (actually bloody generator died on me and yanmar wouldn't fire again )

Now took the very strong roll calculations image, brought it in AutoCAD and scaled it properly to measure time on the X axis:

Results:

Movement of fins from end to end with fins at full travel is 0.8 to 1.0 sec
Fins stay idle at either end for approx 0.6 to 0.7secs
this is consistent with the roll period that for full travel of fins and a roll accel of 4 to 5 (aka 0.4 to 0.5rad/sec) was 2.95 to 3.05secs
even managed to measure response from my theoretical trigger point (you know roll accell hits the mid roll curve) and it's typically less than 50ms (although a few flaps were at almost 80ms...)

Overall, I'm very happy with the results (would be happier if I hadn't had to take the geny apart) and I'd be interested to compare these numbers with JFM, Bart or whoever else has some hard data on roll (and preferably not on a boat double the size of MiToS, mr FourtyTwo, get a MPU chip and wire up your Pi to do something useful )

happy new year to all!

cheers

V.

 

[jfm]

...the point where roll accel zeroes itself and boat starts rolling the other way. .

Vas im sure you know this but the maths is the opposite of what you have written there. When boat stops rolling one wAy and starts to roll the other way, that’s when acceleration is at its maximum not zero. You get maximum acceleration when you have zero velocity.

Your fin angular velocity might be ok. 0.8 to 1.0 seconds for the full angular stroke is I think on a par with others. BartW and I traded data on this a few years ago- his electric fins move very fast, and faster than typical hydraulics but the sleipner hydraulics are fast and are slightly faster than the CMC electric fins (in the 1m. Sq fin size). Iirc the pic below shows the sleipner angular velocity was 95 degrees per second and this is the pic we used when discussing this. I would like to x2 check the data though because some of the data in that picture is in radians. Obviously the fins can’t move at 95 radians per second but I’d like to check whether 95 degrees is the correct value because I have a hunch it should be faster. I’ll see if I can find the data...

 

[rgarside]

Vas im sure you know this but the maths is the opposite of what you have written there. When boat stops rolling one wAy and starts to roll the other way, that’s when acceleration is at its maximum not zero. You get maximum acceleration when you have zero velocity.

As you point out, there have been references to "roll acceleration", etc. However, I think what is actually being used is the roll rate [I think the MPU gives that as a direct output], so for a sinusoidal kind of response the roll rate will be around zero at max roll [when roll acceleration will also be a maximum].

 

[jrudge]

I have read various comments about stabilisers that they tend to need a first upset to realise they need to do something.

Clearly you can mitigate this to some extent with speed or response, but given you are working well outside the box I wonder if there could be some sort of sensor on the side of the boat ( parking sensor / infra red etc) that could see the wave coming and make an Initial correction to minimise the first roll ?

It does not have to be perfect - simply realise there is a wave from the post side and make an initial minor correction ?

 

[jfm]

I have read various comments about stabilisers that they tend to need a first upset to realise they need to do something.

Clearly you can mitigate this to some extent with speed or response, but given you are working well outside the box I wonder if there could be some sort of sensor on the side of the boat ( parking sensor / infra red etc) that could see the wave coming and make an Initial correction to minimise the first roll ?

It does not have to be perfect - simply realise there is a wave from the post side and make an initial minor correction ?

jeremy as a general point fin systems work by reacting to what they feel, not by predicting. So it’s all about reacting quickly as you say. Predicting is too hard and the imperfect stabilisation caused by predicting incorrectly is generally worse than the imperfection from reacting late. But if Vas can crack that as you say then great. It’s quire a challenge to think of a reliable and convenient advance sensor.

On this point gyros are best because they have zero reaction time so fins cannot beat them on pure reaction time. The best system is fins and gyro together, running off same/shared software. In due course Vas could build that . Ferretti have sleipner fins combined with seakeeper gyros as a tick box option on the 920 and maybe other models but not on combined software.

 

[jfm]

As you point out, there have been references to "roll acceleration", etc. However, I think what is actually being used is the roll rate [I think the MPU gives that as a direct output], so for a sinusoidal kind of response the roll rate will be around zero at max roll [when roll acceleration will also be a maximum].

All ok if that is the case - I was being a bit precise and distinguishing speed from acceleration because obviously they are completely different things. No worries.

 

[jrudge]

jeremy as a general point fin systems work by reacting to what they feel, not by predicting. So it’s all about reacting quickly as you say. Predicting is too hard and the imperfect stabilisation caused by predicting incorrectly is generally worse than the imperfection from reacting late. But if Vas can crack that as you say then great. It’s quire a challenge to think of a reliable and convenient advance sensor.

On this point gyros are best because they have zero reaction time so fins cannot beat them on pure reaction time. The best system is fins and gyro together, running off same/shared software. In due course Vas could build that . Ferretti have sleipner fins combined with seakeeper gyros as a tick box option on the 920 and maybe other models but not on combined software.

Rafiki knows all about car sensors ( lidar etc). I suppose I was thinking if you knew the rate of closure you could calculate the moment is was going to hit. You know from what side so you could then make an initial correction. Given what Vas has accomplished so far the code behind this would be nominal!

Just a thought!

Car sensors are incredibly reliable and well tested.

 

[rgarside]

thanks for that, I wasn't aware of this function, don't remember seeing any mention in any of the libs I tried, so probably not implemented. Will try again at some point!

Happy New Year!

Seems that they are available - try looking at this:-
https://kingtidesailing.blogspot.com/2015/09/how-to-make-nmea-0183-tilt-compensated.html

The Arduino code includes several libraries, and takes the "Motion Fusion" output from the 9250. This should mean that the orientation results are calculated using the accelerometer and gyro data at a high rate on board the MPU. Reading the article, it seems that doing the compass calibration on the fly is a bit much for an Arduino, but could be handled by a Raspberry Pi.

I have a 9250 sitting here, and I have found I could just plug it into a Raspberry Pi running Openplotter and use it as an orientation sensor and compass. However, I couldn't find an easy explanation of the exact computation Openplotter uses to do that. I'm sure that the information must be available somehow - but its not on my priority list at the moment!

 

[vas]

happy new year to all!

As you point out, there have been references to "roll acceleration", etc. However, I think what is actually being used is the roll rate [I think the MPU gives that as a direct output], so for a sinusoidal kind of response the roll rate will be around zero at max roll [when roll acceleration will also be a maximum].

All ok if that is the case - I was being a bit precise and distinguishing speed from acceleration because obviously they are completely different things. No worries.

apologies, lost in translation, problems with reading english, thinking in between gr and en and typing back in en...
I'm indeed using the gyroscope data as mentioned here:

float getGyroY_rads() gets the gyroscope value from the data buffer in the Y direction and returns it in units of rad/s.

Your fin angular velocity might be ok. 0.8 to 1.0 seconds for the full angular stroke is I think on a par with others. BartW and I traded data on this a few years ago- his electric fins move very fast, and faster than typical hydraulics but the sleipner hydraulics are fast and are slightly faster than the CMC electric fins (in the 1m. Sq fin size). Iirc the pic below shows the sleipner angular velocity was 95 degrees per second and this is the pic we used when discussing this. I would like to x2 check the data though because some of the data in that picture is in radians. Obviously the fins can’t move at 95 radians per second but I’d like to check whether 95 degrees is the correct value because I have a hunch it should be faster. I’ll see if I can find the data...

true John, I'd really like to have a look at a couple of graphs from your sleipner (if that's ok and not under nd of course...)
I feel that I'll have to up the fin size a bit to be able to suppress strong abrupt movement/roll, but will be sure once I re route the hydraulics and up the pressure.
Being able to move the fins from end to end in less than 0.8sec as I'll guess will be the case, probably means they don't produce enough resistance to compensate roll. Gut feeling that is of course.

I have read various comments about stabilisers that they tend to need a first upset to realise they need to do something.

Clearly you can mitigate this to some extent with speed or response, but given you are working well outside the box I wonder if there could be some sort of sensor on the side of the boat ( parking sensor / infra red etc) that could see the wave coming and make an Initial correction to minimise the first roll ?

It does not have to be perfect - simply realise there is a wave from the post side and make an initial minor correction ?

Jeremy, not a bad idea and definitely out of the box, wonder how well it will work as we're talking about smallish wake when fins are expected to start responding. Together with the boat rolling, god knows if the ir detector will be picking plain sea, wave coming, or simply the boat moored next to me
Actually coming to think of it, will definitely wont work with IR sensors when moored!

HOWEVER, I think I can use the existing sensor in a slightly more elaborate way. Bear with me:

as I've said before I'd like the stabs to keep roll under or around 1.1of my value, which is 0.11rad/sec roll rate (and not accel )
BTW, John, I'd really love to know what sort of hull roll rate you achieve with fins operating in STAR mode.
In order to do so I've been setting up the trigger point to 1.1 (my values from now on) and trying to play with fin movement (amplitude)
Realised that once I'm there and boat is not moving, I NEED all travel fins have to give. So no point in starting with smaller amplitude and upping it up at say 2 or 2.5 as by that time it's too bloody late.
However, I have to admit it's plain silly to aim for a value and setup the system to start reacting when this value is reached!
I could easily start by triggering the fins earlier at 0.5 or 0.6 (as in 0.05rad/sec which is above nothing but definitely not annoying) using say half full amplitude to correct smallish roll and up it to full amplitude at 1.1 or even 1. This way and considering that fins will be already moving I wont be caught with fins "sleeping" when roll starts, just caught with fins moving less...
Will try it as it's dead easy to do right now (well after the freezing weather we expect tomorrow passes by)

On this point gyros are best because they have zero reaction time so fins cannot beat them on pure reaction time. The best system is fins and gyro together, running off same/shared software. In due course Vas could build that . Ferretti have sleipner fins combined with seakeeper gyros as a tick box option on the 920 and maybe other models but not on combined software.

fins are easy and low tech things as you know John. The high tech part - the controller - is manageable for sure.
I couldn't easily fabricate a high precision high speed rotating thing with just my v.experienced machinist Vangellis. Haven't seen one taken apart true, but I guess it would need reasonably low tolerances that's not easily achievable and special bearings that will be hard to source. If you know else, glad to hear. Will need a new project for 2019 winter

Happy New Year!

Seems that they are available - try looking at this:-
https://kingtidesailing.blogspot.com/2015/09/how-to-make-nmea-0183-tilt-compensated.html

The Arduino code includes several libraries, and takes the "Motion Fusion" output from the 9250. This should mean that the orientation results are calculated using the accelerometer and gyro data at a high rate on board the MPU. Reading the article, it seems that doing the compass calibration on the fly is a bit much for an Arduino, but could be handled by a Raspberry Pi.

I have a 9250 sitting here, and I have found I could just plug it into a Raspberry Pi running Openplotter and use it as an orientation sensor and compass. However, I couldn't find an easy explanation of the exact computation Openplotter uses to do that. I'm sure that the information must be available somehow - but its not on my priority list at the moment!

thanks will search again for a arduino lib with motion fusion enabled !
downloaded and checking the code, will come back when I have some progress to report. Not planning on using a pi though, and v.curious why this guy goes on and on about the arduinos not having enough memory for compass calibration... A teensy 3.6 or an ESP should be sufficient, no?

cheers

V.

 

[rgarside]

thanks will search again for a arduino lib with motion fusion enabled !
downloaded and checking the code, will come back when I have some progress to report. Not planning on using a pi though, and v.curious why this guy goes on and on about the arduinos not having enough memory for compass calibration... A teensy 3.6 or an ESP should be sufficient, no?

.

I think the Arduino has no problem with a static, fixed calibration. I think the thing that is more demanding is doing a continuously updated calibration that might be needed to deal with arbitrary motion in 3D.

Continue having fun in 2019!

 

[vas]

a bit late for an update, but took me the best part of 2019 sorting and rebuilding the yanmar generator engine. Took half 2020 to get all the automation and autocontrol to the generator (via N2k) so last month I started again testing the fins at STAR operation in the evenings when the cat liner gets in Volos port creating some serious wake that will easily drop a glass of water on the floor and mess various things onboard.
Took something like 10 code iterations in order to get a working solution. Following videos are from the roll accel values as well as a video from boat rolling (or not rolling tbh) this evening in Port.

Looks like it's getting there!

and the code view:

cheers

V.

 

[kashurst]

Vas,I think you missed your vocation
result!

is the algorithm based on acceleration or lateral movement?

 

[vas]

Vas,I think you missed your vocation
result!

didn't have such things in the 80s in Greece I'm afraid.
Didn't have lots of computers either, nor micros. First computing experience was at Bath Uni mainframe when I started my PhD in 89 (using vi and latex...)

is the algorithm based on acceleration or lateral movement?

roll accel exclusively. Tried hard to get roll angle values from the MPU that were stable and useable, no luck. Things were okayish with generator (and engines) off. Once you turn them on, all hell breaks loose and no smoothing algorithm can make anything out of them...
TBH, my approach was to improve as much as I could what code I had then (well actually rewrote the lot as the routines where all over the place) see where I can get and then (well, following winter I guess) rewrite it based on your writeup.
So for now, I measure roll accell (changed my code from rad/sec to deg/sec ), improved the routines that do averaging so I know where my mid point is (so that I don't need a dynamic calibration) and trigger the thing when roll accell is higher than a smallish value (video or boat rolling was 0.25deg/sec)
Just to get an idea, last year I was mostly working at triggering values of 1-1.5d/s!

Obvious result is the earlier you react the better the anti roll action, but then you need to have varying degrees of fin travel according to roll accel else you overcorrect and it's both annoying and pointless.
I know turning into a fully dynamic response of fin movement is the right solution, but currently too busy with other work related things to tackle it atm.

And a description of the graph:

• Red sinusoidal is roll acceleration in deg/sec
• blue/black and red flatish lines above and below zero respectively are the 0.3d/s trigger limits on the roll accel, when it goes through them fins move.
• slightly jaggy lines grey and mustard above and below zero respectively are the stbrd and port fin position in degrees/5.0 (so that I dont get the graph scaled too much and sinusoidal roll accel is flattened completely!) Note that it seems port fin seems to be moving slightly more than stbrd. Need to check the angular sensor on top of the shaft and carefully calibrate them (again unlikely to happen this season!) Also note that hydraulic controlling is done on plain solenoids, not progressive valves (which cost more than what I paid to buy and ship all the kit down here!) but still you see a slower start of each fin movement which after the first 5-8deg reaches the max speed till the end of travel.
• finally the other yellow/mustard v.square line is the roll period as measured based on the rollaccel plot. Simply wanted to establish the value as it was obvious it's not consistent on different roll scenarios.

On my following week's to do list is to measure and plot the fin speed in deg/sec for both port and stbrd fin and test that against the higher or lower rpm of the positive displacement pump I'm using (another cheapo at 120euro a piece compared to 1 grand for a proper swash plate one). All tests are done with the generator running a massive 3ph inverter that JFM kindly donated to the project which drives a 3ph motor coupled to a 16l/m positive displacement pump. Currently running at 30Hz vs 60Hz max meaning it most likely pumps around 8l/m.
There's also a second positive displacement pump on a clutch at the port engine for when underway which iirc is 8l/m@1500rpm and which will be used under way at my typical displacement speed of 7-8kn.

Once I get all my data and values right, I can assess the situation and decide what I should do from there on.

Needless to say once boat moves again, I'll have to tune all that according to movement speed which I believe will be fairly easy as it's going to be a multiplier (dunno 0.2-0.4) of the amplitude on the STAR operation. Wont change trigger points, just amplitude. Easy to change values and test on the way compared to having to wait for 6:00pm Express Skiathos arrival at port each evening!

cheers

V.

 

[BartW]

Great stuff Vas, !!
I'm so impressed that you could make this work !

re the fins during navigation,
I'm sure you know this, but during navigation the dynamic behaviour of the fins is totally different,
they only need a small movement for a big reaction ...

on my CMC system, its a different operation mode, "navigation" or " at anker"
you can't switch direct from one to the other, alway's need to "center fins" in between,
and in navigation mode the excursion is limited to max +/- 15* iirc, (at anker it is +/- 45* )
when the boat goes in gear in "anker" mode, the stab system immediately goes in "stop", fins in center,
for this action, we have installed a position switch on the gearbox gear lever.

 

[vas]

thanks Bart, agree and I'm aware of that.
Actually working on a fairly complex set of conditions for it to autochoose how to move/work.
So if either engine goes reverse, they auto park.
when moving (fwd!) fins operate as you say in greatly reduced movement (amplitude) which becomes smaller the faster boat moves. At planning speed pump disengages as it's on a clutch and 1:1 to crank so should only run up to 1500-1700rpm.
Thing is managing the worse scenario which is at rest, I'm not worried about fine tuning operation while moving

V.

 

[Sticky Fingers]

some measuring, mocks, sketching on the hull and a couple more Qs, hope it's picked up by the ones in the know!

first, the plan to have the stabs placed at the e/r is a no go.
Following careful measuring, e/r placement is way too aft:
Stab axle would be 6.55m from bow and 3.70m from stern
Forward tip of the fin would be 6.45m from bow and aft tip of the fin ending at only 2.75 from stern.
Cannot go further towards the bow as there's not enough clearance under the tanks:

Bear in mind that I'm simply laying the mock on the hull ply, but this is going to be reinforced with most likely 3 layers of 20mm marine ply to an overall thickness of 75mm, plus the cross frames on both directions. So going to be a fairly thick area there.

So moved down to the cabins, lifted port cabin mattress and ply, and surely enough there's plenty of easily accessible space for them there:

Stab axle will be 5.40m from bow and 4.80m from stern (this aft measurement is a bit vague as the stern bulges approx 30cm in the middle, measurements I'm giving are for side of hull)
Forward tip of the fin would be 5.30m from bow and aft tip ending 4.00m from stern which I think is more appropriate. Actually fins will be moving under the tanks so v.close to the COG of the boat.
I hope this is acceptable placement along the length of the craft. That's how it looks on the side elevation I'm playing with and checking all new construction on...

Outside now, some pics with the light blue door frame (don't ask where it comes from and why it was laying there!) exactly where the axle would be:

Second issue is how far OUT they can be placed. To be honest I can get them as close as 200mm from the end of the hull.
Hull deadrise there is 20degrees.
shortening the stabs a bit (as in reducing their "height" from 530mm down to say 450mm) at rest the stab is definitely within the footprint of the hull, easily.
This way I'll go down from 0.42sqm to 0.355sqm with better proportions 0.95X0.45m.

HOWEVER, if they move, the outward movement will get the tip of the fin almost 150mm outside the waterline footprint of the hull. Is that acceptable?
Actually the top edge of the fin will be flirting with fresh air on the outward ending of the movement. Is that something that happens?
Looking at the section posted by Bart on his thread for sure the fin goes outside the hull footprint on the outward movement but it doesn't look like coming out of the water (if the wiggly line denotes waterline, it's almost 300mm upwards of the chine!):

JFMs M videos show water turbulence, but you cannot actually see the fin surfacing.
My hull chine (or whatever you call the change from the side to the 20 degrees going towards the keel) is only 80-100mm below waterline where the fins will be fitted whereas looks like that on the 70-80ft hulls, there's 300+mm there!
Is that "allowed" or should I move the fins further in?
Actually the fin axle is at 1.65m from the keel, full width to the chine is 1.95m, so 0.30m from the chine. I can go 0.20m or 0.40m, the former will be edgy, the latter will reduce leverage (I guess) a lot, reducing the effectiveness of them.
FWIW, fin rotation seems to be 30degrees either way from center, following pics show fin movement for 45, 40deg as well as 30. For some odd reason I had assumed it's 40deg, but just now checked with daughter's protractor.

I'll start preparing the ply sheets (well, after buying a sheet tomorrow!) and getting the reinforcements there (a 4kg pot of epoxy should be enough I recon), will be the end of the week before I start thinking about drilling and securing the units in place in port side. Stbrd is a bit dodgy as I either have to move the aircon out of the way, or lift it up 300mm, or drill a LARGE inspection hatch under daughter's bed bulkhead and do all the installation through the hole...

hope for some feedback!

cheers

V.

 

[vas]

hello all,

a year later from my last post on this thread and got some new info to report, so bear with me!

I have to admit that I've not worked that much over all these lockdown periods so had time to rethink my code. Seemed to me that what I was trying to achieve with my code was way too complex and bound to hit various walls so to speak. So at some point around xmas I thought sod that, I'll do a v. rough and simple version of the code simply simulating what an old analogue gyro device would do. So once unsettled and boat listing, fins move till listing is reduced/zeroed (ideally) then moving the other side, do the same the other way. No waiting for unsettling up to x gyro value and then acting upon, just plain stupid cause-effect introducing delays.
Meant that my 400lines of code for the main routine were halved (if so!)
Amazingly, it worked much better with no lost flaps and better response on the STAR operation - remember throughout the winter/spring we were not even allowed to use the boats (for some time wasn't even allowed to get there)
Based on the hypothesis that this is the best I can crudely achieve in terms of force of fin induced stabilisation, I came to the simple conclusion that fins cannot shift enough water to stabilise at rest when the liner does it's handbrake turn each evening at Volos port. So it was decided to try and improve on the fins which remember were more squarish to start with and I'd chopped 60odd mm from their bottom.

Had the boat out on the hard for a month after 2yrs in with the main task being to stir more water with the fins

Started with a mock in carton as in the following pic. The idea was to have a slanted flat piece at the bottom (enabling the fins to trap and shift more water on their outward movement) and extend them aft squaring them and generally putting material as far away from the shaft in order to increase performance - at least that was my take...


the free end of the fin was already slanted and more or less parallel to the waterline. A 5mm piece was lasercut and drilled. Took me a great amount of time to taper all these 10.5mm holes drill the ertalon fin and thread it down to 80mm depth. 24 tapers (iirc) wouldn't like to do that again!








Anyway, bottom plate bolted on, then cut the vertical fin extension but needed somehow to support it. Fin at the aft section was around 10mm wide, so had a v.clever (or stupid if you wish) thought of drilling 200mm long 8mm in dia holes and threading a ss rod and bolting it into a solid 24mm bar that was drilled and taped. Another hell of a job eventually completed. 10mm jacket tube 1mm thick over the ss threaded rod and the 2.5mm plate tig welded on the tube as well as the 5mm thick endplate.
Easily said than done. Was my second serious tig welding job, wasn't that bad tbh and following 4weeks onboard and 3-4h of operation on quartering and beam seas they are still intact, so I'm happy!













Boat back in the water in early June, tbh haven't had the time to tune it in STAR operation but had a few good runs with the new s/w running underway (at 7-8kn) which were amazingly stable even getting beam on the wake of a 30m cruiser doing 15+kn next to me.
Mind I'm pretty sure the unmodded version of the fins would be reasonably good underway (anyway dropped the angular movement to half underway).
Off to Crete next week (by car!) so will be back to do some more testing on STAR and underway operation at the end of August. Will report back then.

All in all, the stabilisation project was successful and boat is now useable at all (acceptable) weather conditions without bobbing about underway. Unless I fix the soundproofing of my 3k rpm MASE generator, I'm not at all interested in using the star mode at anchor or overnight, I'll just move anchorage tbh.

cheers

V

 

[Bouba]

Brilliant, as always

 

[kashurst]

Your determination and resourcefulness is astounding
Enjoy the summer.

 

[vas]

thanks!

still to report next winter is the conversion from on/off solenoid valves for the hydraulics moving the fins to proportional valves.
Only catch is they cost almost 2k, so trying to find s/h kit that is small enough to fit the project.
That will address my last issue which is the "banging" everytime a valve is open and a fin is instructed to move as it happens too abruptly and if you're at the cabins you can definitely hear the ram head banging the rudder end of the fin shaft to move it!

then if still not happy, I guess I'll have to design and built my own custom fins, fairly oblong and increasing in size the further they go from the pivot point - guess grp with a foam core and a bronze shaft and frame.
For the record, fins went up circa 20% from 3.4sqf to almost 4.1sqf. I recon to get measurable improvement on the STAR operation, I'll have to get close to 5sqf with 1:2 proportion if not more 1:2.5~
Boat IMHO is too short (43ft) and light (12ton) with a quick roll period (2.8s iirc) to use the typical fin proportions for STAR operation.
OTOH, STAR operation is more like an easier to address topic for when stranded at port for 8-9m a year Obvs, whatever improvement you achieve in STAR operation will pass on to the underway operation as well.
For the record, in the four weeks I've been onboard this season thus far, I've not used STAR operation not even for a minute but run the stabs for 3-4h already last week on the return trip with beam/quartering seas.

cheers

V.