ASI-404 Mobile Manipulator for the IDP Hub

1.2.1 Tinkering Corner

The Tinkering Corner (Location in Figure 3) is where staff and students have access to machines to do fabrication such as 3D printing and laser cutting. The space is also utilised for classes and workshops.

1.2.2 Sandbox

The Sandbox (Location in Figure 4) is the ‘classroom’ area of the Hub. It is frequently booked for events, classes and workshops. Students also come here to study or have discussions.

1.2.3 ILounge

Like Sandbox, this space is used for classes and discussion amongst students. (Location in Figure 5)

2 Problem Analysis

2.1 Stakeholders

The project involves the Hub Technical Staff seen in Figure 6, How Yee Teng (primary) and Patrick Tan Shoong Chin (secondary), as well as the Hub Technical Assistants. To gather insights, data collection through surveys and observations helped the team to understand their roles and contributions as well as understanding what problems the staff faced on the ground.

2.2 User Survey

User surveys conducted by the team were to collect information such as the taskings that the staff members need to conduct daily, the frequency of each task (Figure 7) and their thoughts on how to improve their current workload.

Staff report that even single-item pickups disrupt their work: tools are dispersed across the Hub, and requests often arrive mid-task, forcing pauses or delays. Students also pile used items on a table, leaving staff to restock before the 6 pm close, creating a rushed end-of-day.

To understand staff workload, we tracked Hub footfall for one month and compiled historical data on major tasks (Figures 8–9). Both series show steady growth in recent months, signaling rising demands without added manpower.

2.3 Problem description

To ascertain the problems further, we drafted up a problem identification table utilising the 5W1H template in Figure 10.

Staff surveys and observations show a consistent strain in balancing time-critical tasks with student support. Accordingly, we framed a problem statement that captures these operational challenges faced by Hub staff.

2.4 Problem Statement

Several redundant tasks are slowing down the work of the Hub Staff and reducing efficiency in the Hub during the school semester. There is a need to streamline or automate these tasks.

2.5 Design Statement

To build a system that is mobile, to travel around the Hub’s environment, can manipulate and interact with the Hub’s objects and is autonomous, the staff do not need to act as a middleman

2.6 Value Proposition

To assist in handling tasks that cannot be handled by software changes due to the physical nature of interaction, a physical solution can be created that will be able to aid the staff in handling work as proposed in the Value Propostion Canvas in Figure 11.

The team will develop an autonomous mobile manipulator that combines navigation and manipulation: it can move through the Hub, pick and handle objects, and deliver them to staff—without requiring constant monitoring or extra devices.

2.7 Concept Development

In Figure 12, the team compared candidate concepts across hardware complexity, cost, scalability, and task fit. A traditional mobile manipulator emerged as best: it supports quick end-effector swaps, adapts well to the environment, and remains statically stable—even during power loss or emergencies.

2.8 Design Specifications

Based on the derived problem statements and key problems identified by the staff, the design specifications were prepared. Given our limited manpower, budget of $1600 SGD and time for development of less than a year, we decided to scope down to 3 distinct tasks that the system must achieve that assists with the staff.

Task 1. The system must be able to perform tool collection

Task 2. The system must be capable of point-to-point delivery

Task 3. To supplement controls to the system, a user interface must be created

2.8.1 Task 1: Tool Collection

For task 1, the robot is to grab tools from the pegboard shown in Figure 13, put it into an onboard basket and deliver it to a table. End-effector system with tool changer capabilities enables picking tools of different geometries.

2.8.2 Task 2: Point - to - point delivery

For task 2, the robot is to travel to the storeroom shown in Figure 14 where several components are located to return items that the students have borrowed throughout the day. The onboard basket can be detached from the system to return items as a set.

2.8.3 Task 3: User Interface

For task 3, for the staff to control and monitor signs onboard for the system to function, a user interface is to create that can link commands from the user to the relevant commands for the hardware to perform the task. A sequence diagram for the user interface is shown in Figure 15.

2.9 Subsystem Identification

