On a small scale machine, it is not always practical to activate
components using mechanical/contact means. In the case of a torpedo
launching from small AUV, it is ideal not to have any physical
connections such as wires or connectors between the vessel and the
projectile. A reliable light source and a light dependent resistor (LDR)
can easily replace a momentary contact switch. The figure below
illustrates the simplicity of the circuit:
For
the given circuit, the trigger is connected to a voltage divider. In
the dark, the LDR is measured to be at least 33k Ohms, providing a
minimum of .75Vs to the trigger. As the LDR is exposed to light, its
resistance drops, increasing the voltage going into the trigger. For a
10k Ohm pull up resistor, the resistance of the LDR should drop to
around 5k Ohms to bring the voltage down below 1/3Vs, activating the 555
timer. At this point, the output, which powers the transistors
controlling the motor to the torpedo, is driven high to Vs until the
reset pin is pulled below .7Vs.
To stop the torpedo,
the reset pin is connected to a momentary switch. This switch is
connected to the tip of the torpedo. When the torpedo runs into an
obstacle such as a wall, the reset pin will drop down to 0V, shutting
off the output, and consequently, the motors.
A 555
timer in this configuration is known as a bistable circuit. It maintains
its current output state until interrupted by the reset or trigger
pins.
Image source: http://www.kpsec.freeuk.com/555timer.htm#bistable
Image modified by: Author
Sunday, June 3, 2012
Friday, May 25, 2012
Friday april 18th meeting
Here is the overall result of our meeting on friday, may 18th.
As where we are today, we have a water proofed chassis that drives around. Both cameras are working sufficiently. Compass needs some work but it is functional. Tether seems like it works properly and we have some manipulators but they require more work.
Next we laid out what we need to do for short term goals.
Next there was a discussion on what cables go in and out of the computer box and the oterbox.
Then the missions were reviewed and we decided in what order we want to approach and take care of the tasks.
Missions:
#1 Visual: Square Gate.
#2 Id 9 inch Colored Buoys(Red, Green, Yellow) and in order
#3 Visual: U-Shaped Bridge.
#4 Dropping markers in bins
#5 Shooting Torpedo
#6 Manipulation of two cylinders horizontally and vertically.
#7 Capture Laurel at depth and surface inside an octagon.
We grouped the tasks that were at the same level of difficulty. From simplest to most difficult.
Group1: Tasks # 1and 3.
Group2: Task # 2.
Group3: Task # 4.
Group4: Tasks # 5 and 6.
Group5: Task# 7.
Following is a table of what we pan on accomplishing by the stated date given that we have 8 weeks to the competition.
As where we are today, we have a water proofed chassis that drives around. Both cameras are working sufficiently. Compass needs some work but it is functional. Tether seems like it works properly and we have some manipulators but they require more work.
Next we laid out what we need to do for short term goals.
Next there was a discussion on what cables go in and out of the computer box and the oterbox.
Then the missions were reviewed and we decided in what order we want to approach and take care of the tasks.
Missions:
#1 Visual: Square Gate.
#2 Id 9 inch Colored Buoys(Red, Green, Yellow) and in order
#3 Visual: U-Shaped Bridge.
#4 Dropping markers in bins
#5 Shooting Torpedo
#6 Manipulation of two cylinders horizontally and vertically.
#7 Capture Laurel at depth and surface inside an octagon.
We grouped the tasks that were at the same level of difficulty. From simplest to most difficult.
Group1: Tasks # 1and 3.
Group2: Task # 2.
Group3: Task # 4.
Group4: Tasks # 5 and 6.
Group5: Task# 7.
Following is a table of what we pan on accomplishing by the stated date given that we have 8 weeks to the competition.
Wednesday, May 23, 2012
Ethernet Discoveries
After hearing some advice and following up with research, the team learned that the Fast Ethernet (100Base-T) only uses 4 out of the 8 wires in an Ethernet cable. After tearing apart an old Ethernet cable, pins 4, 5, 7, 8 were clipped and have been confirmed to work as intended. For Gigabit Network Interface Cards (NIC), Ad-HOC is auto-detected, eliminating the requirement of a crossover cable.
Python Submarine Class
A class for controlling the submarine has been completed. Using the functions turnLeft, turnRight, goStraight, ascend, descend, clawopen, clawclose, and stop, a Python program can autonomously control the onboard motors.
Submarine( port, baud, cmd_size ):
This is the class constructor for the Submarine. The port is the serial port to which the motor controller is connected. The baud is the baud rate for the serial port. cmd_size is the length of the commands to be sent to the motor controller. The default for cmd_size is 8.
turnLeft( int ):
Taking a parameter between 0 and 100, the RoboSub will turn left using the appropriate number of thrusters. If the power is between 1 and 50, the left motor will move in "reverse." For power levels greater than 50, the right motor will push forward. At 100, both motors are operating at full power in opposite directions.
turnRight( int ):
Identical to turnLeft, except the motor roles are reversed.
goStraight( int ):
This takes a parameter between -100 and 100. At -100, the left and right motors will be at full power in reverse, and at 100, the motors will be at full power forward.
ascend( ):
This forces the climb motor to draw the RoboSub toward the surface.
descend( ):
This brings the RoboSub lower into the water.
clawopen( ):
This will open the claw and shut off the motor after a brief moment.
clawclose( ):
This will close the claw and shut off the motor after a brief moment.
stop( ):
This shuts off all motors and the robot should start floating if it is positively buoyant. Depending on time, this may change to allow the climb motor to counteract the buoyant force and maintain its current depth. ( Ideal )
Usage is as follows:
import submarineclass
import time
RoboSub = submarineclass.Submarine( 9, 2400 )
RoboSub.turnRight( 25 )
time.sleep( 1 )
RoboSub.goStraight( -90 )
time.sleep( 5 )
RoboSub.stop( )
RoboSub.clawopen( )
RoboSub.ascend( )
time.sleep( .4 )
RoboSub.stop( )
RoboSub.clawclose( )
This should turn the RoboSub right for 1 second, then move backward at 90% power for 5 seconds, open the claw, move up a bit, then close the claw.
Submarine( port, baud, cmd_size ):
This is the class constructor for the Submarine. The port is the serial port to which the motor controller is connected. The baud is the baud rate for the serial port. cmd_size is the length of the commands to be sent to the motor controller. The default for cmd_size is 8.
turnLeft( int ):
Taking a parameter between 0 and 100, the RoboSub will turn left using the appropriate number of thrusters. If the power is between 1 and 50, the left motor will move in "reverse." For power levels greater than 50, the right motor will push forward. At 100, both motors are operating at full power in opposite directions.
turnRight( int ):
Identical to turnLeft, except the motor roles are reversed.
goStraight( int ):
This takes a parameter between -100 and 100. At -100, the left and right motors will be at full power in reverse, and at 100, the motors will be at full power forward.
ascend( ):
This forces the climb motor to draw the RoboSub toward the surface.
descend( ):
This brings the RoboSub lower into the water.
clawopen( ):
This will open the claw and shut off the motor after a brief moment.
clawclose( ):
This will close the claw and shut off the motor after a brief moment.
stop( ):
This shuts off all motors and the robot should start floating if it is positively buoyant. Depending on time, this may change to allow the climb motor to counteract the buoyant force and maintain its current depth. ( Ideal )
Usage is as follows:
import submarineclass
import time
RoboSub = submarineclass.Submarine( 9, 2400 )
RoboSub.turnRight( 25 )
time.sleep( 1 )
RoboSub.goStraight( -90 )
time.sleep( 5 )
RoboSub.stop( )
RoboSub.clawopen( )
RoboSub.ascend( )
time.sleep( .4 )
RoboSub.stop( )
RoboSub.clawclose( )
This should turn the RoboSub right for 1 second, then move backward at 90% power for 5 seconds, open the claw, move up a bit, then close the claw.
Thursday, April 5, 2012
New Sub Designs
A few hours of hacking away at AutoCAD Inventor led to this design for the robosub chassis. Notice the rendering and exotic tundra. I do not think that the sub will be effective on land, but it had much more dramatic shadows in this location.

