The Underwater Motor Designed to Let Water In

Blue Robotics makes components for underwater robots, including thrusters that move a vehicle through water. Its cofounder Rustom Jehangir discovered that making an affordable thruster required changing where the water could go, rather than simply buying cheaper versions of conventional parts.

The company's early design tried to protect an ordinary motor inside a sealed tube. Its eventual design let water flow through a purpose-built motor, while protecting individual components. For a hardware founder, the useful lesson is architectural: a costly requirement may come from the way a product is divided into parts. Before negotiating every component price, ask which boundary is creating the expense.

A seal that brought its own problems

A thruster turns electrical power into movement through water. It needs a motor, a propeller and a way to keep operating in an environment that can corrode metal and punish small leaks. A cheap motor on a workbench does not automatically become a cheap underwater product.

In his June 2014 development account, Jehangir described four revisions built around a radio-controlled aircraft motor inside a sealed tube. A magnetic coupling transmitted rotation through the boundary without a shaft passing through it. The arrangement still depended on sensitive manufacturing tolerances and proved expensive. Steel bearings also corroded in salt water.

Buying a different motor did not solve the whole problem. The available motors did not provide the desired torque, the turning force needed by the propeller. Blue Robotics therefore developed a motor specifically for the application.

The consequential choice was allowing water into the motor assembly. Protective coatings and seals guarded individual components; plastic bearings replaced a troublesome material. Water could flow through the assembly, eliminating the original sealed tube and magnetic coupling. The account also describes working with Proto Labs on injection-molded parts.

This is a founder's retrospective, not an independently measured cost comparison. It establishes the design change and reported difficulties, without showing how much money each revision consumed. The lesson is stronger when kept at that level: simplifying the architecture removed whole categories of parts and tolerances.

Flooded does not mean careless

Blue Robotics' current thruster usage guide describes the T200 and T500 as flooded motors. Water lubricates their bearings. The guide warns against running them dry for more than ten seconds. Each motor also requires a suitable electronic speed controller, the separate device that regulates electrical power to the motor.

That distinction matters commercially. A motor that welcomes water has conditions of use just as a sealed motor does. Its advantage depends on the complete application, including power electronics, mounting, maintenance and the customer's operating habits. A redesign can move a constraint rather than remove every constraint.

The broader environment remains difficult. In a 2025 Hackaday discussion announcement, Blue Robotics engineer Tony White's work provides a community entry point into underwater vehicles and their reliability challenges. The announcement does not certify a particular thruster's service life. It shows why a reader interested in inexpensive underwater robots must also think about systems that work away from the bench.

Neither source supports a claim that this architecture suits every depth, fluid or duty cycle. A customer choosing a component needs documented limits for the actual job. A founder redesigning one needs engineering verification before a sales promise.

Price the boundary, not just the shopping list

A bill of materials lists what a product contains. It can hide why those parts are necessary. Build a second list of boundaries: places where water, heat, dust, vibration or movement crosses between assemblies. Beside each boundary, record the components, manufacturing operations and checks that it creates.

For an underwater assembly, that could include a housing, coupling, sealing surfaces, assembly procedure and leak check. For another product, it might be a cooled enclosure or a rotating shaft. The point is to expose the cost of the arrangement before optimizing its individual pieces.

This table is a planning aid, not an instruction to remove a seal. The requirement comes first. Some boundaries exist because a failure is unacceptable, and their expense is justified.

A cheaper component can make a dearer product

Consider an illustrative comparison in US dollars. Architecture A uses $80 of parts, requires 20 minutes of assembly at $30 an hour and passes its final check on 90% of units. Architecture B uses $92 of parts, takes eight minutes and passes 98%. Assume failed units consume the same parts and labor and are discarded. These are invented planning inputs, not Blue Robotics figures.

A costs $90 before rejects: $80 plus $10 of labor. Dividing by 0.90 gives $100 per accepted unit. B costs $96 before rejects: $92 plus $4 of labor. Dividing by 0.98 gives approximately $97.96 per accepted unit. The more expensive shopping list produces the cheaper accepted unit under those assumptions.

The difference is only $2.04, small enough that omitted costs could reverse it. Coating inspection, tool amortization, rework recovery, shipping damage and warranty returns belong in the next version of the model. A production trial should measure the inputs, rather than treating these arithmetic results as a forecast.

It is the same discipline behind a turntable maker's selective investment in tooling: spend where the process justifies it. Here the earlier question is whether the architecture creates avoidable process work. A machine cannot economically repair every unnecessary design complication.

Give the next prototype a question to answer

An architectural experiment needs a written hypothesis. For example: protecting components individually will remove two assembly operations without increasing inspection time or failures under the specified conditions. Then define the observations that would disprove it.

Keep technical acceptance separate from customer acceptance. A prototype might survive the engineering checks and still demand maintenance that buyers will not perform. Conversely, a customer may accept an operating restriction if the component makes a previously unaffordable application possible. Neither answer should be guessed from enthusiasm for the design.

A small company also needs a service route. Replacement availability, troubleshooting and clear installation instructions are part of the product's economic usefulness. OpenFlexure's local service question offers a related reminder: availability on paper is different from a working instrument in the customer's hands.

In the next hour, choose one expensive boundary in your product. List the operations it creates, identify the requirement it satisfies and write one alternative worth evaluating with a qualified engineer. Do not redesign the whole product. Give the next prototype one cost-bearing assumption to challenge.

Blue Robotics' example earns its interest because the useful change happened before the price negotiation. The team asked whether the motor needed the box around it. Sometimes the part that costs most is the assumption holding the other parts together.