Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 26373 - sci-electronics/stage: Virtual world simulator for robots and sensors.
Summary: sci-electronics/stage: Virtual world simulator for robots and sensors.
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Default Assignee for New Packages
Whiteboard: Science overlay
Keywords: EBUILD, InOverlay
: 185116 (view as bug list)
Depends on:
Blocks: 185298 260383
  Show dependency tree
Reported: 2003-08-10 21:28 UTC by brian gerkey
Modified: 2019-08-14 15:59 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---

player-1.4_rc1.ebuild (New package) (player-1.4_rc1.ebuild,670 bytes, text/plain)
2003-08-10 21:31 UTC, brian gerkey
sci-electronics/player-1.6.5 ebuild (player-1.6.5.ebuild,915 bytes, text/plain)
2005-12-27 10:40 UTC, Jean-François Richard
sci-electronics/stage-1.6.2 ebuild (stage-1.6.2.ebuild,685 bytes, text/plain)
2005-12-27 10:41 UTC, Jean-François Richard
player-2.0.4.ebuild (player-2.0.4.ebuild,3.23 KB, text/plain)
2007-11-23 17:03 UTC, Angelo Arrifano (RETIRED)
The 2.1.1 ebuild (player-2.1.1.ebuild,3.26 KB, text/plain)
2008-10-21 15:51 UTC, Renato Caldas
Patch that fixes compilation with gcc-4.3 (fix_gcc_4_3_3.patch,703 bytes, patch)
2008-10-21 15:51 UTC, Renato Caldas
Details | Diff
zlib-1.2.6.patch (zlib-1.2.6.patch,927 bytes, text/plain)
2012-05-23 22:29 UTC, Manuel Rüger (RETIRED)

Note You need to log in before you can comment on or make changes to this bug.
Description brian gerkey 2003-08-10 21:28:52 UTC
Please find attached player-1.4_rc1.ebuild.

player is a robot device server that provides access to robotic devices (i.e.,
sensors and actuators) in a way that is neutral with respect to programming
language, control architecture, and location.  In addition to providing an
interface to physical robot hardware, player can also act as an interface to
simulated robots within the simulators stage and gazebo (ebuilds for stage and
gazebo are forthcoming).

player is widely used in robotics research and education, and is currently being
used by the Robotics Engineering Task Force (RETF) as the basis for a
forthcoming standard for robotic device control.

I suggest app-sci/player.


Reproducible: Always
Steps to Reproduce:
Comment 1 brian gerkey 2003-08-10 21:31:36 UTC
Created attachment 15878 [details]
player-1.4_rc1.ebuild (New package)
Comment 2 brian gerkey 2004-10-19 10:52:22 UTC
I submitted this ebuild 14 months ago, and it was last touched almost 12 months ago.  Should I assume that it's been rejected?

Comment 3 Olivier Fisette (RETIRED) gentoo-dev 2004-10-19 11:02:23 UTC
Not at all. It is just that the science team has over a hundred requests pending! With so much work to do, we tend to focus on more popular packages and those we are already familiar with. Also, all packages must be tested to ensure they work before inclusion in Portage, and I frankly have no idea how to test a robot device server since I have no such hardware.
Comment 4 brian gerkey 2004-10-20 08:21:18 UTC
Ok, that makes sense; thanks for the feedback.  I'd really like to get this ebuild into portage.  As for popularity, we're doing very well as far as robotics software goes:
But it's a specialized market, and there's no reason to have even heard of our software if you don't work in robotics or AI.  As for testing, you really can't test Player beyond compilation and installation unless you have some robot hardware on hand.  Now, we also maintain two robot simulators, Stage and Gazebo, to which Player is the interface.  You could test Player + Stage and/or Player + Gazebo without any special hardware.  Would it help if we submitted ebuilds for Stage and Gazebo?
Comment 5 Olivier Fisette (RETIRED) gentoo-dev 2004-10-20 16:25:27 UTC
> As for popularity, we're doing very well as far as robotics software goes