Based on the taskings that the robot must accomplish, we have identified the key subsystems that need to be developed to bring the system to a minimum viable product, shown in Figures 16 and 17.

2.10 Design Methodology

For the design methodology, the team intends to adopt the framework seen in Figure 18 that covers research, iterative design, execution and finally evaluation of results until all goals are achieved.

2.11 Work Allocation

The work allocation amongst the team members is shown in Figure 19.

3 Mechanical Subsystem - Frame (Fang Chen)

The scope of this subsystem is to design a structure to integrate the AMR and Cobot mechanically.

3.1 Design Pre-Evaluation

Some key specifications influencing our design are shown in the figure below. Refer to Appendix A for detailed information. Link to Appendix A

3.2 Design constraints

To design the robot, design constraints must first be established. The 2 categories of constraints are environmental and system constraints.

3.2.1 Environmental Constraints

To perform Task 1 (Tool Collection) and Task 2 (Point-to-Point Delivery), the robot’s physical size must be appropriate. Constrains on the robot’s dimension are as identified:

1. Height Constraints:

The structure must position the Cobot at a suitable height so that its full 910 mm reach can access both the top and bottom sections of the pegboard, as well as the worktable surface as shown in figure 21.

2. Width Constraints:

The robot’s overall footprint must fit within the aisle and workspace clearances shown in figure 21 to allow smooth navigation in the Hub.

After taking measurements of the Hub’s environment, the allowable range of robot specifications is summarised below:

3.2.2 System Constraints

1. Payload Capacity and Stability Constraints:

The AMR’s payload limit and stability requirements significantly influences the mechanical design. Figure 23 shows the main payloads on the AMR.

The AMR has a payload capacity of 100kg. After deducting the weight of the payloads in figure 23, 40.9 kg capacity remains. This limited allowance requires the structure to be designed as lightweight as possible to accommodate for contingencies.

Apart from that, the overall CG of payloads must remain within the AMR's designated limits, as illustrated in figure 24 below. To achieve a centralized CG, our components must be arranged in such a way that the weights distributed across the AMR are as even as possible. This is challenging due to the significant variation in payload weights and the need to optimise the AMR’s limited space.

2. Functional requirements of robot:

To support the robot’s intended operations, the mechanical structure must accommodate the following features as shown in the figure below.

Integrating these functional needs poses a space optimization challenge as there is limited space available on the AMR.

3.3 Payload configuration concept screening

With the design constraints established, the next portion of the design process involved identifying the optimal payload configuration on the AMR. To do this systematically, the largest and most restrictive component- the controller- was positioned first to define the primary boundaries, after which smaller components were arranged around it.

The figure below shows the 4 main controller orientations explored:

Based on these orientations, 5 iterations were drafted:

To decide the best design, these iterations were screened through a selection matrix as shown in figure 28. The definitions of the evaluation criteria are as stated in figure 29. To understand the rationale behind the selection process in details, refer to Appendix D1.

From the concept selection matrix, we see that iteration 5 is the best performing configuration. Thus, it will be the chosen design for further development.

3.4 Chosen Design

With the chosen payload configuration in section 3.3, we went on to design the details of the full robot as seen below.

Figure 31 shows some general dimensions of the robot, all which comply with the constraints mentioned in section 3.2.1. As shown, the robot can reach both the top and bottom of the tool board. Its width also remains within the maximum allowable 780 mm.

3.5 Features of Design

3.5.1 Frame of robot

The frame of the robot is made of 3030 Aluminium profiles which are bolted onto the AMR surface at 8 points. We tried to use as little profiles as possible for a lightweight structure.

Unchosen frame Design:

The figure below shows a previous frame iteration. This design wasn’t selected as it required more profiles, particularly at the base (highlighted in red in the figure) where it mounts to the AMR. Using more profiles increases tolerance accumulation, making assembly more difficult and raises the risk of structural misalignment. Additionally, this design requires more bolt points. Thus, it wasn't used.

3.5.2 Adaptable Frame Design

For contingency reasons, the frame is designed such that more profiles can be easily added in to support the Cobot if needed, without needing to redesign the whole frame.

