Written by: Fabian Suske

Approved by: Carolina Barrera

Intro:

In order to fulfill mission success, the selected components need to brought to live. Therefore the MCU Teensy needed to be programmed.

Objective:

The objective of the Code is to read the EMG sensor, the temperature sensor, the kill switch as well as moving the motor. Due the components chosen a variety of challenges needed to be addressed. The main challenge arises due to using a stepper motor in combination with the Allegro A4988 stepper motor driver. This combination needs constant signals from the MCU to the driver while moving. Therefore pulling of items like the kill switch or the temperature sensor are not possible. As a result Interrupt Service Routines (ISR) were used for almost everything.

Main components:

EMG

The first ISR was used to read the EMG signals. Prototyping has shown that pulling this value, the way it is required, is not sufficient enough. The arm then reacts funny and junky. It also has a poor response time. Most of this results in the fact, that the user starts using the arm in the middle of the pulling process. As a result the long burst might be interpreted as short ones. Or short ones not at all.

This problems were solved once the ISR was implemented. If the user starts using the arm, the Teensy registers an interrupt at the assorted pin. Then the burst duration algorithm “kicks” in and delivers an accurate result.

The code to detect if the user operates the arm or if noise triggered the interrupt is as short as possible in order to not interrupt the movement of the arm.

Temperature Sensor

The temperature sensor was another challenge. The way the sensor is designed to work as followed: After a few byte were written into registers on the sensor the sensors starts the temperature reading. Then the user has to wait at least 750ms (a little more is better) before the measurement can be read. If the user tries to read the measurement faster the senor either return one of his “default” values 0 or 85 or it simply returns the last measured value. If the value continuously is read to fast, the value displayed might be obsolete and wrong.

Waiting for 750ms on the other hand is not acceptable while the motor is running. An ISR that performs the reading in a smart way has been implemented:

The ISR will be handled by a timer object. Every time the timer has an overflow the ISR is triggered. Once the ISR is called it checks a flag to see if the sensor is currently reading a measurement or not. If the measurement is not in progress a measurement is started. Once the ISR is triggered the second time 800ms later the values are ready to be read.

In this way no time is wasted with a delay function.

Kill switch

The kill switch is handled in a similar fashion as the EMG sensor. In case the kill switch is triggered due to an external interrupt, the ISR then sends a low signal to the enable pin of the LDO which then shuts down the entire system.

Motor control

The last part that’s needs to be coded is the motor control. The previously mentioned EMG-ISR has provided us with the direction of movement (Up, Down or Stop). The constantly called motor routine then moves the arm in the desired way.

In order to not violate our range of motion a few functions needed to be implemented additionally. The 150 degrees of freedom needed to be translated into degrees the motor actually travels. Once the position of the motor was found a routine checked if the desired motion is valid. If the motion is not valid, the arm travels the maximum possible distance.

Temperature Protection

In order to shut down the system once an unsafe operating temperature of 55°C is reached yet another ISR has been implemented. This ISR is also based on a timer. Once this ISR detects that the temperature is unsafe, the system is shut down in the same fashion as with the kill switch

Written by: Fabian Suske

Approved and edited by: Carolina Barrera

Intro:

In order to fulfill the L2-13 subsystem requirement “Safety/Temperature sensor” a test has been carried out. This test followed the Verification and Validation Test Plan. The temperature sensor was implemented as a safety switch in the device. The feature is to prevent incidents when the components overheat, and the device could potentially become a hazard for the user’s safety.

Test Objective:

The test criteria that needs to be tested in this inspection is the following:

“Test Objective:  To successfully verify the L2-13 (Safety) requirement, the Prosthetic Arm shall implement a temperature sensor such that upon reaching unsafe operating temperature (above 55°C), the system will shut-off “[1]

Test Method

The test was set up in the following way:

• Temperature sensor
• Maker1000
• C Algorithm to control the shutdown

Because of the incident while testing the kill switch, the Teensy MCU was not available for testing anymore. So, the temperature sensor was tested with the Arduino Maker1000 on a breadboard.

