Monday, March 6, 2017

Depth Control

Drop something into the ocean and it will either float or sink. You might get lucky have have the mass of the thing exactly match the mass of the water it displaces, in which case it is neutrally buoyant. It won't be that way universally, especially if you drop it into waters with different temperatures. The most likely scenario is that the density of the water is separated into strata, with the denser water sinking below the less dense water. A neutrally buoyant robot will only be neutral in exactly one stratum in the water column.

A common solution is to design for positive buoyancy, so the robot just slightly floats, then to use motors to apply constant downward thrust to dive. The advantage of this approach is in the case of catastrophic failure, the robot can be recovered because it will float to the surface. The disadvantage is that you need bigger batteries to provide this thrust, and more complex control logic for handling scenarios where the robot is not level.

I decided that I wanted to explore active buoyancy control. When you SCUBA dive, your air consumption is tied to the amount of work you do, and I wanted to have a robot that used minimal power to stay down a long time for monitoring, slow speed following, etc. I also wanted to think a little bit forward to scenarios where the robot could hand-off extra gear to a diver underwater (spare tanks, cameras, lights) and would have to compensate for unpredictable changes in buoyancy. This is what real submarines do, and many model submarine hobbyists have incorporated pumps and ballast tanks, so I know it's possible, at least at hobbyist depths.

Controlling Buoyancy

To control buoyancy, you either have to change the weight of your robot or change the amount of water you are displacing. Hot air balloons change weight by dropping sand bags, but that's a one-way street and only good for a bailout safeguard. I chose instead to use pumps and valves to move water into and out of an internal bladder.

Since water is very heavy, the pressure at 100ft is around 45PSI. That means to pump water out to ascend, the pumps would have to be able to pump more than 45PSI. It also means that when not pumping, the system would have to resist the difference in pressure between inside and outside. If it did not, water could flow through the pumps to equalize the pressure. To prevent this, powered check valves are needed to prevent undesired flow.

My solution

Hardware

I found some 12VDC 100PSI pumps that are designed for marine/RV water supply applications. They are self-priming and contain an internal check valve to prevent back flow. I used 2 pumps, each paired with a powered check valve that prevented forward flow.

Pumps and check valves


Electronics

The pumps use a lot of power, so I needed to use something other than a transistor to switch them. I used MOSFETs before, but I read that relays are usually a better choice for motors because they isolate the switching electronics from the load, and I wanted the option to have separate battery packs. Since relays draw some power, I learned that you need a diode in place to protect the switching transistor from frying due to the flyback effect when you cut power.

2 relay independent circuits

Sensor

To know where you are in the water, you need a pressure sensor, I selected a sensor that works in the desired pressure range and verified (on my scope using a test rig) that it reads 0.5V for every bar of pressure (14.7PSI).

Pressure sensor and test rig

Control Logic

The robot will either want to go down or up at a desired speed (or stay put). So, it seemed logical to use a two-stage PID loop. The first stage will translate the pressure into a desired velocity (change in pressure) clamped to a narrow range, like +/- 1 meter/second. The second stage will pump in or out to try to maintain that velocity. The advantage of this approach is that the robot does not make drastic moves, but rather takes its time reaching its target.

To tune the control loop, I wrote a simulator that incorporated the drag of sea water on the test housing I was using. I then did a parameter sweep to find suitable parameters for the control loop that gave good convergence.

Housing for testing

To test all this, I needed a housing that could withstand the pressures involved. I learned just enough about CNC machining to make a collar out of PVC and a bulkhead out of acrylic. I hoped that a 6 inch PVC pipe, rated to 150PSI internal pressure, could withstand 45PSI external pressure to get past testing. The bulkhead design relies on an o-ring of the right hardness and two smooth surfaces. If done correctly, the pressure simply compressed the o-ring and makes the seal better.

Bulkhead

Collar and clamps on PVC pipe


I decided on using a single port for the water supply, which required me to carefully alternate pressure readings and active pumping. I also wanted to be able to manually control the robot while testing, so I added a piezo button (that I knew worked at depth) and some logic to count series of button presses. To make sure the button press could be detected reliably, I used a 555 timer chip to make the output always at least 100ms.

555 timer circuit, button (not connected)



Testing

The electronics all worked as designed, which was a relief. The pumps were able to pump a lot of water into a sealed container and prevented it flowing out when the power was cut. When the pump direction was reversed, the water came out in a surge due to the pressure, but I should be able to finesse this asymmetry with some control logic heuristics.

The housing did not work well enough to use. This was the first of several indications on this project that I will eventually have to "up my game" in the mechanical engineering arena.

Learning from failure

On my first test, I could see water flowing through PVC threaded connections that were teflon taped just like a plumber would do. I glued them in, which resolve that issue.

The second test went much better. I took the housing to 120ft (60PSI) and looking through the acrylic lid I saw no leaks. However, between the time I stopped looking and when I retrieved it on the surface, about a cup of water had made it into the housing. I have no idea where the water got in.

At this point, I figured I could live with a small amount of water if I protected the electronics by placing them all in a dry bag inside the housing. But after all was said and done, the 6 inch diameter was not enough to allow me to route the tubes and have a way to fit everything inside.