3.5.3 Adjustable Cobot position

The Cobot is adjustable along it’s z axis for 2 purposes: To make space for future accessories and to allow easy re-adjustments to the robot’s CG if needed.

3.5.4 Electronics segregation - Control and Power panel

There are 2 electronics panels on the robot-Control and power panel. The control panel holds components such as the PC and network switch, while the power panel holds components such as voltage regulators and power distributors. Separating power and control components simplifies troubleshooting and minimizes electrical noise interference.

The vertical, large panel design also provides ample space for future electronic expansion and very easy access to components.

3.5.5 Component mounting and wire management

DIN rails were used to enable convenient rearrangement and replacement of components while cable trunking laid in a grid manner makes wire management easy.

Additionally, spaces at the top and bottom of the panel are intentionally left for wires to pass through, as shown below.

Having described the robot’s features, the following video shows the current state of the assembled robot to provide clearer view of its physical construction.

3.6 Structure analysis

3.6.1 Current AMR payload weight

As of the current design (excluding the external cover, tool changer unit, and basket), the total payload weight on the AMR is 81.72 kg. Considering a ±5% tolerance, it would be 77.63kg-85.81 kg. To improve accuracy, the actual material properties of heavier components were measured and applied in SolidWorks (See Appendix D2).

3.6.2 Stability analysis

As mentioned in Section 3.2.2, the AMR has defined boundaries that indicate the permissible CG range for its payload. To ensure our design meet this requirement, CG analysis was conducted at three arm positions: Default, fully forward, and fully sideways. In all cases, the CG remained within the allowable limits.

The stability test of the assembled robot was also found to be consistent with our analysis results.

3.6.3 Structural strength analysis

Static simulation was done to ensure that the frame and Cobot mounting plate is strong enough to withstand the heavy weight of the Cobot. From the figure below, we can see that the structure is well below it’s yield strength. Explanation for how analysis was done can be found in Appendix D3. Apart from yield strength, we also analysed other aspects such as Factor of safety. See Appendix D4 for more information.

As the robot is stable at its extreme arm positions in the CG analysis, and static loading tests indicate the structure is strong, we know that it will also remain stable under dynamic conditions, particularly since both the Cobot and AMR will be operated at conservative speeds for safety reasons.

4 Mechanical Subsystem - End-Effector (Jason)

To design the End Effectors for the system, design constraints must be established in terms of the actuation mode of choice, overall maximum size and the maximum mass before further analysis on the approach can be done.

4.1 Actuation mode

To narrow down the ideal Actuation mode for the system, we evaluated the main types of actuation methods against various criteria for the system through the Concept Screening technique seen in Figure 44.

Given the AMR’s payload limits and internal space constraints, hardware requirements received higher weight. Based on the concept screening and system needs, electric actuation was selected for the end effector.

4.2 Size and Mass Constraints

The size and mass constraints of the system are decided by the following factors:

Cobot End Effector Payload Capacity: 5kg

Ideal end effector centre of gravity: Within 135mm from the end connection of J6, max width of 200mm.

Allocated space on the robot structure: 600mm x 135mm x 200mm (See Figure 45)

4.3 End Effector Analysis (Task 1: Tool pick and place)

Given the task requirements, one end effector must pick tools from the pegboard, shown in Figure 46. Tool size and mass were measured to define the end effector’s design requirements as shown in Figure 47.

4.3.1 Design challenges

The clamping interface must secure tools with varied, non-linear surfaces and materials (plastic, rubber, steel) whose friction affects required clamping force. Because approach angles may be imperfect, the gripper must tolerate misalignment from positional error without dropping the tool. (Figure 48)

4.4 End Effector Design

With the design constraints known, design specifications for both the gripper and tool changer unit are specified.(Figure 49)

4.5 Grippers

To choose the ideal gripper mechanisms, the team used a concept screening chart to evaluate different designs against key metrics shown in Figure 50.

Based on the metric scoring, the rack and pinion and lead screw approach were both chosen to further prototype and explore.

