Toggling OTG Function in a USB Cable

The new control system for FTC (new as of 2015) uses Android phones to control the robot.  One android phone hooks up to joysticks, reads those joystick values, and send them via a wifi-direct connection to a second phone.  The second phone attaches to custom hardware from Modern Robotics which controls a variety of motors and servos, or reads sensor values.  See Figure 1.

Figure 1

In the configuration shown in Figure 1, both phones act as HOSTS... they must provide power and dictate communications to passive electronic devices (joysticks) or active electronics programmed to be USB slaves (Modern Robotics devices).  A phone was not originally intended to be a HOST, rather it is by default a slave to a computer (the master) to which is may be connected to transfer files or charge.  Similarly, the phone was not originally designed to power other devices... the USB jack on a phone was designed to accept power so that the phone's battery could be charged.

A protocol call On-The-Go (OTG) was developed to allow phones to act as HOSTS under certain circumstances.  When a special cable is plugged into the phone, it acts as a HOST.  When a normal USB cable is plugged into the phone, it acts as a client and can be charged and receive information from a computer (eg be programmed).  See figures 2 and 3.  These two modes of operation are currently mutually exclusive (although there is talk of a new OTG standard which will allow the phone to charge even when in OTG mode... this standard currently only works on certain Android phones).

Figure 2: Configuration for CHARGING and
 PROGRAMMING.

Figure 3: Configuration for Running and
Controlling the Robot

In FTC, our students spend a lot of time toggling the phone between master and slave.  Whenever they program the phone from Android Studio or need to charge the phone, they use a regular USB cable so the phone is the slave.  Whenever they want to test the robot, the phone is the master and an OTG cable is required.  Each toggle requires the cable to be swapped out.  It became clear to me that this was an issue about halfway through the 2015-16 season as students started reporting that the micro USB connectors on the phones (ZTE speeds) were breaking.  We moved to better phones (Moto G2 and G3), but even with those there have been failures.  While the logical fix to the problem is to coach kids to be careful and gentle when swapping out cords, in practice this is a futile endeavor.
The difference between a standard USB cable for an Android phone and an OTG cable for an Android phone is that the fifth pin (called the "ID" pin) is left open for a standard cable, and grounded for an OTG cable (Figure 4).  Hence a logical "fix" to the two cable problem seemed to me to make a cable with a switch that shorted the ID pin to ground in one position, and leaves it unconnected in the other (Figure 5).

Figure 4

Figure 5

I purchased USB DIY connector shells from Adafruit (figures 6, 7).  This is the link for the standard size, and this is the link for the micro shell.  I located pinouts for each of the shells (figure 8) and soldered solid core wire to each connector.  Soldering to the micro USB connectors is tough... the size of the solder pad and the spacing between them are both small.  It takes a steady hand and good hand-eye coordination, as well as a lighted magnifying glass.

Figure 6

Figure 7

I tested the concept by wiring the two USB connectors together on a breadboard.  I could "toggle" the state of the ID pin by putting the wire for that pin into the breadboard line for GND, or leaving it out.  The test proved successful, so I soldered all the wires together using  a switch as shown in Figure 5.  Figure 9 shows one of two finished cables that I made. 

Figure 8

Testing showed that the cable worked.  I needed a female to female connector and then a male to mini connector to test the connection to the Modern Robotics hardware.  I used the female to female connector along with a male to male cord to connect to the computer, and to test charging the phones.  All of the functions worked!

Figure 9

I attempted to replicate the procedure and make a second cable and had much more trouble.  The soldering was messed up on the micro connector once and I had to start over.  The breadboarding test showed erratic behavior.  I purchased a micro USB female breakout (Figure 10) to make sure that my soldering was done well.  When I couldn't find a problem there, I just soldered the wires directly to the standard USB connector and that seemed to fix the problem.

Figure 10

In all, this was a successful experiment to show a possible method to fix the problem of having to swap out cables.  However, I was not convinced on the durability of the custom cables that I made, and they are not easy to remake.  Hence, these cables are used on our school's soccer bots (Figures 11 and 12), but not on competition robots.  The CAD files for Moto G3 phones for use with these custom cables are found here.  I suspect that a new family of cables similar in principle to the one I made will be on the market soon, making my work obsolete.  Still, it was a fun challenge.

Figure 11

Figure 12

WaterProof Electronics Module

Our robotics team participated in the MATE underwater competition last year, and one of our design goals was to make a mechanized gripper which functioned underwater.  We learned that this is hard after several failed attempts, several of which are shown in Figure 1.

Figure 1

