Open source underwater glider

A versatile autonomous environmental drone using a buoyancy engine

Similar projects worth following
There has been a breakthrough with low cost autonomous drones and as this capability has matured a wide range of hobby and commercial applications have developed. There are no affordable extended duration underwater exploration platforms and this project aims to address this need.

Utilising commodity hardware, 3D printed parts and an open-source autopilot, I aim to produce a low cost and versatile underwater glider capable of extended missions of up to weeks at a time. I hope that by having this platform available, it would reduce the cost of underwater projects for all, from hobbyists, amateur scientists to seafood farmers



  1. Designing the underwater glider
  2. Printing and assembly
  3. Testing movement assemblies
  4. Component selection
  5. Schematic creation
  6. Testing specifications
  7. PCB Design
  8. PCBs and soldering
  9. Waterproofing problems
  10. Exams are over
  11. Buoyancy engine updates
  12. Design process transparency
  13. Glider simulation using Unity3d
  14. Second generation glider completed
  15. Underwater testing
  16. PCB modifications
  17. Underwater gliding
  18. Designing third generation hardware
  19. PCB developments

The CAD model

The model is viewable on the Onshape online platform here (requires webGL)


Why a glider?

Traditional unmanned underwater vehicles depend upon active propulsion, limiting their range and runtime, making them unsuitable for long duration monitoring missions. Underwater gliders use a buoyancy engine to change the mass of the glider, allowing them to ascend and descend through the water. With power only being used to power the engine intermittently, gliders can typically run for weeks or months without recharge, making them ideal for environmental monitoring. Yet there are few commercial solutions available (and those that are available are very expensive) and even fewer hobbyist projects exist.

As underwater gliders travel slowly through the water, they disturb the surrounding water very little, allowing for accurate and reliable data recording. Underwater gliders are normally AUVs (Autonomous Underwater Vehicles) and can run a pre-determined route without requiring human interaction. Their low speeds and autonomy, combined with long battery life, make underwater gliders ideal for long duration, environmental monitoring missions, capable of recording dissolved gas levels, pH, temperature and optical sensing (for oceanic surveying and sealife recording).

The glider is open-source, with 3D printed components combined with readily available hardware, allowing it to be assembled for a low cost. Given the openness of the project, the project could be forked to produce alternative designs suited to particular scenarios. For instance; changing the tubing to aluminium to become a deep sea glider; using a unique sensor array for specialised applications; changing the buoyancy engine size to increase speed.

I am looking to use the open-source ArduSub (based upon the popular ArduPilot) autopilot platform, allowing the glider to be controlled using a standardised interface.

With this technology available, there would be a wide variety of uses. For instance, with increasing interest in product transparency and traceability, environmental monitoring is becoming increasingly important; a kelp farmer could use the glider to monitor water conditions (temperature/pH/nutrition levels/pollution) during a season of growth and push the measurements to a blockchain. The kelp/seafood could be packaged with a QR code, which would direct you to a web frontend, presenting the conditions during the season of growth. The use of the blockchain for measurement storage would remove the chance of measurement tampering, so the consumer would know both the conditions that their food grew in and what they’re eating.

Above: A block diagram outlining the how the glider could be used for product traceability


The buoyancy engine that I have designed uses a threaded rod to move the ends of the syringes when rotated by a stepper motor, causing the plungers to take in water. When water is taken in, the volume of the glider remains constant, but the overall mass increases, therefore the overall density of the glider increases and the glider becomes less buoyant.

At the centre of the glider will be a mass that controls pitch and roll. The mass shall be composed of Lithium ion batteries and steel rods, to form a substantial mass, so that it has sufficient control over the glider. The mass shall control the pitch and roll of the glider. The pitch will be dictated by a stepper motor connected by a threaded...

Read more »


Attribution-NonCommercial-ShareAlike 4.0 International

license - 20.36 kB - 04/26/2017 at 12:51



The eagle schematic

sch - 387.56 kB - 04/30/2017 at 08:29



The eagle board

