Solar Boat 2019

It’s officially an obsession

Following a pretty intensive effort on last year’s SMUD solar regatta entry with CCSF, i’ve dived right back in, but am starting mostly from scratch.

The SMUD regatta is an anual solar boat race near Sacramento, California. There are three events; a 100 yard solar only sprint, a ~200 yard solar only slalom, and a 25 minute battery only endurance race. Read more about it here.

Firstly, i want to really understand the parameters the propellers, motor, and solar panels operate within. To that end, i’ve built a couple dynamometers to test electric motors, mapping out their efficiency across their range operating speeds, while constrained by the power limitations similar to those imposed by an ideally loaded solar panel (~30v and ~15a at MPPT). That data is coming along nicely, and letting me make some good comparisons already. Once a motor is selected, tweaking and tuning of that motor is possible through timing, PWM switching frequency, current limiting, rpm limiting, PID gains etc. All that is made possible by the super tunable VESC speed controller. Hats off to Benjamin Vedder on that one.

Javaprop + OCtave

Propeller design this time around has been must more thorough. Rather than hunting around in JavaProp for something that looks about right and making it, i’ve taken to extending the software with a suite of custom GNU Octave scripts.

One script sweeps across a range of propeller diameters and rotation speeds. It designs a maximum efficiency propeller (for a given water speed) that fits each input parameter, graphs the efficiency and a few other pieces of data. This allows much better birds-eye-view decision making and comparisons between seemingly different operating modes.

Is it best to gear a motor down, accept the ~5% efficiency loss intrinsic there, but get a more efficient propeller at lower rotation speeds? What would it take to direct drive a propeller at a motor’s optimal rpm, and the propeller’s optimal rpm without the gearbox? How much less efficient is that? If less than 5%, the counterintuitive move of selecting a fast spinning, lower efficiency, smaller diameter propeller makes sense!

I’ll factor the motor efficiency curve into a propeller sweep to get a composite parameter-space and find an optimal value that takes this tradeoff into account.

Reverse Engineering

Interestingly, JavaProp is not open source, and a few of the key functions/methods are not completely clear, and use constants built into them that i’d love to get a hold of. To that end, i used a java Decompiler to unpack code from some of the java classes. This let me re-implement the functions in Octave and get more control and confidence out of the simulations. Octave is significantly slower, but the control tradeoff is totally worth it.

Variable Pitch Propeller System?

Another big question is whether there is enough advantage to chase a variable pitch propeller system. In theory it’s better because the angle of attack of the propeller airfoils is always ideal for the combined incoming water speed and rpm. However, the mechanism is likely tough to make small, reliable, stiff, and backlash free. Additionally, having the ability to make smart choices about what angle of attack to have at each moment is great, but it demands that at each moment, a smart angle of attack has been made! What is we choose bad angles of attack and the blade are in a worse position than they’d be without?

I made another JavaProp and Octave script to graph a comparison between two propellers (usually with the same geometry, but that isn’t required). Importantly, there seem to be huge gains at low speed, and moderate gains at very high speeds, but little or nothing in the middle-ground. This of course makes sense. The first couple m/s of boat speed feel a 30%-plus increase in thrust, so i think it’s worth chasing. It’s also a pretty hard thing to design, so the challenge sounds fun :-)

Combined Data

The above image is a combined propeller and motor efficiency map. If we did want to run a direct drive propeller, this graph would be the guide with which we’d pick an RPM and Diameter to develop. This was mostly a matter of establishing workflows, since it seems a gear reduction pays for itself with regard to matching any propeller efficiency point with any motor efficiency point. Maximum system efficiency in the graph is around 65% above, but could be (0.87propeller * 0.92motor * 0.95gear) around 76% efficient with a gear reduction and more efficient motor (like the SK3 260kv tested below) running a more efficient propeller geometry (slower and larger).

This is why we do testing :-)

Either/or Chart

