Our arm system consists of a power supply, two microcontrollers, a Bluetooth controller, a small DC motor, and three stepper motors and motor drivers. The arm itself is mainly 3D printed with steel bearings and axles for smooth rotation and meshing of our parts. The arm also uses a belt drive system for the second linkage to optimize motor placement for reduced torque on the system. In order to control the arm we have a microcontroller at the base of the arm with an ESP32S3 that is connected to a controller via Bluetooth. The microcontroller reads joystick inputs of the controller and then sends STEP/DIR commands to our stepper motors to rotate the arm or move a linkage of the arm. The second microcontroller is located near the end effector of our arm and actuates the claw. It is connected via WiFi to the base microcontroller. Once the base microcontroller reads a trigger input from the Bluetooth controller, it sends a command to the end effector microcontroller to power a DC motor which either closes or opens the claw depending on the button press. The entire system is quite heavy and requires a lot of torque to move. To reduce the torque required by the stepper motors, we improvised a jib that is connected to the arm via an elastic band.

Overview: In designing our arm from scratch, we had many engineering considerations when determining how our mechanical and electrical systems would work to produce our imagined robotic arm. After many many iterations, we arrived at the previously described system. There is a myriad of components we needed to consider for this design with the majority being integrated with our custom PCB stepper drivers. We reached out to TAs of the course who had previously made their own robotic arm, and they nudged us in the direction of using a Trinamic stepper driver (TMC 2652C-LA). We used its design to make our own stepper driver and had to source the dozens of components needed for its functionality and fit on our PCB.

Learnings: While assembling the arm we ran into many mechanical issues which forced us to source new components quickly like our steel bearings and axles. Luckily for us, other issues we encountered like an inadequate claw design were able to be remedied with components from a makerspace on our campus.

Future Work: With more time and budget to improve our project, we would reconsider our choices for materials and components to make the system function smoother and look more refined. For instance, we underestimated the weight of our 3D-printed arm. Exploring other materials could help us reduce weight while remaining rigid which would make the stepper motors more effective without degrading the functionality of the system.

(10/23) COMPLETED 

Overview: The main components of our arm are 3D printed. We initially broke this task into three parts to increase our efficiency and delegate this effort effectively. Purab designed and printed the base for the arm. Sasha designed and printed the arms and pulley/gear system. Syler designed and printed the claw for the arm. This whole process required a ton of 3D printing which occupied a great deal of time.

Learnings: We hoped that our designs would mesh together, and we would be able to amalgamate our prints to assemble our puzzle piece arm. This was not the case and a huge problem in building our arm. Upon trying to mesh our individual designs, Aleksandar realized that our designs would simply not work. Too much friction would be caused by the 3D-printed axles, the base was too large and weighed too much to rotate, and not enough time was available to integrate the rope-activated claw into a new base design. Aleksandar overhauled the entire mechanical design and spent days in envision CADing to make an effective solution allowing time to print and iterate along the way. New axles and bearings were sourced for all rotating parts to enable the arm to move, and the fully 3D-printed vision was left behind. We ended up using steel axles and ball bearings to make the entire robot appear frictionless.

Future Work: As noted in our team tab, we are not mechanical engineers. Through cooperation with friends and peers with more background in mechanical design, we were able to arrive at our system which is far from perfect. If given more time our main focus would be to reduce the weight of the system to reduce the torque needed from our motors. We would also redesign the base to fit our motors more snuggly to pull more output from the motors. There are a lot more improvements that could be made, but we would start there. In Aleksandars journey to make a good robot arm he spoke with people from envision, yonder dynamics, and DIB. He talked with David, one of the heads of DIB, and Mingwei alot, he also spoke with Claire, a now graduate Mech E student, and envision volunteers and other TAs when working on the many iterations of design.

(11/4) COMPLETED