brd - 136.03 kB - 05/18/2017 at 11:19


Standard Tesselated Geometry - 95.20 kB - 04/15/2017 at 22:29


Standard Tesselated Geometry - 1.05 MB - 04/15/2017 at 22:29


View all 39 files

  • 1 × Printed parts Print all the parts in the "files" section, print the amount indicated
  • 1 × 84mm ID 90mm Acrylic tubing 1000mm The main tubing
  • 4 × 74mm ID 5mm C/S Nitrile o-rings Seals for the central compartment of the glider
  • 1 × 49mm ID 4mm C/S Nitrite o-rings Used to seal the tail section
  • 2 × 10mm aluminium tubing (1 meter lengths) Used in general assembly

View all 48 components

  • PCB development

    Alex Williams2 days ago 1 comment

    I realised that the production of PCBs will take a couple of weeks, so I have prioritised the redesign of the PCBs over the last few days. This version of the PCB is designed to work in conjunction with the Fathom-S tether interface from Blue Robotics. The control board uses the serial output from the Fathom-S to program the control board and allows for remote communication. The Fathom-S board provides a serial port connection over a tether length of 600+ metres, compared to the glider's current 5 metre limit (USB communication limit). Additionally, the control board passes through the battery supply to the Fathom-S so that the control board uses the 5V supply that the Fathom-S board produces with its 7805 regulator. Programming the control board via the Fathom-S interface requires a dedicated serial port, so in order to use another serial device (compass or dissolved oxygen sensor) more dedicated serial ports are required. Therefore I am now using an ATMEGA2560 as opposed to the ATMEGA328P, providing up to 4 UART connections (and much more flash memory; 256kB compared to 32kB). Other changes include a dedicated 16MHz crystal and using the MPU6050 breakout board as opposed to the LSM9DS0 (Still out of stock until November).

    Although this control board can be used as a standalone autopilot, with the MPU6050 and external pressure sensor/compass/GPS, the board can also be used as a slave board for an external autopilot (such as Pixhawk). To allow this, there is a set of header pins towards the left of the board for analog inputs/digital outputs. The control board reads PWM signals through the analog pins from the external autopilot and converts the signal into absolute positions for the motors.

    Although I am aware that KiCad is more open-source and is completely free (no paid for features, therefore more accessible), I have decided to stick with Eagle. Given time restraints, it is practical for me to continue using a program I am familiar with. (Onshape was quick to pick up as it is very similar to Solidworks)

    Images of the schematic and board are below and you can download the Eagle design files from the Dropbox development folder (Glider_PCBs/Control_board/v0.2). I have ordered the control board from OSH Park with their Super Swift service and paid for postage to the UK so the boards should be here in about a weeks time.

  • Designing third generation hardware

    Alex Williams08/05/2017 at 21:21 0 comments

    I am using the cloud CAD service ‘Onshape’ to produce the model of the third generation of the glider. This allows the design to be more open (all files are public and viewable at any stage during the design process) and more accessible (Onshape is free and does not require an expensive license, only an internet connection).

    I'm going to produce parametric parts with dimensions that vary in accordance to local variables. The third generation of the glider will be designed so that the user can input values according to a test print and then all dimensions of the printed components would be adapted for the user’s printer, which would minimise post processing. Unfortunately Onshape does not let you specify global variables, (values that remain constant between different parts within an assembly), so I will design the glider within a single “Part studio” (A multipart assembly). If this is too complex (too many features in a single file), I will have to remove the parametric feature.

    An example test piece is below and shows how a single piece would be able to determine the best values for a person's printer for dimensions such as the size of a hole for an M3 bolt through a wall.

    A live version of the glider model can be found here and is updated automatically whenever I make an edit to the model.

  • Underwater gliding

    Alex Williams08/02/2017 at 09:55 1 comment

    I have been able to use a pool to test the glider and although there was not a lot of video footage, it provided a lot of information about how well the glider currently works and any flaws that the current design has.

    The below video only shows the descent phase as the buoyancy engine was not working reliably enough at this point to demonstrate the transition between descent and ascent. Also, the IMU has yet to be integrated into the control software, so the glider does not have a PID algorithm to adjust the position of the mass; you can see that the mass does not move from its fixed position at the front of the rail. As the mass is at the front of the rail, the glider’s angle of attack is high so the glider’s glide ratio is quite low.

    The exterior printed parts would fill with water through very small imperfections, this caused the glider’s ballast trim to become incorrect over time (to the extent that the glider was unable to become positively buoyant at all). I will tackle this by reprinting the parts with a 100% infill, so water would be unable to enter the prints.

    Also, when the engine motor has insufficient torque to drive the plungers, the plungers will jam with the rotor still rotating. This causes the nut to dig into the drive screw and the nut wears away the thread. This then causes the plungers to jam more frequently. A peristaltic pump would potentially address this issue. I plan to design a peristaltic pump proof of concept within a couple of weeks.

  • PCB modifications

    Alex Williams07/24/2017 at 13:44 0 comments

    Several modifications to the control board PCB have been made.

    As the IMU that I was going to use (LSM9DS1) is out of stock until November, I had to modify the board to use an alternative IMU (MPU6050), which does not have a magnetometer. I used the SDA and SCL pads from the board to hookup the MPU6050. I had also set digital pin 2 on the atmega328p to control a stepper motor, however the MPU6050 requires the digital pin 2 specifically, so you can scrape away at the PCB to obtain the D2’s signal track, making sure to isolate the D2 signal from the stepper motor. You have to re-allocate D12 (or any other spare pin apart from D10 - used during program upload so can cause erratic behaviour) to the “Step” pin of the left hand stepper motor driver.

    The 3.3v regulator was swapped out for the 7805 5v regulator, as the MPU6050 requires a 5v supply. The pinout of the 7805 is different to the original regulator, so be careful when swapping the regulators. The 3.3v from the FTDI cable will also have to be isolated, meaning you cannot power the Atmega328p by only the FTDI cable, you also require external/battery power. I will add an automatic power supply switching circuit for the board by the next board revision.

    To enable auto-reset when uploading, a 10uF ceramic capacitor was linked between DTR/RTS pin of the FTDI cable/adapter.

    Although not as necessary, I also added a reset button.

    I hope to produce another revision of the board with these alterations soon.

  • Underwater testing

    Alex Williams07/24/2017 at 13:40 3 comments

    As the design is at a stage where it is watertight and all motor controls are working, we were able to test the glider underwater.

    The first clip is of the glider ascending as the buoyancy engine expelling water. The air bubbles released at the start is air coming out of the nosecone as it fills with water. The second clip is an underwater view of the glider as it descends by taking water into the buoyancy engine.

    During underwater shot, you can see my fingers nudge the glider downwards slightly, this is only to prevent the nosecone from breaking the surface of the water as the nosecone will take in a small amount of air which will become trapped and prevent the glider from descending.

    We need a larger (and deeper) volume of water in order to trim the glider properly and to test forward motion.

    I intend for the third version of the glider to be documented to a greater depth so you can print and assemble the glider. You can produce the first generation of the glider using the information/files I have provided on Hackaday, and in order to produce the second generation, you can obtain the STL files from the development dropbox folder.

  • Second generation glider completed

    Alex Williams07/24/2017 at 10:39 0 comments

    Whilst the first generation of the glider was beneficial as a design concept, it was not designed to be functional (there was design flaws which prevented it from being watertight etc)

    The second version of the glider has been completed, this version builds upon the first generation using the general structure but adapts it for a larger tubing whilst ensuring it is watertight. (Although this version of the glider is functioning, it looks less good than the first generation)

    The endstops are now implemented and here is a short demonstration of the glider homing itself once turned on, without an external power source:

    The control software for the homing of the glider can be found in the GitHub repository along with a python script that allows the user to control the glider via key presses. The python script first initialises a connection with the glider using the serial port, then it uses the tkinter library to detect key presses and sends the command across the serial port. The arduino detects these and moves the servos as requested. This allows for a more streamlined interface with the glider compared to the Arduino serial monitor.

    The original printed wings have been replaced with stainless steel wings as I did not originally understand the hydrodynamics of the wings. An additional benefit is that the steel wings are heavier and so act as ballast.

    A nosecone was printed for the frontend to streamline the glider slightly. The nosecone bolts onto the front endcap, after the endplate, so the nosecone does not need to be watertight. A piece of gauze was added to the water inlet to minimise fouling.

    The batteries have been hooked up to the control board and the glider is able to run without external power. The batteries charge through the communication/power cable and the battery protection circuit prevents overcharging/overdischarging/shorting etc.

    The back endcap has a pressure equalisation inlet, power switch, communication/power cable and a blank (will be replaced with a pressure sensor), A printed shroud was added to protect the connectors on the endcap (and to prevent something from turning off power to the glider).

    Mild steel rods were used on the underside of the glider to act as ballast and will be used to trim the glider so that it is neutrally buoyant when the buoyancy engine is half full.

  • Glider simulation using Unity3d

    Oliver Williams07/22/2017 at 21:57 5 comments

    We want to develop the control software for the glider in a way that will allow testing. In theory, with an accurate glider model, this allows you to develop the software independent of hardware, reducing the cost/time of PID optimisation.

    The control software sets the buoyancy and trim and requests the angle and depth. Therefore, the Arduino code is written so that it either controls real or simulated hardware. A compiler flag is used to switch between real or simulated hardware.

    Using Unity3d I created a simulation of the glider ascending/descending. The movement through the "water" is modelled using the buoyancy engine, Realistic Water Physics. The glider is modelled as a number of elements, the main body, a volume at the front that changes buoyancy and a mass that moves on the underside of the body that trims the angle. 

    Unity provides an Arduino with depth/gyroscope readings which are then used by the Arduino to calculate motor movements and these are passed back to Unity. Using these motor movements, Unity models the simulated glider.

    The below GIF shows a screen capture of the glider simulation ascending and then descending.

    Over the coming weeks I will optimise the simulation model to accurately reflect experimental data from the glider.

  • Design process transparency

    Alex Williams07/21/2017 at 22:32 0 comments

    The glider currently has had two main design iterations. The first version of the glider was the completed version within the smaller tubing and was primarily a design concept. The second generation of the glider developed from the first generation and will take it to a functional prototype. However, the second generations did not involve a complete redesign so the design is clunky in some places where the glider transitioned from a smaller tube to larger tubing. The third generation of the glider will be a functional glider with a complete redesign to fit the larger tubing, complete with thorough assembly instructions and documentation.

    The first two generations of the glider have been modeled using Solidworks, which is a closed sourced and expensive CAD package. As I intend to redesign every component of the glider for the third generation, I'm looking to transition to using Onshape, an online CAD package which is free to use.

    With regards to circuit design, I used Eagle to design the first version of the PCB, but this is closed source and provides a limited feature set when used for free. I will have a look at KiCad because this would provide an alternative to Eagle that is an open-source package and is completely free.

    I have also updated the "links" section to include a link to a Dropbox folder which is the working folder that I use to store all files related to the glider (Design files/datasheets/screenshots/everything). The main workings are currently within "Glider_version_2".

  • Buoyancy engine updates

    Alex Williams07/20/2017 at 16:25 0 comments

    I have been able to retrofit the syringe buoyancy engine designed for the older tubing into the newer Blue Robotics tubing and this is now watertight. There are a couple of areas where the length of the buoyancy engine has increased; notably the piping has increased the length as I originally intended for each syringe to connect to the exterior, but this would have increased the number of seals to the exterior (increasing chance of leaking) so I instead joined the syringes together which increased the length of the buoyancy engine.

    The test setup:

    Testing of the buoyancy engine running underwater, first pushing out air and then taking in water:

    The current buoyancy engine has a couple of potential downsides. The current rate of change is approximately 3 grams per second with a total mass change of about 160 grams. The new tubing requires a total glider mass of approximately 11kg, so a mass change of 0.16kg gives the buoyancy engine little control authority over the glider and a greater variable mass will be more effective.

    Using a larger syringe is not possible as larger medical syringes are not produced, so a custom syringe would have to be made which would introduce the problems associated with dynamic seals. Alternatively a peristaltic pump could be used to move liquid (oil/water) from an internal bladder to an external bladder and the variable mass amount would be dictated by the bag size. A peristaltic pump based buoyancy engine would also reduce the length of the engine so it would be more compact. In order to increase the rate of change of mass on the current buoyancy engine (so the glider is more effective at shallower depths as it can transition between ascending/descending states more quickly), the motor has to rotate more quickly or the threads on the screw have to be larger, but both of these options will slightly reduce torque. I will explore the option of a peristaltic pump based buoyancy engine in the near future.

  • Exams are over

    Alex Williams07/06/2017 at 16:47 1 comment

    Now that the exam period is over I am able to start spending more time developing the glider. This is a quick update about the development over the last week or so.

    The Blue Robotics order arrived and the components are of a very high quality and a significant improvement over previous hardware. The new tubing has an internal diameter of 100mm, whereas the previous tubing had an internal diameter of 84mm. In order to produce a proof of concept quickly, I will use the internals designed for the smaller tubing and use spacers so that the internals do not move around within the new tubing. I have currently fitted the backend of the internals within the new tubing using spacers. Blue Robotics also produce endcaps which forms a watertight seal with their tubing and you can easily print components that bolt onto the endcaps.

    I uploaded the arduino bootloader to the ATMEGA328P so that it can now be programmed standalone and was able to test the stepper motor drivers on the board and they function perfectly. However, I was unable to solder another board with the IMU (LSM9DS1) attached using the hotplate method as the pins were too close together. I was going to order another IMU and solder it at a hackerspace with a hot air soldering station, however the component is out of stock until November. A workaround is using the SDA and SCL pads on the PCB to attach another IMU (MPU6050).

    I have produced a battery holder for the lithium ion batteries using battery spring contacts and printed holders which snap the batteries into place. The batteries are protected using a 3 cell protection circuit. This battery holder will also accommodate steel rods on the underside to act as the movable mass which is used to control roll and pitch.