The below chart is the maximum of either a direct drive propeller without a gearbox efficiency hit, or a propeller with a gearbox (but with a more optimal propeller speed/diameter). Even if we assume a 10% energy loss from the gearbox, It clearly shows that a larger, slower prop still wins. The hump centered around the 2200rpm mark is the area where direct drive is better than a gear reduction. It must be noted however, that these are peak efficiencies, and that isn’t the only factor in selecting a propeller. Next i’ll examine the width of acceptable efficiency band for each propeller. We don’t want highly efficient propellers that only work well at a single water speed, we want something that behaves nicely even off the design spec.

Getting Hot

One of the available paths is to design a nacelle that accommodates a motor and gearbox underwater. This would mean the strut can be narrow and only had to be strong enough withstand the thrust and steering forces, since it only has to carry electrical wires, and angle drives are eliminated. A single stage planetary gearbox claims 95% efficiency, and that’s likely better than all the reduction and transfer necessary to get mechanical power down to the propeller (a couple belts, and associated bearings for instance). However, the pod becomes quite a lot bigger. This propeller is 20” in diameter, and the nacelle is around 19” long! The prop is pretty efficient, and is designed to run in a range of 400-700rpm from 0 to 10mph.

One major concern with this is cooling. While the aluminium casing would be well coupled to the water, the motor’s bell rotates, so must be free. That means it requires a liquid or gas atmosphere in which it can rotate. Simulations were run to figure out if the motor would cook itself in this small pocket of air. Airflow and cooling were simulated in Autodesk CFD, and Autodesk Fusion 360. CFD is the more robust simulation, but fusion gives a faster equilibrium result.

The equilibrium temperature from fusion was very troubling (~300F!), along with the discrepancy between simulations (~130f after 25 minutes running simulated in CFD). One thought was to replace the air atmosphere with one of Helium, which has a Thermal Transfer Coefficient over 5 times greater than air! This could be fed via a regulator to the pod, ensuring a slight positive pressure. Any leakage in the nacelle seals would then force helium out, rather than letting water in, and the motor would be significantly cooler due to this much better thermal transfer. The below image is with a helium atmosphere, and identical scale/color limits to the previous image (air atmosphere). While this is still significantly above the safe limits of a motor, it’s also the long-term fusion equilibrium result, which doesn’t represent the reality of a race boat that only operates for a maximum of ~30 minutes.

Off design efficiency

One concern with JavaProp is it’s total lack of awareness or desire to create a generally efficient propeller. Sure the propeller designed via it’s algorithms is pretty much ideal for the exact use set of input parameters, but a boat doesn’t always operate at that point, in fact, likely most of its time is outside of that area. What if the designed propeller is only any good exactly at that point, and falls off a cliff once it’s out of the design area?

I wrote an additional script that creates a new propeller for each point in a matrix of diameters and rpms as in the “parameter space”, but this time it also scans across the off-design boat speeds and integrates the curve, giving a number for the area under the efficiency vs boat speed plot for each propeller. This is much more time consuming, and high density plots take a couple hours to process! The analysis is also a little gross, in that it doesn’t find the exact start of the desired range, it finds the step where it surpasses the low and high limit within a small-ish range. That means there are some jagged edges, but ultimately this plot is about understanding the space, and large scale trends. If more detailed information were desired, once could select a much smaller sample range and increase the resolution. Alternatively, once a propeller is chosen from the space plot, a closer analysis should be done to see what other interesting off-design properties it has.

The image below describes the area under the efficiency curve between setpoints with the design water speed changing. At what design speed does the resultant propeller operate with the best cross-range efficiency? In our application, it looks like around 4mph. The design rpm was held at 400rpm.

This is a similar plot, except the design rpm is changing, instead. The rpm was held at 400rpm.

Crossing the above two graphs (takes forever but) give a map of where the best combination of integrated efficiency is. The results point toward a propeller designed for 3.3mph in the water, spinning at 375rpm. That will yield a propeller that’s overall efficiency is as high as can be. It may perform better at other setpoints, but at this range, it’s got no rival. Can we build it yet?..