Basic FAQ

From The Player Project

Jump to: navigation, search
m (I have problems, documentation didn't help me, how can I get help?)
(+ developers section + one more FAQ from the ML)
Line 73: Line 73:
==How do I cross-compile Player (e.g., for the iPAQ or Gumstix)?==
==How do I cross-compile Player (e.g., for the iPAQ or Gumstix)?==
Of course you can find the [http://playerstage.sourceforge.net/doc/Player-cvs/player/group__tutorial__crosscompiling.html proper tutorial] for this.
Of course you can find the [http://playerstage.sourceforge.net/doc/Player-cvs/player/group__tutorial__crosscompiling.html proper tutorial] for this.
 +
 +
==What is the difference between Player and Stage and Gazebo? What is the difference between Player device drivers and simulated device models in Stage or Gazebo?==
 +
 +
See the explanation on [[Player#How_Player_works | How Player works]]
==When I try to connect to Player, I get "connection refused."==
==When I try to connect to Player, I get "connection refused."==
Line 164: Line 168:
odometry will be reported.
odometry will be reported.
-
==What is the difference between Player and Stage and Gazebo? What is the difference between Player device drivers and simulated device models in Stage or Gazebo?==
+
==Suppose I write a Plugin, how do I set it up to have its own messages?==
-
See the explanation on [[Player#How_Player_works | How Player works]]
+
The 'opaque' interface is designed for this purpose.  It allows you 
 +
to exchange messages with arbitrary content.  On the client side, 
 +
there's an OpaqueProxy.  Of course, there will not be XDR wrappers 
 +
for your custom messages, so you have to do your own (de)marshaling 
 +
on each side.
 +
 
 +
The opaque interface is usually used to prototype new interfaces and/
 +
or extensions to existing interfaces.  After some testing and 
 +
refinement, these additions can be submitted for consideration to be 
 +
included in player.h, at which point they'll be fully supported, with 
 +
XDR wrappers, client-side proxies, etc.
Line 236: Line 250:
For Player users, see the FAQ entry on reading camera data; from Player's perspective, Gazebo cameras work just like real cameras (which means you can develop image processing algorithms using Gazebo-simulated images).
For Player users, see the FAQ entry on reading camera data; from Player's perspective, Gazebo cameras work just like real cameras (which means you can develop image processing algorithms using Gazebo-simulated images).
 +
 +
 +
=Developers=
 +
 +
==How do I get the latest code?==
 +
 +
All the code for the project is mantained in a CVS repository at SourceForge. An excellent source of CVS documentation (besides the CVS [http://www.gnu.org/manual/cvs-1.9/cvs.html manual]) is [http://www.loria.fr/~molli/cvs/doc/cvs_toc.html here]. Project-specific instructions for CVS access, both anonymous and read/write, are [http://sourceforge.net/cvs/?group_id=42445 here].
 +
 +
We keep our code organized into CVS modules, and that is how you should access it. You should '''not''' check out directories directly, because you will bypass any module dependencies that we have set up. The following modules will likely be of greatest interest to you:
 +
* player
 +
* stage
 +
* gazebo
 +
 +
 +
==How do I build from CVS?==
 +
 +
Since we're using the GNU Autotools, it's a little different to build from CVS instead of from a distribution. First, you need autoconf and automake installed. They are already installed on any reasonable UNIX-like machine, but you might need to upgrade them; you can download both packages from any GNU mirror. We're currently using:
 +
* autoconf 2.53
 +
* automake 1.6
 +
 +
Newer versions will probably work, but older ones probably won't. If you do use newer versions, keep in mind that you should not use any macros that aren't available in the versions listed above, because that will likely break the build for other developers.
 +
 +
Building from CVS involve the same steps:
 +
 +
# ./autoreconf -i -s  OR  ./bootstrap
 +
# ./configure [options]
 +
# make
 +
# make install (optional)
 +
 +
The autoreconf tool runs the right Autotools in the right order to generate necessary files, including a configure script. You only need to supply the -i -s arguments the first time you use autoreconf on a checked out copy. If autoreconf doesn't work for you (older versions were pretty buggy), then you can run the bootstrap script instead, which does the same thing.
 +
 +
You only usually need to run autoreconf when some part of the build system, such as configure.in or acinclude.m4, has changed; at other times, you can just run configure, or even just make. However, it's safest to run autoreconf whenever you udpate from CVS, in case something important changed. The exact dependencies among the various files and tools are of course deterministic but extremely complex and it's best not to think about them.
 +
 +
One more thing: since we're using automake, we don't write Makefiles. Instead, we write Makefile.ams (automake files), which are like meta-Makefiles. Except in special cases, Makefiles (and Makefile.ins) are auto-generated and should not be checked in.
 +
 +
 +
==

Revision as of 09:13, 31 July 2006

Personal tools