Real-Time Capability of Rigid Body Vehicle Model on Rigid Terrain
Stefan Oberpeilsteiner
Dear Chrono Team,
I am currently implementing a simplified tractor model in Chrono for use in a real-time simulation environment. The model consists of a rigid chassis, a fixed rear axle with steered and driven wheels, and a front axle modeled as a rigid beam suspended via a central pivot (as commonly used in tractor front axles) with additional steering. The goal is to capture the essential dynamic behavior of the vehicle—particularly in heave, pitch, and roll—sufficiently well for deployment on a motion platform.
The vehicle operates on a rigid, non-deformable terrain, represented by a tessellated triangular mesh. The primary excitation arises from terrain-induced vertical disturbances with dominant frequency components up to approximately 10 Hz.
My core question is:
What is the expected feasibility of running such a model in real time using Chrono? In particular:
-
Are there benchmarks or best practices for achieving stable simulation at control loop frequencies ~1 kHz?
-
Which solver/integrator is recommended for this type of setup?
-
Are there known performance bottlenecks when using non-deformable terrains modeled as triangular meshes?
Any insights—especially from prior experience with real-time vehicle simulation or motion cueing applications—would be highly appreciated.
Best regards,
Stefan Oberpeilsteiner
Dan Negrut
Hi Stefan – here’s an example of real-time simulation using Chrono: https://thelastgarage.com/ .
Disclaimer: the link above is not to a “one afternoon” project, but what you want is very likely possible.
As about your three questions, I would start with the defaults in Chrono and then tweak the model parameters to get the level of performance you need.
Dan
---------------------------------------------
Bernard A. and Frances M. Weideman Professor
NVIDIA CUDA Fellow
Department of Mechanical Engineering
Department of Computer Science
University of Wisconsin - Madison
4150ME, 1513 University Avenue
Madison, WI 53706-1572
---------------------------------------------
--
You received this message because you are subscribed to the Google Groups "ProjectChrono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
projectchron...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/projectchrono/ddfef702-fd37-4479-aceb-72186eeac1f0n%40googlegroups.com.
Marcel Offermans
Hello Stefan, Dan,
Let me chime in here as that's "my" project. It indeed uses Chrono to run real-time vehicle physics (with a lot of work on top as well as Dan mentions, I've been working on this full-time for over three years now).
Let me answer your questions though:
As to how to achieve "stable" simulation at 1000 Hz (to be honest, you don't always need 1000, 500 might be fine too, but that's another discussion), what I've done is completely removed the graphics rendering from the core simulation loop as a first step: you certainly don't need to render every 1 ms, most GPUs won't be able to keep up with that, no monitors can. So decouple that and make a physics loop that does just that: calculate the physics. Well, there is one other thing you want to do there and that's read controller inputs (and possibly provide force feedback effects to wheel and pedals). Then you simply need that thread to keep up with real-time and pace it as well as you can. Most modern computers will be fast enough. Most operating systems you run this on won't be (hard) real-time OS'es and that means you have to settle for a "best effort" synchronization with time. In practice that is very do-able though in my experience.
As for the solver, I agree with Dan's feedback, start with the defaults. I found them pretty good.
As for performance bottlenecks on a non-deformable, triangulated mesh, I would say you might run into some bottlenecks there if you end up with a big mesh, but like so many things in Chrono, the "tire vs mesh" interaction is something you can optimize and plug in your own implementation and there are many ways to replace what's there now with something more specialized for your use case.
All in all I would say what you're trying to do is certainly feasible. Chrono is a great platform for this.
Greetings, Marcel
Stefan Oberpeilsteiner
Dear Dan, Marcel,
Thank you both for your responses.
Dan – I truly appreciate the pointer to The Last Garage. It’s an impressive piece of work, and I fully understand that such results are the outcome of sustained effort—not something to be achieved in a short afternoon. I certainly don’t underestimate the complexity involved in building robust real-time simulations.
Marcel – your practical insights are very helpful, especially the emphasis on decoupling rendering from the physics loop. That’s indeed the architecture we follow as well.
In our case, the 1 kHz target is not due to fast motion dynamics, but rather stems from the requirements of the motion cueing system and real-time hardware integration. While we employ classical motion cueing algorithms (e.g., washout filters and tilt coordination), which operate in the lower frequency range (typically below 10 Hz), the simulation loop needs to run at high frequency to ensure low-latency signal delivery and stable control of the motion platform. Our setup involves full dynamic simulators with a human operator onboard, so the control interface must respond smoothly and predictably to external disturbances.
By way of background: I’ve been developing simulation software myself for many years and have been involved in scientific research in multibody dynamics and real-time applications. We’ve developed our own simulation kernel that achieves real-time performance for rigid MBS, but it currently lacks in tire modeling and terrain interaction. This is where Chrono appears promising—especially due to its open architecture and extensibility.
Your replies have given me the confidence that a prototype based on Chrono is a worthwhile path forward. I’m particularly interested in exploring how customizable the tire-terrain interaction can be for our application.
Thanks again for your openness and support.
Best regards,
Stefan Oberpeilsteiner
Radu Serban
Hi Stefan,
Let me provide a little bit more background and details on this.
Decoupling the physics and rendering in two separate threads or processes is common practice, especially in the gaming industry. Since you already do that, I will not elaborate further.
Regarding simulation of (wheeled) vehicle-terrain with Chrono, please keep in mind that Marcel is only using the so-called “handling tire models” available in Chrono::Vehicle (Pacejka, TMEasy, TMSimple, Fiala). What all these models have in common is that the only information they need from a terrain system is the terrain height and normal at a point on the terrain below a query point (Chrono::Vehicle provides several options, using 1, 4, or more query points in order to establish the tire-terrain geometric relationship). Identification of the point on the terrain corresponding to a query point is done by casting rays from the query point(s) into the (collision) terrain surface.
In Chrono::Vehicle we did not special-case a mesh that is used to represent a rigid terrain. Instead, we use a “generic” Chrono collision mesh which can also be used for the typical Chrono collision and contact interactions. What we suggested to Marcel and what he did in his simulator was to specialize meshes that represent a terrain, taking advantage of the characteristics of these meshes (e.g., the fact that they are mostly “flat” and as such, one can implement an efficient broad phase (e.g., using binning in the “horizontal plane”) for ray casting that quickly discards most mesh triangles as intersection candidates.
I contemplated implementing this type of optimization in Chrono::Vehicle. The problem for us is that we also have other tire models available (e.g., rigid tires and FEA-based tires) which rely on the underlying Chrono contact formulation to generate the tire-terrain forces. That means that a specialization of terrain meshes would need to deal not only with ray casting, but also collision detection against arbitrary collision models present in the Chrono system. That is doable but is not a very high priority.
Best,
Radu
To view this discussion visit https://groups.google.com/d/msgid/projectchrono/f9a30e4d-4643-4ed3-b82d-188d7c7fbd1dn%40googlegroups.com.