No offense meant. I was thinking in terms of how specialised this software is.

> Now, we also maintain two robot simulators, Stage and Gazebo, to which Player 
> is the interface.  You could test Player + Stage and/or Player + Gazebo 
> without any special hardware.  Would it help if we submitted ebuilds for 
> Stage and Gazebo?

That sounds like a good solution. player compiled and installed OK here.
(Documentation will need to be installed in
"/usr/share/doc/player-${player-version}" rather than "/usr/share/doc" to
comply with Gentoo standards, though. I can make this change.) If you can 
submit working ebuilds for robot simulators, along with some instructions on 
how to test them, I will try them out and eventually add both packages to 

I also noticed there is a number of missing dependencies in your ebuild, such 
as Python, tcl/tk, gtk, libraw1394, jpeglib and libRTK. Also, the videodev2 
headers from the Linux kernel could not be found by the configure script, 
altough they are present on my system. These issues will need to be fixed. 
Since you are probably familiar with the libRTK package, I suppose you could 
also submit an ebuild for this package.
Comment 6 brian gerkey 2004-10-20 17:14:22 UTC
Sounds great.  We're planning to make new releases of pretty much everything (librtk, stage, gazebo, and player) in early November, so we'll submit ebuilds for the new versions after that, hopefully addressing all the problems you've noted.
Comment 7 brian gerkey 2004-11-19 12:26:32 UTC
If I may ask your advice, what's the best way to handle optional dependencies?  Player contains many "drivers" that provide access to various bits of hardware, software, and simulators.  Each driver may have some dependencies (e.g., OpenCV, GSL, FFTW, libraw1394), but none of the drivers is actually required to build Player.  We check for all dependencies during configuration, so that the build succeeds on any reasonably POSIX platform.

It seems like a shame to strictly require all of the optional dependencies, when Player will happily build without them (albeit with fewer drivers and thus less functionality).  At the other extreme, we could add USE flags for everything on which Player depends (including our other packages librtk, stage, and gazeo), but I'm hesitant to pollute the USE namespace with a lot of new flags.  In between these two options, we could not require any optional dependencies, but just build support for whatever the user has installed.  So if the user wants to use a driver that requires the GSL, then it's his responsibility to install the GSL before installing Player.  And maybe there are other options I haven't thought of.

What do you recommend?
Comment 8 Olivier Fisette (RETIRED) gentoo-dev 2004-11-19 12:53:13 UTC
Optional dependencies are always managed using "USE" flags. Since it is 
possible to add local "USE" flags to an ebuild, there is no "USE" pollution to 
fear. Usually, the best course of action is to strictly require the packages 
which are necessary for the basic and most common fonctionnalities, and to use 
flags for the optional components that are more exotic, or that some users are 
likely not to require.

Compiling "just for what is installed" should be avoided as much as possible 
for two reasons. First, we do not want the users to do dependency tracking 
themselves; Portage should do it for them whenever possible, and should give 
them all the information they require to configure the package. Second, it 
could get very hard to fix bugs if the same package built on different machines 
using the same compiler, "USE" flags and "CFLAGS" had different 
Comment 9 Jean-François Richard 2005-12-27 10:39:56 UTC
Attached are app-sci/player-1.6.5 and app-sci/stage-1.6.2 ebuilds.

