2. Tengo una plataforma hardware de un robot, la cual esta basada en un PIC-microcontrolador (o un FPGA) y quiero incorporar el MRS, es decir, quiero poder hacer una aplicacion en el Visual Programming Language (VPL)del MRS y ese codigo poderlo bajar a mi plataforma, es posible??, que tan abierto esta el MRS para poder manipular esto?
Sí, es posible interactuar con una plataforma basada en un PIC microcontrolador con MSRS. Pero debes tener en cuenta que el código que escribas en MSRS nunca se va a ejecutar en el propio PIC.
MSRS está basado en la plataforma .NET y por lo tanto se ejecuta siempre en una máquina que tenga instalado .NET Framework o .NET Compact Framework.
Bajo mi punto de vista la solución más simple para tu caso es desarrollar los servicios de MSRS que necesites para comunicarte desde un PC con el PIC (via serie, USB, bluetooth, WiFI, o de la línea de comunicación de que dispongas). Una vez hecho esto, el código de control que desarrolles con el VPL por ejemplo se ejecutará en el PC que mandará los comandos necesarios al robot y a su vez obtendrá la información de los sensores.
Por otro lado, si no quieres ejecutar nada en un PC y lo que quieres es que todo el código de control del robot se ejecute en el propio robot físicamente, tienes la opción de usar una PDA o similar con soporte para .NET Compact framework, en ese caso sí que puedes escribir el programa con el MSRS y luego ejecutarlo en la propiar PDA o teléfono Windows Mobile que va montado en el robot...Raúl Arrabales Moreno. conscious-robots.com/raul
El administrador ha deshabilitado la escritura de mensajes a los usuarios no registrados.
tenemos un irobot create, pero el "control de acciones" del robot lo queremos hacer desde un FPGA, es decir, que el FPGA mande los comandos necesiaros en forma serial al robot. Por otro lado este FPGA tendra un sistema operativo (SO) Linux corriendo en el y este SO tendra los algoritmos en c++ para controlar las acciones del robot, el desafio es integrar MSRS a este sistema.
Sabemos que con MSRS podemos programar el irobot create directamente por medio un puerto (tipo serial). Lo que queremos hacer es captar esa "compilacion" que hace el MSRS y poderlo meter al SO Linux dentro del FPGA y que el FPGA se encargue de enviarle los comandos al robot (y no que se haga directamente), segun entendi en tu mensaje que debemos tener corriendo .NET forzosamente, pero es posible planteandote el entorno que tenemos??
gracias nuevamente
El administrador ha deshabilitado la escritura de mensajes a los usuarios no registrados.
Raúl
Moderador Moderador
Mensajes: 444
Karma: 6
Re:Robot PIC-microcontrolador y Robotics Studio - 2007/10/29 14:15Hola, la verdad es que no consigo entender cuál sería el papel de Robotics Studio en el escenario que planteas. En realidad yo veo estas posibles opciones:
A.- No usar MSRS, y simplemente controlar el iRobot con el código en C++ que se ejecuta en una pequeña máquina Linux que puede ir montada sobre el robot.
B.- Usar MSRS para escribir el código de control del robot, B.1. y ejecutar el código en un PC de sobremesa, B.2. o poner un mini-PC (placa mini-ATX o similar con soporte para .NET framework).
C.- Usar MSRS para escribir código de control y también una FPGA montada en el robot. (creo que es la opción que planteas tú).
La opción A entiendo que sería la mejor en el caso de que tengas mucho código ya desarrollado en C++, preparado para funcionar con Linux y con el iRobot Create en particular. Si no es así, yo personalmente preferiría usar MSRS porque dispondrías de mucha más flexibilidad.
La opción B es mi preferida, porque podrías depurar todo el código de control que escribas con el simulador de Robotics Studio (el Visual Simulation Environment), podrías escribir aplicaciones usando el VPL (Lenguaje de programación visual) y además podrías reutilizar tus servicios para otros robots. El requisito fundamental es que necesitas .NET Framework en la máquina en la que se ejecute el código. Si, como pretendes, quieres que la CPU que controla el robot vaya montada en el propio robot, puedes buscar una solución del tipo B.2 (en vez de una FPGA). Por ejemplo, mira como se han montado los iRobot Create para la competición de Sumo MEDC 2007:
Al robot le añaden un mini PC (embedded PC) ICOP eBox 2300s y una cámara Logitech. De esta forma el robot es totalmente autónomo y ejecuta los servicios DSS en la CPU de a bordo.
Sobre la opción C, para mi no tiene mucho sentido (porque creo que no he entendido bien lo que quieres conseguir). Si ya tienes el código de control escrito en MSRS (es decir, en algún lenguaje sobre .NET o en VPL), ¿para qué necesitas el código en C++ que quieres ejecutar en la FPGA? Y si lo que quieres usar es sólo el código en C++, volveríamos a la opción A. ¿Cuál es exactamente la razón por la cual quieres conectar la salida de MSRS con la FPGA y no usar sólo una de las dos opciones?Raúl Arrabales Moreno. conscious-robots.com/raul
El administrador ha deshabilitado la escritura de mensajes a los usuarios no registrados.
mira el entorno que te platico de tener la FPGA con un linux embebido que se encarga de controlar el robot, es porque todos los drivers del brazo y de la camara los tenemos ya hechos en vhdl (por lo que necesitan ser implementados en la FPGA), ademas hemos hecho algunos "cores" de vision tambien en vhdl que actuaran junto con la camara, asi que tener la FPGA controlando el robot es casi una obligacion para nosotros.
Con el MSRS simplemente queremos ofrecerle al usuario una nueva alternativa para que programe sus "algoritmos de navegacion" en forma esquematica, como lo hace el VPL, en lugar de solo tener la opcion de programar en C++. Es decir, que el usuario pueda hacer su algoritmo en VPL y despues de alguna forma, este algoritmo pueda ser ejecutado por el linux embebido que corre en el FPGA (ya que este linux va a ser el que controle todo el comportamiento del robot, del brazo y de la camara), por eso te decia la opcion de pasar ese algoritmo hecho en VPL a codigo de c++, o algo parecido que pueda ejecutar el linux embebido.
Otro ejemplo podria ser que el usuario pueda hacer una parte de su aplicacion en MSRS y despues otra parte en codigo C++ (quiza porque algunas cosas que no se puedan hacer en el VPL, tenga la opcion de hacerlas en C++), y al final juntar estas dos partes para que el linux embebido pueda ejecutar el codigo completo. Algo asi como un flujo de diseño hibrido. Es por eso que queremos que el linux embebido se haga cargo de todo (ya a bajo nivel).
Queremos saber si el MSRS cuando baja su codigo al robot hace un codigo "intermedio" (una especie de compilacion) que nosotros podamos agarrar o utilizar para meterlo en el linux embebido, y éste se encargue de mandarle los comandos al robot.
Bueno Raul espero haberme dado a explicar y ojala puedas ayudarnos con tus consejos y con tu experiencia que llevas en este campo, nosotros como te podras imaginar apenas estamos empezando.
Gracias y Saludos
El administrador ha deshabilitado la escritura de mensajes a los usuarios no registrados.
Raúl
Moderador Moderador
Mensajes: 444
Karma: 6
Re:Robot PIC-microcontrolador y Robotics Studio - 2007/10/30 15:05Hola, ahora entiendo lo que queréis hacer. La verdad es que yo diría que lo tenéis bastante avanzado. Ya veo que dada vuestra situación no os interesaría la opción B. Eso sería una opción válida para alguien que empieza de cero con ese robot, pero si ya tenéis los diseños en VHDL y los algoritmos de visión quizás no tenga mucho sentido.
Lo que sí es muy buena idea es lo de dar a los usuarios la posibilidad de usar el VPL para generar sus propios comportamientos. Y en realidad sí que podríais usar MSRS para esto, pero más que hacerlo como un esquema de control híbrido sería un sistema de control por capas o niveles (al menos, es como yo lo veo viable).
Me explico: en realidad MSRS no genera ningún código intermedio para el robot como sospechas. Lo que genera es el código intermedio de .NET. Es decir, tu escribes tus servicios en C#, o en VB.Net, o con el VPL y eso al compilarlo genera un ensamblado (assembly) que está en CLI (Common Intermediate Language).
Todos los servicios se ejecutan en el CLR (Common Language Runtime). Es decir, se ejecutan en una máquina son .NET Framework (o .NET Compact Framework). La gran ventaja de MSRS es que este código usa las bibliotecas CCR y DSS (que también se ejecutan en el CLR), proporcionando las facilidades necesarias para orquetrar servicios y coordinar la entrada-salida asíncrona.
Pues bien, como vosotros tenéis un robot que ya tiene un sistema de control embebido (la FPGA con Linux), lo que podríais hacer para que un usuario pueda programar el robot con MSRS sería lo siguiente:
Tendríais que escribir servicios de MSRS que se comuniquen con el controlador FPGA de robot. Esto habría que hacerlo en ambos sentidos: tanto para mandar comandos al robot, como para recibir información de los sensores del robot. Una vez hecho esto, estos servicios estarían disponibles en el VPL para los usuarios que quisieran usarlos.
Por ejemplo, hay en MSRS un servicio genérico para una tracción diferencial (diferencial drive). Este servicio genérico se podría implementar como un servicio específico (eso no es más que una implementación de un interfaz – o de un contrato genético en la nomenclatura de MSRS). Vuestro servicio, pongamos que se llama JC_DifferentialDrive mandaría comandos al controlador FPGA por medio de alguna línea de comunicación. Un programa escrito en VPL usaría el servicio JC_DifferentialDrive como una estancia específica del servicio genérico DifferentialDrive. De esta forma, el mismo programa VPL que se usa para controlar un Lego NXT o un Pioneer 3 DX serviría para controlar vuestro iRobot Create.
Espero haberte aclarado un poco más las opciones disponibles…Raúl Arrabales Moreno. conscious-robots.com/raul
El administrador ha deshabilitado la escritura de mensajes a los usuarios no registrados.
gracias por tus comentarios, han sido de mucha utilidad y nos han servido para aclarar el panorama.
Lo que me comentas en el ultimo parrafo de hacer nuestros propios servicios, hay alguna documentacion en su sitio (o en la documentacion del Robotics Studio) para hacer esto?, o algun ejercicio parecido en donde desarrollen sus propios servicios? Tenemos idea de como hacer lo de los servicios, pero no mucha.
nuevamente gracias
El administrador ha deshabilitado la escritura de mensajes a los usuarios no registrados.
Yo te diría que el primer paso para escribir servicios en MSRS es entender qué son y para qué sirven el CCR y el DSS. Estoy trabajando en unos manuales en español, pero mientras tanto lo único que tengo son las siguientes guías sobre cómo aprender a usar el MSRS y el VPL. Lo que he intentado es dar un orden lógico para leer la documentación disponible:
Los enlaces anteriores no son manuales, sino que establecen simplemente un orden para la lectura de la documentación disponible en la página de Microsoft.
Seguir los tutoriales de servicios y de robótica en C# da una idea de cómo funciona todo, si bien es cierto que se necesita un conocimiento previo de qué es el CCR y sus principales llamadas para entenderlo completamente.
Voy a ver la documentación que tengo sin publicar en español, porque a lo mejor tengo algo parecido a los tutoriales que hay en inglés que pueda ser de utilidad. Espero publicarlo en la web la semana que viene (pondré aquí un enlace)..Raúl Arrabales Moreno. conscious-robots.com/raul
El administrador ha deshabilitado la escritura de mensajes a los usuarios no registrados.
Desde la vez en que me explicaste como es el proceso de "compilacion" del MSRS me quede con una duda.
Segun entendi, cuando hago mi aplicacion en el VPL, esto al compilarlo me genera un codigo ensamblador que esta en CLI, una vez estando en este lenguaje se ejecutan gracias al CLR, ambas "herramientas" propias del .NET framework, asi que por eso se necesita una maquina que este corriendo .NET framework, cierto??
Lo que no entendi es que todo esto se ejecuta en mi PC y ya despues se le manda en comandos que entiende el robot, o quiere decir que dentro del robot se esta corriendo el .NET framework??, es decir, yo entiendo que se tienen 2 computadoras, mi PC (que es donde tengo windows, MSRS, las herramientas del Visual Studio, etc) y la otra "computadora", que es la que tiene el robot por dentro, ya que este tiene un microprocesador que es el que manda todos los comandos a los sensores y actuadores a bajo nivel, porque nosostros como usuarios el mas bajo nivel con el que podemos mandar comandos al robot es por serial, nosotros le mandamos una serie de numeros con el protocolo serial y el microprocesador del robot se encarga de "traducir" todos esos numeros en acciones del robot.
En resumen no entiendo que es lo que se le manda al robot por el cable que le conecto de mi computadora al robot, se mandan ya los comandos en forma serial??, o poniendolo de otra forma, todo eso del CLI y el CLR (.NET framework) se ejecuta en mi PC o es que el robot tiene corriendo dentro de el el .NET framework??
Otra cosa, que tan "tratable" es ese codigo ensamblador en CLI??, es decifrable?? es decir, que tan viable es hacer un interprete (o si existen interpretes) que de alguna forma me puedan cambiar de ese codigo ensamblador a lenguaje C++ por ejemplo??
Gracias por tu respuesta Saludos
El administrador ha deshabilitado la escritura de mensajes a los usuarios no registrados.
Raúl
Moderador Moderador
Mensajes: 444
Karma: 6
Re:Robot PIC-microcontrolador y Robotics Studio - 2007/11/07 19:19Hola, Cuando diseñas una aplicación en VPL, es decir, un diagrama o un conjunto de diagramas, hay un generador de código que genera el código correspondiente a tu aplicación en C# (C Sharp). Esto significa que el código C# se compila y se genera a su vez el correspondiente ensamblado (assembly) en código CLI. Y como bien dices el ensamblado en CLI se ejecuta en el runtime de .NET (el CLR). Por lo tanto, todo el código que generes con el VPL necesita ejecutarse en un entorno .NET Framework (o .NET Compact Framework). De hecho puedes utilizar VPL para escribir aplicaciones para .NET que no sean de robótica. Eso sí, necesitan usar el DSS.
Sobre la segunda pregunta que haces: normalmente dentro del robot NO se ejecuta .NET Framework. Como bien distingues, normalmente hay al menos dos computadoras. Una es la que va embebida en el robot y No ejecuta .Net Framework (la llamaremos PC-ROBOT), la otra es por ejemplo tu PC de sobremesa (la llamaremos PC-CONTROL). Un posible escenario es en el que PC-CONTROL es un PC con Windows (y con .NET Framework) que ejecuta diversos servicios de Robotics Studio. Estos servicios son capaces de comunicarse por el interfaz serie con el PC-ROBOT. De esta forma tu aplicación VPL es capaz de leer los sensores del robot a través de la información que PC-ROBOT envía a PC-CONTROL. Y también es capaz de mandar comandos de PC-CONTROL a PC-ROBOT.
Como vosotros mandáis unos números mediante un protocolo serie, la forma de controlar esto en MSRS es mediante servicios que se encarguen de mandar estos números desde PC-CONTROL a PC-ROBOT. Como dices, es PC-ROBOT el que se encarga de interpretar ese número y realizar el comando correspondiente en el hardware del robot. En definitiva, lo que se mandan son los comando, no el código de tu aplicación en .NET.
Sobre la última pregunta que me haces en relación al desensamblado de los ensamblados en CLI, no soy un experto en .NET. Sé que se puede ver muy fácilmente el código ensamblados CLI con un visor (por ejemplo, este: [1]). A parte del propio interprete que es el CLR de .NET, sé que existe MONO [2], que es un porting de .NET para Linux, pero no creo que soporte toda la funcionalidad necesaria para MSRS.
Espero haber solucionado tus dudas. Por supuesto existen más escenarios posibles de funcionamiento. Ahora mismo estoy haciendo algunas pruebas con mi código en VPL, así que si descubro algo más relacionado con el tema lo contaré aquí.
Foros... 
Fuente RSS de Conscious Robots