View all 19 project logs

  • 1
    Step 1

    Print all the pieces listed in the "files" section, print 1 unless indicated otherwise.

    Collect all the components listed in the "components" section.

    The only tools required for assembly are hex keys and a cross head for the screws. A drill is optional, but useful to bore out any incorrectly sized holes.

  • 2
    Step 2

    Using a hacksaw cut 9 lengths of aluminium, 3x 6cm, 3x 13cm, 3x 28.5cm

    Drill 2 holes in the 6cm pieces, each 5mm from each end on the same face.

    Drill 2 holes in the 13cm pieces, one 5mm from an end and the other 9cm from the same end. Both holes are on the same face.

    Drill 3 holes in the 28.5cm lengths, one 5mm from an end, another 245mm from the same end on the same face, the final hole 178mm from the same end on the other face.

    Make sure to go all the way through both sides of the bar for all holes.

  • 3
    Step 3

    Using 2 30mm M4 bolts and nuts per wing, construct the wings.

View all 38 instructions

Enjoy this project?



Kevin Klemens wrote 05/21/2017 at 03:18 point


This is an awesome project and i am very excited to get my materials all together and start printing (I have a Taz6). Thanks for making the files available and providing instructions, that is huge for the marine robotics hobbyists. I started a thread on the BlueRobotics forums if you wanted to join in:

