The Javelin Video Interactive Missile Simulator, developed for the Robotics Group at DCIEM, was undertaken to demonstrate the suitability of VIG technology in the area of generic shoulder-mounted weapon simulators. As a follow-up to the Leopard VIG simulator (LVIGS), a critical goal of this project was the reuse of a majority of LVIGS software components. This was made much easier through object-oriented design, and the use of C++, a fully object-oriented language. The implementation was developed on a 486 class PC. The simulator required real-time frame capture, zoom, pan, scroll, and CGI overlay.
Like LVIGS, the Javelin Simulator is event-driven. Events originate from objects closely modelling actual input devices, propagate through the system affecting the major software components and those objects closely modelling (and driving) output devices. As an example, consider the pressing of the trigger as generating an event causing the missile in the launcher to be fired. This in turn affects the display as the missile moves out over the terrain.
Tracking the movements of the launcher is handled by the SR Research Eye3 system. A specially designed structure holding four small light sources is attached to the launcher and monitored by an external camera. The image acquired is transferred to a board inside the PC which then translates it into three spatial coordinates and three rotations.
The terrain model from LVIGS was used almost without any modification (except for the addition of flying targets). Other components that translated with no or minimal modifications were mission management, camera correction, and simulation playback and dispatching. The simulation driver, as well as the display and sound managers, however, underwent major modifications. OOP allowed code reuse.
Two methods of communcation between objects were used in the Javelin Simulator: direct notification and observer notification. Direct notification is used in situations where one object knows about another object because of some relationship or dependence on it and thus can communciate directly with it. Observer notification is appropriate when communication is required between two completely independant objects. As an example of these two methods, consider a simple switch such as the Trigger which must communicate with the Launcher. If it decided to have the Trigger directly notify the Launcher when it is pressed, then certainly an instance of a generic switch is not suitable the generic switch doesn't (and shouldn't) know anything about launchers. The solution for this using the direct notification method is to derive a new class from the generic switch such as a launcher switch that does know all about launchers and will pass a fire event to it when pressed. The other solution is to use the observer notification method where the Launcher requests that the Trigger (still a generic switch) send a message to it whenever a transition is detected. The advantage of this solution is that a new class need not be created just to pass this one message. If the launcher trigger had some other features unique to launchers such as the ability to lock and unlock, then the obvious need for a new subclass anyway makes this choice less clear.
Software Components
The GVIGS architecture can be broken down into three major software components: modelling, hardware support, and simulation support. Each of these will be examined in the sections below.
Modelling Components
Software models are abstract representations of real-world entities used in shoulder mounted launcher systems that cannot be directly implemented in the simulation environment. An example of this would be the missile which is fired out of the tube in the computer model but of course never leaves the tube (if even present) in the physical simulation environment.
Two major abstract systems are modelled in the Javelin Simulator: terrain and missile. The terrain model is comprised of objects that define and deform the terrain such as hills, obstacles, and targets. The missile model includes the Launcher, missiles, and the Guidance System.
The Terrain Model
Encompassing terrain objects (hills), obstacles, targets and the classes that manage these, the terrain model is the largest system in the Javelin Simulator. Its main responsibilites are in determining the visibility of objects and the detection of missile impacts.
Terrain Objects
Terrain objects define the plains and hills in the terrain model. A terrain object consists of a set of markers and a front range offset. A terrain model object marker can be thought of as a point or pillar used to outline or construct an object. Each marker has an azimuth, range, and a top and bottom elevation (which may be equal) in terrain model coordinates. Also included in a marker are top and bottom altitudes which are generated from the elevations and range. Terrain model object markers are common to all types of terrain model objects and indicate the current location in the terrain model.
The front range offset value specifies how much closer the bottom of each marker in the terrain object is closer to the VIG than the top. A value of zero is special in that it signifies that only the top point on each marker is to be considered. This provides a convenient method for outlining distant hills and other terrain features where a single point for each azimuth is sufficient.
Targets
Two types of targets exist in the Javelin Simulator: video based and CGI based (popup). Video based targets are visible on the raw video disc imagery while CGI based are placed on the video during editing and recreated during the simulation. Both types of targets are represented in the terrain model by a sequence of target location nodes which are marker pair, frame number associations.
Added to the Javelin Simulator for targets was the attribute for flying. It presented an interesting design problem in that flying targets must not deform the terrain but still must be involved in all terrain model queries.
The Missile Model
The Javelin missile model is distributed across three components: missiles, the Launcher, and the Guidance System. Missiles are fired from the Launcher and controlled by the Guidance System.
Missiles
The firing sequence and flight characteristics for GVIGS missiles are based on the TOW missile model used in TVIGS. The "TOW-like" missile implemented has a gyros on stage and two burn stages each followed by a coasting stage. To aid in the experimentation of different flight models, the missile was designed so that the duration of each stage and the thrust of the two burn stages are passed in at creation The display and visibility of the missile is driven by a flashing beacon which cycles on and off every half second.
There are three significant events in the lifetime of a Javelin missile: firing, launch, and impact. If a missile is present in the tube when the Launcher detects a fire switch transition, it is fired. The fire event schedules the launch sequence and sets the missile as updateable by the Simulation Driver. With the gyros run for the appropriate duration, the first stage is fired and the missile is launched.
At launch, the missile first retrieves it orientation from the Launcher. Next the launch sound is started and the Launcher informed of the launch event (see the Launcher section below for details). Finally, the missile hooks itself into the display system using the beacon bitmap for its sprite.
When in flight, the missile calls the Terrain Manager at update to check for impacts. When an impact is detected, the explosion sound is started and the beacon bitmap is replaced with that for a terrain or target explosion. After the explosion has completed, the missile is destroyed removing all hooks into the simulation and display systems and killing all events owned in the sound system.
The Launcher
The Launcher is a complex object. In addition to loading, firing and guiding missiles, it receives the position and orientation information determined by \globalVar{theTracker} and drives the custom force generation device (FGD).
The Guidance System
The Javelin guidance system is modelled on a radio controlled cone of influence system. Within a certain flight time, the missile is controlled inside a wide angle and outside that time, a narrow angle. The time and the angles of control are given as parameters at construction.
A missile is passed to the Guidance System from the Launcher when leaving the tube through the guide method and it is observed. Knowing the initial vane deflections, the Guidance System then proceeds to flip the vanes as needed to keep the missile on or moving towards the sight. The missile is guidable only when inside the cone of influence and the beacon is on and visible from the Launcher. As an observer of the missile, the Guidance System is notified on each movement. It uses the position and visibility passed to determine the control response.
The Mission Editor
The Mission Editor is a standalone program used to create and edit VIGS missions. This consists of five steps:
Quantify the camera movement (azimuth and elevation) that takes place over the course of the mission.
Specify the base plane, that is, the horizontal plane that extends to the horizon.
Identify the significant terrain objects such as hills and valleys.
Identify the size, position and movement of video targets.
Create popup targets that will appear and disappear at specified times and places during the mission.