From: Nathan F. <nfa...@sp...> - 2004-03-08 17:37:54
|
Deleting the cache with 'Make clean' is an excellent idea. Go for it Richard! I've wasted hours trying to get everything to compile and build properly. As the Player server grows and incorporates more and more device drivers and algorithms, the damn thing gets harder to (1) configure, (2) make without something going wrong, and (3) install correctly with Stage and Gazebo. I think it may be time for a change. One possibility is to build the Player drivers as loadable modules (similar to Linux device drivers). Then, the configuration utility could try to build ALL of them by default, and skip over the ones missing prerequisite software packages, or that are architecture specific to a different platform. Player could then automatically load the correct modules after it reads its configuration file at startup. I'm no expert in this stuff, but it's an idea anyway. Regards, Nathan Farrington -----Original Message----- From: pla...@li... [mailto:pla...@li...] On Behalf Of Richard Vaughan Sent: Friday, March 05, 2004 4:27 PM To: Jose Sanchez Cc: pla...@li... Subject: [Playerstage-developers] Re: [Playerstage-users] including gazebo with player That cache causes so much trouble! Perhaps we should delete it in 'Make clean'? R. On Mar 5, 2004, at 3:59 PM, Jose Sanchez wrote: > Thanks, > > it worked out, you are a genius, it was an old config.cache, I erased > as you suggested and finally it worked. > > We tested with player and it works, > > thanks again. > > Jose > >> Hmmm, two possibilities: >> >> 1) Try removing config.cache in the Player source dir, then run >> configure >> again (it may be using a cached value for the gazebo test). >> >> 2) If that fails, send me your config.log; there may be some other >> reason >> that the Gazebo test fails. >> >> A. >> >> >> On Fri, 5 Mar 2004, Jose Sanchez wrote: >> >> >>> Hi all, thanks for your replys, but I still don't get it to work >>> >> >> >>> First, when I run ./configure in gazebo, I didn't change anything on >>> the >>> path. What I look is that gazebo worlds are installed in >>> /usr/local/share/gazebo/worlds, however I make the export libraries >>> you >>> guys told me and now when I make locate gazebo.h it prompots >>> >>> linux:/home/jose/player-src-1.4rc2 # locate gazebo.h >>> /home/ghulam/Documents/gazebo-src-0.3.0/libgazebo/gazebo.h >>> /home/jose/gazebo-src-0.3.0/libgazebo/gazebo.h >>> /usr/local/include/gazebo.h >>> >>> so gazebo.h is installed correctly. But player does not find it. I >>> even try by configuring gazebo as ./configure --with-player=yes but >>> still doesn't work. >>> >> >> Andrew Howard email: ah...@po... >> Department of Computer Science http: >> www-robotics.usc.edu/~ahoward >> University of Southern California phone: 1 (213) 740 6416 >> Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696 >> << Insert pithy saying here >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > -- Richard Vaughan School of Computing Science / Simon Fraser University ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Playerstage-developers mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: ahoward <ah...@po...> - 2004-03-08 18:59:20
|
A couple of comments on this... 1. As it stands, the build process should detect which dependencies are installed, and build the appropriate set of drivers. If it doesnt, that's a bug in the build scripts (the build should not fail during compilation). Getting Player to build a *complete* set of drivers, on the other hand, can be quite a challenge. The obvious solution is to use the various package management tools available on the various *nix flavours and distros (we already have a Gentoo ebuild). Any volunteers? 2. I am also interested in enhancing support for dynamically loaded drivers, but for different reasons. Increasingly, I see students writing code that really belongs in the server, but which will never appear in the "official" distribution. Hence I would like to see drivers that are maintained outside the Player CVS tree, and loaded at run-time for specific experiments. Note that Brian has already set up the dynamic-loading mechanism in the server; we just need to brush this off a bit, write some documentation, and perhaps provide a set of template files for "external drivers" (aka browser plug-ins). I will probably do this myself if I can find a few moments. A. On Mon, 8 Mar 2004, Nathan Farrington wrote: > Deleting the cache with 'Make clean' is an excellent idea. Go for it > Richard! I've wasted hours trying to get everything to compile and build > properly. > > As the Player server grows and incorporates more and more device drivers > and algorithms, the damn thing gets harder to (1) configure, (2) make > without something going wrong, and (3) install correctly with Stage and > Gazebo. I think it may be time for a change. > > One possibility is to build the Player drivers as loadable modules > (similar to Linux device drivers). Then, the configuration utility could > try to build ALL of them by default, and skip over the ones missing > prerequisite software packages, or that are architecture specific to a > different platform. Player could then automatically load the correct > modules after it reads its configuration file at startup. > > I'm no expert in this stuff, but it's an idea anyway. > > Regards, > > Nathan Farrington > > > -----Original Message----- > From: pla...@li... > [mailto:pla...@li...] On Behalf Of > Richard Vaughan > Sent: Friday, March 05, 2004 4:27 PM > To: Jose Sanchez > Cc: pla...@li... > Subject: [Playerstage-developers] Re: [Playerstage-users] including > gazebo with player > > > That cache causes so much trouble! Perhaps we should delete it in 'Make > clean'? > > R. > > On Mar 5, 2004, at 3:59 PM, Jose Sanchez wrote: > > > Thanks, > > > > it worked out, you are a genius, it was an old config.cache, I erased > > as you suggested and finally it worked. > > > > We tested with player and it works, > > > > thanks again. > > > > Jose > > > >> Hmmm, two possibilities: > >> > >> 1) Try removing config.cache in the Player source dir, then run > >> configure > >> again (it may be using a cached value for the gazebo test). > >> > >> 2) If that fails, send me your config.log; there may be some other > >> reason > >> that the Gazebo test fails. > >> > >> A. > >> > >> > >> On Fri, 5 Mar 2004, Jose Sanchez wrote: > >> > >> > >>> Hi all, thanks for your replys, but I still don't get it to work > >>> > >> > >> > >>> First, when I run ./configure in gazebo, I didn't change anything on > > >>> the > >>> path. What I look is that gazebo worlds are installed in > >>> /usr/local/share/gazebo/worlds, however I make the export libraries > >>> you > >>> guys told me and now when I make locate gazebo.h it prompots > >>> > >>> linux:/home/jose/player-src-1.4rc2 # locate gazebo.h > >>> /home/ghulam/Documents/gazebo-src-0.3.0/libgazebo/gazebo.h > >>> /home/jose/gazebo-src-0.3.0/libgazebo/gazebo.h > >>> /usr/local/include/gazebo.h > >>> > >>> so gazebo.h is installed correctly. But player does not find it. I > >>> even try by configuring gazebo as ./configure --with-player=yes but > >>> still doesn't work. > >>> > >> > >> Andrew Howard email: ah...@po... > >> Department of Computer Science http: > >> www-robotics.usc.edu/~ahoward > >> University of Southern California phone: 1 (213) 740 6416 > >> Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696 > >> << Insert pithy saying here >>> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IBM Linux Tutorials > > Free Linux tutorial presented by Daniel Robbins, President and CEO of > > GenToo technologies. Learn everything from fundamentals to system > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > > _______________________________________________ > > Playerstage-users mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > -- > Richard Vaughan > School of Computing Science / Simon Fraser University > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > Andrew Howard email: ah...@po... Department of Computer Science http: www-robotics.usc.edu/~ahoward University of Southern California phone: 1 (213) 740 6416 Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696 << Insert pithy saying here >>> |
From: Brian G. <ge...@ro...> - 2004-03-08 19:35:11
|
On Mon, 8 Mar 2004, ahoward wrote: > 1. As it stands, the build process should detect which dependencies are > installed, and build the appropriate set of drivers. If it doesnt, that's > a bug in the build scripts (the build should not fail during compilation). Quite right; compiling and linking should *never* fail. If/when that happens, please report it to this list and/or the bug tracker. > Getting Player to build a *complete* set of drivers, on the other hand, > can be quite a challenge. The obvious solution is to use the various > package management tools available on the various *nix flavours and > distros (we already have a Gentoo ebuild). Any volunteers? Interesting....so we'd go ahead and install GSL and libgnomecanvas and such before building Player? Sounds like a good idea, but also a lot of work. Does RPM even support automatically installing prerequisite packages? As I recall, all it does is complain if you don't have things installed, leaving it to you to install them. That would be bad for us if, for example, the Player RPM refuses to install because you don't have the GSL installed. We want to be able to say, "package X *prefers* to have packages Y and Z installed first, but can proceed without them." > 2. I am also interested in enhancing support for dynamically loaded > drivers, but for different reasons. Increasingly, I see students writing > code that really belongs in the server, but which will never appear in the > "official" distribution. Hence I would like to see drivers that are > maintained outside the Player CVS tree, and loaded at run-time for > specific experiments. > > Note that Brian has already set up the dynamic-loading mechanism in the > server; we just need to brush this off a bit, write some documentation, > and perhaps provide a set of template files for "external drivers" (aka > browser plug-ins). I will probably do this myself if I can find a few > moments. This would be really easy. Much easier, in fact, than allowing for the drivers in the distro to each be either built as shared objects or directly linked into the server. All you need is an example Makefile and .cc file. In fact, I give an example in the Player manual of the compile/link line to use (in Linux, at least) and hanging out at the bottom of sicklms200.cc is an example of how to define the functions (i.e., _init() and _fini()) that are the interface between the loader and the shared object. If somebody wants to polish this up a bit, maybe release a "starter kit" for writing a dynamically loadable driver, go for it. brian. |
From: Brian G. <ge...@ro...> - 2004-03-08 19:12:31
|
On Mon, 8 Mar 2004, Nathan Farrington wrote: > Deleting the cache with 'Make clean' is an excellent idea. Go for it > Richard! I've wasted hours trying to get everything to compile and build > properly. Ok, the motion carries. I've just changed Player to delete its config.cache on 'make clean'. I'll leave it to the other maintainers to change their packages (e.g., Stage, Gazebo) as they want. All you need to do is add the following two lines to the toplevel Makefile.am: clean-local: rm -f config.cache Interestingly, I've noticed that some (newer?) autotools installations don't even create a cache. I guess that with faster computers, the cache wastes more time through confusion than it saves by caching results from system tests. > As the Player server grows and incorporates more and more device drivers > and algorithms, the damn thing gets harder to (1) configure, (2) make > without something going wrong, and (3) install correctly with Stage and > Gazebo. I think it may be time for a change. > > One possibility is to build the Player drivers as loadable modules > (similar to Linux device drivers). Then, the configuration utility could > try to build ALL of them by default, and skip over the ones missing > prerequisite software packages, or that are architecture specific to a > different platform. Player could then automatically load the correct > modules after it reads its configuration file at startup. Actually, creating loadable modules (instead of linking the drivers directly into the server) won't simplify anything. It's already our policy that each driver is built by default, unless: (1) a prerequisite software package (e.g., GSL, Gazebo) is not found; or (2) the driver is very new (e.g., wavefront, clodbuster), and not guaranteed to build correctly. The same logic would apply to building the drivers as shared objects; we'd just have the extra headache of creating the shared objects (probably with libtool) and then finding them in the filesytem at runtime. I should make it clear that I'm not opposed to building drivers as shared objects. In fact Player has supported loading such shared objects at startup for ages (with the -d command line arg), and the only reason that it's not an option right now to automatically build all the drivers in this way is that I haven't had the time to implement it. All I'm saying is that moving to shared objects won't help with whatever difficulties you're having in configuring and building Player. Can you explain these difficulties in more detail? Perhaps then we can determine a good fix. brian. |
From: Nathan F. <nfa...@sp...> - 2004-03-08 23:38:39
|
Brian, Two things. First, whenever Player, Stage, Gazebo, or LibRTK doesn't build correctly, I assume I did something wrong. That's why I haven't been reporting build errors. And, I can't figure out in what order I need to install the packages so that I get all of the visualization tools! And I have no idea what is going on with this RTK2 v. RTK3 thing, and why RTK3 has its own configure script?! It's driving me nuts. Second, I use Player for three different purposes: (1) for simulation of multiple robots with Stage and Gazebo, (2) for controlling a Segway RMP, and (3) for controlling several ActivMedia Pioneer robots. For simulation, I can use a full blown Linux distribution on a high-end machine with all the niceties (like GSL, OpenGL, etc.). But for controlling the robots, I install my own custom made, stripped down Linux onto a 266MHz Pentium-class single board computer with 128MB of RAM and 128MB of flash secondary storage. Basically, I need to have 3 separate Player configurations for my 3 separate platforms. I like to create a Player binary with every driver I can for my simulation system. This makes sure I can experiment with everyone else's drivers and try them out. For the two embedded Player configurations, I try to include only the drivers that I need. The reason is not just to reduce the Player binary file size. The primary reason is that I don't have all the other libraries installed on the embedded computer (like GSL). By default, Player will try to build and link all the drivers it can into the Player binary. When I build Player on my desktop and try to use the binary on the embedded computer, Player fails because it can't find the libraries I had on my desktop! And I don't even want to use the drivers that need those libraries! So that is why I want loadable modules. I want to be able to copy sicklms200.o, p2os.o, and segwayrmp.o to my embedded computer as individual drivers, and not have to copy amcl.o, and all the other drivers that Player links by default. I've also been experimenting with my own server drivers. For instance, I made a very basic 'Detection and Tracking of Moving Objects' algorithm. It works server-side and I've shoehorned it into a fiducial interface (not the best interface, but it works). Trying to build multiple Player configurations for multiple platforms, while trying to develop custom drivers, is a nightmare! I think Andrew's suggestion of allowing custom server side drivers to be linked into Player would be very helpful for my development. I wouldn't have to keep rebuilding player every time, which means I don't have to put Player into my CVS repository anymore. Regards, Nathan Farrington -----Original Message----- From: pla...@li... [mailto:pla...@li...] On Behalf Of Brian Gerkey Sent: Monday, March 08, 2004 11:04 AM To: Nathan Farrington Cc: pla...@li... Subject: Re: [Playerstage-developers] Suggestions for Makefiles and configuration On Mon, 8 Mar 2004, Nathan Farrington wrote: > As the Player server grows and incorporates more and more device drivers > and algorithms, the damn thing gets harder to (1) configure, (2) make > without something going wrong, and (3) install correctly with Stage and > Gazebo. I think it may be time for a change. > > One possibility is to build the Player drivers as loadable modules > (similar to Linux device drivers). Then, the configuration utility could > try to build ALL of them by default, and skip over the ones missing > prerequisite software packages, or that are architecture specific to a > different platform. Player could then automatically load the correct > modules after it reads its configuration file at startup. Actually, creating loadable modules (instead of linking the drivers directly into the server) won't simplify anything. It's already our policy that each driver is built by default, unless: (1) a prerequisite software package (e.g., GSL, Gazebo) is not found; or (2) the driver is very new (e.g., wavefront, clodbuster), and not guaranteed to build correctly. The same logic would apply to building the drivers as shared objects; we'd just have the extra headache of creating the shared objects (probably with libtool) and then finding them in the filesytem at runtime. I should make it clear that I'm not opposed to building drivers as shared objects. In fact Player has supported loading such shared objects at startup for ages (with the -d command line arg), and the only reason that it's not an option right now to automatically build all the drivers in this way is that I haven't had the time to implement it. All I'm saying is that moving to shared objects won't help with whatever difficulties you're having in configuring and building Player. Can you explain these difficulties in more detail? Perhaps then we can determine a good fix. brian. |
From: Brian G. <ge...@ro...> - 2004-03-09 05:13:20
|
On Mon, 8 Mar 2004, Nathan Farrington wrote: > Two things. First, whenever Player, Stage, Gazebo, or LibRTK doesn't > build correctly, I assume I did something wrong. That's why I haven't > been reporting build errors. And, I can't figure out in what order I > need to install the packages so that I get all of the visualization > tools! And I have no idea what is going on with this RTK2 v. RTK3 thing, > and why RTK3 has its own configure script?! It's driving me nuts. Well, if you frequently encounter problems during installation, then either you're dumb or we've done something wrong, at least by explaining things badly. I know that you're not dumb, and I know other smart people who haven't found the installation procedure to be terribly easy, so I'll go ahead and admit that we haven't done as much as we can to explain how things should go. You should install the following packages in the following order (for the record, this information is on the FAQ, though not all in one place): (1) librtk (2) gazebo (3) player (4) stage Note that, beginning with Stage 1.4, Stage should be installed *before* Player, just like Gazebo. And don't worry about librtk3. It's not meant to be used by anyone; it's only in the distro because the playermap utility needs it. Also, you might look at Richard's Wiki on this topic: http://deckard.cs.sfu.ca:8080/Wiki/PlayerStageGettingStarted > Basically, I need to have 3 separate Player configurations for my 3 > separate platforms. I like to create a Player binary with every driver I > can for my simulation system. This makes sure I can experiment with > everyone else's drivers and try them out. > > For the two embedded Player configurations, I try to include only the > drivers that I need. The reason is not just to reduce the Player binary > file size. The primary reason is that I don't have all the other > libraries installed on the embedded computer (like GSL). By default, > Player will try to build and link all the drivers it can into the Player > binary. When I build Player on my desktop and try to use the binary on > the embedded computer, Player fails because it can't find the libraries > I had on my desktop! And I don't even want to use the drivers that need > those libraries! > > So that is why I want loadable modules. I want to be able to copy > sicklms200.o, p2os.o, and segwayrmp.o to my embedded computer as > individual drivers, and not have to copy amcl.o, and all the other > drivers that Player links by default. Aha; you want *fewer* drivers; most people want *more* drivers. So, one solution is to add support for building the drivers as shared objects. Frankly, I won't have time to do this anytime soon. If anybody out there is handy with libtool and wants to do this (or help with it) let me know. Another solution, which I use, is to just write a couple of shell scripts, each of which runs Player's configure with the appropriate arguments to include and exclude drivers as appropriate. Take a look at 'config.p2os' and 'config.simulation' in the toplevel of Player's source tree for examples. Depending on which platform you're building for, you would run the appropriate shell script and then make. The downside to this approach is that you have to explicitly *exclude* all the drivers that you don't want. Would a --disable-all option to the configure script, which would exclude everything and then let you include only those drivers that you want, be useful? > I've also been experimenting with my own server drivers. For instance, I > made a very basic 'Detection and Tracking of Moving Objects' algorithm. > It works server-side and I've shoehorned it into a fiducial interface > (not the best interface, but it works). Trying to build multiple Player > configurations for multiple platforms, while trying to develop custom > drivers, is a nightmare! I think Andrew's suggestion of allowing custom > server side drivers to be linked into Player would be very helpful for > my development. I wouldn't have to keep rebuilding player every time, > which means I don't have to put Player into my CVS repository anymore. Ok, since there's a demand, I'll supply an example of how to build your own drivers as shared objects. Please hold. brian. -- Brian P. Gerkey ge...@ro... Stanford Robotics Lab http://robotics.stanford.edu/~gerkey |
From: Richard V. <va...@cs...> - 2004-03-09 08:26:47
|
On Mar 8, 2004, at 9:04 PM, Brian Gerkey wrote: > > Would a --disable-all option to > the configure script, which would exclude everything and then let you > include only those drivers that you want, be useful? Yes, that'd be a good thing. My lab will soon be building Player for some very small embedded devices and we only want the single (new) driver we're developing. A single switch to turn everything else off and reduce Player's footprint would be great. In addition to these teeny robots, we're also working on Player drivers for the NOMAD robot daemon and the ROBOTEQ motor controller. There are lots of NOMADs out there that could be revived with a bit of Player goodness, and the ROBOTEQ device is being promoted by VIA as a nice match for their mini-ITX boards for robot applications. We're building a custom outdoor robot based on an VIA EPIA M10000 and a ROBOTECH controller. rtv. -- Richard Vaughan School of Computing Science / Simon Fraser University |
From: Brian G. <ge...@ro...> - 2004-03-10 19:24:25
|
On Tue, 9 Mar 2004, Richard Vaughan wrote: > On Mar 8, 2004, at 9:04 PM, Brian Gerkey wrote: > > > > > Would a --disable-all option to > > the configure script, which would exclude everything and then let you > > include only those drivers that you want, be useful? > > Yes, that'd be a good thing. My lab will soon be building Player for > some very small embedded devices and we only want the single (new) > driver we're developing. A single switch to turn everything else off > and reduce Player's footprint would be great. I had a stab at this yesterday and it turned out to be harder than I suspected. Not to say that it can't or won't be done, but it probably won't be done anytime soon. For now, your best is maintain a little shell script that runs configure with --disable-<foo> for all the foos that you don't need (again, look in the Player source tree at config.p2os and config.simulation for examples; but note that they are not necessarily up-to-date). brian. -- Brian P. Gerkey ge...@ro... Stanford Robotics Lab http://robotics.stanford.edu/~gerkey |