OHM GeneralVehicle

[PhantomCruiser]

Stupid question incoming -

I've got a few meshes knocked together as ocean going vessels, this will work on the water too? I figure to have attacchment points on the flight deck for VTOL craft. Originally planned just to have it as a static mesh, but if this will work it'll be much more dynamic.

 

[fred18]

Stupid question incoming -

I've got a few meshes knocked together as ocean going vessels, this will work on the water too? I figure to have attacchment points on the flight deck for VTOL craft. Originally planned just to have it as a static mesh, but if this will work it'll be much more dynamic.

yep, in orbiter there's no difference between land and sea. sea is only a flat land surface painted in blue

 

[gattispilot]

I wonder if it would better visually to set the height higher than the ground? Then then vessel will not be in the ground?
I raises Dan's IALunar Rover so that the lowest y would be 0.

ClassName=GeneralVehicle
Module=GeneralVehicle

Empty_Mass = 1000			;[kg] empty mass (almost unused)
Mesh = IACarLunarRover_GV				; meshname
Cockpit_pos = .411 1.96 .96	; [m m m] Position of the cockpit camera
Acceleration = 1.45			; [G] Acceleration factor expressed in Gs
Brake = 3					; [G] Deceleration factor expressed in Gs
Max_Speed = 200				; [km/h] Max Speed
Reverse_Max_Speed = 50		; [km/h] Max Speed in Reverse
Steering_Speed = 1.5  		; Steering wheel velocity factor
Full_Pedal_Time = 2			; [s] seconds from the beginning of pressing of Acceleration or Brake and the full power is applied
Max_Steering_Angle = 30  	; [DEG] Max steering of the front wheels per side
Height_From_Ground = 0.001 	; [m] height of the center of gravity from the ground
Always_Upright = TRUE   	;if set to TRUE vehicle will always remain parallel to the ideal ground, without following terrain's inclinations
Four_Wheels_Steering = FALSE ;if true also rear wheels will steer

;Mesh Groups - just specify using space between them

Rear_Right_Groups = 1
Rear_Left_Groups = 1 
Front_Right_Groups = 2
Front_Left_Groups = 6
;Middle_Right_Groups = 1 
;Middle_Left_Groups = 94 
;Steering_Wheel_Groups = 8

;Front_Wheels_Diameter = 0.750766		;if not specified the module will try to calcualte it automatically
;Rear_Wheels_Diameter = 0.755238				;if not specified the module will try to calcualte it automatically

;Rotations info
;Rear_Axel_Pos = 0.0 -0.2426463 -2.121106   ;if not specified the rear right tyre group barycenter will be used
;Front_Axel_Pos = 0.7848695 -0.2371205 1.54079	;if not specified the front right tyre group barycenter will be used. The left will be considered symmetrical
;Steering_Axis = 0.6513898 0 1.542014		;axis for steering of the front tyres. Just specify the Front - Right tyre rotation, the Front left will be considered symmetrical if not specified the front right wheel groups barycenter will be used
;Steering_Wheel_Pos = 0 0 0.505				;if not specified the steering wheel group barycenter will be used
;Steering_Wheel_Axis = 0 0.487821 -0.872943				; if not specified 0 0 -1 is used

Camber = 0							;[DEG] camber angle of the front wheels, no  camber is implemented for rear wheels.

Here I

Height_From_Ground = 1 	; [m] height of the center of gravity from the ground

 

[fred18]

I don't see the point: you can set whatever value you want

 

[gattispilot]

I don't see the point: you can set whatever value you want

Yes. I was just thinking that rather than where the bottom of the wheels hit. raise it up so that the vessel from a point of view isn't in the ground. Of course you can get a view of the vessel on top of the surface.

Just a comment NOT about your add-on

 

[Abloheet]

I have a few comments and suggestions.
The time to full throttle and brake is very realistic. Is there a similar feature in the time to turn as well? Isn't turning resistance modeled, like, the speed of the vehicle will reduce when it turns? And can suspension be modelled as well? Like the vehicle will tip forward a bit while accelerating and backward when braking. And will tilt a little in the direction opposite of turning. Will increase the realism a lot.

