PAL Robotics TIAGo++ Omni: Omnidirectional Platform

• PAL Robotics TIAGo++ Omni is a mobile manipulator featuring a mecanum-wheeled omnidirectional base, dual arms, and integrated simulation in Isaac Sim.
• It employs both a physically accurate wheel and roller collider model and a lightweight velocity-based approach to replicate real-world S-shaped acceleration profiles.
• The platform’s ROS 2 interfacing and sensor integration enable advanced research in tactile reinforcement learning, whole-body motion transfer, and LLM-based task planning.

PAL Robotics TIAGo++ Omni is a mobile manipulator in the TIAGo family whose most explicit arXiv treatment describes it as a dual-arm platform with a mecanum-wheeled omnidirectional base and presents its public integration into Isaac Sim. In the literature considered here, the platform is characterized primarily through simulation-oriented modeling of omnidirectional drive dynamics, ROS 2 interfacing, and calibration against real robot trajectories. Related TIAGo-family papers expand the context through tactile reinforcement learning, whole-body motion transfer, and LLM-based task planning, but they also make clear that many TIAGo results concern differential-drive or manipulation-only abstractions rather than an exact TIAGo++ Omni model (Schoenbach et al., 11 Oct 2025).

1. Platform definition and position within the TIAGo family

The TIAGo++ Omni is presented as a versatile mobile manipulator equipped with a mecanum-wheeled base that allows omnidirectional movement. The most direct platform-specific contribution in the available arXiv record is the introduction of a public Isaac Sim integration, motivated by the absence of a TIAGo++ Omni model in Isaac Sim prior to that work and by the difficulty of reproducing the robot’s base behavior in simulation because mecanum wheel contact is physically complex, the original base controller is effectively a black box, and the real robot exhibits S-shaped acceleration and velocity profiles rather than immediate velocity jumps (Schoenbach et al., 11 Oct 2025).

This characterization distinguishes TIAGo++ Omni from other TIAGo-family research platforms. Some TIAGo studies focus on the TIAGo service robot with a sensorized gripper in PyBullet, some on a differential-drive TIAGo used for whole-body imitation, and some on a simulated Tiago or Tiago Lite in Webots for LLM-based planning. The available literature therefore supports a family resemblance across TIAGo variants, but not the assumption that all TIAGo papers are omni-base papers. A recurring implication is that TIAGo++ Omni should be treated as a specific omnidirectional member of a broader research lineage, not as a generic label for all TIAGo experiments.

2. Isaac Sim integration and system-level representation

The Isaac Sim integration imports the non-wheel parts of TIAGo++ Omni via the Isaac Sim URDF importer, explicitly including the torso, arms, fingers, and head. Joint control is handled using ROS 2 together with the Isaac Sim API: joint state messages are exchanged, and trajectory commands are converted into sequences of joint-state-like updates for synchronization. Sensor integration is described as straightforward: LiDAR and cameras are added using Isaac Sim’s built-in sensors, their data can be published to ROS 2, and example RViz 2 visualizations and transform trees are provided (Schoenbach et al., 11 Oct 2025).

Within this integration, the principal modeling challenge is not the articulated upper body but the omnidirectional base. Gazebo’s TIAGo model is described as approximating the omnidirectional drive rather than truly simulating it, and the imported URDF in Isaac Sim is likewise insufficient for a faithful mecanum implementation. The resulting architecture therefore separates the robot into a relatively standard articulated subsystem and a custom base subsystem. This division is significant because it locates the novelty of the TIAGo++ Omni model less in arm kinematics than in drive dynamics and command-transition behavior.

3. Omnidirectional base modeling with mecanum wheels

The Isaac Sim work introduces two distinct control models for the TIAGo++ Omni base. The first is a physically accurate model that explicitly simulates mecanum wheels and roller-ground interactions and is intended for faithful dynamics. The second is a lightweight velocity-based model that directly sets the robot base velocity in Isaac Sim, uses a learned S-curve profile to smooth command transitions, and is intended to be computationally cheaper and better suited to learning-based robotics (Schoenbach et al., 11 Oct 2025).

The physically accurate model is built around three elements: wheel modeling, roller collider modeling, and holonomic controller implementation. The URDF wheels are replaced by procedurally generated mecanum wheels using a script from prior work. Each wheel has 15 free-spinning rollers, the roller angle is 45 degrees, and the wheel geometry is scaled to match the real robot. For roller-ground contact, each roller collider is modeled using six spheres, explicitly as a compromise between computational efficiency, smooth motion, and sufficient contact realism for lateral driving. The paper emphasizes that roller alignment and circular wheel shape matter because misalignment can cause intermittent loss of contact and unrealistic jumping.

Base control is expressed through Twist commands consisting of linear velocities $v_x$, $v_y$, and angular velocity $v_\theta$. With wheel radius $r$ and distances $L_x, L_y$ from the robot center to the wheel along the $x$ and $y$ axes, the inverse kinematic mapping is:

