Sep 25 - Oct 10, 2019
Back to the ProntoJAUS page.
Click here to see the video.
This video demonstrates the general purpose diagnostic capability possible when using the Kairos ProntoJAUS. Kairos uses Generic Message as a standard approach for accessing common JAUS components in unique ways. This limits the need to always define different messages for unique applications. The Kairos Autonomi suite of Generic JAUS elements consist of QueryGeneric, SetGeneric, ReportGeneric, GenericSensor and GenericDriver.
The Kairos JAUS Workbench is located on a host computer and on a remote, JAUS-enabled vehicle retrofitted with the Pronto4™ kit. The following steps are performed to take over the operation of a window on the remote machine and then perform some actions:
Note how easy it is to change between applications on the remote machine. This approach significantly simplifies diagnostics on the remote by providing access through JAUS to any application that generates and uses a GUI. Maintenance is standardized through a single set of GUIs, both on the remote and local machines.
All this is accomplished with the use of a Generic Message, a Report Image Message and a Visual Sensor Component.
Click here to see the demonstration.
This example shows how to implement the minimum code required to create a functional JAUS system that has the capability to read a descriptor file defining the entire “a priori” nature of a JAUS installation. The resultant executable can be run on a standard PC under the Windows operating system multiple times. Each instantiation of the program creates a unique node that is part of an entire JAUS system. A limited Kairos Autonomi™ JAUS (KJAUS) DLL is supplied to allow the user to create a JAUS system on his or her desktop and experiment. This example will work with either the limited KJAUS DLL or the full KJAUS DLL.
Run the MINFILE.EXE program and observe the following results:
Execute MINFILE.EXE a second time and it will recognize that it as already been run before and instantiate as Node 2. There are Node-specific INI files that are shown above the transaction window. These files contain the descriptor information that we will load and “execute” upon these nodes.
Press the “Load Descriptor File” button on each running MINFILE.EXE program and a unique descriptor will be loaded. One is for Node 1 and the other is for Node 2. These descriptor files define the components, interfaces, routes, service connections and much more for the JAUS systems represented by them. They are human readable and text editable. Changes in the JAUS system can be immediately made by making changes in the descriptor file and loading.
The descriptor file for Node 1 is loaded and a number of transaction statements immediately occur in the transaction window. Several components are installed. A duplicate component install is requested, the Node Manager and it is ignored. A service connection is created from Node 1 to Node 2.
On Node 2, since the descriptor file has not yet been loaded (unless you loaded it), you will see that the sent message is going to a component that does not exist on Node 2. Press the ”Load Descriptor File” and then the transaction window will stop showing new “Component does not exist” messages. This is because the component is now installed.
There were service connections installed on each node that are sending Report Time messages from Node 1 to Node 2 and from Node 2 to Node 1. The rate of each can be seen in the Service Connection frame as delivered messages.
The next step will be to send a request heartbeat from one node to another. We will send that from node 1 to node2 and receive the response back on node 2. Each node will show in its transaction window the progression of our actions.
If we press QUERY again the process will repeat and the ReportHeartBeatPulse contents will increase and change. Try pressing QUERY from Node 2 and observe the results: similar but in the opposite direction.
The text file used as a descriptor file is of a very simple format. This is actually the same format as generated by the KJAUS Builder or the Kairos Message QueryStructure when a node is queried for its internal structure:
address, 1, 1, NodeManager, 1
“Address” sets the address of the node that is reading the file and the components are defined by each of the “Component” lines. “Srvconn” sets up and initiates a service connection. The interface and routing are also defined in the file. The file for both Node 1 and Node 2 are shown. Detail for these files can be found in the KJAUS Builder documentation.
address, 1, 2, NodeManager, 1
That was all really nice, Kairos, but what happened.
Assuming that you have read and understood the MINCODE example, we’ll explain what MINFILE does.
The descriptor file contains all of the information to configure a JAUS system. It can define all sub-system, nodes, components, interfaces, routes, service connections, initial messages, etc.
Each Node booted and then loaded its descriptor file. The defined components were instantiated, and a service connection of the “Report Time” message was created on each node from their Node Manager to the other. The service connection messages are continuously transmitted between the nodes. The “Query” allows requests for “QueryHeartBeatPulse” to be sent, received and processed as desired.
This example shows how to implement the minimum code required to create a functional JAUS system. The resultant executable can be run on a standard PC under the Windows operating system multiple times. Each instantiation of the program creates a unique node that is part of an entire JAUS system. A limited Kairos Autonomi™ JAUS (KJAUS) DLL is supplied to allow the user to create a JAUS system on his or her desktop and experiment. This example will work with either the limited KJAUS DLL or the full KJAUS DLL.
The next step towards exercising this demo is to start up each node. Press START on each node.
You will note that each side (the following two pictures) has installed two components: the Node Manager and the Communicator components. They are assigned as separate node numbers and their IP addresses and ports aim at each other. This is good because now they can chat.
The next step will be to send a request heartbeat from one Node to another. We will send that from Node 1 to Node 2 and receive the response back on Node 2. Each Node will show in its transaction window the progression of our actions.
Press QUERY on node 1 and observe that transaction activity shows up on node 1 and node 2. Note that the QueryHeartBeatPulse was routed out and the ReportHeartBeatPulse was routed back and its contents displayed. A sequential count as well as a time-based value.
So what just happened?
Two programs were executed. We will refer to a running executable access the Kairos JAUS DLL as a Node and the instance of Kairos JAUS DLL as KJAUS. Each Node created its own copy of the data space of KJAUS in its own thread. Only one copy of the KJAUS executable portion was loaded though. When the unique instance of the KJAUS which was initialized was loaded, it sent several transaction statements that are viewed in the transaction window of each Node.
As the Nodes powered up they determined if another instance was running, primarily by checking for a unique named pipe assigned to each Node. These Nodes can communicate with each other through UDP by port reflection, over the Ethernet from one machine to another or through these named pipes. In this example the IP address of the machine is used to create a communications interface and then a route.
JAUS messages go from one Node to another and in our case from one executable to another through a Node Manager / Communicator pair. The Node Manager and Communicator are actual JAUS components and are used in their defined roles.
When the Nodes were first executed they entered the PowerOn state. This occurred because the Nodes internally received a PowerUp event in the Finite State Machine (FSM). When the Nodes were “Started” they received an “Initialize” event when the component was installed. The Primary <STATE> statement is a local executable event that occurs during program execution as the FSM for the Node Manager component changes states. This FSM behavior can be found as part of the JAUS Reference Architecture.
So now the Nodes have booted and some initial components have been installed. When QUERY was pressed a QueryHeartBeatPulse message was generated and sent through the defined UDP interface using routing information from Node 1 to Node 2. The QueryHeartBeatPulse was routed to the proper component on Node 2 by the Node Manager (itself) and then the requested information was embodied in a ReportHeartBeatPulse message and then rerouted back to the requesting Node and requesting component. A predefined interface and route was used to return the message, and it was consumed by the requestor. After it was consumed, KJAUS generated an event <AFTERDELIVERY> that was used to grab the information in the returned message and present it as a statement in the transaction window.
We have basically set up the “a priori” nature of a JAUS system with UDP interfaces and defined routes from one Node to another and then formed a message that was sent from one source component to another target component on the other node. The message was received, processed and a response was generated. That response was sent back through a defined return path to the requesting component, decomposed and acted upon.
This is the core functionality of JAUS, although this is a simple example. We just build upon this simple example to make complex unmanned, interoperable systems.
Example Trouble Shooting
Although this example is quite simple in function, a considerable amount of technology is used and needs to be functioning properly.
If programs do not execute:
If programs do not communicate:
Back to the ProntoJAUS page