Press "Enter" to skip to content

Roko.ca Posts

AUV Thrust Module Design Progress

A quick update on some design work I’ve been picking away at recently. I’ve managed to roughly place all the parts for the drivetrain in the thrust module and started work on the control fin motor/gear layout. Still all subject to change, but it looks like I’ll be able to fit everything I need in the tail cone.

Cut-away view of the work in progress AUV propulsion module.
Cut-away view of the work in progress AUV propulsion module.

Next step of this design is to figure how to seal the control surface shafts. Ideally, those will be magnetic couplers as well, but I have to analyze how much torque will be required, and how much I can transmit with a small magnetic coupler. Failing that, I’ll design it to use Ikelite glands — I have an Ikelite camera case which uses these, and the performance seems good.

I found a source for BLDC gear motors that run off 24 volts and aren’t insanely expensive, which I’m hoping to use for the control surfaces. Standard hobby servos run of much lower voltages, and I was hoping to implement my own control scheme for the motors — More on that later, as I’ve ordered one motor to test out to verify it will actually be suitable.

Leave a Comment

A Lesson in Rigidity

After getting some metal stock this week, I was anxiously waiting for the weekend so I could start machining some prototypes for the AUV’s universal ring bulkheads.

Now, I need to throw out a disclaimer — I’m not an expert machinist by any stretch of the imagination. In fact, quite the opposite and I’m learning as I go, which is what this post is all about.

Having read through different things on feeds and speeds, I set up some programs with what I thought were somewhat aggressive cuts (for the Sherline) that I hoped the machine could handle — 1mm depth with a 3/8″ end mill into 6061 aluminum, with a feed of about 260 mm/minute. I’d read complaints about the rigidity of the 2000 series mill, but figured I’d try anyways.

The intent was to mill out the center of a 6″ diameter piece of Aluminum, so I could use the 3.1″ Sherline chuck to clamp from the inside onto the lathe for all the turning operations I’d need to do. I was hoping to salvage the inside chunk, since the stock wasn’t cheap. I planned on accomplishing this by milling in half way from one side, then flipping the part and milling in from the other side.

Now, the Sherline motor handled the first cuts like a champ. The 2000 series vertical column? Not so much. Unfortunately, as the machine went through the cuts, it put enough stress on the vertical column causing it to pivot along the vertical axis and throwing it off center. You can see the steps caused by this in the picture below, due to the column gradually pivoting at each cut, throwing off the alignment more and more. Luckily this was a roughing cut, so the the stock wasn’t lost.

Stepped profile caused by the wandering alignment of the mill's vertical column
Stepped profile caused by the wandering alignment of the mill’s vertical column

Eventually, I tightened the column well enough that it finished the last cuts without too much added deflection. Figuring I could tighten up the mill just a little bit more before flipping the part and trying the other side, I put the wrench on again, applied some torque and snapped the bolt clean off, leaving me with a Z-axis no longer attached to my mill, and the mill out of commission!

Not to be deterred, I figured I would try and see how well the the part fit in the lathe’s chuck using the pocket that was milled in one side. Not too bad, I must say:

6" diameter part on a 3,1" diameter chuck
6″ diameter part on a 3,1″ diameter chuck

I then screwed the chuck inot the lathe. I had to use two riser blocks to get clearance on the large part, causing some inappropriate cutter geometry. I needed that much offset to get the part below 6″ diameter, after which the intent is to only use a single riser block, and some special tool holders I’m planning to make in order to hold tools perpendicular to the part.

Turning large diameter parts
Turning large diameter parts

Turning the large diameter part was easier than I’d thought I used 0.2mm depth of cut and a 60 mm/min feed rate, which the machine handled well. The part stayed solidly affixed to the chuck, even when I accidentally crashed the tool into the part.

Now that I’ve gotten the stock cut such that I can mount it on the lathe, and turn it freely on the lathe, hopefully soon I’ll be able to start working it to the final shape. Unfortunately, I ran out of time to machine today and had to start cleaning up at this point.

Next steps, I’ll have to fix the mill. From what I’ve read online, the rigid column Sherlines fare much, much better than the fancy articulating column mills, and luckily the part to do the conversion is fairly inexpensive. Although perhaps the Sherline isn’t the right tool for machining large parts en-masse, for the quantities of parts I need and considering it’s what I already had available, it looks like it’ll fit my needs just fine.

