The experimental object is the xArm Lite6, a desktop-level six-degree-of-freedom robotic arm. According to UFACTORY documentation, the Lite6 has a compact mechanical structure, a maximum payload of 600 g, a maximum end-effector speed of 500 mm/s, and a repeatability of ±0.5 mm [11]. These characteristics make it suitable for small-scale manipulation and teaching-oriented simulation tasks.

To reduce model inconsistency, both platforms use the same source URDF/Xacro description of the xArm Lite6. The benchmark task is a predefined pick-and-place sequence rather than an open-ended grasping algorithm. This design keeps the focus on platform implementation and simulation workflow. Table 1 summarizes the task definition.

The benchmark is an implementation comparison rather than a claim that the two physics engines are equivalent. To replace qualitative labels with auditable measures, the common task is decomposed into six ordered stages: approach, grasp, lift, transfer, lower, and release. Task-stage completion is C = n_completed/6. Five binary implementation indicators are also recorded: P = 1 when an

online motion planner generates the executed trajectory; R = 1 when that trajectory is executed through a robot-controller chain; A = 1 when successful transport depends on an explicit attachment or parenting operation; F = 1 only when the transported object remains governed by contact, friction, mass, and inertia without kinematic attachment; and I = 1 when the implemented prototype provides scene-level scripted interaction for reproduction and display. These indicators describe the submitted implementations, not every capability of Gazebo or Unity; they also make clear which claims are supported by current evidence and which require additional repeated-trial experiments.

The procedure contains four steps. First, the same xArm Lite6 URDF/Xacro description and the same six-stage task are prepared for both platforms. Second, the platform-specific joint and scene components are configured. Third, each implementation is checked against the complete stage sequence. Fourth, C, P, R, A, F, and I are assigned from inspectable implementation evidence, as defined in Table 2. The available submission package contains the implemented workflows and task sequence but no repeated-trial log, timing trace, force trace, or joint-error

record. Accordingly, the revision reports no fabricated success-rate, duration, oscillation, or frame-rate statistics; Section 4.4 instead specifies the controlled experiment and reporting fields required to obtain them.

The Gazebo implementation is built around the ROS Noetic ecosystem. The xArm Lite6 URDF/Xacro model is loaded into a ROS workspace and instantiated in the Gazebo simulation environment. The robot description contains the link, joint, visual mesh, collision mesh, inertial, and joint-limit information required for simulation. To drive the virtual joints through ROS controllers, the active arm joints and gripper joint are configured with transmissions.

Motion planning is implemented using MoveIt!. The arm planning group and gripper control group are configured so that the manipulator can plan motions between predefined poses. OMPL is used through MoveIt! to generate feasible joint trajectories. The generated trajectories are then sent to Gazebo through joint controllers and gazebo_ros_control. PID controller parameters are adjusted to reduce slow response and overshoot during target tracking.

The original contact-only behavior in Gazebo was not sufficiently stable for transporting the small object in this setup: small pose errors, limited contact area, friction/inertial mismatch, or controller oscillation can produce slip or loss of contact. gazebo_grasp_fix is therefore used after its contact condition is satisfied. The plugin creates a deterministic attachment to a gripper-related link, which prevents drops during the remaining stages but removes slip, force-closure, payload-coupling, and regrasp behavior from the transport phase. Thus, the Gazebo implementation is suitable for testing planning and controller sequencing, not for learning or validating a low-level physical grasp policy.

The Unity implementation uses the same xArm Lite6 URDF model. The model is imported through the Unity Robotics URDF Importer, which reconstructs the link hierarchy, mesh references, and joint structure. Each robot joint is represented using Articulation Body, which is more suitable than ordinary Rigidbody components for serial-chain robot structures.

The task sequence is controlled by C# scripts. The script defines staged joint targets corresponding to the approach, grasp, lift, transfer, lower, and release stages. During execution, joint target positions are interpolated to reduce abrupt changes in motion. This makes the Unity implementation a scripted reproduction of the task rather than a planner-driven trajectory-generation workflow.