I have generated some drawing file for the above components and we will attempt to cut them as soon as possible. The next step is to make sure that the motor controllers are working.
Corrosion test
After the thrust profile test was completed, I did not have enough time to dismantle the experimental set up, so I left it in our lab for a day until I could return to it. Upon extraction, I was much surprised to find the level of corrosion present on the DC-DC converter and 2 of the 3 shaft couplers on the motors.
Corrosion on the DC-DC converter
Corrosion on the shaft coupler
The rate of corrosion is really the interesting part of this test. The parts were likely submerged for 36 hours and look as if they are starting to grow barnacles. In order to prevent this, I believe we should apply a coat of acrylic paint to surfaces which will be continuously exposed to the water.
If it works for ships, it should work for us.
Tuesday, April 3, 2012
Thruster with new power supplies
We exchanged the original power supply: (see photo)
For two, also old but better power supplies:
The difference lies in the current ratings. The Cenco power supply is only rated to provide 3 amps at 50 volts, whereas each Lab-Volt can handle up to 10 amps. The reason the two are wired in series is because the Lab-Volts can only provide up to 36 Volts. Neither power supply can provide for all of our needs in the thruster profile, so two in series is the way to go.
Like last time, the thrusters were immersed in water to simulate the load the will experience while in operation. Unlike last time, the DC-DC converter unit was also submerged for the duration of the test.
Instead of varying the voltage on this trial, I merely set the Lab-Volts to generate a potential of 48 Volts, and then connected the motors.
Here is a summary of the results:

