Roman Quadrireme Galley by Ian_Grant - 1/32 Scale - RADIO

[Ian_Grant]

Finished the daughter board and finally started to, gingerly, try out some code. Here is what it looks like:

Four 3-pin connectors for the servos along the bottom edge; fuses are in but they are bypassed by the 2-pin jumpers; three 3-pin connectors for signals from the RC receiver (one for future use) near the top left corner.

 

 

Being a complete newbie I planned to take it in small steps. The first step was to verify that I could use the "pulseIn" command to measure the widths of the PWM pulses in the servo control signals from the receiver. This consists of literally two lines of main program loop - read the pulse width, and do a serial write to my monitor screen to tell me about it. Maddeningly it always returned zero after exceeding the timeout period waiting for a pulse to arrive. I went down several blind alleys, handicapped by my lack of an oscilloscope, but using my multimeter I was seeing the DC levels at the microcontroller pins vary as I moved the Transmitter's sticks, indicating the expected varying duty cycle.

 

Finally I asked about it on the Arduino forum. After some twists and turns, it came out that I was specifying the wrong pins at which to monitor for the signal!  Being ex-engineer, I was looking at the schematic and specifying the pins on the microcontroller chip to which I knew I was connecting the signals; turns out that Arduino makes it simpler by designating "pin numbers" as the pin numbers at the connectors on the UNO board not those of the chip. They make the Arduino a true "black box" with the user not even needing to know what chip pin they are using - just call it by the board pin number or name and the compiler knows where it goes on the chip.

 

A true case of not knowing what I didn't know, if you follow me.

 

I plan to get an Arduino book from the library to see what else I don't know.

Edited November 19, 2022 by Ian_Grant

[Thistle17]

It is all a learning experience. Once understood we move on to bigger things. I haven't looked yet but I assume the daugther board is offered as an accessory to the controller board. You have my attention.

Joe

[Ian_Grant]

Yes, you can buy many Arduino "shields" as they call them; I call them daughter boards. Most of them are for a specific function eg motor controllers, or wifi access, or whatever. Mine is a general-purpose prototyping board that provides some +5V and GND rails, plated-thru holes dog-boned to the connector pins, a footprint for a small SOIC, another reset button for the Arduino since its button is now under the "shield", and a couple of LEDs one of which I use as a power indicator.

 

No luck at the library today; two books I saw on the website last night were checked out today! GRRR..

Edited February 20, 2022 by Ian_Grant

[Ian_Grant]

Some progress, of sorts.

 

I can now read the width of the PWM pulses from both channels of my RC Rcvr using the Arduino. Program flow is: Measure Ch1 input pulse width, serial write to monitor, measure Ch2 input pulse width, serial write to monitor in a second column. Snag is that it doesn't work reliably unless I insert "wait" delays of 4 or 5 msec after each serial write. Not sure why; something to do with latency on serial port?? This also means that I am not reading all pulses; the 5 msec wait time after Ch1 eclipses the input pulse from Ch2 so the Ch2 pulse I actually read after the delay is from the next RC 50 Hz cycle. Not really important in the scheme of things since it's only a 20 msec relative delay.

 

Then I wrote another little program to read CH1 input and send the pulse to a servo connected to one of the Arduino outputs. It works! I can control the servo from my RC transmitter's stick even with the Arduino interposed between the Rcvr and the servo! Cool! Snag is that there is some jitter on the servo. I realized that this is due to fluctuations in the pulse width readings which may be due to noise. Another reason to need a scope for this project. I could send the servo a running average to smooth it out but in an actual model I was going to read the sticks just at the start of each rowing cycle so it might be ok.

 

Next test will be to drive a servo slowly back and forth, ignoring the RC rcvr, to see if that can be done without jitter.

Edited December 4, 2021 by Ian_Grant

[mtaylor]

Been a long time since I've anything digital at component level...so take this with a grain of salt.  Feel free to tell me to go sit in the corner if you wish.

 

