logo logo
Home arrow Forums...
Thursday, 09 February 2012
 
 
Main Menu
Home
Conscious Machines...
AI Techniques...
Neuroscience...
Researchers...
Publications...
Reviews...
MC Bibliography
Robotics Studio...
Forums...
Blog...
Frontpage
Upcoming Events
22.Feb. 2012

CogSys 2012
Vienna, Austria
04.Apr. 2012

TSC 2012
Tucson, Arizona
17.May. 2012

EAIS 2012
Madrid, Spain
05.Jun. 2012

Cognition & Consciousness
Menorca. Spain
02.Jul. 2012

ASSC 16
Brighton, UK
02.Jul. 2012

Revisiting Turing and his Test
Birmingham, UK
31.Oct. 2012

BICA 2012
Palermo. Italy
Tag Cloud
Architectures Associations Books Conferences Conscious Conscious Machines Consciousness Developer Documentación Documentation Español Machine Machine Consciousness Machines Neuroscience Publications Research Researchers Reviews Robotics Robots Spanish Studio VPL
Spotlight
More
Reader's Preferred
MCexperts List
FAQs
Glossary
Site Map
 
Conscious-Robots.com Forum  


hector
User

Junior Boarder
Posts: 6
graphgraph
Karma: 1  
Dudas con el Pioneer 3DX real y simulado - 2010/07/09 14:40 Hola a todos:

Me gustaría, si es posible, que me ayudases a entender mejor el comportamiento del MRS en el siguiente caso:

En mi proyecto de fin de carrera, tengo que utilizar el robot Pioneer 3DX. Para ello primero he creado un servicio que simula el robot de forma similar al tutorial "Robotics Tutorial 4 - Drive-By-Wire" añadiendo algunos servicios mas, como el GPS Simulado, Sonar Simulado creados por Raúl. Y ahora querría trasladar lo que he hecho en el simulador, al robot Pioneer real.

Con lo que tendria que utilizar los servicios de Arcos (ArcosBumper, ArcosDrive, ArcosCore) y el servicio Arcos Sonar (de Raúl). Para ello he tomado como ejemplo, el servicio "Explorer" que viene en la distribución del RSD (RDS Local Code Location Path: samplesMiscExplorer).

Pero he visto que en ningún momento se subscribe a dichos servicios, y sí a las servicios genericos:
Code:

  using bumper Microsoft.Robotics.Services.ContactSensor.Proxy; using drive Microsoft.Robotics.Services.Drive.Proxy; using sicklrf Microsoft.Robotics.Services.Sensors.SickLRF.Proxy;


Por lo que tampoco se añade ninguna referencia de Arcos.
Pero en el manifiest de dicho servicio, si se hace referencia de estos servicios:
Code:

  <Manifest  xmlns:arcosdrive="http://schemas.microsoft.com/robotics/2006/06/arcosdrive.user.html" xmlns:explorer="http://schemas.microsoft.com/robotics/2006/07/explorer.user.html"  xmlns:arcosbumper="http://schemas.microsoft.com/robotics/2006/06/arcosbumper.user.html" xmlns:this="urn:uuid:8312abfc-c10e-4274-94fd-b0fde9c8cd84"  xmlns:arcoscore="http://schemas.microsoft.com/xw/2005/12/arcoscore.user.html"  xmlns:dssp="http://schemas.microsoft.com/xw/2004/10/dssp.html" xmlns="http://schemas.microsoft.com/xw/2004/10/manifest.html">   <!--   Starts the Explorer orchestration with partner services for MobilesRobots Pioneer 3DX.   -->   <CreateServiceList>     <ServiceRecordType>       <dssp:Contract>http://schemas.microsoft.com/robotics/2006/06/arcosbumper.user.html</dssp:Contract>       <dssp:PartnerList>         <dssp:Partner>           <dssp:Contract>http://schemas.microsoft.com/xw/2005/12/arcoscore.user.html</dssp:Contract>           <dssp:PartnerList />           <dssp:Name>arcosbumper:Arcos</dssp:Name>           <dssp:ServiceName>this:ArcosCore</dssp:ServiceName>         </dssp:Partner>       </dssp:PartnerList>       <Name>this:arcosbumper</Name>     </ServiceRecordType>     <ServiceRecordType>       <dssp:Contract>http://schemas.microsoft.com/robotics/2006/06/arcosdrive.user.html</dssp:Contract>       <dssp:PartnerList>         <dssp:Partner>           <dssp:Contract>http://schemas.microsoft.com/xw/2005/12/arcoscore.user.html</dssp:Contract>           <dssp:PartnerList />           <dssp:Name>arcosdrive:Arcos</dssp:Name>           <dssp:ServiceName>this:ArcosCore</dssp:ServiceName>         </dssp:Partner>       </dssp:PartnerList>       <Name>this:arcosdrive</Name>     </ServiceRecordType>     <ServiceRecordType>       <dssp:Contract>http://schemas.microsoft.com/robotics/2006/07/explorer.user.html</dssp:Contract>       <dssp:PartnerList>         <dssp:Partner>           <dssp:Contract>http://schemas.microsoft.com/2006/06/contactsensor.html</dssp:Contract>           <dssp:PartnerList />           <dssp:Name>explorer:Bumper</dssp:Name>           <dssp:ServiceName>this:arcosbumper</dssp:ServiceName>         </dssp:Partner>         <dssp:Partner>           <dssp:Contract>http://schemas.microsoft.com/robotics/2006/05/drive.html</dssp:Contract>           <dssp:PartnerList />           <dssp:Name>explorer:Drive</dssp:Name>           <dssp:ServiceName>this:arcosdrive</dssp:ServiceName>         </dssp:Partner>       </dssp:PartnerList>       <Name>this:explorer</Name>     </ServiceRecordType>     <ServiceRecordType>       <dssp:Contract>http://schemas.microsoft.com/xw/2005/12/arcoscore.user.html</dssp:Contract>       <dssp:PartnerList />       <Name>this:ArcosCore</Name>     </ServiceRecordType>   </CreateServiceList> </Manifest>



