Posts

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
Post a Comment
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
Post a Comment
Read more

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)
Post a Comment
Read more

Week 12

Image
  End of Semester This week marked the end of the first semester for the project, with a path set up for the next semester to have a prototype early on, as we have key components constructed for our final presentation. Motor with Display Code Demo (Elijah) Since the motor arrived this week, it was important to verify that a C++ program could interact with the motor via the sFoundation SDK (provided by the motor's company, Teknic). A passive demo was chosen as the team did not want to hastily demonstrate an active application with the motor within a week of its arrival, as we need more time to better understand it to avoid potential injury. The demo ended up displaying the tracking capabilities of the program, with the C++ program able to continuously query and display the shaft rotation amount in counts (approx. 0.01 degrees). This demo will be shown during the final presentation in live format. Motor Power (Gavin) While waiting for the materials to come in for the mounting structu
Post a Comment
Read more

Week 11

Image
  Continued Manufacturing This week was the continuation of the prototype building, with key materials arriving late in the week allowing for a more cohesive product at the end of the semester. Display Code Continuation (Elijah) In the meantime as the motor arrived, work was done on the display side of the code to make sure that the motor code had a proper program surrounding it. The display code runs off of SFML and Swoosh, two graphics libraries in C++. The goal for this week was to have an interactive menu screen with sound, and establish a "Sandbox" mode which will allow the user to freely move the robot handle and observe the corresponding dot move around the screen. In addition to setting up the initial menu system, the code is now hosted on Github to ensure proper version control and distribution among systems. Motor Mount and Power (Gavin) More analysis of the motor mount was conducted, specifically for the plates that the motors will directly connect to, and the stre
Post a Comment
Read more

Week 10

Image
  Initial Manufacturing This week marked the beginning of producing our first prototype, and gaining a batter understanding of what the final product should be for this semester with our available resources. Display Code Demo (Elijah) There are two sides of the code thus far in the project, display and motor control. In the meantime while motors arrive, work on understanding the display code was done. The library chosen for the display was SFML , a cross platform graphics and audio library compatible with C++.  The desired demo was designed to show how the code can produce an animation on screen while simultaneously listening for user input (mouse click), thus giving credence that the final program can display the handle position and listen for motor updates .  Beginnings of the demo were mostly learning details of C++ like h files, pointers, and classes, with the first output being very simple and static. After research of the documentation, testing, and development, the final demo fo
Post a Comment
Read more

Week 9

Image
  Continuation of Design Details This week primarily continued our focus of a more in-depth redesign of each module so that we can more efficiently build the initial prototype once parts are available. Motor Backdrivability and Tracking (Elijah) Once deciding that the ClearPath-SC line was the most probable motor for our application, we needed to make sure that specific functions were possible. This first of these functions was backdrivability, which seems to be most probable through the motor's torque limits, which are programmable in both directions. A excerpt from the user manual detailing this can be seen below: The excerpt shows ClearPath's native motor control program, ClearView. When doing further research if it is possible to adjust these limits through the C++ API, it does seem possible through the  sFnd::ILimits::TrqGlobal attribute. It is important to note that the documentation says the torque limit is not typically  changed during an application, but this infers th
Post a Comment
Read more