-
Notifications
You must be signed in to change notification settings - Fork 42
AMASE Scenario Files
AMASE scenarios describe the data content that is used by AMASE to execute simulations. AMASE scenario development involves the LMCP data interface, the Setup Tool, and the CMASI data protocol.
Several examples are provided throughout this section. It is recommended that the reader load and run these examples in AMASE. Furthermore, experimentation is key to learning AMASE, as is true with most software products. Users should use examples as a basis for more detailed scenario development
AMASE loads scenarios from files in the XML format. XML is a human and machine readable text format that defines a tree structure of data. AMASE includes a Setup Tool application that aids the user in developing scenarios using graphical interfaces, but it is recommended that the reader become familiar with XML syntax and structure, since hand-editing files is sometimes necessary. This section describes the scenario file format using XML nomenclature and examples. More information is available here.
AMASE scenario files typically follow the structure shown below.
<AMASE>
<ScenarioData>
<SimulationView LongExtent="0.05" Latitude="1.5119" Longitude="-132.525"/>
<ScenarioName>Test Scenario</ScenarioName>
<Date>24/04/2008:00:00:00</Date>
<ScenarioDuration>600</ScenarioDuration>
</ScenarioData>
<ScenarioEventList>
<!-- LMCP serialized events go here -->
</ScenarioEventList>
<AMASE>Scenario files should start with the top-level name “AMASE”. The two major sections of a scenario file are the ScenarioData and ScenarioEventList, as shown in the figure. Other sections can be included in a scenario file. See later sections of this document for a discussion of custom sections in scenario files. The ScenarioData section of the scenario file includes metadata that describes the scenario being loaded. This section is used by AMASE plugins. In particular, the SimulationView section enables map displays to start with an appropriate view point for the scenario. The ScenarioDuration parameter aids constructive simulation tools by denoting when a scenario is finished. The Date field is used to denote when a scenario was last edited.
The heart of an AMASE scenario is the ScenarioEventList. This section includes all of the “events” that are dispatched as part of the scenario definition. The next section discusses scenario events.
Scenario events are XML representations of LMCP data objects. LMCP is the native data language used by AMASE to send and receive events throughout the application and externally connected clients. LMCP data objects can be serialized into XML according to the LMCP standard. (See the LMCP Guide for more information on serializing LMCP objects as XML.) AMASE uses the LMCP XML protocol as a basis for encoding events in AMASE scenario files. AMASE deserializes these events at runtime and dispatches them to the simulation. The figure below shows an example of a scenario event. In this case, an AreaSearchTask (part of the CMASI message set) has been declared. AMASE follows the LMCP XML definition to describe all of the fields of the object. Additionally, a “Time” attribute is included to tell AMASE when to dispatch the event, in simulation time. In this case, the event is dispatched at scenario load time (or 0.0 seconds). If it were non-zero, the event would be dispatched by the simulation at the prescribed time.
Note that scenario events must be time-ordered to be properly dispatched. For instance, if an event with a time of 10 seconds is listed later in the event list than an event with a time tag of 20 seconds, both events will be dispatched 20 seconds into the simulation. An event that does not include a time attribute is assumed to have the same time value as the preceding event.
<AreaSearchTask Time="0" Series="CMASI">
<SearchArea>
<Polygon Series="CMASI">
<BoundaryPoints>
<Location3D Series="CMASI">
<Latitude>1.0</Latitude>
<Longitude>-10.0</Longitude>
</Location3D>
<!-- More boundary points -->
</BoundaryPoints>
</Polygon>
</SearchArea>
<ViewAngleList/>
<DesiredWavelengthBands>
<WavelengthBand>EO</WavelengthBand>
</DesiredWavelengthBands>
<DwellTime>4</DwellTime>
<GroundSampleDistance>0.5</GroundSampleDistance>
<TaskID>1</TaskID>
<Label/>
<RevisitRate>0.0</RevisitRate>
<Parameters/>
<Priority>0</Priority>
<Required>true</Required>
</AreaSearchTask>Since scenario events are serialized LMCP objects, it is important to understand how AMASE uses LMCP to handle events. LMCP uses a set of data definitions called MDMs. Each MDM describes a set of data or “messages” that can be serialized or deserialized by LMCP. The primary MDMs used by AMASE are CMASI and ENTITIES. These MDMs describe the data for defining entities (such as aircraft and ground vehicles), zones (such as Keep-In and Keep-Out boundaries), tasks for aircraft and ground entities to execute, and some support data such as Location2D and Location3D, which define geographic coordinates. LMCP is built using the PackageMaker tool to include all of the MDMs that are needed for a given application. In order for AMASE to read and write these objects, the LMCP build must include all of the data types that are described in the scenario files. For instance, if a user needs to extend CMASI to include a new type of task, and then includes that task as part of a scenario file, then he/she must ensure that AMASE runs with the Java classes necessary to load all of the objects for that new MDM.
Example scenarios are provided in the AMASE development kit in the example scenarios directory.
In this example, a single aircraft is defined and commanded to fly a continuous route of waypoints. At one of the waypoints, it’s camera is commanded to stare at a geographic point. This example uses several aspects of the CMASI data protocol, including AirVehicleConfiguration, AirVehicleState, MissionCommand, and Waypoint. In order for an aircraft to be properly loaded by AMASE, it must have an AirVehicleConfiguration, and AirVehicleState defined in the scenario. The AirVehicleConfiguration declares the aircraft, and describes the payloads and dynamic constraints. AirVehicleState declares an initial operating condition for the aircraft as well as any payloads that are on the aircraft.
The aircraft in this example includes a simple EO camera that is mounted on a gimbal. In CMASI, gimbals are defined using a GimbalConfiguration object. The EO camera is defined using a CameraConfiguration. The camera is “added” to the gimbal by denoting the camera ID in the gimbal’s list of contained sensors. The aircraft is initialized using an AirVehicleState object. The AirVehicleState must include a valid speed value to operate correctly. The aircraft model uses the declared AirVehicleState to initialize the kinematics properties. Also, each payload (in this case a gimbal and a camera) is initialized with the declared state object. The AirVehicleConfiguration also includes a NominalFlightProfile and a list of alternate flight profiles. These profiles are used by aircraft management tools and models to understand the flight properties of an aircraft. The NominalFlight profile cannot be null, but the list of alternate profiles can be empty. The nominal profile describes how the aircraft flies at its design condition. Alternative profiles can be used to describe other modes of flight, such as dash, climb, or descent.
By examining the execution of the scenario in AMASE, one can see a number of features. When the scenario starts, there is no route prescribed for the aircraft. At 5 seconds into the simulation, a route appears. The waypoints form a continuous loop, because the NextWaypoint field of the last waypoint is set to the ID of the first waypoint in the route. The aircraft will fly this route until a new navigational action is commanded. At the second waypoint, the gimbal is slewed to stare at a fixed location. The gimbal continues to stare at this point throughout the mission. Note that as the aircraft banks, the footprint of the camera cannot remain fixed on the designated point due to the banking of the aircraft. When the aircraft returns to level flight, the camera again fixes on the point.
The route also makes use of the flight profiles defined for the aircraft. The waypoints vary in altitude and speed along the route, and the model manages speed, altitude, and energy usage as it traverses the prescribed path. Some of the waypoints are designated as “TurnShort” while others are “TurnPast”. This governs when the aircraft begins its turn toward the next waypoint.
This example uses the aircraft from example 1, but commands loiter actions in place of waypoints. The CMASI protocol supports three types of loiters – Circular, Figure Eight, and Racetrack. This example shows each type of loiter executed for a fixed amount of time. Instead of a CMASI MissionCommand, this example uses the CMASI defined VehicleActionCommand. The loiters are added as actions to the command. Each action is executed upon completion of the previous action.
The CMASI data protocol includes representations of tasks and zones for the purposes of mission planning. This example shows Keep-In and Keep-Out zones as well as examples of the three basic search tasks: point search, area search, and line search. Zones and the AreaSearchTask both use the geometry system of CMASI. The example shows Rectangle, Polygon, and Circle geometries.