/public/

Preliminary Detailed Design

Table of Contents 1 Team Vision for Preliminary Detailed Design Phase 2 Prototyping, Engineering Analysis, Simulation 2.1 Purpose 2.2 Tail Mock-Up V2 2.3 New Body and Mock-Up 3 Drawings, Schematics, Flow Charts, Simulations 3.1 Purpose 3.2 Electronics - PCB Development & Design 3.3 Power - Battery Update 3.4 Safety - Water Detection 3.5 Architecture - Battery Packs 3.6 Simulation - Geometry in Actuation 3.7 Robofish Electronic Systems Architecture 3.8 Input and Source 3.9 Output and Destination 4 Bill of Material (BOM) 4.1 Purpose 4.2 Input and Source 4.3 Output and Destination 5 Test Plans 5.1 Purpose 5.2 Muscle Testing 5.3 Tail Testing - Muscles 5.4 Inputs and Source 5.5 Outputs and Destination 6 Design and Flowcharts 7 Risk Assessment 8 Design Review Materials 9 Plans for next phase

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

Purpose

In 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

Purpose

For 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 & Design

The 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 between.

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 later.

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 battery.

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 battery.

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 procedure).

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 two.

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 microcontrollers.

Input and Source

1. Selected Concepts
2. Feasibility Models
3. System design and interface definitions
4. Test plans

Output and Destination

1. Complete hierarchy of design files from system level down to components
2. Parts list
3. Software design that specifies coding requirements
4. Test plans, including expected performance vs. requirement

Bill of Material (BOM)

Purpose

In 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

1. PRP.
2. Design Files.

Output and Destination

Completed BoM and Budget

Test Plans

Purpose

Demonstrate 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.

Muscle Testing

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.

Pros:

• 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.

Cons:

• 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.

Pros:

• Least complex solution, requires minimal adjustment of current proposed design state.

Cons:

• 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.

Pros:

• Consistent muscle design.

Cons:

• 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.

Parameters:

• Force vs. Pressure F(P)
• L_rest
• L_min
• L_max

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

1. Engineering Requirements.
2. Feasibility Models.

Outputs and Destination

1. Report that summarized the degree to which Eng Reqs are satisfied.
2. Assessment of accuracy of feasibility models.

Design and Flowcharts

This section should continue to be updated from your systems level design documentation.

Risk Assessment

Additional 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..

Design Review Materials

Plans for next phase

---

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Subsystem Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Customer Handoff & Final Project Documentation