RE: [Playerstage-developers] Suggestions for Makefiles and configuration

[Nathan F. <nfa...@sp...>]

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.