The breadboard was placed in a “temperature isolated” environment which was then heated up until the unsafe operating temperature of 55°C was reached. An indicator LED in the breadboard notified the system’s shutdown.

Test Conclusion:

Figure 1 shows that after the temperature reached the 55°C the Serial plotter stopped, and so we knew the shutdown had been initialized.

At the same time the LED indicating the shutdown went on in Figure 2.

The Serial Monitor also logged the temps and the shutdown. Figure 3 shows the analog serial values the temperature sensor was outputting.

Resources

[1] https://drive.google.com/drive/folders/0B3qlnfB-grPcVzJOTTZyemZ2R3c

written by: Fabian Suske

Approved and edited by: Carolina Barrera

Intro:

In order to fulfill the L2-8 subsystem requirement “Portability” an inspection has been carried out. This test followed the Verification and Validation Test Plan. This requirement is basically to ensure the arm can be operation for 20 minutes – as agreed, and justified in previous stated requirements.

Test Objective:

The test criteria that needs to be tested in this inspection is the following:

“Test Objective:  To successfully verify the L2-8 (Portability) requirement, the Prosthetic Arm battery system shall allow the user mobility, as to permit a 20 minute operation without constraining the user to a wired connection to the mains grid, or generation source.“[1]

This requirement goes along with duration, and both entail the success in the battery selection. If the team chose the right battery, then the arm will be able to operate for 20 minutes continuously, and ideally, it would not need to be recharged until the meal is finished. Therefore, the battery has been hooked up to the PCB and the both critical Voltages read.

Test Method

The test was set up in the following way:

• Battery
• PCB
• DMM

After the battery was hooked up, the DMM was used to measure the Voltage for 12V and 5V at the respective points. These readings are the power to the MCU and the motor. From the arm MCU there are wires that power the Hand’s MCU, and the motors in the wrist and fingers. This is the reason for having these two requirements for battery selection.

Figure 1 shows the mount of the battery inside the bicep, and Figure 2 and Figure 3 show the reading of the output voltages from the PCB.

Test Conclusion:

The first positive indication was that all status/power LED’s light up. This means the battery is able to provide at least 6 V to the Buck Converter. The following measurement ensured that the Voltage levels outputting the right values.

[1] https://drive.google.com/drive/folders/0B3qlnfB-grPcVzJOTTZyemZ2R3c

Written by: Forrest Pino

Edited and Approved by: Carolina Barrera

Intro:

In order to fulfill the L1-11 system requirement “Custom PCB” an analysis has been carried out. This test followed the Verification and Validation Test Plan. This requirement was one that applied to all the groups in EE 400D. It requires that groups develop a custom PCB that help the network and controller communication in the electronic system of the project.

Test Objective:

The test criteria that needs to be tested are provided by Prof. Hill in this class document[1]:

Prof. Hill provided multiple criteria which the Custom PCB should follow, and set a grade scale accordingly. For this project an “A”-Grade was desired.

Therefore this criteria apply:

“All components (resistors, capacitors, LEDs, IC chips) are surface mount. Some exceptions are header pins and large electrolytic capacitors, and components not available in surface mount. All PCB traces were manually routed. Used only one surface mount IC component for the PCB design. All other non-IC components were surface mount (resistors, capacitors. LEDs, IC chips). All PCB traces were manually routed.”[2]

Equipment

• Eagle Schematic and Layout
• Soldered Custom PCB

The PCB schematic and layout were designed using Eagle. Most of the ICs were ordered through Digi-Key. They are all surface mount components. Upon arrival of the PCB and the ICs, the components were tested to make sure there were no shorts or burnt components. Manufacturing solder the board by hand the first version of our PCB, but voltage outputs from the buck converter were not right. Chances are the board got burnt or one of the pins of the IC3 was not solder properly.

