410 likes | 550 Views
OpenMASK 4. New version. Summary. Introduction Principles Simulation, scheduling, distribution Data exchanges between objects New version Types Attributs Extensions Visualisation Principles Visualisation with Ogre. History. L’ancestor of OpenMASK was a simulator Scheduling
E N D
OpenMASK 4 New version
Summary • Introduction • Principles • Simulation, scheduling, distribution • Data exchanges between objects • New version • Types • Attributs • Extensions • Visualisation • Principles • Visualisation with Ogre
History • L’ancestor of OpenMASK was a simulator • Scheduling • Distribution • From a simulator to a Virtual Reality platform • Visualisation • Management of VR interfaces
Simulation Principles
Principles Basic element : Simulated object • Fonctionnalities : • Distribution (localised on a process) • Frequential call • Communications with peers • Streams (inputs/outputs) • Messages (sending/receiving)
Distribution • To distribute is easy • Indicate on which process the object must be simulated • How does it work ? • Object creation • Mirror creation on demand • Difference between mirror et reference objects
Distribution : Objects creation • Two process 1 and 2 • An object A with an output c on process 1 • An object B with an input d on process 2 1 A c A { Class ObjetAvecSortie Scheduling { Frequency 75 Process process1 } UserParams { ... } } #OpenMASK3 root { Class Controller Scheduling { Latency 0 Machines { process1 portalux.localdomain process2 portalux.localdomain } } B { Class ObjetAvecEntree Scheduling { Frequency 75 Process process2 } UserParams { ... } } 2 B d
Distribution : Mirror creation • B wants to connect its input d to the output c of A • B asks to its process 2 to give it a reference to connect itself to c • 2 hasn’t got A • 2 creates the mirror of A and informs 1 • B can connect itself • Thereafter, A synchronises its mirror A each time c is updated 1 A référence c Synchronisation B { Class ObjetAvecEntree Scheduling { Frequency 75 Process process2 } UserParams { dConnectTo [A c] } } 2 ? A miroir B c d
Reference Life cycle Construction constructor & postConstruction() Initialisation init() Frequential call compute() Characteristics Has inputs and outputs Reads the configuration parameters Updates its outputs every time it is recurrently called Mirror Life cycle Construction constructor & postConstruction() Characteristics Has only outputs Is not initialised Is not computed Its outputs are synchronised by the controller Distribution : Miroir vs Référence => The ouputs can and must be created only during the construction phase of the objects
Frequential computation • Fréquential call • Each object has its own simulation frequency • The controller schedules the calls to the specified frequency • Simulation time ≠ Real time • It isn’t because an object is to 50Hz that its calls will be to 50Hz • A clock object by “wasting” time, makes possible to synchronize the simulation
Communications • SynchronousInput/output = data flow • N inputs connected to 1 output • Possible to get the data by the entries at each frequential call • AsynchronousMessage = id [+ data] • Events : sent the message to a specified object • Signals : broadcast the message through the controller to all the registered listening objects • Call a dedicated method at each message reception
The basic type • OMK::Type::BaseTwo functions : • SerialisationIn distribution : • The data are exchanged through streams between processes • PolationIn multi-frequency simulation : • interpolation et extrapolation of numeric data to a specified date • Every data types are its sons
New version Granularity & simplicity
The extended type • Encapsulation of any type • OMK::Type::SimpleTypeT< T >Provides the two basic functions: • Serialisation • T must give the stream operators >> and << • Polation • Default polator (no interpolation) • Possibility to define its own polator
New extended object Extensibility of the object • Attributs • Easier manipulation of data • Automatisation of some functionalities • Extensions • Modifying the granularity • Littler components easier to design • Creates the objects by assembling extensions instead of coding
Attributs • Definition: • Id • Type • Value • Functionalities: • Accessors (id, value) • Connectivity (input, output, connection) • Messages (value update, reading, connection) • Allows: • Introspection • Automatisation of some tasks
Attributs « Obj2 » « Obj1 » « id » « id » « pos » Attribut : « id » Listener ConnectTo Listener Disconnect Listener SetValue Listener SetValueOf Listener GetValue Value :3 Value :2 Value :4 disconnect_id current_value {« id »,« 3 »} get_value_of_id [« id’ »] connect_to_id {« Obj2 », « pos »} current_value_of_id’ {« 4 »} current_value_of_id {« 4 »}
Extensions Sub-simulated objects • Functionalities • Creation • Initialisation • Computation • Possibilities (thanks to the owner object) • Creation of attributs, extensions, listeners • Sending events and signals • Access to attributs and others extensions
Examples of what it can do : Extending the initialisation Offering a new configuration syntax Adding listeners Extending functionalities Adding attribut Adding new inputs or outputs Adding new parameter to control object behavior Modifying the value of an attribut Converting an attribut value before or after it is used by the object … Extensions
Visualisation Ogre
Visualisation • Dynamical creation by messages • Visual objects (≠ simulated object) • Animators • Update by the animators • Based on the Ogre rendering engine
Visual object • Role • Displaying a graphical 3D object • Calling its animators to update its visualisation • No direct access to the simulation data of the simulated objects (aim of its animators) • With Ogre • Reads a mesh (3D objects format used by Ogre) • Puts it in the Ogrehierarchical scene • The mesh display is managed by the Ogre rendering engine
Animator • Role • Creation of a plug to retrieve the data • Input (flow from a output) • Listener (listen a valued or not event or signal) • Other (a specific plug, for instance for a data base) • Getting the data through its plug • Updating its owner, the visual object to display (no matter how the data is retrieved by the plug) • With Ogre • Associated to a node in the Ogre tree scene • Update its associated node according to the data value
Visualisation : Créations • Add a visual object • Receiving the message • Creation • Add animators • Receiving the message • Creation • Automatically plugs creation • Flow => Input • Event => Listener Visu Visual Objects Factory Visual Object Animator Plug Input Animator Plug Event Animator Factory Listener Add Animator Add Visual Object
Visualisation : Update • Retrieving the data through the plugs • Updating call • Using the data value given by the plug Vis Visual Object Animator Plug Input Object Animator Plug Event Listener Object
Visualisation attribut Specialised attribut for visualisation • Creates an animator defined by configuration • Chooses the plug according to the attribut • With a output • Data flow => Connects the plug to the output • Without output • Message => Registers the plug to recieve the data • During a set of theattribut • Update the output • Or send the value in a message
Create a simulation New modules & Configuration
Simulator structure • Configuration • Gets the configuration • Plugins • Each one registers their object creators • Controller • Created • Configured • Run
Configuration • Simulation Tree • Hierarchical • Describes the simulation structure • Describes the objects, extensions, etc. • Objects creation • Based on their description • Initialisation with some specific parameters • Multi-process • Trees are coherent on all processes • Objects ares coherent on all => if not mirors will be different from the references
Configuration : File Format • Textual format with a hierarchical syntax • Allow to create the configuration tree Key word to identify the file (the first line) #OpenMASK3 Comments // Comments syntax like C++ /* You can write both type */ Hierarchical node identifier { ... } Simple data identifier valeur Multiple data node identifier[valeur1 valeur2 ...]
Configuration : Simulation objects • All the objects have this syntax, including the controller objectName// object id { Class ObjectClassId// object class id Scheduling // parameters for scheduling the object { ... } UserParams // parameters defined by the user { ... } Extensions // parameters of the extensions { ... } Sons // children, in fact only controler has ones { ... } }
Configuration : Controller • Root object of the simulation #OpenMASK3 root // id of the controller { Class Controller// the controller class id UserParams // parameters { Plugins [ ... ] // used plugins ... // other parameters traces, etc. } Scheduling { ... // parameters to define the multi-process } Sons // the simulation objects { ... } }
Configuration : Extensions • They are declared in the Extensionsnode of the object • They are defined by : • An id for the extension • An id for the extension type • Some parameters of the extension Extensions { extensionId // id { Class EntensionClassId // type id ... // other parameters } }
Examples Objects & Extensions
SimplePoint / a point in the space OMK::SimplePoint • Conditions • Offer a position in the space • Coding • Inherits ExtensibleSimulatedObject • Agregates an OMK::Transform attribut • Creates an output
SimplePoint / Declaration 1/class SimplePoint : public ExtensibleSimulatedObject 2/{ 3/ DECLARE_OBJECT_FACTORY( SimplePoint ) ; 4/protected: 5////\brief The "Position" attribute. 6/ OMK::AttributeT< OMK::Type::Transform > _position ; 7/} ; • Comments: 1/ Inherit ExtensibleSimulatedObject 3/ this macro declares : CLASS_ID, constructeur, destructeur 6/ The position attribut
SimplePoint / Implementation (1/2) 1/ REGISTER_OBJECT_FACTORY( SimplePoint, "SimplePoint" ) ; 2/ 3/ SimplePoint::~SimplePoint() 4/ { 5/ } • Comments : 1/ Macro to register the object in the factory and declares "SimplePoint" as its class id which will be used in the configuration 3/ Destructor : nothing to do, the inheritance does everything
SimplePoint / Implementation (2/2) 1/ SimplePoint::SimplePoint( Controller& ctrl, const ObjectDescriptor& objectDescriptor ) 2/: ExtensibleSimulatedObject( ctrl, objectDescriptor ), 3/ _position( "Position", Transform( Wm4::Vector3f::ZERO ) ) 4/{ 5/ addAttribute( _position, true ) ; 6/} • Comments: 1/ Constructor with the parameters used by the factory 2/ Inherits ExtensibleSimulatedObject 3/ Initialises the attribut : Id + initial value 5/ Adds the position attribut to the objectThe output is created by the true To creates an output this line must be in the constructor (or postConstructionmethod)
SimplePoint / Operation • Creation • Creates the attribut • registering
SimplePoint / Configuration (1/2) • Type id SimplePoint • Scheduling parameters inherits SimulatedObject • Extensions capabilities inherits ExtensibleSimulatedObject • Parameters associated to Position attribut • Position <Transform> : Initial value • PositionConnect [<name> <name>] : Connection to the output of an other object • PositionConnectByEvent <yes|no> : Activation of the (de)connection of the input associated to the attribut by event • Etc. other activations by events or signals
SimplePoint / Configuration (2/2) • Example 1/ my_point_in_the_space // object id 2/ { 3/ Class SimplePoint 4/ Scheduling 5/ { 6/ Frequency 60 // call frequency 7/ } 8/ UserParams 9/ { 10/ Position [[0 100 0]] // initial position 11/ } 12/ }