Aria and Teleoperation

[1]

Hello,

  We are currently working on a semi-autonomous teleoperation system and
  are experimenting with the Pioneer 2-DX (with onboard computer).  We
  would like to use Aria for various reasons, so I thought I would share
  our ideas and maybe get some feedback.

  First, we have to decide on a programming language for the application
  that will do the actual driving of the robot. This application will run
  on the onboard computer. Our initial ideas were:    

    1) Using C++ and Aria; wrapping the relevant objects with CORBA to
       allow remote invocation.  While we probably wouldn't have to wrap
       the Aria objects in this particular case, it might be useful for
       other problems.

    2) Using Java and RMI.  Has anyone used Java, with or without Aria? I
       saw in the archives some talk about wrapping Saphira with JNI, but
       wrapping the Aria objects with JNI could get ugly (wrapping any
       objects with JNI can get ugly ;-)).  Are there any plans to write
       a Java version of Aria?

  We are leaning toward #1, but would love to look at Java if it is
  possible.
 
  Any comments or suggestions?

  Thanks,
  Keith

[2]

On Sat, Oct 27, 2001 at 06:56:51PM -0400, Keith O'Hara wrote:
> 
>   Hello,
>
>   We are currently working on a semi-autonomous teleoperation system and
>   are experimenting with the Pioneer 2-DX (with onboard computer).  We
>   would like to use Aria for various reasons, so I thought I would share
>   our ideas and maybe get some feedback.

Glad to hear you'd like to use Aria.

>   First, we have to decide on a programming language for the application
>   that will do the actual driving of the robot. This application will run
>   on the onboard computer. Our initial ideas were:    
>
>     1) Using C++ and Aria; wrapping the relevant objects with CORBA to
>        allow remote invocation.  While we probably wouldn't have to wrap
>        the Aria objects in this particular case, it might be useful for
>        other problems.

This is possible of course, but it might be a bit of a heavy weight
solution when a light weight one might do.  For something like
teleoperation you don't necessarily care about all that many things
within Aria, so you could make a program that used Aria and just
listened for commands/distributed information on a socket.  There is
even a socket class in Aria (ArSocket) to make things like this
easier.

>     2) Using Java and RMI.  Has anyone used Java, with or without Aria? I
>        saw in the archives some talk about wrapping Saphira with JNI, but
>        wrapping the Aria objects with JNI could get ugly (wrapping any
>        objects with JNI can get ugly ;-)).  Are there any plans to write
>        a Java version of Aria?

There are no plans for a Java version of Aria.  I haven't used Java in
any serious way, but the people who tried to wrap Saphira with JNI had
some major problems because of the way that Saphira didn't do
threading well, though I think some of them got it to work.  Aria's
threading is better of course, and it can also be run in single
threaded mode.  Aria was basically made to do these types of
unexpected things, as in my experience the aren't all that rare, and
with them in mind in the beginning it wasn't that much extra work.

You could also just make some C functions (extern "C" and all that)
that use C++ objects to make it easier to call from Java.  Meaning you
could have an init(void) function that created an ArRobot, and a
connect(void) function which created the appropriate connection and
made the connection, and a couple of functions for setting the speeds.

>   We are leaning toward #1, but would love to look at Java if it is
>   possible.
>  
>   Any comments or suggestions?

Your straight #1 suggestion is probably the most robust long term
solution for using Aria from another language.  However, I wanted to
make sure you didn't overlook the possibility of using another
lighter-weight solution...  With everything related to robotics I've
often found that the simplist solutions work the best.  Our
WorldLink/WorldPass software for example is fairly complex, but still
just uses a simple protocol over a socket, and we built it incredibly
quickly.  The huge advantage of the #1 suggestion and why I say its
probably the most robust long term, is that when its done you can
write any arbitrary program all in your chosen language, whereas with
the client/server thing over a socket you have to add things to each
side to add functionality...  So its all a matter of your goals and
the scope of your project.  If you're just doing one application with
it, the short term client/server over a socket solution may be easier,
but if you're going to do others and use it long term, then #1 is
probably the best way to go. 

There are CORBA implementations you could use in Java so that if you
did #1 you could just use Java to program in, aren't there?

