Tires Rotating Beyond Mechanical Limits

[Ted Sender]

Hello,

I am currently using Chrono for vehicle simulations with a polaris vehicle. I am using rigid tires on rigid terrain. I am noticing that with certain terrain profiles one or both of the front tires rotate very quickly beyond its mechanical limit when the vehicle drives over a harsh bump/dip.

These are the current settings I am using:

Solver: Barzilai-Borwein, tolerance 1e-6, max iters 400, time step 1 ms

Collision: Bullet, default suggested envelope 1 mm, default suggested margin 1 mm

Terrain: Rigid, coeff friction 0.6

I have tried using different solvers, but they did not seem to work (some just failed to perform the calculations or crashed the program). I tried lowering the time step from 1 ms to 0.2 ms, but that did not work either.

Attached is a video showing an example of the problem I am having. Right around t = 6 seconds, the front right wheel drives over a dip and then the wheel suddenly rotates clockwise well past its mechanical limit (the limit is about 0.48 radians, but the wheel rotates like 2 radians). 

I also logged some force/moment values to the terminal to see what was going on, thinking that it could have been a problem with the tire forces. Attached is a .txt file showing the tire's steering angle, tire force and torque values, and the applied force and torque to that wheel's spindle (I believe all forces/moments are expressed in the global frame).

From this data, it seems that when the tire has no reported force/torque, the spindle still has some applied force/torque. At t = 5.1 seconds, this occurs, but is not a problem as the spindle torque is rather small. However, at t = 5.90 seconds, the tire force is zero but the spindle torque starts to increase and then the wheel rotates beyond its limit.

Does this seem like a problem with the collision model/settings or is it caused by something else? Any help is greatly appreciated. I hope the data provided is helpful, but if you need some more values, let me know.

Thanks,

Ted

[Dan Negrut]

Ted – there was no video attached…

 

One thing that might be worth trying is to use SCM deformable terrain. If you have a couple of hours, give it a try – folks in our lab have had good success with that.

 

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

608 772 0914

http://sbel.wisc.edu/

http://projectchrono.org/

---------------------------------------------

--
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/38e5d8a2-5ccc-47bf-93cb-bb0f6ff6e327n%40googlegroups.com.

[Ted Sender]

Hi Dan,

I realized there was no video attached. The system wouldn't let me attach it for some reason and it said someone had to approve the post before I could edit it. Here is the video. Let me know if you have trouble viewing it.

I'd like to use SCM terrain, but I'm using someone else's setup that they provided to me and I have no idea how to get SCM to work.

Ted

[Ted Sender]

I wanted to give a brief update. I tried getting SCM terrain to work with the default settings. I think I set things up correctly by looking through the source code to see what I have to do. And I am STILL seeing this weird problem. The problem seems to be that when the tire force/torque is reported as zero, the wheel spindle torque can sometimes be non-negligible (on the order of hundreds in magnitude) and causes the wheel to rotate beyond its limit. It's like the applied torque to the spindle is as if the tire is in collision, but the collision hasn't occurred yet. That's my best guess.

I tried changing some of the collision parameters that I am aware of, but this had no effect whatsoever. Any help would be greatly appreciated.

Ted

[Ted Sender]

Hi Dan,

I created a minimally working example that will allow you and your team to see the exact problem I am experiencing. I am attaching a zipped file that contains two folders, a "src" folder for code and a "data" folder with some necessary data. You will need to create a build directory associated with the "src" folder.

The "data" folder provides a few vehicle control sequences and the associated terrain heightmap. "control_log_trial1.txt" contains a sequence of commands that pushes chrono right near its simulation capabilities in this scenario, but " control_log_trial2.txt" and "control_log_trial3.txt " push it over the edge completely as the front right tire rotates well past its mechanical limit while the wheel is not in contact with the ground. The code is preconfigured to run the "trial2" commands.

Usage Instructions:

1. At the top of the main() function you will see a code block that configures a few settings. Follow the instructions provided to configure the location of a few folders and select which control log file to use.