Leave a Comment

AUV Bulkhead Rings

One of the goals I’ve had for most of my AUV project was to make it as modular as possible, which would allow future upgrades and change of mission in the future — Want to take video? Swap out the sonar with a video module. Need better control in the water column for inspecting things? Add lateral thruster modules. Want to take water quality samples? Swap out the sonar module for a water quality sensor module… And the list goes on.

To achieve this, years ago I came up with an idea for a universal bulkhead design, which would allow each module to plug into any other, provided that the electrical interfaces matched through the bulkheads. The design would also allow mix-and-matching of flooded and non-flooded compartments, depending on the payload and mission configuration.

AUV Universal Bulkhead Ring with o-rings

The design is fairly simple, each bulkhead essentially consists of two identical rings with a flat plate bulkhead sandwiched in between them. The bulkheads are screwed together and O-rings keep everything sealed up nice and tight. The compartment tubes are held into place by a series of radial screws (not properly shown in the photo above) which don’t clamp down on the tube (causing stress points in the material) but rather act as pins to prevent the tube from sliding out.

One of the challenged was getting the design to play nicely with standard cast acrylic tubing, with its loose tolerances. This necessitates usage of large diameter o-rings to make up for the variance in tube diameters. One option could have been to machine the acrylic tube’s inside diameter to appropriate tolerance, but I decided that the difficulty of doing so with the tools available to me outweighed the convenience of using stock cast acrylic profiles.

 

AUV Universal Bulkhead Assembly
AUV Universal Bulkhead Assembly
Leave a Comment

Setting up a CNC Mill and Lathe Part 2

I didn’t write a post for it, but I did the CNC conversion on the Mill and Lathe about a month back, and for the most part, it went well. This weekend, I finally had enough spare time to get back to working on getting it actually up and running. I’ve somewhat trammed the machine and gotten rid of most of the backlash, but will need to do a bit more work on that before working on real parts — The big “fun” thing I did was get some g-code running on the mill, and do some practice engravings with a sharpie and some paper. Things are working pretty well, and there’s definitely something cathartic about the sound of the steppers working through circular profiles. (Even if the knobs on the handwheels are rattling somewhat. I’ll need to tape those down)

eCam Engraving Test
eCam Engraving Test

For a CAM program, I’ve been looking for something that can handle non-trivial profiles on the lathe, so that I can use it to machine the profiles of the AUV’s Kort nozzle and nose-cone. Affordable lathe CAM programs are hard to find, but one that has piqued my curiosity is eCam — I’m playing around with the trial version right now, and it seems to be working well for my uses so I think I’ll shell out and purchase a copy once I’ve confirmed it can output effectively to LinuxCNC for some specific uses cases I have. It’s definitely in the lower price range for CAM software, at least for hobby usage.

Some minor modifications to eCam’s post-processor were needed for the basic engraving routine:

  • Update the “Head New Program” section by removing the line “O{PRG_NUM}({PRG_NAME})” and splitting the line “G0G28G91Z0” into three unique lines, one for each G code command. (LinuxCNC doesn’t support multiple G-code commands with a coordinate in a single line. Multiple G-code commands without coordinates appear to be fine)
  • Disable incremental moves.
CNC Testing, "Engraving" With a Sharpie.
CNC Testing, “Engraving” With a Sharpie.

Loading up the code was pretty painless, and the milling machine is working well so far! The lathe tests are showing I need to do a bit more work on the postprocessor to get it to play nicely with LinuxCNC, but it doesn’t look like it will be too onerous.

I’ll try to get some materials soon, after which if all goes well I can start working on some of the AUV’s structural components.

Leave a Comment

Doppler Velocity Log Acoustic Windows

Although I haven’t posted anything in the past month, I have been working away at the AUV here and there between work and some much-needed vacation. I’m making some decent progress in design and setting up for manufacture. A couple of the big things I’m working on are some detailed design work on an acoustic modem, and putting some finishing touches on my CNC machines to start building some of the mechanical components for this project. I’ll post an update on those topics when I have some more substantial progress.