As for the various lib dependencies that Mr Gerkey refers to (Comment #7), I am not aware of each and every driver... If I could have a list of the drivers that require some other libraries, I could certainly have the ebuild to disable/enable them with a USE flag.
Comment 10 Jean-François Richard 2005-12-27 10:40:46 UTC
Created attachment 75621 [details]
sci-electronics/player-1.6.5 ebuild
Comment 11 Jean-François Richard 2005-12-27 10:41:58 UTC
Created attachment 75622 [details]
sci-electronics/stage-1.6.2 ebuild
Comment 12 Angelo Arrifano (RETIRED) gentoo-dev 2007-07-15 22:34:09 UTC
Hi there.

I searched on bugzilla for a player ebuild and I found Zero Bugs. So I submitted a player ebuild. 

Today, when submitting the last ebuild (gazebo) I tried to find player ebuild (the one I submited before) and I came across with this thread.

Strange I didn't find this bug in the first time : \

- -

Anyway.. Since player goes now in its 2.0.4 version and Gazebo project born, I hope my efforts would be useful to you guys.

See ebuilds:
player: #185116
stage: #185298
gazebo: #185470

Comment 13 Angelo Arrifano (RETIRED) gentoo-dev 2007-11-23 15:45:53 UTC
*** Bug 185116 has been marked as a duplicate of this bug. ***
Comment 14 Angelo Arrifano (RETIRED) gentoo-dev 2007-11-23 17:03:19 UTC
Created attachment 136785 [details]
Comment 15 Sébastien Fabbro (RETIRED) gentoo-dev 2007-11-23 17:15:17 UTC
Angelo's ebuild now in science overlay. Thanks all. Report problems here. 

@sci-electronics: feel free to merge this into the main tree.
Comment 16 Denis Dupeyron (RETIRED) gentoo-dev 2007-11-24 08:02:20 UTC
(In reply to comment #15)
> @sci-electronics: feel free to merge this into the main tree.

You talkin' to me ? ;o)

I certainly will have a look at this. In the meantime I'm reassigning this to sci-electronics, because if I don't it's not on my radar (and that's the reason why I hadn't seen this before).

Comment 17 Renato Caldas 2008-10-21 15:50:17 UTC

Player 2.1.1 is out. The 2.0.4 ebuild seems to work ok, but there are some compilation problems with gcc-4.3.

The attached ebuild and patch work perfectly here.
Comment 18 Renato Caldas 2008-10-21 15:51:09 UTC
Created attachment 169320 [details]
The 2.1.1 ebuild
Comment 19 Renato Caldas 2008-10-21 15:51:52 UTC
Created attachment 169322 [details, diff]
Patch that fixes compilation with gcc-4.3
Comment 20 Justin Lecher (RETIRED) gentoo-dev 2010-06-29 16:18:01 UTC
Doesn't build anymore:

mkdir .libs
 x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../libplayercore -I../../../client_libs/libplayerc++ -Wall -I../../.. -MT garminnmea.lo -MD -MP -MF .deps/garminnmea.Tpo -c  -fPIC -DPIC -o .libs/garminnmea.o In function ‘void GarminNMEA_Register(DriverTable*)’: warning: deprecated conversion from string constant to ‘char*’ In member function ‘int GarminNMEA::ReadSentence(char*, size_t)’: error: invalid conversion from ‘const char*’ to ‘char*’ error: invalid conversion from ‘const char*’ to ‘char*’ error: invalid conversion from ‘const char*’ to ‘char*’ In member function ‘char* GarminNMEA::GetNextField(char*, size_t, const char*)’: error: invalid conversion from ‘const char*’ to ‘char*’
make[4]: *** [garminnmea.lo] Error 1
make[4]: Leaving directory `/var/tmp/portage/sc

And there is a version bump to 3.0.2
Comment 21 Andreas K. Hüttel archtester gentoo-dev 2010-11-01 15:01:52 UTC
Under construction.
Comment 22 Bartosz Krzeszewski 2011-03-15 23:36:08 UTC
I have the same buid error
Comment 23 Manuel Rüger (RETIRED) gentoo-dev 2012-05-23 22:29:35 UTC
Created attachment 312891 [details]

fixes compilation for player-3.0.2 with >=zlib-1.2.6
Comment 24 2016-04-22 07:02:23 UTC
per up stream @ this project has moved to github and was renamed from player to stage.

new home @
upstream github source has not seen much activity since Jan-2012 with version 4.1.1

Please let us know if you (or anyone else) has continued interest in this project.

Tom D
Comment 25 Marek Szuba archtester gentoo-dev 2019-08-14 15:59:24 UTC
Recent versions are in the tree: sci-electronics/Stage