Preliminary Detailed Design
Team Vision for Preliminary Detailed Design Phase
- Plans for this phase.
During the Preliminary Detailed Design Phase our team hoped to solidify, by working more closely with P16029, design decisions which are critical to the initiation of prototyping and building in the second half of MSD. Having established critical parameters and systems which were investigated further in the subsystem level phase, we must know make decisions regarding key systems and components which will directly impact the success of our design.
- Accomplishments during this phase.
Over the first half of the detailed design phase our team and P16029 were able to make decisions regarding key systems and components including but not limited to: power, battery housing, battery placement, tail design, body size, body configuration, and object detection. Advancements in CAD models and physical testing has led to realizations regarding previous assumptions and concepts that has directly impacted old designs.
Prototyping, Engineering Analysis, Simulation
PurposeIn order to advance our understanding of the physical manifestation of our proposed systems additional physical testing was performed. In addition to this physical testing some additional mathematical modeling was performed to assess certain established concerns regarding the tail and the body.
Tail Mock-Up V2
Built upon the previous version of the tail mock-up presented in the subsystem level design phase the new tail mock-up was constructed using a more rigid material in such a way that McKibben muscles can be tested on the apparatus. Holes were drilled through the tail pieces to allow for the crossbars of the T-configuration to be placed at any of several locations along the tail section. In addition to this holes were spaced along the backboard to allow for the muscles to be placed at different angles. Overall this system will allow us to study many different muscle configurations including lengths, angles of attachment, and systems.
New Body and Mock-Up
Modifications needed to be made to the previous body concept particularly because of size constraints. A new version of the body was drawn that is sized more appropriately. In addition to simply creating the body, parts were imported and placed on the body to assess sizing. In the image below from SolidWorks is the fish body with several parts including valves, the waterproof box, the pump, and the ballast tank.
Additional sizing considerations were identified with this sketch including the placement of the ballast tank and the box in relation to each other as well as the battery packs.
In order to visualize the sizing of the new design a new body mock-up was created. With the exception of the thickness of the material this mock-up based directly on the sketch presented above. For comparison with the previous iteration of the Robotic Fish this mock up was placed beside the skeleton of the old fish. Images of this side-by-side comparison can be seen below.
The new version was also place side-by-side with the old version of the body for comparison as well.
Drawings, Schematics, Flow Charts, Simulations
PurposeFor the preliminary design, the team focused on tackling aspects that may cause the most issues or might be difficult to constrain as per Robofish's total and complete design.
Electronics - PCB Development & DesignThe entire electronic system was considered and a preliminary design was created. This included gate drive circuitry for the valves, various interface circuits for different sensors and battery systems.
The preliminary design concept was to utilize three separate printed circuit boards. Two boards would include 6 gate drive circuits each and the third board would include the various interface circuits.
The gate drive schematic is pictured. The system will
include 12 drives total. The system should only use
around 9 drives but extra circuits were created in the
event more valves or pumps were needed. The circuit takes
in a digital I/O command from the Arduino and uses it to
apply 24V to the valve or pump associated with it. Note
that due to the inverting nature of the optocoupler, an
active-low signal is necessary from the micro-controller
to activate the power MOSFET and subsequently the device.
VBST is taken as 24V as from the boost converter and VDD
is taken as 5V from a regulator. The optocoupler was
implemented as a precaution to ensure that the
low-voltage micro-controller is separate from the
high-voltage gate drive circuitry. The 22k resistor acts
as a pull for the optocoupler output. The optocoupler
controls a set of npn and pnp BJTs which are powered with
5V and ground. Sending a high or low signal to the bases
of the BJTs brings either 0V or 5V, respectively, through
to the gate of the MOSFET. A status LED was implemented
for visual assistance. The bypass diode is in parallel
with the valve or pump and ensures that the voltage over
the device does not exceed a diode-drop above the supply
voltage of 24V. Closing the MOSFET brings ground to the
valve which is already connected to 24V and allows
current flow. The 12 inputs and outputs are also
displayed in blocks.
After initial design, this gate drive circuit was simulated in PSPICE simulation software. A pulsing waveform generator was used to simulate the Arduino and a series resistor and inductor were used to simulated the solenoid within the valve. The inductor and resistor values were derived from the Parker datasheet. Note that the power MOSFET set to be purchased is rated for around 50A and therefore should also be compatible with sinking current through the 2A pump purchased. The PSPICE diagram is shown.
The results of this simulation are shown in the next figure. The lower waveforms represent the Arduino command to the optocoupler (green) and the subsequent solenoid voltage (red). The upper waveform represents the current through the solenoid which will enable the transition of the solenoid. Please note that this simulator does differ from the actual circuit in that the Arduino command is taken as active-high. In actuality, due to the nature of the optocoupler, the Arduino command is active-low in reference to activating the solenoid.
Once the circuit was verified to work in simulation, we then went ahead and constructed the circuit on a prototype board using the necessary components and configuration as per the schematic. We simply used one of the Arduino waveforms generated earlier for the swimming algorithm as our input for the gate drive (represented by the pointed-out LED). Remember that the signal is active-low. The clicking of the solenoid can be heard. The video can be viewed here.
With the hardware test being successful, we then went on
to design a PCB that would contain 6 gate drives. Eagle
PCB design software was used to input the verified
schematic and create a PCB layout. The Eagle schematic is
shown, which features 6 gate drive circuits.
The resulting PCB layout is shown. The board was ordered from PCB house OSH Park. The inputs, outputs, and power connections of the board will be access through screw terminals which are located on the edges of the board. Once the boards arrive, the necessary components will be purchases and the PCBs will be populated. The plan is to use four circuit board standoffs to stack two of these boards on top of one another.
The second board which is yet to be designed for the Robofish electronics system, will include the remaining interface circuitry for the various devices and systems. The first element of this board is the 5V regulation. The battery voltage comes into the board and is used to create 5V using a linear regulator. The total battery system voltage will be around 14.8V. The linear regulator was deemed acceptable since the 5V power is only used for low power application and digital circuitry. Otherwise, a switching regulator would have been considered. Also on the board will be some hold-up capacitance on either side of the regulator to ensure that transient current spikes do not deplete the 5V or battery voltage by much. Hold-up capacitance is also established for the 24V power from the boost converter. Finally, a status LED is included to provide a visual indication of active 5V power.
A Hall sensor will be incorporated onto the jaw of the fish to notify the system if an object is caught. In order for the Hall sensor output to be sent to the Arduino for processing, the signal must be sent through a single resistor.
Another device involved in the Robfish operation is a pressure sensor. This will be either used to measure the pressure of the water on the outside of the fish, or inside the ballast tank. The outside water pressure could tell the system an approximate depth in which it is at. This may not be used as the actual depth of the fish is not too much of a help if the fish uses object tracking to catch an object. A pressure sensor inside the water tank could enable for pressure reading about how full the tank is and pump performance. The interface is a simple non-inverting amplifier which takes the sensor output (0V to 40mV) and scales it by 124X to reach a Arduino-readable scale of 0V to 5V.
A proportional valve was also considered to allow for
more precise control of the water flow into and out of
the ballast tank. The proportional valve would be
directly in series with the ballast tank water line. The
proportional valve chosen, as well as many other valves,
operates on 3V to 10V. In order to provide active control
for such a valve, the Arduino was to be used. The Arduino
has the capabilities to output analog signals in the form
of pulse width modulation (PWM). A circuit schematic was
created which translated the PWM signal to an analog
voltage compatible with such a proportional valve. The
PWM signal consists of a constant frequency 400Hz signal
between 0V and 5V. The Arduino changes the pulse width of
this signal to represent different outputs. The goal of
the circuit was to map 0% duty cycle to 2VDC and 100%
duty cycle to 10VDC as well as the linear relations in
The first stage of the circuit is an 8Hz filter. 8Hz was
chosen as the cutoff frequency for the filter due to its
proper balance of low rise time and low voltage ripple. A
larger filter resulted in a faster response time but with
subsequently more voltage ripple. This extrapolated DC
voltage from the filter output is buffered so that the
remainder of the circuit does not change the
characteristics of the filter. The buffered DC voltage
value between 0V and 5V is sent to an amplifier which
scales the signal to an 8V magnitude and concurrently
offsets the range by +2V. Note that for the offset, the
readily-available 5V was utilized with a voltage divider
to create a 2V offset, instead of creating separate 2V
reference for this purpose. The functionality of the
interface circuit was verified using PSPICE software.
The green trace represents the filter output voltage
while the red trace represents the amplifier output. Note
that 2.5V on the filter output leads to approximately 6V
on the output (halfway between 2V and 10V). The rise time
of the system is approximately 10ms. This means that when
the Arduino changes pulse widths, the proportional value
will see the appropriate analog voltage about 10ms
Power - Battery Update
After the poor result obtained from the UltraFire
batteries, Sanyo batteries of the same type (18650) were
purchased for testing. A battery was put under a
controlled discharge under a 2-ohm load while the voltage
was monitored. Approximately 3 voltage readings were
taken per hour. Squaring these voltages and dividing by
the load resistance gave the power profile of the
An equation was mapped to the power profile and the
integral of which was found over the test duration to
extrapolate the total energy contained in the
Safety - Water Detection
The need for a water detection system arose when critical
water-free area concepts were introduced. Areas of
concern include the battery compartments, pump area, and
electronics bay. If any trace of water is detected in any
of these areas, the fish should undergo an emergency
surfacing for direct retrieval. The water detection
system simply uses the fact that water is conductive. If
water completes the circuit between two nodes, the
following interface circuit will bring 5V power to on of
the digital I/O on the Arduino to be detected. A
pull-down resistor in the circuit ensures that the
Arduino will not falsely detect water by keeping the
signal low until water completes the circuit. Within the
resistor bank, a potentiometer will be included to adjust
the sensitivity of the detection system (how much
moisture is necessary to activate the emergency
The two nodes between which water would be detected, would be implemented as long copper foil strips taped to the bottom of the container. This would enable for complete coverage of the container. The copper foil strips would be tied in parallel for each necessary water detection segment of the system.
Architecture - Battery Packs
In order to power the fish for an estimated 5 hours it
was determined that 36 of the selected 18650 batteries
would be needed. These batteries would be equally
distributed into two tubes which are to be placed on
either side of the underside of the fish body. Batteries
would be housed in plastic battery holders in sets of
Each holder containing two batteries would be attached to another back-to-back to create a four battery cell. To achieve the 16 batteries in the tube four of these cells would be placed end to end. The tube would need to be at least a diameter of 2.5 inches and a length of nearly 11.5 inches.
It may be necessary to fill the dead space in the tube to minimize the buoyancy of these tubes. A direct result of their weight, these battery packs were viewed early in MSD1 as a way to reducing the potential for tipping by acting as a keel. The air trapped in these tubes could offset the weight contribution of the batteries by an undesired amount. Two solutions have been proposed to deal with this issue:
1. Sheath - The final section of the
tail has been proposed to be casted out of molding rubber
some of which will be used to fill this dead space and
create a sheath for the batteries.
2. Filler - The space will be filled with scrap material machined to fill the gaps.
Note: These testing plans for these solutions will be discussed in the testing section
For the aforementioned battery sheath seen in the figure below it will designed in such a way that it will not interfere with the proposed method of detecting water in the previous section. The rubber sheath would be cut in such a way that the battery cells could be removed from the sheath easily.
The overall vision of this subsystem is battery packs that each contain 16 batteries. Duplicates of the packs will be constructed so as to always have batteries charging that can be cycled onto the fish. The even number of batteries is intended being that the batteries need to be charged in smart chargers in even numbers.
Simulation - Geometry in Actuation
Robofish Electronic Systems Architecture
The following figure shows a preliminary design of the
entire robofish system electronics, specifically
connection between devices and PCBs. Minor changes are
expected to be made to this architecture as the design
takes form. A example of which is the I2C notation
between the Arduino and Raspberry PI. Upon talking to our
subject matter expert, we decided to go with a simple,
custom serial-style communication between our
Input and Source
- Selected Concepts
- Feasibility Models
- System design and interface definitions
- Test plans
Output and Destination
- Complete hierarchy of design files from system level down to components
- Parts list
- Software design that specifies coding requirements
- Test plans, including expected performance vs. requirement
Bill of Material (BOM)
PurposeIn order to track all of the expenses over the course of this project a running bill of materials is kept. This is used so that the team is aware of the materials we have purchased as well as the remaining budget as we progress into the build phase.
Seen below is a snapshot of the current expenses so far. This does not include the resources that were made available to the teams from from the previous Robofish teams by way of what was left in the lab. These resources appear on the Full BOM.
A link to the live BOM can be found here.
Input and Source
- Design Files.
Output and DestinationCompleted BoM and Budget
PurposeDemonstrate objectively the degree to which the Engineering Requirements are satisfied as well as characterize the designed systems and assess whether or not changes need to be made to the designs.
Testing Plan Summary
In order to characterize the muscle which will be used in the final design several muscles will be constructed for testing purposes. It was determined that the muscles must be able to elongate in order to account for the antagonistic muscle contraction. The ME team has identified four possible solutions to this problem given that direct attachment of the muscles into the tail is desired. The team will test these solutions and characterize the muscles in order to identify the best solution defined as maintaining as much of the force generating capabilities of the muscles as possible while allowing for the strain.
1. Initial Strain This method accounts for the necessary length change required by increasing the mesh length to tubing length ratio while maintaining end-end attachment such that the mesh’s diameter at rest is above is free resting diameter. What is does, being that the tube is elastic, is it allows for the muscle on the antagonistic side to extend past its resting length as the mesh now has the ability to elongate being that it has a fixed maximum and minimum diameter.
- Adding initial strain to allow for extension of the muscles without having to add additional parts which complicate the system and introduce additional failure points.
- Inconsistencies between individual muscles would be far more drastic and frequent if complicated tweaks are made to the production process. Furthermore, without further testing, the effect that this method will have on the contractile potential of the muscles is poorly understood.
- Of concern with this solution is that the initial strain on the muscles would severely hinder the ability of the fish to start moving. It is anticipated that the force production would be much lower during some start up time. Once a muscle is contracting after the antagonistic muscle has contracted and all transient inefficiencies have decayed away the muscles are expected to generate the full force once more.
2. Built-In Slack Another solution that was considered was to simply make the muscles as long as they need to be to account for antagonistic actuation. Considering that the required elongation only seems to be 12% of the total length, according to the first generation mock up, the slack present in the system would most likely not lead to kinking or twisting of the muscles’ inner tubes. Furthermore, as with the other systems, the dampening effect of the slack will theoretically decay out.
- Least complex solution, requires minimal adjustment of current proposed design state.
- The slack built into the design may even further reduce an already smaller angular deflection that results from the direct attachment method.
3. Spring in Series This method places a spring in series with the muscle. The spring would allow for the extension of the antagonistic side. McKibben muscles made with the nylon mesh cannot extend like physiological muscles but the spring would allow for this extension without having to change the muscles.
- Consistent muscle design.
- More complicated in terms of the number of parts.
- As the muscle contracts the spring would extend. As the spring attempts to return to its resting position this would move the tail. This whole series of events would introduce a fairly consistent lag in the response of the tail to the actions of the muscles, which may complicate the swimming algorithm.
- The spring constant of the springs must be high enough to resist extension when the muscle is attempting to contract, but low enough to allow for the extension required when the antagonistic side contracts. This presents a significant conflict in design qualities that may not be able to be resolved.
4. Tension lines If the solutions to attach the muscles do not fix the problem we may have to fall back of the previously used method to couple the muscles to the tail pieces. The old system of using “tension lines” will be improved upon so as to strengthen the system with a better system to tension and stronger lines.
Pros: Reference to go on by using last teams system
Cons: Proved to be a tough method to get to work correctly
Who Will Be Testing This...
The ME team will be conducting these tests as a collaborative effort.
What Will be Tested For and How...
The muscles characteristics will be assessed in order to determine which solution will work best regarding the muscle parameters. We will generate a force pressure curve for the muscles and measure length change of the muscle to assess strain. For strain we will capture of the following: length at rest, length when fully contracted, maximum length when stretched. We would also like to test the responsiveness of the system especially in the case of the spring in series wherein we expect some lag between muscle contraction and actuation. These tests will be performed on the muscle test rig in the lab and with the new tail mock-up.
- Force vs. Pressure F(P)
Tail Testing - Muscles
Testing Plan Summary In conjunction with testing the muscles on their own we will use the new tail mock-up to test the application of the muscle solutions to the tail system. Muscles will be attached/used with the tail mock up in order to determine the feasibility of the strain solutions.
Who Will Be Testing This...
The ME team will be conducting these tests as a collaborative effort.
What Will be Tested For and How...
The tail mock up was constructed in such a way that it can used to test many different configurations. We will use this rig to test the solutions. This is more of a binary testing situation being that any given configuration of any given solution will either work or not. It may be possible to compare the working configurations but this has not been decided upon at this time.
Inputs and Source
- Engineering Requirements.
- Feasibility Models.
Outputs and Destination
- Report that summarized the degree to which Eng Reqs are satisfied.
- Assessment of accuracy of feasibility models.
Design and FlowchartsThis section should continue to be updated from your systems level design documentation.
Risk AssessmentAdditional risks have been introduced as the design has changed. We have continued to consider the risks that persist as well as the newly introduced risks.
A link to the live document can be found here..