Difference between revisions of "Apogy/Concepts"
(→Java Script Program)
|Line 320:||Line 320:|
=== Operation Call [[File:Apogy_OperationCall_icon.gif ]] ===
=== Operation Call [[File:Apogy_OperationCall_icon.gif ]] ===
Revision as of 10:27, 4 September 2018
Table Of Contents
- 1 Table Of Contents
- 2 Overview
- 2.1 Session
- 2.2 Systems
- 2.3 Variable
- 2.4 Context
- 2.5 Environment
- 2.6 Time Source
- 2.7 Worksite
- 2.8 Program
- 2.9 Initial Conditions
- 2.10 Tool
- 2.11 Topology
In Apogy, users control Systems by invoking commands (through Programs) and monitor the System's health through telemetry (i.e. states).
These Systems are operated in a Environment which defines such things as Digital Elevation Maps, orbit models, sun position, etc (i.e. what the Environment contains).
|User, System, Environment and Data Product.|
The System's command produces result (i.e. returned value, such as an Image, an error code, etc.) that Apogy geo and time tags. This allows the results to be displayed within the 3D Environment. This helps in maintaining the situational awareness of the operator and keep the data in context.
The following tables presents a brief summary of the Concept defined in Apogy. Please refer to the sub-sections for more details.
In Apogy, the Session is the entity that contains all the configuration and data that are required to make use of Systems. The session is implemented as an Eclipse Project with an Apogy nature, and as such, is mapped to the host file system. Sessions can be exported/imported to and from archived files (.zip).
The Session project includes a central resource (session.sym) that contains most of the configuration elements (Variable, Context, InitialCondition, etc) and also has references to other ressources contained in the project (scripts, data products, etc). In Apogy there is at most one active Session at any given time.
The Session contains:
- the Environment being used;
- the list of Programs that can be executed;
- the list of available InitialConditions;
- the list of Tools that are available.
In Apogy, a System is an entity that can execute commands and provide its state information. Typically Systems represent actual hardware (ex: a rover, a camera, a robotic arm) but can be used to represent something more abstract (a planning system, a resource dispatcher, etc.).
In Apogy, a user makes use of the Systems to perform tasks in a given Environment. The System supports commands and reports on it status through its telemetry : the System is defined by its interfaces. Given this definition, a System can be modeled as a class : methods represent commands (with their parameters and return value) and the attributes represent states returned as part of telemetry. In Apogy, a System is defined using the Eclipse Modeling Framework.
In Apogy a System is named and is defined in EMF model. This model includes:
- The System Interface Class defining the commands and attributes it supports;
- A list of Connection Points where other sub-system can be attached;
- A list of Assembly Links that are used to assemble a System's sub-System (in composite Systems);
- A topology of nodes that are used to defined the system representation in 3D;
- A list of Topology Bindings that are used to bind attributes of the interface class to behavior in the topology (ex: binding the value of a 3D transform to the value of a revolute joint position);
Simple Systems can be assembled together to create composites Systems (ex: Integrated Rover Example). This allows sub-systems to be modeled independently and reused as part of different assemblies. The assemblies of Systems is supported through System Type Members, Connection Points and Assembly Links.
System Interface Class
The System's Interface Class refers to the EClass that defined the 'Operations' (methods) and attributes of the System. Only Operation and attributes defined in the interface can be accessed by Apogy to create commands, display values, bind attributes, etc.
System Type Members
Composite System contains Type Members that refers to other System. This is the pattern used by Apogy to implement composite data type (ex: struct in C programming language ). These Type Members can be made accessible to the parent System.
|An example of a composite System and its Type Members. For example, type member platform is of type MobilePlatform.|
Apogy allows operations to be called on a composite System's Type Member (ex: calling rover→mobilePlateform.moveForward(1.25)) in a hierarchical fashion. In the same way, attributes of sub-system can be accessed (rover→mobilePlateform.leftWheelPosition).
System can be compose at multiple levels (i.e. a System can have type members that are themselves composites Systems and so on.). The Integrated Rover is an example of such a System.
Connection Points define physical locations where other sys-system are expected to be connected. To used the analogy of a construction toy's blocks, connections point points define the brick studs.
|A System connection points and relationship to the System's topology. The connection points are shown as yellow rectangles and topology Nodes as blue rounded rectangles.|
They are named and refer to a Node defined in the System's topology. The root connection point is implicit and always refer to the System's root topology node.
Assembly Links describe how systems are attached to each other in composite Systems.
In the construction toy's analogy, the assembly links represent a construction set's instructions. The assembly links are named and refers to their parent's connection point to which the subsystem root connection point is attached.
A user can define multiple instances for a given System (ex: vehicle1 and vehicle2 of type MobilePlateformApogySystem). Similar to the way multiple variables of a given type can be defined in programming languages, Apogy uses the concept of Variable.
Each Variable has a name (that should be unique) and refers to the type of System it represents. Variable can refer to simple or complex System.
When developing complex operations sequence or testing scripts that command Systems to perform tasks, a user often needs to run such commands on some sort of simulated version of the Systems. In other cases, during development, a specific sub-system of a larger assembly may not yet have an implementation that communicates with it's hardware (or the hardware may not yet be available). A way for the user to work on operational sequence or scripts should be made available. In summary, the specific System implementation used typically depends on the context of use.
In order to addresses such cases, Apogy makes use of Context . At it's base, a Context maps Variable to actual implementations of the Interface Class of its System and sub-systems. By doing so, when a Variable is instanciated, the actual Interface Class Implementation specified in the Context is used. Used together with a System Interface sub-classes, the Context allows commands and script to be executed in a transparent fashion in diverse implementation settings.
|Simulated Context selected as the active context.||Real Context selected as the active context.|
In the example above, 3 Variable have been defined:
- myRover : Refers to a System which Interface Class is Rover, which has 2 sub-classes:
- RoverSimulated : A simulated implementation of the Rover;
- RoverReal : An implementation that connects to the actual hardware rover.
- myArm : Refers to a System which Interface Class is Arm, which has 2 sub-classes:
- ArmSimulated : A simulated implementation of the Arm;
- ArmReal : An implementation that connects to the actual hardware robot.
- myLidar : Refers to a System which Interface Class is Lidar. In this cas, the Lidar hardware being no yet completed, only 1 sub-class is available:
- LidarSimulated : A simulated implementation of the Lidar;
The user has created 2 Context : Simulated and Real. In this case, both real and simulated version of the rover and arm are used, but the Lidar hardware not being available, both Context make use of the simulated implementation (LidarSimulated) of the Lidar. This setup allows command sequence or scripts to be developed and tested now using the Simulated context, and later used with the real world implementation when the actual Systems become available.
While many Context can be defined in a given Session, only one can be selected as the active context. The Context definition includes:
- A name (should be unique);
- The DataSet where results will be stored. This allows result from different Context to be saved separately (this is often useful to keep data from a simulated run separate from data produced by actual, real System).
The Environment contains the definitions of worksite, and what the user has to work with in a specific mission (such as Variables, Context, Worksite, etc).
The Environment contains the following:
- the Variables that are available;
- the list of available Contexts and the one currently active;
- the list of available Worksite and the one currently active;
- the list of available Time Source and the one currently active;
Time Sources are used to feed the time to the Session. This in turns updates the position of the sky elements (Sun, Moon, Stars).
Apogy provides the following Time Sources:
A Worksite represent the physical surroundings where the Systems are being used.
While many Worksite can be defined in a given Environment, only one is active at any given time .
A Worksite contains:
Apogy provides a few specialization of Worksite for different places. The appearance of these specialized worksites will differ when viewed in the 3D Viewer.
The Sun is represented in the Sky in Apogy. Its position in the Sky is updated based on the current active TimeSource used and thy location of the Worksite. One attribute of the Sun radius is its radius : this is used to compute the apparent angular diameter of the Sun in the Sky in the 3D viewer. The Sun also provide a method used to get its irradiance given a distance.
The Sun is a Node in the topology, thus its position relative to other Node can be queried.
The Moon is represented in the Sky in Apogy (when applicable for the Worksite). Its position in the Sky is updated based on the current active TimeSource used and thy location of the Worksite. One attribute of the Moonradius is its radius : this is used to compute the apparent angular diameter of the Moon in the Sky in the 3D viewer.
The Moon is a Node in the topology, thus its position relative to other Node can be queried. An example of such use if found in the # PTUDishAntennaApogySystem.
The Star Field contains the stars that are seen in the Sky. The Star Field contains a list of Stars . The Star Field contains all the stars found the Bright Star Catalog, which includes more than 9000 stars.
- Apparent magnitude which defines how bright the star appears;
- Equatorial Coordinates that locates it on the celestial sphere;
The number of star shown in the Sky can be changed by configuring the cut-off magnitude in the 3D Viewer preferences.
A Surface Worksite is a specialization of Worksite and represent a worksite located at the surface of a celestial body. It contains a list of Map, which are component of a Worksite that contains Map Layers that are sharing a common pose relative to the Worksite origin.
In Apogy, a Map contains MapLayers that shared a common position and orientation relative to a Surface Worksite origin. If we use the analogy of an atlas, a Map represent a given region (like a page in the atlas), and the map can contain multiple layers (roads, waterway, topography).
A map layer represent data of a given nature for a given Map.
Cartesian Triangular Mesh Layer
A Cartesian Triangular Mesh Layer contains a triangular mesh that represents surface topography.
Apogy currently supports the following Cartesian Triangular Mesh Layer:
|CartesianTriangularMeshURLMapLayer||A layer that contains a mesh and uses URL to locate the mesh data.|
In Image Layer contains an image and its associated size when projected onto the Worksite. Apogy currently supports a variety of Image Layers:
Once defined, Image Layer can be projected onto Cartesian Triangular Mesh Layer through the use of Layer Presentation. Layer Presentation provides control over how the image are to be projected (transparency) and order of projections:
|The Canadian Space Agency Emulation Terrain topography with aerial imagery and discrete slopes superimposed on the topography.|
This specialization of # Surface Worksite for working on the surface of the Earth. The Earth Surface Worksite includes the following:
- The Geographical Coordinates (longitude, latitude and altitude) of its origin;
- The angle (XAxisAzimuth) between is X axis and true North.
- An Earth Sky which includes:
The position of the Sun, the Moon and the stars are dynamically updated based on the time and date provided by the active TimeSource and the location of the worksite on Earth.
The orientation of the reference frame of the Earth Surface Worksite is as follow:
Operation Call List
An Operation Call List is a simple Program that contains a list of Operation Calls that are to be invoked in the order that are found in the list. There is no flow control. Individual Operation Call can be invoke through the User Interface.
Java Script Program
An Operation Call is a specific invocation of an Operation on a Variable using a set of Parameters.
- A reference to the Variable;
- References to a Variable type member and/or feature onto which to call the Operation (if applicable);
- An Operation to be called;
- A List of Parameters to use when calling the Operation;
Apogy defines Initial Conditions which are used to capture the current states information of all System currently in use. Initial Conditions can be applied to a Session to initialize all System to a previous configuration. This is useful when testing a Program (the user can reset the System to a know state before testing a Program).
Multiple Initial Conditions can be defined and their content updated with the current System state at any time. Note that the actual data captured and System initialization is delegated to the System API Adapter implementation provided by the System developer.