The Unity grasping mechanism is also deterministic. A spherical trigger is placed near the gripper; when the object enters the region and the grasp stage is active, the object becomes a child of a GrabPoint or gripper transform. Parenting guarantees pose following until release but bypasses contact-force, friction, slip, payload inertia, and force-closure constraints. Trigger radius and timing therefore become hidden task parameters: an oversized trigger can capture an object before valid contact, a small trigger can miss a valid grasp, and a parenting or Rigidbody-state error can cause penetration, discontinuous velocity, or an incorrect release pose.

As shown in Figure 1, both implementations start from the same URDF/Xacro model but diverge in their execution pipelines. Gazebo uses ROS Noetic, MoveIt!/OMPL, joint controllers, and gazebo_grasp_fix, whereas Unity uses the URDF Importer, Articulation Body joints, and staged C# targets.

Both implementations completed the predefined six-stage sequence, giving C = 6/6 for Gazebo and C = 6/6 for Unity. In Gazebo, MoveIt!/OMPL generated the robot trajectory and the ROS controller chain executed it, so P = 1 and R = 1. These values demonstrate the presence of an integrated planning-and-execution path; they do not measure path optimality, controller accuracy, or real-robot success.

Gazebo completed object transport only with plugin-assisted stabilization in the submitted implementation, giving A = 1 and F = 0. Contact-only behavior could lose the object, while gazebo_grasp_fix removed this failure by attaching it after the contact condition. Figure 2 documents the initial, approach/grasp, lift/hold, and transfer/release states. Because no paired repeat-run logs were supplied, the revision does not assign a numerical improvement to the plugin; the required paired comparison is defined in Section 4.4.

Unity also completed all six stages (C = 6/6). The current prototype executed predefined interpolated C# targets rather than online planning or ROS-controller execution, giving P = 0 and R = 0. Object transport depended on trigger-based parenting, giving A = 1 and F = 0. Scene-level scripted interaction was present (I = 1). These indicators document implementation structure and repeatable task reproduction; they do not establish lower tracking error, higher physical grasp success, or a smaller Sim-to-Real gap.

Table 3 lists the implementation components that determine the audit indicators. The comparison is limited to the submitted prototypes: Gazebo combines an online planner and ROS controller chain with plugin-assisted transport, whereas Unity combines staged script targets with trigger-based parenting and scene-level interaction.

Table 4 reports the operationalized results. The equal completion value (6/6) shows that both prototypes reproduced the scripted task, but the remaining indicators show that they did so through different mechanisms. In particular, A = 1 and F = 0 for both platforms, so completion cannot be interpreted as evidence of physically robust grasping.

For gazebo_grasp_fix, a policy or task controller can appear successful after the plugin converts a contact event into a rigid attachment even when the real gripper would not achieve sufficient normal force, friction margin, or force closure. Direct deployment to an xArm Lite6 can therefore fail under jaw-pose error, uncertain friction, object compliance, mass-distribution error, controller delay, or acceleration-induced slip. The plugin is appropriate when the research question begins after grasp confirmation, such as testing collision-free transfer or task sequencing; it is not appropriate when grasp acquisition, holding force, or slip recovery is the research target.

Unity parenting creates a stronger abstraction boundary: the object pose is kinematically inherited from the GrabPoint, so payload-dependent torque, contact impulse, slip, rebound, and release velocity are not learned or validated. A controller tuned in this state can fail on hardware because the real arm must accelerate the payload, maintain contact during motion, and release with nonzero residual velocity. Parenting is therefore suitable for visualization, operator training, and state-machine validation, but a Sim-to-Real control study should retain Rigidbody dynamics, model gripper contact, randomize mass/friction/compliance, and validate the resulting command sequence on hardware [12]-[15].

For both platforms, attachment success must be logged separately from physical grasp success. A reproducible transfer study should define a grasp-success event from finger closure and object retention before attachment is enabled, then evaluate whether the same command survives randomized object pose, friction, mass, latency, and sensor noise. Without that separation, deterministic binding systematically underestimates the Sim-to-Real gap.