To handle misalignment and limit contact pressure on curved surfaces, we explored compliant fingers—specifically the Festo Fin Ray design (Figure 51). Its flexible, fin-like ribbed structure passively wraps around objects, redirecting contact forces into closing forces rather than peeling. The result is gentle, adaptive gripping of irregular or fragile parts, high misalignment tolerance, and simpler actuation/control than rigid parallel jaws.

4.6 Tool Changers

As the system will be interacting with various tools, a singular gripper design may be unable to carry or support all types of objects. As a result, the team aims to implement a tool changing system onboard the Cobot to facilitate end-effector changes. Due to the actuation mode being limited to being electric, the team narrowed down 3 concepts that can be explored and evaluated those against metricsa as seen in Figure 52.

Due to the limited space and mass constraints on the system, the Compactness/Weight criterion was weighted highly. Based on the scoring, the Permanent Electromagnet was chosen to be the concept to be explored further.

4.7 Prototypes

4.7.1 Gripper

Before analysis can be done, an approximate normal force acting on the gripper jaw was established at 10N based on supporting a load of 15N with rubber contact against metal at a coefficient of friction of 0.69. (Refer to Appendix E2 and E3)

To test the Fin Ray design, an inspired gripper was designed and simulated it in SolidWorks via Nonlinear analysis, using TPU-85A as the material. The goal of the analysis was to locate the ideal gripping section that will allow the gripper to wrap around the object as seen in Figure 53. The full analysis can be seen in Appendix E4.

To test the Rack and Pinion concept with the Fin Ray gripper fingers, a 3D-printed prototype was built using PLA with TPU-85A for the fingers to test the deformation and gripping strength. (Figure 54)

Since this is a prototype, it was designed with parts that facilitate swapping of finger geometries (Figure 55) to test clamping force. Initial tests seen in the video below show favourable results in carrying objects up to 900g. Further tests will be conducted to validate different gripper profiles and geometries.

4.7.2 Tool Changer

To test the permanent electromagnet concept, calculations(Refer to Appendix E8)guided the selection of the magnet and target material to maximize holding force.

The electromagnet used was a permanent electromagnet with a 24V demagnetisation (release) input with 30kg rated strength. For the magnetic material, S275 Ferritic Steel was chosen with 6mm thickness to improve flux and holding force. (Figure 56)

Initial tests indicate that the magnet can sustain 10kgs of load for a sustained period. Future works into the next semester will focus on creating the tool changer system with the mechanical body and electrical connections.

5 Electrical Subsystem - Electrical Integration (Fang Chen)

The scope of this subsystem is to design and implement the circuitry used to integrate AMR and Cobot together.

5.1 AMR and Cobot integrated circuit

The system load can be classified into 2 categories: peripheral devices (PC, router, etc.) and the Cobot controller.

Ideally, all electronics would be powered directly from the AMR. However, the controller requires up to 1 kVA during continuous operation, while the AMR can only supply 960W (48V, 20A max), which is insufficient. To address this, a 72 V battery with a capacity of 1152 Wh was introduced.

Figure 57 shows the initial circuit design, where all loads were powered solely by the battery. This configuration was later revised as the battery runtime is limited. To extend system operating time and optimize power usage, the peripheral devices were powered by the AMR instead, reducing the load on the battery. The finalized circuit design is shown in Figure 58.

In the final circuit, the AMR’s 48 V is stepped down to 5 V, 9 V, 12 V, and 24 V to power the peripheral devices. Since the controller operates on AC power, the 72 VDC from the battery is converted to AC through a power inverter. This is the current circuitry on our robot. Additional loads such as tool changer, and other peripherals are to be incorporated later in the project. Battery runtime calculations comparing the initial and final circuit designs are provided in Appendix F1

5.2 Centralised E-stop system

Currently, both systems have separate E-stop circuits. A centralized E-stop system is required to ensure that pressing the E-stop sends a signal to both systems simultaneously, triggering their respective shutdown sequences. This will be implemented using a relay as shown below.

6 Software Subsystems (Jason)

6.1 Software Strategy

