[Opensim-dev] robot simulation
Diva Canto
diva at metaverseink.com
Sat Mar 1 17:52:23 UTC 2008
Hi,
Having supervised real world systems simulation in SL, and thinking
about these issues in the process, here are some thoughts about it.
(You can see one of our projects here:
http://mondego.calit2.uci.edu/xwiki/bin/view/SL/WebHome; 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)
- 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.
- 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.
- 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:
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.
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.
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!)
Diva / Crista
Jordi wrote:
> For other interested developers:
>
> 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.
> 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.
>
> It may be the future and an eye should be kept on that but right now
> there are other priorities.
>
> Comments?
>
>
>
>
> On Sat, Mar 1, 2008 at 2:35 PM, dan miller <danbmil99 at yahoo.com
> <mailto:danbmil99 at yahoo.com>> wrote:
>
> --- Jordi <mumismo at gmail.com <mailto: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
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> --
> Jordi Polo Carres
> NLP laboratory - NAIST
> http://www.bahasara.org
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080301/d19ca518/attachment-0001.html>
More information about the Opensim-dev
mailing list