From this point onward, I was at the coding phase of the project— which is by far the most challenging part for me, as it's an area I'm least familiar with. I encountered several major obstacles during this stage:

1. Compatibility and Reliability Issues

One of the first issues I faced was the conpatibility issues between ROS2 and the newest Ubuntu version, and the lack of documentation and community threads for the relativly new ROS2 also made solve this problem more difficult.  I ultimately had to rely on trial and error to resolve this. The solutionn was to downgrade to an older Ubuntu release to ensure more reliable performance.

2. MoveIt Path Planning 

Setting up the MoveIt path planning plugin was another major challenge. The main challenge came from the need to export the CAD model of the arm into a URDF file—a format not natively supported by Fusion 360. So I had to use a third-party plugin to complete the export. This causes several very confusing problems that i had to solve, including a weird orientation issues where the exported models would always be laying on its side, which i later discovered to be due to the different XYZ coordinate system Fusion and ROS uses.

3. Hardware Interface and Intergration

My original plan was to use the 5 pins on the servo motor controller, each of which would control a component of the motors motion (Eg. Speed, Angle, Acceleration ...). For a total of six motors this would need 30 pins that can individually output changing voltage. However, midway through construction, I realized that since the off-the-shelf components I bought actually supported an alternative communication method called Serial Bus. This discovery allowed me to not use the 5 pins but only 2 pins and 2 wires total, as the wire would chain together all the motors.

For the hardware interface, I learned C++, and used it to code a node that would listen for the planned path and convert it into serial signals the motors can understand. And surprisingly it actually worked, however...

However, it was during this phase that I discovered a major design flaw: I had completely overlooked the need for angle sensors or limiters. This meant that there is no way for the robot to know calibrate its joint positions, which means the arm's movements lack any real precision or accuracy. Although it appeared to be moving correctly, there are no sensors that I can use to calibrate its simluation position.  This was not all however, as I continued testing, I identified several additional mechanical design flaws:

1. Glue Belts – These were often either over-tensioned (causing them to snap under load) or under-tensioned (leading to slippage).

2. Wobbly Axles – The axles connecting the motor and speed reducer were only supported on one side, resulting in wobbling during motion. This not only reduced tension consistency but also applied undue stress on the reducers.

3. Poor Cable Management – The robot arm couldn't rotate 180 degrees without cables tangling. Additionally, the cables weren't properly secured to the arm’s structure.

these combined issues together made me decide to halt the further development of the software, and go back to more research to construct a more solid foundation.