Welcome to the new OpenJAUS website and thank you for reading our forum posts!

This is the developers discussion area. It is the main place to stay on top of the ongoing development of OpenJAUS. Whenever new issues or ideas come up, we'll be sure to post them here first. We hope you get involved here too!

The number one complaint that we see about OpenJAUS support is the lack of activity on our forums. With the release of the new website, we've tried to change things to address this concern. First, the forums are now more organized and easier to use. Second, we plan on moving all discussions about OpenJAUS development to the forums. This means that anything that may have been sent by email in the past, will now be open to the forums.

OpenJAUSv3.3 has been released for over a year with great success, but there is still much work to be done. The biggest technical request that we have seen is for OpenJAUS to be SAE AS-4 JAUS compatible. To do this, we need to transform OpenJAUS into the service oriented approach that is defined by SAE's JAUS Service Interface Definition Language (JSIDL) and the new JAUS Service Set (JSS) Core.

Our vision for the future is to make OpenJAUS a central SAE JAUS Runtime Framework, and allow others to develop components and services that use the framework to interoperate. We would like to open the website for people to offer freeware or commercial applications that integrate with OpenJAUS. This model has worked well for other open source projects such as Eclipse and Jooomla. We hope this will be the equivalent for the robotics and unmanned systems community. The net result will be robotic systems that are more modular and a greater ability for those systems to interoperate out-of-the-box.

Our plan for the future runtime framework (what used to be called node manager, node manger interface, and component framework) is to make a very robust system with all of the features necessary to streamline unmanned systems integration. The previous releases have mostly been written by Danny Kent and myself, with the help of some other folks from UF, and testing largely done by the small robotics business community. This new framework will be a major effort, one that Danny and myself cannot take on alone. With OpenJAUS gaining popularity everyday we hope that you now have a vested interest in this project and that you'll join us in developing the next version of OpenJAUS as something we all can design, build and use together. This forum is the main place that we plan on coordinating this effort.

In return for assistance on OpenJAUS we will find ways to more directly benefit you as a sponsor. Part of this is already implemented, as we now have more direct visibility for our sponsors on this website.

If you are interested in getting involved, sign up for an account on our forums and sign up for the OpenJAUS newsletter. In the upcoming weeks, we will be beginning the new system design by posting and discussing requirements on the forums. Please join in!

I just wanted to chime in here and echo a lot of what Tom stated in his post.

We're very excited about the future. Every step down the path for the OpenJAUS project has been time consuming but exciting and fun. This new website (with forums, newsletters, content, FAQs, tutorials) took Tom and I about 6 weeks to pull together. But we feel like we finally have a site that is strong enough to support our vision of the future. For example, we got rid of Trac and its repository functionality to replace it with Google Code. Google Code wasn't available to us in 2006 when we started this, but its a great resource and tool.

Make sure to watch this thread and others in this forum in the near future. Now that the website effort is complete, we'll be training the bulk of our efforts on the design phase of the next-generation runtime engine (as Tom spoke about).

Thanks for your continued support and I hope we continue to hear from everyone!

Hey guys,
Wasn't sure if this was the correct thread or maybe the New System Goals thread would be a better place. However, one thing I would like to see as we begin to move forward is a fairly succinct list of development goals. Based on what I know about v3.3.0 and what I am guessing the goals of the SAE implementation might be, I imagine it might look something along these lines.


1. Develop a library that provides the functionality described in JSS Core
1a. Provide a set of examples and tutorials that outline how to develop a new service from the core services
1b. Provide a set of unit tests that allow for testing that each unit in the library is still functional


2. Develop a library that provides some (or all) of the transport layer specifications provided in AS5669A
2a. Provide a mechanism to link the transport layer to the transport service provided in goal 1.
2b. Provide a set of unit tests that allow for testing that each unit in the library is still functional


3. Develop a stand alone application that allows for multiple components to exist as separate processes and to communicate on the same node.
3a. Build the stand alone application using the libraries provided in goal 1 and goal 2.


4. Provide a working example to allow new developers to quickly test the framework.
4a. Build the example using the libraries provided in goal 1 and goal 2 and communication via the application in goal 3.


I haven't put too much thought into it but hopefully you get the idea. If I were to relate the goals basck to v3.3.0 it might look like this:

libjaus = goal 1
libopenJaus = goal 2
ojNodeManager = goal 3
ojVehicleSim = goal 4

Hey Nick,

Yep, I think this is a great idea. We need to layout specific goals and milestones. I can take a crack at it and post a schedule to the forum, then we can all put our 2 cents in. Once the plan is settled we can post it to the googlecode wiki and add tickets according to milestones to the issue tracker.

I gotta run, but I'll post more on this later.

To continue my thoughts... I think the new code base libraries will be organized a bit different from the current ones. The previous implementation when on the assumption that all JAUS entities in the system would be dependent upon a core & full message library. With the SOA version of JAUS, that's not the case.

The new design says that the messages are contained within the services. In that sense, each service will contain a library of messages. I'm thinking this will allow us to get away with simply one libopenJaus. I'm sure there will inevitebly be some users of that library that don't want all of the capabilities it provides, or may not be able to compile certain aspects of it on their system (ex: OS stuff). If that's the case, I think we can have compile flags that turn off specific parts of the library during the build.

As far as the Node Manager goes, I'm not sure if we're going to provide a stand alone one out of the box or not. I'm guessing yes, but I still don't know what this architecture means for our traditional view of the JAUS implementation.

To address your idea about project goals, I came up with a tentative schedule. I also need to make another post to discuss how I'd like to work on the system design...

I like the idea of allowing a user to pick and choose what aspects of the library to compile. We can get more into that when we decide on what will be in the library / libraries.

It seems to me that the document layout of the standard provides a pretty good library breakdown. It seems that the main focus is going to be on providing JSS Core. However, if part of the plan is to implement an ojVehicleSim equivalent then we would also need to implement some of the JSS Mobility. Also we would be implementing part or all of AS5669A.

I can see OpenJAUS providing libraries such as oj5669, ojCore, ojMobility, ojMissionPlanning, etc. I think it would be a huge undertaking to support the full service sets for all except JSS Core though, Mobility alone is pretty big, but maybe support some of the Services in Mobility, especially as an example. Other developers can add on as they need the services. One thing I would also like to see is some kind of versioning to the libraries. I personally would like to see the libraries named according to the service sets or document names, but if we decide to go with the libopenJaus naming we should keep in mind that it conflicts with the v3.3.0 naming. It would be great to be able to have both versions installed side by side. This will also play a role as the standards get updated. What version of JSS Core do we support, can we tell this quickly from the installed library name, can the libraries coexist or is it a one only situation?

The reason I like to idea of separating a transport library (AS5669) from the service sets is that it makes it fairly clean to update a single portion without affecting the rest of the system. For example, there's a AS5669 vB release and a new JSSCore vA release. I want to update the transport layer, but not the Core because all my custom services are built using the old Core, how can this be easily accomplished? (Assuming the interface from service layer to transport layer hasn't changed). If we have them all tied together in a single library it is not as easy. I have to download the new OpenJAUS release, move around all the files, maybe adjust my makefiles / project files, and then recompile the entire thing. If they're separate I download the updated library, compile it and should be able to run without any changes the other pre-existing code. I think it also allows us to update the portions of the standard that are most critical without having to repackage the entire thing unless we need to.

The schedule looks pretty good. It seems like you have set periods to discuss each of the Core services but I don't see mention of access control, management or liveness.