Adam:

As the week started we have turned to Steven for a advice on how to proceed next. What we have learned at this point that we can’t do everything at once, since there is a high risk of something not working properly, so in the end, ruining any progres we have made. After his and all the other teachers advice, we are on a right path of making things finally work our way.

Adrian:

Nothing much has changed in my department. I am still coding the basic movements, trying to integrate Moveit! into the programming. However, with ROS and Moveit! meant mostly to be used on Linux, their Windows solution hasn’t been too kind with my computer. So while I try to program simple movements for testing, I’m also being my own tech support to figure out why ROS isn’t working correctly, and looking into small issues with translation between the URDF file and Rviz.

Jacob:

We started this week with a lot of words of wisdom from Steven and other teacher that luckily set us on the right path and opened our eyes. They told us to fucs on individual parts and not on the whole assembly at once. And that’s what we did – me and Adam focused on the claw while Sergi and Pamala focus on the arm. Also last time we also forgot to print some models so we had them printed for now.

Farah:

Contributions

Workspace Setup: Organized the workspace and directory structure to accommodate the robot assembly received from the mechanical team.

Understanding the Hardware: Analyzed the robot’s mechanical design to understand how to integrate it with the software components.

Initial Launch Files: Created basic launch files in arduinobot_bringup to initialize the robot’s nodes for testing.

Challenges

Hardware-Software Alignment:

Ensuring that the software architecture aligns with the physical design of the robot was a significant challenge. The mechanical team provided a robot assembly with specific dimensions, joint configurations, and mechanical constraints that needed to be accurately represented in the software. The discrepancies between the theoretical models and the actual hardware could lead to incorrect movements or even damage to the robot.

URDF Modeling: The Unified Robot Description Format (URDF) files in arduinobot_description/urdf had to be meticulously updated to match the physical robot. This involved specifying correct joint types, link lengths, masses, and inertia tensors.

Joint Configurations: The robot had unique joint arrangements that required custom configurations. Ensuring that the joint limits and motion ranges in the software matched the physical capabilities was crucial.

Coordinate Systems: Aligning the coordinate frames between the software model and the physical robot was essential for accurate motion planning and control.

Kinematic Chains: Understanding and modeling the robot’s kinematic chain was necessary to implement effective controllers and motion planning algorithms.

Testing and Calibration: Extensive testing was conducted to verify that the software commands resulted in the expected physical movements. This included calibrating sensors and actuators to synchronize the software and hardware responses.

Dependency Management:

Installing and configuring the necessary packages and dependencies to support the new hardware introduced several complexities:

ROS2 Packages: The integration required additional ROS2 packages that were not part of the initial setup. This included packages for hardware interfaces, controllers, and specific sensors.

Version Compatibility: Ensuring that all packages were compatible with the ROS2 distribution in use, I started using ros2 jazzy at first but it quickly realized that dua to it being the newest distribution they ware a lot of documentation Gaps in some cases, the lack of comprehensive documentation for certain packages or drivers required diving into source code or seeking help from community forums. so I switch back to Humble, and it went much smoother after that.

CMake and Package Configuration: The CMakeLists.txt and package.xml files across various packages needed updates to include new dependencies and to ensure correct build configurations.

System Libraries: Dependencies on system-level libraries (e.g., Boost, Eigen) required careful management to prevent conflicts and to maintain system stability.

Pamela:
During this week we decided to split the work between the mechanical engineers Sergi and I took care of the arms and the base and Adam and Jacob the gripper.

So Sergi and I met once we got the modified parts with the tolerances to assemble them.

During the week Jacob and Adam also got the printed gripper but they realized that the gripper was designed for another type of motor so they had to design a part that would fit the servos that would go in its place.

Below we can see the complete assembly of the entire robot without the missing part to fit the servo into the gripper:

Once we got the complete assembly, we gave it to Adrian and Farah so they could test it with the real prototype.

Sergi:

What I did this week as a mechanical engineer was assemble the whole robot, especially the base and arm components and once we finished (mechanical engineers team), we gave the assembled robot to the computer science team to try their code out and test how the arm moves.

During the assembly we had some screws problems, that the ones that we had were not the right ones so we had to change them to find the correct ones. Another problem that we faced was that we didnt’t had enough pieces to gather the servomotor with the robot pieces, but finally we could get them to finish the assembly.

All the photos of our progress and the final look of the robot are in Pamela’s part.

At the end this was a fun week because for me it was a more entirely mechanical work to assemble pieces together with screws and servomotors.