<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
Having supervised real world systems simulation in SL, and thinking
about these issues in the process, here are some thoughts about it.<br>
(You can see one of our projects here:
<a class="moz-txt-link-freetext" href="http://mondego.calit2.uci.edu/xwiki/bin/view/SL/WebHome">http://mondego.calit2.uci.edu/xwiki/bin/view/SL/WebHome</a>; it's not
"robotics" as such, but it's control of physical systems. BTW, I can't
wait to move this work to OpenSim! -- it's just a matter of certain ll
functions being added)<br>
<br>
- Better physics would be really nice. The engineers of the company we
were working with, a hardware company, were constantly asking for it.
My students had used ODE tools before, so they had to lower their
standards in the SL work. We ended up ignoring physics altogether.<br>
<br>
- Not having physics, however, is not necessarily a show-stopper for
these simulations; it all depends on what you want to simulate. If the
focus is on the control of the physical layer of the system, then, yes,
bad physics is a show stopper. However, if the focus is on the
higher-level control layers, you can go a long way by emulating the
physical layer through meaningful parameters that you feed into your
system. For example: need to account for the effect of wind? -- use a
parameter that introduces an error into the movement; need to account
for gravity tipping your robots down after a blow from the opponent
robot? -- emulate it by encoding the forces into numbers and
interpreting those numbers; need to rotate your vehicle according to
track? -- fake it by hardcoding the rotation. etc. This emulation of
the physical layer, although painful at points, will allow you to
proceed with the control that is more logical in nature, like
scheduling, coordination between objects and stuff like that.<br>
<br>
- WRT to sensors: Note that some sort of GPS, microphones, and contact
already exist: llGetPos gives
you the object's position; llListen(0) makes you listen to the chat
channel, which is a sort of a microphone. The touch and collision
events get at the
contact issue. It would be really nice to extend the API to account for
more sensing modes. But again, this is not necessarily a show stopper,
you can fake some sensing modes to some degree. We ended up developing
a generic sensor framework that works like this:<br>
For example, assume you need a temperature sensor. That means that some
objects emit heat. So, in those objects, stick a script that broadcasts
their temperature through llSay/Shout messages on some channel, e.g.
"TEMP 100". The "sensors", then, are objects that simply listen to
those messages.<br>
<br>
For people who are used to work with physics simulation software, this
may look like a bunch of hacks. Well, they are hacks; or, technically,
"emulation", as opposed to "simulation." All simulations emulate
things, at some level; it would be nice to lower that down to the
server rather than doing it at the scripting level -- no question about
that. I would be the first supporting an effort to improve the state of
physics in OpenSim, because I think that simulation of real world
systems in an immersible manner is a tremendous application area for
this technology. However, if your focus is on the logical control /
coordination, and your project benefits from being persistently online
and having people in the mix, you can go a long way already by faking
the physical layer at the scripting level.<br>
<br>
WRT to SL being a "game" platform, therefore using physics for added
realism but not for function: that may be true of Linden Lab's SL. I
hope the people here in OpenSim break away from that whole "fantasy
game" philosophy. Some fantasies -- social, technical and scientific --
end up having a huge positive impact in the real world. Those are a lot
more worthwhile supporting than sex beds and warrior tales (not that
there's anything wrong with that, but ... choose your game!)<br>
<br>
Diva / Crista<br>
<br>
Jordi wrote:
<blockquote
cite="mida4162420803010225j35c088dehee651e508dd6c3d8@mail.gmail.com"
type="cite">For other interested developers:<br>
<br>
We talk about this in the irc channel and the general conclusion (at
least the idea I got) is that it would be too difficult to add this
kind of functionality at present time. <br>
OpenSim still have to catch up in features and openviewer is in its
infancy. Adding these features will potencially need changes in the
client. Openviewer is not there. <br>
<br>
It may be the future and an eye should be kept on that but right now
there are other priorities. <br>
<br>
Comments?<br>
<br>
<br>
<br>
<br>
<div class="gmail_quote">On Sat, Mar 1, 2008 at 2:35 PM, dan miller
<<a href="mailto:danbmil99@yahoo.com">danbmil99@yahoo.com</a>>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">--- Jordi <<a href="mailto:mumismo@gmail.com">mumismo@gmail.com</a>>
wrote:<br>
> Hi,<br>
<br>
</div>
Welcome Jordi. I do robotic simulation by day, and have been known to<br>
contribute to the physics plugins on nights and weekends. I have goals
very<br>
similar to your own. A few points inline below.<br>
<div class="Ih2E3d">><br>
> I am collaborating in the development of a robotic simulator (<br>
> <a href="http://playerstage.sourceforge.net/wiki/Gazebo"
target="_blank">http://playerstage.sourceforge.net/wiki/Gazebo</a>).<br>
> I wanted to add a multiuser mode oriented to allow competitions.
Searching<br>
> around I have found OpenSim.<br>
<br>
</div>
I used playerstage & Gazebo while doing robotics at CMU. The
simulator I<br>
work on at my day job is similar in some ways to PS/G (we considered
using<br>
it but for various reasons developed our own). A common element to all<br>
these projects is ODE -- it's the physics engine under Gazebo, my work
code,<br>
and is by far the most developed engine for Opensim. Unfortunately
there<br>
are many issues other than just the physics engine to consider before<br>
undertaking an integration.<br>
<div class="Ih2E3d"><br>
><br>
> I have being asking about this in the chat channel and basically
OpenSim<br>
> lacks and needs to accommodate this kind of simulator at least the<br>
> following:<br>
><br>
> - realistic physic simulation (IMHO<br>
> <a href="http://www.adrianboeing.com/pal/index.html"
target="_blank">http://www.adrianboeing.com/pal/index.html</a> is the
way to go)<br>
> - sensors: cameras (multicameras), lasers, contact, gyroscopes,<br>
> temperature,<br>
> microphones, GPS , etc.<br>
> - joints, articulated bodies<br>
> - code to make articulated bodies move, reach etc using the joints
and the<br>
> physic<br>
> - External interfaces so that programs can control all that (in
their own<br>
> process without using scripting )<br>
<br>
</div>
Yep, that's what opensim would need, to be able to do the kind of
simulation<br>
we're discussing here. However, problems arise when you start to think<br>
about how the server and client components are architected. Second
Life is<br>
basically a gamer world; the physics is there to impart a sense of
realism.<br>
However, most of what you see typically in SL involves scripting and<br>
animation, which often ignore physics completely. Everything the server<br>
does has to be transmitted to each client over the internet, with
variable<br>
delays, packet loss, etc. The client is designed to try to produce an<br>
acceptable result in spite of these conditions. The upshot is that the<br>
client frequently presents behavior to the user that is not exactly
what the<br>
simulator is 'thinking', and is also not the same from client to client.<br>
The most obvious example of this is in avatar animation, which is
basically<br>
a client-side script. I'm still a bit unclear how server-side scripting<br>
really works, but I imagine it's basically streaming messages to the
client<br>
about the position, velocity, etc. of each object ('prim' in SL<br>
terminology). There is no provision in the client to understand things
like<br>
linkages, wheels, etc -- the client is very dumb, it just tries to show<br>
things where they are supposed to be. It also does some interpolation
of<br>
velocity between messages, which can cause quite a bit of mischief.<br>
<br>
The good news is that this project is really in its infancy, and there
is an<br>
opportunity to get involved in something that is still baking in the
oven.<br>
The trickiest part will be to decide what can be done on the server side<br>
that will remain compatible with the Linden viewer, which will be the<br>
standard client-side application for the foreseeable future.
Alternatively,<br>
one could imagine extending the client side to do things more in line
with a<br>
shared, deeply realistic simulation. The OpenCroquet project seems to
have<br>
been developed with this sort of thing in mind, but it's a research
project,<br>
not something we've seen work in the real world (ie over the internet,
with<br>
hundreds of users simultaneously).<br>
<div class="Ih2E3d"><br>
> What OpenSim has that our simulator lacks is :<br>
> - multiuser environment<br>
> - project visibility<br>
> - Tons of tools, models, etc<br>
> - Scripting<br>
> - good navigation system in the world<br>
><br>
><br>
> I am considering switching efforts to OpenSim but I want to know if<br>
> invasive<br>
> changes like those would be welcomed. Keep in mind that the
simulation<br>
> will<br>
> be much more computer intensive. Also, maintaining the interfaces
for<br>
> external programs can be tedious and get few users.<br>
> Also, it seems that OpenViewer is in an early stage of
development. Some<br>
> of<br>
> those changes would need support from the client.<br>
><br>
> Any comments welcomed.<br>
> Mostly: it would be welcomed? Anyone interested in helping with
this?<br>
><br>
</div>
well, I for one am very interested. We can get into a deeper
discussion of<br>
the technical challenges on IRC some time. My moniker is danx0r.<br>
<br>
-dbm<br>
<div>
<div class="Wj3C7c"><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"
target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Jordi Polo Carres<br>
NLP laboratory - NAIST<br>
<a href="http://www.bahasara.org">http://www.bahasara.org</a><br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>