[Opensim-dev] robot simulation

[dan miller]

--- Jordi <mumismo at gmail.com> wrote:
> Hi,

Welcome Jordi.  I do robotic simulation by day, and have been known to
contribute to the physics plugins on nights and weekends.  I have goals very
similar to your own.  A few points inline below.
> 
> I am collaborating in the development of a robotic simulator (
> http://playerstage.sourceforge.net/wiki/Gazebo).
> I wanted to add a multiuser mode oriented to allow competitions. Searching
> around I have found OpenSim.

I used playerstage & Gazebo while doing robotics at CMU.  The simulator I
work on at my day job is similar in some ways to PS/G (we considered using
it but for various reasons developed our own).  A common element to all
these projects is ODE -- it's the physics engine under Gazebo, my work code,
and is by far the most developed engine for Opensim.  Unfortunately there
are many issues other than just the physics engine to consider before
undertaking an integration.

> 
> I have being asking about this in the chat channel and basically OpenSim
> lacks and needs to accommodate this kind of simulator at least the
> following:
> 
> - realistic physic simulation (IMHO
> http://www.adrianboeing.com/pal/index.html is the way to go)
> - sensors: cameras (multicameras), lasers, contact, gyroscopes,
> temperature,
> microphones, GPS , etc.
> - joints, articulated bodies
> - code to make articulated bodies move, reach etc using the joints and the
> physic
> - External interfaces so that programs can control all that (in their own
> process without using scripting )

Yep, that's what opensim would need, to be able to do the kind of simulation
we're discussing here.  However, problems arise when you start to think
about how the server and client components are architected.  Second Life is
basically a gamer world; the physics is there to impart a sense of realism. 
However, most of what you see typically in SL involves scripting and
animation, which often ignore physics completely.  Everything the server
does has to be transmitted to each client over the internet, with variable
delays, packet loss, etc.  The client is designed to try to produce an
acceptable result in spite of these conditions.  The upshot is that the
client frequently presents behavior to the user that is not exactly what the
simulator is 'thinking', and is also not the same from client to client. 
The most obvious example of this is in avatar animation, which is basically
a client-side script.  I'm still a bit unclear how server-side scripting
really works, but I imagine it's basically streaming messages to the client
about the position, velocity, etc. of each object ('prim' in SL
terminology).  There is no provision in the client to understand things like
linkages, wheels, etc -- the client is very dumb, it just tries to show
things where they are supposed to be.  It also does some interpolation of
velocity between messages, which can cause quite a bit of mischief.

The good news is that this project is really in its infancy, and there is an
opportunity to get involved in something that is still baking in the oven. 
The trickiest part will be to decide what can be done on the server side
that will remain compatible with the Linden viewer, which will be the
standard client-side application for the foreseeable future.  Alternatively,
one could imagine extending the client side to do things more in line with a
shared, deeply realistic simulation.  The OpenCroquet project seems to have
been developed with this sort of thing in mind, but it's a research project,
not something we've seen work in the real world (ie over the internet, with
hundreds of users simultaneously).

> What OpenSim has that our simulator lacks is :
> - multiuser environment
> - project visibility
> - Tons of tools, models, etc
> - Scripting
> - good navigation system in the world
> 
> 
> I am considering switching efforts to OpenSim but I want to know if
> invasive
> changes like those would be welcomed. Keep in mind that the simulation
> will
> be much more computer intensive. Also, maintaining the interfaces for
> external programs can be tedious and get few users.
> Also, it seems that OpenViewer is in an early stage of development. Some
> of
> those changes would need support from the client.
> 
> Any comments welcomed.
> Mostly: it would be welcomed? Anyone interested in helping with this?
> 
well, I for one am very interested.  We can get into a deeper discussion of
the technical challenges on IRC some time.  My moniker is danx0r.

-dbm