As a solution, Electronics and Control purchased a stencil, and the second version of the PCB worked perfectly. However, there was one feature that could not be implemented; the kill-switch. The incident is explained fully in the corresponding blog post, but the safety feature was removed from the system.

Conclusion:

(Custom PCB) Showing all SMD components

On the Custom PCB are 2 Surface mount IC’s the Linear Technelogie LT3971-5 Buck Converter

(Showing the package of the Buck Converter)

as well as the Allegro A4988 stepper motor driver. The Buck is a DFN-10 Package. The motor driver is a QFN-28 package.

Both packages are a challenge to solder due to their small size.

The resistors and capacitors are all 0603. The Diode (DO-214AC) and the Inductor (1812) are bigger due to their availability.

Even the LDO is a Surface Mount Device. But this component is no challenge due to it’s big size (TO-263).

The connectors were implemented as PTH (Through hole) components.

The traces were all manually routed following this instructions[3]

Afterwards the PCB was checked using a whole suit of DRC including OSH, Sparkfun and LeanPCB. The PCB passes every single one. Therefore the PCB passes this Analysis.

References

[1]http://web.csulb.edu/~hill/ee400d/Lectures/Week%2009%20Design%20Verification%20and%20Validation/a_Meeting%209%20Agenda%20F’16.pdf

[2]http://web.csulb.edu/~hill/ee400d/Lectures/Week%2009%20Design%20Verification%20and%20Validation/a_Meeting%209%20Agenda%20F’16.pdf

[3] http://arxterra.com/printed-circuit-board-pcb-how-to-layout/

Blog Post – Integration Interface

Written by: Carolina Barrera

As mentioned multiple times in our documents, we scheduled integration for the arm for November 19^th. No physical integration happened on this day. We didn’t assemble the two systems together, however we made some advancements in the process of integrating the components together.

An idea the two groups wanted to achieved initially, in which our system has a uniform forearm connected the bicep to the hand, and helps harmonize the appearance of the overall system was very desired. It seemed more promising for obtaining a better result in the validation for both teams, and it could lessen the weight that extra pieces (in the integration) add to the system.

Based on this approach, there were a couple of ideas that were considered before bringing up this idea:

1. The dimensions for the wrist height and width are 3 in. by 3 in, respectively. Adding a cover would mean that our wrist would have a dimension of 3.5 inches at least.
2. The weight of connector parts, and big screws in-between subsystems would be minimized if we tried.
3. A harmonized structure would give more opportunities to both groups to increase points in their validation grade.

In November 19^th, the idea of a one-solid piece helping as a shell mechanism, and unedifying both the forearm and the arm was brought up to consideration. The ideas described above served as reasons for implementing this instead of having the two independent components, as agreed originally. We measured the parts that we have at the moment, and figure the rough length of this new piece. Figure 1 is a picture we took on that day that could help as reference of the dimensions of this new part, and the functionality it would have.

Figure 1 – Agreement Guideline Created on Nov. 19

To achieve this, the department of design offered their help, and the Junior TA, Van Lieu shepherd both Manufacturing Engineers in finding an aesthetic way to integrate their pieces. The resulting design is shown in figure 2.

In regards to the agreement, there are items that were communicated as clarifications:

1. The hand and the arm agreed in the idea of implementing a solid interface for integration. This “integration part” that serves as a shell is result of the design and manufacturing efforts of both Manufacturing Engineers, Forrest Pino and Wilson Mach under guidance of Van Lieu, Industrial Design student from CSULB.
2. This part will house the motor for the hand that allows the wrist rotation on the hand side. Additionally, it will house the wires going to the PCB of the hand -located near to the “elbow”, and a slipring -that will prevent over-twisting and ripping of the wires when the wrist rotates.

We moved forward in the process of integration -even though we were not physically putting together the components. This meeting could be considered the initial phase of the integration, in which the baseline is set, and both groups agreed in dimensions, and restrictions that will direct our project into mission success. More updates will be posted if relevant changes come up in the project. However, with the time left, and the advance stage of both projects don’t give space to last-minute changes.