Home   Data   Documents   Tools   Links

The following links provide the JAUS Reference Architecture 3.2 in machine readable format. The formats are such that you should be able to get them into your system and use them right away. If you would like to see a format that is not listed here, let us know and we will make it so.

 

  File Catagory    File Contents File Format   Download
  JAUS Elements Components and Messages CSV JAUSElements.jdr
  JAUS Parameters Messages with Parameters CSV JAUSQualificationDoc.txt
  Dynamic Elements Dynamic Components and Messages CSV Standard&Dynamic_JAUSElements.txt

  

JAUS Interoperability Hints

The JAUS Reference Architecture 3.2 defines the mechanics of implementing the JAUS standard. These mechanics are really just definitions of content such as components, messages, and math. Interoperability is really the context where this content is used. There are a number of hints that will assist with interoperability among existing JAUS systems:

 

ReportHeartbeatPulse

In order for other nodes to be able to determine the presence of your node you need to perform some form of discovery process. JAUS interoperable agreements among the JAUS community have settled on a few common rules to help determine the presence of a node. The following rules apply:

  1. The ReportHeartbeatPulse message must be sent from your node every 1 second

  2. It cannot be a service connection but must a normal message

  3. The destination of the node must be set to a broadcast, but there are differences

    • JCTS destination 255,255,255,255

    • Mobius destination 255,255,1,1

  4. The message must be sent multicast to 224.1.0.1, port 3794

  5. The message must be sent from port 3794

  6. The message must be sent via UDP

  7. The sequence number must increment

Transport Header

Usage of JAUS system over various internet facilities has necessitated that various transport headers be added to the standard JAUS message in order for it to be recognized. While this is a interoperable requirement, it is currently not covered in the standard.

  1. Add JAUS01.0 to the front of every JAUS message that is transmitted over UDP

  2. Remove the JAUS01.0 from the front of every JAUS message after it is received but before it is processed.

Video Transmission

Currently video that are sent over the JAUS protocol is in the form of Moving JPEG or MJPEG. The are many definitions of what MJPEG is (Masked, Motion, or Moving). In a JAUS context it is a sequence of JPEG images that are transmitted at a full motion frame rate, 8 frames per second or greater. There seems to be no discussion on how to send the images except for the large the RA 3.2 rules concerning the transmission of large data sets. There are really two ways to send these images as video over JAUS using the ReportImage. Not too many folks are sending video over JAUS at this point so interoperability is undefined as of yet

1. Break up the images into a number of records such that the resultant packet size is less than the maximum 4079 byte size of the standard JAUS message and then send the image in multiple JAUS ReportImage messages. Use the control fields and the sequence numbers to reassemble the image on the other side. This method does not support more than one video stream at any one time from a VisualSensor component. Additionally there are challenges if the ReportImage stream is sent as a service connection while other service connections are sent from the component

 

2. Place a sub-header in the ReportImage message that provides the name of the image, defines the size of the entire images to be sent and the current sub frame number of the image being sent.

  1. Filename, 12 bytes long, string

  2. Size, 4 bytes, unsigned integer

  3. Sequence, 2 bytes, unsigned short integer

  4. Block, 0 to 4071 bytes in length, typically 2K

This method allows multiple video streams to sent and reassembled from multiple components. Service connection video is implementable without interleave issues. Image reassembly does not depend on message sequence numbers that may be out of sequence because of other activities.

These are just a few. We will add many more over time. Most likely Reference Architecture 3.3 which is due to be released 2nd quarter 2007 will address many of these unwritten interoperability issues.

 

Revisions