The difference lies in the current ratings. The Cenco power supply is only rated to provide 3 amps at 50 volts, whereas each Lab-Volt can handle up to 10 amps. The reason the two are wired in series is because the Lab-Volts can only provide up to 36 Volts. Neither power supply can provide for all of our needs in the thruster profile, so two in series is the way to go.
Like last time, the thrusters were immersed in water to simulate the load the will experience while in operation. Unlike last time, the DC-DC converter unit was also submerged for the duration of the test.
Instead of varying the voltage on this trial, I merely set the Lab-Volts to generate a potential of 48 Volts, and then connected the motors.
Here is a summary of the results:

Interesting differences compared to the previous experiment include that the sag voltage at the source is the same for each configuration (40V) and the current changes only marginally from two motors to three. If the resistance in the cable is approximately 5.5 Ohms, as was previously calculated, the power lost to the cable is 30, 38 and 43 Watts respectively.
Thruster Profiles
A question arose about the efficiency of our DC-DC converter, and
this also brought to our attention that we had not completed a thrust
review on our new motors. This post serves to correct this omission and
to characterize the efficiency of our power scheme.
First, the motors that we use are called Johnson Pump Motors, and are traditionally used as replacement motors for bilge pumps. You can see a picture of one on their website:
http://www.johnson-pump.com/JPMarine/products/bilge/sparemotor.html
We would like to understand the power profile of these bilge pump motors so we can make a power budget for the rest of the craft.
First, all of our motors were submerged in a bucket of water, in order to properly simulate the load they will experience while in use.
Next, a variable power supply was connected to a single motor, and the voltage was adjusted in 1 volt increments from 1 to 12 Volts.
The results can be found in this table:
At full power, one motor can absorb 60 Watts from the power supply. At this point, I am concerned about our DC-DC converter. The power on the input side is only rated to go to 120 Watts, and assuming 100% efficiency, the brick can only provide enough power to run 2 motors.
Now to characterize the efficiency of the DC-DC converter.
The unregulated power supply was set to 48 Volts DC, this voltage was sent through a 108 ft ethernet cable, and the motor was connected across the 12 V converter.
Immediately the supply voltage sagged to 38 Volts, this is understandable as the resistance of the ethernet cable is proportional to length, and some power is lost in the cable. Cat5 cable has 24 awg solid core wire in it, and its resistance per foot is .0256 (according to powerstream), this corresponds to a resistance of 5.53 Ohms (forward and back). The current in the cable is 2 amps, thus the voltage drop across the cable is approximately 11.05 Volts. This puts the predicted voltage at 36.9, which is close to actual.
Next, the supply voltage was varied and the current and voltage across each motor was recorded.
In the one motor configuration, the follow data was collected.
Unfortunately, I used the readings from the supply to provide the current and voltage readings, so the results are not compensated for the losses in the cable. Additionally, the supply voltage sagged to the recorded number AT the supply, so the real voltage across the DC-DC converter is likely (5.53 Ohms*Asource) less than the reported voltage. If you account for these losses the approximate efficiency is 78% from power into the brick to power into the motors.
When a second motor was added to the test, the following data resulted.
The efficiency is mostly similar, but the voltage across each motor has dropped from 11.8 to 9.7 and the current has dropped to 3.83. Additionally, the power budget per motor drops from 62.5 Watts to 37 Watts.
On the third motor test, the following data was collected.
Again, the voltage across the terminals drops significantly with the increased load, and the power budget per motor drops to 22.2 watts ( note that the third table has a data point 2 volts above the previous data)
It appears that the driving factor for this power limitation is the brick itself. The output has a maximum current of 10 amps, which is insufficient to run 3 motors simultaneously.
Another concern is running the rest of the electronics on the same system. If the voltage drops below 9 volts, many of our cameras will cease to function, meaning that if we drive full blast we will lose the ability to see.
I recommend that we take further data using a separate Ethernet cable to transfer power. This would result in a 4 fold decrease in the cable resistance, and would cut our cable losses to 2.75 Volts which may help alleviate some of these problems.
First, the motors that we use are called Johnson Pump Motors, and are traditionally used as replacement motors for bilge pumps. You can see a picture of one on their website:
http://www.johnson-pump.com/JPMarine/products/bilge/sparemotor.html
We would like to understand the power profile of these bilge pump motors so we can make a power budget for the rest of the craft.
First, all of our motors were submerged in a bucket of water, in order to properly simulate the load they will experience while in use.
Next, a variable power supply was connected to a single motor, and the voltage was adjusted in 1 volt increments from 1 to 12 Volts.
The results can be found in this table:
At full power, one motor can absorb 60 Watts from the power supply. At this point, I am concerned about our DC-DC converter. The power on the input side is only rated to go to 120 Watts, and assuming 100% efficiency, the brick can only provide enough power to run 2 motors.
Now to characterize the efficiency of the DC-DC converter.
The unregulated power supply was set to 48 Volts DC, this voltage was sent through a 108 ft ethernet cable, and the motor was connected across the 12 V converter.
Immediately the supply voltage sagged to 38 Volts, this is understandable as the resistance of the ethernet cable is proportional to length, and some power is lost in the cable. Cat5 cable has 24 awg solid core wire in it, and its resistance per foot is .0256 (according to powerstream), this corresponds to a resistance of 5.53 Ohms (forward and back). The current in the cable is 2 amps, thus the voltage drop across the cable is approximately 11.05 Volts. This puts the predicted voltage at 36.9, which is close to actual.
Next, the supply voltage was varied and the current and voltage across each motor was recorded.
In the one motor configuration, the follow data was collected.
Unfortunately, I used the readings from the supply to provide the current and voltage readings, so the results are not compensated for the losses in the cable. Additionally, the supply voltage sagged to the recorded number AT the supply, so the real voltage across the DC-DC converter is likely (5.53 Ohms*Asource) less than the reported voltage. If you account for these losses the approximate efficiency is 78% from power into the brick to power into the motors.
When a second motor was added to the test, the following data resulted.
The efficiency is mostly similar, but the voltage across each motor has dropped from 11.8 to 9.7 and the current has dropped to 3.83. Additionally, the power budget per motor drops from 62.5 Watts to 37 Watts.
On the third motor test, the following data was collected.
Again, the voltage across the terminals drops significantly with the increased load, and the power budget per motor drops to 22.2 watts ( note that the third table has a data point 2 volts above the previous data)
It appears that the driving factor for this power limitation is the brick itself. The output has a maximum current of 10 amps, which is insufficient to run 3 motors simultaneously.
Another concern is running the rest of the electronics on the same system. If the voltage drops below 9 volts, many of our cameras will cease to function, meaning that if we drive full blast we will lose the ability to see.
I recommend that we take further data using a separate Ethernet cable to transfer power. This would result in a 4 fold decrease in the cable resistance, and would cut our cable losses to 2.75 Volts which may help alleviate some of these problems.
Saturday, March 17, 2012
Yellow Whip Pinout
pin 1: 12V +
pin 2: 12V GRND
pin 3: Rx
pin 4: Tx
Future builds will include a second arduino to handle sensor data. This arduino will have SDA and SCL pins for I2C communication.
Friday, March 16, 2012
Voltage drop across the 100 feet ethernet cable
Today we wanted to make sure we can send 48V through our 100 feet ethernet cable without losing more than 12V while pulling about 3A.
So I devised the following setup to figure out the voltage drop across the cable.