I've been working on really long range communications with a friend, so give me a ring when you get to that part. We have Wifi and 4G working on a Pixhawk 2.1 and we are pretty close to getting Iridium satellite comms working for our boats, but I always wanted to put the circuits on a UUV.

  Are you sure? yes | no

Alex Williams wrote 05/22/2017 at 17:57 point

Thank you for your interest in the glider. I am currently looking at using the 4” tubing from Blue Robotics as the current design may not be watertight, due to a mixture of the endcap design and the limits of my printer. The Blue Robotics’ tubing would increase reliability of the seals and easier to produce a working prototype. I hope to have the parts purchased within a few days and will publish an update outlining the parts. Given the comments of others, I am also going to look at using a bladder based buoyancy engine, giving me a greater engine volume and reducing complexity. I will overhaul the design once my school exams have finished (a couple of months).

Once I have the glider functioning underwater, I am interested in adding an autopilot for running predetermined routes and a sensor array for data collection. I am also interested in long range communication for longer missions, using either 4G or the Iridium communication module (I was initially put off by the price though) and any help in that department would be greatly appreciated.

  Are you sure? yes | no

Kevin Klemens wrote 05/22/2017 at 19:57 point

I concur with your move to the BR 4" WTC. I've been looking at that for the hull of my vectored thrust UUV (Design idea right now). Any commonality with parts for your glider and BR products would be a good thing to make for an easier entry for people. I've physically been there to help with the WTC depth tests, so I can vouch for their numbers.

