From: Olivier M. <Oli...@cy...> - 2003-06-20 07:27:46
|
Hi, I am currently considering developing an interface between Player and Webots. Webots is a commercial mobile robot simulator (http://www.cyberbotics.com/products/webots/) that models a number of robots not yet supported by Player / Stage (like Khepera, Koala, Hemisson, Lego RCX, Sony Aibo, Humanoid robots). Webots already supports most of the devices included in Player (and even more). Moreover, Webots includes a transfer capability to real robots. Such an interface would allow many other robotics people to use Player for controlling their favorit robot, through Webots. Webots would not replace Stage or Gazebo as it is a different kind of simulator (commercial, simulates noise and physics, 3D, include a large library of robots, sensors and actuators, transfer to real robots, etc.) This interface would be released under the GPL license to allow the code to evolve with Stage if necessary. From a technical point of view, such an interface could be either merged into Player code (like the interface with Stage) or implemented as a shared library loaded at runtime as specified by the existing command line option of Player. Webots would launch an instance of Player for each of its simulated or real robots. I was just wondering what you think about that. Would such an interface be welcome by robotics users and Stage developers ? Would you help me, or support me developing such an interface ? -Olivier -- -Olivier Michel http://www.cyberbotics.com Phone/Fax: +41 21 693 8624 |
From: brian g. <bg...@us...> - 2003-06-20 21:00:12
|
hi Olivier, On Fri, 20 Jun 2003, Olivier Michel wrote: > I am currently considering developing an interface between Player and > Webots. Webots is a commercial mobile robot simulator > (http://www.cyberbotics.com/products/webots/) that models a number of > robots not yet supported by Player / Stage (like Khepera, Koala, > Hemisson, Lego RCX, Sony Aibo, Humanoid robots). Webots already supports > most of the devices included in Player (and even more). Moreover, Webots > includes a transfer capability to real robots. > > Such an interface would allow many other robotics people to use Player > for controlling their favorit robot, through Webots. > Excellent! > Webots would not replace Stage or Gazebo as it is a different kind of > simulator (commercial, simulates noise and physics, 3D, include a large > library of robots, sensors and actuators, transfer to real robots, etc.) > > This interface would be released under the GPL license to allow the code > to evolve with Stage if necessary. > From a technical point of view, such an interface could be either > merged into Player code (like the interface with Stage) or implemented > as a shared library loaded at runtime as specified by the existing > command line option of Player. Webots would launch an instance of Player > for each of its simulated or real robots. We've been happy so far with the current model, wherein the Player source tree contains a number of simulation drivers that handle the interface between the simulator and Player. That simulator-Player interface can take several forms. So far, Player & Stage communicate explicitly through a memory-mapped I/O segment, and Player & Gazebo communicate through 'libgazebo', which is a little Gazebo client lib that hides the communication mechanism (although right now, it also happens through memory-mapped I/O). If we go this route, then the Webots-Player interface would definitely need to be GPL, since it would be part of Player. There would not be a problem with Webots' existing commercial license, since Player and Webots would be separated by an external interface (e.g., memory-mapped I/O, shared memory, TCP socket) and so would not be considered to be a single "program". > > I was just wondering what you think about that. Would such an interface > be welcome by robotics users and Stage developers ? > I don't speak for everyone, but I think that it would be very welcome indeed. It's a great idea to have different simulators for different purposes, all with a unified interface (i.e., Player). > Would you help me, or support me developing such an interface ? > I'm willing to help. Of course, you'd have to do the work, but I'd certainly provide support and answer questions. I would suggest that to start you take a look at the way the current Stage and Gazebo simulation drivers work. As Gazebo is in a state of significant flux, you'll need to either get a CVS snapshot: http://playerstage.sourceforge.net/snapshots/snapshots.html or check out the current code from CVS: http://sourceforge.net/cvs/?group_id=42445 If you do the latter, also read the "Developers" section in the FAQ: http://playerstage.sourceforge.net/faq.html#developers Note that there's currently a disparity between the way that Stage and Gazebo use Player. With Stage, Player is spawned automatically by the simulator, whereas with Gazebo, the user starts the simulator and then manually starts Player. We're in the process of resolving that issue now. brian. |
From: Richard V. <va...@hr...> - 2003-06-20 21:50:59
|
Olivier, Brian has done the heavy lifting with his reply, so I'll just add that I'd be vary happy to see a Player/Webots interface. I've used Webots and liked it. I think it'll be a good choice for some people for whom neither Stage nor Gazebo is just right. If it brings current Webots users to the goodness of Player, that'll be just dandy. good luck with your port, and keep in touch. Richard. On Fri, 20 Jun 2003, brian gerkey wrote: > hi Olivier, > > On Fri, 20 Jun 2003, Olivier Michel wrote: > > > I am currently considering developing an interface between Player and > > Webots. Webots is a commercial mobile robot simulator > > (http://www.cyberbotics.com/products/webots/) that models a number of > > robots not yet supported by Player / Stage (like Khepera, Koala, > > Hemisson, Lego RCX, Sony Aibo, Humanoid robots). Webots already supports > > most of the devices included in Player (and even more). Moreover, Webots > > includes a transfer capability to real robots. > > > > Such an interface would allow many other robotics people to use Player > > for controlling their favorit robot, through Webots. > > > > Excellent! > > > Webots would not replace Stage or Gazebo as it is a different kind of > > simulator (commercial, simulates noise and physics, 3D, include a large > > library of robots, sensors and actuators, transfer to real robots, etc.) > > > > This interface would be released under the GPL license to allow the code > > to evolve with Stage if necessary. > > From a technical point of view, such an interface could be either > > merged into Player code (like the interface with Stage) or implemented > > as a shared library loaded at runtime as specified by the existing > > command line option of Player. Webots would launch an instance of Player > > for each of its simulated or real robots. > > We've been happy so far with the current model, wherein the Player source > tree contains a number of simulation drivers that handle the interface > between the simulator and Player. That simulator-Player interface can > take several forms. > > So far, Player & Stage communicate explicitly through a memory-mapped I/O > segment, and Player & Gazebo communicate through 'libgazebo', which is a > little Gazebo client lib that hides the communication mechanism (although > right now, it also happens through memory-mapped I/O). > > If we go this route, then the Webots-Player interface would definitely > need to be GPL, since it would be part of Player. There would not be a > problem with Webots' existing commercial license, since Player and Webots > would be separated by an external interface (e.g., memory-mapped I/O, > shared memory, TCP socket) and so would not be considered to be a single > "program". > > > > > I was just wondering what you think about that. Would such an interface > > be welcome by robotics users and Stage developers ? > > > > I don't speak for everyone, but I think that it would be very welcome indeed. > It's a great idea to have different simulators for different purposes, all > with a unified interface (i.e., Player). > > > Would you help me, or support me developing such an interface ? > > > > I'm willing to help. Of course, you'd have to do the work, but I'd > certainly provide support and answer questions. I would suggest that to > start you take a look at the way the current Stage and Gazebo simulation > drivers work. As Gazebo is in a state of significant flux, you'll need to > either get a CVS snapshot: > > http://playerstage.sourceforge.net/snapshots/snapshots.html > > or check out the current code from CVS: > > http://sourceforge.net/cvs/?group_id=42445 > > If you do the latter, also read the "Developers" section in the FAQ: > > http://playerstage.sourceforge.net/faq.html#developers > > Note that there's currently a disparity between the way that Stage and Gazebo > use Player. With Stage, Player is spawned automatically by the simulator, > whereas with Gazebo, the user starts the simulator and then manually starts > Player. We're in the process of resolving that issue now. > > brian. > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > -- Richard Vaughan / HRL Laboratories / va...@hr... / +1 310.317.5689 |
From: Olivier M. <Oli...@cy...> - 2003-06-24 08:41:49
|
Richard and Brian, I truely appreciate your positive answer. I also got personal messages from users of Players interested in such an interface. I just added the Player Webots interface in my development schedule. From a technical point of view, I will contribute to the GPL code of Player to create this interface (hence it will be GPL as well). I think the best way is to use a similar system as between Stage and Player. Webots will launch an instance of Player for each robot controlled by Player. Player will understand it was launched by Webots from the value of an environment variable set by Webots, hence it will load and use the libController.so shared library (which is not GPL and is part of Webots) to be able to communicate with Webots. Does this sound the best way to proceed ? -Olivier -- -Olivier Michel http://www.cyberbotics.com Phone/Fax: +41 21 693 8624 Richard Vaughan wrote: >Olivier, > >Brian has done the heavy lifting with his reply, so I'll just add that I'd >be vary happy to see a Player/Webots interface. I've used Webots and liked >it. I think it'll be a good choice for some people for whom neither Stage >nor Gazebo is just right. If it brings current Webots users to the >goodness of Player, that'll be just dandy. > >good luck with your port, and keep in touch. > >Richard. > >On Fri, 20 Jun 2003, brian gerkey wrote: > > > >>hi Olivier, >> >>On Fri, 20 Jun 2003, Olivier Michel wrote: >> >> >> >>>I am currently considering developing an interface between Player and >>>Webots. Webots is a commercial mobile robot simulator >>>(http://www.cyberbotics.com/products/webots/) that models a number of >>>robots not yet supported by Player / Stage (like Khepera, Koala, >>>Hemisson, Lego RCX, Sony Aibo, Humanoid robots). Webots already supports >>>most of the devices included in Player (and even more). Moreover, Webots >>>includes a transfer capability to real robots. >>> >>>Such an interface would allow many other robotics people to use Player >>>for controlling their favorit robot, through Webots. >>> >>> >>> >>Excellent! >> >> >> >>>Webots would not replace Stage or Gazebo as it is a different kind of >>>simulator (commercial, simulates noise and physics, 3D, include a large >>>library of robots, sensors and actuators, transfer to real robots, etc.) >>> >>>This interface would be released under the GPL license to allow the code >>>to evolve with Stage if necessary. >>> From a technical point of view, such an interface could be either >>>merged into Player code (like the interface with Stage) or implemented >>>as a shared library loaded at runtime as specified by the existing >>>command line option of Player. Webots would launch an instance of Player >>>for each of its simulated or real robots. >>> >>> >>We've been happy so far with the current model, wherein the Player source >>tree contains a number of simulation drivers that handle the interface >>between the simulator and Player. That simulator-Player interface can >>take several forms. >> >>So far, Player & Stage communicate explicitly through a memory-mapped I/O >>segment, and Player & Gazebo communicate through 'libgazebo', which is a >>little Gazebo client lib that hides the communication mechanism (although >>right now, it also happens through memory-mapped I/O). >> >>If we go this route, then the Webots-Player interface would definitely >>need to be GPL, since it would be part of Player. There would not be a >>problem with Webots' existing commercial license, since Player and Webots >>would be separated by an external interface (e.g., memory-mapped I/O, >>shared memory, TCP socket) and so would not be considered to be a single >>"program". >> >> >> >>>I was just wondering what you think about that. Would such an interface >>>be welcome by robotics users and Stage developers ? >>> >>> >>> >>I don't speak for everyone, but I think that it would be very welcome indeed. >>It's a great idea to have different simulators for different purposes, all >>with a unified interface (i.e., Player). >> >> >> >>>Would you help me, or support me developing such an interface ? >>> >>> >>> >>I'm willing to help. Of course, you'd have to do the work, but I'd >>certainly provide support and answer questions. I would suggest that to >>start you take a look at the way the current Stage and Gazebo simulation >>drivers work. As Gazebo is in a state of significant flux, you'll need to >>either get a CVS snapshot: >> >> http://playerstage.sourceforge.net/snapshots/snapshots.html >> >>or check out the current code from CVS: >> >> http://sourceforge.net/cvs/?group_id=42445 >> >>If you do the latter, also read the "Developers" section in the FAQ: >> >> http://playerstage.sourceforge.net/faq.html#developers >> >>Note that there's currently a disparity between the way that Stage and Gazebo >>use Player. With Stage, Player is spawned automatically by the simulator, >>whereas with Gazebo, the user starts the simulator and then manually starts >>Player. We're in the process of resolving that issue now. >> >> brian. >> >> |
From: brian g. <bg...@us...> - 2003-06-24 14:32:52
|
On Tue, 24 Jun 2003, Olivier Michel wrote: > I truely appreciate your positive answer. I also got personal messages > from users of Players interested in such an interface. I just added the > Player Webots interface in my development schedule. > > From a technical point of view, I will contribute to the GPL code of > Player to create this interface (hence it will be GPL as well). I think > the best way is to use a similar system as between Stage and Player. > Webots will launch an instance of Player for each robot controlled by > Player. Player will understand it was launched by Webots from the value > of an environment variable set by Webots, hence it will load and use the > libController.so shared library (which is not GPL and is part of Webots) > to be able to communicate with Webots. Does this sound the best way to > proceed ? > hi Olivier, That sounds great. A few comments: * We're actually moving away from the current Stage model, toward the Gazebo model, where Player is started manually, with its own config file. Unfortunately, I don't have time just now to explain the subtleties; perhaps Richard and Andrew can talk about this. * Rather than an environment variable, I would use a command-line arg. * You only need one instance of Player, even for many simulated robots, since Player can listen on many ports simultaneously. This solution is far more scalable than running one Player process per robot. * Actually, loading non-GPL shared libs into a GPL binary is a bit of a gray area, because at that point they become "one program", which isn't strictly allowed. For example, the Linux kernel allows it, but warns you that you've "tainted" the kernel. Would it be possible to separate the interface such that you don't need to load any non-GPL code into Player? brian. |