Overview: As mentioned in the system & components list milestone, a large effort for this project was R&D of our PCB for driving our stepper motors. Using schematics of the TMC chip, we created our own version, schematic, and PCB. Suitable MOSFETs and components needed to be sourced to integrate with the constraints of our system, copper pours had to be enlarged to support our desired operating amperage, and extensive wiring had to be laid out to connect the components in correct orientations. Our team researched the PCB together, Aleksander did the bulk of the schematic considerations, and Syler designed the PCB, finalized the schematic, and soldered all the SMD components to the boards upon arrival.

Learnings: None of our team members had much previous experience designing PCBs, so this was a great learning opportunity. In designing the PCB we learned about design considerations like decoupling capacitors, sense resistors, and a myriad of wiring considerations when connecting our components. These components all had to be sourced, and we had to scour through countless datasheets to ensure their compatibility with our driver. This was also new to us given our PCB and hardware experiences. These challenges taught us the importance of thorough research, precise design, and meticulous assembly in creating a functional PCB. In the design of the PCB we ran into an issue with the MOSFETS, we accidentally switched the sources of the CMOS chips which in turn causes a short. This is very applicable to classes like ECE 102 and 164, where we learn the NMOS essentially has a diode connection from the source to the drain, this means when we switch the sources our NMOS's source is constantly connected to power allowed current to flow continuously! 

Future Work: As we will mention later in the component testing milestone, our PCB had some issues. Future work would include fixing the footprint of the MOSFETs of the PCB along with making some other edits to improve performance. The stepper drivers we used got quite hot in a relatively short amount of time when operating the arm. Including components or improving PCB design for heat dissipation would be in the cards.

(11/18) COMPLETED

Overview: After the design phase of our project, we shifted to system integration which confirmed the feasibility of our system design. In testing our components we were able to iterate designs to better mesh our components together and replace ineffective parts for a more effective solution. Throughout our testing, we pivoted from a rope system for the movement of arms to a belt-driven system, created a motorized claw to replace the previous linear actuated design, implemented a jib to pull on the arm to reduce torque, added material between the motors and base to create a more snug-fitting, and abandoned the idea of strictly relying on 3D printed materials. Unfortunately, we found a short in our PCBs which rendered them useless in operation. From our testing, we deduced that the sources of the MOSFETs were connected which caused the N channel to always be on making it impossible for the components to switch current and drive a motor. Without this foresight, we tried configuring the chip which required hooking it up to a power supply which likely fried the TMC 2652C-LA. Fortunately, we foresaw potential issues with the PCBs and already had backup drivers ready to integrate into the system.

Learnings: A huge learning point from all of the testing and iteration we had to complete during this process was to not try to reinvent the wheel. Although the course required it, designing a custom, untested PCB to perform a task that could be performed by an already existing, tested product is not wise. Neglecting other designs that used bearings and steel axles to rotate about, and instead trying to make an entirely 3D-printed system work led us down an iteration nightmare that wasted resources and time. If we were to redo the project, we would spend much more time considering other solutions and what made them work, what was similar between them, and what seemed fundamental to making a project like this work. 

Future Work: The aforementioned learnings associated with testing our components and parts are lessons that will be carried with us into future projects and possible future work on this system. There are many modes in which this project could be improved and if so these improvements will be made with greater consideration and a broader perspective.

(11/21) COMPLETED

Overview: Our arm moves with input from a Bluetooth controller. To implement this, we needed to use the ESP32S3's Bluetooth capabilities to connect to our controller. Purab and Syler worked individually to find and write code to bridge the gap between the microcontroller and the controller. Purab found a GitHub repository, implemented some tweaks, and connected the controller for effective inputs. These inputs were then used and mapped to work with each motor individually. We also made a tutorial on how to connect a controller to an esp32 dev board here.

Learnings: Initially, we planned to use a wired Logitech controller to operate the arm via HID, aiming for faster processing and improved accuracy. However, we encountered several challenges, such as powering the ESP while the controller was plugged in and testing inputs with the controller. Consequently, we decided to switch to a Bluetooth Xbox controller to control the motors, which resolved these issues and streamlined our setup.