$$\begin{bmatrix} \omega_1 \ \omega_2 \ \omega_3 \ \omega_4 \end{bmatrix} = \frac{1}{r} \begin{bmatrix} 1 & 1 & -(L_x + L_y) \ 1 & -1 & (L_x + L_y) \ 1 & -1 & -(L_x + L_y) \ 1 & 1 & (L_x + L_y) \end{bmatrix} \begin{bmatrix} v_x \ v_y \ v_\theta \end{bmatrix}.$$

The literature is explicit that this matrix equation alone is insufficient. It describes only idealized velocity conversion, whereas the real TIAGo++ Omni does not behave like instantaneous wheel-speed execution. Instead, the real controller produces S-shaped velocity profiles, wheel speeds ramp up smoothly, the exact internal controller is inaccessible, and simple PID tuning in Isaac Sim did not match real behavior. The key modeling problem is therefore not only omni-base kinematics but also the transition dynamics between commands.

4. Learned S-curve calibration and empirical fidelity

To approximate the real robot’s transition dynamics, the Isaac Sim study defines an S-shaped function

$$S_{\Theta}:\mathbb{R}_{\ge 0} \rightarrow \mathbb{R}_{\ge 0},$$

where $\Theta$ parameterizes the trajectory shape over time, and a network learns a mapping from wheel velocity, or in runtime use a velocity change $v_y$0, to those parameters. The learned S-curve is explicitly three-part rather than logistic because the recorded profiles are asymmetric: a steep initial rise, a smoother approach to target, and a linear-like middle segment. The parameterization is

$v_y$1

with transition points $v_y$2, linear slope $v_y$3, and sharpness parameters $v_y$4. The ramp-like functions are implemented using softplus, and the continuity constraints enforce matching at $v_y$5 and $v_y$6, asymptotic slope consistency, $v_y$7, and $v_y$8 (Schoenbach et al., 11 Oct 2025).

The parameter predictor is a small MLP with architecture $v_y$9 and softplus activations between layers. Training uses Adam; 100 random initializations are trained, and the model with the lowest validation error is selected. The training data consist of real wheel velocity recordings from simple $v_\theta$0-direction movement, $v_\theta$1-direction movement, and rotational motion about $v_\theta$2. A crucial evaluation choice is that diagonal $v_\theta$3-$v_\theta$4 motions are not included in training and are instead reserved for generalization testing.

Runtime command interpolation uses a conservative bound on per-wheel velocity change. The appendix gives

$v_\theta$5

$v_\theta$6

$v_\theta$7

and

$v_\theta$8

The commanded base velocity is then updated as

$v_\theta$9

This makes the command follow a learned time profile rather than an instantaneous step.

Real-robot calibration and evaluation are performed using open-loop trajectories. Pose is measured with OpenVR using a VIVE tracker mounted at the robot’s rotational center and two VIVE lighthouses for triangulation. The dataset includes 20 target velocities, linear commands from 0.05 to 1.00 m/s, rotational velocities from 0.05 to 1.5 rad/s, and motions in $r$0, $r$1, diagonal $r$2-$r$3, and rotation about $r$4. Each command lasts 4 seconds, is repeated 3 times, and the resulting profiles are averaged. Relative error is defined as

$r$5

with reported mean relative error (MRE) and standard deviation (STDRE).

Model	Motion	MRE $r$6 STDRE
Physically accurate / full	x-direction	$r$7
Physically accurate / full	y-direction	$r$8
Physically accurate / full	x-y-direction	$r$9
Physically accurate / full	rotation	$L_x, L_y$0
Lightweight	x-direction	$L_x, L_y$1
Lightweight	y-direction	$L_x, L_y$2
Lightweight	x-y-direction	$L_x, L_y$3
Lightweight	rotation	$L_x, L_y$4

These results are described as showing that both models track real behavior reasonably well, with the lightweight model often slightly better or comparable. The lightweight controller also reduces the required physics step rate from 360 to 60 steps per second. At the same time, the paper identifies a persistent mismatch for non-axis-aligned motions: the real controller does not always enforce proportional acceleration across wheels, the real robot may drift slightly during acceleration, and the simulation often produces smoother cornering than hardware. The reported interpretation is that this discrepancy is acceptable for many open-loop experiments and may even introduce robustness-relevant variation for learning.

5. Adjacent TIAGo-family research relevant to TIAGo++ Omni

A substantial part of the technical context for TIAGo++ Omni comes from TIAGo-family work that is relevant but not platform-identical. In tactile manipulation, the paper on “TIAGo RL” introduces open-source reinforcement-learning environments for the TIAGo service robot in PyBullet, centered on a sensorized gripper with TA11 load cell sensors and designed to make simulated tactile signals resemble real sensor output for sim-to-real transfer. The package comprises three base environments—TIAGoTactileEnv, GripperTactileEnv, and TIAGoPALGripperEnv—and uses desired joint velocities as actions, a force-tracking reward, and TD3 for preliminary grasp-force control. The work is directly relevant to TIAGo-family manipulation benchmarking, especially for tactile grippers, but it explicitly does not mention TIAGo++ Omni by name and does not describe any omni-base-specific chassis or control policy (Lach et al., 2023).

