Customer Handoff & Final Project Documentation
Table of Contents
Team Vision for Final Demo and HandoffDuring this Phase, our team planned to:
- Complete the Technical Paper
- Complete the ImagineRIT Poster
- Complete the rest of the test plans
- Prepare and present our Lightning Talk
- Troubleshoot our electrical system
What Our Team Accomplished:
- Completed the Technical Paper
- Completed the ImagineRIT Poster
- Prepared and presented our Lightning Talk
- Completed mechanical test plans
- Troubleshooted possible malfunctioning electronic components
Electrical Subsystem Updates
Plastic covers were 3D printed to conceal and protect loose wiring. The CAD of these pieces can be seen below:
What Happened ElectricallySo, our electrical subsystem was unable to support the existing mechanical subsystem. Due to two blown out motor modules. The failure mode is still a mystery, but an educated guess could be made that a wrongly soldered wire allowed extra power into Brake and Direction terminal points.
The use of MOSFETs was unnecessary since the Anaheim Automation MDC100-050101 Motor Controller has built in Transistor–Transistor Logic (TTL), meaning that the Arduino can directly control the Brake and Direction pins with an analog output without the use of MOSFETs. However the MOSFETs were actually used to invert the logic required to drive the motors. For example since when grounding the Brake to the Ground pin would have switched on the device with a logic 0 input this can be undesirable since it would make more sense for the motors to turn on during a logic high event. The MOSFETs were used to correct this and allow the allow the Arduino to directly control when the motor drivers turned on, instead of assuming that from when the power supply is plugged in the pin wouldn’t automatically be grounded switching on the motors on undesirably. Just something to consider going forward. Electro-mechanically the system should work as expected, but with putting two systems there will always be problem solving efforts. Therefore, it can only be speculated from the limited testing using the sample Arduino code (actuating the motor back and forth), after a few minutes the motors were hot to the touch. Heat should be a major concern if the motor incorporates a back and forth motion.
Arduino TroubleshootingAfter the motor controllers broke, we wanted to make sure that the Arduino was still in good shape. We tested this using an oscilloscope to make sure that the Arduino was still outputting 5 V for all pins. The results can be seen below.
Test Results SummaryUnfortunately after the motor controllers stopped working, we were unable to complete any electrically involved tests. However, we were able to complete all mechanical tests.
Test Results Completed:
- S3 - Hand/Wrist Range of Motion
- S15 - Anatomical Accuracy of Forearm
- S16 - Test Rig Size
- S17 - Mitigation Device Fit
Test Plans/Results document can be found here.
Risk and Problem Tracking
- Updated Risk Management documentation can be found here.
- Updated Problem Tracking documentation can be found here.
Final Project Documentation
|Project Management||Design Tools||Design Documentation||Validation & Presentation|
Using a one directional driving motor would be a better design, there would be less heat and less vibratory motion to deal with. This would extend the longevity of both the motor drivers and the motors. But due to time and size restraints the more simplified, less thought out design decision was made. A word of warning Anaheim Automation technical support has been unhelpful in providing data and overall troubleshooting. Using the single direction drive approach, the controls would be based upon changing the speed of the motor via the motor driver’s external potentiometer output. I have provided sample code on edge for connecting the Arduino to MATLAB if you decide to take that approach. Which from a controls standpoint using Simulink in conjunction with Arduino, MATLAB, and Simulink should provide a cost-effective solution for controlling the test arm. A sample controls Simulink file will also be added to EDGE for reference. But at this point it is our understanding that a closed loop feedback using the nine degree-of-freedom (DOF) sensor will be the best way to control the test arm.
The use of capstans is a good idea for connecting the pulleys rather than a single string because the increased friction between the pulley and string will cause less slip. Capstans operate according to the equation seen above and improves the slip exponentially with each time the ‘rope’ wraps around.
Summary Points are Below:
- Have at least one EE on the team
- Use capstans for the rotational motions to decrease slip
- Source electrical components so that they are all compatible, and source them from companies that have great technical support and extensive documentation available *Cough cough* Anaheim Automation!
- Make the mechanical components lighter so that the design would require less powerful motors
- Use a Simscape Multibody or other similar Dynamics Modeling System to better estimate the required Torque
Our summary document can be found here
Functional Demo MaterialsInclude links to:
- Notes from review (To be added after)
- Action Items (To be added after)
Plans for Wrap-up
- As a team, we plan to take shifts presenting out exhibit at ImagineRIT. At our exhibit, we will demonstrate an eating motion from our device, as well as provide information about Essential Tremors to guests.
- Following ImagineRIT, we will clean out our locker, donate any surplus materials to the Senior Design office, and hand off our device to our customer.
- Last, we will participate in our final Gate Review during Finals Week