In the meantime, I was digging for some files and came across some earlier CFD results, specifically pertaining to the Doppler Velocity Log (DVL) and the flow of water around it. A DVL works by sending sonar pulses out at multiple off-nadir angles and measuring the doppler shift in the return signal. If the AUV is stationary, there is no Doppler shift, but if there is motion a Doppler shift is induced which can be measured to determine the motion of the AUV underwater in lieu of not being able to get a GPS lock.

Water flow around the DVL Pockets.
Water flow around the DVL Pockets.

Due to the relatively small diameter of the AUV, and the size of the DVL transducers, they needed to be pocketed in the hull. I ran some simulations to determine the way water would flow, and as expected there is some recirculation induced by the pockets. This not only adds drag but potentially increases flow noise on the transducer itself.

As such, I’ve modified the design slightly and will attempt to put a LDPE window to hopefully improve the flow. LDPE is a type of plastic which has an acoustic impedance fairly close to water, so should be mostly transparent to the sonar wave. Modeling the shape proved an interesting challenge, but haveing done so will enable to me to fairly easily cut out the shape from flat sheet using the CNC.

DVL Acoustic Windows (Bottom left transducer cavity exposed)
DVL Acoustic Windows (Bottom left transducer cavity exposed)

Hopefully, some more updates will be forthcoming in the next couple of weeks!

Leave a Comment

Setting up a CNC Mill and Lathe Part 1

One of the key factors to getting my AUV project underway was converting my mill and lathe to CNC, something I’ve been meaning to do for a while. After much research, I settled on the Gecko 540 and some decent steppers and put in a parts order.

With those parts en-route, I talked getting LinuxCNC running on a machine from 2006 — An AMD 64 X2 3800+ based computer, with a Radeon X850 video card. Initially trying the latest and greatest LinuxCNC, I got atrocious latency results. I ended up trying out old releases, starting with 8.04 (Hardy Heron was a flash from the past!) up to 12.04 and settled on 10.04 as the best compromise in terms of latency performance vs new distro. After a lot of painstaking work, I finally got good latency results:

Final Latency Test Results
Final Latency Test Results

It ended up being a bit of a paint to tweak everything just right to minimize latency spikes and in the end, I think I’ve actually made my BIOS inaccessible with a USB Keyboard, so next time I want to get into it I’ll need to scrounge up an old PS2 keyboard… To get this relic of a computer running reliably, I ended up having to:

  • Install of the 10.04 ISO and then update the LinuxCNC install to 2.6
  • Turn off _everything_ in the BIOS, or at least set it to manual (e.g. overclocking, power savings)
  • Modify Grub to pass “acpi=disable isolcpu=1” plus the additional options in the next link
  • Applying the IRQ tweaks listed here (This dropped the regular latency by an order of magnitude!)
  • Still using the stock open-source Radeon driver — Vesa improved the “resting” latency by a factor of 2, but when running glxgears it popped back to the same range.

The frustrating part is that I still experience large spikes when opening Firefox or other applications while 2x glxgears are running, I suspect due to some HDD access issue. Either way, I’m not planning on using this machine for anything else while machining, so hopefully I won’t run into problems with that. Without opening large programs and running 2x glxgears, I’m getting a latency of about 5000ns — Not too bad!

 

 

 

Leave a Comment

Musing on Star Trackers

Several years back, I was intrigued by the concept of the “PicoSat” form factor, which is smaller than a CubeSats that instead of costing the same as a house to launch, only cost approximately the price of a car to launch. A few had launched as sub-payloads on a Dnepr, including the $50 Satellite (Eagle-2) which operated for a surprisingly long time.

Gears in my head immediately began churning for a thought exercise on how small you could make things to fit on a PicoSat — Maxon EC10 flat based reaction wheels, miniaturised ablative plasma thrusters, tiny mirror-based zoom lenses, and as the title suggest, star trackers.

Remote sensing satellites need extremely good pointing accuracy in order to take images of what they need to on the ground. While other small scientific missions can typically make do with basic orientation based on sun detection, earth/horizon detection or even passively through gravity gradients, using magnets and hysteresis rods, to be able to take a decent resolution image of anything on the earth, you need better pointing accuracy. that’s where star trackers come in.