Future Work: With the Bluetooth setup now complete, the input delay is barely noticeable. With more time to work on the project, we would try to map the analog joystick inputs to directly correlate with the speed of the motors. In our current implementation, there is no way to vary the speed of the input using the controller.

(11/21) COMPLETED

Overview: Our design incorporates two onboard ESP32S3 dev modules. One is mounted on the base to process controller inputs and map them to specific motor controls for basic arm movement. The second board controls a DC motor responsible for closing and opening the claw. We opted to use an ESP-NOW connection between the two boards using WiFi to maintain a neat appearance without having to wire the boards together on a system with so many moving parts. WiFi was chosen over Bluetooth for better performance with lower power consumption, low latency, longer range, and simpler pairing. 

Learnings: While implementing the ESP-NOW connection, we encountered several challenges. Initially, we faced issues with the stability of the connection and the synchronization between the two ESP32S3 dev modules where there were a lot of packets that were failing to send. Through trial and error, we adjusted our code and configurations to achieve a reliable connection and were able to send and receive data efficiently with a small input delay. Additionally, we learned the importance of optimizing our code for low latency and efficient power consumption. 

Future work: With everything working now, we plan to further refine our system. We aim to enhance the speed of the ESP-NOW connection and reduce the send/receive delays even further. Additionally, we will work on improving the user interface for easier control and mapping inputs to allow for more precise motor control of the claw. Similar to the stepper motors, we would like for the claw to receive analog input to open and close in a correlating manner to the magnitude of said input. 

(11/30) COMPLETED

Overview: A stretch goal for the team was to implement inverse kinematics in order to operate the arm smoothly and without much cognitive load on the operator. The inverse kinematics of the system were relatively easy to solve as we designed both of the linkages of the arm to be the same length. Theoretically, the input of a joystick would correlate to moving the end-effector either up and down or in and out. These desired locations would be processed by the script which would output the number and direction of steps for each linkage to reach the desired end-effector position. 

Learnings:  Describing the kinematics of a system can be incredibly painstaking and translating them to function with the real world and real-world conditions complicates things even more. This is a harsh reality that we had to face and kept us short of obtaining this stretch goal. With our motors having space to move during operation,  not flush gear meshing, and variable motor movements due to relying on the attachment jib, we simply had too many variables and not enough time to debug an inverse kinematics control scheme. In actuality, we found it quite intuitive to operate the arm without a complex control scheme using joystick inputs to directly control each stepper motor individually.

Future Work: With more time and a more robust system which would be arrived at by future work described in previous milestones, control schemes could be realized without as much of a hair-pulling effort.

(11/28) UNRESOLVED

Overview: With the mechanical system assembled and the electrical system wired. We move to testing the entire system and calibrating motor commands to refine movement and provide enough torque for successful operation. However, motors were not the only part of the system that we had to alter and improve during our testing. Various elasticities of the bands connecting the jib to the arm had to be tested to provide enough additional force to help lift the arm without prohibiting it from moving back down. Material like duct tape, hot glue, and elastic bands were connected to the claws to improve the gripping strength of the system as the smooth and rather thin claws were not capable of holding anything with a noticeable weight. We also had to edit the code to map our controller inputs to control the desired motors as before testing we were not sure which direction the motors would be moving inately. 

Learnings: Our calibration and testing were executed relatively efficiently and completed in a timely manner. That being said, this had to be the case or the team wouldn't have slept for a much longer time period. Unfortunately for us, we had dealt with unforeseen hurdles that forced us on the back foot in completing this project. Fortunately for us, our team bunkered down for this milestone and pushed the project over the finish line developing and enhancing a resiliency to not succumb to adversity which we will prove important in our future projects.

Future Work: The previous sections mention improvements and considerations for the robotic arm in their own regards that would require new testing and calibration into the system. This would still remain an integral step if more work is to be done on the project.

(12/2) COMPLETED