2. Build the code (you will need to create the build directory and configure it using cmake).

3. Run the build/Release/my_demo.exe file from a powershell.

Notes:

1. During part of this simulation, I print information regarding the right steering wheel so you can see the tire and spindle forces/torques and the actual steering angle. The timestamp on these print lines is off by 5 seconds from the actual simulation time, as the vehicle is "disabled" for the first 5 seconds of the simulation.

2. This code has only been tested on Windows 10

Other Instructions:

Use the "find" command and search for "INSTRUCTIONS". If you want to try this setup with SCM terrain instead of RigidTerrain, then follow the instructions at the other two INSTRUCTIONS code blocks.

Other things I have tried:

1. I tried all of the tire collision types: SINGLE_POINT, FOUR_POINT, and ENVELOPE, but they all produce the same error.

2. I still get the same result with SCM terrain.

Please let me know if you are able to find someone who can look into this issue and if they are able to observe this problem using the code/data provided.

Thanks,

Ted

[Dan Negrut]

Hi Ted,

One of our lab students, Harry Zhang (thanks, Harry), too a look at the material you sent.

For some reason he cannot post on the forum at this point, so I’ll convey the message from him.

 

Please take a look here: https://drive.google.com/file/d/1dEzGlTbs_n4dlS2QtM6juDvpV-aOtFTL/view?usp=sharing)  

1) Harry ran the same script as you did, for rigid terrain, and generated a movie out of it on his Linux machine. From the demo, we didn't spot abnormal behavior. Can you double check the video provided at the link above?

 

2) For SCM, one issue is that you are using a "TMEasy" tire while running the demo. That won’t work on SCM deformable terrain. SCM terrain typically (but not always) requires a rigid tire, e.g., "Polaris_Rigid.json" or "Polaris_RigidMeshTire.json" as json input. Harry attached a demo file that he wrote to reflect this. Maybe you want to modify your SCM part and use rigid tire during simulation. Or use Harry’s model and build off it. Note that you can also use a deformable tire via finite element, but that is an overkill. It’s not simple to set up, and it takes very long to finish a simulation. Given that your project aims at solving a controls problem, using rigid tires on SCM is adequate.

 

Good luck with your project.

 

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

608 772 0914

http://sbel.wisc.edu/

http://projectchrono.org/

---------------------------------------------

 

[Ted Sender]

Hi Dan and Harry,

Thank you very much for looking into this for me. I confirm I can view the videos/files in your zipped file.

I find it interesting that you did not observe any weird behavior. Harry, can you please confirm which control log file you used when making that video? Did you also test both the trial2 and trial3 files? Would it also be possible for you to show me the lines that my code prints to the console for both of those runs?

The current version of Chrono I am using is from late October or early November 2024 (no idea which version that would be). I've thought about trying the latest version (but someone else did the install for me and it was a pain to go through), but I couldn't tell from the github repo if anything related to the components to run this simulation have changed since then. Thoughts?

One other question, how did you get the camera to track the vehicle like that in the "demo_rigid" video?

Thanks,

Ted

[Ted Sender]

Two other things. 

1. Are you processing the terrain differently from me in that demo_rigid video? During this video frame below I can see weird ridges in the terrain which do not appear in mine. My terrain should look very smooth (see the video I uploaded in my second post).

2. Please watch the video I attached from my second post. As the front right tire drives over the depression in the ground (right after the hill), you will see that my tire drives through the center of that depression. But your tire appears to graze the side of it. Something is very different between what you are simulating and what I am simulating.

Thanks,

Ted

[Harry ZHANG]

Hey Ted,

1. After I tried running control_log_trail3.txt, the same problem happened for me. I need to take some time working on it before get back to you.
2. I didn't change the terrain generation part of the code, so I would assume in principle terrain should be same for both of the simulation. However, I saw that for both rigid and SCM terrain generation, you are converting point cloud data into mesh then initialize terrain based of mesh. I did similar terrain before (with crater and hill) but I directly use blender to draw a mesh, and create a terrain based of mesh. If it's easy for you to create your terrain using mesh, I would recommend trying it out. 
3. For camera angle, I am using ChWheeledVehicleVisualSystemIrrlicht. While simulation is running, you can drag the visualization window to change angle. But if you want to define specific camera locations and camera point locations, you can do so using ChVisualSystemIrrlicht, couple examples in the repo demonstrate it. 

Thanks for the follow up, will get back to you asap.

Best,

Harry

4. 
   
   
   

---

From: Ted Sender <tse...@umich.edu>
Sent: Monday, January 20, 2025 10:12 PM
To: Dan Negrut <neg...@wisc.edu>
Cc: ProjectChrono <projec...@googlegroups.com>; Harry ZHANG <hzha...@wisc.edu>

[Harry ZHANG]

Hey Ted,

Other few things that worth trying at this point I can think of are:
1. Try to play around with Solver settings and step size. 1e-3 might be too big for time step,.

2. Try to see if the control inputs given to driver could be smoothed. E.g. Don't have too big of jump for the adjacent control input. 

Could you please try out really quick and let me know how it goes? 

Best,

Harry

---

From: Harry ZHANG <hzha...@wisc.edu>
Sent: Tuesday, January 21, 2025 9:52 AM
To: Ted Sender <tse...@umich.edu>; Dan Negrut <neg...@wisc.edu>
Cc: ProjectChrono <projec...@googlegroups.com>; Radu Serban <ser...@wisc.edu>

[Ted Sender]

Hi Harry,

Thank you for following up. I am glad you were able to see the issue with at least one of those control logs.

Due to how part of my setup works, it's just much easier to create the mesh directly from the raw point cloud data. but my point cloud is generated to be rather smooth and so I figured it shouldn't be an issue.

I did test smaller step sizes a few weeks ago. I went down to 0.2ms but the issue still occurred. I also tried other solvers and lowering their tolerances and increasing the max solve iterations, but nothing worked.

The control inputs being given to Chrono should already be fairly smoothed. The controller in my setup has a maximum rate at which steering and throttle can change, but I can double check to see if anything else funky could be going on. I have checked the steering commands in that crater area and the steering command is not erratic in any way. Will check the throttle/braking later today in that one section.

Let me know what you find.

Thanks,

Ted

[Ted Sender]

Hi Harry,

I am just following up to see if you were able to identify the issue or find a potential fix? Nothing on my end seems out of the ordinary. Also, the Chrono version I am using is 9.0.1.

Thanks,

Ted

[Harry ZHANG]

Hi Ted,

Could you please tell me if your end goal for the Chrono simulation is to control vehicles operating on deformable terrain (SCM)? If this is the case, I can check if the SCM terrain simulation works fine or not. I would rather help with that, instead of debugging the rigid terrain, which might be time consuming only to have you move on to SCM. 

 

Best,

Harry

---

From: Ted Sender <tse...@umich.edu>
Sent: Sunday, January 26, 2025 1:00 PM
To: Harry ZHANG <hzha...@wisc.edu>
Cc: Dan Negrut <neg...@wisc.edu>; ProjectChrono <projec...@googlegroups.com>; Radu Serban <ser...@wisc.edu>

[Ted Sender]

Hi Harry,

I can sort of go both ways with this. The original setup some of my colleagues gave me uses rigid terrain with the TMeasy tires, and so the easiest thing on my end is to just keep using that setup. However, using SCM terrain would be more realistic,  but I have no idea what parameter values I would need to use and how to connect them to a coefficient of friction. If I use deformable terrain, then I would want to use terrain that resembles sandy loam. The trajectory planner I'm using makes no assumption of soft soil and just uses a ground surface coefficient of friction as it plans a route, so I will need to check with my colleagues if they think their planner will still work reasonably in this setup. I will have to get back to you on this.

In the meantime, if you are able to quickly/easily determine if SCM terrain will work, then you can go ahead and let me know. I will get back to you if I truly do need rigid terrain.

Thanks,

Ted

[Ted Sender]

Hi Harry,

I would like to pursue both rigid terrain and SCM terrain. My colleagues said that deformable terrain might work with their setup, but they have not fully tested it. If you can get SCM terrain to work with that example, then I'd like to know what you did so I can try it out. Is the primary thing I need to change just to make sure I'm using rigid tires on SCM terrain?

However, I still would like to know if the rigid terrain can be fixed. I am told by my colleagues that this problem existed in older versions of Chrono and was mostly fixed, but as I found out recently, this problem is still around. Are you able to look into this at least a little bit, or perhaps determine how difficult it would be to address?

Thanks,

Ted

[Ted Sender]

Hi Harry,

For a quick update, my team said using deformable terrain should actually be fine. The primary thing I would like to ask from you is if you know where I could find reasonable parameters for the SCM terrain to represent different types of soil? I am more interested in slightly deformable soil. Are the default parameters good for this?

Thanks,

Ted

[Harry ZHANG]

Hey Ted,

You can check this link where we used to make SCM demo for different levels of softness of terrain: https://github.com/harryzhang1018/Chrono_Playground/blob/0b42260af4fc80912520f3f40a18752bba08b71c/trackVehObsAvoidance/demo_ROS_M113_train.cpp#L162

Chrono_Playground/trackVehObsAvoidance/demo_ROS_M113_train.cpp at 0b42260af4fc80912520f3f40a18752bba08b71c · harryzhang1018/Chrono_Playground Contribute to harryzhang1018/Chrono_Playground development by creating an account on GitHub. github.com

On the other hand, I am also trying to build SCM terrain and try to run your experiment on SCM terrain to see if the problem still exists.

Best,

Harry

---

From: Ted Sender <tse...@umich.edu>
Sent: Wednesday, January 29, 2025 3:47 PM

[Ted Sender]

Hi Harry,

I tried configuring my setup with SCM terrain and I changed the tires from TMeasy to rigid, and the entire simulation just went bonkers. As soon as the vehicle dropped onto the ground, the wheels kept spreading out and the chassis was trying to go through the ground and bounced around a bit. Switching back to TMeasy tires avoids this problem, but I'm told that rigid tires are supposed to be used with SCM terrain. No idea what was going on. Any help would be greatly appreciated with either rigid or SCM terrain.

Thanks,

Ted

[Harry ZHANG]

Hey Ted,

Please try to use the SCM code with the mesh file (link: https://drive.google.com/drive/folders/1jLb3nsbg6UU0vKVMWUsmMBlhJp771NLz?usp=sharing) I sent you. 

For SCM, you have to use rigid tire, or rigidmeshtire, TMEasyTire won't work because both TMEasyTire and SCM are empirical force model, we can't use TMEasytire with SCM if we want to get the sinkage and force from terrain. 

I didn't check your point cloud to scm terrain converter, but I guess something there caused a problem. I convert the txt point cloud into an obj mesh file, which seems works fine with SCM terrain.

Best,

Harry 

---

From: Ted Sender <tse...@umich.edu>
Sent: Sunday, February 2, 2025 11:57 PM

[Ted Sender]

Hi Harry,

Thank you for the help on this. It turned out that the dimensions I passed to the terrain.AddMovingPatch() function were not correct. I had to increase the dimensions and then I was able to get SCM terrain to work. Though, can you please explain how to interpret the OOBB_dims variable, because this is not documented clearly? I thought the values I originally passed to it were sufficient, but evidently they were not.

I have a few more questions related to SCM terrain. 

1. Depending on the soil parameters I choose, sometimes I've seen the wheels fly off the vehicle. What is causing that to happen in this situation?

2. Will increasing the SCM terrain resolution result in significantly longer runtime cost? Or is that whole point of the moving patch? Are you able to share how small of a resolution you have used without compromising on runtime cost too much?

Thank you very much again for all of your help. I really appreciate it.

Ted

[Harry ZHANG]

Hello Ted,

You are welcome, glad we figured something out along the way.

1. OOBB_dims. If you go to source code SCMTerrain.h, it has descriptions here. If we assume only four wheels contact with the terrain, then the movingpatches' center will be center of four wheels, the oobb_dim is the bounding boxes around with the center. SCM's Ray-casting process only happens inside these bounding boxes, rather than doing ray-casting to every single SCM node. Noticed that source code suggests dimensions is in unit of (in) rather than (m), which might cause your issue I guess.
2. Probably check "SoilParametersCallback" class in SCMTerrain.h, The SCM parameter has some physical meaning and need to be restricted by some relations between each other. I would use the "soft, medium, hard" terrain parameter sets I sent you first to test before customizing own set of SCM parameters. You could probably find more information about the SCM parameter in Chrono SCM terrain implementation paper (https://www.researchgate.net/publication/326922379_An_Overview_of_the_Chrono_Soil_Contact_Model_SCM_Implementation).   
3. Like I said, moving patch's job is to limit the ray-casting process inside the defined bounding boxes. If we use the same size of moving patches, but use finer resolution of terrain, that means inside the same bounding box, there are more ray-casting you need to perform. I tried 5cm as resolution and it seems to work fine. The choice of resolution will depend on the purpose of your application.  In my opinion, mesh resolution and parameter choice should consider: 1) accuracy, if you have reality testing results which could be used to calibrate the parameters; 2) speed, you don't want to have too fine resolution of mesh because that will make the simulation super slow like 100 RTF. 3) appearance, if you want to see the track of the tire left on the terrain, you need can't choose resolution/parameter that can't leave feature/sink. 

Cheers,

Harry

An Overview of the Chrono Soil Contact Model (SCM) Implementation - ResearchGate This document contains details of the SCM deformable soil model implemented in Chrono. The soft soil model discussed herein is an extended version of the classical SCM Soil Contact Model used at ... www.researchgate.net

---

From: Ted Sender <tse...@umich.edu>
Sent: Monday, February 3, 2025 11:20 PM

[Ted Sender]

Hi Harry,

I think that makes sense regarding OOBB_dim. I was also hoping to know what "OOBB" stands for as it is never mentioned in the code (as far as I could tell). The same goes for AABB. I believe you are misinterpreting the comment "[in]" which just denotes an in-variable (input) as opposed to an out-variable (output)

I have another question. Something weird happened to my computer last night. Currently, I am struggling to render graphics with SCM terrain (although this previously worked fine the other night). I can run without a GUI just fine, but whenever I tell the GUI to render the simulation with SCM terrain, the window seems to freeze up on a white/blank image. I've been accessing this computer remotely, so I need to see if the issue persists when I am in-person, but are there any thoughts on this? If I switch back to rigid terrain I can render the simulation fine, it's just with SCM terrain that suddenly has been creating problems.

Last, when you were using a resolution of 5cm, what was your real-time factor?

Thanks,

Ted

Ted Sender - B.S., M.S. Mechanical Engineering

PhD Candidate - Mechanical Engineering

Research Assistant - Epureanu Research Group

E-mail: tse...@umich.edu

Cell: 216-633-0165

[Radu Serban]

Some clarifications:

• Indeed, all units in Chrono::Vehicle are SI (with a very few exceptions where angles are provided in degrees and those should be marked clearly in the documentation).
• AABB and OOBB are standard terms in computational geometry: axis-aligned bounding box and object-oriented bounding box, respectively.
• The moving patch feature in SCM allows you to specify an arbitrary number of OOBBs associated with separate bodies; in particular, you can indeed attach an OOBB to the vehicle chassis (which needs to be large enough to always cover the projection of the wheel collision shapes onto the SCM reference plane) or else attach (smaller) OOBBs to each wheel (which can significantly reduce the number of ray casting tests and hence improve performance).
• SCM parameters (at least for the normal direction, based on the Bekker semi-empirical formula) do not really have direct physical meaning. They are identified from experimental data to fit the Bekker formula. ‘Kc’ and ‘Kphi’ are related to physical characteristics but are not physical parameters. ‘n’ is completely non-physical.
• The handling tire models (TMeasy, Pacejka, etc) do not work with SCM not because the are “empirical force models” but because they do not carry collision geometry.
• Additional performance of the ray casting can be obtained by proper setting the number of OpenMP threads.
• See more details in this paper (which describes the current SCM implementation in Chrono, quite different from the old one that Harry linked to).

 

Radu

[Ted Sender]

Hi Radu and Harry,

Thank you very much for the advice and help. I have two more questions as I'm playing around with SCM terrain.

1. Contrary to what you guys are saying, I actually get faster runtime performance when I do NOT specify a moving patch. Simply adding a moving patch for the entire vehicle or for each wheel actually increases the runtime cost. Without a moving patch, the simulation runs about 3-4x slower than realtime, and with the moving patch it's about 5-8x slower. This is with a 5cm resolution. This doesn't make any sense. How could this be?

2. If I make the SCM terrain resolution 2.5cm or smaller, then the terrain becomes invisible. It is still there because I can see the vehicle driving over bumps, but it is no longer rendered. Any idea what is going on here?

Thanks,

Ted

You received this message because you are subscribed to a topic in the Google Groups "ProjectChrono" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/projectchrono/px_RSXwsTIY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to projectchron...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/projectchrono/CH3PPF46CDC218568930AD62C36E640A0F8A7F62%40CH3PPF46CDC2185.namprd06.prod.outlook.com.

[Ted Sender]

I am resending my previous email because I received a message saying it was too large due to the attachment. I apologize if you are receiving this message twice:

Hi Harry and Radu,

I wanted to let you know that this tire problem actually does exist with SCM terrain. My terrain generation code (for a paper I'm working on) keeps creating heightmaps that result in the front tires rotating beyond their limits when the vehicle drives over certain areas. I am sharing a minimal working example that uses SCM terrain to show this problem. In the "src" folder, use the "my_example.cpp" file (ignore the one with the suffix "_orig"). You can set the heightmap and control log file to use at the top of the main() function. Google drive link: https://drive.google.com/file/d/10wLR3nX4szBR3JG8fG_kDJnxO-J1r1gV/view?usp=sharing

The "data" folder contains a number of files, but only pay attention to the files with the prefix "scenario_85" and "scenario_601". All of the control log files provided for each of the corresponding heightmaps result in this tire problem. Please let me know if you are able to observe that the front right tire rotates beyond its limit with these files.

I do still want to ask again a question from my previous email in that I observe faster computational performance when I do NOT use the AddMovingPatch feature with SCM terrain. Any idea why this might be? Try it out with this example code.

I look forward to hearing back your thoughts.

Thanks,

Ted

On Tue, Apr 29, 2025 at 3:49 AM Ted Sender <tse...@umich.edu> wrote:

Hi Harry and Radu,

I wanted to let you know that this tire problem actually does exist with SCM terrain. My terrain generation code (for a paper I'm working on) keeps creating heightmaps that result in the front tires rotating beyond their limits when the vehicle drives over certain areas. I am attaching a minimal working example that uses SCM terrain to show this problem. In the "src" folder, use the "my_example.cpp" file (ignore the one with the suffix "_orig"). You can set the heightmap and control log file to use at the top of the main() function.

The "data" folder contains a number of files, but only pay attention to the files with the prefix "scenario_85" and "scenario_601". All of the control log files provided for each of the corresponding heightmaps result in this tire problem. Please let me know if you are able to observe that the front right tire rotates beyond its limit with these files.

I do still want to ask again a question from my previous email in that I observe faster computational performance when I do NOT use the AddMovingPatch feature with SCM terrain. Any idea why this might be? Try it out with this example code.

I look forward to hearing back your thoughts.

Thanks,

Ted