Future direction

I still want to test it. My options are:
  • Do a tethered test, where only the pressure sensor is inside the housing and the rest is on the surface in a boat, 
  • Relocate the water port to the acrylic bulkhead, or
  • Build a custom housing that is designed to accommodate my test board
The tethered test is tempting, but it would be a complete throwaway in that I wouldn't learn anything for building an untethered robot. 

I've already learned that you can't glue anything to acrylic but acrylic, so I'd have to tap threads into a hole and hope it doesn't leak - not a good bet. There does not seem to be any sort of acrylic hose barb I can use - it's just too brittle for that application.

Since I have to eventually build the final housing, I might as well tackle CNC machining and get good enough at it to make things work. That sounds the most interesting, so that's what I'll do next.

Why not try 3D printing, you ask? So far, most consumer-grade 3D printers do not produce materials that are strong enough. The layers tend to delaminate under stress. Solid plastics, interlocking layers, and special glues that fuse the layers are more robust.

Friday, March 3, 2017

Tracking with Ultrasonic Sound

If dolphins can find fish with sound reflecting off the fish, it should be possible to find a person swimming with a sonic transmitter, right? Right???

Building a beacon

The reason modern 5.1 stereos have only one woofer is that low-frequency sound is omni-directional - you can't tell where it's coming from. The higher the frequency, the easier it is to determine where it came from.

Speakers and microphones must be sized in proportion to the wavelength of the sound they handle. Since I'd eventually need to build an array of receivers to determine the direction the sound came from, each sensor unit needed to be small, so ultrasonic seemed like the right choice.

Fortunately, there are lots of ultrasonic transducers on the market that should work. I decided to use the one pictured below, which is waterproof and made of aluminum.
40KHz Transducer
These pick up sound in a cone of 80+-15 degrees, so can be placed on a spherical surface to determine the direction of the sound based on intensity at each sensor - no need to build a complex circuit to calculate the differential time of arrival for the signal. They can also handle 140Vpp, so I have some headroom if I need more power to work in the water.

It turns out driving these is really easy - just set up a series of pulses with the right voltage. I accomplished this with a Netduino Mini microcontroller, some transistors, an makeshift underwater housing, and a reed switch to control the power. The Netduino (and most similar microcontrollers) supports pulse width modulation (PWM) in hardware, so it can provide a very accurate 40KHz driving signal.

Transducer in the housing

Netduino Mini and circuit
I even experimented with a 10:1 transformer which I used to get 90Vpp out of my 9V battery, but it turned out to be unnecessary, so I decided to reduce the risk of stopping my heart by accident and stuck with 9V directly from the transistor.

That was the easy part.

Building a receiver

The fun part about piezoelectric transducers is that they produce voltages when they encounter a change in mechanical energy, and sound is just such a change. The complicated part is that they produce very little voltage. In order to see the voltage being produced, I needed to amplify the output, which led me to learn a little about op-amps (Operational Amplifiers). 

Amplifying the signal

Op-amps come in different types for different applications. Since I need to amplify sound, I chose the LM386N audio amplifier. Well, actually two of them, along with some resistors & capacitors that set the amplification ratio and implemented a high-pass frequency filter. During development, I was wrangling with a lot of stray noise being amplified, which inspired the filters. In the end, I realized that the ballast in the fluorescent light on my magnifying desk lamp was emitting an EM field with was creating voltage (via induction) in the wires on my prototype. I made the wires lay flat and switched to a different light, but I never got around to seeing if the filters could be eliminated.

Reading the signal

The Netduino has analog inputs that can read 0-3.3V, so I set the gains on the op-amps to give me a maximum amplitude such that, after passing through a half-wave rectifier and a capacitor, I got out a stable voltage that was in the range the Netduino would handle.

Display

My goal was to take this thing out to the water and test it, so I needed an indicator for the signal strength. In the end I used a 7-segment LED numerical display to show a scaled value from 0-9.
Receiver circuit (numerical display not shown, and my pet parrot stole a capacitor)

Testing

First step was in air, and it worked exactly as intended - I got a gradual ramp of signal as I moved in from 20 feet to 0 feet.

The next step was in water. I wanted to see how the signal strength was affected by the density of water. So, I took the transmitter and receiver to a large koi pond where I worked. The signal was even stronger! I got good signal strength and directionality at 40 feet distance.

The final step was in the ocean, SCUBA diving. Again, it worked perfectly a few feet below the surface. But as we descended, the signal began to reduce until it was negligible. The signal returned as we ascended. My conclusion was that it must be due to pressure on the transducer. My theory is that the metal face is deformed inward by the water pressure and responds to/transmits sound energy less the further it is deformed. I repeated the experiment driving the transmitter at 90Vpp with the same results.

Next steps

I have some crazy ideas about using CO2 canisters and pneumatic controls to balance the internal and external pressure, but since my purpose is to learn, I've decided to set this approach aside for the moment to see if I can do something with computer vision. Since I always use a dive light, even during the day, it should be possible to track the light itself.

