An
Adventure in Engineering Design, Programming, and Pursuit of Robotic
Projects: Updated 06/18/2009
Project
log for the Squidlian
STATUS
- CANCELLED
Final
Accomplishments (14 June 2009):
Demonstrated
Visual Basic control and sensor concepts: compass, voltage sensor,
control of relay via buttons, and establishment of communications
via the network connection panel
Established
learning basis for creating VB controls & communications
Validated
concept of Ethernet cable / USB extension for communications and
video
Discovered
relative difficulty in mating PVC pipe with acrylic pipe for sealed
connections (involved using fiberglass and epoxy...)
Why
the Squidlian? by Justin S. McFarland (August 3, 2008)
Originally,
I had a desire to do some significant engineering on an attitude
dynamics project similar to my days in the Spacecraft
Systems Simulation Laboratory at Virginia Tech. As a paid
student researcher in that lab, I was responsible for the cold gas
propulsion system from May 2003- May 2004. Upon full admission
into USC in Fall 2007 I wanted to see if I had the talent to recreate a
similar project and perhaps advance beyond it and attempt to publish
technical papers combining the project knowledge and coursework.
Knowing that an air bearing system was a bit out of the question, I
sought after the 2D planar robotics projects and pondered over doing
something in a fish tank. After the costing of a large fish tank,
realizing that many of the components / sensors were too big for a
design, and other difficulties in March 2007, I was pointed to the
concept of an underwater Remotely Operated Vehicle (ROV) from a
discussion on www.societyofrobots.com.
After reviewing the
Rollette design (Concept
Reference: Jason Rollette
http://www.rollette.com/rovrev2/),
and realizing that the designer was an electrical engineer (and thus a
different set of motivations and comfort levels in design) there were
some differences that had to be introduced into this design aside due to
'technology readiness' as well as differences from the operational requirements.
Talking to Bob Soli about the
concept, we seemed to found our purpose, some general requirements, and
shortly after we were hooked.
Purpose:
to build a guided remotely operated underwater vehicle used to support
Bob Soli with the task of scrubbing algae from the bottom of Blue Boat
(his Cal-27) by illuminating the hull with lighting, providing, video
coverage of the area. The secondary purpose is to play around and
explore the shoals and areas around the marina to potentially aid in
future navigation of boats in the area, monitor pollution, water
temperature, and support potential salvage operations. The primary
overarching purpose is to build a cool project to 'get our feet wet' in
a complete design of a underwater system, have fun, and don't get
hurt.
Requirements:
Construct
a simple remotely operated vehicle capable of submersing 8'+ in the
Potomac River
that must
Be
able to be launched from Blue Boat
Survive repeated exposures to the
marine and surface environments
Provide ROV guidance through use of video to the surface
Identify
(or enable a user to identify) a suspect area on the hull for inspection
Provide continuous illumination of the target area for scrubbing of a
boat hull for 10 minutes [TBR] within 10 cm [TBR]
Allow for replacement of expendable hardware with minimal risk to
surrounding systems (e.g. light bulbs)
Document
Be
completed by 31 July 200830 September 2008
31 December 2008
Documentation:
1.
Commented source code (e.g. set of BS2 files), microcontroller(s) (e.g.
1- BASIC STAMP 2), compile method/compiler (Parallax Basic Stamp Editor
v2.3), and platform (Windows XP). Source code comments must
declare all variables used & intrinsic function calls (e.g. FREQOUT).
2.
CAD files, design drawings, and/or images taken during assembly with
dimensions
3.
Bill of Materials / Parts List; costs; vendor(s)
4.
Electronics schematics & circuit verbal description using IEEE
symbology as much as possible
5.
Discussion about tips on building the ROV, mistakes to avoid, or
possible additions that could/should be added to make it better.
6.
Video (if possible) of the robot in action to show what it can do and
why anyone in their right mind should try to repeat the construction
process
Task
List
Determine
test method for using an operational battery and the relay card
(New 8/3/08)
10. Get Use operational batteries sufficient to test the bilge pump
underwater (Revised 8/3/08)
12.
Design algorithms for bilge operational control pump firing
(Revised 8/3/08)
…
14.
Build HyperTerminal remote test bed and verify real-time MCU to relay
card connectivity
…
Integrate
compass sensor (New 8/3/08)
[on-going testing last updated 9/28/08]
Integrate
accelerometer sensor (New 8/3/08)
Integrate
voltmeter sensor (New 8/3/08)
[on-going testing last updated 9/28/08]
Integrate
temperature sensor (New 8/3/08)
Integrate
conductivity sensor (water leak) (New 8/3/08)
Test
operational breadboard relay card design (New 8/3/08)
17.
Complete first build of craft construction
18.
Alter craft to achieve neutral buoyancy
18.
Test hull underwater
19.
Integrate final electronics and wiring, seal and test underwater
…
20.
Alter craft to achieve neutral buoyancy
21.
Test integrated craft systems underwater
22.
Test LED / Camera functionality underwater
23.
Conduct maneuvers underwater
…
Build
camera tilt/pan unit
Make
improvements!
Tasks
Completed
Test the camera underwater and record video!
[8/24/08]
Test
protoboard with operational LED matrices (New 8/3/08)
Protoboard
operational breadboard relay card design (New 8/3/08) [8/22/08]
Construct
operational LED matrices (New 8/3/08) [8/21/08]
Seal front end section and test underwater
[8/16/08]
Build GUI controls and verify real-time MCU to relay card connectivity
[8/11/08]
Add to the relay card test circuit, the LED panel
[8/3/08]
Integrate LEDs on the PC board and solder
[8/2/08]
Build a test LED circuit for each color
[7/30-8/2/08]
Connect MCU to relay card with pumps and test sequence
[7/26/08]
Build a test circuit from the relay card to the MCU and test relays
[7/26/08]
Build relay card test circuit with bilge pump and manually actuate DIP
switches for use
[7/10/08]
Purchase
batteries [7/4/08]
Finalize
power estimate [7/4/08]
Form the camera mount (double sided tape + Styrofoam?)
[6/27-30/08]
Integrate front end section of submarine with hardware (PVC, etc.)
[6/30/08]
Solder the relay card together
[6/27-30/08]
Test
communications architecture (video and serial connection) [6/23/2008]
Identified
candidate communications architecture
Identify
candidate configurations
Identify
candidate construction materials and techniques
Identify
candidate video cameras
Updates
Thursday,
June 18th 2009 - Posting Old Data
One
of those delightful things that haven't been posted where more of the
final configuration pictures of the Squidlian. Here are some
images from October 8-9, 2008. The first images here are some of
the epoxies used and a mixing station. The next photo shows the
Ethernet connection through the end-cap.
Images
of the Squidlian construction. Note the intense levels of
fiberglass, epoxy putty, and epoxy on the surfaces to see some of the difficulties
at waterproofing the connections. LED lights are shown on after being
commanded by the test relay card / battery manually. Bob is shown
holding one of the small Rule bilge pumps that he later installed with
bungie cords (not shown).
Image
of the connection terminal (left side of GUI independent window
open). Right panel is the control panel, the upper left indicator
is the voltmeter level. The compass is in the upper right and the
controls are at middle bottom. Indicator lights are in a vertical
bar to indicate which relay is open. Some dormant alarm indicators
are in the lower left. On the desktop is the Arduino at right
connected to the digital voltmeter, analog voltmeter, and compass board
which is connected to the battery at left.
Sunday,
June 14th 2009
The
Squidlian project has been cancelled. A few more images will be
posted in the upcoming weeks to show the final as built configuration
that's currently at the Soli residence. No significant progress
had been made since the last post and much of the resources for building
the Squidlian have been moved over to the Inky, Blinky, Clyde, and Pinky
projects as well as Camera-on-a-Stick. Camera-on-a-stick is going
to use the parts from Squidlian in a fairly similar configuration as the
one we have currently. The idea is to flood the mid hull section,
ballast the camera section (and waterproof it), attach cable lines to
the structure (eyelits), and then lower it into the water for a video
and sensor test bed. As a submarine project the Squidlian was
underpowered and extraordinarily bulky.
Monday,
September 29th 2008
It's
been pretty hectic around here trying to get through my homework and
deal with the day-to-day operation of the McFarland household - but
we're still kicking. Unfortunately the stock market crashed 770
points, Congress doesn't know how to get along, and more importantly
we're going to miss the scheduled milestone of launch again.
Fortunately, Bob has been making steady
progress with the assembly and integration of the propulsion
system. We've both been making progress in our areas. I've
been finicking with the voltmeters - both the LED display and the analog
voltage sensor as well as the compass. The sensor protoboard
seemed easy enough in concept but in implementation the header pins and
wires may have been too noisy for the voltmeter and compass to work well
together. The source of error is unknown at this time but after
hours of playing around - I've decided to start from scratch and
redesign the protoboard into a cleaner configuration.
Early
last week I went over to Bob's to help out with leak testing. The
Squidlian main hull is shown standing vertically on it's own (a
desirable storage feature). It's ~52" tall and ~32"
wide. We proceeded to take the vehicle upstairs to fill it with
water (after removing the camera). We found some leaking in the
areas Bob sanded the joint epoxy and identified them with magic
marker. We filled the vehicle from one corner and then sealed that
corner and moved the water around inside the vehicle from corner to
corner testing all the joints. This method seems to work well, but
is only unfortunately representative of very shallow descents.
After
testing, I needed to take the vehicle back home with me to get
measurements for the relay card to fit through the 4-way rear section of
the vehicle. This ironically proved how portable the vehicle is by
car (this was an initial consideration) as well as moving it in and out
of the houses and elevators. I handled it easily myself by
slinging it over my shoulder like a newspaper bag.
Bob
has continued work on the vehicle by adding fiberglass to key areas to
clean it up as well as mounting the LED headlights he purchased separately.
These lights are white high-intensity lights for marine vehicles (my
green lights were pushed aside in order to avoid dealing with more parts
to water proof at this time). He's devised methods for
through-hulling the wires from the LEDs and bilge pumps as well as how
to mount them. I hope to go over midweek to review progress and
give him more help with the spaceframe internal structure we'll be using
to mount the camera, batteries, and other goodies inside the
vehicle. We'll also be working on the ballasting mechanisms to get
the vehicle neutrally buoyant for our first set of in water tests.
Our
tests will start as surface only maneuvers testing out the range of
motion of the tethers using the 4 attitude thrusters. We'll also
get an assessment of vehicle speed and handling qualities. It has
been our plan for weeks now that we're going to delay the vehicle
performing descents ant ascents until we have done a manual pulley-based
descent. The objective is to do a test and assessment of the
quality of the images from the camera in the dirty Potomac water with
and without the lights of Blue boat. We can do this even on the
surface with the tilting camera and the vehicle being able to be
manually pushed up and down via a pulley. We plan on waiting until
spring to really get more design improvements together - including a
complete rework of the hull. The idea being to use the current
prototype as such, a means to test out ideas, but not necessarily go all
out on this version if major improvements can be made or if design
features are desired for the next generation vehicle.
Reviewing
the requirements - the vehicle need not be launched from Blue Boat but
can be launched from the marina and operators can be transfered to Blue
Boat. We should be able to survive repeated exposures. We
should have ROV guidance worked out as well as video transmission.
In doing so we should be able to stare at a target and remain on
target. Using the spaceframe concept we hope to deal with swapping
in and out of hardware. Documentation is still ongoing and
hopefully will have a large amount of progress by the 11 October
Robotics meeting where I'll be presenting. And well, I missed the
deadline again...
Be
able to be launched from Blue Boat
Survive
repeated exposures to the marine and surface environment
s
Provide
ROV guidance through use of video to the surface
Identify
(or enable a user to identify) a suspect area on the hull for
inspection
Provide
continuous illumination of the target area for scrubbing of a boat
hull for 10 minutes [TBR] within 10 cm [TBR]
Allow
for replacement of expendable hardware with minimal risk to
surrounding systems (e.g. light bulbs)
Document
Be
completed by 31 July 2008 30 September 2008
Sunday,
September 14th 2008
This
weekend worked more on the GUI and also did more propulsion calculations
with the updated estimated wetted area of the Squidlian. The
propulsion system is to involve using 4 x 500 GPH bilge pumps for maneuvering
and a combination of additional thruster systems for additional top
speed.
Thursday,
September 11th 2008
Over
the past several weeks the custom relay card has been coming together
and tonight I finished the digital testing of the board. The
design concept originally called for 3 separate boards, 1 board (the
switching board) being elevated over two boxes with their own boards
(effectively making it approximately 3 board lengths long), but upon
inspection of the 3 board approach - it was found that a sandwich style
board could be made with the relays all on one card in a much more
elegant and compact design. So I started that the weekend of
the 24th with the arrival of new parts and began the prototyping process
with PowerPoint sketches and moving parts around on the boards
physically.
It's
been a struggle since the beginning, starting with the manual DIP switch
testing and then working my way up to doing the digital testing while
connected to the MCU. The testing methodology was build a little
test, then build more then test. I setup the terminal blocks
first, the IC strip (sans Darlington Array), the DIP switch, capacitor,
resistors, diodes, and LEDs on the board and soldered them
appropriately. I then started soldering the power and grounding
wires to the first LED and tested it's connectivity. Then I
finished a side (4 circuits at a time) then the next.
The
2nd phase (worked on 1 September) was combining the switching card to
the relay / capacitor filter card. This involved drilling
out holes into the protoboard to fit the relay center pole. After
this was accomplished the wiring of the capacitor / resistors filter
banks was accomplished eventually resulting in again starting with one
relay then working to 4 then to the other half. Each of these
stages allowed for use of the DIP switches for testing.
After
confidently testing the manual portion of the card, I installed the
Darlington Array and began digital testing. Some issues with the
digital testing were discovered from forgetting to solder some
connections together, to finding overlapping solder regions, melted
wires with exposed copper, to realizing that I need to have a common
ground (again!) between the MCU and the relay card. Testing
confirming that the MCU / relay card connection could be flawlessly
achieved occurred 11 September.
Concurrent
testing occurred with the Visual Basic 2008 Express Squidlian GUI with
Compass and it was proven that both can operate perfectly well
concurrently. The picture shown shows the relay card setup
connected to the MCU and power supply. The MCU was connected to
the compass breadboard and an intermediate breakout board assisted with
the ground and other connections. The MCU was connected to the
computer over the serial hard line.
Monday,
September 1st 2008
I
put together the 2nd half of the relay card yesterday and started
integrating the two together. I got halfway through the
integration (4 relays are active and tested of 8). I verified that
it fits fine in the straight 4” ID 4.5”OD PVC pipe… BUT… when I
went to try to put it into the new 4 way intersection sections… it got
stuck! The inner dimensions of the 4-way section at the point of
intersection is not 4”. It does this funky extrusion that screws
everything up. So I’ll hope to shorten my spacers between the
protoboards boards in order to make it fit.
I
also worked on the compass more last night and early this morning before
going into work. I have a time lag problem! It sends the
command to the compass to send a reading. The compass does so
after 40 ms delay. The data reader on the computer side however
sends the command then immediately tries to read the data from the card
getting… nothing! Doing it manually of course works since there
is larger than 40 ms delay! So I need to find some function for a
delay in VisualBasic that I can put in there to grab it autonomously.
*sighs* It doesn’t ever seem to end.
Also
– my parents said they were closing the pool shortly.. so any
submarine testing in controlled clear water has to occur within 10 days.
We could get the structure completed by then and do more leak
testing, but probably won’t be able to submerge it. We probably
could get thrusters mounted on it by then and it would be a surface
vessel with a camera however.
Sunday,
August 24th 2008
Structure
Update:
Squidlian
goes for a swim! Bob came over today after being 'torn' from work
on a Sunday...
To
prepare for the event, I rebuilt the foam forms to make them a better
fit with the structure. I also added (2) 3/8" dowel rods into
the design with cardboard backing on one section to assist in keeping
the camera sections together, a problem I discovered around 1 pm this
afternoon when trying to load it into the vehicle. I failed on two
sections but the 3rd and 4th worked well. I sanded down the forms
largely with my figure, a piece of sand paper, and also a large block of
sandpaper over the two sections. Each is approximately 4 inches in
diameter, enough to fit inside the pipe sections but small for the inner
acrylic section. This section has 2 pieces of 4-1/2" OD/
4" ID light duty PVC approximately 1" wide.
The
camera opening now is clear of debris and the backlight is
covered. Interestingly the microphone is partially covered but you
can still hear significant amounts. This could prove useful for
diagnosis of problems in the future. The camera was hooked up
using the Ethernet adapter cables & the underground 100'
cable. The desktop PC was used for the video recording.
The
next round of testing occurred outside in the pool. The cable
unfortunately did not work with the laptop. This may have been to
the fact that the laptop's power is low and the USB ports are known to
be flaky. I did eliminate the long cable in the loop and then the
camera worked again. This unfortunate delay on a low battery did
not allow for much testing and we did not get to save all the videos the
last of which was definitely going to be the best. Meanwhile, I
got some upside-down video at least (Bob did later turn the vehicle
around and flip the camera).
Control
Update:
Significant
progress on the front of the GUI over the past week. Jason Sexton
and his large library of VB books helped me out significantly. The
GUI includes a compass indicator, water detection, battery, temperature,
MCU, and relay status as well as controls for the craft. The comms
menu brings up the previous GUI module for connection to the Arduino MCU.
The design took a long time to draw the compass components and their 24
frames and the various indicators. I have tested manually updating
their states to my satisfaction and have since added the beginnings to a
compass calibration routine. To note I added some flair from my
CFFC days in the cardinal symbols... I thought it was appropriate.
On
Wednesday afternoon I received my relays, resistors, capacitors, and LED
lights required to finish the build of the 2nd LED panel and start
construction on the custom relay boards. I didn't do as well with
this panel as I did previously because I accidently used 40W setting
instead of the 20W setting on the soldering iron.
As
indicated by the tutorial, I did build a prototype for the relay card
that was confirmed to work using the power supply on the 22nd of
August. I also finished the LED panel on the 21st of
August.
Compass
Update:
Last
week I worked with the compass module and the Arduino to provide real
time compass updates through the Arduino IDE over the serial
connection. The objective is to test the compass with the GUI as
soon as possible.
Since
I finished the relay I also submitted a tutorial (my first) to the
Society of Robots. Might be a series of many, who knows?
Society
of Robots Tutorial by Justin S. McFarland
The
objectives of this tutorial are to familiarize members with relays;
produce an example solderless breadboard circuit using a relay and a
DIP switch; and provide an example using a PCB board, DIP switch, and Darlington
array to control the relays semi autonomously.
The
first part of the discussion is a discussion about why use a relay?
An indication that you may need relays in your design are your
applications include the need for voltages/amperages that your
microcontroller organically cannot provide by itself. Examples
include high voltage motors for propulsion, large LED arrays,
solenoids, or objects you want to either fail open or closed such as
heaters or cooling applications.
Relays
provide the option to have devices either connected as normally open or
normally closed. This means that when power is connected to your
circuit by default the gate is either closed or open. Where
the 'normally' indicates whether the relay state is tripped as true.
The device will be in its normally closed state if the power to the
relay still persists if a signal is lost to the relay.
The
example circuit that we'll breadboard includes the following parts:
(1)
3 Pole terminal block
(2)
1500 Ohm resistors 1/4 W, 5%
(2)
LED,RED,635nm,T-1(3mm)
(1)
18 pin IC dual wipe socket
(1)
8 position DIP switch
(1)
RELAY,12VDC@15A,SPDT
(1)
small signal diode switching
(2)
solderless breadboards
(1)
12VDC regulated power supply
(1)
470 micro-Farad capacitor 25V
Various
connection wires
The
circuit works by providing an indicator light for power first, then the
user controls the DIP switch position 1 manually to actuate the relay.
This also turns on the LED indicator light and powers the signal diode
in parallel with the relay. Note the hazards in this design are
the orientation of the IC, switch, capacitor, relay, LEDs, and diode.
The
relay itself in this configuration is not connected to a device or an
external power source. This is due to the very difficult fact
that this type of relay does not fit on a breadboard with the exception
of in the IC slot. This also means that you will have to
customize your protoboard to account for this at the next step in
design. The future design will also integrate the Darlington array
on the IC slot. As a preventative measure it shouldn't be included
on the board in the first go around.
To
be continued...
Tuesday,
August 12th 2008
So
I got the GUI to send commands last night to the relay card to turn it
on and off. I also got the compass working. I hope to get
the compass into the GUI soon and also have a bunch of indicator lights
for the different channels of the microcontroller being active.
The
GUI is a Visual Basic Express 2008 product that takes advantage of the
serial port component class. This made it ridiculously simple to
program the product. I had been using VB.NET 2003 - it was a
vastly inferior product that lacked these types of functions. So
the GUI v001 opens a port defined in the combo box at the baud rate
defined in the next combo box. The grab data works once the
connection has been established and the microcontroller is actually
sending data at that baud rate. The data appears in the text
box. I've been using it to verify the MCU is at the
"Ready" state as well as passing some numbers like the compass
heading. The send data button sends the text string in the text
box beside it. This functions the same as the MCU accepting
character strings via the Arduino IDE shown here.
I
verified that the different relay gates opened and shut as
desired. The close port does the obvious, closes the COM port that
was open and therefore frees it up for another application. To
note: you can have a COM port open for a single application at a
time. I have a new concept design that's similar to the
original. I'm going to just try and build it in VB and then
upload the result. It will also include accommodations for the
Parallax HM55B compass sensor with which I've been fooling.
I
ordered parts for a second LED board and the relay cards last week from
MPJA and Jameco. I also selected a number of fuses for protection
of the bilge pumps during operation from RadioShack. Additionally
I also found a number of new protoboards (MPJA.com) and storage cases
for each as well as some wiring connection options through the
cases. These cases were drawn up in CAD and verified again to fit
inside the structure.
On
the construction side Bob has been continuing work on the water
testing. He hasn't yet had time to lick the problem due to being
overworked at the day job - but he has some faster options now than
fiberglassing: caulking.
On
the logistics side I was reviewing some harness options from
McMaster-Carr:
The
problem is that they are usually man-rated and thus very very expensive
(at least I think they are) at $50 a pop minimum.
Tonight
after sailing Bob also provided me with a lead acid battery recharger
and a depth gauge (transducer) good from 2-200 ft. Looks like we
can integrate the depth gauge without too much of a problem!
Sunday,
August 3rd 2008
Continued
with testing on the LED board which included a solid hour of
output. No problems emerged and the board was not terribly warm,
although it was noticeably warm to the touch. The board quickly
cooled after being turned off. I also started tracing out the
wiring diagram for the operational relay card. The test unit will
continue to do just that, be a test instrument for this and future
projects. However, with the difficulties associated with creating
yet another set of seals for Bob to master, I think that a custom
designed relay card is the best solution and I'm confident I can do it
(puts on Jr. Electrical engineer hat). As this relay card is being
completed the propulsion system and sensors system integration will also
be worked on. A third generation card may include a
microcontroller of its own accepting commands from a different
microcontroller. That would be a pretty significant advancement
indeed.
I
have yet to test the compass or accelerometer units or write code for
their integration into the system. I also still have to get the
instruction sheet from Bob on the voltmeter. The voltmeter is for
monitoring of the batteries while on voyage. I also need to get a
temperature probe worked out. Unfortunately at this point I'm
running out of PINS on my Arduino. Eight are currently being reserved
for the relay card and one for the camera servo. This leaves 4 for
digital and 5 for analog operations. Also (of course) as the
number of connected devices increases, the requirement to go to external
power for the microcontroller becomes more prominent. For
a more robust sensor solution I'll have to go to a more advanced
processing core such as the Propeller or another unit (which will
significantly delay the entire development process). This will be
included in a future generation of the computing system.
Saturday,
August 2nd 2008
Well
we officially missed the project target date (but that's ok we're making
progress). Friday I purchased some fuses, some fuse chassis
mounts, solid wire, and new protoboards from RadioShack. The
primary goal was to get a new fuse for my multimeter and the protoboards
for the LED wiring. The multimeter now works (310 mA fuse /
250VDC). I measured an amperage of a single serial circuit at 28
mA peak while the measurements fluctuated from 24-28mA. A quick
calculation indicates that resistance at 28 mA is 375 W
(Ohms). The
parallel circuits then result in a overall resistance of just 62.5 Ohms
with an overall circuit consumption about 1.8 W.
On
Saturday I measured the circuit again using the multimeter at 10.5V to
confirm my previous day's measurements. Curiously I got only 20 mA
peak and the reading was much more stable with tighter lower limits
around 18mA but as more pressure was applied the measurements steadied
around 20mA. To achieve these measurements I altered my test
configuration to use a header strip and was measuring the amperage to
the contacts on the board. This method instead of measuring off of
two jumper cables appears to be more stable. The estimated
resistance is then 52.5 W (Ohms).
Results in a circuit resistance when parallelized to 8.75 Ohms. Next I
placed jumpers over the headers and In trying to use the multimeter for
resistance, it just gave me the 0L reading. Of course I needed to
actually... turn off the circuit first... and then run the meter from
positive to negative over a continuous component. This doesn't
work for LEDs as I later researched. Instead, I wound up
consulting the spec sheet and found the Vf and If for
the LEDs were 3.5V (known) and 40 mA. So using that information
and the following formula:
R
= (VS - VL) / I = (12 - 3.5 x 3) / 0.040 = 1.5 /
0.040 = 38 W (Ohms).
The
next closest resistor is 39, but the tolerance of 5% doesn't cover the
difference. The next common resistance up is 47. I of course
only had 5 of the necessary 6, so I also make due with combining a 33
with a 15. In each case the extra margin will provide with a bit
longer life of the LED which is fine by me.
The
website (http://www.kpsec.freeuk.com/components/led.htm) also has some helpful indicators:
IF max.
Maximum forward current, forward just
means with the LED connected correctly.
VF typ.
Typical forward voltage, VL
in the LED resistor calculation.
This is about 2V, except for blue and white LEDs for which it is
about 4V.
VF max.
Maximum forward voltage.
VR max.
Maximum reverse voltage
You can ignore this for LEDs connected the correct way
round.
Luminous intensity
Brightness of the LED at the given
current, mcd = millicandela.
Viewing angle
Standard LEDs have a viewing angle of
60°, others emit a narrower beam of about 30°.
Wavelength
The peak wavelength of the light
emitted, this determines the colour of the LED.
nm = nanometre.
I
completed the tasks for building the LED circuit into a protoboard after
testing on the breadboard and also testing with the relay card.
I've definitely been thankful for the power supply. Without it,
none of these shenanigans would be possible - especially testing at
various levels with for the LEDs and other projects. The circuit
board clearly fits inside the opening for the panel as designed.
Pictures of the soldering are low quality from the QuickCam (my actual
camera's battery is apparently dead).
Testing
the protoboard was straightforward but found a problem with the relay
card. The 8th bank doesn't work, this could be due to the fact
that the first four banks were completed with RC circuits and the other
4 banks need something to complete their circuit. The relay does
switch and the LED triggers, but the voltage did not come through the NO
side (though it may have come through the NC side?). This will
have to wait until tomorrow for further investigation. The first
relay back was used for the LED panel test.
I
placed the panel inside the PVC T to demonstrate the fitting.
Noting I still have to work up a mounting system for it. I think
that a 4.5" acrylic circle will work well to screw into and
mount. I used the Arduino and the battery box with the power
supply for the test. The battery box was switched on and then the
power supply set to a constant 12VDC. The Ardunio program was
already uploaded so I switched to serial monitor mode. A manual
test of the relay card switching on DIP 1, revealed success (as was
expected since I had already separately tested the protoboard directly
with the power supply). The Ardunio test was next and the results
recorded in the video.
Construction
Bob
tried a tub test to satisfy the task Seal front end section and test underwater
- " My first bathtub test failed the water-tight criteria.
I’m evaluating quality control in construction procedures: The
insertion was pretty tight in one of the connections, and the glue
hardened before I could push the inny into the outy completely."
Ah well. He'll get it soon enough! After he gets that solved we'd
be able to try out
Test the camera underwater and record video! rapidly. He's also been to RadioShack and the Home Depot
hunting up parts for various things - including a trial at melting the
plastic together (eep). He did mention that the leak was not
coming from the section between the acrylic and the PVC, but the PVC
joints. He's also looking into the screw caps as the cause (this
is a serious failure mode). Hopefully he gets it all sorted out.
Thursday,
July 31th 2008
LED
testing continues! This time I recorded the voltage drop over each
LED (just for reference confirmation). The power supply indicates
10.5VDC while my RadioShack voltmeter indicates 10.39V across the
terminal block. The drop across the first LED is 3.35V, second
6.87V, and third 10.38V. I couldn't get an amperage reading (the
goal). It appears my fuse blew inside the multimeter awhile ago...
and I have yet to have replaced it. Regardless, for fun I removed
the rest of the LEDs from the protoboard that I've been working with
(and Bob too) and put them back on the breadboard.
Tuesday,
July 29th 2008
Lighting
I’m
actually not sure how we should do the LEDs as far as how much voltage
draw. We can switch to using independent voltage for the LEDs that
would be non-rechargable and go to a set of 7, AA or C or D batteries
for 10.5V with 3 LEDs in series with a set in parallel or add another
lower voltage guy in at the end (at the risk of amperage).
We have 22 LEDs left, so no need to order new just yet (I
physically broke two while removing them from the protoboard - 1
hardcore damage and the 2nd I didn't realize I broke it until later).
I
placed the 3 x 4 matrix (series x parallel) on the breadboard setup
tonight and recorded the results. They look promising!
Propulsion
Due
to some new calculations on thrust and drag – we may choose to
reconfigure the sub a bit further. I’m not getting as much speed
as I’d like to fight against the current. I was hoping for at
least 1 knot max speed. But we can waive it and just go out on
very mild days. We also still have to figure out how we can get it
into the water. Bob mentioned that the current is a 1.
Logistics
Bob
and I also discussed for a bit the procedures for getting the sub into
and out of the water. They ranged from placing the sub in the
cabin area. The main sail boom and another rope to heave it into
the air then maneuver it over the side. We also talked about using
the mast some how to get the sub into the air from the bow of the boat.
It fits in either place. About 30 inches are between the deck and
the waterline of the boat so just pushing it overboard is out of the
question.
Alternatively
we have the option of building a second craft and launching the
submarine from it. A second pier at the marina is available
with a wench in which we can trailer the 2nd craft laden with the sub
onto to the dock and lower it into the water via the wench. This
approach of course is the most interesting. The 2nd boat would be
launched from the 2nd marina pier area and then picked up by Blue Boat
(much like when someone drives a motor boat off the pier and then has to
go put away their car... they swim after their boat later). This
could get a little rough. Again alternatively it is possible to
use the main boom to lower the 2nd craft into the water behind the Blue
Boat and then tow the vehicle behind Blue Boat the entire trip.
This would require the submarine to do a rendezvous and dock maneuver
with the 2nd craft (a highly attractive challenge). This of course
increases the challenge to the users because now we have to control 3
vessels simultaneously: A.) blue boat, B.) the sub and C.) the 2nd
craft. The 2nd craft would likely be tethered to one of the
wenches on board blue boat and would not range too far, but as it will
be unpowered it would be at the mercy of the current and could prove to
be challenging to manage the maneuvers of all 3 vehicles. The likely
configuration will be in the strongest of currents that we field the
craft that all vehicles would be lined up with the current motion and
the users would have to deconflict the cables.
Monday,
July 28th 2008
Tested
the volt monitor sensor that Bob constructed. I hooked it up to
the HY3020E via a terminal block (just recently purchased from Jameco)
with a breadboard and the two provided lead wires. The LEDs light
up with respect to the voltage of the batteries. The red LED
toward the negative terminal indicates a high voltage condition of
12.4V. The remaining series of LEDs are triggered in 0.2V
increments. Yellow 12.2, green 12.0, 11.8, green 11.6, green 11.4,
yellow 11.2, red 11.0V.
I
also tested the LEDs Bob put together. The series of six requires
21VDC (3.5VDC a piece). The maximum reverse voltage is 5V - so
there's little room for error. The objective was to power this off
the 12VDC power supply internal to the craft, but it's not entirely
necessary. A block of 8 AAs should suffice to power them
also. Regardless, the LEDs are going to have to be placed in a
series/parallel matrix to stay at 12VDC. So the goal is to put
together 3 LEDs (10.5VDC) in series and then parallelize the next sets.
Friday,
July 25th 2008
Received
the Digikey parts this week and mostly finished the relay card
construction. I moved 3 pol terminal block from the transformer
section (unused) to the 8th relay and also added red LEDs and resistors
to the remaining 4 positions on the card. The transistor array IC
socket and chip were installed after cutting out the jumper wires across
the area. As usual I powered up the card using my 8AA battery box
with switch and tested the outputs using the manual DIP switch.
All relays continued to work and the new resistors all glowed
appropriately (if not strangely due to the fact they are clear LEDs but
emit red light). Next,
I attempted an initial test at having the Arduino MCU provide the signal
to the relay card with a digital output set to HIGH. This was
unfortunately uneventful. It could be that I'm just retarded and
need to put the MCU board ground into the relay card and the circuit
would be completed... [so I'll try that... then I will try the analog
signal next if necessary].
Ok,
so I just tried it... and it works how about that!?! Nothing like
getting your thoughts together and going... hey... shouldn't I have
grounded that... oh sheesh. LOL. Critical milestone passed!
Yeeeeeeeeeeeehaaaaw!
Thereafter
the contingency plans range from trying out the MCU with my RadioShack
Electronics Learning Lab to measure the output signal of the relay
card. If the voltage signal is below the needed 2V (observed
by using the DC power supply) then the plan is to try to build an OP AMP
circuit to increase the voltage output.
In
the news from the construction and devices front, Bob and I drew up some
alternative configurations that would improve the gravity gradient stability
of the vehicle. This is achieved by adding a second level to the
craft now dubbed Squidlian (after my current rank in 'Biggest Brain' on
Facebook 94.6% tile in the world). We placed the batteries (6 in
number) on a new lower level of the craft oriented horizontally.
For nominal drag for a faster moving vehicle the orientation would be
better suited longitudinally and will also be considered as a potential
configuration.
The
hours of work in SolidWorks is really tedious because of the means of
interfacing parts. The mating system employed by the software is
fragile especially for closed systems which the submarine clearly
is. The problem with the mating is that over constraints are
apparently all over the place geometrically and it's difficult to
discern what to remove as far as mating constraints. This results
in some annoying behaviors that just seem to be a waste of time, alas
I'll just have to struggle through. No real drawings to
share. However I did confront the issue of loading the sub into
the car. With the desire to have a lower level, the lights on top
no longer are variable due to the constraint of getting through
doorways... thus the lights are now on the bottom and canted out to the
side to avoid blockage from the battery tube.
Thursday,
July 10th 2008
Surprise
shipment came in today the HY3020E power supply from
PowerSupplyDepot.com! Being over a month early this is a great
development for the project... and potentially gets us back on track for
a potential launch by the end of the month.
The
power supply has the markings from the supplier (not the manufacturer)
using the P/N 15950PS and has 3 modes of operation: constant current,
constant voltage, or restricted current protection mode with a min/max
setting. I set the power supply to constant voltage at
13.6VDC. I connected the positive power supply connection to the
terminal block center pole with the bilge pump connected to NO (normally
open) filtered power. The bilge pump has two positive leads: a
manual brown and white wire and the automatic brown wire. The manual
wire was connected for this test.
The
8 AA power supply (12VDC) is connected to the relay card VB. The grounds
are connected together on the relay card GND and on the power
supply. To test the bilge pump I used the DIP switch to manually
turn on channel 1 and the bilge pump works just fine.
Wednesday,
July 9th 2008
Updated
the communication architecture documentation to reflect the latest
design (this was done earlier - just needed uploading).
Over
the 4th weekend I purchased 12 - 12VDC / 3200 mA-hr lead-acid batteries
from Jameco. Originally this was an accident but I forgot to
factor in the depth of discharge into my calculations. I'd prefer
only to go to 50% DOD instead of 100%. This preserves battery life
and also gives sufficient reserve for emergencies. I also ordered
a number of various parts to complete the bill-of-materials including:
I
also of course before purchasing the batteries completed my power
estimate calculation and sketched out the crtical dimensions of each
potential candiate:
P/N
264057
P/N
318924
In
the end P/N 318924 was selected because well... it fit.
Other
fun things over the weekend:
I
tested the relay card with my new switch able 12VDC (8AA) power supply I
made. The manual DIP switches were all actuated and the relays
opened/shut on command as well as the appropriate lighting of the LEDs
on the card. The next step will be to integrate the MCU into this
loop and get the MCU to send the signals to the relay card. This
is a critical milestone for the project as the entire control scheme
depends on its success.
I
also started work on integrating the tilt servo into the system and
sanded down the current foam forms to 4" OD for a prototype
correction. I fit Bob's sewer style 4.25" OD, 4" ID pipe
into the acrylic and around the foam forms for use as ribs approximately
1" in width. The idea is that the camera foam will rotate
within the ribs and be contained by a soft plate on the one end of the
camera system. The opposite end will be connected to a servo also
within a foam form that will turn the other form. This form will
be rigid while the camera form will be loose and free to turn. The
trick will be to make it all accessible and removable.
The
camera payload needs to be removable through the 4" ID section of
the hull (duh) so the previous use of the 4.25" ID of the acrylic
piece wasn't very intelligent. This is one of those things that I
needed the calipers for so that I could have avoided this issue during
the CAD prototype phase. Now at least I have the calipers and can
update my drawings... I was off a lot.
Tuesday,
July 1st 2008
Purchased
MASTECH HY3020E power supply from PowerSupplyDepot.com for $269 (with
shipping $281). It is about half the cost than from JAMECO but it
will come in mid-August. The sister model the HY3010E also was
out, so I chose to wait to get the cost savings. I'll make due in
component testing with lead-acid batteries instead. I went with
this model because of the wattage of the unit with the control to 20
A. I expect that 4 simultaneous pumps actuating will draw about
this much off the batteries and I wanted to test the relays to this
level. Until that point however, we'll just use one relay at a
time. The higher voltage also will allow me to try out 24VDC motor
applications in the future so I'm pretty excited about it even if it
will be about a month later than I want it to be.
MFG:
MASTECH
Model:
HY3020E
Input:
110 VAC 60Hz Output: 0-30VDC @ 0-20A
In
addition to the power supply, I also purchased numerous parts from RadioShack
including a number of resistors, capacitors, project boxes, 2 switches,
a DIP switch for the relay card, 2 - 8 AA battery holders, 9V battery
hook-ups (for both 9V and these 8 AA holders). From Home Depot I
purchased some additional PVC end-cap fittings 4 each of the screw in
end-caps and 4 of the adapter sections, a 36 pack of AAs, 5 pack of
1/2" colored electrical tape for marking the different comm. lines
(and used as electrical tape), 3 different colors of 16 gauge wire 24'
in length, and 1 - 2 x 2 x 8' section of Styrofoam.
The
new acrylic 12" 4.5" OD / 4.25" ID section arrived Monday
and I cut the Styrofoam from the weekend into a 4.25" approximate
cylinder with a cavity on the inside and some wire paths.
The
first image from the camera can see some of the foam (will be corrected)
as well as a glare off the acryllic due to the LED backlight on the
camera itself. I will likely tape it off with electrical or
masking tape (or a combination) to absorb the light. That's my
wife in the background playing video games.
Relay
card has 4 filtered RC channels with 4 LED indicator lights as an
excursion from the base kit. Additionally I added a 8 rocker DIP
switch to help out with manual testing. I will add an 18 pin
switching transistor array and may just complete the board with the transformer
in the upper left. I don't plan on using it as such, but we shall
see.
Thursday,
June 26th 2008
Lots
of parts have been coming in over the past week:
The
JAMECO order with the relay card, LED's, and voltage monitor are in (also
included in the image are the RadioShack PC boards that are under
consideration for mounting the LED's - but they don't fit quite well...)
Box
from Home Depot score... a collection of parts: 2 - 4" 90 deg
bends, 4 T-s, 2 joints, and 2 caps
Monday,
June 23rd 2008
Received
comm. parts and tested the new comm. architecture over the USB to
Ethernet method works great!
The
control system will also be verified… but I'm still screwing around
with that… as I have to still improve the user interface stuff. I’m
still just working in providing text strings and no fancy GUI.
The
last major parts left to get are the bilges and the batteries. I
ordered the relay card last week with the LEDs. I have also been
trying to figure out a good way to test the bilges off-line. The
nominal solution would be a variable voltage / variable amperage
bench-top power supply that could go up to 20 A and 30 V… but from
what I can gather those are pretty expensive (alas if I get really
serious about this stuff I’ll budget one for next year…or I’ll
just buy one as the spousal unit has approved said purchase).
Meanwhile
to test the bilges we can just use the relay card after it’s built
with the lead acid batteries (or a car battery?) and the bilge pumps and
switch them manually on/off on the card to verify operation at the
amp/volt level. I will also be able to test the relays with the
microcontroller unit independently by having some LEDs on the other side
of the relay instead of the bilge. This way we can test both parts
independently, but not jointly until we have to…
looks like the
west marine rule bilge pumps can be at 12V at 0-10A draw for general
sizes of pumps.
Placed
an order to McMaster Carr for the acrylic cylinder for $15. The
section is 4" OD with 1/8" wall thickness. This will be
a tight fit with the camera, but manageable as the camera is 2" in
diameter. I'm working on fitting it with a rotation servo.
Squared
away with Bob tonight on the parts to date with open authorization for
purchase of $120 more of goods (between the two of us). To date we
have the 2 camera purchase at $60 and $20 ($80 total with rebate) and
the $200 communication architecture order for $280 total sans MCU cost
and other materials on hand such as the servos. After the
sensor/servo architecture setup is completed
Purchased
the LEDs due to their high output power status > 3000 mcd and with
multiple they should be very bright. The goal with multiple colors
is to be able to see which color penetrates the depths best in the
marina / river environment. The relay card is the same one I used
in college for our thruster control project. It will be able to
handle the loads required to control the bilge pumps from signals from
the MCU and powered by lead acid batteries. I also purchased a
voltage monitor kit to help out with monitoring the MCU power levels as
they are absolutely mission critical.
Order
from Amazon.com et al:
Over
the weekend I also ordered the communication architecture parts. I
changed the design to simplify the wiring a bit using active repeater
USB extenders. They're good for 150' without extra power at a cost
of $39.99 each. Overall the cost was the same as the proposed
architecture after shipping ($200). The one Amazon.com retailer
for the RJ45 to USBA converter was charging $5 PER ITEM! so it became
less appealing to go that route.
Remaining
major items are of course the bilge pumps, loose wiring for the wiring
harness, the batteries and superstructure of the sub. The relay
card will enable the testing of the algorithms for the bilge pump firing
at the appropriate voltage levels. I just wish I had a power
supply unit. I suppose I'll get one eventually... and probably
even an oscilloscope. Looks like I'm evolving into a electrical
controls system engineer.
Started
working with the video camera (ended up getting a second one and giving
it to Katherine to play with) and continued working on design concept
for communications (total payload cost $80 sans shipping / tax and
including rebate). This is notably inefficient. If I had
more time I could probably figure out a way to send video over the same
cable as the serial connection to interface with the RJ45.
Communication
Architecture Parts List:
2
x CAT5e 100 ft. waterproof cable ($40 each - $80) - Alternative
cables (not waterproof $20 each)
3
x RJ45 to USB-B adapters ($8 each - $24)
2
x USB A extension cables (9.8 ft.) ($6 each - $12)
2
x Female USB A to Female USB A ($3 each - $6)
1
USB A to USB B cable (6 ft.) ($4)
Total
Communications architecture cost: $126 (sans shipping / tax)
Command
and Control
Worked
with the GUI interface sketch to define some areas of interest for the
video display and the controls. The controls are setup to mimic a
PS2 controller so that it would make a lesser transition to when we
implement joystick control.
The
window will probably be native to Visual C++ Express 2008 and expanded
about OpenCV video analysis tools. The first of which is to just
use the preview image to assess the surrounding environment and capture
to video. A set of Christmas Tree lights will be in the upper left
to indicate health and status. A compass section will be used to
show heading (and it would probably be good to have a relative heading
from the shore/boat (e.g. the user) to help with relative orientation
and motion). The lower left is the control section where nominally
one would be camera control and the other would be vehicle throttle
control. I have control surfaces on the right, but the current
prototypical design will unlikely have any need for control surfaces.
GUI
Control Long-term Vision
Enable
simultaneous use of 3 user defined COM ports
Handle
camera start/stop of video transmission as well as take snapshots or
video
Indicate
sensor readings for internal temperature, compass heading, indicate
speed, external temperature, battery temperature, battery voltage,
'water' sensors, 'humidity' sensors, indicate sensor status as
on-off
Record
motion with an accelerometer, integrate, and map
Control
vehicle thrusters, lighting, and camera with PS2 controller or mouse
GUI
Control Short-term Vision
Enable
simultaneous use of 2 user defined COM ports
COM
1: Handle camera start/stop of video transmission as well as take
snapshots or video
COM
2: MCU control and sensor observation
Battery
bank voltage (1 PINs) [Secondary Goal]
Relay
board gates (~6 PINs) - ON/OFF
LED
lamps and (color? 1-2 PIN) - ON/OFF
Allow
for "emergency" shut-down of GUI to allow for new code
to be transmitted [Tertiary Goal]
Craft
safe-mode where it will default to command: surface
Handle
maneuvers to simultaneously cue multiple relay gates for:
Updated
the design again over the past couple days to include the end caps and
revisions for the rear section to allow for entryways into the
structure. There's still some design change room to occur for the
structure in that the pathways for wiring to the propulsion system
haven't been defined yet (nor the path for the propulsion system
itself). I also ordered a video camera to try out also from
Amazon.com which hopefully arrives by Saturday.
Logitech
QuickCam Communicate Deluxe ($19.99 price after rebate). I hope to
mount the base to a servo for full rotation about the pitch axis of the
camera. Hopefully it fits within the acrylic forward
section. Otherwise a different camera will have to be
selected. Not particularly fun with the way websites give you
dimensions these days. At minimum however, this camera will serve
as a means to post videos about my projects - which is well worth the
$20.
Time
for work... ahhhh!
Saturday,
May 24, 2008
Re-vamped
this whole site... found parts and costed materials at Home Depot.
Added the Subsystems branch from this site.
Looks
like it may be possible to build a 'jet vane' actuator for directing
water flow through a pipe. This would assist in using the two
large bilge pumps for multiple directional control in vectored thrust.
Continued
revising the calculations for thrust and drag throughout the week.
Determined the maximum velocity equation and believe that we'll require
2 x 2000 GPH bilge pumps given a vehicle 120 sq. in cross section,
1/4" exit diameter on each hose (too small?), and a drag
coefficient of 2.0 (no idea).
Began
calculations on the submariner system design using MS Excel focusing
specifically on necessary thrust levels to meet the requirements for
surviving out in the river. Something that allows us to move
faster than 3 knots is probably going to be necessary to overcome the
(hopefully) worst of currents. This would prevent us from losing
the vehicle from tearing off via the tether.
We'll
need to purchase a power system and a pump in fairly short order after I
get the basics coded up. After we get one of these integrated, then we
can expand rapidly.
Task
list -
Primary
Sub-System testing (pun intended):
1.)
Ethernet based telemetry & communications
2.)
Batteries (power)
3.)
Pumps (propulsion)
4.)
Lights (payload)
5.)
Video camera (payload)
Full
Subsystem test! Milestone
....
Hardware
integration
6.)
Wiring harness design
7.)
PVC construction & wiring integration
Water
test! Milestone
8.)
Microcontroller
9.)
Comm system
10)
Batteries
11.)Sensors
monitoring power (voltage, amperage)
12.)
Lights
13.)
Video camera
14.)
Sensors monitoring temperature of batteries, lights, video camera
15.)
Pumps
16.)
Sensors monitoring power to each pump
Water
& subsystem test! (Small scale)
17.)
Improvements...
Pool
test!
18.)
Improvements
Launch!
Launch
system (needs to be discussed):
1.)
'Crane' / slide?
...
Bob's
stuff:
1.)
Lights (LED preferable - low heat, low power)
2.)
Pumps [<200]
3.)
PVC [<100]
4.)
PVC goop
5.)
Paint
6.)
Pump mounting equipment to PVC
7.)
Crane/slide stuff for getting the sub into and out of the water (more
PVC/wood/metal pipe?]
8.)
Gigantor ethernet cable with waterproof shielding [?]
9.)
Ethernet float device [?]
10.)
Ethernet watertight barrier device [?]
~
[200 + 100 + 50 + 50] = 400$?
I'll
get the electronics stuff since it'll be easier for me to play with
those toys, and I'd probably order stuff online to get it anyway.
We'll
probably have to buy 2-3 video cameras. I'm thinking a half descent web
cam will do. I have one already picked out I think. We can just buy one
at a time though. There are some alternatives though that are a bit more
expensive that have a lot more features for robotics that we'll have to
discuss.
Justin's
stuff:
1.)
Batteries [expense] [35-50?]
2.)
Microcontroller(s) [expense - should have sufficient] [15-70/per]
3.)
Software ROV [time]
4.)
Joystick [expense for new one... have one but not well suited] [10-50]
5.)
Laptop/Desktop [expense - have] [1000+]
6.)
Video camera(s) [expense] [70-220]
7.)
Ethernet COM interface [cheap]
8.)
Video capture device [expense] [~70]
9.)
Thermosisters [cheap + time]
10.)
Sensors [cheap + time]
11.)
Wiring harness [cheap + time]
~
1500$ less stuff on-hand = [100+10+220+70] ~ 400$?
Submarine
ROV project got off to a lovely stall with the problems with MSRS v1.5
and the sample Boe-bot problems. I've had COM port issues, issues
with the generic functions, and general frustration with the poorly
documented code. I posted some questions to both the Parallax and
MSRS robotics forums for help today and on Sunday. The objective
was to build an ROV template / process of my own to interact with the
submarine vehicle. It may be easier just to go to a Visual C++ or
Visual Basic solution instead of the C# MSRS. I 'just' need to get
a COM port connection established via Ethernet to the main processor of
the vehicle and have it execute pre-programmed maneuvers.
Nominally I'll try to do this as "spacecrafty" as possible
with control tables that can be changed with a new software release.
This process was to be initially emulated with the progress of playing
with the bluetooth modules with the Boe-bots on my robotics test bed.
That so far has been unsuccessful. But it it was hard... everyone
would be doing it!
This
project involves building a submersible ROV that will be launched from
the Alexandria Marina and also from "Blue Boat". The
design must be able to:
1.)
Survive the harbor environment for a single exposure duration of 2 hrs [TBR]
2.)
Survive repeated exposures to the harbor and surface environment
3.)
Provide ROV guidance through use of video to the surface
4.)
Identify a suspect area on the hull for inspection
5.)
Provide continuous illumination of the target area for scrubbing of a
boat hull for 10 minutes [TBR] within 10 cm [TBR]
6.)
Repeat illuminations every 2 minutes [TBR]
7.)
Allow for replacement of expendable hardware with minimal risk to
surrounding systems (e.g. light bulbs)
I'll
attempt to use the GUI prototype from the Boe-bot project to be the
starting point for this project. I'll also try to
control it with a joystick. Later I'll drop the TTL and go
wirelessly via Bluetooth (this step isn't necessary for the sub - but is
necessary for my other project). I'm choosing this approach to
reduce risk - both by keeping it out of the water and to make sure the
control algorithms work as well as build up a tool-box of capability and
code to be applied in future projects. Then I'll prototype an Ethernet connection on an AVR board probably and
try again with adding the video controls, lighting controls, sensor
monitoring, etc.
If you use prop screws instead of the bilge pumps, you may be able to
test the motor control out of the water depending on the thermal range
of the components.
The tether itself should be also tied off to another location before the
laptop! If something bad happens with your control software and the ROV
takes off and stretches out the cable you could not only lose your ROV
but your laptop too! So I'll also build an anchor post with this
in mind...
Bluetooth under any amount of water is not going to work. It's a
higher frequency RF channel that penetrates poorly through water.
I am considering that anything that I put in that bot is going to be
considered expendable, so the throwaway cost has got to be reasonable
and that board is not that reasonable to me - especially for a prototype
design with moderate risk. A swimming pool isn't as high of a risk
but a river or ocean is a very high risk.
Separately there's all sorts of weird things that can happen underwater
and having a method to ground the sub from a electrostatic discharge is
a good idea, which may be some grounding through the Ethernet cable to
the anchor. I liked Jason Rollette's approach of the tethered Ethernet
cable actually since the data rate can be pretty high for video
transmission. You have to build your own proto board, but that's
not that big of a deal especially since he beautifully provides the
specs on the site.
I honestly intend to try and mimic a lot of his work with a few
exceptions like enlarging the PVC diameter from 2" to 4" over
more of the body to allow for maintenance room and assembly. My
hands are too big to play in those tight areas. I also plan on
jacking up the maximum power on the lights and using LEDs to reduce heat
and power consumption as well as building a custom heat-pipe system for
heat transfer to the water. I do plan on using the bilge pumps for
my initial design. My friend has a sailboat and we can pawn them
off to others if we want to convert propulsion systems. Mainly I
haven't found cheaper alternatives. For increased control
authority, you can add jet vanes to the piping and eliminate the
individualization of 1 pump per exit nozzle. You can also
add some pressure regulator feedback and solenoid gates to pulse the
thrust. And also Rolette mentions the obvious you can reduce the
exit area to increase the exhaust velocity. I also plan to vary
the design by having a specialized payload module that can be 'easily'
changed out. This is for experiments of various types including
new cameras, sensors, etc. to be added on a future revision that I'd
want to test out.
