Menu
▾
▴
Re: [simspark-devel] Physical and Graphic Layers, and agent-server Binary Protocol
|
From: Hedayat V. <hed...@ai...> - 2009-02-08 13:49:46
|
<!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">
<span></span>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Hi,<br>
</p>
<span><br>
<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><i><b>Yuan
Xu <a class="moz-txt-link-rfc2396E" href="mailto:xuy...@gm..."><xuy...@gm...></a></b></i>
wrote on ۰۹/۰۲/۰۷ 01:37:21:</span><br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;" cite="mid:18a...@ma..." type="cite">
<pre wrap="">Hi,
2009/2/6 Hedayat Vatankhah <a class="moz-txt-link-rfc2396E" href="mailto:hed...@ai..."><hed...@ai...></a>:
</pre>
.....
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
In my mind, Player wants to abstract the Robot Device Interface, then
robot program can be language and platform independent.
It is a good idea.
But, i am not sure is it all the device are available for humanoid robot.
Furthermore, the interface of real robot is designed by manufacturers,
it would make the abstraction useless.
So, I agree with developing a new binary protocol ourselves, and It
follows the KISS principle ;-)
</pre>
</blockquote>
Certainly, Player does not support all of the available robot devices.
But support for more devices can be added as new drivers for Player.
The driver will work using the manufacturers' specific interface, and
provides the common interface to higher levels. Just like our
simulator, which is another robot device, just a simulated one! So,
personally I still think that Player integration is good for the future
of the simulator, specially as the long term goal is to run the agents
on real robots. Finally, we can also create models for the robots which
Player already supports...<br>
And I think that a good design for a new binary protocol is not that
simple too. (I've mentioned some of them in the email). But we might go
for a temporary protocol for 2009 (IMHO).<br>
<br>
<br>
Thanks a lot,<br>
Hedayat<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:18a...@ma..." type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Joschka Boedecker <a class="moz-txt-link-rfc2396E" href="mailto:jos...@go..."><jos...@go...></a> wrote on ۰۹/۰۲/۰۶
07:53:23:
Hi Hedayat,
On Wed, Feb 4, 2009 at 7:16 PM, Hedayat Vatankhah <a class="moz-txt-link-rfc2396E" href="mailto:hed...@ai..."><hed...@ai...></a> wrote:
....
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.
I agree!
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.
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?
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.
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.
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.
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.
I like the last idea, if it can be done as a plugin ;-) Sounds pretty good!
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.
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.
....
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.
It would be good to allow the old and the new protocol for different
teams, like in 2D I guess.
Yes, if people cannot argue that's unfair for some reason!
(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).
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?
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).
Cheers,
Joschka
Good luck,
Hedayat
[1] <a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/External_Data_Representation">http://en.wikipedia.org/wiki/External_Data_Representation</a>
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with
Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code
to
build responsive, highly engaging applications that combine the power of
local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Simspark Generic Physical MAS Simulator
simspark-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sim...@li...">sim...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/simspark-devel">https://lists.sourceforge.net/lists/listinfo/simspark-devel</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
|