I'm glad I didn't think of this approach sooner - I had a lot of fun putting this part together!

Parts is parts

There's an old joke about engineering large projects: "Q: How do you eat an elephant? A: One bite at a time."

A robot, like anything, is the sum of its parts. If I can break it down into bite-sized parts, I can solve each one, and then solve the problem of integrating them later.

I figure that the parts needed by such a robot are as follows.

Housing

I tried my hand at building my own flashlight for diving (successfully!) so I was not a complete novice. But something this large would have to be custom-built. I could not just rework a maglite.

Under the ocean at my usual diving depths there is 45lbs of pressure for every square inch of the housing, so it has to be strong. It also needs to be relatively light, machinable, and waterproof. A natural choice is some sort of plastic like PVC or Delrin. Aluminum would also work, but I'd rather not tackle working with metal until I have to.

Making the thing would lead me into the world of CNC machining at MakerPlace

Buoyancy

On first blush, it seems like you could just carefully tune the weight of the robot to weigh the same as the displaced water, so that it is neutrally buoyant, but it's not that simple. Water changes density slightly with temperature and salinity. While I have not yet encountered a halocline, I regularly cross thermoclines as I dive deep into the canyons of La Jolla. 

Some robots use active trust (motors pointed upward) to mantain vertical position, but that seemed too energy-intensive to me. A much more interesting problem would be to control it dynamically, like submarines do.

Pitch, Roll, and Yaw

Being underwater is a lot like flying, so I'd need to control 3 axes. Roll is easy - just use a keel weight like sailboats do. The weight will always keep the housing upright.

Pitch ought to be similar, with the exception that the keel weight must be movable forward and back. I'l need a 3-axis accelerometer to detect the angle of the housing, then use control logic to position the weight to achieve the desired pitch. Basically, a sensor, a motor, and a control loop - not rocket science.

That left yaw, a.k.a steering. Being a Star Trek fanboy, I figured I could do that with propulsion if I had two nacelles like the Enterprise. By applying different amounts of thrust to each side, I can steer or even rotate in place by running one motor backward.

Nacelles allow steering without a rudder


Propulsion

At the same time I was getting this effort started, Blue Robotics was just starting their KickStart campaign. I got two of the first runs of their T100 motor with an integrated speed controller.

I looked at building it myself out of sump pump motors, but when I dug into the details of how to hold out 45PSI of salt water from coming in the drive shaft, I realized I was in over my head. Finding bearings for the rotating shaft that could both rotate and be waterproof was a big challenge. Blue Robotics used a much more elegant solution.

Tracking

In the person-following project, we used image analysis to find a color blob and track it. This proved difficult as the target walked past a colored wall or into the shade, as the hues and intensities that reached the camera changed accordingly. With diving, it is even worse as particulates in the water can limit visibility and water itself blocks more red and yellow the deeper you go, eventually fading to black. And almost ALL dive gear is black. Following big black objects would be great for tracking if I lived where there was clear water :-{

At about 100ft off Roatan, Honduras

About 100ft on the wreck of the Yukon, San Diego

Deep in the murky waters off San Diego, basically everything is black. Clearly a more sophisticated method was needed.

There is a lot of work being done on segmenting images, and more recently, deep learning, but the limited visibility in San Diego led me to try something else first: sound.

Dolphins use sound to locate fish in water too cloudy to see in. I figured if I could wear a transmitter, the robot could follow me as long as the sound was directional. Multiple ultrasonic transducers, each with a narrow angle of input, should do the trick.

Collision detection

On land, hobby roboticists use sonar for range-finding. I figured if I could use ultrasonic sound to do tracking, collision detection could build on that.

Control logic

Finally, you have to have a set of electronics to tie it all together. An onboard computer of some kind, various input/output lines to the motors and sensors, and some custom circuits to do what I can't buy off the shelf.

It turns out this is the easy part. For a software engineer, writing software is like a Siren Song - it makes you feel good doing something you're good at, and it's tempting to spend all your time gold-plating the control logic and neglecting the parts you suck at. Well, at least for me ;-}. So, I promised myself to do a balanced approach.

Birth of a gearhead

In 2008 I was feeling I needed to stretch myself technically. The opportunities to do that at work were not enough, so I decided to get a Master's in Computer Science to add to my Bachelor's.

Along the way, I got involved in a computer vision project on a grant to explore using color to track a person and follow them with an autonomous robot. I ended up writing all the computer vision and control logic, except the low-level CAN interface, which Paulo wrote.

I was hooked.


Dr Tarokh and me testing the robot

I worked at Illumina doing manufacturing software, customer-facing instrument control software, and other things. Along the way I got to work with electrical and mechanical engineers ("real" engineers) and longed to learn how to do what they did.

Eventually at Illumina I no longer worked on hardware and began to miss it. So I decided to give myself a project as a learning experience. As a SCUBA diver, I spend a lot of time in the water, so I thought it would be fun to build a robot that could follow me while I was diving. Not terribly useful, but educational ;-}

And by "build" I do not mean "assemble from a kit". My goal was to learn, and so I wanted to build the pieces from scratch as much as possible.