Thread: [simspark-devel] Physical and Graphic Layers, and agent-server Binary Protocol

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
 <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
Hi all! 
Recently I had some discussions with Joschka, and there are some
decisions which should be made for the future direction of our
simulator. So, we want to bring the discussion to this list, please
participate! 
 
First of all, we'd like to make our physics and graphics support more
modular, so that we can use physical engines other than ODE and
graphical engines like OGRE and OpenSceneGraph. 
For physics, using PAL may or may not be a good decision. Please have
these issues in mind and let us know any ideas which you have about
these issues. 
 
As you already know, my main plan was to add Player support as a way to
provide a new binary protocol (agent-server for now, but might or might
not be suitable for monitor-server communication too). But there are
some issues which should be decided about. So, following is some parts
of my last email to Joschka about these issues. Please read and let me
know about your opinions. 
Thanks in advance! 
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
 
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;} blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important} blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important} blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important} blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style>Joschka
Boedecker <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:jos...@go...">&lt;jos...@go...&gt;</a>
wrote on
۰۹/۰۲/۰۶ 07:53:23: 
<blockquote style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;" cite="mid:84b...@ma..." type="cite">
 <pre wrap="">Hi Hedayat,

On Wed, Feb 4, 2009 at 7:16 PM, Hedayat Vatankhah <a   moz-do-not-send="true" class="moz-txt-link-rfc2396E"   href="mailto:hed...@ai...">&lt;hed...@ai...&gt;</a> wrote:
  </pre>
</blockquote>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:84b...@ma..."   type="cite">
  <blockquote type="cite">
    <pre wrap="">...    </pre>
  </blockquote>
  <pre wrap=""><!---->
PhysX would be great to have (and so would be BULLET, since PhysX only
runs on Windows and Linux so far). We need a discussion on the
re-design of the physics integration on the list I think (same for the
graphics). This will also be a pretty big task, maybe too big for a
single person.
  </pre>
</blockquote>
I agree!<br>
<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:84b...@ma..."   type="cite">
  <blockquote type="cite">
    <pre wrap="">Till now I was mostly involved with CMake support and package migration, but
I'm going to go for the new protocol. But some design decisions are needed
here, and I'll be happy if you and others can help me!
The first question which arise is about Windows support. Currently, Player
doesn't support Windows (while it is planned for Player 2.2), so adding
Player support as the main way of agent-server protocol will make our
simulator to not work on Windows at least temporary. I don't know how much
important is it.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I still think Player integration is important, and that it is the way
to go for the future. But maybe we should not make it the main
protocol as long as not all the platforms are supported. I guess it
would be helpful if we had it running for Linux and Mac already, so
that once it's ready for Windows, it won't be too much work to adapt.
But I'm not familiar with the details, so you might be able to judge
better if this makes sense. Another possibility would be to develop a
more efficient binary protocol for the server as an intermediate step.
What do you think?
  </pre>
</blockquote>
I think currently the main platform is Linux, so the protocol we use on
it will be the main protocol. We can retain the current protocol as an
option, but personally I prefer to use Player protocol as the main
protocol.<br>
Implementing another binary protocol is an option too, specially if we
want to prepare a binary protocol for RC09 ASAP. I think Player
integration will take time, and also considering the parallel nature of
Player, it is a good opportunity to redesign our multi-threaded
implementation of the simulator, which will make the task a bit longer.
<br>
But if we want to implement another binary protocol, we should at least
try to do it in a way to make future works easier. Currently sensors
generate S-expressions directly, and often there is no internal
structure representing those data exactly (data is extracted and
converted to S-expression directly), and Percept() functions receive
S-expressions. Some design decisions are needed here too.<br>
<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:84b...@ma..."   type="cite">
  <blockquote type="cite">
    <pre wrap="">Another important thing here is how our simulator and player should
communicate. If I understood correctly, Gazebo uses shared memory for this
task. it'll make our simulator more Linux dependent. Another solution is to
communicate using TCP sockets, but the overhead might be too much.
(Again if I understood correctly!) Stage is implemented as a player plugin,
but I should still investigate how it handles multiple agents.
Another solution which is in my mind is to integrate Player server into our
simulator, so we can communicate with it directly.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I like the last idea, if it can be done as a plugin ;-) Sounds pretty good!
  </pre>
</blockquote>
I'll investigate it! And if we want to implement something such as
protocol selection, I think we must go for this solution so that we can
have control over the used protocol. <br>
<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:84b...@ma..."   type="cite">
  <blockquote type="cite">
    <pre wrap="">I'm still in the early stages of investigation, and I'm pretty busy too! But
I hope to be able to do it soon.
    </pre>
  </blockquote>
  <pre wrap=""><!---->...
  </pre>
</blockquote>
<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:84b...@ma..."   type="cite">
  <blockquote type="cite">
    <pre wrap="">Another solution is to forget Player integration for now, and implement a
binary protocol inside the simulator for our own. That's easier for
implementation, but could create additional problems such as missing client
classes.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It would be good to allow the old and the new protocol for different
teams, like in 2D I guess.
  </pre>
</blockquote>
Yes, if people cannot argue that's unfair for some reason!<br>
<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:84b...@ma..."   type="cite">
  <blockquote type="cite">
    <pre wrap="">(Also, we should not use a simple binary protocol such as what is
used in 2D, since that's not portable (a 32bit server cannot communicate
with a 64bit monitor for example).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I see, that's a good point. This should also be discussed on the
mailing list, I think. Maybe someone has already thought about these
problems and might have a proposal. Could you maybe raise these points
on the mailing list?
  </pre>
</blockquote>
Yes, there are solutions. For example, Player uses XDR[1], but it seems
that its not available for windows (But a Player guy have created 
a Windows version for use with Player I think). <br>
<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:84b...@ma..."   type="cite">
  <pre wrap="">Cheers,
Joschka
  </pre>
</blockquote>
<br>
Good luck,<br>
Hedayat<br>
<br>
[1] <a moz-do-not-send="true" class="moz-txt-link-freetext"   href="http://en.wikipedia.org/wiki/External_Data_Representation">http://en.wikipedia.org/wiki/External_Data_Representation</a><br>
<br>
</body>
</html>