Since the stars are relatively stationary in the sky, as with the old days of sail, they can be used for navigation and specifically for highly precise orientation of satellites. The positions of stars in the sky are very well known, including their small relative motion.

As a thought exercise, and as a way to learn some more Python, I wrote a small star tracker program that assumed an input from a 640×480 imager with a small lens in front. I didn’t do any work into determining the actual SNR of the stars as my focus was primarily on the algorithm. Detecting faint stars in orbit is a challenge in and of itself which I won’t address in too much detail in this post. This was all done years ago, so I’m writing mostly off of memory and comments I left scattered around my Python code…

I downloaded the publicly available Hipparcos star catalogue as a basis for my star tracker, which contains the position at the epoch of measurement, as well as their relative motion so I could adjust their positions to the current date.  This catalogue was processed to make a unique catalogue for the star tracker, which included not only position but also relational data comparing each star to neighbouring stars.

For test images, I simply used Stellarium with a representative rectilinear lens configuration. I output the screenshot, loaded it into python and ran the algorithm.

Before I go any further, I want to point to the references at the bottom, as they were used to guide the process of development of this code, notably reference 1 is a great resource and worth a read if you’re interested in learning more about star trackers! A lot of the methods outlined in that document are what I used to develop this code.

The methodology I used was as follows. The code was written to eventually be translated to C for a small microcontroller, so I avoided use of libraries in the core algorithm which wouldn’t have simple, high-performance comparable libraries in the embedded C world.

  1. Detect centers of stars using a weighted average blobing algorithm
  2. Step through stars in order from brightest to least bright, and calculate a “triad” for each:
    1. Find two next brightest stars within a specified distance
    2. Based on the two vectors made up by the two stars centered on the origin star, create a unique relational triad for comparison
  3. After all triads are computed, compare to the catalogue to find the closest match and identify stars and their positions
    1. Perform this iteratively, as multiple hits per star are gained, and there are false alarms
    2. Sort detected stars based on how close the calculated triad was to the matched catalogue value
  4. Starting with the closest match, perform vector space rotation to determine exact match. Refine calculated orientation by running through subsequent matches.
Sample Results, Centred on HIP59928
Sample Results, Centered on HIP59928

Results of the full algorithm. Stars found by blobbing are circled in green, with a red dot in their centre and with a yellow index number assigned. Red lines indicate all the triads considered in the match, and the detected star Hipparcos catalogue numbers are shown in white/blue. Only stars in the center yellow rectangle were used as the basis for triads, as anything outside of that risked having the next adjacent bright star out of frame, leading to erroneous results. Pretty accurate overall!

Algorithm Outputs Centred on HIP3821
Algorithm Outputs Centred on HIP3821

Now, this algorithm isn’t sufficient for a real star tracker, as several problems would still need to be addressed:

  • Planets
  • Noise in image due to low SNR
  • Real star-trackers are often de-focused to create larger blurry stars to aide with centroiding. This would require adjustments.
  • How to deal with bright objects (e.g. sun). Usually accomplished with shrouds
  • Rotational accuracy is usually not great with star trackers, requiring two pointing in different directions to get peak accuracy
  • etc….

References:

  1. Raveesh Kandylil – Attitude Determination Software for a Star Sensor
  2. Wiley J. Larson and James R. Wertz, Space Mission Analysis and Design (There’s a newer version: Space Mission Engineering: The new SMAD)
Leave a Comment

Thrust Module and Environmental Sealing

Preliminary Thrust Module
Preliminary Thrust Module Design

Given the drag results from the CFD analysis, it became possible to begin more rigorous design work on the thrust module, namely to create detailed propeller designs, motor selection and coupling the two. I’ve done some preliminary propeller analysis using JavaProp and have been fiddling with OpenProp to get an idea of the efficiency and rpm of various propeller designs to meet the thrust requirements – Those parameters are sufficient for estimating the sustained torque on the motor. Given sustained torque and rpm, it became easier to size the motor required to drive the AUV at its design points.

One of the tradeoffs made in the AUV design is how to seal the motor from the external environment. Several options were considered, including traditional pump shaft seals, magnetic coupling, and simply running a brushless motor exposed to the elements. All are valid options depending upon the goals of one’s project, but ultimately I settled on using magnetic coupling for a number of key reasons:

Pros:

  • Completely sealed from the external environment, with a lower probability of leakage than a rotary shaft seal. This is a bonus if pressure compensation is needed (e.g. oil filling), as that reduces the probability of environmental contamination
  • Likely no need for pressure compensation at design depth. (Depending upon isolation can design)
  • Acts as a clutch to save the drivetrain from excess torque and stalling
  • No friction losses as with shaft seal
  • Motor is protected from corrosion in ambient environment

Cons:

  • More complicated design
  • Requires precision machining for precise alignment to avoid strong magnetic forces perpendicular to the shaft (the inside magnetic ring essentially sits in an unstable null)
  • Potential eddy-current losses in the surrounding structure and the isolation can if made of metal.
  • Motor needs to be cooled to ambient environment (easy)
AUV Parts _ Magnetic Coupler
Simplified Magnetic Coupler — Isolation can in dark grey, outer ring in dark blue, inner ring in burgundy.

One challenge is designing the isolation can, illustrated in dark grey above. This is the component that isolates the external environment from the internal. The isolation can needs to be as thin as possible, yet as strong as possible to support the pressures acting upon it. Metal seems to be a natural choice, but the rotating magnets will induce eddy currents resulting in reduced efficiency. I’d like to avoid this if possible. I’m thinking of using an engineering plastic such as acetal with an internal pressure design, as analysis indicates that it will stand up to the required pressures without needing pressure compensation.

Past experience with machining thin wall features in acetal indicates that I need to approach this with caution. The extrusion process used to create the stock plastic rods I buy causes a significant amount of stress within the acetal which can cause warping during machining. I will attempt to anneal the acetal prior to machining to see if that will help. Another option I’m considering is casting the isolation can with rigid polyurethane, epoxy or fiberglass composite.

Knowing the torque limits of the drivetrain, and the torque requirements of the propeller, I carried out some analysis on coupler designs using the Finite Element Magnetic Methods (FEMM) software package. The great thing about this software is that I can import DXF files straight from CAD, so I can design, simulate, tweak and update and re-simulate, allowing me to experiment with several design permutations.

2D Simulation of Magnetic Coupler, rotated to point of maximum torque,
2D Simulation of Magnetic Coupler, rotated to point of maximum torque

The rough configuration I’m considering is shown in the simulation results above. The magnets are arranged in an alternating north-south configuration (i.e. each magnet is polarized opposite to its neighbour). This was done so that as the delta angle between the inside and outside increases  with applied torque, the opposite polarized adjacent magnet would provide a repelling force, preventing free rotation. I ran through a series of different angles, and the peak torque occurred when the delta angle between the inner and outer elements was half the angular separation of the magnets. (22.5 degrees for magnets spaced at 45 degrees). The chart below shows the resulting torque vs angle curve for a similar design to that depicted above

 

Another key parameter is that the outside of the outer ring should be magnetic steel. As shown in the simulation, this keeps the magnetic field contained (which should reduce eddy currents in the aluminum tail cone) and actually increases torque in the coupler

Some final tweaks need to be made to the design to match the peak torque of the coupler to that of the motor and gears — As long as the coupler torque is higher than the propulsion service torque and below the max torque of the motor/gears, it should act as failsafe clutch.

With the rough size of the coupler set, now I can put some more effort into designing the rest of the thruster module, to see how I can fit everything I need inside of it — The main motor, the 4x rudder motors and drive electronics.

Leave a Comment

QTTX 131600 Heavy Duty Flat Car

I’ll admit I’ve always been a train geek, and have recently started collecting some N-Scale trains but unfortunately living in Vancouver I don’t have room for a permanent layout.

When I first discovered Onshape, the project I set out on to learn and test the tool was creating a model of one of my favorite rail cars, a QTTX 131600 series 12-axle heavy duty flat car.  (I didn’t feel like going through the hassle of getting permission to post a real photo here, but there are plenty of great photos at that link). The goal was to attempt to 3D print the design to see how well it would turn out. This is just a quick summary, with a more detailed build thread up at n-scale forums.

First up, I modeled the buckeye trucks. These specific roller bearing buckeye trucks are not readily available in N-Scale, so I had to design my own. Furthermore, the mounting height had to be non-standard so that I could stuff them under the bolster mechanism. I ended up using several overlay photos, combined with the QTTX131600 rough dimensions from TTX’ materials that I dug up after some research. This took a lot of messing around with, but the end result was pretty good. Below is an early version of the truck.

Roller Bearing Buckeye Truck
Roller Bearing Buckeye Truck

The rest of the flat progressed fairly well. The aim was to make it accurate, rigid, yet with as little material as possible, as 3D printing can be expensive. Again using plenty of reference photos and dimensions that I found while scouring the internet, I came up with something pretty close. I had to make a couple of alterations underneath the body to enable smooth flow over un-prototypical 11″ radius curves and omitted any of the hidden air brake equipment. I also whipped up a quick pressure vessel load. I used tiny magnets embedded in the deck and the load supports to keep tings in place.

QTTX131600 heavy duty flat car, with load.
QTTX131600 heavy duty flat car, with a load.

After multiple iterations with revisions here and there trying to stiffen up thin features so they’d survive the 3D printing and cleaning process, I sent it off to Shapeways to be printed. After a tense couple of weeks, I finally got the parts back in the mail!

QTTX 131600 3D Printed Parts
QTTX 131600 3D Printed Parts

The parts came out well, and even the thin features like hand rails, hand brake and the ladder survived the process although not my handling — I had to glue some back on). The features are incredibly delicate, at sub-millimeter dimensions. Some of them I beefed up to non-prototypical dimensions, but they look well regardless.

First, I assembled the trucks and bolsters to test how they rolled. The first version trucks were a bit tight, so did not roll as smoothly as I would have wanted. I eventually printed another set of trucks with looser tolerances which performed much better.

Buckeye Trucks
Buckeye Trucks