At first I used a 150 W lamp in series and the voltage drop across the cable was about 2V from 1A. Eventually I used two rheostats for a lower total resistance and the voltage drop was 7.2V while pulling 3A. This proves that we can send the power for the cameras and otterbox through the cable without harming it.
So I devised the following setup to figure out the voltage drop across the cable.
At first I used a 150 W lamp in series and the voltage drop across the cable was about 2V from 1A. Eventually I used two rheostats for a lower total resistance and the voltage drop was 7.2V while pulling 3A. This proves that we can send the power for the cameras and otterbox through the cable without harming it.
Thursday, March 15, 2012
Serial Joystick Box
Below is a link to the documentation on the Serial Joystick box.
http://profmason.com/?p=1805
Orange and White (TX)
Orange (RX)
Green (Ground)
Green and White (5V in)
A couple of implementation notes: The serial TX (Orange and White) should be on a twisted pair cable with a ground cable (which is green on this box) These two cables are the minimum that we need to send down. The green and white wire is power to the box (currently set to 5V, but if we use the wires taped to the back we can set it for 12V)
http://profmason.com/?p=1805
Orange and White (TX)
Orange (RX)
Green (Ground)
Green and White (5V in)
A couple of implementation notes: The serial TX (Orange and White) should be on a twisted pair cable with a ground cable (which is green on this box) These two cables are the minimum that we need to send down. The green and white wire is power to the box (currently set to 5V, but if we use the wires taped to the back we can set it for 12V)
Monday, March 12, 2012
OtterBox Test Results