"Jitter" as I recall can be caused by several things.  One is the charge time on any caps in the circuit or also the choice of processor.  There doesn't appear to be any shielding or decoupling methods here.  Depending the frequency this operates at you could be picking up a lot of circuit noise.  Might be that motor controller is what you need as that's what this circuit is doing.   Do you have any "friends" that have a TV repair shop?  Or are HAMS?  I"m thinking for a o'scope.   

 

Lastly, double check (use magnification and check all your solder joins.  You could have a solder hair crossing terminations which is something I did more than few times back in the day.

 

 

[Ian_Grant]

On 9/16/2021 at 9:55 PM, mtaylor said:

 

"Jitter" as I recall can be caused by several things.  One is the charge time on any caps in the circuit or also the choice of processor.  There doesn't appear to be any shielding or decoupling methods here.  Depending the frequency this operates at you could be picking up a lot of circuit noise.  Might be that motor controller is what you need as that's what this circuit is doing.   Do you have any "friends" that have a TV repair shop?  Or are HAMS?  I"m thinking for a o'scope.   

 

Lastly, double check (use magnification and check all your solder joins.  You could have a solder hair crossing terminations which is something I did more than few times back in the day.

 

 

No luck so far on finding a scope. The PWM pulse widths from the Rcvr, as reported by the Arduino, vary by about 20 usec so yes maybe that's the effect of noise but that would be a lot of noise on the edges. On the other hand this is an old 75 MHz crystal set, not a modern 2.4 GHz one. I changed the program to keep a running average of 5 readings and the variation reduced to 1 usec.

 

That said, I decided to see how steady servo movement would be with the Arduino driving it with a repeating pattern while ignoring the Rcvr pulses, wondering if I would see a jittery response. Short answer is that the servo movement is rock solid. I noticed no jitter whatsoever.

 

I also realized that in the final program, once per RC 50Hz cycle, the code would calculate the next settings for the four oar servos, then send out their respective PWM pulses one after the other. This means that the start time of a given pulse depends on the duration(s) of all pulses sent before it,   e.g.  if I send out 1msec, 1msec, 1msec, 1msec ... and in the next cycle 2msec, 2msec, 2msec, 1msec, ....then the fourth channel will see a delay of 23 msec between the start of its 1st and 2nd pulses since there are 3 extra msec to wait for the first three signals the second time around.....we're straying a ways from model ships here but I find it interesting 😁. This worried me so I wrote some code to slowly switch a servo between two positions, but with different inter-pulse delays. I saw no ill effects at all.  Apparently servos aren't too concerned with the actual pulse repetition rate, just with the pulse width. Great to know.

Edited December 15, 2021 by Ian_Grant
grammar

[Richard Braithwaite]

I like the idea of controlling oar position with software as it allows experimentation with different oar paths and velocities...I've also been developing some rowing machinery for my trireme model. My prototype does not use software to control the position of the oars, but drives the oars (port and starboard independently) in a simple, sinusoidal, elliptical orbit which enables the oar handle path to fit within the close constraints of the trireme structure. 

Video of prototype in action below:

 

 

 

Edited October 19, 2021 by Richard Braithwaite

[Ian_Grant]

Hi Richard!  I'm glad you found this, and may I say I'm a great admirer of your gorgeous triere! Of course I had seen your smooth mechanism before but I wanted to try something different. 

 

By the way, I wonder why I get no notifications if someone comments in this log that I started?

 

Update: I've been testing code, overcoming newbie arduino problems and getting used to it. At one point I was stuck for hours trying to get a bunch of nested IF's to do what I wanted! 🤪  I finally got around it by rewriting code to avoid such deep nesting. I just completed writing the program last night but only the first third is tested. As now written, the oar motion will simply be rectangular because I wanted to try to get the jig's oars going to be able to test the turning features etc. I can easily refine the stroke shape later. I  wrote the code to stop the inside oars in a middling turn, and reverse them on a hard turn, whether going forward or backward. Should be interesting. Also, as written, as throttle advances there is an initial range over which the strike rate (oar cycles per minute) is constant but the sweep length gradually increases to full, then a new range over which sweep length stays at full but strike rate increases, to max speed (which would be short duration for actual human rowers). It also occurred to me while walking the dog this morning that there's no reason for the oars to move at the same speed on the power and return strokes; I will try speeding them up a bit on the return stroke to see how it looks.

 

Software provides flexibility, but it also means there are a thousand possible ways to do this. I'd need an actual model to finalize the parameters eg how effective is the rudder for slight course corrections without changing the oar motion, when exactly to reverse oars on a turn, what's a good strike rate for the slower speeds, what's a reasonable strike rate at full speed, etc.

 

Rainy weekend coming up so I will try debugging. Another video to come soon I hope.

Edited December 15, 2021 by Ian_Grant

[rookie]

Hey Ian

Just went through this topic; very cool! 

Thanks for the link

Glad you didn't ask me for "help" with coding 😀

C++ not really my thing

Looking forward to seeing it afloat ... 

 

[mtaylor]

18 hours ago, Ian_Grant said:

By the way, I wonder why I get no notifications if someone comments in this log that I started?

 

Go up to the top of the first post.. there's box labeled "follow"   Click it and you'll get notifications.

[Ian_Grant]

5 hours ago, mtaylor said:

Go up to the top of the first post.. there's box labeled "follow"   Click it and you'll get notifications.

Thanks!

[Ian_Grant]

On 10/30/2021 at 10:39 AM, rookie said:

Hey Ian

Just went through this topic; very cool! 

Thanks for the link

Glad you didn't ask me for "help" with coding 😀

C++ not really my thing

Looking forward to seeing it afloat ... 

 

Hey bro!  Well C++ or programming in general is definitely not my thing!  C++ seems to have more punctuation than anything else. I've run into situations where I make a syntax error in a program statement but the compiler doesn't complain and the statement just does nothing when executed. Not sure why the silence from the compiler.

 

However I did borrow a great book from the library "Teach Yourself Arduino Programming in 24 Hours" by Richard Blum. I highly recommend it to anyone starting with arduino.

Edited December 15, 2021 by Ian_Grant

[Ian_Grant]

Well, I think the program is working at least it looks that way 😁. I didn't dare plug servos into the daughter board on the first try in case the software generated invalid pulse widths which could perhaps damage a servo by trying to make its motor go beyond the mechanical end point, however I used my new 'scope to observe the output pulses. Yes I did get a 'scope and it is the only way I got to where I am in debugging. It is a joy to have for stuff like this.

 

Here are a couple of shots of the "throttle" and "rudder" pulses from the RC receiver into the Arduino. There were two things I did not expect, (1) the trailing edge of one always exactly aligns with the leading edge of the other, and (2) the "rudder" pulse from the right stick on the transmitter comes first; somehow I assumed the signal from the left stick would be "channel 1". These two shots show them both at 1msec minimum, and both at 2msec maximum. Actually they don't quite get to 1 and 2 msec without moving the transmitter's "trim" adjustment sliding pots.

 

 

After quite a lot of effort to read these pulse widths and derive appropriate pulse widths to output to the servos, I decided to rewrite the code, abandoning the Arduino "servo library" completely for technical reasons. The most important was that the moment I defined an output pin as going to a servo the Arduino started generating a pulse stream at the pin, with interval 20msec as defined by its own internal clock divider. Of course, there is zero chance that this matches the 20msec interval defined by the RC set's crystal so the output became asynchronous to the inputs which led to issues I won't detail here. I wanted to keep program flow simple: measure the two input pulses; calculate next positions for the four oar servos; send out four appropriate servo pulses; sit in an "idle" loop while waiting for the next input pulses. Nice and synchronous and easy to monitor on the scope. Since the period for RC sets is 20msec, and the two input pulses are each 2msec at most, I have 16 msec for the calculation and sending of four pulses. The four pulses take at most 8msec so there is plenty of time for each program execution cycle.

 

Instead of using the "pulseIn" command from the servo library I rewired the two connections from the RC Receiver to the two Uno pins which support external interrupts. The program configures them to interrupt on either rising or falling edges at these pins. The interrupt routines read the DC level at the pin (to know whether the interrupt was because of a rising or falling edge) then record the internal clock counter reading in either a "startTime" or "endTime" register as appropriate. If it is the end of the pulse, a flag is set before returning to the main program. The main program sees the flag then knows it can calculate the latest pulse width by subtracting startTime from endTime. It then resets the flag and continues.

 

To send a calculated output pulse to a servo, the code simply sets the output high, waits the calculated time using the "delayMicroseconds" command, then pulls it low again; no interrupts required.

 

To spare the servos potential damage, I sent their calculated pulses, one at a time with 1 msec pauses between, to a microcontroller output pin to which I connected a scope probe. Just as well because the the first try did not go well and sent pulses much much wider than the servos could have handled safely. After some debugging effort I got correct-looking pulses. Here are a couple of photos.

 

 

The top trace is the incoming throttle pulse, repeating at "20msec" intervals. The bottom trace shows the four pulses which would go to the oar servos, completely synchronous to the input. You can't see it from these static photos but the pulse widths for the two sweep servos "breathe", getting wider then shrinking again to make the servos move the oars back and forth (observe the difference in the pictures). As I advance throttle they vary more and more quickly, indicating the oars are moving faster, as expected. If I put the rudder to one side, I can see the inboard oars stop moving as designed. If I jam the rudder  hard over I can see the relationship between the "sweep" and "lift" servo on the inside of the turn "flip" as that side begins to backstroke.

 

The time from the falling edge of the throttle pulse to the first output pulse, about 0.2 msec, is the time taken by the program to record the throttle pulse's width then calculate next positions for the four servos for this RC cycle.

 

I didn't have time to try it on the actual rowing jig 'cause I was setting up all my Hallowe'en display this afternoon but hopefully I can try it tomorrow. I also plan to add code to make the stroke elliptical, which only requires changing the formulas in four lines of code. In fact I can use the daughter board's DIP switches to select between rectangular and elliptical motion just for fun. I'm pretty excited and looking forward to seeing oars move.😀😜

Edited October 13, 2023 by Ian_Grant
sp

[Ian_Grant]

I found some time to hook it all up. It all seems to be working as expected. Features like the inside oars on a turn stopping, then back-stroking if the rudder goes really hard over, are shown in the following video.

 

 

After my son shot the above video, I realized I forgot to show the "pause" function I programmed in. This "pause" is a momentary stop in the oar motion at the end of the power stroke. The duration in terms of RC cycles (20 msec) is entered at the start of the program. I have entered 12 for now, representing 12 x 20 = 240 msec, approx 1/4 sec.

 

 

Edited December 15, 2021 by Ian_Grant

[Rail and Tie]

Absolutely brilliant work!

 

Don't forget the Ben Hur sound track to be added... "Thump, Thump, Thump, Thump..... RAMMING SPEED!.... Thump Thump..."

 

This certainly opens up a lot of possibilities for a realistic RC ship.

[Ian_Grant]

Thanks!  After viewing the video I checked the "elliptical" calculation again since I didn't see much difference even though I said so in my ad lib narration. The equations are correct; not sure why the change isn't more obvious.

 

The noise is still an issue, although the "juddering" and "thud" you hear when the oar beams are going down would go away in the real ship in which I would use stainless steel upright shafts and linear bearings. Not two pieces of wood with a dado in them 😁.

 

Yes, I thought of having the arduino generate, or maybe just trigger an external circuit, to generate a bass drum beat, but apparently they actually employed flutes to time the rhythm not drums which are a Hollywood thing. Treble sounds from flutes are more easily heard then a bass sound in a ship with all its timbers and oars groaning. And maybe the oarsmen too?

Edited December 15, 2021 by Ian_Grant

[Bedford]

That's coming along nicely, I know you're aiming for the most realistic motion you can get so as a rower I think the strokes are way too fast at this stage. It takes a lot of effort to move oars that big and that long.

 

I'd suggest that the slow speed you showed should be full speed and is it possible to have the power stroke slower than the return stroke to simulate the extra effort?

 

I would also suggest that the pause is too long, it probably only needs to be long enough to be discernible. 

[Ian_Grant]

Thanks Bedford for your interest and especially your suggestions!

 

Yes, I entered 40 or maybe it was 50 strokes per minute for the top speed which is not humanly possible as the trials of Olympias demonstrated. But it just looked so s..l..o..w when I ran it at 30 😁...

 

Yes again, I thought of changing the return speed but didn't get around to it before making the videos. It would be very easy to do in the code. Having said that, in a real model the sweep servos may slow naturally on the power stroke in the water compared to the no-load return. Sea trials would be required to finalize all the variables.

 

Yes again, again, I enter a value for the pause at the start of the code, in terms of "number of 20 msec increments". It can be any integer value; the video uses "12".

 

I went through this exercise to decide if a rowing model would be feasible. My conclusion is that a model could be built, and that software can be easily adapted to tailor the rowing motion to a model's in-water behaviour. So that's great. My one worry is about overheating the sweep servos. I'd definitely select a type with a metal housing, the better to conduct heat away from the motor. In fact, with my mind free-associating while walking the dog, it occurred to me that if I select waterproof servos for the sweep they could sit in an open well in the hull with their housing bottoms actually in the cooling water. 🤪 Not that I'm eager to have a big hole in the bottom of the boat......but if needs must......

Edited December 15, 2021 by Ian_Grant

[Ian_Grant]

Modified the software to incorporate Bedfords' suggestions. The return stroke speed is now multiplied by a variable "returnFactor" which I enter at the start of the program. I have renamed the variable which defines the pause at the end of the power stroke to "powerPause", and  added a new variable "returnPause" which defines a pause at the end of the return stroke. The two can be given different values if desired. Zero is a valid value.

 

In the video below, "returnFactor" is set to 1.5, and both pause variables are set to 5 which yields a pause of 1/10 second but is not really discernible yet. Some value between this and the previous 1/4 sec can be entered later during sea trials. I decreased the cruising strike rate (variable "CSR") to 24 strokes per minute but maximum strike rate (variable "MSR") is still at 40 which is a bit too fast.

 

 

Edited December 4, 2021 by Ian_Grant

[mtaylor]

Looks good, but I think it still needs to be slowed down for both strokes unless you're setting up for "ram speed".  Once you add the scale length to oars, at this speed I think they'll be a blur but that can sorted later.

 

Way back in the lost MSW (before the Big Crash), there was a builder who did a static ship (Roman I think) with rowing oar movement.  Rather impressive it was to see.  

[Bedford]

That's looking really good now. As you said, the power stroke may be naturally slowed by the work load but those servos are very low geared so probably not a whole lot slower. I'm really enjoying this experimental build.

[Ian_Grant]

4 hours ago, Bedford said:

 I'm really enjoying this experimental build.

Thanks!  It's been fun getting it to run, but now I have to get my head back into ship rigging in order to clear my none-too-large model bench for a possible galley build.

 

Cheers!

[Ian_Grant]

Although I'm busy now rigging another ship, I still mull a galley over in my mind as I walk the dog. I've looked into waterproof servos and they are $$$, nor are they truly "waterproof". The IP-67 standard defines a waterproof servo as one that will continue to operate for about 30 minutes while immersed to a few inches, or something like that. Although I was not proposing to fully submerge them, only the lower half of their housings, I worry about the prospect of water getting in where the wires enter which always seems to be at the bottom of one end ie where the motor is, which makes sense. Or past the gasket between the case bottom and centre portions.

 

My latest thought is to connect metal-housed servos to the water via aluminum heatsinks bonded to the housings with thermally conductive adhesive. Either the heatsinks are immersed in water in an internal "well" beneath the servos, or they pass through the hull bottom and there is no wet well. They might be quite vulnerable hanging down while boat is being handled, but on the other hand there may be a torpedo ballast under the keel anyway, which could protect them.

 

It will be many months of further thought before I complete my current build.

 

Happy new year everyone!

[Brinkman]

Speaking of waterproof servos, have you seen how peoply DIY it? I think it's something like filling them with oil and they can be used fully submerged on submarines and the like.

[Richard Braithwaite]

On 10/30/2021 at 4:06 AM, Ian_Grant said:

Hi Richard!  I'm glad you found this, and may I say I'm a great admirer of your gorgeous triere! Of course I had seen your smooth mechanism before but I wanted to try something different. 

 

By the way, I wonder why I get no notifications if someone comments in this log that I started?

 

Update: I've been testing code, overcoming newbie arduino problems and getting used to it. At one point I was stuck for hours trying to get a bunch of nested IF's to do what I wanted! 🤪  I finally got around it by rewriting code to avoid such deep nesting. I just completed writing the program last night but only the first third is tested. As now written, the oar motion will simply be rectangular because I wanted to try to get the jig's oars going to be able to test the turning features etc. I can easily refine the stroke shape later. I  wrote the code to stop the inside oars in a middling turn, and reverse them on a hard turn, whether going forward or backward. Should be interesting. Also, as written, as throttle advances there is an initial range over which the strike rate (oar cycles per minute) is constant but the sweep length gradually increases to full, then a new range over which sweep length stays at full but strike rate increases, to max speed (which would be short duration for actual human rowers). It also occurred to me while walking the dog this morning that there's no reason for the oars to move at the same speed on the power and return strokes; I will try speeding them up a bit on the return stroke to see how it looks.

 

Software provides flexibility, but it also means there are a thousand possible ways to do this. I'd need an actual model to finalize the parameters eg how effective is the rudder for slight course corrections without changing the oar motion, when exactly to reverse oars on a turn, what's a good strike rate for the slower speeds, what's a reasonable strike rate at full speed, etc.

 

Rainy weekend coming up so I will try debugging. Another video to come soon I hope.

Really interested to see how this turns out. My rowing machine is fairly primative in that it describes a constant speed elliptical orbit and will not follow how an actual oarstroke would work when operated by a real human being (particularly during the acceleration phase from a stationary start...) I have been doing some research into this and writing some simulation code (in C++ for speed of execution). the purpose of this exercise is not to support any rowing machine but to gain an greater understanding of oared warships and how they could have been optimized in design.

Some time ago I found a paper online describing a rowing machine model that used a weighted pully system so that the pressure applied during the power stroke (when the oar blade is in the water) is constant from catch to finish (cant find the reference now...) which I thought might be quite interesting..

[Ian_Grant]

That does sound interesting!

 

Working on Preussen for now but I can't get a galley out of my head. I think the sweep servos may be a problem as regards overheating; can't find any torque analog servos with metal case for heatsinking and I've seen too many videos with digital servos whining due to their internal CPU (!!) updating position at up to 400 Hz. Don't want the boat to whine, and digital servos burn more power. A servo with internal 32-bit CPU and 12-bit DAC may be de rigueur in an RC helicopter but seems ridiculous overkill to move oars at 30 strokes per minute......And their prices!!

 

Next summer I want to build a full mock-up to test force required to propel full remes of oars in the pool. Right now I have no idea what torque I need. Starting from full stop would obviously require peak torque, but I could start off at a slower & shorter stroke to limit total power.

 

Also thinking maybe I could buy a plastic analog torque servo and cut a hole in the case next to the motor to get access for metal heatsinking. Not sure if it can be done while leaving all necessary motor supports in place. Only one way to find out!  🤞

 

Once I know a torque value I can select a servo, buy one, and conduct thermal tests under load with a thermistor attached to case. Definitely need more data.

 

 

Edited February 16, 2022 by Ian_Grant

[Ian_Grant]

Came across this interesting article on servos and allowable torque. I expect the "stall torque" which is all that hobby servo manufacturers seem to specify is the max "intermittent" torque at zero speed. Now wondering if I can pry any info from servo vendors about their "continuous" torque curves, or at the least a derating factor. Hoping I can get through to some sort of applications engineer or even better a designer.

 

https://www.motioncontroltips.com/servo-motor-torque-curve/

[Ian_Grant]

On 1/14/2022 at 10:47 AM, silverman834 said:

Speaking of waterproof servos, have you seen how peoply DIY it? I think it's something like filling them with oil and they can be used fully submerged on submarines and the like.

Silverman, I had never heard of that before, but you are right. I found this video about it.

 

 

[Richard Braithwaite]

A couple of figures from the Olympias sea trials that may be of interest (Ref The Trireme Trials 1988 Report on the Anglo-Helenic Sea Trials of Olympias, J F Coates, S K Platis, J.T. Shaw, Oxbow Books)

The first shows a trace of the oar handle and blade of one of the Thranite oarsmen (top tier, who tended to provide most power as they had the least constrained positions):

The next plot is of speed from a standing start (Thranites only). Acceleration and maneuverability are particularly important for this type of vessel so that they could break from a slow moving formation faster than the opposing vessels and so achieve a tactical advantage and get into a position to ram.

You can see that the first few strokes are at a lower rate, accelerating as the boat speed increases and the pressure on the oar blades reduces for a given stroke rate (at higher speeds the inertia of the oars will become more dominant in determining stroke rate).

 

My current simulation code allows you to set a maximum load that the oarsman can apply to the oar handle and then works out the dynamics of the oar handle (and the resulting forces on the boat) accounting for water pressure on the blade and oar inertia.

When I use the data for Olympias with Thranite oarsmen only I get the following match for the trials data:

 

For a working model (it you wanted to make starts more convincing), you already have the ability to vary the rate of the power and recovery parts of the stroke. You might be able to add a sensor for boat speed (gps or spinner?) and adjust stroke rate accordingly?

 

I just noticed that this thranite oarsman achieved a 700mm stoke (the design hoped for 800mm ...), which is similar to the stroke length that my manikin figure is managing on my model (on the more constrained, lower level). I've just posted a GIF animation of him in action on my blog!

 

 

Edited April 28, 2022 by Richard Braithwaite

[Richard Braithwaite]

On 2/16/2022 at 2:29 PM, Ian_Grant said:

That does sound interesting!

 

Working on Preussen for now but I can't get a galley out of my head. I think the sweep servos may be a problem as regards overheating; can't find any torque analog servos with metal case for heatsinking and I've seen too many videos with digital servos whining due to their internal CPU (!!) updating position at up to 400 Hz. Don't want the boat to whine, and digital servos burn more power. A servo with internal 32-bit CPU and 12-bit DAC may be de rigueur in an RC helicopter but seems ridiculous overkill to move oars at 30 strokes per minute......And their prices!!

 

Next summer I want to build a full mock-up to test force required to propel full remes of oars in the pool. Right now I have no idea what torque I need. Starting from full stop would obviously require peak torque, but I could start off at a slower & shorter stroke to limit total power.

 

Also thinking maybe I could buy a plastic analog torque servo and cut a hole in the case next to the motor to get access for metal heatsinking. Not sure if it can be done while leaving all necessary motor supports in place. Only one way to find out!  🤞

 

Once I know a torque value I can select a servo, buy one, and conduct thermal tests under load with a thermistor attached to case. Definitely need more data.

 

 

I did some trials with an early prototype rowing machine. If you go for a "realistic" stoke rate of say 50 spm the speed of the boat is very low (it can never be faster than the oars move through the water!) and the force required (and hence torque on your servos) is trivially small.

A more significant factor determining how strong your servos need to be will be the friction in your rowing machine mechanism.

A couple of pictures of my Mk 1 Galley and its rowing machinery (simple, circular path, constant speed...).

I found, that as the scale speed is so low you need a really calm day if you do the trials outside! 

My calculations suggest that this will still  be the case with a 1:24 scale model of Olympias even with its 170 oars...