Week 4

 Module Brainstorming

For this week we did a lot of brainstorming and coming up with the different modules the device will consist of and the possible solutions for each area.

Raw Module Generation

  • Below is the final set of modules defined by the team:

  • The textual list of the modules is as follows:
    • Gantry Movement
    • Kinematic Data Acquisition
    • User Interface / User Experience
    • Motor Controller / Motor Selection
    • Handle Ergonomics
    • Power Electronics / Distribution
    • Computing (Added post-photo)
  • Note: The module "Physical Display" was scrapped due to establishing a monitor will suffice and does not need to be an entire module.
  • Note: The module "Table" was put on hold for future evaluation, as the module primarily involved placement of the device in respect to the table rather than different objects or tools

Module Organization

  • After coming up with the modules, at least 10 different solutions for each model were brainstormed. 
  • Below is the set of photos for each module area (click the photo to inspect closely).






  • These were organized by overall module, and the modules themselves were classified into 2 areas: Software and Physical
  • Below is the map of the Software related modules (Kinematic Data Acquisition, UI/UX, and Computing)


  • Then, the next map is for the Physical related modules (Gantry Movement, Motor Controller/Selection, Handle Ergonomics, Power Electronics/Distribution) 



Final 3 Choices for each Module

For an in-depth listing of the merits for each module solution, visit the following sheet:
  • Each set of module solutions was then narrowed down to 3 choices, on which the linked Google Sheet holds the final choices. Though as an overview, each sheet is dedicated to a module, and the top 3 choices are listed with their pros and cons, along with the original module photo for reference (UI/UX pictured below).


Final Choice for each Module

  • The final choices for each module will be finalized during our team's meeting this Wednesday (10/4) as new information was obtained from a meeting (unscheduled, happened after a class) with our client, Dr. Kim, on Tuesday (10/3) regarding the feasibility of a gantry system and his goals regarding force control. 
  • A photo from the meeting can be seen below, detailing how to obtain position and force data from each mechanical system (gantry and linkage). Due to this information, we will properly reevaluate our current modules before making our final decisions.


Previous Deliverable Revisions

  • After receiving feedback last class on our previous deliverable submissions, we have been revising their content.
  • Specifically this week, Gavin worked on Deliverable 3 on making the Requirements more general to have them more testable in theory with a wider range of module choices, such as the data storage requirement not explicitly mentioning the number of tables, and now focusing on the type of data stored.


Comments

Post a Comment

Popular posts from this blog

Week 0

Image
Start of Second Semester   This week was the start of the second semester and focused on the mechanics and graphics of the program. Program Display (Elijah) Established a final theme for the GUI , and developed a second more straightforward theme to account for different audiences . Created the ability to use the program without a motor to allow for non -motor issue troubleshooting . Motor inputs are set to 0 (as seen in demo ) Linkage Forces Math (Sean) Checked Dr. Kim's math for solving the (x,y) coordinates of the end of arm Checked Dr. Kim's math for Torque required to produce a force at the end of the arm. Was going to ask Dr. Kim some questions but I became sick, so will do that Thursday. Handle Redesign(Nathan) Handle Redesigned for different heights. Handle size and material reduced. (Gavin)
Read more

Week 2

Image
  The Second Week Back   This week we focused on completion of 30% of the project which included milestones for each subsystem to complete as well as Completing Deliverable 5.  Kinematic/Kinetic Implementation and Risk Assessment (Elijah) Implemented the foundation of kinematic tracking with a single motor and translating that to a correlating screen position (responsible for the moon moving on screen ) Implemented the foundation of kinetic response to path deviation with a single motor , increasing the applied acceleration to a correction to ultimately control the torque to output the specified force on the handle Implemented correction timing mechanic , in which the user can correct themselves within a specified time limit before the motor takes effect completed sections 5 .4 - 5 .5 focusing on risk assessment and implementation End Connectors CAM and Assembly Drawings (Sean) Completed CAM for End Connectors Discussed CAM with Blake Shishido Completed Drawings for Full Assembly as we
Read more

Week 1

Image
  The First Week Back This week we focused on redesigns for the linkage system, some force mechanics research, as well as gaining an understanding for what will be necessary to have 30% completion by the 24th.  Force Field Research & Motor Code Time Tests (Elijah) https://www.sciencedirect.com/science/article/pii/S0165027012004736?casa_token=AO8eNFj4LAkAAAAA:25cCp1lG-zfDO-fEjP4doXl2ZQ7PDhODTE-xHWemj-rrrkQw-FP2ySvuFeykV3wAH7_5qdku  (Paper Link) Using the original given forcefield paper from last semester, found another robot named BioMotionBot, a very sophisticated 3D motion bot made in 2013. A lot of design revolved around using a 6D torque sensor (Manus also used this), while ours will rely more on calculations. (Cause these are really expensive) Had useful info and equations regarding force fields, which will be the crux of the course correction mode. Figure 1: BioMotionBot Figure 2: Force Field Equation (3D) Created a dedicated test screen in the program, capable of now causing
Read more