I read the below comments on oil bladders, and while a good idea, I think you're going to have more fine tuned buoyancy control with the piston style ballast tanks, but that is just my two cents. It would be interesting to see dive results using both methods.

I'll send you a PM on the command and control aspect and we can collaborate on that.

  Are you sure? yes | no

Modzer0 wrote 05/25/2017 at 15:00 point

On the oil based bladders below. The reason oil is attractive is for deeper water. When you're diving an air based system you're doubling the compression every 10m which causes changes in volume and with changes in volume come changes in buoyancy. With an external bladder which is commonly used for deep diving such as ARGO oil is the only way to go.

An alternative is to use front part of the hull itself as big buoyancy engine cylinder.

  Are you sure? yes | no

Kevin Klemens wrote 05/25/2017 at 17:46 point

I agree, if this were to be going really deep >100m I'd say oil and hydraulics would be the way to go. That's what the commercial deeper diving gliders use. The 200m Slocum looks to be using piston tanks though.

However, the real limit here is going to be the WTC. The 4" acrylic ones should be good down to 100m, but there isn't a customizeable 4" aluminum one yet, unless Alex finds one. So 100m will probably be the depth rating, which would be a good number for an inexpensive glider like this. Material cost goes up exponentially the deeper you need to go.

The reason I'm a bit against oil based buoyancy is because I've seen a few DIY oil compensation experiments (lights and servos) and none of them worked well.  It only managed to make a mess of electronics when they leaked. All the oil pumps I've seen for gliders look to be piston based with a three way valve.

