Spanish/Doc/Player

From The Player Project

Revision as of 10:38, 6 June 2009 by Thjc (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

/* Fichero de documentación de Player - parsed by Doxygen for the user

* manual
* $Id: player.txt,v 1.8 2006/02/17 18:34:20 gerkey Exp $
  • /

/** @mainpage The Player Robot %Device Interface

Copyright Brian Gerkey y contribuidores 1999-2006, y posterior. <p>Parte del proyecto Player/Stage/Gazebo [1] \section Introducción <p> Playes es un interfaz para dispositivos robóticos. ¿Qué significa esto? Hablando en la terminología de sistemas operativos (SS.OO) , Player es una Capa de abstraccion del Hardware (Hardware Abstraction Layer: HAL) para dispositivos robóticos. El sitema operativo (Linux, Mac OS X, etc. ) oculta los detallos del hardware del ordenador definiendo unos conceptos genéricos como son el "ratón", y la "impresora", cada uno con un interfaz estandarizado. Los programas como los procesadores de textos pueden (en gran medida) evitar conocer los detalles de su ratón o impresora particular, siempre que se adhieran a utilizar el interfaz adecuado. Los detalles necesarios para hacer que un ratón particular tenga soporte para el interfaz estándar "ratón" son manejados por un driver

Player tiene el mismo objetivo para dispositivos robóticos, pudiendo así ser considerado una especie de sistema operativo para robots (Robot OS). Player define una serie de interfaces estándar (@ref interfaces), cada uno de los cuales es una especificación de las formas en las que se puede interactuar con alguna clase de dispositivos. Por ejemplo el interfaz @ref interface_position2d es usado por los robots móviles que se mueven por el suelo, permitiéndoles aceptar comandos que les hacen moverse (con objetivos a conseguir en velocidad o en posición) y devuelve su estado (la velocidad y la posición actual). Muchos drivers dan soporte al interfaz @ref interface_position2d, incluyendo los drivers @ref driver_p2os, @ref driver_obot, y @ref driver_rflex, cada uno de los cules controla un tipo de robot diferente. El trabajo del driver es hacer que el robot de soporte a un interfaz definido como estándar. Así el código de control escrito para Player que es usado en un robot podrá funcionar (dentro de unos límites razonables) en otro robot.

\section Transporte

Player también pone a disposición de los usuarios unos mecanismos de transporte que permiten a los datos ser intercambiados entre los drivers y los programas de control que están siendo ejecutados en máquinas distintas. Con gran diferencia el método de transporte más común en uso hoy en día es un transporte cliente/servidor basado en sockets TCP (vea @ref start para ver un ejemplo de su uso). En esta configuración el programa @ref util_player es ejecutado con un fichero de configuración (@ref tutorial_config) que define qué drivers deben inicializarse y cómo se vinculan con el hardware. Los drivers se ejecutan en el servidor player (a menudo en múltiples hilos) y el programa de control de control actua como cliente para este servidor. @ref clientlibs están disponibles en varios lenguajes para facilitar el desarrollo de estos programs de control. Otros métodos de transporte pueden ser utilizados en su lugar, por ejemplo un transporte basado en JINI experimentar está también disponible.

\section repository Player como un repositorio de código

Aunque la mayoría de los drivers de Player controlan directamente el hardware, últimamente han sido desarrollados una serie de drivers abstractos. Un driver abstracto usa otros drivers, en vez de como hardware, como fuentes de datos y como lugar donde enviar comandos. El uso fundamentar de los drivers abstractos es encapsular algoritmos útiles de tal forma que puedan ser reutilizados fácilmente. Por ejemplo, el driver @ref driver_amcl es una implementación de localización adaptativa Monte Carlo, un algoritmo sobradamente conocido para la localización probabilística de un robot móvil. Este driver tiene soporte para los interfaces @ref interface_position2d (de tal forma que pueda ser usado directamente en vez de la odometría) y el interfaz más sofisticado @ref interface_localize (que permite que múltiples hipótesis sobre la localización del robot puedan ser tenidas en cuenta). Además de esta imprementación increiblemente útil de un algoritmo de localización en particular, definiendo interfaces estandarizados se crea un entorno en el cual algoritmos e implementaciones alternativas pueden ser desarrollados y puestas a prueba. Otros drivers abstractos incluyen los drivers @ref driver_vfh, @ref driver_wavefront, y @ref driver_laserbarcode. En un futuro ideal, Player se convertira en una plataforma de desarrollo común y un repositorio del código de la comunidad para este tipo de algoritmos.

\section Versiones

Este documento describe la versión de Player 2.x que representa un cambio significativo con respecto a las versiones 1.6.x . La información no puede ser utilizada para versiones anteriores de Player

\section Licencia

El código fuente de Player y su documentación está disponible bajo los términos de la licencia GNU General Public License v2. Una copia de esta licencia debe ser incluida con el código fuente en el fichero COPYING. La copia y la redistribución está perminida solamente bajo los términos de esa licencia. Las librerías de cliente están simultaneamente disponibles bajo los terminos de la GNU Lesser General Public License v2.1.

  • /

/** @page help Obteniendo ayuda

Si tiene problemas y no puede encontrar lo que necesita aquí, hay varios lugares donde buscar ayuda.

Primero, compruebe <a href="http://playerstage.sourceforge.net/index.php?src=doc">la página de documentación online</a> para asegurarse de que esta documentación se corresponde a la última documentación. También compruebe <a href="http://playerstage.sourceforge.net/index.php?src=faq">la página de preguntas frecuentes online</a>.

Como siguiente paso, podría buscar dentro de <a href="http://sourceforge.net/mailarchive/forum.php?forum_id=8201">los archivos de la lista de correo playerstage-users</a> para comprobar si sus dudas no han sido solucionadas allí previamente.

Si no se soluciona su problema, puede gastar unos minutos con <a href=http://www.google.com>Google</a>. Esto a menudo funciona ya que podrá encontrar conversaciones relacionadas con Player/Stage/Gazebo en todo Internet.

Si aún necesita ayuda, puede enviar un email a la lista de correo playerstage-users@lists.sourceforge.net y algún usuario o desarrollador quizá le solucione su duda. Recuerde que estos correos van a cientos de personas, así que por favor sea correcto y proporcione tanta información como le sea posible en el correo. El idioma oficial de la lista de correo es el inglés.

Para más pistas sobre obtener ayuda eche un vistazo <a href="http://playerstage.sourceforge.net/index.php?src=faq#reporting_bugs">aquí</a>.

  • /

/** @defgroup libplayercore libplayercore

\section synopsis Resumen Esta biblioteca C++ define las llamadas para programar los driver, las colas de mensajes usadas para mover los mensajes entre dispositivos, utilidades para leer los ficheros de configuración y para cargar y crear instancias de los drivers.

Los componentes principales de libplayercore son:

 - @ref message_basics : La mensajería básica basada en Player, incluyendo límites de tamaño, especificaciones de unidades, y estructuras de dirección.
 - @ref interfaces : La sintaxis y la semántica para cada interfaz de la biblioteca.
 - @ref ConfigFile : Parseo de los ficheros de configuración.
 - @ref Message : El objeto básico usado para pasar la información.
 - @ref MessageQueue : Los mensajes son enviados y puesto en colas; cada driver tiene una. 
 - @ref Driver : La clase de la que todos los drivers heredan.
 - @ref Device : Un drivers cuya instancia ha sido creada y que esta unido a un interfaz; todos los accesos externos al driver son mediantos uno o mas objetos Device. 

\section linking Ejemplo de compilación y enlace El uso más común de libplayercore es construir un driver como un plugin para Player. Si el código de tu driver es mydriver.cc, se puede construir con el siguiente comando (en Linux): \code

 $ g++ `pkg-config --cflags playercore` -o -shared mydriver.so mydriver.cc `pkg-config --libs playercore`

\endcode


  • /

/** @defgroup libplayererror libplayererror

Esta biblioteca C proporciona avisos de errore y utilidades para sacar información de depurado. En vez de llamar directamente a la biblioteca stdio (printf, puts, etc.), usa macros predefinidas en error.h, de tal format que la cantidad de mensajes que aparecerán pueda ser controlada de una forma centralizada y que todos los mensajes puedan ser escritos en un fichero .player.

  • /

/** @defgroup tutorials Tutoriales

Posteriormente se encuentran varios tutoriales sobre temas diversos que puedan ser de interés para un usuario de Plaer. El objetivo de estos documentos es proporcionar al usuario explicaciones concisas (con ejemplos siempre que sea posible) de los conceptos más importantes y de las tareas comunes.

Por favor contribuye! Si tienes algo que añadir, si es añadir un nuevo tutorial, aumentar un tutorial existente o sugerir uno nuevo. Envía tus contribuciones a la lista de correo: playerstage-users@lists.sourceforge.net.

  • /

/** @defgroup utils Utilidades de Player @brief Utilidades de Player

Varias utilidades están incluidas con la distribución de Player:

  • /

/** @defgroup clientlibs bibliotecas para el cliente

Las bibliotecas están disponibles en varios lenguajes para facilitar el desarrolo de los programas cliente TCP. Probablemente usará una de estas librerías para desarrollar el programa de control del robot si, como la mayoría de la gente, está utilizando @ref util_player (tanto con hardware como en emulación).

También esté seguro de echar un vistazo a <a href="http://playerstage.sourceforge.net/index.php?src=contrib">librerías contribuidas.</a>.

  • /
Personal tools