ARMtech

  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

  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

  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

  Design Details This week primarily focused on refining the details of each individual module to better prepare for the initial wave of ordering finalized parts and the construction of the prototype. Motor Selection More research has been dedicated to the selection of specific motors, with factors such as required torque, power, and control scheme being the main components considered. Some time was put into possibly downsizing the force requirements and/or the playing field size, and the motors available to such specs, but after discussing with Dr. Kim (client), there may be alternative ways to obtain the full power motors. The company from which we are considering purchasing from is Teknic's ClearPath line, featuring different motor styles based on control sceheme. These lines each have pros and cons, with the two most probable lines being SD and SC. For the SD line, a dedicated microcontroller is required that can be programmed with C++ code, and Teknic provides a compatible dev