JAUS: a testament to poor design and early adoption.
Written 2008-06-10
Tags:Robot Message passing Application programming interface Endianness JAUS
Suppose two very different robots meet each other some day. Wouldn't it be wonderful if they could handshake, and then talk to each other in a very nice, simple, predefined way. It's such a wonderful concept. In fact, it is such a wonderful concept that the US Department of Defense wanted it done, so it put together a plan. JAUS is what they invented. I went to a conference last week to hear about it.
JAUS (the Joint Architecture for Unmanned Systems) is an acronym for exactly what it does not do. Joint-usually meaning that the team that worked on it is from a diverse group, but I suspect that the group did not contain any experienced network programmers because of one glaring error.
Now, they also call JAUS an architecture. To say that, is to say that something can be built on JAUS. However, the only thing that JAUS is good at doing, is message passing. You know what else is good for message passing? UDP. JAUS is a decent multi-component message passing standard, but because the rest of JAUS is so dysfunctional, you can't really rely on JAUS messages to go where you want them to, do what you intend them to do, or accomplish much of anything useful. You know what else is good at putting data where it belongs? IP addresses and TCP ports.
Back to the two robots meeting in a field. Robot A has data for Robot B. These two robots are within PAN(personal area network) range of each other, so they can send data back and forth. The only question is: can they understand each other? Probably not. What if Robot A and Robot B were designed, built, and programmed by the same people? Well...maybe. The problem is that JAUS has its own identification system built into the JAUS header. The JAUS identification system lets you specify which component you want to message behind the same IP address. So, suppose A wants to ask B where it is located. A would look up the identifier for position that the programmers for A used and query B with it. The problem? B might not use the same identifier as A did. At best, B will ignore unknown messages from A. At worst, a "where are you?" from A could be a "fire weapon" command. JAUS does have some default records bolted on to the architecture now, but don't trust it: if your robot has to communicate with an older JAUS implementation, you've got nothing and JAUS gains you nothing. You'll have to keep records of each set of JAUS protocols for every revision, which is remarkably hard to do with a closed standard.
JAUS (the Joint Architecture for Unmanned Systems) is an acronym for exactly what it does not do. Joint-usually meaning that the team that worked on it is from a diverse group, but I suspect that the group did not contain any experienced network programmers because of one glaring error.
Networks have been big endian since the beginning of time(teletypes), and from the time x86 workarounds have been in place, programmers have been using things like htons() and ntohs() to make sure their data is in the proper format for networks( big endian ). Not so with JAUS! With JAUS, x86 programmers no long have to worry about network byte safety, because everyone else will!That's the level of enthusiasm about this particular item the speaker had. I suspect that the JAUS folks first started laying out some code and later discovered that JAUS on Macs couldn't talk to JAUS on PCs. Next they probably figured out what endian-ness is. The speaker basically recommended I keep two copies of all code: One for big-endian, and one for little-endian.
Now, they also call JAUS an architecture. To say that, is to say that something can be built on JAUS. However, the only thing that JAUS is good at doing, is message passing. You know what else is good for message passing? UDP. JAUS is a decent multi-component message passing standard, but because the rest of JAUS is so dysfunctional, you can't really rely on JAUS messages to go where you want them to, do what you intend them to do, or accomplish much of anything useful. You know what else is good at putting data where it belongs? IP addresses and TCP ports.
Back to the two robots meeting in a field. Robot A has data for Robot B. These two robots are within PAN(personal area network) range of each other, so they can send data back and forth. The only question is: can they understand each other? Probably not. What if Robot A and Robot B were designed, built, and programmed by the same people? Well...maybe. The problem is that JAUS has its own identification system built into the JAUS header. The JAUS identification system lets you specify which component you want to message behind the same IP address. So, suppose A wants to ask B where it is located. A would look up the identifier for position that the programmers for A used and query B with it. The problem? B might not use the same identifier as A did. At best, B will ignore unknown messages from A. At worst, a "where are you?" from A could be a "fire weapon" command. JAUS does have some default records bolted on to the architecture now, but don't trust it: if your robot has to communicate with an older JAUS implementation, you've got nothing and JAUS gains you nothing. You'll have to keep records of each set of JAUS protocols for every revision, which is remarkably hard to do with a closed standard.