.. .. Copyright (c) 2004-2014 Laboratório de Sistemas e Tecnologia Subaquática and Authors .. All rights reserved. .. Faculdade de Engenharia da Universidade do Porto .. Departamento de Engenharia Electrotécnica e de Computadores .. Rua Dr. Roberto Frias s/n, 4200-465 Porto, Portugal .. .. For more information please see . .. .. $Id:: concepts.rst 548 2014-06-01 13:21:35Z pdias $: .. section to add wrapping chapter 4, 5 and 6 .. Neptus Overview - Design concepts and software architecture .. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; .. _ref_concepts: .. General Information .. ******************* Essential Information ********************* Neptus is a C4I (Command, Control, Communications, and Intelligence) framework that is used to command autonomous vehicles. The core logical interface to talk to the system is the Inter-Module Communications |TM| (IMC), that is developed and maintained by |lsts|. IMC is a message-oriented protocol which defines a set of messages that together define the inter-connection between the systems and Neptus. .. This stands for Inter-Module Communications and is developed and maintained by |lsts|. Getting Systems to Communicate ============================== .. _sec_announce: Announce -------- .. This is a IMC message. This message contains some useful information that lets the surrounding systems to connect to them. Before going into detail of how to connect to a vehicle let us introduce the notion of **Announce**. *Announce* is a IMC message, containing the information that will allow the surrounding systems to connect to them. This is done by indicating which ports are open to connect to. As an example look at the following URIs announced from Neptus: :: imc+udp://127.0.0.1:6001/ imc+tcp://127.0.0.1:6001/ This indicates that port :samp:`6001` is opened for IMC messages for both UDP and TCP protocols. Another important peace of information, among others, is that in the *Announce* message it is also included the system location (e.g. LAUV location). .. One more important peace of information, among others, that also comes in the announce is the system location. .. NOTE:: |admonition_note| Since the system location is received through *Announce*, even if there aren't any receiving messages through normal channels, it is still possible to know and display systems' locations. .. Because of receiving location of the system through Announce, even if we are not receiving messages through the normal channels, we can display the systems' locations. The *Announce* message is sent approximately every 10 seconds. .. _sec_comms_connections: Connections ----------- IMC messages employ the communication protocols UDP (unicast, broadcast and multicast) and TCP over IP. .. The communication protocols used for the transfer of IMC messages are UDP (unicast, broadcast, and multicast) and TCP over IP. When Neptus is started, three access ports of IMC communication protocol are opened: two UDP, and one TCP. .. When Neptus is started, some IMC protocol communication accesses are opened: two UDP, and one TCP. One UDP communication access port is opened for the single purpose of listening for Announce messages. This port is **fixed** and can be one of the :samp:`[30100, 30101, 30102, 30103, 30104]` interval. The listener can connect to any one of these ports. The sender must send the announce message using UDP broadcast and multicast to all of these ports. The address to send these messages is :samp:`224.0.75.69`. **The port interval and address are fixed and should not be changed**. .. WARNING:: |admonition_warning| These values **SHOULD NOT** be changed in normal operation. So avoid changes to any preferences/settings that are named *IMC Multicast \** or *IMC Broadcast \**. The second UDP access port is opened for unicast IMC messages. This will be announced as explained before. Port :samp:`6001` is normally the opened one in Neptus and :samp:`6002` for the vehicles. This port will be used for normal UDP IMC communication. The majority of the messages circulate through this ports. Additionally a TCP access server port is also available. This is used for transmitting messages that are by nature more sensitive and their destination is known to be reached. .. Additionally a TCP access server port is also available. This is used for transmitting messages that are by nature more sensitive and should be known that arrived to the destination. Connecting to a Vehicle Phases ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Next, we describe the steps that happen in the two systems connection phase. #. Start the communications hub (this is where the router is); #. The Neptus and the vehicle are started. The order is not important; #. Both systems will start announcing their points of connection; #. Neptus will pick up the announce of the vehicle and starts transmitting messages to it (See on :ref:`ref_systems_list` the :ref:`table_con_systems_list_color_codes` and :ref:`table_con_systems_list_symbology_description_connectivity`); a). This will trigger the vehicle to send messages to Neptus; #. Both systems are connected. .. TIP:: |admonition_TIP| The :ref:`ref_systems_list` is a good point to check the connection state from Neptus to a system. .. _sec_neptus_apps: Operators Interfaces ==================== Neptus presents itself in two main interfaces: the **operator console**, and the **review and analysis** (see figure :ref:`fig_console_and_mra`). .. The console is to be used for planning and operating the vehicles' missions. The review and analysis, .. or MRA, allows to see the mission collected data. .. _fig_console_and_mra: .. figure:: _assets/console_and_mra.png :scale: 100% Operator Console (left) and Review and Analysis (right) The **operator console** supports the planning, execution, and (simplified) review phases. In the figure we see one possible configuration of the console. As we can see in the figure, the console interface is divided into two main parts: the mission map on the left and the planning elements and controls to the right. The mission map (left) is where we have the virtual representation of the mission site with the world map, systems location, and data revision overlays. For the world map, the user can choose among a set of available options: tiles from Open Street Map, Google Maps, Virtual Earth, S57 nautical charts or other Internet mapping tile sources. On the latter they are downloaded automatically as needed from the Internet, while on the S57 nautical charts it is required for the user to have compatible charts stored on disk. On the right side of the console, the vehicle command widgets comprise plan execution controls and, bellow, the mission tree with the elements such as LBL beacon transducer positions and mission plans (both local to the console or stored in the LAUV plan database). Less used widgets are available only by pop-up dialog windows (like the ones seen on the figure bottom left, showing LBL ranges and chronometer) that can be quickly switched on or off by shortcut keys. .. and the user can switch their visibility on or off quickly by using accelerator keys. The operator console can have various configurations that allow the customization of a specific vehicle or mission situation. So depending on the configuration loaded, the console may have different components/layouts. Additionally each console configuration can hold different profiles that make it possible to change the layout of its components in operation. The Mission Review and Analysis (MRA) is the interface used to analyse produced data. There are several visualizations available in MRA and they also vary according to data availability (sensor payloads are activated only on operator request). MRA allows inspection of all logged IMC message in both a tabular format or by plotting data present on the messages in time-series plots. More console widgets and MRA visualizations are available, others can be added to Neptus as plug-ins. .. Insertion of the core concepts section .. include:: coreConcepts.rst-i