Despite good intentions, servos sealed with silicone sealant and an o-ring to seal the rotating shaft failed after less than an hour in the water.   A housing for electronics made from PVC couplings sealed with PVC cement and teflon tape over the threads for the endcap also failed.

Figure 2

I worked on my own (without students) to come up with an alternative for the electronics housing.  I located several waterproof boxes online, such as this one, shown in Figure 2.  They use a strip of rubber which gets seated in a groove and compressed by a shoulder.  The boxes make a good watertight seal, but getting cabling into the boxes presents a problem.

Figure 3

There are a bunch of bulkhead cable connectors on the market, such as those shown in Figure 3.  There are also metal ones such as this one. The idea is that you make a hole in a box, then slide the connector through the hole.  The connector is sealed by compressing an o-ring when a nut is tightened.  The cable itself goes through the opening in the middle and is compressed against another o-ring.

Putting those products together, I made a test enclosure shown in Figure 4.  While it looked good, it still leaked over time.  The bubbles could be seen coming from the bulkhead connector where it sealed with the box.

Figure 4

I came up with a design based roughly on the double o-ring sealed designs of enclosures made by Blue Robots (https://www.bluerobotics.com/product-category/watertight-enclosures/), which used two pieces of 1 1/2" diameter PVC rod (McMaster 8745K22) as plugs for the ends of a transparent plastic tube.  PVC is cheap and easy to machine.

I did all my machining on the PVC with this lathe tool from MSC Direct.  It is described as  Accupro - 3/8 x 3/8 Inch Shank, Full Radius Cutoff and Grooving Single Point Tool Bit GS-060F, Grade Micrograin, 0.06 Inch Groove Width, 0.21 Inch Depth Of Cut.

I turned a 1.245" diameter, 1" long shoulder into the PVC.  On that shoulder, I turned two grooves for o-rings.  The width of the grooves was 0.16" and the final diameter of the PVC was 1.04".   Each groove holds an o-ring, #214, McMaster # 9452K34, with actual width of 0.139" and actual inner diameter of 0.984".

This made for a fairly tight fit with the acrylic tubing I was initially using (part of the kit from SeaMate, part 1-ACC-1201-AA).  However, it made a very nice fit with the polycarbonate I ordered from McMaster Carr, 8585K206, inner diameter 1 1/4" +/-0.050".

Testing with the plugs in the acrylic tubing showed that the container was waterproof.  Testing was done by placing the container fully submerged into a large container full of water (sealed 4" ABS pipe in one case, coffee carafe in another) and letting it sit for roughly 12 hours.  As various webpages note, all seals leak, so while I didn't see signs of leakage, that doesn't mean it won't happen on a real underwater ROV in real operating conditions.

I next used an 8.5mm diameter drill bit (0.3346, essentially Q size) to create through holes in the center of each of the plugs.  These holes were tapped for 10mm x 1.5 and then filled with cable penetrators (here and here from Blue Robotics) with the threads wrapped in Teflon tape.  I initially only did this procedure on one plug and used the enclosure vent and plug as a test to see if the hole was sealing underwater.  Once it did, i installed the cable penetrator.

The last step was running the cable through the penetrator and waterproofing the penetrator.  I followed the guidelines posted on the MATE website, specifically at this link:  http://www.marinetech.org/module4/.  They suggest using marine epoxy and sealing on both the outside and the inside.  On the inside, they suggest stripping a bit of insulation from each wire in offset locations and then covering this part with marine epoxy.  This prevents water from entering the container between the conductor and insulator of each strand, as shown in Figure 5.  There are clearer directions here.

Figure 5

The result of all this work is a functional and professional looking container, Figure 6.  The electronics board in the tube is connected by five wires which include input power (12V), output power (5V, regulated), ground, output servo signal, and input to trigger the servo switching positions.

Figure 6

I placed the module underwater in a coffee carafe for two hours and ran the toggled the position of an attached servo intermittently.  The servo functioned throughout the test and there was no water in the electronics module when it was removed.

Figure 7

The electronics module runs an Adafruit 5V Trinket.  A simple PCB board is shown in Figure 7.  Eagle CAD files can be found here.  A LM1085 steps 12V down to 5V which is the supply for the servo.  There is an input wired to Trinket pin 0 which triggers one of two different pulses on pin 1 (the control pin for the servo).  Because the Trinket has only an 8 bit timer, it requires a different library (the normal Arduino servo library uses a 16 bit timer), called the Adafruit Soft Servo library.  With the library, you need to "manually" setup the servo to refresh happen every 20ms.  This is done by setting up a timer in the setup function (Figure 8), and then using the function shown in Figure 9.

Figure 8

Figure 9

The code for this project is found on Github here.