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

[Yuan Xu <xuy...@gm...>]

Hi,

2009/2/6 Hedayat Vatankhah <hed...@ai...>:

>
> 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.

OGRE and OSG manage the scene tree and special data structure themselves,
it needs to copy data from a scene tree to another when running
internal monitor.
So, I don't think integrate OGRE or OSG into simspark is a good idea.
But, some external tools can benefit form OGRE and OSG.

> 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.

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 ;-)

>
> Joschka Boedecker <jos...@go...> wrote on ۰۹/۰۲/۰۶
> 07:53:23:
>
> Hi Hedayat,
>
> On Wed, Feb 4, 2009 at 7:16 PM, Hedayat Vatankhah <hed...@ai...> 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] http://en.wikipedia.org/wiki/External_Data_Representation
>
>
> ------------------------------------------------------------------------------
> 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
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>



-- 
Sincerely,

Xu Yuan