Vectors are implemented in theXYVectorclass and are essentially comprised of a location, direction and magnitude. They may be used in certain applications dealing with simulated or sensed forces, or simply used in a GUI application to render current fields or an instantaneous vehicle pose and
trajectory. Minimally each vector consists of a location in the x, y plane and a direction and magnitude. They may also be configured with all relevant drawing hints discussed in Section12.2. 12.6.1 String Representations for Vectors
Vector objects may be initialized from a string representation, and converted to a string represen- tation from an existing object. The following is an example:
vector = x=5,y=10,ang=45,mag=20
Alternatively, instead of expressing the vector in terms of its direction and magnitude, it may also be given in terms of its magnitude in both the x and y direction. The following vector is nearly identical, modulo rounding errors, to the above configured vector:
vector = x=5,y=10,xdot=12.142,ydot=12.142
When a vector object is serialized to a string by invoking the object’s native serialization function, the first of the two above formats will be used. The following is a string example using many of the general object fields and drawing hints available:
vector = x=5,y=10,ang=45,mag=20,label=pingu,source=simulator,type=wind,
vertex_size=2,vertex_color=red,edge_color=red,edge_size=2,head_size=12
The last parameter,"head size=12", is a drawing hint unique to the vector object and refers to how big the arrow head should be rendered. If left unspecified, it may simply be rendered at whatever size the GUI application uses by default.
12.6.2 Vectors in the pMarineViewer Application
ThepMarineViewerapplication registers for the MOOS variableVIEW VECTOR. The viewer maintains a list of vectors keyed on the label field of each incoming vector. A vector received with a thus far unique label will be added to the list of vectors rendered in the viewer. A vector received with a non-unique label will replace the vector with the same label in the memory of the viewer. This has the effect of erasing the old vector since each iteration of the viewer redraws everything, the background and all objects, from scratch several times per second.
The label is the only text rendered with the vector inpMarineViewer. Since the label is also used as the key, if the user trys to “update” the label, or use the label to convey changing information, this may inadvertently result in accumulating multiple vectors in the viewer, each drawn over one another. Instead, theVIEW VECTOR may be posted with the message to be posted in themsg=value
component. When this component is non-null, pMarineViewerrenders it instead of the contents in the label component.
Exercise 12.1: Poking a vector for visualising in pMarineViewer.
• Try running the Alpha mission again from Section4. The window should look similar to Figure 6. The uPokeDB tool is described in [4].
• Poke the MOOSDB with:
$ uPokeDB alpha.moos VIEW VECTOR=x=100,y=0,mag=40,ang=135,label=one
A vector should appear in the viewer 100 meters East of the vechicle’s starting position. • Poke the MOOSDB with:
$ uPokeDB alpha.moos VIEW VECTOR=x=100,y=-40,mag=40,ang=135,label=two vertex color=orange,vertex size=12,edge size=5,edge color=green,head size=12
A new vector should appear in the viewer 40 meters South of the first vector, with all the drawing hints from the command line.
• Poke the MOOSDB with:
$ uPokeDB alpha.moos VIEW VECTOR=x=120,y=0,mag=40,ang=135,label=one
The first vector poked will appear to have moved 20 meters to the East. Since it has the same label as the first vector, the second vector effectively replaces the first one in pMarineViewer’s memory.
13 The pMarineViewer Utility: A GUI for Mission Control
13.1 Brief Overview
The pMarineViewer application is a MOOS application written with FLTK and OpenGL for ren- dering vehicles and associated information and history during operation or simulation. The typical layout shown in Figure60is that pMarineVieweris running in its own dedicated local MOOS com- munity while simulated or real vehicles on the water transmit information in the form of a stream of node reports to the local community.
Figure 60: A common usage of the pMarineViewer is to have it running in a local MOOSDB community while receiving node reports on vehicle poise from other MOOS communities running on either real or simulated vehicles. The vehicles can also send messages with certain geometric information such as polygons and points that the view will accept and render.
The user is able manipulate a geo display to see multiple vehicle tracks and monitor key infor- mation about individual vehicles. In the primary interface mode the user is a passive observer, only able to manipulate what it sees and not able to initiate communications to the vehicles. However there are hooks available and described later in this section to allow the interface to accept field control commands.
A key variable subscribed to by pMarineViewer is the variable NODE REPORT, which has the fol- lowing structure given by an example:
NODE_REPORT = "NAME=nyak201,TYPE=kayak,UTC_TIME=1195844687.236,X=37.49,Y=-47.36, SPD=2.40,HDG=11.17,DEPTH=0"
Reports from different vehicles are sorted by their vehicle name and stored in histories locally in the pMarineViewer application. The NODE REPORT is generated by the vehicles based on either sensor information, e.g., GPS or compass, or based on a local vehicle simulator.