Autonomous Production Line with Create3 and FANUC CRX-10 in ROS2 Humble

The program delivers and performs operations on a dice block with three robots; each communicating through ROS2 middleware via custom-made actions, topics, subscriptions, and services. The FANUC robots are using a custom python driver to control movements with cartesian, joint, and gripper actions, while the Create3 uses a combination of onboard movement actions for navigation around the station.
To communicate between different robots, each individual robot uses a custom "RobotClientNode" which establishes a communication pipeline for indicating their ready status. This is what makes the synchronized handoff operation possible.
The process is started or stopped through a message sent by a broker that monitors and aggregates process data. The broker has no responsibility for communication between robots, and rightly so! ROS2 should always be responsible for inter-robot communication.
All robots report to this broker. Reports include information such as the robot's current location, ROS2 actions, and their overall goals (i.e. "Waiting for Create3 to be at the dock"). This information is collected in order to aggregate various processing data for identifying areas for process improvement. The broker and its analytics are available through a web interface developed with Django.
CURRENT PROBLEMS:
1. There is latency when trying to stop the conveyor after the retroreflective sensor is triggered. This could be caused by the ROS2 configuration causing the sensor to poll too frequently, which hinders the thread's ability to perform correctly. To solve, the polling rate could be reduced, or a thread could be dedicated to handling this task.
NOTE: This was later fixed by resetting the ROS2 daemon, and further testing wasn't done. The root cause is still not known.
2. The Create3's built-in docking program is somewhat unpredictable, sometimes causing the robot to search for the dock, even when the dock is directly in front of it. This can cause the robot to travel under the table and get into trouble with the cables. To solve, the sensors that detect and avoid imminent collisions could be re-enabled, which would cause the robot to detect some barrier, like cardboard underneath the table, and move away. Alternatively, the custom auto-docking algorithm I developed previously could be used since I know that the dock is always going to be in front of the robot - see video:
• Autonomous Docking wit...
3. The Create3 swings a little too far out, and sometimes at an angle when navigating back to the home station and collides with the safety cones. To solve, the drive distance for this movement should be adjusted. This wouldn’t address the alignment issue precisely, but would be appropriate given the system’s physical space constraints. The inconsistent alignment issue is caused by the onboard docking program, which sometimes docks the robot at a slight angle, which increasingly affects the robot's travel path at further distances.