The ROUGHIE glider uses piston tanks and trimmable pitch and roll and seems to have a very nice flight path.

  Are you sure? yes | no

Mike Yurick wrote 05/13/2017 at 17:37 point

Nice project, wish I had some water handy to do something like that.

Any plans for a nosecone camera?

  Are you sure? yes | no

Alex Williams wrote 05/14/2017 at 13:51 point

I am considering using the 4” tubing/seals from Blue Robotics, as this would make it far easier to make watertight (I am going to release a project log concerning this). They have a dome endcap specifically for camera use and I was planning on purchasing one to have it available for experimentation later down the line.

  Are you sure? yes | no

Modzer0 wrote 05/12/2017 at 20:13 point

An operational tip that will help you save power is to not rely on the weight mass for pitch control. When the glider is neutrally buoyant with the pistons at 50%, or 60% if you want a bit of positive reserve in case of leaks. The larger the variable ballast the larger the reserve. There will be leaks when you least desire them. Once you trim at level , and at the neutral buoyancy position of the piston rely on the piston to control the pitch. With it being forward mounted taking in ballast will naturally put it at negative pitch and the opposite is true as well.  Brute force isn't needed with the motors, slow everything down, and go for maximum power efficiency over speed.

  Are you sure? yes | no

Alex Williams wrote 05/14/2017 at 13:53 point