Also, one thing I noticed is that the TAS and GS readings in surface mfd remain at zero when the vehicle is in motion. The surface hud also shows zero speed. Only General Vehicle's indepedent output shows the speed. Why is this so? Aren't Orbiter's inbuilt instruments supposed to show the vehicle speed in metres/second?

 

[gattispilot]

Also, one thing I noticed is that the TAS and GS readings in surface mfd remain at zero when the vehicle is in motion. The surface hud also shows zero speed. Only General Vehicle's indepedent output shows the speed. Why is this so? Aren't Orbiter's inbuilt instruments supposed to show the vehicle speed in metres/second?

I could be wrong. But I think because the vehicle's position is moving and not using thrust,....

 

[fred18]

I have a few comments and suggestions.

always well accepted! Thanks!

The time to full throttle and brake is very realistic. Is there a similar feature in the time to turn as well?

If I understand this right it should be

Steering_Speed = xxx   Deg/s     Value that expresses how quick the steering is applied

Isn't turning resistance modeled, like, the speed of the vehicle will reduce when it turns?

not entirely, the actual distance covered by the vehicle while turning is reduced due to trigonometry (sin and cos of steering angle are accounted), but no physical effect is simulated

And can suspension be modelled as well? Like the vehicle will tip forward a bit while accelerating and backward when braking. And will tilt a little in the direction opposite of turning. Will increase the realism a lot.

Well I gave a deep thought about this while coding the module, but the main issue is that this is a general module, therefore the parameters that the user will have to input to have the proper realism would increase significantly, some examples:
- spring constant for the suspensions (to be treated carefully due to numerical instability)
- damping constant for the suspensions (to be treated carefully due to numerical instability)
- distance between minimum and maximum suspensions' extension
- a lot of other groups to animate (think about the formula 1 car, with the front triangles that have to rotate up and down) with all the relevant parameters (pivot points, translations, rotations, scale of the cylinders etc)
- and many more that will easily arise when starting to code

in conclusion IMHO it is something that can be simulated in a single and defined vehicle, but that could be overwhelming (and may become too difficult for users to handle) for such a generic module

Also, one thing I noticed is that the TAS and GS readings in surface mfd remain at zero when the vehicle is in motion. The surface hud also shows zero speed. Only General Vehicle's indepedent output shows the speed. Why is this so? Aren't Orbiter's inbuilt instruments supposed to show the vehicle speed in metres/second?

this happens because, in order to have such a stable simulation, the module works by moving around frame by frame a still vessel sitting on the ground. So for Orbiter is like the vessel never starts to move around, it just "teleport" itself in the location calculated for the next frame.

I can try to guess that inside Orbiter itself the functioning of the status update of a single vessel in the simulation is something like:

- forces acting on a vessel -> accelerations on the vessel
- accelerations -> velocity vector change of the vessel -> final velocity vector (this is what you see in the instruments)
- velocity vector -> position update

GeneralVehicle works exactly in the same way, but it does it by itself, not passing through the normal Orbiter simulation process, so Orbiter sees a vessel with 0 velocity each frame that is being teleported in the next spot.

I hope this clarify your doubts!

 

[fred18]

Updated on OH with the "No_Steering_Animation" option, which allows to have the vehicle turning without the wheels steering, as asked by Gattisplot earlier here.

 

[Abloheet]

this happens because, in order to have such a stable simulation, the module works by moving around frame by frame a still vessel sitting on the ground. So for Orbiter is like the vessel never starts to move around, it just "teleport" itself in the location calculated for the next frame.

I can try to guess that inside Orbiter itself the functioning of the status update of a single vessel in the simulation is something like:

- forces acting on a vessel -> accelerations on the vessel
- accelerations -> velocity vector change of the vessel -> final velocity vector (this is what you see in the instruments)
- velocity vector -> position update

GeneralVehicle works exactly in the same way, but it does it by itself, not passing through the normal Orbiter simulation process, so Orbiter sees a vessel with 0 velocity each frame that is being teleported in the next spot.