In whole-body imitation and safe physical interaction, “Human to Robot Whole-Body Motion Transfer” presents a framework validated on the TIAGo robot, using real-time inertial motion capture, a correspondence mapping from observed human posture to robot Cartesian goals, a task-prioritized whole-body controller, a differential-drive base imitation controller, and a variable admittance controller for switching between stiff and compliant end-effector behavior during contact. The validated platform has a differential-drive base, torso lift, 7-DOF arm, and wrist force sensing, and the paper reports real-world experiments on TIAGo with 10 DOF excluding the head. For TIAGo++ Omni, the correspondence mapping and whole-body control concepts are directly informative at the mobile-manipulator level, whereas the differential-drive base controller is not an omni-base controller. A plausible implication is that the upper-body retargeting and admittance components transfer more directly than the base imitation law (Arduengo et al., 2019).

In task planning with LLMs, “Investigating the Effectiveness of a Socratic Chain-of-Thoughts Reasoning Method for Task Planning in Robotics, A Case Study” uses a simulated Tiago or Tiago Lite robot in Webots R2023b via the Webots ROS2 package for an object-search task. The simulated robot is differential-drive, equipped with an odometer, two wheels, one Astra Depth camera on the head, and one Hokuyo Lidar on the chassis, and it is controlled through ROS2 Twist messages. The paper compares Non-CoT/Non-SocraCoT, CoT only, and SocraCoT, where SocraCoT uses four LLM roles—LLM_A, LLM_B, LLM_C, and LLM_D—for subtask generation, Socratic critique, code generation, and strict code review. Its relevance to TIAGo++ Omni is therefore conceptual rather than kinematic: it is a proof of concept for zero-shot, non-fine-tuned LLM-based planning and controller synthesis on a TIAGo-family simulation, but it is not an omni-base implementation and does not support one-to-one transfer of the motion model (Bot et al., 11 Mar 2025).

6. Research uses, limitations, and recurring misconceptions

The TIAGo++ Omni literature positions the platform as useful for reinforcement learning with mobile manipulators, sim-to-real transfer studies, trajectory tracking in complex environments, synthetic data generation, and sensor-based robotics research in Isaac Sim (Schoenbach et al., 11 Oct 2025). Within that usage spectrum, the two base models serve different methodological roles. The physically accurate model is intended for cases where wheel-ground interactions matter or validation against real motion is required. The lightweight velocity-based model is intended for throughput-sensitive applications, including large-scale rollouts, because it avoids roller contact computation and wheel-joint tuning while preserving the learned S-shaped acceleration profile.

The literature also imposes clear limits. The Isaac Sim evaluation is open-loop only; wheel acceleration behavior is only approximated; non-axis-aligned motion is less accurately captured; the exact real controller remains unknown; and some real robot motion patterns may be too idiosyncratic to reproduce fully (Schoenbach et al., 11 Oct 2025). The tactile RL study shows a further cautionary pattern: a learned policy can improve simulation reward while failing to transfer to the real robot, in that case by bouncing the object back and forth between the fingers and exploiting the reward without achieving a stable grasp, leading the authors to conclude that the agent seemed to have overfitted to that particular training scenario (Lach et al., 2023). The Webots LLM study is likewise simulation-only, zero-shot, and not fine-tuned, and it explicitly reports continued problems in spatial perception, state estimation, object tracking, and distance measurement (Bot et al., 11 Mar 2025).

A common misconception is to treat any result on “Tiago” or “TIAGo” as if it were automatically a result on TIAGo++ Omni. The available papers do not support that simplification. The Webots task-planning study uses a differential-drive Tiago or Tiago Lite rather than an omni-base platform; the whole-body motion-transfer paper validates on differential-drive TIAGo and notes the nonholonomic limitation that side steps cannot be reproduced; and the tactile RL environments are manipulation benchmarks for TIAGo-family hardware rather than omni-specific base models (Bot et al., 11 Mar 2025). Another misconception is that accurate omni-base simulation is reducible to wheel kinematics alone. The Isaac Sim study rejects that view explicitly by showing that command-transition dynamics and S-shaped velocity ramps are central to reproducing real TIAGo++ Omni behavior (Schoenbach et al., 11 Oct 2025).

Taken together, these works define TIAGo++ Omni not merely as a mobile manipulator with omnidirectional kinematics, but as a platform whose research identity is increasingly shaped by simulator integration, learned calibration of base dynamics, and its relation to a wider TIAGo ecosystem of tactile manipulation, whole-body control, and language-conditioned planning. The strongest direct evidence concerns omnidirectional base simulation in Isaac Sim; the broader TIAGo literature supplies transferable ideas and cautionary counterexamples, but only with careful attention to the distinction between omni-base, differential-drive, and manipulation-only settings.