(I'm replying to both of your comments to make replying easier)

Many thanks for your informed comments. I am looking to make this a low cost platform that people are able to use as they wish, including to record the temperature/dissolved gas levels of lakes/still water. Hopefully, this will be the use case I demonstrate. It may only have quite limited utility in readily accessible water bodies particular any that are fast flowing or with tidal currents. Thank you for the comment about thermal layers in lakes, that would have been tricky to identify/figure out otherwise.

Having seen yours and others’ comments, I had another look for bladders and I found that water pouches could be viable. Using a pair and an oil ballast, this would give me a greater variable ballast (150g for 3 syringes vs 600g bladder in the same space) and hence a larger reserve. Due to your mention, I am looking at a small peristaltic pump that I could use to control the bladder and to adjust both buoyancy and pitch. However, I am likely to use the movable mass to control pitch when starting out, as I feel like this will be easier than using the buoyancy engine to control both buoyancy and pitch and will be sufficient for proof of concept.

In addition to having a reserve in the buoyancy engine in the case of a leak, I am also contemplating having some masses on the exterior of the glider, attached to the tubing by strong magnets (on the interior). In the case of a leak, an electromagnet ring would pulse on and repel the masses and making the glider positively buoyant. I have yet to work out the feasibility of this type of leak emergency system.

  Are you sure? yes | no

Modzer0 wrote 05/15/2017 at 22:26 point

If you try to maintain pitch with your movable mass system trying to hold it at  specific angle you're going to be fighting your buoyancy engine. Trim it level at neutral buoyancy. When you take in ballast you're going to naturally make the front heavier which will give you negative pitch. The more negative the buoyancy the greater the pitch. The same with positive buoyancy, the more, the greater the up angle. You get it for free with forward mounted variable ballast so use it to your advantage.

For a submerged object you have the center of gravity (G) which in your case is altered by the weight mass. Then you have the center of buoyancy (B). At rest B will come to rest directly over G.  When you decrease buoyancy forward B will shift aft. When you increase it B will shift forward which will alter pitch as a result. There's a lot of math but you can skip it because your center of gravity is variable and can be adjusted with input from gyros. If you had a fixed ballast mass then the math would be more important.  The buoyancy engine is at the front so changes will result in larger shifts in B.

The droppable weights are possible, but add a bit of complexity and unless they're secured mechanically they can fall off at the worst moments.

  Are you sure? yes | no

Alex Williams wrote 05/30/2017 at 21:28 point

(I am replying to this comment as hackaday does not allow you to reply to a third level comment, so I cannot reply to the intended comment.)

As I understand it, the variable ballast at the front of the glider would control pitch as desired if the oil is less dense than the surrounding water. Therefore the pitch can also be correctly controlled by the buoyancy engine if it is mounted at the back of the glider, by using oil that is more dense than the surrounding water. Other than less dense oil typically being less viscous (and more available), would there be any major advantages with mounting the variable ballast at the front of the glider, than at the back?

You were also talking about using the oil bladder to achieve greater depths than with the syringes, but the peristaltic tubings that I have come across are typically only rated to 4 bar or so (30m), which isn’t close to the 100m figure that was floating around elsewhere in the comments. Is there a way to use the lower pressure tubing to achieve those greater depths or would I need to find tubing with a higher pressure rating or use a different mechanism altogether?

  Are you sure? yes | no

Modzer0 wrote 05/30/2017 at 21:33 point

You still mount the variable ballast forward. That's where it needs to be to take advantage of the change in buoyancy for pitch. When you start going deeper you're going to need your buoyancy engine and hoses to take the pressure so aluminum and heavy duty hoses will be needed.

  Are you sure? yes | no

Modzer0 wrote 05/03/2017 at 16:24 point

As someone who has built AUVs for the US Navy I have to say this is pretty cool. The downfall of underwater gliders is they need a fairly large and deep body of water. In the open ocean they have plenty of room. It's a bit more difficult in small bodies of water because there's not really much of a power budget for any kind of depth sounder. Something that would be very useful for environmental studies is a low cost version of the Argo buoy that can be used in lakes to profile temperature, O2, and CO2.

One thing you might run into with neutral buoyancy manipulation when diving in something like lakes is a sharp thermal layer. To save power you want to manipulate the ballast as little as possible and very slowly drift down this creates a situation where you'll have it 'float' on top of the denser thermocline. You can of course just take in more ballast and power through but if you do so too quickly you may experience what we have called 'Operation Seadart' where your vehicle does an imitation of a lawn dart and doesn't have the buoyancy reserve to free itself from the bottom. It's a fine balance to dive slowly enough to get a good sensor trace, but quickly enough to gain the desired amount of propulsion, which isn't a lot.  If you want to simplify ballast control use a bladder and a peristaltic pump. It'll reduce the number of moving parts making construction simpler and give you more ballast reserve.

There are a number of ballast control methods but one you may want to consider is oil bladders, one internal and one external in a free flood area. It has the advantage of not being as compressible as air so your buoyancy doesn't change with depth using an external bladder.

  Are you sure? yes | no

ActualDragon wrote 04/30/2017 at 01:44 point

in the movement video, the green weights are to move it forward or whatever. it looks the same size as a AA battery. if the final goal is to go untethered, couldn't you replace those with batteries?

  Are you sure? yes | no

Alex Williams wrote 04/30/2017 at 08:17 point

The green weights in the video are actually 18650 cells, which are lithium ion batteries that is a little larger than an AA batteries, hold more energy and are rechargeable. In the video they are not powering anything and they're just there to show where they will go.

  Are you sure? yes | no

ActualDragon wrote 04/30/2017 at 12:57 point

oh ok. nice project btw!

  Are you sure? yes | no

VijeMiller wrote 04/30/2017 at 00:31 point

Sexy! I mean of course in an engineering sort of way and not bcz it's phallic shap--uh, never mind. Now, to 3D print the largest bath tub so to properly enjoy this submarine.

  Are you sure? yes | no

Legrange wrote 04/10/2017 at 10:16 point

This is cool, I have an affinity for things that go under water.

Curious as to how precise your syringe control is and how precise do you need it to be to function properly? Have you done any real life experiments on the control system, if not, how soon before you try things out? How long before you have a workable prototype of the whole thing?

  Are you sure? yes | no

Alex Williams wrote 04/12/2017 at 10:26 point

I have finished printing about half of the components, and the other half should be quicker to print (I printed the larger components first). I will then be able to assemble the glider and see if anything stands out as being incorrect. Following that, I will design the control circuits and control software.

The capacity of the syringes (180ml) compared to the volume of the glider (~6000ml) is 0.03, whereas the Slocum glider's volume change (450cc) compared to volume (52000cc) is 0.009. From these figures, it seems that the change in density will be sufficient. That being said, I am still sceptical of my glider, as the Slocum glider is clearly much larger and I am unsure as to what degree that will affect the required volume change.

The threaded bolt used to drive the syringes allows for a very precise control over the volume of water taken in; hooking up a stepper motor to the syringes makes it look like repeatable volume change of 0.1cc is possible.

I am currently in the lead up to exams, so will be able to put minimal time into the project over the next 2/3 months. However, following that, I have about 3 months free in which I will do a large amount of development and I hope to come to the point where I am able to perform real life tests on the control systems (simple ascending/descending and pitch control).

  Are you sure? yes | no

Legrange wrote 04/12/2017 at 19:35 point

Thanks for your reply. It's good you're keeping grounded and sceptical. I look forward to hearing more about this project as you get the time to work on it.

  Are you sure? yes | no

Peter McCloud wrote 04/04/2017 at 04:06 point

Great looking CAD model

  Are you sure? yes | no

Alex Williams wrote 04/04/2017 at 09:25 point

Thank you. Functionally, the model has a way to go, but it's more or less there visually

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates