Project Vehicle Handling Simulation in Orbiter2016

[fred18]

So, since I've learned a lot in the last few months about touchdown points handling, and landed vehicle handling, I'm testing the stability of my system with this:

notes:
1) turning is still just basic, I'll develop a proper algorithm, this was just for test
2) I got the mesh from the sketchup 3d warehouse

 

[jacquesmomo]

Great ! I am very very interested by this!!! :thumbup:

Will there be possibilities of additional animations as with "spacecraft"?

 

[fred18]

Great ! I am very very interested by this!!! :thumbup:

Will there be possibilities of additional animations as with "spacecraft"?

I don't know yet. It could be really nice, but i'm afraid to over complicate it. I'll try to see if i can make it easy, if it becomes too messy i'll release the module with just the basics (wheels and steering) and then i'll add new parts.

 

[4throck]

Seems to work fine I wonder how fast it will go on the Moon, Mars, etc:rofl:

 

[jedidia]

Are you planning to opensource this, or will you keep it closed? I'm asking because I'm slowly starting to worry whether Dan's going to update his stuff for Orbiter 2016, seeing as there's not a single shred of Info.

 

[fred18]

Open, for the community to have the chance of keeping it working and for me to have a repo: since i'm always travelling, changing computer etc i always need a place to have everything in the right order, and what best of the official release for it :rofl:

 

[gattispilot]

I am curious. I wonder if it could be used to drive my vessel (LER)? on the moon.

 

[fred18]

My idea is to have simple ini or cfg file in which you state:
- mesh
- wheel groups
- wheel rotation references (spinning, and turning)
- wheel coordinates
- steering wheel groups and rotation reference
- max speed
- maybe some acceleration / braking details
- cockpit position

and I think that's it for the moment.

So I guess it could be used for everything which navigates on ground. The beauty of this is that it seems to me very very stable, so very safe to use

 

[jacquesmomo]

Yes !!!

My little Renault-4L (from the Kourou spatial center) is happy !!! :thumbup:

 

[gattispilot]

So could this be hard coded into other modules. If you need help let me know

 

[Donamy]

Don't forget towing and pushing. :hail:

 

[gattispilot]

I guess one could apply it to a person and move around on a surface? Basically a mesh change.

 

[fred18]

I guess one could apply it to a person and move around on a surface? Basically a mesh change.

yes, to whatever you want

---------- Post added at 16:11 ---------- Previous post was at 15:22 ----------

ok, big improvement definitely needed for the new orbiter: the vehicle won't run flat, it will adapt to terrain. Here is the test on the moon.

Sometimes it sinks below the surface, but my feeling is that there's nothing to do about it, the shadow remains casted correctly, so it's only a graphic artefact while the calculations are done right.

It seems to me that it follows very weel the hills, and the terrain in general, and even if you turn and change local orientation it adapts itself.

I'm very happy with the result, what do you think guys?

 

[gattispilot]

Great. Yes. I discovered that the ground will eat into the mesh. I guess in a real vessel touchdown points would be at each tire. Then they would push up the vehicle based on the terrain.


Seems like the vessel moves smoothly. Will it roll down a hill it no force is applied?

 

[fred18]

Great. Yes. I discovered that the ground will eat into the mesh. I guess in a real vessel touchdown points would be at each tire. Then they would push up the vehicle based on the terrain.

I think that the way mesh is displayed is often an interpolation, so when you zoom in so much on the ground like a vehicle running on a hill there's a slight difference to what is displayed and what is used by calculation.

I tried to let the vehicle be created landed by orbiter itself and still it is sometimes shown a little below terreain. I think that it's the best possible for now, but I'm happy with it.

Seems like the vessel moves smoothly. Will it roll down a hill it no force is applied?

well, I haven't thought about it. It is possible since it is know when it will climb on terrain and when it's going downhill, but for now I think I'll keep just the "keep it simple" approach and won't add this.

 

[gattispilot]

Looking forward to testing?

I found on the LEr which used thrust to move. I couldn't stop on a hill. I would roll down. I think I needed a brake to hold her in place

 

[martins]

Sometimes it sinks below the surface, but my feeling is that there's nothing to do about it, the shadow remains casted correctly, so it's only a graphic artefact while the calculations are done right.

You are correct. There are two effects contributing to this:

• If you select cubic interpolation for the elevation calculation, then this cannot be exactly represented by the surface mesh (which is always piecewise linear). In this case, the car will follow a smoother virtual surface than the visual mesh representation.
• In the interest of performance, the elevation calculations may be based on a coarser surface representation than the visual mesh.

There isn't much that can be done about the first point other than refining the surface mesh much further to better match the curved 3rd order virtual elevation surface. This would impact performance heavily. If you are currently using a cubic elevation interpolation, you could try to switch to linear to see if that is the cause of the problem.

I might be able to work on the second point. Orbiter uses a variable resolution approach for calculating vessel elevation depending on its elevation, so that high-flying fast objects don't have to re-load too many elevation tiles. (similar to the variable visual mesh resolution depending on camera distance). In a sense this mimics a loss in resolution of the altitude sensors at higher altitudes. A vessel on the ground uses the highest elevation grid resolution, but currently this is capped independently from the visual resolution, again to avoid too many tile reloads with negative performance impact for objects that move quickly over the surface. Maybe I could give the user a choice between simulation performance and elevation grid resolution.

 

[fred18]

I might be able to work on the second point. Orbiter uses a variable resolution approach for calculating vessel elevation depending on its elevation, so that high-flying fast objects don't have to re-load too many elevation tiles. (similar to the variable visual mesh resolution depending on camera distance). In a sense this mimics a loss in resolution of the altitude sensors at higher altitudes. A vessel on the ground uses the highest elevation grid resolution, but currently this is capped independently from the visual resolution, again to avoid too many tile reloads with negative performance impact for objects that move quickly over the surface. Maybe I could give the user a choice between simulation performance and elevation grid resolution.

I think that it can be useful for "on ground explorations", thank you very much for your explanation! :tiphat:

In the meantime I finished the steering modelling and I'm happy also with that, it seems enough realistc to me, so I'll just turn it into a general module now and it will be done...:thumbup:

[ame="http://www.youtube.com/watch?v=R-8q9yxs7tc"]http://www.youtube.com/watch?v=R-8q9yxs7tc[/ame]

 

[DaveS]

Don't forget towing and pushing. :hail:

Yes. It would great if the towing physics from tl8's JBT B1200 could be added.

 

[fred18]

Yes. It would great if the towing physics from tl8's JBT B1200 could be added.

I can try with attachments, i don't know if it'll works, i'll see.