After playing around with the fit of all the parts, I cleaned heavily (I used a combination of hot water, simple green, and an ultrasonic cleaner to try and de-grease the residue left over from printing. I hear Bestine is the best way to go, but didn’t have any readily available and am generally not keen on overly harsh substances if I don’t absolutely need them (not that simple green is harmless, but I had it on-hand for servicing scuba regulators).

Painting was a learning experience, as I had to get an airbrush and learn how to paint! I used general art grade acrylics as opposed to any model specific paint and attempted to mix my own colours. The big mistake I made was not using a suitable primer, as I found certain colours (notably the yellow blend I used) would run, likely because of something in the white paint. Any mixtures without white adhered much better. The second big mistake I made was being bit heavy handed as opposed to using thin coats. I ended up going several itterations of painting, and at one point completely  stripped the paint with alcohol and started from scratch. A warning here is that alcohol can warp the parts, but luckily I designed the deck and frame with registration pins to maintain the correct curvature when properly assembled.

Finished 3D Printed QTTX131600 Flat car
Finished 3D Printed QTTX131600 Flat car

The end result wasn’t too bad! I definitely learned a lot along the way, the paint job isn’t perfect, but I’m happy with how it turned out. There are some artifacts showing from the 3D printing process, but overall it’s pretty good and smooth looking. It looks great being pulled behind an ES44AC. I’m not sure if I’ll venture down the road of making any other train cars (I have enough on my plate with work and the AUV project as it is), but it was an interesting project. I may, however, attempt to see how much of this I can reproduce on my mill, once I get it converted to CNC.

If anyone’s interested, I’ve made the models available for purchase on Shapeways:

N-Scale QTTX 131600 Series Heavy Duty Flatcar

N-Scale Roller-Bearing Buckeye Truck (Modified for a generic ride height for use on other cars)

N-Scale Pressure Vessel Load

 

Leave a Comment

Preliminary CFD Results

This post is jumping into the middle of things, as a huge amount of work has gone into getting the AUV design this far, with several revisions of the design and some background work on the sonar to determine how much AUV I’ll actually need to carry it.

A very preliminary design choice was the dimensions of the AUV. The length will be driven by module and payload lengths, leaving the diameter as something needing a tradeoff between how much I could compact the module electronics vs what I could build. I settled on an outside diameter of 5.5 inches, driven largely by the size parts I can realistically make on my small lathe. I would have preferred a larger diameter, but that’s the way the cookie crumbles. Interestingly, with a 5 inch ID (0.25-inch wall thickness), I can just fit 8x 165AH LiFePO4 cells for a 24 volt, 360 Watt-hour battery.

Why imperial units for the diameter when most of the rest of the design is metric? That’s driven by the availability of stock acrylic and aluminum tubing to be used as the main pressure hull body components. (Flooded modules will likely just be fiberglass). Mixing imperial and metric is just a necessary part of life up in Canada. Sometimes with poor results.

Initial Hull Shape
Initial Hull Shape

Knowing the basic dimensions, I’ve been working on detailed 3D CAD models of the entire AUV design, refining the shape and design of the critical components including the Doppler Velocity Log (DVL), drive section, and the universal bulkhead rings (more on those later). The end result is a rough shape of what the AUV will look like in the end. This design will be refined significantly, but is good enough as a starting point, and is shown above. (Note that the antenna on the top wasn’t exported into the flow simulations)

I set up some simulations in OpenFOAM to estimate the drag and flow around the AUV — The goal being to determine enough information to optimize the propulsion design. I’ve been experimenting with both the simpleFoam and pimpleFoam solver. The computational requirements to get a fine enough mesh  to resolve the features properly proved difficult on my home laptop, so I stood up a server on AWS to handle the simulations — After much experimentation with setting up OpenFOAM cases, the AUV hull design, boundary conditions, and meshing, I finally got things set up well enough to run at a high level of detail with a configuration I felt I could trust. 48 hours later, I had a result. I probably could have introduced larger timesteps into the pimpleFoam solver (the maximum Courant number was set to 25), so I’ll experiment with that on future runs.

 

 

 

The plot above shows the flow over the stern of the AUV. The Reynolds number is fairly high in this design, leading to turbulent flow, and some strange flow along the stern, where you can see it circulating near the surface. The drag pressures appear to settle within 0.4 or so seconds, with a total simulation time of 1 second. The time-steps were dynamic, so prior to settling were very short to avoid the solution diverging. Curiously, the viscous drag remains steady, but the pressure drag is somewhat unsteady.

Plot of the viscous and pressure forces converging over successive iterations.
Plot of the viscous and pressure forces converging over successive iterations.

Previous results had already led me to reduce the tail angle in an attempt to reduce the wake, but ultimately I think this will have to do as narrowing the tail angle too much will result in other design challenges in terms of length of the thrust module.

Streamlines and pressure distribution along hull
Streamlines and pressure distribution along hull

Apart from estimating the drag on the hull, the really cool thing is I can determine the inflow velocity at the propeller disc. Since the hull inevitably has a negative impact on the water speed, designing a propeller for a water flow equal to the vehicle velocity won’t produce an optimal design. The simulation allowed me to extract the velocity profile, which I can feed into propeller design to further optimize the design. If time allows I may optimize the nozzle (it’s currently a vanilla Kort nozzle). However, the purpose of the nozzle in this design isn’t just to attempt to improve the performance, but also to provide a safety guard to protect wildlife and support divers during testing, as well as to reduce the probability of entanglement.

From the results, the hull has a significant impact on the inflow. The Kort nozzle does increase the speed a bit around the propeller tips, but closing into the propeller hub the velocity drops sharply.

Axial velocity through propeller disc
Axial velocity through propeller disc

Interestingly, the horizontal tangential (y-axis) velocity is low but produces an interesting plot showing that the flow is not perfectly axial, but slightly canted inwards. Note that the scale of this image is different than above. This is mostly included because I believed it was a cool picture.

Horizontal tangential flow
Horizontal tangential flow

Of course, I’m not a CFD expert and am learning things as I go, so I need to take these results with a grain of salt. The results seem to be within the order of magnitude of what I can find in literature, so they’re good enough for the next steps in the design process.

Next steps in the CFD work will be verifying the control surface size is sufficient enough to provide good control authority, and to size the motors required to turn them. So far the control surfaces have just been eyeballed, so I’ll have to do some initial calculations to determine what’s required, adjust the design, and simulate.

Leave a Comment