[Jderobot-dev] Interfaces GazeboServer

Sab Feb 16 12:29:25 CET 2013

Hola,

[madurando interfaces]

ahora ya recuerdo, perdón por el lío. Efectivamente es como dice Fran:
(a) para el movimiento del robot completo (toda la plataforma) con la
interfaz motors y su posición con encoders. (b) para el movimiento del
cuello mecánico con pose3Dmotors y su posición con pose3Dencoders. 

Las interfaces ptmotors y ptencoders están obsoletas, las buenas son
pose3Dmotors y pose3Dencoders. Cambiamos a estas para hacerlas más
genéricos y valieran, por ejemplo para el cuello mecánico del robot Nao,
que incluyeran roll y reflejar la posición-orientación de cámaras en el
aire, en 3D.

El interfaz de movimiento clásico "motors" ofrece típicamente velocidad
de giro (w) y velocidad de avance (v) de toda la plataforma completa.
Esto valía perfectamente para robots como el Pioneer o los TurtleBot2
que acaban de llegar. En el Pioneer esas órdenes v-w el middleware del
fabricante las transforma internamente a los comandos oportunos para el
motor izquierdo y motor derecho. Esa interfaz motors la extendimos para
usarla también con el Nao, enriqueciendo el interfaz con un tercer
movimiento lateral (l). En el caso del Nao el servidor traducía esas
órdenes v-w-l a los comandos oportunos para las articulaciones de patas
usando modos de caminar. En el caso de robots de ruedas esa l se ignora
olimpicamente.

La parte de motores la veo clara: mantener motors para el robot entero y
pose3Dmotors para los cuellos mecánicos. Quizá la duda ahora es ver qué
hacemos con encoders y pose3Dencoders. Uno de los proyectos que estamos
ahora desarrollando es un robot aéreo, donde el manejo de posiciones
tridimensionales es intensivo. Quizá la opción más sensata, aunque lleve
algo de refactorización, es usar ese formato pose3Dencoders para TODO lo
que sea posición 3D (+orientación, claro): tanto la posición del robot
(sea el que sea Nao, AvionVolador, Pioneer, AutoNav, etc) y también para
posición del cuello mecánico, cámaras en 3D, sensores Kinect, etc. Creo
que ya lo estamos usando en autolocalización visual. El interfaz
encoders se queda muy corto, sólo encaja para robots que se mueven por
mundo plano, casi lo pasaría a obsoleto. Los robots planos pueden usar
tranquilamente pose3Dencoders poniendo la z a 0 y los ángulos pitch y
roll a 0 también, usando sólo x-y-yaw. ¿Cómo lo veis?

Definir bien interfaces y que todos los componentes los respeten aumenta
la interoperabilidad, lleva su tiempo pero es muy bueno. Por ejemplo
permite usar el mismo teleoperador para el Nao, Pioneer, Autonav, etc. o
que la posición 3D se exprese siempre de la misma manera en todas
nuestras aplicaciones. La posición es sencilla: XYZ respecto de algún
sistema de referencia, pero la orientación es más peliaguda. Hay muchas
maneras de representarla: angulos de Euler, yaw-pitch-roll,
cuaterniones, etc... Actualmente en pose3Dencoders usa yaw-pitch-roll.

Asi que GazeboServer tendría que ofrecer 'motors' para el robot,
'pose3Dmotors' para cada cuello y 'pose3Dencoders' para cada cuello y
para el propio robot completo. Por cierto igual le podemos cambiar el
nombre a Pose3D, más aséptico, que ahora no tendrá mucho que ver con
encoders...

Ideas? Comentarios?

JoseMaria
On Wed, 2013-02-13 at 13:30 +0100, franciscomiguel.rivas en urjc.es wrote:
> Buenas,
> efectivamente Alex, el Pose3DMotors se creó para cuellos mecánicos  
> dando soporte a pan, tilt y roll y el motors para controlar  
> desplazamiento con robots con v y w.
> 
> Yo los usé para el controlador de nao, los pose3D para cada unas de  
> las articulaciones y los motors para la abstracción de la locomoción.
> 
> No veo la forma de combinar las dos, que supongo que es lo que se  
> busca para el gazeboserver y que sea lo mas genérico posible... pero  
> siempre va a depender de lo que se esté simulando...
> 
> Yo mantendría los dos interfaces como se vienen utilizando:
> pose3dencoders para cuellos
> motors para los motores con v y w.
> 
> 
> ¿no te valen estos interfaces? ¿necesitas meter alguna información mas?
> 
> 
> un saludo,
> Fran.
> 
> 
> 
> 
> "Alejandro Hernández" <ahcorde en gmail.com> escribió:
> 
> > Hola a todos,
> >
> > abro este hilo para comentar sobre las interfaces de GazeboServer.
> > Actualmente se utilizan las interfaces *motors.ice* y* encoders.ice,* pero
> > deberían de ser *Pose3dEncoders.ice* y *Pose3DMotors.ice* . Mirando las
> > interfaces hay cosas que no me cuadran. Estas interfaces según parece están
> > pensadas para un Pan&Tilt y no para los motores de un robot..
> >
> > Qué es lo más correcto:
> >
> >    -  ¿Dejar las que existe ?
> >    -  ¿Cambiar a pose3DEncoders y pose3Dmotors?
> >    - ¿Crear unas nuevas PTPose3dMotor y  PTPose3dMotor para el Pan&Tilt y
> >    modificar las existentes para los robot?
> >
> > Un saludo.
> >
> > Álex.
> >
> > --
> > Alejandro Hernández Cordero
> >
> > <http://www.linkedin.com/in/ahcorde/en>  <https://twitter.com/ahcorde>
> > <https://plus.google.com/u/0/114434050324725472734/posts>
> >   <http://github.com/ahcorde>
> >
> > Play and visit my Curriculum vitae ->
> > https://googledrive.com/host/0BytBL_SySiIjX19Pd1o5dlZaRHc/Game.html
> >
> 
> 
> 
> ------------------------------------------------------------------
> Laboratorio de Análisis del Movimiento, Biomecánica, Ergonomía y  
> Control Motor (LAMBECOM).
> Departamento de Fisioterapia, Terapia Ocupacional, Rehabilitación y  
> Medicina Física.
> Universidad Rey Juan Carlos (URJC).
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers

-- 
http://gsyc.es/jmplaza 
Universidad Rey Juan Carlos