On the 'someday' list of things to do is a C wrapper for Aria.  This
would be so that things like using it with JNI and that things made
with C more in mind are easier to do, but that would be mostly for the
simpler things, since the complex stuff like ArActions would be a pain
to wrap, though it is possible.  I guess it'd also make life easier
for people who only program C, but thats seems to be a diminishing set
of people.  I don't think that would necessarily help much with this
problem though, and the 'someday' list basically means that basically
it looks like a good idea, but its not something that needs to be done
right away, and probably won't be done until someone comes up with a
more compelling reason than it seems like a good idea.  If someone has
a more compelling reason I'd be interested in hearing it.

Matt LaFary
ActivMedia Robotics

[3]

On Sat, 27 Oct 2001 22:12:04 -0400
[e-mail] wrote:

> >   First, we have to decide on a programming language for the
application
> >   that will do the actual driving of the robot. This application will
run
> >   on the onboard computer. Our initial ideas were:    
> >
> >     1) Using C++ and Aria; wrapping the relevant objects with CORBA to

> >        allow remote invocation.  While we probably wouldn't have to
wrap
> >        the Aria objects in this particular case, it might be useful
for
> >        other problems.
>
> This is possible of course, but it might be a bit of a heavy weight
> solution when a light weight one might do.  For something like
> teleoperation you don't necessarily care about all that many things
> within Aria, so you could make a program that used Aria and just
> listened for commands/distributed information on a socket.  There is
> even a socket class in Aria (ArSocket) to make things like this
> easier.

Yes, CORBA might seem a little heavy-weight, but CORBA would give us a
standard way to interface the components of our system.  Also, it would
allow us to talk to the robot over a couple different transports (shared
memory, TCP, etc.) and allow us to write other applications in python,
prolog, Java, whatever!  For our initial system, we really won't be
wrapping any Aria objects, just the classes we write, though
CORBA-tizing some of Aria's classes could prove to be worth our while.

I think CORBA can offer some great benefits to mobile robotics.  For
instance, the trading service could allow you to dynamically look up
services, services being either robot capabilities or other robots.  Also,
the RT event service could also prove to be very useful.

> 
> >     2) Using Java and RMI.  Has anyone used Java, with or without
Aria? I
> >        saw in the archives some talk about wrapping Saphira with JNI,
but
> >        wrapping the Aria objects with JNI could get ugly (wrapping any

> >        objects with JNI can get ugly ;-)).  Are there any plans to
write
> >        a Java version of Aria?
>
> There are no plans for a Java version of Aria.  I haven't used Java in
> any serious way, but the people who tried to wrap Saphira with JNI had
> some major problems because of the way that Saphira didn't do
> threading well

I bet.

>
> You could also just make some C functions (extern "C" and all that)
> that use C++ objects to make it easier to call from Java.  Meaning you
> could have an init(void) function that created an ArRobot, and a
> connect(void) function which created the appropriate connection and
> made the connection, and a couple of functions for setting the speeds.
>
> >   We are leaning toward #1, but would love to look at Java if it is
> >   possible.
> >
  
>
> There are CORBA implementations you could use in Java so that if you
> did #1 you could just use Java to program in, aren't there?
>

Yes, we are probably going to write the GUI for the teleoperator in
Java and have it talk to the robot's onboard app via CORBA.

> On the 'someday' list of things to do is a C wrapper for Aria.  This
> would be so that things like using it with JNI and that things made
> with C more in mind are easier to do, but that would be mostly for the
> simpler things, since the complex stuff like ArActions would be a pain
> to wrap, though it is possible.  I guess it'd also make life easier
> for people who only program C, but thats seems to be a diminishing set
> of people.  I don't think that would necessarily help much with this
> problem though, and the 'someday' list basically means that basically
> it looks like a good idea, but its not something that needs to be done
> right away, and probably won't be done until someone comes up with a
> more compelling reason than it seems like a good idea.  If someone has
> a more compelling reason I'd be interested in hearing it.

I would actually vote for the Java port before the C port.  I think being
able to program the robot in Java would be great.  The code should be
pretty platform independent, it already has decent threading built-in,
networking and remote objects are easy, nice GUI support, reflection, etc.
I don't think the C wrapper would necessarily solve the JNI problem.  We
are looking at RT-Java as a future programming option, though we haven't
done anything due to the lack of a RT-JVM.

-Keith