Quizás parecerá absurda la duda, pero es que no entiendo por qué se hace de esta forma. Ya que mi idea era usar estos servicios directamente en el proyecto del VS. Es decir, agrerar referencias al proyecto de los componentes de Arcos y utilizarlos.

Luego también el proyecto del VS que simula el Pioneer, utilizo operaciones del Drive, que no está o no son iguales que en el ArcosDrive, un ejemplo:
En la simulación tengo:
Code:

  drive Microsoft.Robotics.Services.Drive.Proxy; ... drive.DriveDistanceRequest re = new drive.DriveDistanceRequest(); re.Distance 10.0; re.Power 1.0; yield return Arbiter.Choice(     _drivePort.SetDrivePower(request),     delegate(DefaultUpdateResponseType response) { },     delegate(Fault fault)     {         LogError(null"Unable to stop"fault);     } ); ...


En este caso, para movernos 10 metros, por ejemplo, debemos rellenar los atributos Distance y Power del objeto DriveDistanceRequest.
Pero segun el servicio de Arcos, según lo veo yo, se realiza de otra forma:
Code:

  using arcosdrive Microsoft.Robotics.Services.MobileRobots.ArcosDrive.Proxy; ... arcosdrive.TranslateRequest request = new arcosdrive.TranslateRequest(); request.Distance 10; _drivePort.Translate(request);



En este caso, el objeto TranslateRequest solo tiene un atributo, Distance, y además es un objeto diferente al caso anterior.

Mi pregunta es por lo tanto, si el codigo realizado en la simulación, luego me serviria para utilizarlo con el robot real. Y si no se puediese, que cambios tendría que realizar, con respecto a la simulación.

Espero que mas o menos me haya explicado bien, y se entienda . Y muchisimas gracias por vuestra respuesta, que me será de mucho ayuda y utilizada.

Saludos.

Héctor.
  The administrator has disabled public write access. Please, register to participate in the forum.
Raúl
Moderator

Moderator
Posts: 590
graph
Karma: 10  
Re:Dudas con el Pioneer 3DX real y simulado - 2010/07/13 17:23 Hola, creo que he entendido bien la pregunta y la respuesta tiene un poco de trampa

El tema es que en teoría lo ideal es usar siempre contratos genéricos. De hecho aquí radica (en teoría) una de las grandes ventajas de usar RDS.

La clave de usar contratos genéricos es que hacen tu código independiente del hardware que finalmente uses. Pero claro, la realidad siempre es un poco más cruda.

En un mundo ideal tendrías por ejemplo los contratos genéricos de Drive y Laser. Podrías escribir un servicio para navegar un robot en función de las medidas del láser que podría compilarse sin conocer aún qué hardware se va a usar (sólo sabrías que necesitas un drive y un láser). Es decir, en tiempo de compilación no se sabe qué robot vas a controlar: un Lego, un P3DX o un robot simulado.

Para que en tiempo de ejecución tu programa llegue a funcionar correctamente es necesario que cuentes con servicios concretos de Drive y Laser para el robot que vas a controlar en tiempo de ejecución. Esto es: si tienes un Lego NXT, en tu manifest harás referencia a los servicios Drive y Laser de Lego NXT (mal ejemplo porque Lego no tiene Laser, pero bueno, es sólo para ilustrar la idea).

Si no tienes a mano un robot real y quieres probar tu servicio de contro, pues necesitas implementaciones de los servicios Drive y Laser para el simulador, es decir, unos servicios que simulen los motores y un laser en el mundo virtual. Estos podrían ser los que comentas que estás usando.

¿Dónde está el problema entonces? Pues que no siempre los servicios concretos (que implementan contratos genéricos) tienen todas las operaciones implementadas o las implementan como era de esperar...

En definitiva, siendo prácticos y en línea con lo que comentas, no te queda más remedio que ir probando que efectivamente las operaciones que usas del contrato genérico estén bien implementadas en el servicio concreto que se comunica con el robot real. Porque si no, te puedes encontrar con la sorpresa de que algo que funciona bien en el simulador no funciona igual en el mundo real.

Por ejemplo, a mi me ha pasado lo siguiente: una misma llamada al contrato genérico de Drive para girar -50 grados, en el simulador gira a la izquierda y en el robot real gira a la derecha... No debería ser así, pero el problema viene de que no se ha definido claramente la semántica de las operaciones genéricas desde el principio...
Raúl Arrabales Moreno. conscious-robots.com/raul
  The administrator has disabled public write access. Please, register to participate in the forum.





Lost Password?
No account yet? Register
 Conscious Robots RSS FeedConscious Robots RSS Feed

Find us on Facebook

Follow us on TwitterFollow us on twitter
Spotlight

Machine Consciousness Bibliography Database

 

ConsScale
The Cognitive Machine Consciousness Scale

 
Last Posts in Forum
 
CR
miel continental