Kairos Autonomi:Strap-on Autonomy Systems for Existing Vehicles

    Kairos Unmanned Vehicles Collage

Headlinebanner2.png

JAUS Updates

Back to the ProntoJAUS page.

Jump to JAUS Workbench Camera Demonstration

Jump to JAUS Minimum File Example

Jump to JAUS Minimum Code Example

New JAUS Remote Windows Demonstration, posted 11.4.06

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:

  • The running processes of the remote machine are queried.
  • The running NOTEPAD.EXE application is selected and placed in the remote window.
  • Text and mouse clicks are used to enter data in the NOTEPAD on the remote vehicle.
  • The Kairos Workbench on the remote computer is now selected and operations are performed on it.
  • The validation tab is selected, and QueryHeartbeatPulse messages are sent from the remote vehicle to the host.
  • The NOTEPAD application is then reselected, and more text is shown.

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.

JAUS Workbench Camera Demonstration, posted 11.2.06

Click here to see the demonstration.

JAUS Minimum File Example, posted 10.31.06

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.

JAUS Minimum File 1

Run the MINFILE.EXE program and observe the following results:

  • Boots as Node 1 expecting to chat with Node 2
  • IP address of remote is on this machine
  • Local IP port is the JAUS standard 3794
  • Remote IP port is JAUS standard +2
  • Kairos JAUS DLL has booted from with version #\
  • The initial state of the NODE is PowerOn
  • The Node Manager component is automatically installed and it transitions to the Initialized state

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.

JAUS Minimum File 2

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.

JAUS Minimum File 3

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.

JAUS Minimum File 4

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.

JAUS Minimum File 5

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.

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.

JAUS Minimum File 6

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
Component, "", 1, 1, NodeManager, 0, 1
Component, "", 1, 1, GlobalPoseSensor, 0, 1
Component, "", 1, 1, Communicator, 0, 1
Component, "", 1, 1, DiagnosticDriver, 0, 1
Srvconn, 1, 1, NodeManager(1), 1, ReportTime, 1, 2, DiagnosticDriver(242), 1, 1, 1, 7
Interface, "", 0, UDP, local:3796, 3794
Route, 1, 2, 255, 1, 255, 255, 255, 255, 0,

“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
Component, "", 1, 2, NodeManager, 0, 1
Component, "", 1, 2, GlobalPoseSensor, 0, 1
Component, "", 1, 2, Communicator, 0, 1
Component, "", 1, 2, DiagnosticDriver, 0, 1
Srvconn, 1, 2, NodeManager(1), 1, ReportTime, 1, 1, DiagnosticDriver(242), 1, 1, 1, 2
Interface, "", 0, UDP, local:3794, 3796
Route, 1, 1, 255, 1, 1, 1, 255, 1, 0,

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.

JAUS Minimum Code Example, posted 10.31.06

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.

Run the MINCODE.EXE program and observe the following results:

  • Boots as Node 1 expecting to chat with Node 2
  • IP address of remote is on this machine
  • Local IP port is the JAUS standard 3794
  • Remote IP port is JAUS standard +2
  • KJAUS DLL has booted from with version #
  • The initial state of the NODE is PowerOn
JAUS Minimum Code 1

 

Now run MINCODE.EXE again. Since a pipe name is created for each node that is running, the instantiation number can be determined and the IP addresses can be set accordingly.

  • The JAUS Node has changed to 2, remote Node 1
  • The IP address is set as this machine
  • The local and remote IP ports are also set
JAUS Minimum Code 2

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.

JAUS Minimum Code 3

JAUS Minimum Code 4

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.

JAUS Minimum Code 5

JAUS Minimum Code 6

 

JAUS Minimum Code 7

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.

At this stage we hope that you are all a twitter because you just sent your first JAUS message from one node to another. As it turns out, the ReportHeartBeatPulse message is critical to the usage of JAUS for interoperability.

 

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:

  • Make sure that the proper support DLLs are installed
  • Reinstall the program using install defaults

If programs do not communicate:

  • Proper functioning of Ethernet is assumed
  • Both programs can be run on the same machine or different machines
  • When running on a different machine, set the report and local Ports to 3794

Back to JAUS Remote Windows Demonstration (Top)

Back to JAUS Workbench Camera Demonstration

Back to JAUS Minimum File

Back to JAUS Minimum Code

Back to the ProntoJAUS page