Wow. That is cool. General Vehicle does its own surface interaction calculations and acceleration and deceleration calculations? Without using the Orbiter Engine. Nice. This helps with the performance and stability of Orbiter. But isn't that more work for you?

---------- Post added at 04:52 PM ---------- Previous post was at 04:49 PM ----------

always well accepted! Thanks!



If I understand this right it should be

Steering_Speed = xxx   Deg/s     Value that expresses how quick the steering is applied

not entirely, the actual distance covered by the vehicle while turning is reduced due to trigonometry (sin and cos of steering angle are accounted), but no physical effect is simulated



Well I gave a deep thought about this while coding the module, but the main issue is that this is a general module, therefore the parameters that the user will have to input to have the proper realism would increase significantly, some examples:
- spring constant for the suspensions (to be treated carefully due to numerical instability)
- damping constant for the suspensions (to be treated carefully due to numerical instability)
- distance between minimum and maximum suspensions' extension
- a lot of other groups to animate (think about the formula 1 car, with the front triangles that have to rotate up and down) with all the relevant parameters (pivot points, translations, rotations, scale of the cylinders etc)
- and many more that will easily arise when starting to code

in conclusion IMHO it is something that can be simulated in a single and defined vehicle, but that could be overwhelming (and may become too difficult for users to handle) for such a generic module

Ok, so to enable this level of functionality and realism, a custom module has to be created. I mean, like with some derivatives from your code and with some extra simulations and features added into it? Like spring damping, etc.
Yes, this approach is better then. Its good that your code is available for reference. Thank you.

 

[fred18]

Wow. That is cool. General Vehicle does its own surface interaction calculations and acceleration and deceleration calculations? Without using the Orbiter Engine.

yep, exactly that.

But isn't that more work for you?

it was, but now it's done
:thumbup:

Ok, so to enable this level of functionality and realism, a custom module has to be created. I mean, like with some derivatives from your code and with some extra simulations and features added into it? Like spring damping, etc.
Yes, this approach is better then. Its good that your code is available for reference. Thank you.

Yep, you got it exactly right!

 

[Interceptor]

Anyway to add tread marks,and dust kick up effects?

 

[fred18]

Anyway to add tread marks,and dust kick up effects?

tread marks I think it's very very difficult to do (I'd say almost impossible).

dust kick up it would need particle streams, the user can make a custom module and attach it to the GV wheels, as explained in the doc, that's the quickest way for now I can think.

 

[4throck]

Fred18, one interesting variation of GeneralVehicle would be GeneralEVA.
You would only need to simulate the astronaut's "jumps" as they move (mesh translation), and perhaps the possibility to hide/change the astronaut mesh (to simulate reentering a vehicle).

Think about this, for example for a GeneralVehicle powered Lunar Rover.


Of course, its possible to use an astronaut mesh with GVehicle as it is, if we add a skateboard or rollerskates

 

[Donamy]

Hi Fred, maybe I missed something, but I can't seem to go in reverse.

 

[fred18]

Hi Fred, maybe I missed something, but I can't seem to go in reverse.

there's the key combination you have to press (if vehicle is stopped), from docs:

[CTRL] + [NUMPAD2] = if vehicle is stopped it
starts to move in reverse

is it working?

 

[Donamy]

Found it. Thanks Fred.

...note to self. Read more carefully.

---------- Post added 07-08-17 at 01:08 AM ---------- Previous post was 07-07-17 at 11:59 PM ----------

Another issue: The scenario starts ok, but the SC3 vessel is not attached to the CVbase vehicle. Also the axis are not correct after I attach it with attachment manager.

 

[fred18]

Another issue: The scenario starts ok, but the SC3 vessel is not attached to the CVbase vehicle. Also the axis are not correct after I attach it with attachment manager.

can you post scenario and cfg for vessel and sc3? Maybe you're using the wrong attachment point on the vessel

 

[Donamy]

Thanks for the help !!

 

[fred18]

Thanks for the help !!

I have some issues with vinka's spacecraft so I couldn't test it properly, but it seems to me that the rot value should be 0 0 1 and not 0 0 -1