2-axled Wagon Type A – step 0031 – February 2010

1 Purpose of SrrWagon2axA

The prototype SrrWagon2axA is a so-called “specific vehicle prototype”. I.e., it takes parameters from the user (vehicle model) and orchestrates them to a functioning SrrTrains vehicle model.

To achieve this goal, it makes use of the generic vehicle prototype SrrVehicle.x3d, that is used for all SrrTrains vehicles.

The user must provide two SrrAxle nodes and an SrrTransformationA node (the axles containing two further SrrTransformationA nodes in turn). The user must not initialize those nodes.

The user may provide a boolean control node (e.g. SrrControlBoolA) to switch between the operation modes “v=const” and “Newton”. The user may provide a floating point control node to set the constant velocity and a floating point control node to impose a dozing force. The user must not initialize those nodes.

SrrWagon2axA will coordinate the initialization of all contained nodes.

SrrWagon2axA supports three modes of operation:

standalone:

The end user has opened the file of the vehicle model directly, without any relation to an SrrTrains layout. The model will stand still, but the wheels will rotate with constant velocity.

static:

The vehicle is embedded into an SrrTrains module as a static model. The module author is responsible for any animation, the wheels will rotate with a constant velocity set by the module.

dynamic:

The vehicle has been registered at an SrrTrains layout, an instance of a vehicle has been created at a setup point and now the vehicle is moving along the tracks.

2 User Interface of SrrWagon2axA (uiObj)

SrrWagon2axA is an external prototype that is available at the directory srr/.

<ProtoDeclare name='SrrWagon2axA'>

<ProtoInterface>

<field accessType='inputOutput' name='objType' type='SFString' value='SrrWagon2axA'/>

<field accessType='inputOutput' name='version' type='SFFloat' value='0.0031'/>

<field accessType='inputOutput' name='objId' type='SFString'/>

<field accessType='inputOutput' name='quasiModule' type='SFString'/>

<field accessType='inputOutput' name='mass' type='SFFloat' value="1000"/>

<field accessType='inputOutput' name='wee' type='SFFloat' value="0.0025"/>

<field accessType='inputOutput' name='length' type='SFFloat' value="5.0"/>

<field accessType='inputOutput' name='axlesPositions' type='MFFloat' value='1.0 4.0'/>

<field accessType='inputOutput' name='axle0' type='SFNode'/>

<field accessType='inputOutput' name='axle1' type='SFNode'/>

<field accessType='inputOutput' name='transformationWagon' type='SFNode'/>

<field accessType='inputOutput' name='vIdleRotation' type='SFFloat' value="1.0"/>

<field accessType='inputOutput' name='idleRotate' type='SFBool' value="false"/>

<field accessType='inputOutput' name='vConstControl' type='SFNode'/>

<field accessType='inputOutput' name='vConstEnableControl' type='SFNode'/>

<field accessType='inputOutput' name='dozeControl' type='SFNode'/>

<field accessType='inputOutput' name='standalone' type='SFBool' value='true'/>

<field accessType='inputOutput' name='visible' type='SFInt32'/>

<field accessType='outputOnly' name='basicallyInitialized' type='SFNode'/>

<field accessType='inputOutput' name='modParam' type='SFNode'/>

<field accessType='outputOnly' name='initialized' type='SFNode'/>

<field accessType='inputOutput' name='enabled' type='SFBool' value='true'/>

<field accessType='outputOnly' name='staticModel' type='SFBool'/>

<field accessType='inputOutput' name='exitViewpoint' type='SFNode'/>

<field accessType='inputOnly' name='deleteTrain' type='SFTime'/>

</ProtoInterface>



The fields objId, standalone, modParam, quasiModule, initialized and enabled should be directly connected to the model's miMod(Model) interface, maybe doing some intermediate trace output in a script.

The fields mass, wee, length and axlesPositions set the parameters of the wagon for the train kinematics. mass is the mass in kg, wee is indicating the friction, length is the “length over buffers”, axlesPositions[0] is the distance of the first axle from the vehicle front (buffer) and axlesPositions[1] is the distance of the second axle from the vehicle front (buffer).

axle0 and axle1 are SrrAxle nodes representing the axles. Each of them must contain an SrrTransformationA node to transport the information about axles's transformations from the track geometry to the vehicle model.

transformationWagon is an SrrTransformationA node, whose content will be calculated dependent on the axles's transformations. The vehicle model must use this node to set position and orientation of the whole wagon.

vIdleRotation and idleRotate are used as input for the idle rotation of the wheels in case of standalone and static operation modes. In case of standalone, the flag idleRotate is ignored and the wheels rotate anyway with vIdelRotation, in case of static, the rotation takes only place, when idleRotate is set to true.

vConstControl, vConstEnableControl and dozeControl are optional parameters, that may be used to instrument input from the end user. vConstEnableControl may contain a reference to a boolean control, that will be used to switch the “v=const” mode on and off. Default value is “OFF”. If “v=const” is “ON”, then the whole train containing this vehicle will move with constant velocity. In this case, the vConstControl should contain a floating point control to set/change the velocity in m/sec. dozeControl will impose a “dozing force” in kg.m/sec^2.

The model should listen to the visible field of SrrWagon2axA. Visible outputs either -1 or 0, to be directly used as whichChoice of a <Switch> node.

The fields basicallyInitialized and staticModel output some additional information, which could be useful for the model author. The basic initialization is done, when the vehicle is loaded, before the modParam value can be processed. A standalone model is only basically initialized, but not initialized.

The exitViewpoint is a reference, that can be set by the module author.

If the end user (his avatar) had entered a vehicle, the moving viewpoint of this vehicle was bound. Then the vehicle moved around the layout, could even change modules, and now, when the end user/avatar wants to leave the vehicle, it's the question, which viewpoint should be bound.

The concept of the exit viewpoint allows the module author, to assign a viewpoint to each track section. When the first axle of a vehicle moves into a track section, it will take its exit viewpoint as the own exit viewpoint and report this reference to the vehicle model. Now the model can detect, that the avatar is leaving and can bind this viewpoint.

With deleteTrain the model can request deletion of the whole train. E.g. take the value from the touchTime field of a <TouchSensor> node.