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.

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......

I was probably 2.5 years in to get to where you are!😃 Well done!

Thanks for the tip! That works.

Bless his heart, but I can't read his writing 🙁.

Good question. Longridge does not give a size. Peering through my model's case it looks like I used half mm for 1/100 scale, but Paul may have better information.

This is a great model which I've only just stumbled across! Beautiful! Mort, I can answer your question: The rope passes through a hole in the mizzen channel just in front of the port which has the double doors (like a saloon) and ends in a stopper knot.

Your CWM looks great! Nice job, love the whale tail too.

Admiral we have some things in common. I used to RC sail in the 70's/early 80's then not for years as I got a real sailboat. I revived the model to try to interest my son and his cousins when they were 10 or so without result. Then a few years ago I decided to sail it at the cottage for my pleasure. She was reaching directly away from me out on the lake when I realized I was seeing the white deck - how could that be? Answer - she was sinking by the stern!! Fortunately I was able to locate her by snorkeling. The RC set was ok after being packed in rice but the battery was not happy. It turned out that the little balsa block (poor choice of wood by my young self) I epoxied inside the hull to locate the rudder tube had become unglued from the hull after 35 years. Since I had to cut a hole in the deck to get at this I decided to revamp the whole thing from a simple rectangular hatch amidships to something flashier. I also replaced the white deck with some laminate from a counter place and painted the orange hull blue. Here she is...Never got around to painting the black/white camera targets on the crash test dummy 😄.

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?

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.

Bill, I continue to be amazed at your speed. One note, though, those brass "whiskers" across the taller cranes near the top are meant to be removed. Regards, Ian

When I was doing that, the mizzen was so small inside I used a bicycle spoke. Not a great idea when it came time to drill a hole for a pin to hold the cro'jack yard, LOL....

Great start! I too returned to models after the kids got old enough to ignore me 😃. Look forward to more progress. Blue Ensign built this model and also scribed plank lines and changed the copper I think.

Wonderful looking cannons! And those engravings!..... I'm currently working on the Heller Preussen so I have no need of cannons just now, or indeed for a year or two, but I have in my stash the Heller Soleil Royale in which the cannon barrels are nicely detailed but rather too small in diameter. You might be able to sell quite a few of an improved version to builders of this, I won't say popular, but well known kit. Regards, Ian

Very nice model!

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.😀😜

Wow, very nice catheads Daniel! And I love all the crew members on your gun decks. You should consider doing a cutaway on one side (or maybe get Kevin to make a part-hull side in clear resin? 😉) to show your outstanding detail.

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.

Thanks!

Yes, #340 is the "marines' walk". She is looking good!

Bill, your photo of the "next mess" reminds me: to forewarn you, the marine's walk has some slots among its grid surface for the mainstay and main preventer stay collars to pass through it. Their locations are wrong, given that these stays pass to the right of the foremast (which is why there are no boarding pikes on that side of the mast) and are not centred. If you use Heller's slots you'll have a kink in these high tension lines. Blue Ensign had a detailed description of this on the, all together now, "old Pete Coleman Victory site". Don't glue the walk in until you have tested the alignment to the mainmast and shifted the slots. Also I seem to recall some difficulty getting part 358 installed around the necessarily previously installed bowsprit gammoning (see Longridge pg 225) but the details are foggy. I forget the sequence I used. Try some dry assemblies to prevent getting into a corner. 🙂 Did you happen to buy Daniel's resin knighthead? Whether or no, it is best to attach the relevant blocks to the front of the knightheads now because access is more difficult after this assembly stage is completed. See Longridge pg 266 Plan 10 for list of purchases which use these blocks.

Nice buckets! Those boxes at the taffrail are the flag lockers, which are just a bunch of cubby holes with a canvas flap over the front face, not a wooden hinged lid on top. The blobs of styrene supplied by Heller are unappealing. I copied Blue Ensign on the old Pete Coleman site, and cut the front off one, filling it with an array of short lengths of square brass tubing. I put coloured bits of toothpicks in to simulate folded signal flags. The canvas flaps were simulated with thin bandage tape, one being open to show the flags. Here is a shot from the build. The real locker has many more cubbies, but I called it a day at this point. I could only find this shot of the real thing:

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.

Doh! We spent our summer camping trip on Superior west of the Soo within sight of Whitefish point but I never heard of this museum. Oh well the border was closed anyway. Next time for sure!