The reviewer-proposed Gazebo control experiment should use paired trials of (a) contact/friction-only grasping and (b) the identical task with gazebo_grasp_fix enabled. The robot model, controller gains, trajectory, object model, initial pose, physics step, random seed, and stopping criteria must be held constant. A minimum of 30 paired trials per condition is proposed to estimate uncertainty; each pair should use the same randomized object pose and friction/mass sample.

The current submission package does not contain the repeat-run logs required to populate Table 5 with measured outcomes. The table is therefore a prospective ablation protocol, not a report of completed trials. This evidence boundary is stated explicitly so that the 6/6 stage-completion audit is not misrepresented as a statistical performance comparison.

Platform selection follows from the audited mechanisms rather than from visual adjectives. The implemented Gazebo workflow has P = 1 and R = 1, so it directly exercises online planning and controller execution. It is therefore the relevant prototype when the research question concerns MoveIt!/OMPL integration, collision-aware planning, ROS command flow, or controller behavior. Its A = 1 and F = 0 values also limit any conclusion about physical grasp robustness.

The implemented Unity workflow has I = 1 but P = 0 and R = 0. It is therefore useful for interactive scene reproduction, operator-facing visualization, and task-state demonstration, while the current scripted prototype cannot validate online motion planning or ROS-controller behavior. Unity could address this boundary by receiving the same ROS/MoveIt command source through ROS-TCP-Connector and by replacing parenting with contact-governed transport when physical grasp validity is required.

The equal completion ratio does not make the two platforms interchangeable. Both have A = 1 and F = 0, meaning that deterministic binding―not verified contact mechanics―ensures object retention. The benchmark therefore supports claims about workflow integration and task reproduction only; force closure, slip margin, grasp success under perturbation, and hardware transfer require the controlled and physical experiments described above.

For a conference submission, reproducibility is strengthened by clearly separating platform-dependent implementation details from platform-independent task settings. The task settings include the robot model, initial pose, target object, grasping pose, placing pose, and stage order. These settings define the benchmark goal and should remain consistent across platforms. The implementation details, however, are allowed to differ because they reflect the normal development workflow of each platform. In Gazebo, reproducibility depends on the ROS package versions, MoveIt! configuration, controller parameters, Gazebo world file, and grasp-fix plugin settings. In Unity, reproducibility depends on the URDF Importer version, Articulation Body drive parameters, collider settings, C# script values, object detection radius, and parenting logic.

This separation also makes the comparison useful for later extension. If future experiments introduce physical hardware, the Gazebo workflow can be used to transfer planned joint trajectories to the real robot, while the Unity workflow can be used to build an interactive monitoring or demonstration interface. If the two platforms are connected through ROS-TCP-Connector or a similar bridge, the same motion command source could drive both the algorithmic simulator and the visual digital-twin scene. Such an integrated setup would provide a stronger basis for evaluating the Sim-to-Real gap.

Gazebo can fail before grasping when MoveIt! cannot find an inverse-kinematics or collision-free solution, when joint limits or URDF collision geometry are inconsistent, or when the planned trajectory is not accepted by the configured controller. During execution, poorly tuned PID gains or a mismatch between controller rate and physics step can cause lag, overshoot, or oscillation. During grasping, low friction, inaccurate inertial parameters, sparse collision geometry, or an unfavorable contact normal can cause slip. gazebo_grasp_fix can itself produce false attachment when the contact threshold is too permissive or missed attachment when contacts are intermittent; detachment thresholds can also release the object too early or keep it attached after the intended release.

Unity can fail during import when joint axes, hierarchy, mesh scale, collider geometry, or center-of-mass settings do not match the URDF. Articulation drives can oscillate or lag when stiffness, damping, force limits, or fixed timestep are inconsistent. Because the motion sequence is scripted, an object-position change or unexpected collision is not replanned and can make the gripper miss the target. The spherical trigger can bind an object without valid finger contact or fail to bind because the radius/timing is too small. Parenting while Rigidbody state is inconsistent can create interpenetration, velocity discontinuity, tunneling, or an incorrect release trajectory. These limitations are specific engineering conditions that must be checked in addition to whether the animation reaches the final state.