Once the box was opened, I was pleased to find that there were absolutely no water drops inside of the case.

To further test the waterproofing of the Otter Box, the cotton balls were removed individually and inspected one at a time for any sense of moisture collected over the 14 hour sit. The test also indicated no evidence of moisture in each of the cotton balls.

To conclude the first stage of it's durability and waterproofing test, the result proved the Otter Box to be successful. The Otter Box was able to resist water (up to about 9 feet under water) and is officially ready for the second stage of it's testing phase - which will include drilling holes for connectors and re-submerging the box with the connectors underwater again.
Sunday, March 11, 2012
OtterBox Test
After the pole was dipped in the water, water traces were left on the pole which was used to determine the approximate depth of the pool. Also, a black line was edited to mark its location of water mark.
Here is the team's new Otter Box 2.0. Never used and going to sink into the bottom of the pool to test for water leakage penetrating into the Otterbox before attaching connectors. The box will be tied to a long pole which will sit with the Otterbox and also be used to pull it back up.

To test for leakage, a handful of cotton balls are stuffed inside and placed at the base of the otter box with two 1-kg masses inside to sink the Otterbox.
Here is a closeup of the box as it sits for the next 12-14 hours. This shot was taken approximately 10 minutes after it had set. As we can see, next to no bubbles are floating to the surface which indicates no water penetration... yet?
Sunday, February 19, 2012
Mt SAC ROV Mark IV
Here are a couple videos of the robot driving...
Thursday, February 16, 2012
Coral Reef
Sunday, February 12, 2012
New Prototyping Chassis
Greetings submarine enthusiasts,
Here are some photos of the new prototyping chassis for the robosub team, mark IV. It may not look like much, however it has many benefits over the previous versions.
The first image is an isometric view, for a sense of scale, it has been placed on a standard school desk. The first thing you may notice is that the motors are some what undersized, but that will change when the new motors arrive this week.
The next photo is a top view, and in it you can see that the drive motors are slightly behind the center of the chassis. This is to balance the cameras and sensors which are in the front. The new shape may not look very stream lined, but its boxy shape actually allows for more fine tuning of the ballast and trim weights. All along the bottom pvc there will be holes drilled to allow weights to hang. These holes will be uniformly spaced so that adjustment of trim will be as simple as undoing and redoing a nut. The top pvc rails allow the ballast to be moved left, right, forward and backward to properly distribute the buoyant force. The climb motor has been placed approximately in the center of the chassis, which should allow for stable climbing and descending.
Tasks remaining to be completed on this chassis:
Build a pvc structure which extends beyond the motors so that we cannot crash them into the walls or tangle the tether into them.
Drill the holes in the PVC for trim
Interesting lesson learned during the fabrication of this chassis is that a 13/16th spade bit will create a hole which creates a sufficiently tight fit to 1/2 inch pvc pipe.
Friday, January 27, 2012
Torpedo Awayyyyyyy!!!
Here is the latest update for the torpedo that will be mounted and operated by the AUV.
motoron:
high motor
goto main
killswitch:
sertxd("kill",#b0,cr,lf)
low motor
end
Above is the code i wrote for my micro controller PICAXE. The logic of the program is to continually have power fed to the circuit until the momentary button is activated. Once the momentary button is activated the micro controller will execute 'killswitch' which kills all circuit protocol and power to the entire system.
Parts list:
(1) PICAXE micro controller
(1) momentary button
(x) necessary resistors
(1) LED
(2) transistors
(1) back EMF suppression diode
(1) D/C motor
Let me give a brief explanation for a few items. the micro controller is necessary because i wish to have an LED allowing me to be able to check the completion of the circuit. The momentary button will be mounted in the tip of the torpedo so when it hit something it will stop the program and motor.
(1) PICAXE micro controller
(1) momentary button
(x) necessary resistors
(1) LED
(2) transistors
(1) back EMF suppression diode
(1) D/C motor
Let me give a brief explanation for a few items. the micro controller is necessary because i wish to have an LED allowing me to be able to check the completion of the circuit. The momentary button will be mounted in the tip of the torpedo so when it hit something it will stop the program and motor.
Part 2: Code
symbol motor = 1
main:
readadc 4,b0 sertxd("msg",#b0,cr,lf)
pause 1000
if b0 >100 then motoron
if b0 <100 then killswitch
goto main
readadc 4,b0 sertxd("msg",#b0,cr,lf)
pause 1000
if b0 >100 then motoron
if b0 <100 then killswitch
goto main
motoron:
high motor
goto main
killswitch:
sertxd("kill",#b0,cr,lf)
low motor
end
Above is the code i wrote for my micro controller PICAXE. The logic of the program is to continually have power fed to the circuit until the momentary button is activated. Once the momentary button is activated the micro controller will execute 'killswitch' which kills all circuit protocol and power to the entire system.
Part 3: Mechanics
I havent settled on a tube to mount all my components in yet. Originally i wanted to mount all the components into a cigar tube, however discovering that i will need to have two separate power sources(one for the micro controller and one for the motor) and an added safety measure compartment to keep water away from all the electronics, i had to re-think the final product. Currently I'm leaning towards a fortified piece of plastic pipe, but i'm also investigating other options like different types of metal tubes. I have pictured right now is how i will be attaching the drive shaft to the motor as well as the propeller. My "universal" joint is plastic tubing that fits snugly around the drive shaft and the D/C motor shaft. I also use the same plastic tubing to ensure a tight around my drive shaft propeller. For the portion of the drive shaft that will pass through the hull to water i have obtained a hollow shaft that fits snug around the drive shaft. The fit is almost bearing like so i think with a little grease in side the tube PLUS the safety compartment that will separate the water from the electronic compartment.
******UPDATE******
the torpedo circuit is complete and works properly.
the code that is written for the circuit is executing properly.
the step before testing is to mount the components in an air tight hull.
and the final step before freeing the design of the torpedo is choosing a technique to integrate the torpedo into the AUV
the torpedo circuit is complete and works properly.
the code that is written for the circuit is executing properly.
the step before testing is to mount the components in an air tight hull.
and the final step before freeing the design of the torpedo is choosing a technique to integrate the torpedo into the AUV
Tuesday, January 24, 2012
Here is the prototype for the new Heads Up Display.
Andy and I worked on a nice little augmentation of the Otter Box which we will share at the next meeting.
from math import *
from visual import *
import serial
######################################################################
#Opening the serial port for the compass output
######################################################################
try:
compass.close()
except:
print "compass ready"
try:
compass = serial.Serial(2,baudrate=9600, bytesize=8,parity = 'N',stopbits = 1,timeout=None, xonxoff=0, rtscts=0)
compass.open
output = compass.readline()
print(output)
except:
print('you fail')
######################################################################
RightSideWindow = display(x=0, y =0, witdth = 600, height = 600,scale =(1,1,1) ,background = (.05,.05,.05), autoscale = false)
RightSideWindow.range = 10
headingVect = arrow(pos =(0,0,0), axis = (2,0,0), shaftwidth = 1, color = (.2,.7,.7))
northBox = box(pos=(0,3,0), height = 2,width = .1,length = .1, color = (1,1,1))
southBox = box(pos=(0,-3,0), height = 2,width = .1,length = .1, color = (1,1,1))
eastBox = box(pos=(3,0,0), height = .1,width = .1,length = 2, color = (1,1,1))
westBox = box(pos=(-3,0,0), height = .1,width = .1,length = 2, color = (1,1,1))
northLabel = label(pos = (0,4.5,0),text = 'N')
southLabel = label(pos = (0,-4.5,0),text = 'S')
eastLabel = label(pos = (4.5,0,0),text = 'E')
northLabel = label(pos = (-4.5,0,0),text = 'W')
northeast = box(pos = (2.5*cos(pi/4),2.5*sin(pi/4),0),axis = (-cos(pi/4),sin(pi/4),0),height = 1,width = .1,length = .1)
northwest = box(pos = (-2.5*cos(pi/4),2.5*sin(pi/4),0),axis = (cos(pi/4),sin(pi/4),0),height = 1,width = .1,length = .1)
southwest = box(pos = (-2.5*cos(pi/4),-2.5*sin(pi/4),0),axis = (-cos(pi/4),sin(pi/4),0),height = 1,width = .1,length = .1)
northwest = box(pos = (2.5*cos(pi/4),-2.5*sin(pi/4),0),axis = (cos(pi/4),sin(pi/4),0),height = 1,width = .1,length = .1)
headingLabel = label(pos = (0,6,0), text = 'HEADING')
while 1:
output = compass.readline()
heading = (double(output)-9)*pi/180.
x = -cos(heading)*2
y = sin(heading)*2
headingVect.axis = (x,y,0)
Friday, January 20, 2012
Pinwheel encoder test
The arduino code I used for testing:
int trigs = 0;
void setup()
{
pinMode(13, OUTPUT);
attachInterrupt(0, ledblink, CHANGE);
Serial.begin(9600);
}
void loop()
{
delay(100);
}
void ledblink()
{
trigs++;
digitalWrite(13, HIGH);
delay(200);
digitalWrite(13, LOW);
Serial.println(trigs);
}
....and a quick video:
Thursday, January 12, 2012
Camera Water Proofing part II
Here is the finished version of the waterproofed camera.

Here is the camera looking at the TV!
Here is a front view!
Currently the Camera is sitting in water for its first water test. As far as the electronics go, everything is running perfectly. As far as the video is concerned... it is not so good. It may be that the camera only has 12 inches of water between it and the furthest object, but nothing is in focus at that range.
I think that further testing in a larger body of water is necessary before proceeding to waterproof the other two cameras.
A complication arose during the potting process which may be responsible for the blur. Upon inspection of the finished product, it was noted that resin had seeped into the air gap between the case and the lens. As this would interfere with the video, I drilled out the air gap and cleaned the entire area. Luckily, the resin which seeped in was lacking in catalyst and was still in its liquid phase.
After the cleaning procedure, the camera was tested in air and found to be free of any optical defects. Water immersion revealed the focal problem, which may stem from the main lens being immersed in water as opposed to air.
Two possible conditions may apply.
The focal length has changed due to the immersion in water, and objects at distance will be in focus.
No objects will be in focus, and an additional layer of plastic will need to be added to reestablish an air gap.
Testing on Saturday will determine the proper course of action. Bardia's place, 9 am. If a solution is found, the other two cameras will be waterproofed after testing.
Wednesday, January 11, 2012
Camera Water Proofing
Water Proofing a Camera for Depth:
This I.C. Live Camera is going to become an under water camera, courtesy of some casting resin, hot glue and a plastic box. A link to explain the basics can be found here.
Now, much like the hermit crab, this camera can move on to better housing. But first we need to give it some juice. In order to test the video feed and focus the camera, I attached this Motorola 5 volt power supply and hooked up the video output to an old analog TV.
Once the Camera was appropriately focused, I sealed the focusing ring with hot glue. Additionally I sealed all components with silicone insulation. Here is what it looks like after the sealant is applied.
Once that stuff dried, I attached the top from a clear plastic box to the camera's plastic case.
The rest of the box has two bolts drilled through the sides and then sealed. Additionally, and not captured in photograph, a length of PVC was added to the housing so that this camera could interface with standard PVC fittings.
Once the top and bottom of the plastic box were mated, I drilled a small hole to pull the wires through and filled the entire box with resin. It is currently curing outside so that my house doesn't fill with resin fumes.
Once the resin cures, I will take video showing the performance of the camera and test it in water to make sure that it still functions in the manner that we need.
Subscribe to:
Comments (Atom)



