To ensure completion of the 3 main tasks assigned, an understanding must be done on how the stakeholders would interact with the system and make it perform the desired tasks.

A user sequence diagram (Figure 60) was created to showcase the generic workflow of the system by the user.

A robot sequence diagram (Figure 61) was also created to show the motions of the robot upon receiving a command.

The Home position for the robot is defined as the location where the robot is located while idle whilst the Charge position is defined as the location where the robot will go to charge itself when the battery is low. (Figure 62)

Sofware Subsystem Overview:

6.1.1 Software Sequence for Task 1

For the system to complete Task 1, a detailed sequence flowchart in Figure 64 was created to show the software flow of the system from receiving a command from the user to completing the task.

6.1.2 Software Sequence for Task 2

For the system to complete Task 2, a detailed sequence flowchart in Figure 65 was created to show the software flow of the system from receiving a command from the user to completing the task.

6.2 AMR to Cobot Communication

To allow the AMR and the Cobot to establish communication, the team decided to use the ROS2 Framework as developing a custom software to fully integrate both systems would be challenging given the closed-source nature of the AMR and Cobot.

6.3 Task planning and motion control

To make the system work as a unified robot system, the robot software must know how to establish the parsing of commands from the user to clear instructions to the hardware.

A software container diagram using the C4 model notation in Figure 66 was used to show the communication between nodes to create the Robot Software System.

6.3.1 Safety Interfacing

Both the AMR and cobot include collision safeguards as shown in Figure 67. The software system interlocks their motion, cobot commands are sent only when the AMR is stationary, and vice versa. During cobot operation, an ellipsoidal “protective bubble” enforces a safe zone; any trajectory that breaches it is terminated immediately.

6.3.2 Cobot Trajectory Planner

For the Cobot to reach a desired position in space, a positional command made of Vectors and Quaternions must be sent to establish both relative position and orientation, which is called a “frame”. To move between 2 frames with a specified trajectory and constraints would require a trajectory planner.

Custom planner development was out of scope, so we used MoveIt2 planners compatible with the cobot driver: OMPL, CHOMP, and PILZ. We evaluated them for our use case and compared their performance across key metrics (See Figure 68).

We scored planners 1–3 (3 = best), penalizing stochastic/unpredictable behavior and heavy compute. PILZ ranked highest because it deterministically picks the shortest feasible path, respects velocity limits, and delivers repeatable, predictable motion.

The planner was defined for use in the test_rv5as.py node such that any input commands will move the robot system accordingly.

6.3.3 Waypoint finding

For the AMR to reach a desired waypoint, an API call to the Waypoints API will allow for requesting a specific goal point for the robot to travel too that can also be saved via another API call to the Goal API. A map of the Hub environment was created via SLAM mapping to allow the AMR to localise itself and plan a path to the desired waypoint.

6.4 End Effector Firmware and Control

To control the end-effector, the current proposed plan is to utilise the ROS2 system as the higher-level control whilst a Microcontroller will act as the lower-level control that deals with the motors, sensors and other peripherals on the end-effector unit. (Figure 69)

6.5 Graphical User Interface (GUI)

Based on Task 3, a user interface is to be created to allow the stakeholders to send requests to the system to perform tasks.

Although both the AMR and Cobot have their own respective GUIs for control, to create a unified robot system would mean a singular user interface that allows for control of both systems.

The final GUI vision in Figure 70 is a single, unified interface that controls both the Cobot and the AMR. Built for staff and makers, it enables task execution without any coding, using clear workflows and teach-by-demonstration tools. A dedicated teaching mode streamlines adding goals and waypoints, making everyday operation fast and intuitive.

6.5.1 Current work on GUI

An Engineering GUI prototype has been created to test basic functionalities such as sending movement commands to the Cobot. (Figure 71). The attached videos show the Cobot being controlled via the GUI in both real and simulated environments.

7 Project Plan and Future Work

7.1 Gantt Chart

7.2 Future work

Future work will focus on completing both the frame and end-effector mechanical design, electronics development for the end-effector, further software development for task planning and GUI creation, and extensive testing of the integrated robot system to ensure reliability and safety.