We all know the pain points with discrete time-stepping (Δt):
Large Δt → tunneling, jitter, non-physical artifacts
Small Δt + sub-stepping → accurate but massive performance hit in large-scale RL training
Current workarounds (more iterations, sub-stepping, tuning magic parameters) help, but don’t address the root cause.
I’ve been exploring a fundamentally different approach: a continuous-time solver that removes discrete stepping entirely, using a unified spacetime representation with adaptive compute density.
Key claimed benefits:
Mathematically enforced causality → zero tunneling even at moderate rates
Automatic precision scaling (high during collisions, low during stable motion)
Designed as a drop-in wrapper around existing rigid body states
Open-source prototype (TinyOEKF, C/Python):
Full paper (with derivation & proofs):
Would love feedback from the physics/simulation team — especially if NVIDIA has internal research on non-discrete or manifold-based integrators.
Happy to discuss benchmarks, integration paths, or potential collaboration on next-gen continuous simulation extensions.
Hi @liuzc19761204, thank you for sharing your work and this is definitely an important problem to solve. Have you already tried to implement this algorithm with fixed-step simulators like PhysX or Bullet to validate the idea? Are there results you may be able to share?
Thank you for the response and for recognizing the importance of the problem!
To answer your questions:
The current open-source prototype (TinyOEKF) is primarily validated in state estimation and sensor fusion contexts, where the continuous algebraic approach already shows clear benefits in causality enforcement and multi-scale handling.
We have not yet completed full benchmarks against fixed-step engines like PhysX or Bullet in complex Isaac Sim scenes — that’s exactly the next phase we’re actively working on.
We’re very eager to share preliminary results as soon as they’re ready.
If the Isaac Sim / Omniverse physics team is interested, I’d be thrilled to discuss potential integration paths, share more detailed comparisons, or even explore collaborative validation using Isaac Sim scenarios.
Thank you @liuzc19761204. It would definitely be interesting to see your benchmark results. In the meantime, I can let the physics team know and point them to the open source prototype.
To provide context on our progress: we recently identified that the entire Physical AI stack—from simulation platforms to models like Transformers and Diffusion—is hitting a fundamental dead-end. Relying on discrete time-steps （Δt) and probabilistic fitting to approximate a continuous world leads to an exponential explosion in compute requirements, ultimately hitting a “Compute Wall.” , we call this the “Architectural Original Sin.” Attempting human-level perception via discrete sampling requires massive energy (approx. 5000W), which is the primary bottleneck for deploying high-fidelity AI on edge robotics.
Because our current R&D resources are fully committed to building an algebraically exact physics engine on FPGA to solve this “Power Wall” at the hardware level, we have not prioritized software-only benchmarks for Isaac Sim.
However, since this energy/causality bottleneck directly impacts the future of autonomous systems and simulation fidelity, we have verified that our OEKF can be rapidly deployed as an “External Node” in Isaac Sim for independent validation. This allows your team to witness the “Causal Lock” without modifying your core engine: Rapid Validation Workflow for Isaac Sim
Data Input: Native Sensor Integration
• Sensors: Add an IMU Sensor (200Hz) and a GPS Sensor (10Hz) to the robot body in your scene.
• Bridge: Use the ROS 2 Bridge plugin to publish sensor_msgs/Imu and sensor_msgs/NavSatFix to /isaac/sensor/imu and /isaac/sensor/gps.
OEKF Node: Lightweight Integration
• Dependencies: C++ (recommended) or Python; requires rclcpp, TinyOEKF, and octomath.
• Logic: Subscribe to the topics above. Map IMU velocity/acceleration to z_imu (Attitude) and GPS to z_pos (Position). Call the core “Predict-Update” functions from our library.
Output: Control Feedback Loop
• Parsing: Map the output Octonion into Roll/Pitch/Yaw (i_0-i_2) + X/Y/Z (i_3-i_5) + Causal Coupling Intensity (i_6).
• Control: Publish to /isaac/control/odometry for closed-loop stability control (e.g., high-speed drone maneuvers).
Performance Metrics (High-Dynamic Testing)
• Scenario: High-speed drone flip + obstacle avoidance.
• Expected Metrics: OEKF position error (vs. Traditional EKF )—a >60% reduction. It eliminates attitude jitter by accurately capturing the “Rotation Translation” causal dependency.
Cross-Platform: This logic is platform-agnostic. Adapting it for LeRobot involves only a simple topic remapping—enabling “One Algorithm, Dual Platforms.”
We believe this algebraic mechanism is a vital primitive for the next generation of world models. I strongly urge you to forward this and the attached whitepaper to your senior scientists and physics leads. If your team confirms these results and is interested in discussing how this “Causal Lock” can bypass the Compute Wall for NVIDIA’s future robotics stack, please contact me directly at: liuzc19761204@gmail.comTinyOEKF/docs/Continuous_Physics_Solver_for_AI_Wang_Liu.pdf at master · ZC502/TinyOEKF
I will pass the word along. Since there is no issue to be resolved for this posting, I will close the issue for now to keep the forums organized. Feel free to open a new topic in the future if there is anything else you would like to share. You can also use this channel to open long thread discussions: isaac-sim/IsaacSim · Discussions · GitHub
