• English

En este post vamos a explicar cómo podemos solucionar varios de los problemas de instalación del software de LEGO Educación en diferentes versiones de sistemas operativos de Mac y Windows. Para poder solucionar cada uno de los diferentes fallos debemos descargar un pequeño archivo (llamado parche o “patch”) que nos permitirá solucionar el error. Estos archivos se descargan desde la página de LEGO Education: www.LEGOeducation.com. Una vez hemos accedido a la página hemos de dirigirnos al enlace “MINDSTORMS downloads” y accederemos a la siguiente página, que contiene un listado muy grande de descargas.

A la izquierda debemos seleccionar sólamente las opciones de “Lower Primary”, “Upper Primary”, “Secondary” y “Software Update/Patch” para filtrar y que nos aparezcan sólo los parches para solucionar los fallos de software. La página cambiará y mostrará el suiguiente listado:

A continuación explicaremos brevemente para qué sirve cada una de esos parches:

Para WeDo:

- WeDo MAC: soluciona el problema de instalación en Mac OS 10.7 Lion y las incompatibilidades con Flash 11. Tras la descarga hay que descomprimir el contenido en el escritorio. Este programa debe ser ejecutado cuando el CD de WeDo espera para comenzar la instalación. Se puede encontrar más información en el archivo “Read me” que incluye la descarga. Es necesario que sea la versión 1.2 del software de WeDo.

- WeDo Windows: actualiza la versión 1.2 del software, lo que soluciona la incompatibilidad con Flash 11. Tras la descarga se debe ejecutar el archivo “setup.exe” y seguir las instrucciones que muestre la ventana.

- MAC OS 10.5 (Leopard) Sound Fix for WeDo: soluciona un problema que no permite que el micrófono del ordenador grabe sonido en el software de WeDo en un Mac OS 10.5. Tras la descarga se debe descomprimir el archivo y ejecutar el archivo “WeDo update” que aparece e la nueva carpeta creada tras la descompresión.

- MAC OS 10.7 (Lion) Installer Fix for WeDo: permite la instalación en un MAC OS 10.7 Lion. Tras la descarga hay que descomprimir el contenido en el escritorio. A continuación se deben seguir las instrucciones del archivo “Read me” y se debe ejecutar cuando el CD de WeDo espera para comenzar la instalación. Después de ejecutar este parche se debe ejecutar otro, llamado “WeDo Mac”.

Para LEGO Mindstorms NXT Education Software:

- MAC OS 10.7 (Lion) Installer Fix for NXT: existe un problema que impide instalar el software Mindstomrs NXT en un MAC OS 10.7 Lion a 64 bits. Para poder instalarlo hay que introducir el CD y abrir el contenido del disco. Después se debe ejecutar el archivo terminado en “.mpkg” cuyo nombre se corresponda con el idioma seleccionado.
Si esto no funciona se debería probar lo anterior abriendo el sistema operativo a 32 bits. Para ello se deben presionar simultáneamente las teclas 3 y 2 al encender el ordenador.

- NXT EDU 2.0f3 for Windows: esta aplicación soluciona problemas de compilador y la incompatibilidad con Flash 10.1 que tiene la versión 2.0. Para ello se debe descargar la aplicación y ejecutar el archivo “setup.exe”, y a continuación hay que seguir las instrucciones en pantalla.

- NXT EDU 2.1f3 for Windows: similar a la anterior, esta aplicación soluciona problemas de compilador y la incompatibilidad con Flash 10.1 que tiene la versión 2.1. Este parche sólo es válido si se ha utilizado el parche “NXT Patch”. Para ello se debe descargar la aplicación y ejecutar el archivo “setup.exe”, y a continuación hay que seguir las instrucciones en pantalla.

- NXT EDU 2.f5 for MAC: esta aplicación sirve para corregir todos los fallos de software y los fallos de Flash de la versión 2.0, aunque no añade ningún contenido nuevo. Para ejecutarla se debe tener instalada la version 2.0 y tras la descarga se deben seguir las instrucciones que aparecen en pantalla.

- NXT EDU 2.1f5 for MAC: similar a la anterior, esta aplicación soluciona los problemas de la versión 2.1. Tampoco añade contenido nuevo. Para ejecutarla se debe tener instalada la version 2.1 y tras la descarga se deben seguir las instrucciones que aparecen en pantalla.

- NXT Patch: este parche actualiza la versión 2.0 a la versión 2.1 del software de LEGO Education, incluyendo el Data Logging y otras herramientas del programa.

- Windows 7 Script: este parche permite instalar el software de Mindstorms en un Windows 7 Starter Edition. En primer lugar, si el software se encuentra en un medio físico o en una localización de red, se debe copiar el directorio que contiene el instalador al escritorio. Después se debe descargar el parche y copiar el archivo “AllowWindowsStarter.exe” en el directorio copiado anteriormente, que debería ser el mismo directorio que contiene los archivos “autorun.exe” y “setup.exe.”. Después, al abrir el archivo “AllowWindowsStarter.exe”, el equipo debería permitir la instalación al hacer ejecutar el “autorun.exe”.

En este artículo vamos a hacer una comparación entre los diferentes sets de Mindstorms NXT que están ahora en el mercado. Uno es el que distribuye LEGO por su rama comercial habitual, llamado LEGO Mindstorms NXT 2.0, cuya referencia es 8547. El otro modelo es el 9797, que distribuye LEGO Education, y que podemos encontrar en un pack junto al software de programación y el cargador de la batería. A continuación iremos desglosando el contenido de las cajas y viendo las diferencias que existen entre ellas.

La primera diferencia la encontramos en el packaging. Mientras que el NXT 2.0 viene presentado en caja de cartón sin divisiones, la versión educativa contiene una caja de plástico de almacenaje con dos bandejas repartidoras muy útiles para organizar, contar y no perder piezas.

El modelo 8547 no incluye la batería de litio recargable que nos trae el 9797, por lo que para usar el ladrillo NXT (controlador) se requieren 6 pilas alcalinas AA. Aún así, esta batería puede ser adquirida por separado. El modelo educativo, a su vez, también permite la utilización de pilas.

El número de engranajes de los sets también varía, pudiendo encontrar 31 engranajes en la versión educativa frente a los 11 de la versión comercial.

Puesto que ambos modelos han sido concebidos para distintos fines, vemos que el contenido en piezas varía de uno a otro. El 8547 incluye 620 piezas, seleccionadas para construir los cuatro modelos mostrados en la caja del producto a modo de ejemplos (Alpha-Rex, ShooterBot, Robo Gator y Colour Sorter). El NXT 9797 enfocado al aprendizaje y la investigación, contiene 431 piezas más variadas, con instrucciones para montar un robot modular que juega al golf. De todas formas, los diferentes surtidos de piezas se pueden combinar de múltiples formas para realizar los montajes que imagines. Además, las piezas que se usan no dejan de ser piezas Technic convencionales, y se pueden combinar con todos los otros modelos LEGO.

Aún así, existe un caja de ampliación, que contiene un gran surtido de piezas muy útiles a la hora de construir robots. Se trata de la 9695 Conjunto de recursos Mindstorms, en la que se incluyen instrucciones para montar nueve robots diferentes combinándola con la 9797.

Ahora hablaremos de los elementos electrónicos:

Sensores:

8547: 2 sensores de contacto, 1 sensor de ultrasonidos y 1 sensor de color (con tres funciones: detección de 6 colores básicos, intensidad luminosa y actuar como una lámpara con luz roja, azul o verde).

9797: 2 sensores de contacto, 1 sensor de sonido, 1 sensor de ultrasónidos, 1 sensor de luz.

Procesador:

Ambas versiones usan como procesador el 9841 Ladrillo Inteligente NXT.

Motores:

Ambas versiones incluyen 3 servomotores 9842 Servo Motor Interactivo NXT.

Cableado:

8547: 7 cables de conexión y 1 cable USB.
9797: 7 cables de conexión, 1 cable USB y 3 cables convertidores (para utilizar los sensores y motores de la versión RCX con NXT).

Software:

Es un lenguaje gráfico muy intuitivo que se basa en la generación de secuencias de iconos gráficos extraídos a partir de unas paletas de iconos. Este lenguaje, basado en LabVIEW, surge de la colaboración entre LEGO y National Instruments. A pesar de su simplicidad y facilidad de aprendizaje, dispone de características avanzadas que permitirán la creación de programas muy complejos. Se permite la generación de secuencias lineales, condicionales, bucles, trabajar con variables y constantes, creación de macros, acceso a ficheros, uso de mensajes, comunicación vía bluetooth, etc.

Esta programación es especialmente atractiva, siendo la funcionalidad de ambas versiones prácticamente la misma. A continuación, se señalarán las diferencias para las dos versiones.

El software educativo del 9797 incluye bloques de programación de los sensores y motores propios del RCX, así como el uso de lámparas, mientras que el de la versión 8547 no los incluye, aunque pueden ser descargados desde la página de actualizaciones de LEGO Mindstorms. Los idiomas disponibles son inglés, francés, alemán y holandés, mientras que la versión educativa nos permite su instalación en muchos más idiomas, incluyendo el castellano, que tiene una traducción de bastante calidad.

La principal diferencia entre las dos versiones de software radica en un apartado de apoyo del programa. En el software del 9797, este apartado se llama Robo Center y contiene instrucciones para construir los 4 montajes mencionados anteriormente, y algunos programas de ejemplo para hacer funcionar esos montajes. En la versión educativa nos encontraremos el Robot Educator, que contiene una guía con 50 tutoriales, que proponer 50 retos diferentes con guías de montaje y programación para cada uno. A través de la realización de estas actividades aprendemos a manejar y a comprender mejor todas las posibilidades que nos ofrece el software.

Por otro lado, en ambas versiones podemos encontrar herramientas que complementan las funciones del software. En el software del 8547 podemos encontrar un editor de imágenes (para añadir nuestras imágenes a la colección del motor), un editor de sonidos (para añadir sonidos externos a la biblioteca del robot), y un control remoto para manejar en tiempo real los motores de un vehículo construido con el Mindstorms. Estas herramientas no están presentes en el 9797, pero podemos encontrar una herramienta llamada Data Logging. Con ella podemos tomar los datos que reciben los sensores del robot y generar gráficas a tiempo real, muy útil para realizar experimentos científicos.

Por último, ambas versiones se pueden ampliar con nuevos comandos de programación, descargados desde la web de LEGO o de otros fabricantes que ofrecen otros sensores, como HiTechnic, o incluso se pueden crear nuevos bloques con LabVIEW.

• English

Brian Bagnall acaba de publicar un nuevo libro sobre la programación de robots creados con LEGO MINDSTORMS. Se trata del libro “Intelligence Unleashed: Creating Lego Nxt Robots with Java”. Recordemos que estamos ante uno de los grandes colaboradores en la comunidad leJOS NXJ, la plataforma Java Open Source para el NXT. Este autor ya publicó en el pasado otros títulos similares.

Con las sencillas instrucciones que posibilita el software leJOS NXJ, este nuevo manual facilita el aprendizaje perfecto del LEGO Mindstorms NXT, un kit increíble para construir y programar robots. Haciendo uso del Java, uno de los lenguajes de programación más popular y fácil de usar, y con la ayuda de este libro, permitirá convertir en realidad los robots de nuestros sueños que tanto ingenieros como aficionados han deseado diseñar y construir. Se trata de todo un diverso conjunto de proyectos que se acompaña de trucos de construcción, código de programación, instrucciones de montaje renderizadas en 3D, y cientos de ilustraciones. Este nuevo manual sirve como complemento perfecto para el juego de LEGO NXT: en él se trabajan tanto las posibilidades de comunicación bluetooth del ladrillo inteligente NXT, como los nuevos sensores disponibles, desde el GPS hasta el sensor RFID.

En breve dispondremos de unidades de este nuevo ejemplar, por lo que podremos dar más detalles.

El Cambio climático es la mayor amenaza medioambiental a la que nos enfrentamos toda la humanidad. Si bien los cambios climáticos han existido desde los orígenes de la Tierra, una de las causas que diferencia al actual es la velocidad a la que está sucediendo. Este proceso acelerado de cambio no viene provocado por la Naturaleza, sino por la acción del hombre mediante la tala indiscriminada de arboles, el mal uso del agua potable, etc. Esto ha dado lugar al término Calentamiento Global.

Podemos definir el Calentamiento Global como el cambio originado en el clima producido directa o indirectamente por la acción del hombre y que se suma a la variabilidad natural del clima. Tal y como se recoge en esta definición, el clima sufre una variabilidad natural, pero es mucho más lenta y progresiva que la que está ocurriendo hoy en día.

El último informe de la Intergovernmental Panel no Climate Change (IPCC) nos indica que la temperatura de la tierra ha aumentado 0.6º C en los últimos 100 años, y que se prevee aumentará, en los próximos 100, entre 1.0ºC y 3.5ºC.

Científicos de todo el mundo coinciden en que una de las maneras de paliar ó aminorar está destrucción progresiva del Medio Ambiente, será utilizando las energías alternativas. Una fuente de energía alternativa es aquella que puede suplir a las energías o fuentes energéticas actuales, ya sea por su menor efecto contaminante, o fundamentalmente por su posibilidad de renovación.

Denominamos Energía Renovable a la energía que se obtiene de fuentes naturales virtualmente inagotables, unas por la inmensa cantidad de energía que contienen, y otras porque son capaces de regenerarse por medios naturales. Pueden dividirse en dos categorías: no contaminantes ó limpias y contaminantes. Entre las primeras, nos encontramos con:

Energía Azul, que es la energía que se obtiene por la diferencia en la concentración de la sal entre el agua de mar y el agua de río mediante el uso de la electrodiálisis inversa -o de la ósmosis- con membranas de iones específicos. El residuo en este proceso es agua salobre.

Energía Eólica. ó lo que es lo mismo, la energía cinética generada por efecto de las corrientes de aire, y que es transformada en otras formas útiles para las actividades humanas.

El viento hace girar las aspas del aerogenerador (normalmente suelen ser tres), y ésta energía de rotación se transforma a través de un conjunto de engranajes en energía eléctrica mediante un dinamo gigante. Para conseguir una mayor eficiencia suele emplazarse la turbina en una zona elevada con respecto al suelo. Por este motivo solemos ver los aerogeneradores en lo alto de grandes torres o mástiles.

El tamaño de las aspas delimita el radio del área que éstas barren al girar, por lo que para incrementar la potencia generada de un aerogenerador debemos alargar la longitud de las aspas. Los aerogeneradores domésticos, con unos diámetros entre 1 y 5 metros, pueden generar desde 400 W a 3 kW. Estos generadores son capaces de funcionar con vientos más suaves que los de mayor tamaño, que requieren de una velocidad mínima superior para empezar a funcionar. Como podemos imaginarnos el estudio de la ubicación del aerogenerador será determinante en el rendimiento obtenido del mismo.

Energía Geotérmica es aquella energía que puede obtenerse mediante el aprovechamiento del calor del interior de la Tierra.

Energía Hidráulica: aquella que se obtiene del aprovechamiento de las energías cinética y potencial de la corriente del agua, saltos de agua o mareas, generalmente de los ríos y corrientes de agua dulce.

Energía Mareomotriz, que es la que se obtiene aprovechando las mareas. El efecto gravitatorio de la Luna sobre la Tierra produce desplazamientos de las masas de agua terrestres, dependiendo de la posición relativa de la Tierra y la Luna. Las mareas modifican la altura media de los mares y ésta diferencia de alturas puede aprovecharse interponiendo partes móviles al movimiento natural de ascenso o descenso de las aguas, junto con mecanismos de canalización y depósito. Si bien se trata de una energía de bajo costo no contaminante, silenciosa y disponible en cualquier clima y época del año, su gran inconveniente es el impacto visual y estructural sobre el paisaje costero.

Energía Solar es la energía obtenida mediante la captación de la luz y el calor emitidos por el Sol. Cada año el sol arroja cuatro mil veces más energía que la que consumimos, siendo su potencial prácticamente ilimitado. Se trata de una energía gratuita cuya utilización no produce emisiones de gases de efecto invernadero.

• La Energía Solar Fotovoltaica se emplea para generar electricidad. Esta energía se consigue a través de una instalación fotovoltaica, que consta de un conjunto de células solares, que son las que conforman los paneles solares, un regulador de carga, un acumulador y un inversor. Los paneles solares son los encargados de transformar, gracias al efecto fotoeléctrico, la energía fotovoltaica procedente del sol en energía eléctrica, en concreto en forma de corriente contínua. Acto seguido ésta se almacena en los acumuladores. Este almacenaje permite disponer de energía no sólo en lo momentos en los que ésta se produce, sino en instantes de baja o nula productividad (consecuencia de la presencia de nubes, una mala orientación, horas nocturnas, etc.). Por último, la finalidad del inversor es la de transformar la corriente contínua, almacenada en los acumuladores, en la corriente alterna para su uso doméstico.
• La Energía Solar Térmica, que genera calor, es la que se utiliza para producción de agua caliente, en calefacción, climatización de piscinas, etc. Se trata de la más económica y rentable de las energías renovables.

Otros usos menos conocidos de esta Fuente de Energía es la Potabilización del Agua, las Estufas Solares, la Refrigeración ó la Destilación.

La preocupación de LEGO por el tema se muestra a través de modelos comerciales como los mostrados anteriormente o, por ejemplo, en la presencia de los paneles solares del actual LEGO Creator 5771, la casa de la colina.

Pero más patente es la fuerte apuesta de LEGO Education por inculcar en los futuros científicos, que ahora son nuestros pequeños, la preocupación por el medio ambiente, la influencia de nuestra presencia en el mismo y la forma de encontrar solución a nuestras necesidades energéticas cada vez mayores. En esa línea podemos trabajar el tema de las energías renovables a través del conjunto 9688, que puede combinarse bien con el LEGO MINDSTORMS NXT 9797 o bien con el conjunto de mecanismos simples y motorizados 9686.

El 9594 es un conjunto temático que guía a los estudiantes a través de la construcción con LEGO MINDSTORMS y mediante la programación de una manera estructurada. Contiene tres tapetes de entrenamiento, una alfombra de desafío y un montón de elementos para la construcción de los modelos del desafío, tales como una turbina para la planta de energía eólica o la presa. Disponemos además de las actividades adicionales proporcionadas por el 2009594.

El nuevo desafío ecológico es pues, crear un nuevo paradigma que defina las condiciones del equilibrio entre el Hombre y la Naturaleza. Para ello, hemos empezado a concebir un nuevo estilo de ciudad, la ecológica, donde la gente es consciente de sus responsabilidades para el medio ambiente, de tal manera que los problemas medioambientales son comentados de una manera continua y proactiva.

Agricultura a pequeña escala, incluso la agricultura tradicional con sus sistemas de regadío sostenida por los propios habitantes, el uso de aerogeneradores, celulas solares, la edificación a menor altura que permita la circulación de las corrientes de aire, reduciendo el uso de aparatos de aire acondicionado, reservar un 20% de la superficie de la ciudad a zonas verdes ó el transporte mejorado, con grandes zonas peatonales, hacen que, en su conjunto, el Impacto Medioambiental se reduzca en un alto porcentaje. De esta manera, podemos concluir con que una ciudad ecológia se caracteriza por: el uso de eficiente de la energía, el reciclaje, la agricultura comunitaria y la peatonalización.

El pasado Sábado 21 de mayo se celebró el Scratch day 2011 en Madrid. ElectricBricks impartió dos talleres, uno dirigido a niños a partir de 8 años y otro dirigido a adultos.

Durante 3 horas, los niños conocieron a fondo el manejo de la herramienta, desarrollando y programando proyectos con Scratch y WeDo. El conjunto de construcción WeDo, perteneciente a la serie LEGO Education, permite construir y programar sencillos modelos LEGO conectados a un equipo informático.

En esta ocasión construimos una peonza que era impulsada a través de un brazo, dotado de un motor y un sensor de distancia. Los niños manejaron las piezas, aprendieron el funcionamiento de los engranajes, el concepto de fricción, todo ello en un entorno de diversión y colorido propio de LEGO. Con este tipo de actividades Electricbricks pone al alcance del niño el mundo de la ciencia y la tecnología desde un punto de vista educativo, propiciando su desarrollo cognitivo, es decir, el producto del esfuerzo del niño por comprender y actuar en el mundo.

Esta metodología no está vinculada ni a la inteligencia, ni al coeficiente intelectual, sino a la propia personalidad. Paralelamente, al observar, tocar, manipular y analizar cada uno de los proyectos propuestos, el niño va descubriendo objetos, creados directamente por él mismo, y sus características, mejorando así su desarrollo sensorial. Una de las actitudes que el niño aprende es a ayudar a los compañeros y a participar en retos colectivos de juego de carácter lúdico, sin que sea relevante el grado de resolución del proyecto propuesto, evitando así el carácter competitivo y fomentando a su vez el respeto hacia los demás y el conocimiento de las propias posibilidades.

Próximas actividades con Plazo de Matriculación abierto:

Cursos Intensivos:
JUNIO:
Primer Taller: 21, 22, 23 y 24.
Segundo Taller: 27, 28, 29 y 30.
JULIO
Tercer Taller: 4, 5, 6 y 7.
Horario: 17:00 a 20:00 (12h en total)
Edades: 8+

Os mostramos a continuación como se desarrolló la actividad.

El monitor explica el proyecto que se va a realizar.

Programando la peonza realizada con WeDo

Hoy os queremos presentar una versión de nuestro juego Asteroids para NXT, modificada por nuestro forero JIP. En este caso, se le ha añadido la posibilidad de controlar nuestra nave haciendo uso del Control Remoto IR de Power Functions (ref. 8885-1).

Los cambios se han realizado en el bloque Ship, que es el que controla la nave, el resto del programa se mantiene igual. En esta versión, el nuevo bloque recibirá la denominación Ship2.0, y en él se sustituye el control de la nave mediante los botones del NXT, por un sistema de control dependiente de las palancas del mando PF.

Primero hay una inicialización de variables

El canal del mando no esta prefijado en el programa si no que se lee del fichero canaliir cargándolo en la variable canal a través del bloque Cargar-canal.

Si no existe el fichero la variable canal toma el valor 1.

NOTA: Si no queréis hacer uso de un fichero, podéis pedir el valor del canal al usuario, almacenándolo en una variable, tal y como os explicamos en el apartado 2 del artículo sobre el sensor IR-receiver.

La lectura de los valores del control remoto se realiza en el bloque leermando

El resultado es un valor en la variable estado y a partir de su valor se mueve la nave por la pantalla.

Los valores posibles que retorna el control son

Estos valores se almacenan en las variables rojo y azul (para las direcciones) y projo y pazul (para las potencias).

El valor que se guardará en la variable estado depende de la posición de las palancas

Según el valor de la variable estado la nave se mueve por la pantalla de la siguiente manera

Como estaba en el original, a través de las variables ship_x, ship_y controlamos la posición para dibujar la nave. Por otro lado, las variables counter_x y counter_y controlan los limites de la pantalla (ancho y alto).

Os dejamos el programa para que podáis descargarlo y probarlo, es un fichero .zip que contiene, por un lado, el archivo Asterois20.rbtx (recordemos que es un encapsulado con todos los bloques, sonidos, imágenes, etc…), y por otro el archivo canaliir.txt.

Programa Asteroids 2.0

NOTA: Para que el programa funcione correctamente, será necesario enviar al NXT el fichero “canaliir.txt”.

Esperamos que os haya gustado y aprovechamos para agradecer de nuevo a JIP su aportación.

El Domingo 17 de Abril tuvo lugar el Primer Torneo de Fútbol Robótico en electricBricks. A pesar de que la asistencia fue menor que en otras competiciones debido a la fecha, el torneo fue muy intenso y divertido.
Tuvieron lugar tres partidos, en los que se enfrentaron cada vez dos equipos con cuatro robots cada uno, todos controlados remotamente, por infrarrojos (en el caso de los participantes que usaban Power Functions) o por Bluetooth (en el caso de los Mindstorms).

Los modelos Mindstorms de electricBricks estaban controlados desde PC, mientras que los que trajeron los asistentes eran PF puro o híbrido de NXT y PF, haciendo uso del sensor receptor de infrarrojos.

Las reglas eran las siguientes:

• English

Se denomina exoplaneta o planeta extrasolar a aquel planeta que se encuentra fuera de nuestro Sistema Solar. Si bien durante mucho tiempo se supuso su existencia, no ha sido hasta muy recientemente cuando se ha confirmado su existencia. El descubrimiento en 1992 del primero de ellos alentó el estudio sobre la posibilidad de vida extraterrestre. El objetivo del presente artículo es intentar emular, con carácter educativo, uno de los sistemas de detección de exoplanetas.

1.- Introducción.
Ante la pregunta de si estamos solos en el Universo los científicos se plantean la posibilidad de vida extraterrestre. Una forma de medir dicha probabilidad es mediante la ecuación de Drake, que es un modelo simple de estimar el número posible de civilizaciones extraterrestres en la Vía Láctea. Dicho cálculo requiere el conocer la posibilidad de que una estrella contenga planetas, lo que explica que la identificación de los primeros exoplanetas renovara el interés por la existencia de vida alienígena.

2.- Detección de exoplanetas.

La detección de planetas extrasolares mediante la observación visual directa sería el método que más información proporcionaría, pero este sistema es en la actualidad impracticable salvo en casos excepcionales. La falta de éxito de este sistema obliga al uso de métodos indirectos. El motivo por el que la visualización directa es tan difícil radica en que la luz que vemos reflejada por un planeta es comparativamente mucho menor que la de la estrella, del orden de una millonésima parte inferior. Es decir, la luz directa de la estrella suele deslumbrar respecto de la reflejada por el planeta. Los pocos casos en los que la visualización directa tiene éxito son aquellos en los que los exoplanetas son excepcionalmente grandes o muy alejados de la estrella

3.- Tránsito astronómico.

Se denomina tránsito al fenómeno en el que un astro pasa entre otro astro y el punto de observación. Dada esta situación, el astro que pasa delante del otro astro limita su visibilidad. Desde la Tierra podemos ver tránsitos planetarios, este fenómeno ocurre generalmente con Venus y Mercurio, distinguiéndose su silueta al pasar por delante del Sol. Otro fenómeno más espectacular, el eclipse solar, se considera también como tránsito astronómico. También son visibles los tránsitos de satélites sobre su planeta, como el de Titán sobre Saturno, que además deja ver su sombra sobre la superficie del planeta.

Imagen de Venus en tránsito delante del Sol.

El estudio de los tránsitos astronómicos es el método más extendido para el descubrimiento de exoplanetas. La observación sistemática de ciertas estrellas “sospechosas” de tener planetas orbitando a su alrededor permite ver variaciones en la intensidad de la luz que nos llega de ellas. Si se da una disminución en la intensidad de su luz de forma periódica, es muy probable que esté producida por el paso de un planeta por delante de dicha estrella. Este método se complementa con otros como la astrometría o el estudio de las velocidades radiales.

El gráfico anterior es una simulación en el que se representa la variación de la luminosidad motivada por el tránsito. La curva está normalizada verticalmente, y en el eje horizontal tenemos el transcurso temporal en número de horas. El valor importante a destacar de la gráfica es el intervalo existente entre los picos, que viene determinado por el tiempo de tránsito.

4.- Experimento con LEGO MINDSTORMS NXT.

Hemos planteado un experimento que utiliza el estudio del tránsito para descubrir si existen planetas orbitando alrededor de una estrella. Queremos comprobar si con el hardware disponible a nuestro alcance somos capaces de realizar una emulación de un pequeño sistema solar artificial, con una estrella y dos planetas orbitando a su alrededor, y de descubrir si, a través de la medida de infrarrojos realizada por nuestro satélite, somos capaces de discriminar los tránsitos de los planetas. Como “estrella” hemos usado la IR Ball, que ya usamos en artículos anteriores. A falta de la misma también se puede emplear una lámpara con bombilla incandescente o halógeno, puesto que necesitamos que se caliente y emita infrarrojos. Como planetas valdría cualquier objeto opaco.

Alrededor de esta estrella orbitan dos planetas con trayectorias diferentes y a diferente velocidad, controlados con un Mindstorms con dos motores. Las velocidades de los motores son diferentes, para que los ciclos de los planetas no coincidan. A continuación podemos ver un detalle de la mecánica que produce los movimientos de los tres astros.

Observando este sistema solar se encuentra un satélite. Como la estrella emite infrarrojos, el satélite está equipado con un Sensor de Búsqueda IR NXT para medir su emisión.

Con este experimento queremos comprobar si es posible descubrir el tránsito de algún planeta por delante de la estrella. En teoría, la estrella emite constantemente al mismo nivel, aunque presuponemos que habrá una ligera oscilación en la intensidad y que la recepción de los infrarrojos no será totalmente constante, debido a las limitaciones del sensor. Si un planeta pasa entre la estrella y el sensor, el nivel de infrarrojos recibido será menor que el de la estrella en cierto momento, que se repetirá a intervalos regulares.

Representación artística del experimento.

Aquí mostramos el programa del satélite, que es bastante sencillo. Básicamente es un bucle de 30 segundos de duración durante el cual se generan dos archivos: uno recoge los datos que recibe el sensor de infrarrojos y el otro recoge los datos del milisegundo en el que se toma la medida.

A continuación podemos ver un vídeo del experimento:

Y estos son los resultados que hemos obtenido. Hemos generado una gráfica que representa en el eje vertical el nivel de intensidad de los infrarrojos recibidos por el sensor, y en el eje horizontal el tiempo, en un intervalo de 30 segundos.

Se puede observar que si la estrella no tuviese ningún planeta la oscilación sería mínima. En el caso de que la estrella tenga un planeta, se pueden observar los picos en los que el planeta eclipsa la vista de la estrella, que se repiten a intervalos regulares. Si hay dos planetas se pueden observar dos intervalos diferentes, uno más corto y uno más largo. El más corto coincide con el intervalo del caso en el que había un planeta. El más largo es prácticamente 1,5 veces el corto, con lo cual coincide una de cada dos vueltas. Podemos ver un poco mejor los ciclos en la siguiente imagen.

Ahora ya sabéis cómo detectar planetas en el espacio exterior con nuestros robots. Aún así no aconsejamos lanzar un NXT al espacio… de momento.

5.- Conclusión.
Con el presente artículo mostramos la posibilidad de realizar tanto un experimento atípico como el darle un uso también atípico, tanto al sensor de infrarrojos como a la bola emisora de infrarrojos. En el futuro tenemos previsto realizar un segundo artículo ampliando las posibilidades del experimento, puesto que la elevada sensibilidad del sensor lo permite. Como opciones futuras para mejorar el experimento puede analizarse cuál es la influencia de los siguientes factores bien en la intensidad relativa de la señal recibida o en el período del tránsito medido modificando:

• Las distancias entre planetas y estrella.
• Las distancias entre estrella y satélite.
• Tamaño de los planetas.
• Tamaño relativo entre los planetas.
• Planeta orbitando en un plano distinto al del satélite, etc.

6.- Información adicional:

• Ecuación de Drake.
• The SAO/NASA Astrophysics Data System.
• Simulador de tránsito de exoplanetas.

La lógica difusa o lógica heuristica se basa en lo relativo de lo observado, utiliza expresiones que no son ni totalmente ciertas ni completamente falsas (lógica binaria o booleana), es decir, es la lógica aplicada a conceptos que pueden tomar un valor cualquiera de veracidad dentro de un conjunto de valores que oscilan entre dos extremos, la verdad absoluta y la falsedad total.

Según esta teoría, la función que la represente será una función de transferencia (que tomará cualquiera de los valores reales comprendidos en el intervalo [0,1]) la que determine el grado de pertenencia de un elemento a un conjunto.

Vamos a utilizar la siguiente imagen como explicación

• English

Vamos allá con la segunda y última entrega de nuestra mini serie sobre ROS. Tras el tutorial de instalación, hoy vamos a centrarnos en dotar a nuestro robot de una de las herramientas que a buen seguro más os llamaron la atención del vídeo presentación: la posibilidad de mostrar nuestro robot en una representación 3D en el ordenador, respondiendo en tiempo real a lo que ocurre en el mundo físico.

La herramienta que se encargará de esto se llama rviz, podéis ver la presentación de este proyecto en el siguiente vídeo:

¿Sorprendidos con sus posibilidades? ¡Vamos a instalarlo!

1. Instalación de rviz

Para instalarlo, tendremos que asegurarnos de satisfacer todas las dependencias necesarias, para ello usaremos el siguiente comando:


rosdep install rviz


Ahora generamos el visualizador:


rosmake rviz


Finalmente, podremos ejecutarlo con el siguiente comando:


rosrun rviz rviz


NOTA: Para poder ejecutar rviz, tendremos que tener en otra terminal un servidor funcionando para poder comunicarnos con el NXT.
En estas pruebas, estamos usando el mismo que utilizamos al final del artículo anterior (ROS- Robot controlado desde el PC).


roslaunch nxt_robot_sensor_car robot.launch


Si no tenéis un servidor funcionando al ejecutar rviz, obtendréis el siguiente mensaje

2. Configuración de rviz

Cuando lo ejecutemos, tendremos una serie de terminales funcionando, algo como esto

Nótese que en cada terminal se está ejecutando una herramienta distinta:

En muchas ocasiones la programación orientada a objetos (OOP) puede convertirse en una forma excesivamente compleja de resolver un problema, en especial si se trata de un problema simple. Pero el nivel de abstracción que ofrece esta metodología permite acometer problemas complejos de forma mucho más simple que la programación clásica. A pesar de que ya hemos hecho uso de este tipo de técnicas en los artículos anteriores, en el presente trataremos de centrarnos en las características que diferencian a estas técnicas.

En la actualidad los grandes problemas del mundo real se están descomponiendo, desde el punto de vista de programación, en objetos que encierran ciertas características y engloban no solamente a los datos sino también a las funciones relacionadas y que operan con ellos. Esto permite la modularidad, el encapsulado, polimorfismo y la herencia, que son las características principales de la programación orientada a objetos.

Diferencias y evolución de la programación estructurada a la OOP.

Llegados a este punto conviene definir más concretamente qué es un objeto y una clase, así como sus propiedades.

Una clase es una definición abstracta de un objeto. En esta definición se engloban tanto las características del objeto, sus propiedades y también las funciones para operar con ellos. Pero una clase no representa a un objeto concreto sino que no es nada más que una caracterización o definición: la implementación se materializa cuando creamos al objeto como perteneciente a una clase determinada. Este proceso de creación del objeto suele denominarse instanciación.

El enfoque anterior, basado en clases, es el más extendido en el mundo de la programación OO, y con ella trabajan lenguajes como Java o C++. Pero existe una alternativa a la propuesta basada en clases: es la basada en prototipos. Esta segunda propuesta crea los objetos mediante un proceso denominado de clonación sobre el prototipo, que no es otra cosa que un estereotipo que proporciona la base o estructura para la operación de copiado. Esta alternativa está menos extendida que la primera.

Describamos las propiedades generales de los objetos:

• Encapsulación. Esta es la propiedad que permite ocultar la información. En un mundo dominado por la información como el nuestro, podríamos preguntarnos para qué puede servir la posibilidad de ofuscar cierta información. El objetivo de esto no otro que el de presentar a un objeto a través de un interfaz que oculte los detalles que no son necesarios para operar con un objeto. En muchas ocasiones simplemente queremos realizar ciertas operaciones con objetos, y nos tiene sin cuidado cómo han sido implementados éstos internamente: el encapsulado es la propiedad que lo permite.
• Polimorfismo. Es la propiedad que permite asignar un diferente significado o aplicar un uso determinado dependiendo del contexto en el que se emplea:
  1) Aplicado a una variable, por ejemplo USUARIO, si permitimos que la variable usuario pueda tener varias formas, como que pueda ser de tipo entero, o de tipo string, entonces el programa debería elegir cuál de esas formas debería aplicar al ejecutar el código. De este modo, si empleamos un formulario que acepte como datos de entrada los provenientes de la variable USUARIO, estaríamos permitiendo la posibilidad de que el registro de entrada se realice bien con un nº de usuario, o bien con una secuencia de caracteres. El programa debería tener previsto qué hacer en cada caso.
  2) Si aplicamos el polimorfismo a un método nos encontrarnos con el concepto denominado overload (sobrecarga): Los métodos sobrecargados son aquellos qie mantienen el nombre dentro de la misma clase. Al sobrecargar un método modificamos su funcionalidad dependiendo del tipo de parámetros de entrada que éste recibe (lo cual viene especificado por su declaración): De hecho el criterio que determina si los métodos sobrecargados en Java pueden compilar es que las listas de parámetros de los métodos sobrecargados puedan determinar el método al que llamar. Así, podemos crear dos métodos con el mismo nombre: es importante por ello reseñar la diferencia en la declaración de los dos métodos empleados para ello, puesto que dependiendo de los parámetros recibidos y de dichas definiciones el compilador deberá seleccionar qué método emplear:

public int sum(int num1, int num2);
}
...
}

public string sum(string cad1, string cad2);
}
...
}


• La herencia es una característica que permite la reutilización del código y facilita la extensibilidad del software. Gracias a ella podemos crear nuevas clases partiendo de una jerarquía de clases ya existente, lo que evita tanto el rediseño, como tener que volver a verificar el código ya probado. Del mismo modo se facilita la creación de objetos a partir de otros ya existentes, obteniendo características (métodos y atributos) similares a los ya existentes. La herencia es la relación entre una clase general y otra clase más especifica: permite crear una clase derivada a partir de una primera clase, que se denomina superclase.

Relacionando el presente artículo con el LEGO MINDSTORMS, nos encontramos que si requerimos de un lenguaje orientado a objetos para programar el NXT podemos hacerlo básicamente con LeJOS, la versión Java para NXT. Por otro lado disponemos del Lua: aunque Lua no es un lenguaje orientado a objetos en sentido estricto, dispone de meta-mecanismos que permiten la implementación de clases y la herencia.

• English

El proyecto ROS (Robot Operating System) nace con la intención que dotar a los desarrolladores de software de librerías y herramientas específicas para crear aplicaciones de robótica. Una de sus principales ventajas es que nos permite abstraernos del hardware específico, dándonos además acceso a drivers para los diferentes dispositivos, librerías, visualizadores, gestión de mensajes y paquetes de datos y mucho más.

Esta potente herramienta de desarrollo de código libre (o abierto) ha llegado a nuestro NXT. La integración de ROS con el NXT se ha llevado a cabo en colaboración con el proyecto NXT-Python, y los resultados son impresionantes, como se puede apreciar en el siguiente vídeo.

Para todos aquellos que queráis dar un paso más con vuestro NXT, a continuación podréis encontrar una guía paso a paso sobre cómo instalarlo y hacerlo funcionar.

Aviso a navegantes, toda la instalación, configuración y pruebas de esta guía se han realizado en Ubuntu, en concreto en su versión 10.4 (Lucid Lynx).

1. Configuración del ordenador.

Añadimos el grupo

sudo groupadd lego


Añadimos el usuario al grupo creado

sudo usermod -a -G lego {username}


Creamos una reglas para poder usar el USB sin problemas


echo "BUS==\"usb\", ATTRS{idVendor}==\"0694\", GROUP=\"lego\", MODE=\"0660\"" > /tmp/70-lego.rules && sudo mv /tmp/70-lego.rules /etc/udev/rules.d/70-lego.rules


Reiniciamos udev


sudo restart udev


Finalmente cerramos la sesión de usuario y la volvemos a abrir.

Nota: Los que hayáis seguido previamente nuestro tutorial de instalación LeJOS en Linux, en principio, podéis omitir este paso porque ya está hecho.

2. Instalación de ROS.

2.1 Añadir repositorios

Tendremos que asegurarnos primero de que nuestro Ubuntu acepta repositorios “restricted”, “Universe” y “Multiverse”.

Una vez hecho esto, desde la terminal, añadimos los repositorios de ROS, dependiendo de vuestra versión de Ubuntu:

Ubuntu 9.04 (Jaunty)

sudo sh -c 'echo "deb http://code.ros.org/packages/ros/ubuntu jaunty main" > /etc/apt/sources.list.d/ros-latest.list'


Ubuntu 9.10 (Karmic)

sudo sh -c 'echo "deb http://code.ros.org/packages/ros/ubuntu karmic main" > /etc/apt/sources.list.d/ros-latest.list'


Ubuntu 10.04 (Lucid)

sudo sh -c 'echo "deb http://code.ros.org/packages/ros/ubuntu lucid main" > /etc/apt/sources.list.d/ros-latest.list'


Ubuntu 10.10 (Maverick)

sudo sh -c 'echo "deb http://code.ros.org/packages/ros/ubuntu maverick main" > /etc/apt/sources.list.d/ros-latest.list'


2.2 Configuración de las claves (Keys)


wget http://code.ros.org/packages/ros.key -O - | sudo apt-key add -


2.3 Instalación

Actualizamos el gestor de paquetes


sudo apt-get update


Instalamos el paquete ROS Base, que nos dará el conjunto completo de herramientas para robótica, que incluye software de navegación, visualización, …

NOTA: Tendremos que ser pacientes, pues el paquete que descargaremos es bastante grande (unos 2Gb)


sudo apt-get install ros-cturtle-base


2.4 Configuración de variables de entorno


echo "source /opt/ros/cturtle/setup.bash" >> ~/.bashrc
. ~/.bashrc


3. Instalación de NXT-ROS

Para instalar NXT-ROS necesitaremos descargar primero las siguientes herramientas:


sudo apt-get install python-setuptools
sudo easy_install -U rosinstall
sudo apt-get install mercurial


Ahora vamos a descargar y generar los enlaces de NXT-ROS


rosinstall ~/nxtros /opt/ros/cturtle "http://www.ros.org/wiki/nxt/Installation?action=AttachFile&do=get&target=nxt-0.1.0.rosinstall"
. ~/nxtros/setup.sh
rosmake nxt nxt_apps nxt_robots --rosdep-install


Cada vez que abramos una nueva terminal y tengamos que hacer uso del NXT-ROS, tendremos que introducir en la consola lo siguiente:


. ~/nxtros/setup.sh


4. Probando la instalación.

IMPORTANTE: Para que NXT-ROS funcione con nuestro Mindstorms, necesitaremos tener el firmware 1.28 o superior. Si no sabéis cómo actualizar, podéis seguir el siguiente tutorial: Actualizando el Firmware del NXT

Vamos a comprobar antes que nada si nuestro NXT se conecta correctamente, para eso, vamos a realizar una prueba muy sencilla:

Conectamos un sensor de contacto al puerto 1 de nuestro NXT

En una terminal, tecleamos


. ~/nxtros/setup.sh
rosmake nxt_python
roscore


En otra terminal distinta


. ~/nxtros/setup.sh
rosrun nxt_python touch_sensor_test.py


Deberíamos estar viendo el estado actual de nuestro sensor, como se puede apreciar en la siguiente captura

Si obtenéis el siguiente mensaje al ejecutar el test


Traceback (most recent call last):
File "/u/mwise/external_repos/foote-ros-pkg/nxt/trunk/nxt_python/sensor_tests/touch_sensor_test.py", line 21, in {module}
sock = nxt.locator.find_one_brick()
File "/u/mwise/external_repos/foote-ros-pkg/nxt/trunk/nxt_python/src/nxt/locator.py", line 57, in find_one_brick
raise BrickNotFoundError
nxt.locator.BrickNotFoundError


Significa que hay algún problema de conexión o configuración, por lo que deberéis comprobar que habéis seguido todos los pasos correctamente.

5. ¡Robot controlado desde el PC!.

Todo ha ido bien, ya tenemos ROS instalado en nuestro ordenador, vamos a realizar un pequeño experimento.

Para hacer una primera prueba, vamos a modificar uno de los archivos que nos hemos descargado, en concreto se trata del archivo “robot.yaml” que se encuentra en:

/home/NOMBRE_USUARIO/nxtros/nxt/nxt_robots/nxt_robot_sensor_car


Este archivo es el que nos indica qué tiene conectado el robot y a qué puerto/s. Para asegurarnos de no cargarnos nada, hacemos una copia de seguridad del archivo, y luego lo abrimos (por ejemplo con gedit).

Borramos su contenido y lo sustituimos por:


nxt_robot:
- type: motor
name: r_wheel_joint
port: PORT_A
desired_frequency: 16.0

- type: ultrasonic
frame_id: ultrasonic_link
name: ultrasonic_sensor
port: PORT_4
spread_angle: 0.2
min_range: 0.01
max_range: 2.5
desired_frequency: 5.0

Y guardamos el archivo. Lo que hemos hecho es simplificarlo para que tenga sólo 2 motores, en los puertos A y B, y 1 sensor ultrasónico en el puerto 4.

Ahora tenemos que volver a generar el ejecutable desde la terminal, para que tenga el cuenta las modificaciones.


rosmake nxt_robot_sensor_car


Una vez hecho esto, podemos ejecutarlo con el siguiente comando

roslaunch nxt_robot_sensor_car robot.launch


Dejamos esta terminal funcionando y abrimos una nueva terminal, es aquí donde haremos funcionar el programa controlador.

Para utilizar el teclado utilizaremos:

roslaunch nxt_teleop teleop_keyboard.launch


Si por el contrario tenemos un joystick en el ordenador (aunque no es muy común hoy en día) y queremos usarlo para controlar el NXT, usaremos


roslaunch nxt_teleop teleop_joy.launch


Y tendremos esto en las terminales

Os dejamos con un vídeo para que veáis cómo se comporta el NXT.

Segunda parte ya publicada. Exploramos la posibilidad de representación gráfica del NXT en la pantalla de nuestro ordenador, como se puede ver en el vídeo que abre el artículo.

ROS (Robot Operating System) & NXT (2/2)

Esperamos que os haya gustado, si tenéis alguna duda, podéis postearla en el foro.

Ya hablamos de las posibilidades de control de elementos Power Functions con NXT (Sensor IR Link). En esta ocasión queremos centrarnos en explorar la opción inversa, es decir, controlar el NXT desde un mando IR de PF. Esta opción es la más utilizada en los modelos híbridos que hemos visto en las competiciones. Por eso, hoy vamos a trabajar con el Sensor Receptor de IR (ref. MS1032)

Su principal ventaja es la facilidad de manejo de los mandos PF frente a otras soluciones, como pueden ser los móviles, ordenadores u otro NXT (joystick NXT). Por contra nos encontraremos con las limitaciones propias de cualquier modelo PF: alcance limitado, limitación de canales disponibles (para poder participar en una competición, por ejemplo), o dependencia de factores externos que pueden deteriorar la señal (luz solar).

Para poder hacer uso de este sensor en vuestro NXT-G necesitaréis descargaros el bloque correspondiente:

Sensor Receptor IR

Una vez lo hemos descargado vamos a explorar las posibilidades de este nuevo bloque:

El siguiente esquema muestra la relación de entradas/salidas.
Vamos a explicar para qué sirve cada una:

1. El puerto al que está conectado el Receptor IR.

2. Canal de IR en el que está el mando de PF.

3. Dirección de giro del motor rojo (salida de color rojo del mando).

4. Potencia del motor rojo (de 0 a 100).

5. Dirección de giro del motor azul (salida de color azul del mando).

6. Potencia del motor azul (de 0 a 100).

7. Freno de motor rojo.

8. Freno de motor azul.

9. Configuración del motor rojo (Información de velocidad que envía el mando, de -7 a +7).

10. Configuración del motor azul (Información de velocidad que envía el mando, de -7 a +7).

Ahora que ya sabemos qué es cada conector, veamos con qué información trabajan:

Vamos a hacer un par de experimentos para ver cómo funciona:

Antes de nada, tendréis que importar el nuevo bloque al software NXT-G, si tenéis alguna duda de cómo hacerlo, lo explicamos en el artículo sobre el Sensor de Color (ref. 9694)

1. Tribot básico

Este experimento, aunque muy simple, nos permitirá hacernos una idea rápida de las opciones de control más usadas. En este caso, vamos a asignar a cada motor una de las salidas del mando (roja o azul), de tal forma que podamos controlar los 2 motores de forma independiente.

El programa es muy sencillo

Llevamos un cable de datos de las salidas correspondientes a sentido de giro (dirección) y potencia hasta las entradas de los bloques de motor.

Vamos a complicarlo un poco más, añadiendo una funcionalidad de lo más útil: poder cambiar el canal IR al arrancar el programa, sin necesidad de reprogramar desde el ordenador.

2. Tribot con Selección de Canal IR

Como se puede ver, el programa es muy similar al anterior, sólo que ahora tenemos una variable llamada canal, que se encarga de almacenar el valor que introduce el usuario.

Para obtener este valor del usuario, usamos el bloque Elige canal, que podemos ver en detalle a continuación:

Lo primero es mostrar en pantalla el mensaje para el usuario e inicializar la variable canal a 1 (ya que nuestros canales van de 1 a 4).
Mientras que el usuario no pulse el botón “intro” (condición de salida del bucle) sumamos 1 cada vez que nos pulsen el “botón derecho”.
Antes de salir del bloque, mostramos en pantalla el canal elegido, este texto se mantendrá durante toda la ejecución del programa principal.

Os dejamos el vídeo

Esperamos que os guste.

Las pasadas navidades llegó a las tiendas el nuevo sistema de juego “Kinect” para Xbox 360 de Microsoft, revolucionando la forma de jugar/ interactuar con la consola. ¿En qué consiste? básicamente permite a la consola recibir información sobre los movimientos del usuario, de tal forma que dichos movimientos pueden pasar a formar parte del juego. Los desarrolladores, conscientes del enorme potencial del nuevo dispositivo, no tardaron mucho en crear herramientas que les permitieran exprimir las innumerables aplicaciones y posibilidades de una tecnología semejante.

La compañía PrimeSense, responsable del desarrollo del proyecto, fue fundada por antiguos ingenieros del ejército Israelí. De hecho, parte de la tecnología utilizada en Kinect se basa en prototipos militares de detección de enemigos en campo de batalla. Por lo tanto parece lógico que, aunque se nos presente como un accesorio más de la videoconsola, se puede usar para eso y para mucho, mucho más.

¿Cómo funciona?

El sistema Kinect combina un emisor de IR con una cámara VGA (640 x 480), proporcionando una imagen en la que cada píxel es una posición 3D independiente. De esta manera el sistema proporciona información sobre 307.200 puntos independientes en el espacio, consiguiendo un seguimiento prácticamente perfecto de los movimientos del usuario situado frente al dispositivo.

Cómo no podía ser de otra manera, los experimentos no han tardado en llegar al campo de la robótica, dando lugar a creaciones tan impresionantes como este cuadricóptero autónomo que utiliza el Kinect para detectar obstáculos.

Está desarrollado por la Universidad de Berkeley. Os dejamos con un vídeo para que veáis cómo funciona.

Vamos ahora al experimento que nos interesa, un NXT controlado con Kinect.

El modelo que utiliza de base es un tribot, por lo que la tracción es diferencial. El funcionamiento es sencillo, cada brazo controla un motor, moviendo los brazos hacia delante o hacia atrás desde una posición inicial o neutral, hacemos girar los motores en una dirección u otra, a diferente potencia.

Resulta bastante impresionante la exactitud de los datos capturados por los sensores, así como la rapidez con la que la señal se procesa y se envía al NXT, consiguiendo una respuesta prácticamente inmediata.

El creador de este original proyecto, rasomuro, nos da en su página la siguiente información.

Detalles técnicos:

Como bien sabéis, el pasado Domingo 27 de Marzo se celebró en electricBricks la primera competición de vehículos de combate. Para ir abriendo boca, ya publicamos en el blog algunos artículos al respecto, como el dedicado a nuestro tanque NXT o el de la torreta Lanzabolas. Además de las extensísimas charlas que tuvimos a propósito de tan original concurso en su correspondiente hilo del foro (Vehículos Combate – Foro). Sólo hay un adjetivo para describir el ambiente: divertido, ante todo muy divertido.

Veamos algunos números para hacernos una idea de la magnitud del evento:

En este post mostramos otro avance de la competición de tanques de LEGO radiocontrolados que tendrá lugar el Domingo 27 de Marzo en electricBricks. Para complicar un poco las cosas, los competidores no sólo tendrán que dispararse unos a otros, sino que tendrán que evitar los disparos del tanque electricBricks, mostrado en un post anterior, y además tendrán que esquivar los proyectiles de dos torretas de base fija situadas en el campo de batalla. Aunque puedan parecer inofensivas dada su falta de movilidad, el fuego rápido de estas armas puede ser decisivo en la batalla.

La torreta consta de tres movimientos, cada uno efectuado por un servomotor Mindstorms NXT. El sistema de disparo se efectúa gracias al lanzador de esferas zamor. Este lanzador tiene unas pestañas en las que cabe una bola (mejor dicho “esfera zamor”). Si introducimos un eje en el lanzador, éste empuja la bola contra las pestañas y las fuerza, hasta que supera cierto punto, en el que por la presión de las pestañas la bola sale disparada.

Podemos ver el sistema que empuja el eje en la siguiente fotografía. El motor hace girar un engranaje de 12 dientes conectado a uno de 36, con relación de 1:1/3, para aumentar la potencia. El segundo engranaje mueve una palanca, que con una biela empuja y tira del eje. Al empujar, la bola sale disparada, y al tirar, cae una bola nueva del cargador, que tiene capacidad para 7 esferas.

El movimiento vertical se realiza mediante un tornillo sin fin que hace girar un engranaje de 24 dientes, reducción suficiente para poder mover el peso del sistema disparador. La rotación del tornillo lo produce un motor situado debajo de la base.

El movimiento lateral se produce de forma muy similar al vertical: un tornillo sin fin hace girar la base giratoria. Podemos ver en la imagen también el motor que produce el giro vertical, cuyo eje atraviesa la base por el hueco del centro de la misma.

La torreta se controla desde una “posición segura”, donde se encuentra el procesador NXT. El movimiento vertical se realiza pulsando los sensores de contacto situados a la izquierda del procesador, mientras que el movimiento lateral se controla desde los botones izquierdo y derecho del procesador. El disparo se ejecuta al presionar el botón central del procesador.

El programa que controla el proceso es bastante sencillo, basado en una serie de bifurcaciones dentro de un bucle. Cada bifurcación comprueba si se pulsa un botón, si es así, realiza un movimiento de 20 grados, si no, pasa a la comprobación de otro botón, y así sucesivamente. De esta forma, si tenemos pulsado un botón, se acumulan movimientos cortos en la misma dirección. Si pulsamos dos botones a la vez, los movimientos se intercalan. A continuación podéis ver el programa.

Por último os mostramos un vídeo del funcionamiento de la torreta.

¡Venid preparados, porque no habrá misericordia para nadie!

Con la mirada puesta en la competición de tanques que se celebrará el Domingo 27 de Marzo en electricBricks, hemos querido mostrar el modelo NXT que participará como mediador en la competición. ¿Mediador? Bueno, digamos que será otro rival que participará de parte de electricBricks, que se encargará de hacerles las cosas difíciles al resto de participantes. Para ello está equipado con un lanzador de vigas de 1 x 3, con capacidad para 12 vigas por cargador.

Este modelo está completamente montado haciendo uso de la electrónica NXT y se maneja remotamente mediante bluetooth, por lo que no supondrá una limitación de canales IR para los modelos que usen Power Functions.

La base móvil monta 2 motores de Mindstorms, con una relación de engranajes que permite transmitir el movimiento desde la parte delantera del vehículo (donde están situados los motores) hacia las ruedas de la parte trasera. El sistema de giro es tipo tanque, sin eje direccional.

Os dejamos algunas fotos en detalle para que podáis estudiarlo… ¡o replicarlo!

Primero un par de fotos generales, para ir abriendo boca

Como se puede apreciar, la base es bastante simple, en la parte superior, tenemos el sistema de disparo y a modo de cresta o aleta dorsal tenemos el cargador.

Ahora algunas en detalle

Recientemente, en la BrickWorld de Copenhague (Dinamarca), se ha presentado el primer modelo de NXT Volador. Es un impresionante proyecto que ha sido desarrollado por el equipo de BrickIt.dk entre Octubre de 2010 y el pasado mes de Febrero de 2011.

Tiene unas 500 piezas, y ha requerido de unas 30 horas de montaje, 10 de programación más 10 horas adicionales (presumiblemente para pruebas y correcciones). Más que complejo, estamos ante un proyecto principalmente original.

¿Cómo funciona? Se trata de un modelo que utiliza 2 globos de hidrógeno que permiten que sea capaz de elevarse. También podría haberse realizado con helio, pero el hidrógeno tiene menor densidad. Para desplazarse dispone de 3 juegos de hélices del conjunto 9688. Teniendo en cuenta el tamaño de estas hélices, podemos hacernos una idea de las grandes dimensiones de este artilugio.

En la foto superior puede apreciarse el tamaño del ladrillo NXT en relación con las dimensiones totales del modelo. Se trata de un ladrillo de color negro y se encuentra en el centro de la parte inferior de la imagen, ¡por si alguno no lo había visto!

Utiliza además:

1 unidad controladora RC (parecer ser la ref. 6272c01, aunque no se aprecia en el vídeo)

Os dejamos con un vídeo con las imágenes de la BrickWorld, algunas de las cuales están grabadas desde el aire con la cámara que equipa el propio modelo.

Sí sí, pero… ¿cómo han conseguido que se levante del suelo?

Principio físico

De acuerdo al principio de Arquímedes, todo cuerpo sumergido en un fluido recibe una fuerza de abajo hacia arriba equivalente al peso del fluido desplazado. Resulta obvio que el dirigible, un cuerpo inmerso en la mezcla de gases llamada aire, recibirá una fuerza ascensional resultante (P) equivalente al peso de aire ocupado por su volumen (V), menos el peso de su estructura y su carga (Q);

Siendo γ el peso específico del gas utilizado para llenar los depósitos del dirigible, y Γ el del aire, entonces:

Comportamiento de un sólido de densidad ds en un líquido de densidad dL

Ahora … ¿Cómo podemos saber cuál será el tamaño de los globos necesario para que nuestro globo sea capaz de elevarse?

Tenemos para nuestro ejemplo un peso del montaje de 1 Kg (es una estimación, teniendo en cuenta que sólo la electrónica pesa aproximadamente 700 g).

Recordemos que tenemos: Q (Masa del objeto) y P (empuje hacia arriba o fuerza ascensional). Además de saber que:
Densidad del aire: 1,18g/l
Densidad del hidrógeno : 0,071g/l

Para que el cuerpo suba se requiere que:

P > Q

Calculemos el peso y luego el empuje (llamamos V al volumen del cuerpo que, vacío, tiene masa despreciable, pero que llenamos de hidrógeno, además de adosarle una masa de 1 kg) :

Q = 0,071 V 9,8 + 1 • 9,8

P = peso del aire desalojado (principio de Arquímedes) = 1,18 V 9,8

Como tendrá que ser que E > P,

1,18 V 9,8 > 0,071 V 9,8 + 1 • 9,8

Dividiendo todo por 9,8 :

1,18 V > 0,071 V + 1 – > 1,18 V – 0,071 V > 1 -> 1,12 V > 1 -> V > 0.90 m³

Se necesitan como mínimo 900 litros de hidrógeno para elevar 1 Kg.

Ahora hay que calcular el diámetro del globo, para ello usaremos la fórmula del volumen:

De donde sacamos que r= 0,59m o 59 cm

Vamos a ver si esto se cumple en este caso concreto:

Tenemos para nuestro ejemplo:

La pasada competición de vehículos LEGO de Trial (Domingo día 27 de Febrero) fue un auténtico éxito, tanto por la enorme participación como por el nivel de los asistentes. En esta ocasión realizamos la prueba en exteriores, en un emplazamiento lleno de baches, grietas y cuestas que hicieron las delicias de los más valientes, al tiempo que algunos veían como sus vehículos sufrían irremediablemente con la dureza de las pruebas. Gracias a todos los participantes, tanto los que compitieron como los que fueron a compartir la experiencia. Hizo un frío de justicia, pero ¡qué bien lo pasamos!

Esta competición estuvo compuesta de 3 tramos, o etapas, principales más un cuarto tramo de desempate.

En esta ocasión la galería de fotos inicial recoge aproximadamente al 75% de los participantes, ya que algunos no pudieron llegar a tiempo y se incorporaron con la carrera ya empezada. Aún así, vamos con ellos.

CicutaTrial

El único vehículo que arriesgó con el Mindstorms NXT, eso sí, con un híbrido equipado con sensor receptor de infrarrojos y mando de PF.

Quad’s JIP

Un modelo pequeño, con tracción trasera, que se vio en dificultades con obstáculos de gran tamaño, pero que consiguió resolver otros con mucha soltura.

El Minero

Dos grandes diferencias con el resto de montajes, una torsión en la zona central que le hacía superar obstáculos con facilidad pasmosa, y ¡falta de eje direccional! Compensado, por supuesto, con un sistema de giro tipo tanque.

Julio

Con un diseño muy similar al 8297, este modelo sorprendió por su sistema de dirección en los 2 ejes. Tuvo algún que otro problema mecánico, pero supo resolver correctamente todos los tramos.

Lagarto

Sin lugar a dudas un vehículo singular, eje delantero para tracción, tracción integral (en los 4 ejes), 2 baterías de litio, 4 motores XL, uno por cada eje. Y un diseño muy llamativo, para que negarlo.

Machacanator

Un modelo en el que primaba con mucho la potencia frente a la velocidad, no tuvo pilas suficientes para superar la primera prueba.

La Bestia

Con un enorme parecido a un camión de trial real, montaba 2 motores XL para la tracción y 1 mediano para la dirección. Una rotura del eje trasero lo dejaba fuera de juego en la primera prueba.

DaniRacer

Un vehículo compacto y peculiar, al que su escasa altura le dio algunos quebraderos de cabeza. Sin embargo, apenas tuvo penalizaciones por toque, lo que demuestra su eficacia.

Lagartija

El segundo vehículo de Sheepo, un modelo muy similar al ganador dela edición anterior. Tracción integral, unas ruedas con buen agarre y una buena altura con respecto al suelo han demostrado ser las bazas para ganar.

También compitieron, aunque no llegaron a la sesión de fotos: Biónico, Miguel, Óscar y El Innombrable.

Tabla de clasificación

En esta competición no se establece límite de tiempo, por lo que el piloto recibirá la puntuación máxima (10 puntos) por cada tramo completado sin tocar el vehículo y será penalizado (- 2 puntos) cada vez que lo toque. La mínima puntuación que se puede obtener en cada prueba es 1.

Importante: La competición se hizo a 3 tramos, y se produjo un triple empate. Los tres vehículos empatados (Lagarto, Lagartija y Miguel) se vieron las caras en un cuarto tramo de desempate.

Ahora los vídeos, os recordamos que para facilitar su visualización se ha multiplicado su velocidad por 3.

Andy Milluzzi, junto con John Hansen, ha creado el primer bloque de NXT-G que permite utilizar la comunicación RS485 de nuestro NXT. Esto nos permite comunicar 2 ladrillos NXT directamente a través del puerto 4 haciendo uso de un cable entándar, con velocidades de hasta 921600 bps. Esta es una velocidad muy superior a la proporcionada por el bluetooth, además de evitar los problemas derivados del uso de los buzones.

A pesar de que se trata de una primera versión, ya es posible descargar el bloque desde el siguiente enlace:

Bloque RS485 NXT-G

Este bloque nos permite enviar y recibir cadenas de caracteres (strings). Por el momento no admite la transferencia de números ni de señales lógicas, pero haciendo uso del bloque Número a Texto, podemos convertir los datos numéricos en strings, con lo cual tendríamos parte del problema resuelto.

Para probar estos nuevos bloques hemos conectado dos ladrillos LEGO MINDSTORMS NXT entre sí mediante un cable NXT convencional conectado entre los puertos 4 de cada uno de ellos. Tras las pruebas que hemos realizado, con un sencillo bucle que muestra en pantalla en número de mensajes enviados y recibidos, con unas cifras en torno a los 85 mensajes por segundo. Puede parecer un número relativamente bajo, pero debemos de tener en cuenta que en esta rutina también se están presentando datos en pantalla.

En el caso del programa emisor, enviamos como información el número de iteraciones del bucle, mientras que el programa receptor muestra en pantalla la información recibida.

El autor promete ir actualizando con nuevas funcionalidades, por lo que la idea promete y abre posibilidades para otro tipo de aplicaciones.

RS-485
El RS485 es un protocolo de comunicaciones serie de gran aceptación en la industria. Se emplea habitualmente en aplicaciones de control y adquisición de datos. Las características principales de este estándar son las siguientes:

Asteroids es un clásico de los arcades para recreativas de los años 80. Su planteamiento es muy sencillo, el jugador controla una nave que puede moverse libremente en un campo de asteroides, disparando hasta destruirlos para conseguir puntos. Además debe evitar chocar contra ellos. Hoy hemos querido traeros nuestra particular versión de este juego programada por completo en NXT-G.

El juego fue concebido por Lyle Rains, programado y diseñado por Ed Logg. Para su implementación se utilizó el hardware desarrollado por Howard Delman (la pantalla vectorial o generadora de vectores). Para jugar, se hacía uso de un joystick y un botón de disparo.
Su lanzamiento supuso un tremendo éxito en los Estados Unidos, tanto que se convirtió en el juego más vendido en toda la historia de Atari.

Como curiosidad sobre este juego, el record establecido en 1982 por Scott Safran de 15 años, tardaría 27 años en superarse. En concreto, hubo que esperar hasta el 3 de abril de 2010. El jugador en cuestión fue John McAllister, que inició una partida de 3 días de duración tras la cual lograría batir dicho record (41,336,440 puntos) con una puntuación de 41.338.740, es decir, un 0′006% por encima de la anterior puntuación.
El sistema que utilizó consistía en conseguir suficientes vidas extras y, en ese momento, aprovechar para comer un bocadillo o algo rápido mientras vigilaba no perder ninguna de esas vidas. De hecho, una anécdota al respecto fue que una vez le falló el cálculo y cuando volvió del cuarto de baño sólo le quedaban 2 vidas, pudiendo continuar con la partida por poco.

Este es el aspecto del juego en la versión de 1982

Nuestra versión está algo simplificada, aunque no descartamos ampliarla en un futuro. En este caso nuestro objetivo será esquivar los asteroides, obteniendo 10 puntos por cada uno que evitemos. Si el asteroide impacta contra nosotros perderemos 1 vida, hasta quedarnos sin las 3 disponibles, lo que supondrá el final de la partida.

Este es el programa completo

Como se puede comprobar, y es habitual en los programas largos, lo hemos dividido en diferentes bloques personalizados.

Bloque Var_Ini

Inicializa las variables principales del juego, que se usan en el resto de los bloques.

Bloque End

Muestra el final del juego y espera que presionemos el botón Intro.

Podéis descargaros el código desde este enlace:

Juego Asteroids NXT-G

Se trata de un fichero zip que contiene un archivo con extensión .rbtx, creado con la herramienta “Pack and Go” incluida en el propio software NXT-G. Esta herramienta nos permite crear un paquete que contiene toda la información necesaria para abrir ese programa desde cualquier otro ordenador: los bloques personalizados, las imágenes y los sonidos.

Para los que no sepáis cómo hacerlo, os dejo esta captura de pantalla

En breve colgaremos un vídeo para que lo veáis funcionando.

Esperamos que os haya gustado, si alguien se anima a continuarlo y mejorarlo, estaremos encantados de comentarlo en el foro.

Información adicional:

Telesketch o Sketch es un juguete inventado en durante los años 50 por el francés Arthur Granjean, fue presentado en la Exhibición Internacional de Juguetes de Nuremburg, Alemania en 1959. Tardaría solamente un año en ser comercializado en Estados Unidos con el nombre de Etch-A-Sketch por Ohio Art Company y en España por Borrás. Granjean lo llamó originalmente “la Pantalla Mágica”.

Se trata de un juguete relativamente plano y rectangular, con la apariencia de una pequeña pantalla de televisión. Tuvo una gran acogida en los años 80, por lo revolucionario de su idea, y aún hoy sigue haciendo disfrutar a niños de todas las edades, a pesar de haber sido objeto de numerosas modificaciones y evoluciones.

El Telesketch es una versión muy simplificada de un plotter. Veamos cómo está montado y cómo funciona.

El Teleskecth desmontado sin la pantalla

Se pueden apreciar los mandos giratorios que servirán para mover la punta metálica para arriba, para abajo y hacia los lados.

Detalle del interior

El interior está relleno de polvo de aluminio y partículas de estireno, que al adherirse a la parte posterior de la pantalla, formarán el lienzo sobre el que dibujar. Para borrar el dibujo sólo hay que ponerlo boca abajo y agitarlo para que el aluminio y el estireno vuelvan a recubrir la superficie.

Detalle de la punta

La punta metálica está montada sobre un par de raíles ortogonales. Dicha punta araña la superficie cubierta de polvo de aluminio generando el dibujo.

Crear una línea recta en diagonal o con una curva suave con un Telesketch es notablemente difícil y una verdadera prueba de coordinación. Una solución es alternar cuidadosamente líneas verticales y horizontales con incrementos muy pequeños, una técnica que guarda semejanza con las líneas pixeladas generadas en las pantallas de los ordenadores.

En esta era de grandes tecnologías, juguetes como este siguen siendo un clásico y su impacto es tan grande que hoy en día hay artistas que lo utilizan como base de su trabajo, como es el caso del retratista George Vlosich.

O que quieren homenajear su diseño en los gadgets más punteros, como esta funda para el iPad:

Como curiosidad, ahora os dejamos uno de los primeros encuentros entre un Mindstorms NXT y un Telesketch.

En este caso, se trata de un NXT controlando un TeleSketch:

Como podéis ver en la imagen siguiente, el montaje de nuestro Telesketch es bastante sencillo: dos motores a los lados de la pantalla, dos ruedas dentadas, algunas piezas para conectarlo todo y nada más.

Código de NXT-G

En la imagen siguiente mostramos un ejemplo de programa explicado:

Código en RobotC


#pragma config(Motor, motorA, MotorX, tmotorNormal, PIDControl, reversed)
#pragma config(Motor, motorC, MotorY, tmotorNormal, PIDControl, )
//*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//

while(nNxtButtonPressed!=2){
X=nMotorEncoder[MotorX]/10;
Y=nMotorEncoder[MotorY]/10;
if(X<1){
X=1;
}
else if(X>99){
X = 99;
}
if(Y<1){
Y = 1;
}
else if(Y>63){
Y = 63;
}
nxtSetPixel(X,Y);
}
}
}


El pasado Sábado tuvo lugar la primera competición de sumo de este año 2011, tras el tremendo éxito de ediciones anteriores (Sumo Julio 2009, Sumo Enero 2010), en esta ocasión esperábamos una participación de un grandísimo nivel, con un buen número de luchadores, y no nos han defraudado. Algunos luchadores habituales y muchos nuevos, nos han dado una batalla campal de 2 horas increíblemente divertidas, que queremos compartir con todos vosotros.

Vamos a presentar a los luchadores según el orden de presentación en la sesión de fotos. Aunque hay un par de modelos que llegaron un poco más tarde y no pudieron hacerse las fotos oficiales, sí que los podremos ver en los vídeos de los diferentes combates.

Machacanator

Un modelo potente y ágil, que tuvo que retirarse por falta de alimentación eléctrica, es decir, que se quedó sin pilas. Un diseño completo con PF, 4 motores XL, 2 cajas de baterías y 2 receptores.

Castor

Modelo con Power Functions, 4 baterías, 4 receptores, una buena dotación de motores y muy bien protegido. El ganador indiscutible, muy potente y pesado era, sin embargo, muy maniobrable. El rival que más le aguantó en el ring no llegó a los 15 segundos.

NeXT

Este modelo, que confiaba toda la resistencia frente a los ataques a sus potentes defensas, no contaba sin embargo con ningún tipo de armamento. Controlado por bluetooth desde un portátil, era un luchador con uso exclusivo de Mindstorms NXT.

Wall-E

Modelo híbrido, cuyo parecido con el entrañable robot de Pixar resultaba engañoso, pues demostró ser un rival bastante duro. Era capaz de perder completamente la tracción de ruedas sin por ello tener que abandonar el combate. Base de NXT controlado por PF con el sensor de IR correspondiente.

Cicuta

Otro modelo híbrido, con el mismo sistema de su compañero Wall-E. Increíbles defensas laterales, aunque un armamento escaso, plantó cara a los rivales más duros con honor. Se echó en falta un poco más de tracción.

Julio

Este prometedor luchador de PF no pudo llegar a competir por problemas de tracción.

TumaCo

Amenazantes fauces dentadas, modelo pequeño y extremadamente ligero. Completo con PF.

Doid Bot

ALV1

Makitos

DaniRacer

Yago (sin foto)
ScareCrow (sin foto)

Tabla Clasificatoria Final

Debido a la gran cantidad de vídeos, no podemos colgarlos todos, pero hemos montado un pequeño resumen (¡preparad las palomitas, que son 5 minutos!) de los mejores momentos.

Esperamos que lo pasarais tan bien como nosotros, agradecer desde aquí a todos los participantes y a todos los asistentes, su participación y el buen rato que pasamos.

Ya hicimos un primer proyecto de vehículo propulsado por hélices, que bautizamos como NXT AirScooter. Hoy queremos enseñaros una nueva versión, reconstruida y mejorada, que cuenta con control remoto desde otro NXT por bluetooth.

En este caso hemos utilizado las nuevas palas que vienen en el conjunto Energías Renovables (review 9688), que también utilizamos en el experimento sobre energía eólica.

Desde el punto de vista mecánico, este nuevo sistema es más fiable y seguro, ya que las nuevas palas pueden anclarse directamente con pines a una estructura de viga o ladrillo técnico, mientras que, en la versión anterior se trataba de una gran plancha sujeta por sus studs. Esto simplifica el anclaje y reduce su tamaño.

Es importante también, por otra parte, tratar de evitar cualquier tipo de pérdidas energéticas, que al final se pueden traducir en una reducción de la velocidad del vehículo. En este sentido ha sido particularmente importante evitar cualquier tipo de vibración en los brazos que soportan las hélices: estas vibraciones son también pérdidas energéticas y su existencia propició que versiones anteriores del vehículo no fueran operativas. El AirScooter se limitaba a no avanzar, eso sí, vibrando como un poseso.

También se han reducido las vibraciones en el eje de la hélice aprovechando el doble ataque con los dos engranajes, desde cada uno de los extremos del servomotor del Mindstorms NXT.

El sistema de dirección empleado también es determinante para el avance del vehículo. En nuestro caso hemos probado varios sistemas, como una rueda loca y dos fijas o tres ruedas locas, que es el que permite la máxima maniobrabilidad, aunque impide un control preciso de la dirección. Podeis ver en detalle la forma en la que la hemos implementado.

Veamos el programa del mando.

Este programa recibe información de los 4 sensores de contacto, enviando por bluetooth un número diferente cuando están en reposo, no pulsados, y cuando están activos, pulsados.
Los sensores 1 y 3 controlan los movimientos del motor derecho .
Los sensores 2 y 4 controlarán el motor izquierdo.
Cuando un determinado sensor está pulsado, el motor correspondiente gira en un sentido, si se pulsa su complementario se invertirá el sentido de giro. Si no se pulsa ninguno se envía “0″ para indicar el reposo.

Y ahora el programa del vehículo

En este caso, debemos gestionar la señal numérica recibida, de tal manera que:

Tras la entrada anterior, en la que os comentábamos la existencia de este nuevo software de programación que une Scratch y LeJOS, hemos querido poner a prueba sus posibilidades como herramienta de desarrollo gráfica.

Lo primero que debemos tener en cuenta es que trabaja sobre la base de LeJOS, por lo que tendremos que tener instalado y correctamente configurado LeJOS en nuestro ordenador, si aún no lo habéis hecho o tenéis alguna duda, podéis consultar nuestros tutoriales:

- LejOS en Windows
- LeJOS en Linux
- LeJOS en MAC OS X

Además, no nos podemos olvidar de ¡cambiar el firmware de nuestro NXT!

Una vez realizados estos pasos previos ya estamos preparados para empezar.
La carpeta que nos hemos descargado (Enchanting) contiene los ejecutables correspondientes a las tres plataformas que hemos mencionado antes. No es necesario instalar, bastará con abrir el ejecutable que nos interese.
En nuestro caso, hemos realizado esta prueba desde Windows, y el ejecutable se llama “Enchanting.exe”.

Para aquellos que quieran familiarizarse primero con Scratch, podéis leer nuestra serie de artículos de Scratch.

Ahora, vamos a ponernos manos a la obra con nuestro proyecto, vamos a programar un sigue líneas con Enchanting.

Lo primero que debemos hacer es configurar los motores

Tenemos la opción de controlar motores de corriente directa, como los Power Functions, o motores con un encoder, como los de NXT. Sólo tendremos que arrastrar el tipo de motor que nos interese a la pestaña que representa el puerto al que está conectado. Una vez hecho esto, tendremos que posibilidad de elegir las acciones que ejecutarán esos motores.

Ahora vamos con los sensores

Igual que con los motores, bastará con arrastrar el sensor que nos interese al puerto.

Para hacer nuestro sigue líneas vamos a hacer uso del algoritmo más simple, que se basa en 2 sencillos pasos:

1) Si estamos dentro de la línea, nos moveremos hasta encontrar el final.
2) Si estamos fuera de la línea, nos movemos hasta encontrarla.
Finalmente, tendremos que repetir estos dos pasos en un bucle infinito.

Lo primero que hacemos, desde la pestaña de “Control” es añadir un arranque al programa, y un bucle infinito. Dentro de ese bucle debemos incluir una comprobación del estado del robot con respecto a la línea. Para ello usamos la estructura “Si … si no…” que dependerá del resultado de evaluar el valor de luz reflejada con respecto al valor umbral.
Realizar esta evaluación es sencillo, basta con utilizar un operador de “>” o “<” que tenga como entrada, por un lado la recibida por el sensor de luz, y por otro el valor que tomamos como umbral.

Ahora tenemos que añadir los motores. En esta primera versión haremos que los motores alternen su funcionamiento, de tal forma que en cada condición de nuestra bifurcación sólo funcione uno de ellos, por lo que tendremos que asegurarnos de parar el otro.

Al completar el proceso, tendremos algo como esto:

En la parte superior derecha tenemos los botones de control que ya conocemos de Scratch:

- El círculo rojo, que nos permite interrumpir la ejecución, no está implementado aún, por lo que tendremos que parar el programa de forma manual.
- La bandera verde (marcada con un círculo Rojo en la imagen superior), que comienza la ejecución. En este caso llamará a LeJOS para que se encargue del proceso, mostrándonos lo siguiente:

Y un nuevo icono que se ha añadido a Enchanting que tiene como función indicarnos que la parte gráfica: Scratch y la parte código: LeJOS se están comunicando correctamente. Este icono es un pequeño ladrillo NXT (marcado con un círculo Azul en la imagen del programa).

Como se puede ver, este nuevo software, aún en una fase muy temprana de su desarrollo, nos permite utilizar la simplicidad de la interfaz de Scratch, combinada con la potencia del lenguaje LeJOS de una forma sencilla y bastante completa. Esperamos que os haya gustado el experimento.

Ya hemos hablado en varias ocasiones de Scratch y sus posibilidades como lenguaje de programación polivalente para los más pequeños, en concreto con el sistema de construcción WeDo. En esta ocasión queremos hablaros de un software basado en Scratch, y denominado Enchanting, con una peculiaridad que lo hace de lo más atractivo: ¡la posibilidad de controlar nuestro NXT!

Ya sabemos que existe un software gráfico para NXT, el NXT-G, pero también conocemos sus limitaciones. En este caso, Enchanting nos permitirá hacer uso de una interfaz gráfica sobre el lenguaje de programación LeJOS.

En este imagen podemos ver las nuevas opciones de motores para el NXT.

Os dejamos con un vídeo de presentación de este nuevo software de programación (en inglés).

En estos momentos se encuentra en la versión 0.0.4, y es compatible con Windows, Linux y Mac OS X. Otra buena noticia para los usuarios de Linux, que no podía utilizar NXT-G en sus equipos de forma nativa y tenían que recurrir a máquinas virtuales o programas como Wine para poder hacer funcionar programas de Windows.

Podéis descargarlo desde aquí:

- Descarga Enchanting 0.0.4 (todos los SO)

Para poder utilizarlo, necesitaremos tener previamente instalado y configurado LeJOS en nuestro ordenador, por lo que, si aún no lo tenéis, podéis echar un vistazo a estos tutoriales:

- LejOS en Windows
- LeJOS en Linux
- LeJOS en MAC OS X

En la página del programa se agradece al equipo del MIT que desarrolló el software Scratch y distribuye su código para que los usuarios puedan hacer sus modificaciones. Hemos querido incluir aquí ese agradecimiento, ya que gracias a este tipo de iniciativas podemos hacer llegar la tecnología a todas las edades.

Fuente:
- Página web oficial del Proyecto Enchanting

Hoy vamos a centrarnos en otra posible expansión de las posibilidades de nuestro NXT. Uno de los objetivos principales de LEGO es que podamos combinar diferentes colecciones o técnica, aparentemente dispares, entre si. Como puede ser la unión de ladrillo clásico y NXT (exposición de MOCs con NXT). O poder trabajar con la antigua electrónica de 9V o con Power Functions desde nuestro Mindstorms. Es en este último caso en el que nos queremos centrar, y por eso vamos a realizar un experimento con el cable convertidor NXT (x1676 o 8528). Este cable nos permitirá controlar electrónica de 9V antigua o electrónica PF.

La utilidad principal de este cable es que podemos mover varios motores con un sólo puerto, aunque tendremos que tener en cuenta que estás apilados (conectados todos a una misma señal de salida) por lo que se moverán todos en las mismas condiciones.

Lo primero que deberemos tener en cuenta es que el cable convertidor da salida directa a electrónica 9V antigua, utiliza una clavija negra de 2 x 2 con las pletinas de conexión en los studs/ laterales de la pieza.

Este tipo de clavija no se utiliza sólo para los motores, si no también para las luces, como nuestro famoso semáforo NXT.

Para poder controlar la electrónica de PF, más moderna, necesitaremos un cable de extensión PF (8886 – 20cm- o 8871 -50cm-)

Vamos a explorar un poco más esta posibilidad de control de motores PF. Conociendo la limitación de puertos de motor de un NXT (tiene 3), supongamos un ejemplo de robot tipo rover que requiere de tracción integral, dirección y al menos 1 manipulador. Si utilizamos un motor XL para cada eje de tracción (se trata de un vehículo de dimensiones considerables, por lo que necesitaremos más de un motor), otro motor para la dirección y un cuarto para el manipulador, ya hemos superado la limitación de 3 puertos.

Con ayuda del cable convertidor y el cable de extensión PF podemos hacer que 2 de los motores reciban la salida de un mismo puerto (y por lo tanto funcionarán a la vez), con esto tendríamos tracción total con 2 motores pero consumiendo un solo puerto.

Lo que nos deja 2 puertos más disponibles para funciones adicionales, como la dirección o nuestro manipulador.

Para poder programar estos motores PF necesitaremos hacer uso de la librería Legacy Block, se trata de una librería oficial que nos permitirá controlar electrónica de 9V, ya sean motores o lámparas.

Descarga Legacy block

Una vez descomprimido el archivo (es un .zip) necesitaremos importar a NXT-G un bloque, en concreto se trata del bloque Old Motor

Una vez importado, vamos a ver un breve ejemplo de funcionamiento.

Para ello hemos hecho un montaje con dos servos, conectados a A y C y un cable convertidor (en B) que da salida a 3 motores PF.

Este es el programa que lo controla

Se trata simplemente se una sucesión de órdenes de movimiento a los distintos motores.

Aquí tenéis un vídeo de muestra

Un último apunte a tener en cuenta es que, si bien a priori podemos apilar tantos motores como nos parezca, debemos tener en cuenta el mayor consumo de batería que esto supone. En el vídeo podemos ver 3 motores, un PF mediano (ref. ) y dos motores e-motor de la caja de energías renovables (review 9688).
Como se puede observar, el sistema funciona perfectamente, sin que aparentemente haya problemas de capacidad, sin embargo esto se debe a que los motores giran sin carga. Si los motores se conectan a algún mecanismo, nos encontraríamos seguro con problemas de alimentación.

Esperamos que os haya gustado y os anime a seguir creando.

Hoy queremos mostraros un sensor que puede ampliar hasta límites insospechados las posibilidades de nuestro LEGO Mindstorms. Se trata del sensor de enlace IR (MS 1046). Este sensor nos permitirá controlar cualquier elemento Power Functions de forma remota (mediante infrarrojos).

La combinación NXT+ Power Functions multiplica las posibilidades de ambos mundos, tradicionalmente independientes. La comunicación por infrarrojos permite dos nuevas interesantes combinaciones:

Bloque PF IR Link (Descarga)

Este icono nos permitirá controlar los motores PF de la misma manera que el mando tradicional (8885): podemos girar en un sentido, en el contrario, o detener el motor. Tendremos, como si del mando se tratara, 4 canales. Además podremos controlar de forma independiente las 2 salidas de nuestro receptor IR.

Bloque PFE IR Link (Descarga)

Este bloque hace que nuestro Mindstorms se asemeje más al nuevo mando (8879) pudiendo no sólo elegir el canal y la salida en el receptor, sino que también permite controlar completamente nuestros motores: dirección, velocidad y la posibilidad de frenar los motores o realizar flotación (encadenando movimientos, tal y como pasa con los servos de NXT).

Como comentábamos más arriba, este sensor se comporta como un control remoto con cualquier dispositivo que integre recepción por infrarrojos, como un vehículo, o un tren, por ejemplo.

Vamos a ver un ejemplo de su uso para controlar un motor PF.

Este sería el programa:

En este caso usamos los botones de Derecha e Izquierda del ladrillo para hacer girar el motor en un sentido o en otro. Si no pulsamos ningún botón, paramos el motor.

Esta última condición debería poder obviarse, pero si no la incluimos, el sensor conserva la última información que hemos mandado, por lo que al volver a apuntar al receptor (o al iniciar el programa) el motor no se mantiene en espera, si no que empieza a girar, sin que tengamos control sobre él.

Os dejamos un vídeo del funcionamiento de este experimento.

Un segundo experimento, más complejo, nos permitirá controlar un tren de forma progresiva haciendo uso del bloque PFE. De esta manera, podemos imitar el comportamiento del mando 8879. Con la salvedad de que el movimiento no se mantiene si interrumpimos la señal.

El programa es el siguiente

Utilizamos los botones Derecho e Izquierdo no para indicar la dirección si no para fijar la velocidad a la que giraremos (de -7 a 7). Además usamos el botón central o Intro para realizar una parada inmediata.
Nótese que hemos querido preservar el carácter cíclico de la velocidad, de tal manera que si estamos en 7 y tratamos de subir una velocidad más, nos llevará a 0. Igual pasa si estamos en -7.

Vídeo del funcionamiento

Comentar que hay un tercer bloque para NXT-G, diseñado expresamente para los trenes y denominado

Nuevamente LEGO sorprende a todos los fans de Mindstorms NXT con una actualización de su aplicación de control remoto para dispositivos móviles. En este caso se trata de una aplicación para dispositivos con Android como SO, nos permitirá hacer uso del acelerómetro del dispositivo, así como utilizar un botón específico para el motor de acción.

En la página oficial además nos regalan una divertida frase dedicada a todos los aficionados a la ciencia ficción: “Do Androids Dream of LEGO MINDSTORMS?”, que es un evidente y muy acertado guiño a Do Androids Dream of Electric Sheep?, una novela corta escrita por Phillip K. Dick en 1968 y que sirvió de base para la genial película Blade Runner, dirigida por Ridley Scott en el 1982.

Además de hablarnos un poco sobre las posibilidades de este nuevo control remoto, podremos también descargarnos al código fuente de la aplicación, para estudiarlo o modificarlo a nuestro antojo.

Queremos resaltar un par de detalles:

Seguimos automatizando nuestros dioramas de trenes, en este caso, vamos a realizar una segunda versión de paso a nivel autónomo con Mindstorms NXT programado en NXT-G. Para más referencias os recomendamos al artículo sobre automatización con Scratch+WeDo.

En esta ocasión hemos querido reproducir de la forma más fiel posible un paso a nivel inglés, con su característico semáforo de 3 luces.
El funcionamiento de estos semáforos es muy simple, las luces están apagadas mientras la barrera está levantada, cuando se acerca un tren se enciende una luz ámbar fija (vértice inferior) que da paso, en unos segundos a 2 luces rojas intermitentes (vértices superiores), en ese momento se baja también la barrera. Dicho funcionamiento se puede apreciar muy claramente en el siguiente vídeo.

Encontraremos 2 tipos:

Hoy hemos querido utilizar uno de los sensores que menos aparece normalmente en los artículos, pero no por ello es menos importante: el sensor de sonido. Este sensor es capaz de medir intensidad sonora, ya sea valor directo (0-1024) o valor escalado (0-100). Esto nos puede permitir, por ejemplo, programar nuestros robots para avanzar cuando demos una palmada (valor de sonido más alto que el umbral) o tener un robot bailarín que se queje cuando bajamos la música (valor de sonido por debajo del valor umbral). En este caso utilizaremos el sensor para que nuestro NXT muestre en pantalla código morse en función del mensaje que estemos recibiendo.

Este experimento utiliza como base de comunicación el código morse. Este código permite representar todos los números y letras del alfabeto como secuencias de puntos y rayas.

Esta imagen es una representación del primer alfabeto morse internacional, en este primer alfabeto no existían signos de puntuación ni letras que no aparecieran en el alfabeto inglés (como la CH o la Ñ), que sí aparecerían más adelante, junto con signos de puntuación como: ?, . , ”

Como se explica en la parte superior:

1. Una raya equivale a 3 puntos.
2. El espacio entre las partes de una misma letra es de 1 punto.
3. El espacio entre dos letras es de 3 puntos.
4. El espacio entre palabras es de 5 puntos.

Es decir, para hacer posible la comunicación se establece como unidad de medida la duración (en tiempo) de un punto, por lo que una raya equivale en duración a haber mandado 3 puntos, etc…

Aquí tenéis la tabla actual, extraída de Wikipedia, en este caso, se puede observar la inclusión de símbolos nuevos, tal y como comentábamos antes:

Convenciones: — : raya (señal larga) · : punto (señal corta)
Sí se comete un error al transmitir el mensaje en morse, la señal «error» son ocho señales cortas (. . . . . . . .)

¿Para qué se utiliza?

Samuel Morse tardó 7 días en enterarse de la muerte de su esposa en 1832, debido a lo penoso de las comunicaciones a larga distancia en aquella época, tras este desgraciado hecho se decidió a inventar un dispositivo que agilizara ese tipo comunicaciones. El 6 de enero de 1833, Morse realizaría la primera demostración pública de su telégrafo.

Una vez presentado el invento, se concentró en la tarea de construir un telégrafo práctico y despertar el interés del público y del gobierno en el aparato para luego ponerlo en marcha. En 1835 apareció el primer modelo telegráfico que desarrolló Morse.

El funcionamiento del dispositivo es el siguiente:

Cuando en la estación emisora se cierra el interruptor (manipulador) circula una corriente por el siguiente circuito: polo positivo, línea, electroimán, tierra, polo negativo, lo que tiene como consecuencia que, activado el electroiman atraída una pieza metálica terminada en un punzón que presiona una tira de papel, que se desplaza mediante unos rodillos de arrastre, movidos por un mecanismo de relojería, sobre un cilindro impregnado de tinta, de tal forma que, según la duración de la pulsación del interruptor, se traducirá en la impresión de un punto o una raya en la tira de papel. (Wikipedia)

Durante este tiempo, Morse desarrolla junto con el telégrafo un código de señales para facilitar la comunicación, dicho código se perfecciona durante 1838, y toma el nombre de Código Morse.

Intentó implantar líneas telegráficas primero en Estados Unidos y luego en Europa pero ambos intentos fracasaron. Por fin, Morse consiguió que el Congreso de su país aprobara un proyecto de ley para proporcionar 30.000 dólares designados a construir una línea telegráfica de 60 km. Varios meses después el proyecto fue aprobado, y la línea se extendería a lo largo de 37 millas entre Baltimore y Washington.

Ya hemos visto un poquito de historia, ahora… el experimento.

A forma de rudimentario telégrafo inalámbrico, donde la duración de los pulsos la marca el operador según las normas que veíamos más arriba, hemos construido dos robots, emisor y receptor, que se comunican mediante código morse.

El robot emisor cuenta con un sensor de contacto

y un sencillo programa en el cual emitimos un sonido (una nota musical) mientras nos mantengan presionado el sensor.

El receptor está equipado con un sensor de sonido (9845),

con un programa algo más largo que le permitirá mostrar en pantalla puntos o rayas en función de la intensidad del sonido.

Nótese que miramos la intensidad del sonido y no su duración, de tal manera que a cada vuelta de bucle comprobaremos si hay o no sonido, pintando puntos cuando sí que haya.
De esta manera si recibimos sonido durante varias iteraciones de bucle pintaremos varios puntos juntos o, lo que es lo mismo, una raya.

Además hay una línea de control continua que nos permite comprobar que el programa está en marcha, aunque no esté recibiendo señal. Esta línea se pinta en X=Numérica, Y=0, donde Numérica es la varible que representa la posición de X en función del tiempo, se obtiene de dividir el valor del temporizador entre 100 .
Mientras que el mensaje se muestra en X=Numérica, Y=30.

Por último, indicar que, para evitar que la información se solape en pantalla, debemos borrar la pantalla cuando Numérica alcance el máximo que admite la pantalla de ancho, es decir 99.

Aquí tenéis un vídeo del funcionamiento

Esperamos que os haya gustado el artículo y os anime a experimentar con nuevos proyectos, además de buscar nuevas funcionalidades para nuestro set de robótica.

Algunas veces, dentro de la comunidad LEGO, nos encontramos con noticias impactantes y algunas que nos llegan al corazón. Esta es una de ellas. El nuevo proyecto del genial Daniele Benedettelli es la creación de una silla de ruedas autónoma de bajo coste, para ayudar a niños con discapacidad y a sus familias, que en muchos casos son incapaces de afrontar el enorme gasto que una silla de ruedas motorizada tradicional puede alcanzar.

Este proyecto comenzó en Agosto de 2008, tras la petición Gina Wilson Burns, madre de un niño con discapacidad, a Danielle para crear una silla de ruedas autónoma controlada por un NXT, consiguiendo así reducir enormemente los costes del equipo tradicional.

Dicho y hecho, Daniele se puso manos a la obra con el proyecto, su primer paso fue comprobar las posibilidades de navegación autónoma de un dispositivo equipado con NXT. En este caso se trata de un sistema de navegación con balizas láser, hace uso de un sensor fabricado por el propio Benedettelli que puede emitir un haz láser y evaluar su posición debido a la reflexión con respecto a las balizas.

Recientemente, durante el mes de Abril de este mismo año, Benedettelli presentó su prototipo durante la celebración de la Campus Party Europe celebrada en Madrid, resultando galardonado con una mención de honor.

A continuación podéis encontrar el vídeo de la presentación del prototipo.

Daniele Benedettelli es bien conocido en la comunidad Mindstorms NXT como el creador de algunos proyectos que ya hemos comentado en el blog, como :

- NXT Retratista
- Resolvedor del Cubo de Rubik

Así como su libro: LEGO MINDSTRORMS NXT Thinking Robots

Le deseamos toda la suerte del mundo en este proyecto.

Enlaces de interés:

- Blog de Gina Wilson Burns y su hijo Mac
- Blog de Daniele Benedettelli sobre el proyecto, Podéis encontrar también una dirección de contacto para colaborar con él en el proyecto.

En agosto National Instruments anunciaba la próxima salida al mercado del software LabVIEW 2010, y hoy podemos ya confirmaros que es una realidad. Vamos a repasar las características y mejoras más importantes de este nuevo software frente a sus predecesores.

El software NI LabVIEW 2010 tiene un compilador mejorado que genera código máquina optimizado, disminuyendo el tiempo de ejecución de la aplicación hasta en un 20 por ciento. Además, LabVIEW 2010 aborda temas más importantes como apoyo con la instalación de software o configuración de hardware basado en Web.

Con la última versión de LabVIEW, ahora es posible integrar los temporizadores y sincronización con el control, en el lenguaje G. El motor de nanosegundos que utiliza LabVIEW en sus mecanismos temporizadores ahora se puede sincronizar con estándares como IEEE 1588.

Mejoras destacadas en LabVIEW 2010

Nuestro forero DaniRacer, que ya nos sorprendió con una exposición de MOCs con NXT, nos ha mostrado hoy un impresionante parque de atracciones utilizando PF y mindstorms, y hemos querido compartirlo con todos vosotros. El parque consta de 5 atracciones, a cual más original. Además queremos señalar el impresionante trabajo mecánico y de recreación que se ha hecho de algunos de los modelos, que imitan a la perfección a los originales.

Vamos a verlas en detalle.

Las famosas Sillas Voladoras:

Sobre esta atracción, podemos leer en la página del Parque de Atracciones:

“También popularmente conocidas como Las Cadenas, Las Sillas Voladoras es un carrusel del que penden cadenas con sillas que se elevan y giran. Te harán sentir la sensación de flotación, prácticamente igual que si estuvieras volando.”

Las sillas voladoras del siguiente vídeo pertenecen al Luna Park de New York. La velocidad de giro es muy inferior a la que ha creado DaniRacer. La perspectiva con la que ha sido tomado el vídeo nos da la sensación de que las sillas se abren más hacia el exterior de lo que realmente lo hacen: el ángulo con el que se abren depende básicamente de la velocidad de giro y del radio. Podéis estudiar la dinámica del movimiento siguiendo el enlace inferior.

Por lo que podéis ver en el vídeo que hay al final del artículo, DaniRacer ha conseguido imitar esa sensación de vuelo a la perfección, aunque a mayor velocidad.

La mítica lanzadera

“Espectacular caida libre desde 63 metros de altura a 80 km/h.

La mejor forma de experimentar el “puenting” seguro sin salir de Madrid. Esta instalación, traída de EE.UU., otorga el privilegio de sentir una caída libre a 80 km/h desde 63 metros de altura. La intensa sensación dura apenas 2 segundos: suficiente para poner en alerta todo el sistema nervioso.”

Un curiosa atracción pendular

Que me recuerda poderosamente al Aladino/TIR:

“T.I.R. [1989 - 2009]: Inaugurada el 28 de julio de 1989 con el nombre “Aladino” y desmantelada en primavera de 2009. Consistía en una viga vertical de 15m con el eje en el centro y en cuyo extremo se localizan los asientos. El eje realiza giros de 360º haciendo que la viga gire de manera similar a las manecillas de un reloj. El extremo donde se sitúan los asientos también tiene un eje que gira en sentido contrario al eje principal, haciendo que los asientos siempre mantengan la misma posición horizontal. Se situaba en la zona Oeste del parque, al lado de las Sillas Voladoras y el Tifón. Ninguna atracción ha ocupado su lugar.”

Para los amantes de atracciones más relajadas, tenemos la barcaza

Que se desplaza con un suave movimiento pendular mientras gira sobre si misma. Lo que recuerda al nuevo Tifón, aunque este último es mucho más rápido y para nada relajante…

“En Abril de 2008, el Parque de Atracciones de Madrid incorpora TIFÓN en la Zona del Maquinismo. En esta atracción puedes subir y balancearte a la vez que giran y se trasladan de la forma más divertida. Un divertido viaje en el que se alcanza una altura de más de 15 metros y sus asientos son similares a los de una moto pero con un arnés automático trasero que maximiza las sensaciones.”

Por último, para los nostálgicos de las atracciones más clásicas… los coches de choque

Estos coches de choque son completamente automáticos y están dotados de un ingenioso sistema que imita un movimiento pseudo aleatorio.

Detalle del sistema de engranajes

Os dejamos con el vídeo de las atracciones en funcionamiento, esperamos que os guste.

Es curioso, pero a pesar del innegable atractivo que han tenido las ferias en todos nosotros, son muy pocos los conjuntos relacionados con esta temática que LEGO ha ofrecido. Uno de ellos es el caso de la noria 4957, que pasó sin pena ni gloria por nuestro país, no porque no gustara, sino porque estuvo en catálogo durante 3 meses únicamente!

El segundo modelo es el tiovivo: sí es cierto que hubo un pequeño carrusel en el 1989 de 23 piezas, nada que ver con el reto actual de 3263 piezas, que no sólo tiene una estética impecable sino que además tiene un motor que proporciona movimiento circular al conjunto y a los caballitos que suben y bajan. Y, ¡cómo no… el tiovivo tiene música también!

Información adicional:

• Dinámica del movimiento circular.

• English

Ya está disponible el nuevo sensor de LEGO Educativo, que hasta ahora sólo podían disfrutar los usuarios de la versión comercial 2.0 del NXT. Se trata de un sensor con tres funciones: color, luminosidad y lámpara, todo en un mismo puerto. Es el 9694, Sensor de Color NXT.

El nuevo sensor puede ser utilizado como un sensor de luminosidad clásico, para detectar colores (hasta 6 distintos en NXT-G) o como lámpara, emitiendo luz roja, verde o azul. Los usuarios del set educativo 9797 ya tenían una lámpara, pero debían usarla con un cable especial y consumían un puerto de motor, ahora esto no es necesario.

Para poder hacer uso de las funcionalidades del nuevo sensor, necesitaremos descargarnos 2 bloques nuevos:

Bloque Lámpara (para Sensor de Color)

NOTA: Después de descargar los archivos zip, los descomprimimos y entramos en la carpeta. Debemos buscar un archivo zip que corresponda con el idioma de nuestro software.
En nuestro caso, los archivos se llaman Spanish Color Sensor 2_x.zip y Spanish Color Lamp 2_x.zip
Debemos descomprimir este segundo archivo, ya que es el que lleva la información necesaria para importar el bloque.

Ahora debemos añadirlos a nuestra paleta de bloques, para ello podemos seguir estos sencillos pasos:

Cuando se nos abra la nueva ventana, pulsamos “Examinar”

Recordemos que la ruta del bloque será:

[Ruta del archivo descomprimido]\ColorLamp\Color Lamp\Spanish Color Lamp 2_x

o

[Ruta del archivo descomprimido]\ColorSensor\Color Sensor\Spanish Color Sensor 2_x

Seleccionamos el bloque y la paleta en la que queremos incluirlo y hacemos clic en “Importar”.

Cuando se termine la importación, recibiremos el mensaje “Importación correcta”.

Y este es el aspecto que tendrán nuestros nuevos bloques una vez importados:

Bloque Color

Bloque Lámpara

Importante:

Para poder usar el nuevo sensor como un sensor de luminosidad, no hay ningún bloque, hay que utilizar el bloque Color (que acabamos de importar) y seleccionar:

“Acción – Sensor Luz”

Y nuestro menú cambiará a este:

Donde tenemos las opciones habituales del sensor de luminosidad clásico, más la posibilidad de, si tenemos marcada la opción de emitir luz, emitir en rojo, verde o azul.

Cualquier duda o problema, podéis visitar el foro.

Share

Tweet

• English

¡Noticia importante! Ya está disponible la actualización -gratuita- para los usuarios del Software Educativo NXT que tengan la versión 2.0. Esta actualización es compatible con Windows y MAC.

Este parche, que actualiza a la versión 2.1, corrige los siguientes problemas:

• English

Ya hemos hablado de los sistemas holonómicos, además, hemos visto varios ejemplos realizados con NXT. Todos ellos basan su capacidad de desplazamiento en ruedas omnidireccionales – o en esferas – , sin embargo, hoy queremos mostraros un tipo de robot holonómico que utiliza ruedas estándar combinadas con un tipo de dirección sincronizada integral (a las 4 ruedas). Esto le permite moverse en cualquier dirección de forma prácticamente inmediata.

Utiliza únicamente 2 motores, por lo que aún nos deja un puerto de motor libre para cualquier cosa que se nos pueda ocurrir, desde una pala a un brazo/manipulador.

Vista frontal

Se trata de un modelo con tracción a las 4 ruedas, que también tiene dirección sincronizada en las 4 ruedas, por lo que puede orientar las ruedas en cualquier dirección sin desplazarse, es decir, no necesita hacer maniobras para cambiar la dirección.

Detalle del sistema de tracción, un lateral

El otro lateral

Imaginaros el potencial de un vehículo como este para acciones cotidianas como aparcar, avanzamos hasta encontrar el sitio, ponemos las ruedas perpendiculares a la acera… y aparcamos.

Vamos a ver en detalle la dirección sincronizada.

Aquí tenéis el vídeo del vehículo aparcando, además de poder ver en detalle su funcionamiento.

Esta versión no está equipada con ningún sensor, el aparcamiento se hace con distancia conocida, pero si montamos un sensor ultrasónico (o varios), por ejemplo, podríamos hacer que aparcara en cualquier lugar y circunstancia. O podríamos añadirle un sensor brújula que nos permitiera saber hacia dónde nos estamos moviendo, algo que es difícil de controlar, ya que puede desplazarse en todas direcciones.

Esperamos que os haya gustado, para cualquier cosa, podéis utilizar el foro.

Ya se encuentra disponible la actualización del conjunto de recursos para robótica de LEGO Educativo. Nuevas piezas y nuevas posibilidades. Incluye una gran cantidad de elementos especiales, como orugas, conectores exclusivos, tornillos sin fin, y elementos estructurales LEGO, como vigas, ejes y conectores. Esta nueva caja de LEGO Educativo tiene 817 piezas y viene con la presentación tradicional en caja de plástico con clasificadores para las piezas.

Se trata de una gran herramienta de expansión para nuestra caja de robótica, ya sea la versión comercial (ref. 8547) o la educativa (ref. 9797), ofreciéndonos posibilidades que hasta entonces no teníamos, ya sea por la inclusión de nuevas piezas o por tener más cantidad de algunas que puedan hacernos falta.

Recordemos que muchos de los diseños que podemos encontrar hacían uso de la referencia 9648, la antigua caja de recursos de LEGO Educativo, pues bien, este nuevo conjunto de piezas es la actualización de dicho set.

Existen infinidad de modelos disponibles que podéis construir con estas nuevas piezas, pero si queréis una pequeña guía para empezar, a continuación encontraréis las instrucciones para 9 robots.

NOTA: estos robots están pensados para usar los sets 9695 + 9797
Para descargar las instrucciones, haced click derecho en la imagen correspondiente y seleccionad “Guardar enlace como…”.
También podéis visualizarlo en el navegador simplemente haciendo click en la imagen del modelo que os interese.

Algunos robots clásicos:

Tribot

RoboArm

Humanoide

Reloj Clásico

Escorpión

SoundBot

Y algunos nuevos

Vehículo Inteligente

Clasificador de colores

Rover con 4 orugas

El bit es la mínima cantidad de información posible, puesto que éste almacena únicamente un posible valor, que podemos representar de varias formas: como verdadero o falso, activo-desactivado, 0 ó 1, etc. El operar con este tipo de información constituye la plataforma sobre la que se fundamenta la lógica computacional moderna, en definitiva de los microprocesadores actuales. Recibe el nombre de Lógica Booleana en honor quien la inventó en el siglo XIX, George Boole.

Consideremos que los dos posibles valores que puede tomar un bit de información son 0 ó 1. Con los bits podemos realizar varias operaciones. Una forma de representar estas operaciones es mediante unos símbolos que se denominan puertas u operadores lógicos. Dichos operadores requieren de uno o más bits como entrada y producen una salida que depende de ellos y del propio operador. La relación entre los bits de entrada y el resultado producido se pueden representar en una tabla, que se denomina tabla de verdad. La tabla de verdad no nos indica más que el valor que obtendremos a la salida de la función lógica dependiendo de los valores que ésta tenga a su entrada.

Los sistemas digitales se construyen mediante combinación de puertas lógicas. De ellas, las más comunes son NOT, AND, OR, NAND, NOR y XOR.

La puerta lógica más simple es el inversor, también denominado NOT. El resultado de una inversión es cambiar el valor de entrada a su opuesto: si a la entrada tenemos un 0, el resultado será un 1, y viceversa. La tabla de verdad del inversor es la siguiente:

La paleta de funciones booleanas en LabVIEW tiene el siguiente aspecto:

Hagamos un ejemplo minimalista para mostrar las funciones booleanas anteriores. En el Panel Frontal hemos dibujado unas flechas, no son más que meros elementos decorativos. Partiendo de las dos señales booleanas A y B realizamos las operaciones lógicas nombradas anteriormente.

En el diagrama de bloques queremos hacer patente que las funciones NAND y NOR son las versiones negadas de las AND y OR respectivamente. Es decir,

Si ejecutamos el programa vemos que el color de los indicadores de salida va cambiando en función de los valores de las señales de entrada X e Y según la función aplicada. Hemos elegido el color verde claro para el valor TRUE y oscuro para FALSE.

En el ejemplo anterior hemos realizado estas operaciones trabajando con unas entradas de tipo boolean. Este es el funcionamiento más habitual para este tipo de operadores. Pero estas funciones lógicas también pueden aplicarse sobre otros tipos de datos. Dentro del ámbito de los lenguajes de programación se denomina polimorfismo al hecho de posibilitar que un mismo interfaz pueda ser empleado sobre diferentes tipos de datos. En nuestro caso podemos decir que las funciones lógicas que nos ofrece LabVIEW son polimórficas, queriendo decir con ello que el mismo símbolo nos va a permitir operar no sólo con variables de entrada de tipo boolean, sino que también permite trabajar con otro tipo de datos. Si aplicamos el NOT a una matriz obtendremos una matriz cuyos elementos serán los negados de los originales, elemento a elemento. En general, podemos aplicar estos operadores sobre arrays de booleans, sobre clusters de booleans, números, arrays numéricos o matrices.

Veamos con otro ejemplo una de las aplicaciones típicas de los operadores numéricos: las máscaras. Las máscaras nos permiten extraer cierto tipo de información del dato sobre el que se aplica. Supongamos que tenemos una secuencia de 8 bit como 01101011 y queremos saber cuáles de los 4 de mayor peso están a uno. Del resto de la secuencia no nos interesa conocer nada, por lo que podemos anularla. Para ello podemos aplicar la función lógica AND con un patrón de 8 bits en el que ponemos a 1 los 4 bits de más peso, tal que 11110000. El resultado 01100000 es un AND que se ejecuta bit a bit.

En el siguiente ejemplo de LabVIEW realizamos la máscara del dato de entrada, lo que es equivalente a aplicar la función AND. Al ejecutarlo podemos modificar tanto el valor de entrada como el de la máscara. A pesar de que nosotros introducimos el valor de los datos como enteros, se muestra su valor en binario para que veamos cómo se están realizando las operaciones bit a bit.

Los ejemplos anteriores de LabVIEW se han ejecutado en el ordenador. Ahora vamos a implementar un pequeño ejemplo práctico pero trabajando sobre un LEGO MINDSTORMS NXT. Hemos conectado un servomotor en el puerto A del robot NXT. Nuestro objetivo es hacer un sencillo programa que nos permita controlar dicho servomotores con dos pulsadores.

Vamos a crear un pequeño interfaz que deliberadamente nos obligue a hacer uso de funciones lógicas. Para ello activaremos el motor según dos posibles pulsadores:

• Un pulsador lo hará avanzar en un sentido, y que denominaremos como pulsador P1 (FWD).
• El segundo pulsador lo hará avanzar en sentido inverso, pulsador P2 (BACK).

Por la forma en la que lo planteamos se van a producir -deliberadamente- 4 casos posibles, según estén pulsados o no cada uno de los dos pulsadores. Podemos representar en una tabla como las anteriores lo que puede suceder:

• El motor se detiene.
• El motor avanza.
• El motor retrocede.

Ahora reescribamos, para cada uno de los resultados, la misma tabla anterior. Empecemos por la tabla en la que el motor avanza. Así, la siguiente tabla representará cuándo el motor va a avanzar. Si avanza, lo representaremos con un 1 lógico, en caso contrario, con un cero.

Podemos razonar del mismo modo para el caso en el que el motor debe retroceder, y obtenemos que sólo se produce el retroceso cuando P1 no está pulsado, pero sí lo está P2, es decir:

El caso en el que se detiene el motor es un poco más complicado, porque puede darse en dos situaciones posibles, en la primera o en la última, es decir:

Dado que ya tenemos las ecuaciones lógicas que van a controlar el control de lo motores, podemos implementar el programa en LabVIEW. Como cualquier problema, éste puede resolverse de muchas formas posibles. Nosotros hemos elegido con finalidad didáctica el controlar el motor mediante una estructura case.

Y lo que se ejecuta en los otros dos casos del case es:

Y el panel frontal que hemos preparado es el que sigue:

El programa consta de varias partes:

• Una primera en la que construyo las funciones lógicas de Avanzar, Retroceder y Detener partiendo de las señales de los pulsadores P1 y P2, tal como he explicado antes. Para comprobar que su funcionamiento es correcto he añadido unos indicadores que muestran su valor en función del estado de los pulsadores. He añadido también dos comentarios para indicar Not P1 y Not P2 con objeto de facilitar la lectura.
• Con lo anterior ya disponemos de las tres funciones, pero como vamos a trabajar con un case para controlar el estado del motor del NXT… ¿Cómo relaciono dichas señales con la entrada de control del case? La solución por la que he optado es por la de agrupar las tres señales en un array de tres elementos y convertir a continuación dicho array en un valor numérico, que es el que controlará el caso a ejecutar. Para construir dicho array de booleans hago uso del icono Build Array, que podemos encontrar en la paleta de funciones de Array. El siguiente paso en transformar ese valor numérico, porque un array no puede emplearse para controlar los casos de un case. Empleo la función Boolean Array To Number. Para comprobar qué valor se está asociando muestro el valor numérico con el indicador que llamo Número.
• A la estructura Case debemos añadirle un caso adicional, porque tal como lo introducimos en el diagrama de bloques sólo tiene dos casos posibles. Además debemos nombrar cada uno de los casos según nos aparezcan los valores en Número, y debemos hacerlos coincidir con según la ejecución adecuada. Para poder ejecutar el programa y observar qué valores ha asignado LabVIEW a esos casos, podemos realizar una primera ejecución asignando a los casos los valores 1, 2 y 3. Debemos además asignar el caso Detener como Default.
• Todo lo anterior se ejecuta en el interior de un while con su correspondiente botón para detener el programa.

Si todo es correcto:

• Cuando presionemos P1 debe iluminarse el LED de Avanzar y el motor girar en un sentido.
• Cuando presionemos P2 debe iluminarse el LED de Retroceder y el motor girar en el sentido contrario al anterior.
• Cuando presionamos los dos pulsadores o cuando ninguno está presionado, debe iluminarse el LED Detener y el motor debe detenerse.

* Ejecución en modo Remoto: Este programa debe ejecutarse en el PC sin descargar el programa en el NXT, sino mediante control directo desde el LabVIEW en tiempo real, porque la estructura case con casos enumerados no puede compilarse para el NXT.

Para cualquier duda, como siempre, podéis acudir al foro.

En este artículo hemos querido programar nuestro propio robot futbolista. Es un clásico de la robótica, que además nos servirá de punto de partida para una serie de experimentos con infrarrojos. Con un tribot modificado, la bola de IR y un sensor de búsqueda de infrarrojos, nos hemos puesto manos a la obra.

Vamos a revisar primero el material:

Bola de IR

La bola emisora de infrarrojos consta de un array de leds distribuidos de forma uniforme por toda la bola. Además, tendremos 4 modos de emisión:

D: 1200Hz – Onda Modulada de 1200Hz

Como alimentación, utiliza 4 pilas AAA, y la duración oscila entre las 7 horas y media del modo A, a poco más de una hora en el modo B; los modos C y D tienen una autonomía de 3 horas y media.

Sensor de búsqueda de infrarrojos

El sensor de búsqueda de infrarrojos nos devuelve la dirección desde la que recibe la señal, según el siguiente esquema:

Lo cual nos permitirá saber de dónde nos viene la señal, además de la intensidad de señal recibida en cada una de las 9 direcciones posibles. Esto nos puede permitir, entre otras cosas, calcular mucho mejor la posición del objeto que queremos localizar o seguir.

Para nuestra primera prueba, vamos a hacer un programa en NXT-G muy sencillo:

¡OJO! En nuestro robot el sensor está dado la vuelta, con respecto al dibujo de las direcciones que hay más arriba. Hay que tenerlo en cuanta al hacer los giros.

• English

¿Quién no ha querido alguna vez decirle a su NXT qué debía hacer y conseguir que lo hiciera? Pues aquí tenéis un primer paso para conseguirlo. Hasta que lenguajes como ROILA sean plenamente funcionales no podremos conseguir que el robot nos entienda directamente, pero sí tenemos herramientas de reconocimiento de voz para el ordenador, y sabemos como comunicarnos remotamente con el NXT desde el ordenador, así que… con mucha paciencia y algunos trucos podremos conseguir que nuestro robot reconozca nuestras instrucciones y las obedezca.

Ya hay algunos programas que basan el reconocimiento de voz en la diferente intensidad con la que se dicen las sílabas de la palabra clave, y utilizan el sensor de sonido (NXTPrograms).
Incluso, hay varios programas que permiten control con voz, dos de los más relevantes son:

Eso es exactamente lo que hace este original programa de nuestro forero CSM. Basado en el programa de la calculadora NXT-G y con mucha paciencia, ha introducido 33 referencias distintas del stock de electricBricks en su catálogo virtual, ¡y con precios actualizados!. Al introducir el código del artículo, tendremos, no sólo el precio, si no también una imagen del producto.

Toda la programación se ha realizado en NXT-G, utilizando la versión comercial 2.0, más concretamente la herramienta de edición de imágenes que esta nueva versión lleva integrada.

El esquema del programa es el siguiente:

1. Presentación del catálogo
2. Nos pide los 4 dígitos del artículo (uno a uno) y opera los cuatro dígitos independientes para obtener uno de la siguiente manera Número final= ((Cifra 1*10 + Cifra 2)*10 + Cifra 3) *10 +Cifra 4, de esta manera, el sistema nos va mostrando los números que hemos ido introduciendo en la parte superior, según los elegimos, ordenados de izquierda (el primero) a derecha (el último).
3. Comprobación de si el artículo está (o no) en el catálogo, para esto hace uso de la estructura case que se trabajó en la calculadora.
4. Por ultimo, tras mostrarnos el artículo, o el mensaje de error correspondiente en caso de que el artículo no exista en la Base de Datos (estructura case). Nos preguntará si queremos mirar otro artículo.

Como podemos apreciar, el funcionamiento es muy sencillo, y la programación encapsulada en Mis Bloques hace que todo sea mucho más claro y también más fácil de modificar.

Vamos a ver en detalle los bloques

Bloque Presentación

Bloque Variables

Bloque IntroNum

Bloque list

Bloque otro

Por último un vídeo del funcionamiento

Después del tutorial de instalación de LeJOS en MAC vamos a ver cómo instalar y configurar el entorno de programación Eclipse para trabajar con LeJOS. Primero lo instalaremos y posteriormente haremos nuestro programa Hola Mundo desde Eclipse.

1. Instalar y configurar Eclipse

Lo primero que tenemos que hacer es ir a la página de descarga de Eclipse y bajarnos Eclipse IDE for Java EE Developers.

Como Eclipse no necesita instalación, basta con descomprimir el archivo y colocar la carpeta resultante donde queramos, por ejemplo, en la carpeta Aplicaciones de nuestro MAC.

Para abrir la aplicación simplemente hacemos click sobre el icono de Eclipse.

Lo siguiente que nos vamos a encontrar es una pantalla que nos pide el nombre de nuestro espacio de trabajo (Workspace)

Tras esto estaremos en la pantalla de bienvenida de Eclipse

Ahora tenemos que crear un nuevo proyecto File – New… – Project

Y seleccionamos como tipo de proyecto Java Project

Ahora damos un nombre a nuestro proyecto

Abrimos Propiedades

Y tendremos que editar:

• English

Muchos usuarios han tenido problemas de conexión bluetooth entre sus ladrillos NTX y su MAC. Vamos a dar un pequeño repaso a la configuración que necesitamos para que todo funcione correctamente. Además, veremos cómo realizar la conexión desde NXT-G y desde LeJOS (instalación de LeJOS en MAC).

Emparejamiento

Lo primero que debemos hacer es emparejar el NXT con el MAC. Para que todo funcione correctamente, os recomendamos que sea el ordenador el que realice la búsqueda y posterior emparejamiento.

Primero vamos al menú “Preferencias de Bluetooth”

¡IMPORTANTE! Antes de continuar, os recomendamos que borréis todos los NXT que hayan sido emparejados previamente con el ordenador.

Nos aseguramos de que nuestro NXT tiene el bluetooth encendido y en modo visible.
Seleccionamos “Añadir nuevo dispositivo”, el símbolo + abajo a la izquierda.

Cuando el MAC detecte nuestro NXT, lo seleccionamos y le damos a continuar

Nos aparecerá la pantalla de emparejamiento, por defecto, la clave de emparejamiento bluetooth de nuestro MAC es 0000

Debemos estar atentos a nuestro NXT, pues nos pedirá que confirmemos la clave.
Aquí tenemos 2 opciones:

1. Cambiar la clave por defecto del NXT: 1234, por la de nuestro MAC: 0000.
2. Confirmar la clave 1234, y cuando el ordenador nos devuelva error, cambiamos la clave del MAC (eligiendo, lógicamente 1234)

Si todo ha ido correctamente, en unos segundos deberíamos tener una pantalla como esta

Ahora, para comprobar que el proceso ha finalizado de forma correcta, volvemos a “Preferencias de Bluetooth” y comprobamos la configuración de puertos del nuevo dispositivo

Tenemos que tener exactamente esta configuración

Si no es así, la cambiamos.

Con esto finaliza el proceso de emparejamiento, que no es más que hacer que los dispositivos se reconozcan entre si, ahora vamos a conectarnos al NXT.

Conectando al NXT por bluetooth con NXT-G

La conexión desde NXT-G es muy intuitiva, sólo debemos tener el cuenta que el NXT no debe estar conectado previamente con el MAC (sí emparejado, no confundir los dos términos).

Seleccionamos la opción Visualizar NXT en el menú de la parte inferior derecha

Cuando se nos abra la ventana, le damos a Buscar

Entonces nos saltará una ventana de sistema que nos preguntará qué dispositivo queremos añadir a la lista de conexiones de NXT-G

Buscamos el nuestro en la lista y le damos a Seleccionar. Aquí es donde la búsqueda difiere de Windows, si recordáis, Windows nos muestra una lista de todos los que encuentra disponibles, sin embargo MAC sólo nos muestra los que le indiquemos.

Una vez seleccionado, pasará a nuestra lista de NXT-G, donde le damos a Conectar (si está Disponible, claro).

En unos segundos, si todo ha ido bien, tendremos esta pantalla

Conectando al NXT por bluetooth con LeJOS

Si no tenéis LeJOS y queréis usarlo en vuestro MAC, podéis seguir el tutorial de instalación de LeJOS en MAC.

Por defecto, la versión 0.85 de LeJOS para MAC lleva incluida la librería BlueCove 2.1.0, que nos permitirá conectarnos por bluetooth a nuestro dispositivo sin problemas.

Abrimos la terminal y tecleamos

cd lejos_nxj/bin
(nosotros lo tenemos instalado en Home)

Con esto estamos dentro de la carpeta de ejecutables de LeJOS.
Ahora, el comando

./nxjconsoleviewer

Esta utilidad te permite monitorizar las conexiones y la salida de consola del NXT.

Seleccionamos como tipo de conexión Bluetooth, introducimos el nombre del NXT (el nuestro se llama Mac) y le damos a Connect. El campo Address se puede dejar en blanco, realizará la búsqueda por nombre.

Puede que te pida la clave de emparejamiento (el NXT tiene por defecto 1234), introdúcela y dale a Emparejar (Pair).

Tras unos segundos, nos aparecerá esta pantalla indicando que todo ha ido bien.

Si esta utilidad no os convence, o no funciona correctamente, podéis probar con el comando

./nxjbrowse -b

-b fuerza a la aplicación a realizar una búsqueda de dispositivos bluetooth (-u es lo mismo pero para USB).
Debería localizarlo correctamente, después, simplemente le damos a Connect

Esta otra aplicación nos permite, no sólo conectarnos al NXT, si no también administrar sus archivos, cargar y descargar programas o incluso ejecutarlos, cambiarle el nombre al ladrillo, etc…

Con esto terminamos el tutorial de conexión Bluetooth, si tenéis cualquier duda o problema, podéis acudir al foro.

Una de las posibles formas de clasificar los robots es distinguiendo si son holonómicos o no. Es una distinción que está relacionada con su movilidad. Simplificando, podemos decir que un robot es holonómico si es capaz de modificar su dirección instantáneamente (en esta consideración se considera masa nula), y sin necesidad de rotar previmente. Un vehículo con un sistema de dirección como el de un coche, por ejemplo, no lo es, porque para poder desplazarse en el sentido lateral tiene que realizar varias maniobras previas. Del mismo modo, un robot con 2 ruedas es no-holonómico ya que no puede moverse hacia la izquierda o la derecha. Siempre lo hace hacia delante en la dirección definida por la velocidad de sus ruedas.

El Dr. Masaaki Kumagai, director del Robot Development Engineering Laboratory de la Universidad de Tohoku Gakuin en Japón ideó un robot que se desplazaba sobre una esfera mediante el uso de ruedas omnidireccionales. El siguiente vídeo abre las puertas a un sinfín de posibles aplicaciones como la ayuda para el transporte de objetos pesados mediante uno o varios de estos robots en sistemas colaborativos.

Grados de libertad
Se dice que el número de grados de libertad (GDL) de un robot es el número de magnitudes que pueden variarse independientemente. En un brazo robotizado cada articulación proporciona habitualmente un grado de libertad. Si queremos posicionar un manipulador en cualquier punto del espacio en cualquier orientación necesitamos 6 grados de libertad, 3 para la posición y 3 para la orientación del manipulador. En el caso de un vehículo que se desplaza en un plano, estamos hablando de 3 grados de libertad: 2 para la posición y 1 para la orientación.

El control está relacionado con los de grados de libertad. En general cada grado de libertad requiere de un actuador. Si disponemos de un actuador por cada GDL, diremos que todos los GDLs son controlables. Habitualmente existe un actuador por grado de libertad, pero no siempre es así.

Diremos que un robot es holonómico si tiene los mismos grados de libertad efectivos que controlables. En general, un robot no holonómico tiene menos grados de libertad controlables que número total de grados de libertad, mientras que si sucede lo contrario, el robot es redundante. En general, a mayor diferencia entre grados de libertad controlables y grados totales, más difícil será controlar el robot.

En el ejemplo del coche, decimos que es no holonómico porque tiene 3 GDLs y sólo se controlan dos. Normalmente cuando montamos un coche de LEGO trabajamos con 2 motores: uno para tracción y otro para dirección. De ahí que sea tan difícil controlarlo (no podemos aparcar lateralmente).

Vehículos omnidireccionales
¿Cómo se construye un sistema capaz de desplazarse omnidireccionalmente? Aunque comercialmente no existen vehículos de estas características, empresas como Mitsubishi están trabajando en prototipos como el MMR25, un concepto muy adelantado a fecha de hoy que emplea ruedas omnidireccionales, del que podeis ver las siguientes fotos a continuación. Para un conductor como nosotros, habituados a un sistema de dirección tradicional, el controlar un vehículo de estas características encierra nuevos problemas que no existen en los vehículos actuales, como la necesidad de disponer de un sistema de visión también omnidireccional (1).

Con una autonomía de 1 hora y una velocidad máxima de 6km/h, el Honda U3-X es un medio de transporte para distancias cortas. El vídeo comercial de Honda explica cómo el U3-X es capaz de desplazarse en cualquier dirección mediante el uso de una gran rueda omnidireccional.

Si bien la idea como vehículo personal de transporte queda lejana a título particular, el sistema de tracción omnidireccional ya existe y son muchos los robots que lo integran. La principal ventaja de un sistema omnidireccional es su maniobrabilidad, pero esto complica tanto el diseño mecánico como el control. Una forma de conseguir este tipo de tracción/dirección es mediante el uso de ruedas omnidireccionales.

La forma más simple de conseguir una rueda omnidireccional es haciendo uso de una esfera. Pero esta idea simple encierra problemas tanto desde el punto de vista mecánico como algorítmico. En el siguiente vídeo de Tomás Arribas podemos ver cómo se resuelve el problema del péndulo invertido sobre una esfera haciendo uso de esta idea. Se emplean dos giróscopos para tener noción de la velocidad de rotación en cada uno de los ejes y de dos motores para controlar el giro del robot sobre la esfera.

Las ruedas omnidireccionales no son una sola rueda en realidad, sino que constan de varias. Sobre la periferia de una gran rueda central se montan una serie de pequeñas ruedas: mientras que la rueda central se comporta como una rueda tradicional, las periféricas rotan perpendicularmente. Las ruedas holonómicas tienen dos grados de libertad. Existen variedad de ruedas omnidireccionales posibles en el mercado. LEGO no fabrica una rueda de este tipo, por lo que si necesitamos una tendremos que construirla o hacer uso de la versión metálica de Tetrix.

Los sistemas dotados de ruedas omnidireccionales habitualmente montan 3 ó 4 de estas ruedas. La principal ventaja de los sistemas de 3 ruedas es que reducen el coste, no sólo de la propia rueda -estas ruedas son relativamente caras- sino por la reducción de la mecánica asociada. Se trata de un sistema con tres puntos de apoyo, por lo que sus tres puntos siempre están en contacto con el suelo, cosa que no tiene porqué ocurrir en un sistema de 4 ruedas. Sin embargo, el control de velocidad de cada una de las tres ruedas es totalmente independiente, lo que obliga a una mayor capacidad de cálculo frente a un sistema de 4 ruedas, en el que las velocidades de las ruedas pueden relacionarse por pares de manera muy simple. La capacidad de cálculo puede ser un factor limitador en sistemas basados en micros pequeños. Uno de los montajes típicos en tres ruedas es la denominada plataforma de Killough, que será motivo de otro artículo.

El siguiente modelo fue construido por Xander para el Lego World 2009.

Las ruedas omnidireccionales también han sido construidas mediante la unión de una gran cantidad de pequeñas ruedas de LEGO.

El robot se controlaba mediante un mando Power Functions y un sensor de enlace IR que recibía dichas órdenes y se las transmitía al NXT:

Una de la ventajas de un sistema de dirección holonómico frente al sistema de dirección tradicional es que su control es mucho más intuitivo. Dado que el vehículo holonómico puede desplazarse en cualquier dirección, si éste no es autónomo y debe ser controlado con un joystick, por ejemplo, el control del mismo puede ser inmediato: la dirección de avance será la del joystick, y la velocidad podría ser proporcional a la inclinación del mismo. En algunos casos puede ser incluso necesario controlar el ángulo de giro del robot, es decir, su rotación. Esto puede ser inmediato en el caso de que el joystick permita el giro, en caso negativo el control de rotación tendrá que ser implementado mediante un sistema auxiliar o un segundo joystick. Si bien los conceptos anteriores son muy sencillos, su implementación no lo es tanto, y la dificultad se acrecienta cuando necesitamos controlar no sólo la dirección de avance sino también la longitud exacta de traslación. La dificultad del proceso radica en que la traslación mediante ruedas omnidireccionales se basa en el deslizamiento de las mismas, y la medida de este deslizamiento depende de un gran número de factores, entre los que se encuentran los materiales de las propias ruedas, el coeficiente de rozamiento con el material sobre el que se desplazan, el ángulo de desplazamiento, velocidad, peso del robot y su distribución sobre las ruedas… estos motivos obligan muchas veces a cálculos empíricos.

Información adicional:

• (1) Omnidirectional Active Vision for Evolutionary Car Driving, por Mototaka Suzuki, Jacob van der Blij, y Dario Floreano.
• (2) Omnidirectional Drive Systems, por Ian Mackenzie

Hay muchos vehículos que hacen uso de las hélices para desplazarse, como aviones o helicópteros, pero pocos resultan tan llamativos y polivalentes como un hovercraft (aero deslizador en español). Estos vehículos suelen ser capaces de desplazarse a velocidades relativamente altas tanto en tierra como por el agua.

Generalmente lo que todos asociamos con un aero deslizador es algo parecido a esto

O a esto

Que nos dejan vídeos tan impresionantes como este:

LEGO también sacó una versión de hovercraft de bomberos, el set 7944, que vio la luz en 2007.

Partiendo de esta genial idea de mover un vehículo con la fuerza de unas hélices, nos hemos lanzado a construir nuestro propio aero deslizador. Este modelo, construido por nuestro forero CSM, está basado en el modelo de Air Scooter de leggor, que podemos ver a continuación

En el modelo de CSM, el air scooter está totalmente realizado con technic y NXT, tiene sólo dos palas y el giro se realiza desde la parte trasera.

Frontal

Trasera

Lateral

Aquí un vídeo para que lo veáis en marcha

• English

El pasado sábado 26 de Junio tuvo lugar la primera competición de karts de electricBricks, en una reproducción a escala del circuito de Mónaco. Como no podía ser de otra manera, este circuito requería de un semáforo a su altura, y lo hicimos.

Se trata de un semáforo controlado por un NXT con un sencillo programa en NXT-G. Intentamos hacerlo lo más fiel posible a los reales (las dos luces rojas se mantienen encendidas hasta que se enciende la verde), pero las limitaciones de consumo (hay 12 bombillas) nos obligaron a controlar el tiempo de encendido de las luces.

La forma de controlar la duración de encendido de las luces depende del tiempo durante el cual se emite el sonido (tenemos marcado “Esperar hasta finalización”).
El proceso es el siguiente:

• English

En este artículo voy presentar una mejora del programa que ya puse en el artículo Kart NXT controlado remotamente con LeJOS. Lo que se plantea en este artículo es conseguir un Kart NXT radio-controlado mediante otro NXT (un mando) que funcione eficientemente (tenga retardos factibles, y sea manejable). El de este artículo fue el modelo final que se usó en la competición de Karts del domingo, y el encargado de llevar la cámara (un Iphone 3G).

El problema principal radica en conseguir un modelo radiocontrol en NXT que pueda competir contra Karts creados con motores y componentes Power Function. En primer lugar estos Karts pesarán menos de base, debido al menor peso de sus motores, y a que no necesitan un ladrillo NXT. También tienen un manejo mucho más sencillo, debido a su sistema de control mediante mando de infrarrojos. La única ventaja con la que partimos es que la comunicación Bluetooth tiene un mayor alcance y además no se ve influida por la luz solar, la cuál interfiere mucho en las comunicaciones mediante infrarrojos.

El problema de la latencia:

Uno de los problemas que tenía el programa anterior era el de las latencias. Debido a la necesidad de enviar suficientemente lento para que el receptor sea capaz de procesar los datos, necesitamos añadir un retardo en el emisor. Este retardo produce, entre otras cosas, que haya una latencia notable entre que nosotros movemos el mando y el kart actúa en consecuencia. Hay varias formas de mitigar esto:

- Reducir el tiempo que se tardan en procesar los datos.

- Ajustar al máximo el retardo a ese tiempo de procesamiento.

- Enviar datos cuando sea estrictamente necesario.

En primer lugar es muy importante que reduzcamos el tiempo que se tardan en procesar los datos. Por ejemplo en el programa del artículo anterior tardábamos mucho en procesar el giro ya que el método rotateTo de la clase Navigator no devuelve el control hasta que el motor haya girado al ángulo determinado. Para eliminar todo este tiempo lo que hacemos es usar la función rotateTo que devuelve el control (ver código del Kart, línea 55). De este modo podremos seguir recibiendo datos tranquilamente mientras rota, y si recibe otra orden de girar, lo que hacemos es parar los motores, y volver a ejecutar el rotateTo con el nuevo grado objetivo y en modo devolver control.

Otra cosa que ayuda a reducir el tiempo de procesamiento en el Kart es procesar la mayor parte posible de los datos en el mando antes de enviarlos, de manera que solo hagamos en el Kart lo que no podríamos hacer en el mando.

Ajustar el retardo en función de el tiempo de procesamiento es una tarea complicada, ya que físicamente es imposible medirlo, por lo que se consigue mediante prueba de ensayo y error.

El último punto es muy importante. Si enviamos datos irrelevantes, y el Kart gasta tiempo procesandolos, perdemos ese tiempo que podríamos estar usandolo para algo realmente necesario o importante. Por tanto el programa del mando se tiene que encargar de enviar información cuando sea estrictamente necesario. Por ejemplo ya habíamos visto que el hecho de enviar constantemente información de que uno de los tacómetros del mando marca 0 grados no tiene sentido. Se ha de mandar información cuando haya cambios relevantes en el mando, como que hallamos movido un motor más de X grados. Por supuesto esto puede crear imprecisión en el mando, por lo que debemos tener en cuenta en que casos nos interesa mayor fineza a la hora de manejar el robot, y que otros casos podemos prescindir de contar con tanta precisión.

En el programa del mando podéis ver como se envía información del giro con mayor o menor frecuencia dependiendo del grado al que queramos rotar (líneas 61 a 81).

Ajustando valores:

Un factor a tener en cuenta es la relación entre cuantos grados giremos los motores de nuestro mando, y cuanta aceleración o giro vamos a dar al Kart. El caso de girar la dirección es especialmente delicado, ya que necesitaremos máxima precisión para poder conducir sin chocarnos o salir constantemente de la pista. En este caso además tenemos que contar con que la dirección no puede girar más de un número determinado de grados o podría romperse. Por eso buscamos un límite de grados, y lo hacemos corresponder con el máximo de grados que queremos girar el volante de nuestro mandos.

Debido a las marchas reductoras la conversión entre giro de mando y de dirección no es exacta, pero lo importante es que el mando sea cómodo. Por eso un limite de 90 grados al girar el mando ya debería dar como resultado el giro máximo de la suspensión, y en un giro de entre 1 y 45 grados deberíamos poder manejar al kart para que realice la mayoría de curvas del circuito.

En el programa se puede ver como tenemos una mayor precisión para los giros más cortos (de la linea 61 a la 65), y está precisión va disminuyendo progresivamente cuanto más giremos el mando (líneas 66 a 81).

Por supuesto este escalado de precisión se debe aplicar también a la velocidad, como se ve en la línea 90, donde aplicamos un cubo para el cálculo de velocidad, lo que hará que los primeros grados tengan un control preciso de velocidades bajas, mientras que cuando giremos mucho el control el coche saldrá disparado.

Un mando manejable:

La forma física del mando es importante también. El kart se hacía muy difícil de manejar con el joystick, así que creamos un nuevo mando con el siguiente aspecto:

Como véis cuenta con un gatillo para acelerar, un pequeño volante para girar, y un botón de freno que usaremos en casos de emergencia. Es un modelo mejorable, pero es mucho más manejable. Uno de los problemas principales es su peso, pero éste es inherente a su naturaleza NXT.

Programa final:

El código a sido bastante modificado con respecto a del artículo anterior. Se han tratado de incluir las mejoras comentadas en los apartados anteriores, para mejorar sobretodo el control. Respecto a la parte física se ha cambiado la transmisión.

En conjunto se ha conseguido un retardo muy bajo de respuesta (entre 150 y 200 ms aprox), muy similar al que tienen los mandos de infrarrojos, así que en este apartado se ha conseguido alcanzar a Power Functions. El manejo es mucho más complejo, ya que nos permite girar los grados que queramos la dirección, y no un giro fijo como el que se consigue con el sistema de gomas usado por los otros karts en la competición. Respecto al peso sigue estando en desventaja, y es imposible mejorar este aspecto. Además al ser el coche cámara de la competición lo que aumenta su peso en más de 150 gramos, haciendo que fuera el único kart de la competición en superar el kilogramo de peso.

Aquí os dejo el código del mando:

import lejos.nxt.Button;
import lejos.nxt.LCD;
import lejos.nxt.Motor;
import lejos.nxt.SensorPort;
import lejos.nxt.TouchSensor;
import lejos.nxt.comm.BTConnection;
import lejos.nxt.comm.Bluetooth;
import java.io.*;
import javax.bluetooth.*;
import java.lang.Math;

LCD.clear();
LCD.drawString("Finalizado", 0, 1);
Thread.sleep(2000);
}
}

Y el del kart:

import lejos.nxt.Motor;
import lejos.robotics.navigation.Pilot;
import lejos.robotics.navigation.TachoPilot;
import lejos.nxt.Button;
import lejos.nxt.LCD;
import lejos.nxt.comm.BTConnection;
import lejos.nxt.comm.Bluetooth;
import java.io.*;
import java.lang.Math;

}else if (i > 800){
navigator.backward();
navigator.setMoveSpeed(Math.abs(i - 1000));
}else{
//Girar
Motor.B.stop();
boolean signo;
if (i >= 0)
signo = true;
else
signo = false;
if (Math.abs(i) < limite){
Motor.B.rotateTo(-i, true);
}else{
if (signo)
Motor.B.rotateTo(-limite, true);
else
Motor.B.rotateTo(limite, true);
}
}
}
}
Thread.sleep(2000);
LCD.clear();
LCD.drawString("Cerrando conexion", 0, 1);
dis.close();
btc.close();
Thread.sleep(2000);
}
}

Como podéis comprobar están los cambios comentados en el artículo, y el resultado ha sido bastante bueno. El único problema es que el manejo es algo complicado y se necesita práctica para conducirlo. Os recomiendo que miréis el artículo sobre la carrera. Finalmente deciros como siempre que si tenéis alguna duda podéis escribir vuestras dudas en el foro.

En el los artículos Control de tareas en RobotC y Control de prioridades de tareas en RobotC vimos como manejar tareas en RobotC. En este artículo vamos a ver el manejo de tareas en LeJOS. La mejor forma de manejar las tareas y sus prioridades en LeJOS es mediante la clase Arbitrator. Este método consiste en crear unas tareas denominadas comportamientos, no muy complejas, que en su conjunto crearán el programa que deseemos implementar.

Modelo de programacion basado en comportamientos:

Los programas que hemos escrito en nuestro robot presentan la apariencia habitual de un modelo de programacion estructurado. El flujo de ejecucion comienza en un punto y se van sucediendo instrucciones que modican los actuadores de nuestro robot. En artículos anteriores hemos aprendido a crear nuevos threads y permitir que haya varios flujos de ejecucion en paralelo. A medida que la dificultad de la tarea a realizar aumenta, el codigo se vuelve cada vez mas complejo y difícil de escalar.

Un modelo de programacion basado en comportamientos permite simplicar el diseño de nuestros programas. Ahora nuestro codigo estara compuesto de varios comportamientos. Los comportamientos son tasks (tareas) relativamente simples e independientes, es decir, no necesitan de otros comportamientos para su ejecucion: Avanzar, esquivar obstaculo, coger pelota, rotar 360 grados, encender leds, etc. Una vez definidos los comportamientos tendremos que establecer una política de activación de los mismos. Por ejemplo podríamos tener un automata de estados finitos que activara uno o varios comportamientos según las necesidades del robot.

Otra alternativa es utilizar un arbitro que se encargue de elegir el comportamiento mas adecuado para cada momento en funcion de algun criterio. LeJOS dispone de un paquete llamado lejos.subsumption que permite programar nuestra aplicacion bajo este paradigma. Cada uno de nuestros comportamientos debera escribirse en una clase Java e implementar el interfaz Behavior. Este interfaz obliga a implementar tres métodos:

public boolean takeControl(): Metodo que indicará si este comportamiento deberá activarse en este momento o no. Por ejemplo, si nuestro comportamiento se encarga de esquivar un obstaculo, su funcion takeControl() deberá devolver true cuando haya un obstaculo cerca del robot.

public void action(): Método que se ejecutará cuando se active el comportamiento.Por tanto deberá contener todas las instrucciones que desempeñaran la labor para la que ha sido creado el comportamiento.

public void suppress(): Metodo que se ejecutara cuando se desactive el comportamiento. Si es necesario devolver el robot a un determinado estado, aquí sera el sitio para hacerlo. Un comportamiento será desactivado cuando otro comportamiento tome el control en su lugar.

Clase Arbitrator y prioridades de los comportamientos:

Una vez creados nuestros comportamientos deberemos crear un objeto de tipo Arbitrator, que se encargará de activar y desactivar los comportamientos. El constructor de Arbitrator acepta como parametro un array de comportamientos (en el programa de ejemplo podéis como hacerlo). Todos estos comportamientos serán los candidatos a activarse durante la ejecución del programa.

Cuando se ejecute el método start() de nuestro objeto de tipo Arbitrator se pondrá en marcha el arbitro que activa la ejecucion de los comportamientos. La poltica que se utiliza es una poltica de prioridades (tasks con prioridades). Tienen mayor prioridad aquellos comportamientos cuyo índice del array sea mayor. El arbitro recorrera el array de comportamientos desde el final hasta el comportamiento que ocupe la posicion 0 y ejecutará el metodo takeControl() de cada comportamiento. Si alguno de esos metodos devuelve true, se ejecutará una iteracion de ese comportamiento llamando a su metodo action().

Este arbitro se encargará contnuamente de evaluar que comportamiento es el que hay que ejecutar. En caso de que otro comportamiento distinto al actual tenga que ser ejecutado, se llamará el método supress() del comportamiento actual y despues el método action() del nuevo comportamiento.

Programa de ejemplo:

Como programa de ejemplo hemos puesto un clásico, el Bump&Go. Es un ejemplo sencillo, así que podréis comprender mejor como funciona la clase Arbitrator. En este caso tenemos dos comportamientos: Avanza y Esquiva. Uno se encargará de ir en línea recta, y el otro de esquivar cuando detecte un obstáculo. Por último el Arbitro se encargará de gestionarlo todo.

Cada comportamiento va en una clase distinta, y el Arbitro también, por lo que tendremos tres archivos (con una clase cada uno). Uno será el de la clase Avanza:

import lejos.robotics.subsumption.*;
import lejos.nxt.*;

public void action() {
Motor.A.forward();
Motor.C.forward();
}
}

Otro el de la clase Esquiva:

import lejos.robotics.subsumption.*;
import lejos.nxt.*;

Motor.A.stop();
try{
Thread.sleep(500);
}catch(Exception e) {}
Motor.C.stop();
}
}

Y finalmente el de la clase Bump&Go, que es el arbitro:

import lejos.robotics.subsumption.*;

public static void main(String [] args) {
Behavior b1 = new Avanza();
Behavior b2 = new Esquiva();
Behavior [] bArray = {b1, b2};
Arbitrator arby = new Arbitrator(bArray);
arby.start();
}
}

Esta es una manera muy cómoda de gestionar tareas, amén de que facilita mucho la programación de programas complejos dividiéndolos en tareas. Si tenéis alguna duda, os recomiendo que os paséis por el foro y preguntéis.

Ya vimos cómo hacer una calculadora en RobotC, hoy queremos enseñaros a programar vuestra propia calculadora en NXT-G. Vamos a hacerlo de forma modular, es decir, haremos usos de “Mi bloque” para cada una de las funciones de la calculadora. Lo primero que debemos hacer es comprobar en cuántas funciones queremos dividir el trabajo, nosotros hemos utilizado 6.

Este es el programa completo

Como podéis ver leyendo los nombres de los bloques y con algún comentario adicional, podemos hacernos una idea muy clara de lo que hará nuestra calculadora.
Hay que tener en cuenta que, para que los bloques manejen la información correctamente, y sobre todo, sean capaces de intercambiar información unos con otros, debemos hacer que todas las variables utilizadas estén declaradas, no sólo dentro del bloque correspondiente, si no también en el programa principal, os recomiendo la lectura del tutorial de Variables y constantes.

Para poder hacer el programa lo más reutilizable posible, hemos separado 6 funciones:

NOTA: Dígito 2 sólo se pide si la operación lo requiere, por ejemplo x^2 no necesita dos dígitos.

Si la respuesta es afirmativa, volvemos al principio del bucle, reseteamos las variables y todo vuelve a empezar.

FACTORIAL

Para terminar, a las 8 operaciones que hemos puesto más arriba, hemos añadido una novena, la operación factorial, el factorial de un número entero positivo se define como el producto de todos los números naturales anteriores o iguales a él. Se escribe n! (NOTA: Por definición el factorial de 0 es 1: 0!=1)

Esta operación requiere, por tanto, un control previo del valor de Digito 1 que nos da el usuario, tendremos que comprobar:
- Si es 0, en cuyo caso devolvemos 1
- Si es <0, devolvemos 0 para indicar error (el factorial sólo está definido para valores positivos)
- Si es >0, calculamos el valor.

Para calcular el valor vamos a analizar la definición: 4!= 4*3*2*1 que es lo mismo que decir 4!= 1*2*3*4, ya que el orden de los factores no altera el producto.
Esto nos permite usar el contador interno del bucle para realizar las operaciones, multiplicando el resultado de la iteración previa por el contador +1 – el contador del bucle empieza en 0, al sumarle uno forzamos que la primera multiplicación sea Ant*1-

Este es el programa del factorial (está dentro de CalcOpera, es la operación 9)

Como podéis ver, hemos dado una vuelta de tuerca a las tradicionales calculadoras con sólo 4 operaciones, añadiendo otras muy comunes, que en algún caso son algo más difíciles de implementar, pero que esperamos hayan quedado claras.

Cualquier duda, como siempre, en el foro.

• English

Tras una buena cantidad de artículos sobre visión artificial llega por fin el esperado sigue líneas con visión. Las dificultades que implica el manejo de imágenes en tiempo real son muchas, sobre todo el retardo entre que la cámara capta la imagen y nosotros la procesamos y enviamos los datos por bluetooth. Estamos utilizando la cámara de un iPhone 3G conectada mediante wifi al ordenador, enviado imágenes gracias al programa Pocket Cam. Capturamos imágenes periódicamente gracias al programa Yawcam, y las procesamos con LabVIEW, que finalmente enviará las ordenes necesarias al NXT mediante Bluetooth.

Funcionalidades que hemos usado:

Si no estáis familiarizados con el LabVIEW os recomiendo que os leáis los artículos de la serie de LabVIEW, sobretodo LabVIEW para usuarios del NXT (I), (II) y (III), así como Manejo de imagenes y shift register en LabVIEW.

El uso de los shift register es fundamental para este programa, pues lo necesitamos para ser capaces de detectar lineas. Así mismo lo son el uso de bucles, sentencias case, manejo de imágenes, etc… Necesitaremos hacer uso de múltiples variables de distintos tipos para ir guardando valores que necesitaremos posteriormente.

Proceso de captura de imágenes:

El proceso de captura de las imágenes tiene varios pasos. En primer lugar necesitamos capturar imágenes con el Iphone. Mediante el programa Pocket Cam podemos capturar imágenes cada segundo por la cámara del Iphone, y enviarlas por wifi al ordenador. A su vez tenemos otro programa actuando en el PC denominado YawCam, que se encarga de recoger estas imágenes enviadas por el Iphone por wifi, y guardarlas en el disco duro (es capaz de hacerlo a varias imágenes por segundo, aunque debido a la limitación del Pocket Cam del Iphone de una imagen por segundo estamos limitados a esa velocidad máxima).

Una vez en disco ya podemos procesarla con LabVIEW, para esto tenemos toda la funcionalidad que explique en Manejo de imagenes y shift register en LabVIEW.

Procesado de la imagen:

Una vez tenemos la imagen ya podemos procesarla. Lo primero es abrirla y usar la función unbound de clusters para poder acceder al array donde se encuentran los datos de la imagen. Recorreremos una de las líneas de la imagen, preferiblemente una intermedia, en busca de la línea negra. Tendremos que escoger un valor RGB umbral para decidir que es negro (línea) y que es blanco. Con que todos los valores estén por debajo de 60 es suficiente. Recordar que no hay que iluminar la línea negra desde arriba o creará reflejo. Buscaremos en la linea píxeles negros que estén por debajo del umbral. Para que no detectemos un píxel aislado como parte de la línea es importante que busquemos secuencias de varios píxeles negros. Si por ejemplo detectamos 6 píxeles negros seguidos sabremos que estamos ya sobre la línea.

Una vez que estamos sobre dicha línea seguimos buscando píxeles hasta que detectemos el otro borde. Tenemos que guardar tanto el número del primer píxel como el del último píxel de la línea para calcular el punto medio. Sabiendo ya este punto medio, tenemos que ver su distancia con el centro de la imagen, cuanto más lejos estemos del centro, más nos estamos desviando de la línea. Que la diferencia entre el punto medio calculado y el centro de la imagen sea positivo o negativo indica hacia que lado nos estamos desviando (derecha o izquierda), y tendremos que actuar en consecuencia, poniendo en funcionamiento unos u otros motores.

Este proceso se mete dentro de un bucle infinito, al que podremos poner algún botón de control para pararlo. Mientras el bucle siga en marcha seguiremos recorriendo la imagen y actuando en consecuencia.

Programa:

El programa es bastante largo, en el hemos usado toda la funcionalidad descrita en anteriores artículos, como bucles, sentencias case. shift registers, uso de variables… El programa sigue básicamente el proceso descrito anteriormente. Aquí podéis ver el Block Diagram:

Y el Front Panel:

Debido al gran retardo entre que la imagen se captura en el Iphone, y el robot actúa en consecuencia el robot no es perfecto, y se necesita mover bastante lento para no salirse de la línea. Lo importante es que es capaz de seguirla. Aquí tenéis un vídeo del experimento:

Espero que os haya gustado, ha sido difícil de implementar, pero ha merecido la pena. Para cualquier pregunta no dudéis en visitar el foro.

• English

El objetivo de este artículo es realizar un vehículo controlado remotamente por bluetooth mediante LeJOS. La novedad de este proyecto es que es el primero que realizamos cuya tracción no es diferencial (como los anteriores).

Mientras que los vehículos con tracción diferencial como el tribot son capaces de cambiar su dirección ajustando la velocidad de los motores, este vehículo cuenta con un motor que se encarga exclusivamente de la dirección ya que los otros dos se encargarán exclusivamente de dar potencia (para dar tracción emplearemos dos motores en lugar de uno solo).

Como mando usaremos el joystick que ya hemos empleado en otros artículos, que se comunicará con nuestro kart mediante bluetooth. Cada vez que haya una diferencia significativa en los tacómetros de los motores del joystick (lo que significará que hemos movido el joystick), este enviará una señal al kart para que gire la dirección, o acelere, según el eje del joystick que hayamos movido.

Comunicación Bluetooth en LeJOS:

En primer lugar os recomiendo que os leáis el artículo Manejo de Bluetooth en LeJOS en el que se explica como comunicar dos NXT mediante bluetooth para enviar cualquier tipo de información. En este caso lo que enviaremos serán datos del valor de los tacómetros de los motores del joystick, los cuales nos indican la cantidad de de grados que queremos girar, o cuanto aumentar la velocidad.

El envío de los datos entre los NXT se hace mediante un buffer, una especie de túnel en el que un NXT va metiendo datos por un lado y el otro los recoge por el otro lado. Es posible que la comunicación no desarrolle como queramos debido a diversos factores. Uno de los más comunes es que el NXT que envía información lo haga más rápido que el tiempo que tarda el NXT que la recibe en procesarla. Esto crea un problema serio, ya que el buffer se irá llenando de información, y llegará un momento que no pueda meter más y se empiecen a perder datos. Además como el receptor recibe más datos de los que tiene tiempo de procesar, se generará un retardo que irá en aumento, traduciéndose en un comportamiento no deseado.

Este es nuestro vehículo:

Control del Kart:

El control de la velocidad del Kart esta manejado por la clase navigator de LeJOS (que nos asegura que los dos motores A y C, que se encargan de la velocidad del Kart, se muevan a la misma velocidad). El control no es directo, sino que tiene velocidad aumentada gracias a un sistema de engranajes. La velocidad del kart se basa en el giro que experimenta el joystick en uno de sus ejes (el controlado por el motor A).

Detalle de los motores de tracción:

El control de la dirección es directo desde el motor B del NXT. Dado que existe una limitación mecánica del angulo máximo de giro, el programa debe tenerla en cuenta para evitar que el motor intente girar más de lo que mecánicamente es posible, bloqueándose. El ángulo girado pretende seguir al giro que experimenta el joystick en uno de sus ejes (el controlado por el motor B).

Detalle del sistema de dirección:

Programa:

La implementación consiste en dos programas, uno para el kart y otro para el joystick. Ambos programas se comunicarán mediante bluetooth por un buffer. El joystick será el encargado de enviarle cuantos grados ha girado en sus ejes, y el kart el encargado de recibir dicha información, procesarla, y transformarla en movimiento.

Los primeros experimentos que hicimos intentando controlar la dirección no daban el resultado que pretendíamos. Esto era debido a que estábamos enviando una gran cantidad de datos por el buffer, y el kart no era capaz de procesarlos a la velocidad suficiente, lo que creaba un retardo cada vez mayor entre el movimiento del joystick y la respuesta del kart. Por eso hemos hecho un método en el que el joystick solo envía información cada cierto tiempo, y si la posición del joystick a cambiado, por lo que no estará enviando datos todo el rato aunque el joystick esté quieto.

También se han resuelto otros problemas como el de la transmisión comentado anteriormente, y se han hecho procesamientos con los datos para que el control fuera más sencillo. Aún así los programas son aún mejorables, y los modificaremos para reducir problemas como el del retardo, y para finalmente poder participar en la competición de karts de la semana que viene con el único kart controlado remotamente hecho en exclusiva con NXT.

Aquí os dejo el código del mando:

import lejos.nxt.Button;
import lejos.nxt.LCD;
import lejos.nxt.Motor;
import lejos.nxt.comm.BTConnection;
import lejos.nxt.comm.Bluetooth;
import java.io.*;
import javax.bluetooth.*;

LCD.clear();
LCD.drawString("Finalizado", 0, 1);
Thread.sleep(2000);
}
}

Y el del kart:

import lejos.nxt.Motor;
import lejos.robotics.navigation.Pilot;
import lejos.robotics.navigation.TachoPilot;
import lejos.nxt.Button;
import lejos.nxt.LCD;
import lejos.nxt.comm.BTConnection;
import lejos.nxt.comm.Bluetooth;
import java.io.*;
import java.lang.Math;

while(!Button.ESCAPE.isPressed()){
int i = dis.readInt();
if (i > 1000){
//Acelerar
navigator.backward();
navigator.setMoveSpeed((i - 1000)/2);
}else if (i > 800){
navigator.forward();
navigator.setMoveSpeed(Math.abs(i - 1000)/2);
}else{
//Girar
boolean signo;
if (i >= 0)
signo = true;
else
signo = false;
i = i/10;
i = i*i;
if (i < 40){
if (signo)
Motor.B.rotateTo(-i);
else
Motor.B.rotateTo(i);
}else{
if (signo)
Motor.B.rotateTo(-40);
else
Motor.B.rotateTo(40);
}
}
}
Thread.sleep(2000);
LCD.clear();
LCD.drawString("Cerrando conexion", 0, 1);
dis.close();
btc.close();
Thread.sleep(2000);
}
}

Aquí tenéis un vídeo del funcionamiento

Son códigos de cierta complejidad, así que si tenéis alguna duda podéis preguntarnos en el foro.

• English

En el artículo anterior de RobotC vimos cómo manejar varias tareas, gestionando el uso de recursos compartidos como los motores. En este artículo ampliaré la información sobre el manejo de tareas, viendo cómo poner mayor o menor prioridad a una tarea, y el efecto que tiene sobre la ejecución del programa. También veremos en qué consiste la planificación de tareas Round Robin y al final pondré un par de programas de prueba con vídeos incluidos.

¿Que significa prioridad?:

A la hora de iniciar una tarea en RobotC podemos asignarle una prioridad. Esta prioridad tiene un valor numérico que va del 0 al 255. Cuando una tarea se está ejecutando en la CPU el resto de tareas están esperando a que la deje libre. La tarea que tendrá el control de la CPU después de que la tarea que la estaba utilizando la deje libre será la que mayor prioridad tenga. Esto significa que las tareas que tengan mayor prioridad se ejecutarán antes que las demás que estén esperando.

RobotC usa planificación Round Robin para asignar tiempo de CPU a cada tarea.

Planificación Round-robin:

Round robin es un método para seleccionar todos los elementos en un grupo de manera equitativa y en un orden racional, normalmente comenzando por el primer elemento de la lista hasta llegar al último y empezando de nuevo desde el primer elemento. El planeamiento Round Robin es tan simple como fácil de implementar, y está libre de inanición (significa que ningún proceso esperará durante demasiado tiempo a que le den tiempo de CPU).

Round Robin asigna a cada proceso una porción de tiempo equitativa y ordenada, por lo que ningún proceso tendrá mayor tiempo de ejecución que los demás. Normalmente Round Robin trata a todos los procesos con la misma prioridad, aunque en caso de RobotC podemos aplicar prioridades, que solo afectarán en el orden en que entren a CPU las tareas que estén esperando, pero nunca en el tiempo de CPU que se les asigne.

Tareas con prioridad en Robotc:

En RobotC se le puede asignar una prioridad a una tarea al iniciarla. Esta prioridad debe estar entre el 0 y el 255. A mayor prioridad antes se ejecutará dicha tarea. Para asignar prioridad a una tarea al iniciarla se usa la función:

StartTaskWithPriority(nombre_tarea, prioridad): Inicia una tarea con la prioridad que hayamos escogido.

Hay que tener en cuenta que la prioridad no será algo perceptible, ya que la asignación de CPUs a tareas se hace muy rápido, pero sin embargo tiene utilidad a la hora de programar, ya que nos aseguramos que ciertas tareas se ejecuten antes que otras mientras ambas estén esperando.

Programa de prueba:

Un programa bastante sencillo para probar que en efecto todas las tareas reciben el mismo tiempo de CPU es el siguiente: se crean cuatro tareas, cada una de ellas se encarga de aumentar un contador y mostrar su número por pantalla. Si todas las tareas tuvieran el mismo tiempo de CPU los números deberían avanzar a la vez.

El código es el siguiente:

int cont1 = 0, cont2 = 0, cont3 = 0, cont4 = 0;

task main()
{
StartTaskWithPriority(tarea1, 250);
StartTaskWithPriority(tarea2, 150);
StartTaskWithPriority(tarea3, 100);
StartTaskWithPriority(tarea4, 25);
while(true)
{
wait1Msec(300);
}
return;
}

Y aquí os pongo un video de su funcionamiento:

También se puede hacer una pequeñas variación, cambiando los retardos dentro de cada tarea para que sean proporcionales. Si por ejemplo ponemos a una tarea el doble de retardo que otra, está cambiará el contador a la mitad de velocidad. Aquí está un código de ejemplo:

int cont1 = 0, cont2 = 0, cont3 = 0, cont4 = 0;

task main()
{
StartTaskWithPriority(tarea1, 250);
StartTaskWithPriority(tarea2, 150);
StartTaskWithPriority(tarea3, 100);
StartTaskWithPriority(tarea4, 25);
while(true)
{
wait1Msec(300);
}
return;
}

Y el vídeo:

En este caso la diferente espera interna de cada tarea produce que los contadores crezcan de forma inversamente proporcional, de ahí que exista una diferencia de velocidades de 1 a 8 entre la tarea 1 y la 4, la misma relación inversa que sus retardos. En este caso la prioridad de cada una de las tareas no afecta para nada al resultado: sabemos que cada vez que se han ejecutado las 4 tareas siempre ha sido la tarea 1 la primera de ellas, a continuación la 2, la 3 y finalmente la 4, debido a la siguiente parte del código:


StartTaskWithPriority(tarea1, 250);
StartTaskWithPriority(tarea2, 150);
StartTaskWithPriority(tarea3, 100);
StartTaskWithPriority(tarea4, 25);


En esta pequeña aplicación no ha afectado para nada la prioridad de ejecución, pero puede que en otra aplicación sí sea necesario el uso de prioridades.

Espero que os haya resultado interesante. Ya sabéis, ante cualquier duda estamos en el foro.

• English

El objetivo principal del procesador es ejecutar la secuencia de instrucciones de los programas de entre un posible conjunto de programas. Cuando es uno sólo el programa a ejecutar, podemos intuir fácilmente cuál es la secuencia de operaciones que se está ejecutando sin más que seguir la traza del proceso en curso. La ayuda de los entornos de programación puede ser de valor incalculable cuando nuestra aplicación se complica y son varios los procesos que deben ser procesados.

En un caso monoprocesador la programación concurrente está relacionada con la forma en la que se decide cuál es el orden de ejecución y de interacción de las tareas a ejecutar, cuánto tiempo de procesador se asigna a cada uno de dichos procesos, o cuál debe ser la forma de acceso a los recursos compartidos.

La forma de conseguir que un sistema con un único procesador que sólo puede ejecutar una instrucción simultáneamente parezca que está ejecutando varios programas a la vez es intercalando en el tiempo su ejecución.

Sabemos que podemos seguir el comportamiento que tiene el procesador a través de la información que tenemos de la traza: cuando hay varias tareas en ejecución las instrucciones de cada una de ellas se irán intercalando dependiendo de la política que exista de la asignación de recursos. ¿Tenemos algún tipo de control sobre la forma en que se ejecutan dichos procesos? ¿Cómo debemos escribir nuestro código para ejecutar varias tareas en paralelo, para que una de ellas tenga una mayor prioridad de uso de tiempo de procesador, o simplemente capture al completo al procesador en determinados momentos?

Control de tareas en RobotC:

En RobotC es posible crear tareas para que se ejecuten simultáneamente. Ya he usado tareas en algún otro artículo como el de Manejo de Bluetooth en RobotC, donde una tarea se encargaba de recibir mensajes y otra de mandarlos. En este artículo ahondaremos sobre el tema, explicando diversas funciones.

Para definir una tarea en RobotC se usa la palabra reservada task, seguida del nombre que queramos darle a la tarea, y entre corchetes el código que queremos que ejecute dicha tarea. Por ejemplo:

task HolaMundo()
{
nxtDisplayCenteredTextLine(3, "Hola Mundo");
}

Siempre tiene que haber una tarea principal denominada task main(), desde la que lanzaremos y controlaremos a las demás. Esta tarea principal se iniciará automáticamente cuando empiece el programa, y en ella es donde debemos iniciar el resto de tareas. Para iniciar las tareas necesitamos utilizar la función StartTask:

StartTask(nombre_tarea): Inicia la tarea especificada.

Podemos detener una tarea en cualquier momento con la función:

StopTask(nombre_tarea): Detiene la tarea especificada, matándola.

También se pueden detener todas las tareas de golpe con las funcion:

StopAllTasks(): Detiene todas las tareas.

Existe una función que permite que la tarea que se está ejecutando en este momento hago uso de todo el tiempo de CPU. Esta función es:

hogCPU(): Suspende todas las tareas excepto la actual, dandole por tanto todo el tiempo de CPU a esta tarea.

Esta función tiene la utilidad de poderle dar a una tarea toda la potencia de la CPU cuando queramos. Por desgracia no funciona del todo bien, y no permite por ejemplo un correcto control de motores si tenemos otra tarea que ya los está manejando. Es importante que luego, una vez terminado lo que deseamos hacer, volvamos a reiniciar los procesos que hemos suspendido. Para ello utilizaremos la función:

releaseCPU(): Reinicia las tareas suspendidas (el scheduler) con la función hogCPU.

De momento no veremos más funciones para no complicar las cosa.

Bump&Go con control de tareas:

El Bump&Go es un programa en el que el robot se mueve aleatoriamente por una habitación esquivando los obstáculos que detecta a su paso. Ya vimos cómo programarlo en RobotC en el artículo Bump&Go en RobotC. En este caso lo vamos a implementar con multitasking (multitareas). Puesto que es un programa sencillo no necesitaremos muchas tareas. Necesitamos lo siguiente:

• Una tarea principal que se encargue de controlar a las otras,
• una tarea que se encargue de mover al robot en línea recta y, por último,
• una tarea que se encargue de esquivar los obstáculos cuando el robot los detecte.

Puesto que tanto la tarea de mover el robot como la de esquivar obstáculos hacen uso de un recurso compartido (los motores) no podemos dejar que se ejecuten a la vez, o interferirían entre sí. Por tanto una vez detectemos el obstáculo pararemos un momento la tarea de moverse en línea recta, y una vez hayamos esquivado el obstáculo la volveremos a poner en marcha.

El código del programa es el siguiente:

#pragma config(Sensor,S4,contacto,sensorTouch)
#pragma config(Motor,motorA,motor_der,tmotorNormal,PIDControl,encoder)
#pragma config(Motor,motorC,motor_izq,tmotorNormal, PIDControl, encoder)
//*!Code automatically generated by 'ROBOTC' configuration wizard!*/

task main()
{
StartTask(moverRobot);
StartTask(controlChoques);
while(true)
{
wait1Msec(300);
nxtDisplayCenteredTextLine(0, "PRINCIPAL");
}
return;
}

Y aquí una breve explicación de algunas líneas:

1 a 3 – Definimos los sensores y motores

6 a 19 – Esta función se encarga de esquivar obstáculos

22 - Aquí empieza la tarea mover robot. Las tareas han de ser declaradas antes de ser utilizadas por otras tareas como la main, por eso task main será la ultima que escribamos.

24 - Bucle infinito

25 – Un pequeño retardo que nos asegura que la tarea anterior haya terminado. Importante ponerlo antes de hacer nada.

26 a 29 - Decimos que se está moviendo, borrando otros mensajes, y ponemos los motores en marcha a la misma potencia.

37 - Dentro de la tarea control de choques solo actuaremos si el sensor de contacto esta presionado.

38 - Antes de manejar detendremos la otra tarea que controla los motores.

39 – Esquivamos el obstáculo.

40 – Y volvemos a poner en marcha al robot.

49 y 50 – En la tarea principal (task main) iniciamos las otras dos tareas.

54 - Dentro de un bucle infinito mostramos por pantalla que la tarea principal esta activa. Si se terminara esta tarea se acabaría el programa, por lo que siempre la necesitamos tener activa (en ejecución o en espera).

Espero que os haya quedado claro. En cualquier caso si tenéis alguna duda podéis consultarnos en nuestro foro.

Hoy queremos presentar un pequeño experimento realizado por nuestros alumnos en uno de nuestros talleres de robótica. Se trata de un robot que utiliza dos ladrillos NXT que se comunican entre sí mediante bluetooth. Este experimento nos permitirá explorar aún más las posibilidades de interacción bluetooth entre ladrillos, fundamental para controles remotos (como ya hemos visto en varios artículos). Pero también para robots que tengan más de un NXT.

Para poder hacer esto tenemos que ser capaces de controlar cuándo y cómo actuamos con cada NXT. Para eso utilizamos un sistema de intercambio de flags entre ladrillos. Para que nos sea más fácil identificarlos, durante el artículos los llamaremos NXT-M (NXT- Master) y NXT-S (NXT-Slave).

Cada uno de los procesadores se encarga de unas tareas a realizar. El Master es el encargado de controlar la tracción del vehículo, mientras que al Slave se le conectan los motores de la pinza, por lo que debe controlar sus movimientos. Cada uno de ellos necesita su programa independiente.

El siguiente es el programa de NXT-M (controla la tracción del vehículo).

Este programa es muy fácil de seguir: nos movemos en línea recta hasta que detectamos un objeto, giramos para encararnos al objeto con las pinzas y enviamos a NXT-S el flag a True, indicándole que ya empieza su parte (1) seguimos avanzando hasta que recibimos el flag False desde NXT-S (2). Ahora nos mantendremos quietos hasta recibir flag True (3) y giraremos de nuevo para soltar el objeto, para lo cual mandaremos a NXT-S flag False (4).

Y este el del ladrillo esclavo (controla los movimientos de la pinza)

Este es aún más sencillo, ya que sólo controlaremos la pinza. Esperamos la señal de NXT-M – marcada como (1) en la explicación anterior- Enviamos flag False a NXT-M (2). Cerramos las pinzas y levantamos el objeto. Enviamos flag True (3) y esperamos la señal desde NXT-M (4). Finalmente liberamos el objeto.

Como se puede observar ambos ladrillos tienen esperas o realizan acciones hasta un cambio en el flag, dicho cambio es enviado por bluetooth desde el otro ladrillo.

Es muy importante tener en cuenta que, para que el ladrillo esclavo pueda comunicarse con el maestro, debe enviar los mensajes siempre a la conexión 0. Sin embargo, el ladrillo maestro deberá enviarlos a la conexión que tenga ocupada (1, 2 o 3).

Os ponemos un vídeo para que lo veáis en funcionamiento.

• English

En esta tercera entrega de los artículos tutoriales sobre LabVIEW vamos a ver nuevos sensores, como el de ultrasonido, nuevas estructuras, y otros métodos para usar los motores. Esto nos servirá para ampliar los conocimientos que ya tenemos y así poder crear programas más complejos.

Manejo de Motores:

Hemos visto como poner los motores en funcionamiento o pararlos, pero sin embargo a veces queremos que recorran cierta distancia (que giren un número de grados determinados). Para ello existe esta función:

Drive distance

Gira el motor x grados, donde x es el valor que especifiquemos en distancia. En Output Port debemos indicar a que puerto esta conectado el motor/motores que queremos girar.

Esta función la podemos encontrar haciendo click derecho en el Block Diagram y metiéndonos en NXT I/O → Complete → Motor → Drive Distance.

Manejo de Sensores:

En el artículo anterior vimos como poner un sensor, seleccionar su tipo, y vimos el funcionamiento del sensor de contacto y de luz. En este artículo introduciré el sensor de ultrasonido y el sensor de rotación:

Sensor de ultrasonido

El sensor de ultrasonido devuelve la distancia al obstáculo más próximo que tenga enfrente medida en cm. Hay que indicar a que puerto de sensores está conectado (preferiblemente el 4 ya que es el puerto rápido). La posibilidad de medir distancias abre muchas posibilidades, nos permite que el robot navegue por un entorno sin chocar con obstáculos por ejemplo, o también nos sirve para saber como de cerca estamos de nuestro objetivo.

Sensor de rotación

El sensor de rotación mide la cantidad de grados que hemos recorrido desde que iniciamos el programa. Esto sirve básicamente para saber la distancia recorrida, y compararla por ejemplo con la que nosotros queriamos que recorriera. No hay que especificar puerto de sensores, sino de motores, ya que el sensor de rotación se encuentra dentro de los motores.

Estructura Case:

La estructura case es una estructura condicional que nos permite ejecutar una parte u otra del código según que valor tome determinada variable o elemento de nuestro programa. La estructura case la podéis encontrar en Structures → Case Structure:

En este caso vamos a utilizar su variante más simple, que usarla como una estructura if. Lo que le metemos es una valor booleano, en caso de que valga True ejecutará una parte del programa, y en caso de que sea False otra. Para escribir en una parte u otra tenemos que clickear en la pestaña superior para que se nos abra el menú desplegable:

Hay muchas cosas que devuelven valores booleanos, como el sensor de contacto, o todas las comparaciones que podéis encontrar en Comparison (igual, menor que. mayor que…).

Programa de prueba:

En el programa de hoy vamos a utilizar todo lo que hemos visto hoy más lo que vimos en el anterior tutorial. El programa va a consistir en un robot móvil que se desplaza gracias a dos motores (A y C). El robot cuenta con un sensor de ultrasonidos, y cuando este detecte un obstáculo a menos de 40 cm. el robot se parará instantáneamente y girará para esquivar el supuesto obstáculo. Una vez termine esta maniobra seguirá adelante hasta que detecte otro obstáculo. El robot se detendrá cuando su motor A haya recorrido más de 6000º.

Por tanto para este programa necesitamos un bucle while, un case que ejecute cosas diferentes dependiendo del valor del sensor de ultrasonidos, un sensor de ultrasonidos, un sensor de rotación, y manejo de motores, tanto para moverlos y frenarlos, como para decirles que recorran una distancia determinada. El Block Diagram es el siguiente:

En caso de que haya un obstáculo a menos de 40cm.:

En caso de que no haya nada a menos de 40cm.:

Espero que os animéis a intentar programar cosas con LabVIEW ya que es sencillo de manejar y tiene muchas más posibilidades que NXT-G. Ante cualquier duda podéis preguntar en el foro.

• English

Uno de los problemas que tienen cualquier sistema que tenga que desplazarse, y en particular un robot NXT móvil, es la deriva en la navegación. La deriva es el desvío de la trayectoria real respecto de la trayectoria prevista, y se debe a diversos factores. Cuanto menos deriva tenga un robot más preciso será su desplazamiento y menos se desviará de su destino objetivo al finalizar el movimiento. Este problema es muy común con los LEGO Mindstorms NXT debido a que no son robots con una forma única, sino que hay muchos montajes diferentes de robots móviles. La forma en que estén implementados los programas también influye en esta deriva.

Cosas que influyen en la deriva:

En el aspecto físico del robot hay muchas cosas que influyen en la deriva. Influye por ejemplo la diferencia de tamaño entre las ruedas, aunque está sea mínima porque una está mas hinchada que otra. Influye el peso del robot en gran medida, y por supuesto el cómo está distribuido este peso. Es importante que el mayor peso posible se encuentre sobre las ruedas tractoras, lo que impedirá que el robot se desvíe de su camino porque le pese demasiado la parte de delante o de atrás:

Influye la solidez del vehículo, que no modifique su forma mientras se va desplazando, su simetría. Otro aspecto importante es que no tenga rozamiento con nada, ya que el mínimo rozamiento podría crear una modificación de la trayectoria. La velocidad es bastante importante también, un vehículo que se desplace rápido es mucho más difícil de controlar que uno que lo haga lentamente.

La parte de implementación es también muy importante, por ejemplo si está usando dos motores para desplazarse, ambos deben ir con la misma potencia y velocidad. También es importante que a la hora de arrancar lo hagan simultáneamente, o el robot comenzará a moverse ya desviado de la trayectoria. Así mismo es importante que se detengan simultáneamente cuando el robot tenga que parar.

A pesar de todas estas precauciones es difícil mantener determinada trayectoria de forma continuada. Por ejemplo es imposible mantener a un robot realizando desplazamientos en forma de cuadrado de manera indefinida, y que siempre vuelva al mismo punto de partida, lo que pasará es que en cada vuelta el robot se desviará más y más hasta que ya nunca pase por su posición inicial.

Clase Pilot, la mayor precisión:

Una de las maneras de alcanzar una precisión muy alta a la hora de desplazar el robot es mediante la clase Pilot de LeJOS. Esta clase, que ya introduje en el artículo Manejo de motores avanzado: clase Pilot, introduce una nueva forma de manejar el robot. Lo primero que se hace es configurar un objeto de esa clase indicando que motores vamos a utilizar (dos motores, ya que esta clase esta solo diseñada para tribots), que distancia hay entre los puntos medios de las ruedas, y el diámetro de la rueda:

Pilot navegador = new TachoPilot(diametro_ruedas, distancia_ruedas, Motor.A, Motor.C);

Aunque las ruedas de los NXT tiene un diámetro de 5.6 cm es importante que pongáis un poco menos, sobre todo si vuestro robot pesa mucho, ya que el peso hace que las ruedas se aplanen un poco. La distancia entre las ruedas debe ser bastante precisa, ya que es de vital importancia sobre todo a la hora de las rotaciones.

A los métodos ya comentados en el artículo sobre la clase Pilot es importante añadir:

void setMoveSpeed(float distancia): Establece la velocidad del robot a la distancia que pongamos por segundo. Por ejemplo si ponemos 5, se moverá a 5 cm por segundo (que seán cm, pulgadas o una medida distinta solo depende de que tipo de medida hayamos usado para configurar el Pilot).

void setTurnSpeed(float grados): Establece la velocidad del robot, pero en este caso es en grados por segundo. Si ponemos 360 las ruedas realizarán una rotación completa por segundo.

Es importante controlar la velocidad, ya que si vemos que nuestro robot no es capaz de moverse con precisión a cierta velocidad deberíamos reducirsela. Otro método útil es:

void steer(float velocidad_giro, float angulo, boolean devolverControl): El robot se mueve en una trayectoria curva a la velocidad de giro indicada hasta que complete el número de ángulos deseado. Si devolver control es True el robot seguirá ejecutando las siguientes líneas de código mientras gira. No hace falta indicarle un angulo, si omitimos este campo el robot girará indefinidamente, o hasta que lo detengamos con otra instrucción.

Programa de prueba:

Para probar la precisión de la clase Pilot he creado un programa que describe un gran rectángulo de 240 cm. Cuanto más cerca quede el robot de la posición inicial más preciso será el programa. Además contamos con un montaje simétrico, relativamente ligero, y con la mayoría del peso sobre las ruedas tractoras. La rueda trasera no es la mejor posible, pero hace bien su función. El programa es el siguiente:

public class figuras {

}

Aquí tenéis el vídeo demostrativo del programa, en el podéis ver que la deriva es mínima (apenas un centímetro), habiendo recorrido 240 cm. y realizado tres rotaciones de 90º:

Ante cualquier duda podéis preguntar en el foro.

• English

En el artículo LabVIEW para usuarios del NXT (I) vimos como crear un VI, y empezamos con un programa de prueba (el famoso “Hola Mundo”). En el artículo de hoy vamos a ahondar un poco más en el manejo básico de LabVIEW, y ver manejo de motores y de algún sensor.

Manejo de Motores:

Para manejar el motor la función que debemos usar es Motor, que la podéis encontrar haciendo click derecho en el Block Diagram y seleccionando NXT I/O → Motor:

Una vez coloquemos nuestro motor podemos observar que tiene varios modos de funcionamiento con distintas entradas y salidas. Para cambiar entre estos modos tenemos que clickear en el menú desplegable. Los modos son los siguientes:

Motor On: Forward

Hace que los motores se muevan marcha adelante con la potencia que escojamos. En Output Port escogemos el Puerto (Port A, Port B, Port C o todos), en Power la potencia deseada, y los demás conectores son para el flujo del programa como ya vimos en el artículo anterior.

Motor On: Reverse

Funciona de manera parecida al anterior, solo que con los motores marcha atrás.

Motor Off: Brake

El motor frena, tratando de detenerse lo más rápido posible. En Port elegimos el puerto del motor que deseamos que frene.

Motor Off: Coast

El motor deja de acelerar, volviendo poco a poco a la inmovilidad. No es un frenazo brusco, por lo que se seguirá desplazando hasta detenerse. Igual que en el anterior elegimos el puerto del motor.

A la hora de elegir a que puertos están conectados, o con que potencia van a moverse, tenemos que enganchar los valores deseados a las entradas (ya sea mediante constantes, controles….). La manera más cómoda de hacerlo es creando estas constantes, controladores o indicadores ya enganchados al las salidas y entradas. Para ello haced click derecho en la entrada o salida deseada y seleccionad Create y lo que queráis enganchar:

Manejo de Sensores:

Para manejar los sensores utilizamos la función Sensor, que la podéis encontrar haciendo click derecho en el Block Diagram y seleccionando NXT I/O → Sensor. En este caso tenemos muchos sensores distintos disponibles, aunque no vamos a ver todos aquí. De momento me centraré en los dos más simples, el de contacto y el de luz.

Contacto: Pressed

Nos devuelve si el sensor de contacto está presionado o no (es un valor booleano). Tenemos que decirle a que puerto de sensores está conectado (Port 1, Port 2, Port 3 o Port 4).

Luz: Luz encendida

El sensor de luz nos devuelve un valor que representa la cantidad de luz ambiente que detecta. En este caso el sensor enciende una pequeña luz que le sirve para ver mejor, reflectando esta luz contra objetos cercanos por ejemplo, lo que sirve para distinguir colores. Hay que decir a que puerto está conectado.

Luz: Luz apagada

De funcionamiento parecido al anterior esta vez actúa con su luz apagada, lo cual nos sirve para detectar luz ambiente, y saber por ejemplo que parte de una habitación está más iluminada (ya que al no tener el sensor su luz encendida, esta no interfiere en los valores que capta). Sin embargo este modo no sirve para distinguir colores.

Bucles While:

Un bucle es una estructura en la que continuamente se repite lo que haya dentro hasta que se cumpla una condición de salida que elegimos nosotros. Esta condición de salida tiene que devolver un valor booleano (verdadero o falso), como el que devuelve el sensor de contacto. Los búcles While los podéis encontrar en Structures → While Loop:

Veréis un ejemplo sencillo de su uso en el programa de prueba que pongo a continuación.

Programa de prueba:

Vamos ha hacer un pequeño programa en el que usaremos un par de motores y un sensor de luz. El programa consistirá en un robot que va girando mientras toma valores con el sensor de luz y los muestra por el Display del NXT. El programa terminará cuando presionemos el sensor de contacto Para que un robot gire un motor ha de moverse más rápido que el otro, esto se consigue aumentando la potencia de uno de los dos. En este caso vamos a tener un robot con los motores A y C, y le daremos mayor potencia al motor A.

Para que se repita la lectura del sensor de luz, y el display del valor en la pantalla del NXT, es necesario meter todo esto en un bucle (while en este caso). Como condición de salida del bucle pondremos que el sensor de contacto esté presionado, de manera que el programa terminará su ejecución cuando esto ocurra. El Block Diagram quedaría así:

Cuando este terminado lo compiláis y descargáis al NXT, y lo ejecutáis. Si tenéis alguna duda podéis consultar nuestro foro.

• English

En el artículo del Lunes vimos como recorrer imágenes con LabVIEW. Para ello necesitábamos un bucle anidado que podíamos recorrer gracias a que teníamos la información de la altura, la anchura y el color de la imagen. A la hora de manejar bucles muchas veces nos interesa saber los resultados de operaciones en iteraciones anteriores para poder manejarlos y operar con ellos, aquí es donde entran los Shift Register, que guardan la información que queramos de una iteración anterior para que podamos usarla cuando queramos. En el artículo de hoy vamos a crear una nueva imagen a partir de la información que saquemos de una que ya tengamos.

Uso del Shift Register:

En primer lugar necesitamos crear el bucle. Una vez tengamos el bucle creado (ya sea while, for…) clickeamos en el con el botón derecho y le damos a Add Shift Register:

Y quedará de la siguiente manera:

Donde la conexión exterior del lado izquierdo es donde se inicializa (lo que va a valer en la primera iteración), la interior de este mismo lado es el valor de la variable que en la iteracción anterior hayamos conectado a la conexión interior del derecho. Finalmente la conexión exterior del lado derecho es el resultado de la ultima iteración.

Es fundamental inicializar el Shift Register usando la conexión exterior del lado izquierdo, o tendrá un valor indeterminado y hará que la operación que hagamos en la primera iteración de un resultado no deseado. Al tener un elemento conectado a la salida (conexión exterior del lado derecho) nos aseguramos de que se ejecute de manera secuencial, ya que tendrá que esperar a que acabe el bucle para ejecutarse.

Un ejemplo sencillo de uso de los Shift Register sería una multiplicación. Una multiplicación no es más que sumar un número a si mismo varias veces. Por tanto podríamos hacer un bucle donde en cada iteración sume dicho numero a lo que ya tuviéramos en la iteración anterior, teniendo en cuenta que inicializaríamos a 0 el Shift Register. Ese programa quedaría de la siguiente manera:

Es posible utilizar el valor de varias iteraciones atrás, no solo de la anterior. Para ello podéis arrastrar en Shift Register una vez lo hayáis puesto. Cada Shift Register coincide con una iteración anterior, si tenemos cinco significa que tendremos los valores de las cinco iteraciones anteriores:

Crear una imagen:

Para crear una imagen necesitamos crear un cluster que contenga todos los datos necesarios. Eso se hace con la función bundle que podéis encontrar en Programming → Cluster, Class & Variant:

Este cluster lo conectaremos a una función de escritura de imágenes, como por ejemplo Write JPEG File que podéis encontrar en Programming → Graphics & Sound → Graphics:

Una vez tengamos la imagen podremos manejarla tranquilamente para mostrarla por pantalla por ejemplo.

Programa de ejemplo:

En este programa vamos a leer una imagen, vamos a recorrerla píxel a píxel, y en una imagen nueva vamos a dibujar un píxel de color negro por cada píxel negro que detectemos en la primera. Usaremos un umbral RGB que iremos variando para ver los resultados, como cuanta línea es capaz de detectar en la imagen de una linea negra sobre fondo blanco.

El Block Diagram sería el siguiente:

Tarda un poco en recorrer la imagen y crear la nueva. Hemos hecho varias pruebas, para que veáis un ejemplo aquí tenéis dos imágenes del panel frontal con distintos RGB umbral:

RGB por debajo de 60:

RGB por debajo de 100:

Como podéis imaginar esto tiene muchas aplicaciones, y es por ejemplo el primer paso para un sigue líneas con cámara. Teniendo la linea sabemos por ejemplo dónde se encuentra el robot respecto a ella y podemos corregir su posición.

• English

Microsoft acaba de anunciar que su Robotics Developer Studio será gratuito a partir de ahora. Esta herramienta permite programar y controlar (incluso remotamente) Mindstorms NXT haciendo uso de Visual Basic y C#. Anteriormente existían 3 versiones de este software, dos de las cuales requerían licencias de pago, ahora las 3 versiones se han unido en una sola, que puede descargarse y usarse sin coste alguno desde la página de Robotics Developer Studio.

Microsoft Robotics Developer Studio 2008 R3 (Microsoft RDS) proporciona una amplia gama de soporte para hacer más fácil el desarrollo de aplicaciones de robots. Microsoft RDS incluye un modelo de programación que hace que sea fácil desarrollar aplicaciones asincronas, orientadas a estados. Microsoft RDS proporciona un marco común de programación que se pueden aplicar para apoyar una amplia variedad de robots, lo que facilita la transmisión de código y conocimientos.

Microsoft RDS incluye un ligero tiempo de ejecución asíncrona orientada a servicios, un conjunto de autoría visual y herramientas de simulación, así como plantillas, tutoriales y código de ejemplo para facilitar el comienzo.

Las siguientes son las características generales:

• El CCR (Concurrency and Coordination Runtime) hace más fácil el manejo de las entradas y salidas asíncronas, lo que elimina las complejidades convencionales de los hilos, locks, y semáforos. Un entorno ligero de Servicios de Software Descentralizado orientado a estados permite la creación de módulos de programas que pueden interoperar en un robot y en los ordenadores personales conectados mediante un protocolo sencillo y abierto.
• VPL proporciona una sencilla herramienta de programación visual que simplifica la creación de aplicaciones de robótica. VPL también proporciona la capacidad de tomar un conjunto de bloques conectados y reutilizarlos como único bloque en otra parte de su programa. VPL permite también la posibilidad de generar código C# legible.
• DSS Manifest Editor permite la creación de escenarios de configuración de la aplicación y distribución.
• El DSS Log Analyzer permite ver los flujos de mensajes a través de servicios múltiples DSS. DSS Log Analyzer también posibilita inspeccionar los detalles del mensaje.
• VSE proporciona la capacidad de simular y probar aplicaciones robóticas utilizando una herramienta de simulación en 3D basada en la física. Esto permite a los desarrolladores crear aplicaciones de robótica sin el hardware. Ejemplo de modelos de simulación y ambientes le permite probar la aplicación en una variedad de entornos virtuales 3D.

• English

Seguimos explorando las posibilidades de control remoto para el Mindstorms NXT, ya hemos visto varios ejemplos de control remoto vía bluetooth, ahora vamos a ver NXToIP, una aplicación que permite controlar un NXT desde un servidor web en tiempo real.

Este proyecto tiene 3 partes fundamentales:

Servidor web con bluetooth (para recibir tanto la señal de la cámara como para comunicarse con el mindstorms). se trata de un PC Windows con un servidor ASP.NET, la interfaz de usuario no necesita ningún plugin, se trata de una simple página html. La interacción en tiempo real utiliza el framework AJAX de ASP.NET.
AJAX- JavaScript asíncrono y XML, es una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones -.

Aquí tenéis un pequeño vídeo demostrativo

Su creador es el mismo que ya nos sorprendió con la aplicación Lego Drive para iPhone.

La importancia de este experimento radica en que muestra posibilidades de control para el Mindstorms que aún están por explorar.

Otro proyecto que merece la pena ha sido desarrollado por Legoguy (Control Remoto NXT, parece que está offline por un tiempo, veremos si se vuelve a poner en marcha) ¡que nos permitirá controlar remotamente el Mindstorms de Legoguy desde nuestra propia casa!

Este es el aspecto que tiene la página en funcionamiento

Y este el robot que controlaremos

Además, podemos encontrar algunas aplicaciones que nos permitirán montar nuestro servidor web en casa y controlar nuestro robot, en este caso un RCX, se trata de: WebBrick y WebRCX.

Share

Tweet

• English

Ya hemos visto en un artículo anterior una implementación de máquina de estados que nos permitía hacer un sigue líneas. Ahora vamos a utilizar el Template de máquina de estados que viene con LabVIEW para un poner en marcha nuestra marble run. Este diseño se basa en el trabajo de Erling (Posibilidades del Datalog), aunque en este caso hemos utilizado un sensor de luminosidad para detectar la presencia de la bola y diferenciar el valor.

Vamos a estudiar primero los estados que tiene nuestro sistema, luego veremos cómo lo implementamos en LabVIEW.

1. Estado Inicial
2. Estado Color :

• English

Al hablar de robótica inmediatamente nos imaginamos máquinas capaces de andar, de moverse o de actuar de forma inteligente. Muchas de ellas solo están, aún, en nuestra imaginación, otras las vamos realizando a pequeña escala con nuestro NXT.

El campo en el que más se usa la robótica en la actualidad es el de la automatización industrial. En él, máquinas automáticas y robots, como por ejemplo los observados en la cadena de montaje de los automóviles, realizan las actividades que antes realizaban los humanos.

Es en dicho sector donde cobra especial importancia la toma de datos. Obtener y almacenar datos de nuestros robots, como valores de variables, valores de los sensores etc, y después saber representarlas e interpretarlas pueden ayudarnos a conocer los fallos del diseño o las posibles mejoras de este. Una forma de almacenar estos datos en el NXT es mediante el uso de datalogs.

Para realizar nuestro ejemplo usaremos un proyecto realizado originalmente por NxtPrograms. El proyecto consiste en un carril inclinado por el que circularan bolas de colores. Al llegar a la parte más baja, un sensor de color detectará la bola y la pala se elevará para colocar dicha bola, de nuevo, al principio del circuito, en un bucle casi infinito.

Como todo lo que construimos, el paso del diseño al papel implica una serie de problemas que deberemos resolver. Es ocasional que por un mal montaje o una mala programación, las bolas se salgan del circuito, o bien se junten en el carril dando problemas a la pala. Para solucionar esto hemos colocado una barrera en la última sección del carril que haga esperar a una bola mientras la otra está en la pala.

Una vez tenemos nuestro proyecto queremos analizar los tiempos que tarda cada bola en completar una vez el circuito, así como su tiempo cuando hay más de una bola en el carril.

Para ello realizamos un programa que, además de realizar el comportamiento de la máquina, introduzca los datos que deseamos en un datalog. La elección de qué datos introducir y en qué momento del programa influirá mucho en la buena realización del experimento.

En este caso, como queremos contar el tiempo que tarda cada bola en volver a la pala, añadiremos un dato más al datalog cada vez que la bola pase por esta, reiniciando el temporizador tras ello. Como vamos a disponer de dos bolas distintas, una roja y otra azul, usaremos dos temporizadores distintos, pero esto no debe preocuparnos, pues el datalog almacenara, junto al dato del tiempo, una referencia que nos permitirá identificar cada temporizador.

Este es el código, implementado por Erling.


#pragma config(Sensor, S1, color, sensorI2CHiTechnicColor)
//*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//

while(true)
{
if(SensorValue(color)!=0)//Si detecta color//
{
pala=true;
wait1Msec(200);
nMotorEncoderTarget[motorA]=60;
motor[motorA]=-100;
wait1Msec(750);
nMotorEncoderTarget[motorA]=60;
motor[motorA]=100;
wait1Msec(10);
pala=false;
}
}
}
task control()
{
while(true)
{
if((pala==true))//Si la pala esta operando//
{
nMotorEncoderTarget[motorB]=90;
motor[motorB]=-100;
wait1Msec(1000);
while(pala==true)//Espera hasta que la bola sale//
{
wait1Msec(100);
}
nMotorEncoderTarget[motorB]=90;
motor[motorB]=100;
wait1Msec(10);
}
}
}
task cuenta()
{
while(true)
{
if(SensorValue(color)==9)
{
wait1Msec(1000);
rojo++;
}
if(SensorValue(color)==2)
{
wait1Msec(1000);
azul++;
}
}
}
task lcd()
{
while(true)
{
nxtDisplayCenteredBigTextLine(2, "ROJO=%d", rojo);
nxtDisplayCenteredBigTextLine(4, "AZUL=%d", azul);
wait1Msec(100);//Tiempo de refresco//
}
}
task data()
{
nDatalogSize=500;
while(true)
{
if(SensorValue(color)==9)
{
AddToDatalog(time1[T1]);
time1[T1]=0;
wait1Msec(1500);
SaveNxtDatalog();
}
if(SensorValue(color)==2)
{
AddToDatalog(time1[T2]);
time1[T2]=0;
wait1Msec(1500);
SaveNxtDatalog();
}
}
}


Realizaremos dos experimentos, el primero con una sola bola de color rojo. Y el segundo con una bola roja y otra azul. Es importante que realicemos el mismo número de tomas de datos, es decir, las veces que la bola repite el circuito, para poder compararlos de forma correcta.

Una vez que tenemos los datos de nuestros dos experimentos almacenados en nuestro datalog, hemos de ordenarlos con una tabla de excel para poder representarlos. Lo primero es pasar el formato ”.cvs” del datalog a uno más manejable. Para ello seguiremos este tutorial.

Tras obtener un nuevo formato para nuestros datos, podemos clasificar estos por color de la bola (el primer número corresponde a la referencia del temporizador, la segunda al tiempo en milisegundos ) y, tras ello, representarlos. Obteniendo las siguientes gráficas:

En nuestro eje “x” tenemos el número de toma del dato, y en nuestro eje “y” el tiempo que ha tardado la bola en realizar el circuito en milisegundos.
Como comprobamos en esta gráfica, los tiempos para la bola roja y la bola azul son prácticamente iguales. Algo totalmente lógico si tenemos en cuenta que poseen el mismo peso y diámetro, siendo su única diferencia el color, que no afectará a su comportamiento en su movimiento por el carril.
Pero: ¿Qué pasaría si tuviéramos bolas de distintos tamaños y pesos? Podríamos diferenciar cuales son las más rápidas y determinar que el radio influye mucho en su velocidad. O bien podríamos detectar bolas que, aunque en un principio deberían ser iguales, presentan alguna anomalía.

Si comparamos el comportamiento de la bola roja sola y de esta junto a la bola azul:

Como se ve los tiempos se reducen considerablemente de un caso a otro, además de haber menor dispersión de datos. Es decir, con una sola bola, los recorridos en tiempo son muchísimo más similares. Algo lógico al no tener que esperar en la barrera debido a que haya otra bola. También es lógico comprobar que el tiempo medio de diferencia entre ambos casos (427 ms, aproximadamente medio segundo) se corresponde al tiempo adicional que tarda la bola por esperar en la barrera reguladora.

Ahora bien: ¿Qué pasaría si añadiéramos otra bola más al circuito? La pala estaría más tiempo ocupada, por lo que las bolas tendrían que esperar más veces en la barrera, aumentando los tiempos para cada recorrido.

Esto, traducido a un caso real de una fábrica, puede darnos conocimientos sobre con cuantas unidades un proceso se satura, formándose cuellos de botella y tardando con ello mucho más tiempo en realizar cada tarea.

En definitiva, la toma de datos y el análisis de estos son una parte fundamental en el diseño de maquinaría en fábricas, y puede resultarnos muy útil para entender de una forma precisa como se relaciona nuestro robot con su medio.

• English

Una de las cosas más reclamadas por los usuarios de NXT es la posibilidad de manejarlo remotamente desde el ordenador o desde un dispositivo móvil. El control remoto desde el ordenador ya es algo usado por todos, de hecho el Mindstorms NXT 2.0 ya la incluye dentro de su interfaz. Pero los usuarios pedían más movilidad, por eso, LEGO sacó hace un tiempo un programa que permitía a algunos teléfonos móviles controlar su robot mediante una sencilla interfaz gráfica (puede descargarse desde la página oficial de LEGO Mindstorms).

Sin embargo, los modelos que admiten esta aplicación son bastante limitados, según los datos oficiales de LEGO, sólo funciona para móviles de las marcas Nokia, Sony-Ericsson y BenQ-Siemens, que además deben tener bluetooth (lógico) y soportar Java (JRS-82).

Además, este software está bastante desactualizado y nuevos gigantes de la tecnología móvil como HTC o Apple no tienen soporte para esta aplicación.

Por suerte para todos los usuarios de Apple, en concreto de los dispositivos móviles iPod Touch y iPhone (en cualquiera de sus versiones) recientemente ha aparecido una aplicación en llamada Lego Drive – programada por Saiyin Topkaya- que nos permite controlar de forma directa (bluetooth) un vehículo con configuración diferencial (ver artículo sobre la rueda loca).

Para usar esta aplicación tendréis que escribir la Device ID (identificador de dispositivo) de vuestro NXT, esta información se encuentra en “Settings – NXT Info” y pulsar en “Connect”
Como la mayoría ya sabéis, Apple tiene restringidos los dispositivos que se pueden conectar con sus productos, por lo que su autor ha tenido que utilizar la librería btstack de Matthias Ringwald, esta librería permite que el iTouch o el iPhone se conecten con dispositivos no “oficiales”.

Para poder usar esta aplicación necesitaréis tener el “jailbreak” hecho (posibilidad de usar aplicaciones no aprobadas por Apple). La aplicación es de descarga gratuita desde Cydia, está en el repositorio de BigBoss.

Os dejamos un vídeo del funcionamiento de LegoDrive

Si no tenéis el “jailbreak” o queréis una aplicación aprobada por Apple tenéis iNXT Remote, con un precio de 3.99€ y se puede descargar desde la App Store. Aunque también podremos controlar el NXT desde el iPhone, esta segunda aplicación necesita de un PC o un MAC con un programa que recibe la señal del iPhone/iTouch por WiFi y se encarga de enviar la señal al NXT por bluetooth. Funciona bastante bien y la interfaz es mucho más completa (el otro carece de interfaz) y enormemente intuitiva. Aunque eso sí, cada vez que queráis usarlo tendréis que llevaros el ordenador con vosotros.

• English

La rueda loca (caster wheel en inglés) es una rueda sin tracción, simple o doble, que puede girar libremente y que generalmente está situada en la parte inferior de una estructura. Se utiliza en carros de la compra, sillas de oficina o vehículos… como nuestro tribot NXT. Vamos a detenernos un momento a revsar este elemento mecánico tan utilizado.

Existen dos tipos de rueda loca:

Rígida

Sujeta a la superficie con una estructura rígida que le permite sin embargo girar adelante y atrás.

De pivote o Rotatoria

Sujeta a la superficie con una estructura que tiene un eje en su centro, anclado a la rueda que puede girar libremente.

Este último tipo de rueda tiene una ventaja fundamental, y es que puede girar en todas direcciones, sin embargo esta facilidad puede convertirse también un problema, conocido como aleteo. El aleteo es ese característico movimiento de vaivén o zigzag que experimentan, por ejemplo los carritos de la compra cuando no tienen peso.

En robótica, las ruedas locas se utilizan generalmente en los modelos con una configuración diferencial, que consta de dos ruedas situadas diametralmente opuestas en un eje perpendicular a la dirección del robot. Cada una de ellas irá dotada de un motor, de forma que los giros se realizan dándoles diferentes velocidades, o frenando una rueda mientras gira la otra.

Con dos ruedas es imposible mantener la horizontalidad del robot. Se producen cabeceos al cambiar la dirección. Para solventar este problema, se colocan ruedas locas. Estas ruedas, como hemos visto más arriba, no llevan ningún motor, giran libremente según la velocidad del robot. Además, pueden orientarse según la dirección del movimiento.

Hoy queremos mostraros la nueva rueda loca minimalista.

Para construir esta rueda, necesitaréis estas piezas:

La rueda que aparece es la ref. 42610

Y seguir estas pequeñas instrucciones:

Aquí tenéis una imagen comparativa entre la rueda loca tradicional y la minimalista

Esta nueva versión de la rueda loca ocupa mucho menos espacio, requiere menos piezas y baja el perfil del modelo, lo cual también puede provocar ciertos problemas de roces cuando el vehículo lleva mucho peso. Sin embargo, para modelos ligeros es sorprendentemente ágil, todos los robots del experimento de Vehículos de Braitenberg en NXT-G montaban esta nueva rueda.

Podéis encontrar un estudio en profundidad sobre la física de las ruedas locas en el artículo de James J. Kauzlarich (en inglés).

Share

Tweet

• English

Acaba de lanzarse la versión Beta2.16 de RobotC para MINDSTORMS. La principal característica es el soporte para el Sensor de Color y el sensor de Temperatura por I2C, ambos de LEGO Education.

La siguiente es la lista de correcciones que han incluido en esta revisión:

• Mantiene el tipo de plataforma cuando se elimina la información del Registro.
• Mejora la asignación de código de las variables temporales.
• Se incorpora “unsigned” para eliminar la advertencia del compilador.
• Se añade la clausula “default” para las sentencias switch.
• parámetro “SGN” código de operación para ‘flotar’ fue incorrectamente el control de la ‘corto’ resultado para ver si se trataba de un ‘float’ NAN (Not A Number). Esta comprobación sólo debe realizarse cuando el retorno de la función es una variable de tipo float. Este problema se ha solucionado.
• Se genera mensaje de error si la declaración pragma “motor and sensors setup” no se encuentra en las primeras líneas del programa. Algunos usuarios tenían estas declaraciones en otros lugares lo que producía ciertos errores.
• La herramienta de la barra de estado muestra ahora el número de “puerto” o “nombre de NXT” del robot conectado, que anteriormente era mostrado como “===========”.
• Se ha corregido el mal funcionamiento de la barra de desplazamiento vertical cuando la pantalla se ampliaba hasta hacer cabera un fichero completo.

Fuente: RobotC

• English

Siguiendo con la serie de artículos sobre los vehículos de Braitenberg, que ya vimos en los artículos Braitenberg en LeJOS y Braitenberg en RobotC, hemos querido ir un poco más allá haciendo un sistema de robots que, a modo de tren autónomo, buscan la luz de su compañero de delante para seguir el recorrido.

El primero de los robots, el que haría de locomotora siguiendo con el símil de los trenes, está controlado remotamente desde el joystick en NXT-G al mismo tiempo que enciende unas bombillas en la parte trasera para dar un punto de referencia al robot que debe seguirlo.

El montaje

Hay una diferencia importante entre este montaje y el que usamos en los artículos anteriores sobre Braitenberg, y es la posición de los sensores:

En este caso hemos optado por ponerlos perpendiculares al robot, en lugar de diagonales como en el caso del montaje anterior. Esto favorece la posibilidad de reconocer la luz que se encuentra frente al robot, ya que tenemos 4 estados (ver artículo sobre máquinas de estados):
1. No hay luz o está demasiado lejos (los sensores no reciben luz o es muy escasa) — Parado
2. La luz se mueve hacia la derecha (el sensor de la derecha recibe más luz) — Giro a la derecha
3. La luz se mueve hacia la izquierda (el sensor de la izquierda recibe más luz) — Giro a la izquierda
4. La luz está frente al robot (ambos sensores reciben por igual) — Movimiento hacia delante

La implementación de esta máquina de estados está el el programa que viene a continuación.

Tomamos inicialmente el valor de la luz ambiente (cuando no se han encendido aún las bombillas) luego comprobamos si la diferencia entre las nuevas medidas de luz son suficientemente grandes con respecto a luz ambiente como para considerar que esa es nuestra bombilla objetivo, y si ese es el caso nos moveremos de acuerdo con sus desplazamientos: girando cuando la bombilla gira o recto si el robot guía sigue recto.

El valor con el cual comparamos depende directamente de nuestras condiciones de luz y del montaje concreto de nuestro robot, en nuestros experimentos esa diferencia ha tomado valores entre 7 y 15.

Es muy importante reseñar la necesidad de unas condiciones correctas de luz para este experimento, ya que, aunque se ha realizado un estudio previo de la luz ambiente, necesitamos poder diferenciar correctamente la luz que proviene de nuestra bombilla de cualquier otra fuente de luz (una lámpara, la luz solar, etc… ). Por lo que se aconseja un entorno lo más oscuro posible.

En el siguiente vídeo se pueden apreciar los resultados del experimento

Cabe destacar que todos nuestros robots llevan exactamente el mismo montaje y programa, con la excepción del primero (que es controlado remotamente).
Además se ha introducido un pequeño cambio de última hora en el programa que veíamos más arriba, todos los robots seguidores esperan un sonido fuerte (por ejemplo una palmada) antes de comenzar la ejecución del bucle principal.

Sin embargo, tal y como se aprecia en el vídeo, cuando los giros son muy cerrados, o el vehículo que va delante se mueve demasiado rápido, podemos llegar a perder la referencia.

• English

En el artículo de hoy vamos a ver cómo conectarnos y manejar varios NXT desde LabVIEW. Es un proceso algo complicado, y debido a las limitaciones propias del Bluetooth, poco fiable. Por tanto la mejor manera de que todo funcione bien es que el PC sea quién realice las conexiones y los cálculos, por lo que trabajaremos en LabVIEW orientado a PC y no a NXT (revisad el artículo LabVIEW orientado a PC o NXT. SubVIs). También explicaré al final cómo renombrar los NXT y descargar el firmware con LabVIEW.

Multicontrol:

Para poder manejar varios NXT con LabVIEW necesitamos hacer uso del módulo Specify NXT. Necesitamos este módulo porque es el que nos va a permitir seleccionar a cuál de los NXT con los que estamos trabajando queremos que los siguientes comandos hagan referencia. Dicho módulo podéis encontrarlo haciendo click derecho en el Block Diagram y accediendo a: NXT Robotics → NXT I/O → Advanced → Specify NXT. El bloque Specify NXT tiene el siguiente aspecto:

En NXT Name elegiremos el nombre de nuestro NXT, y en Connection el tipo de conexión (Bluetooth en este caso, puesto que queremos trabajar con varios simultáneamente). Es muy importante que tengáis los NXT en la lista de dispositivos Bluetooth de vuestro PC, ya que sino LabVIEW no podrá conectarse a ellos. Por supuesto el nombre de NXT que debéis utilizar es el que aparece en Mis sitios de Bluetooth (el administrador de bluetooth de Windows). Os recuerdo que debéis de tener actualizado el firmware del NXT en todos los NXT que vayáis a utilizar, y tener ya descargada la Shell de LabVIEW en el NXT*. Por último, la salida de este bloque es el flujo del programa que queréis que ejecute el NXT, así que lo tenéis que conectar a la parte del programa que queréis que ejecute este NXT.

*Para descargar la Shell de LabVIEW en el NXT en un NXT no tenéis mas que haber usado otro programa orientado a PC con este NXT. Si el de multicontrol es el primer programa orientado a PC que usáis con los NXT, LabVIEW tardará muchísimo en descargar la Shell en todos ellos y muy probablemente dará error de conexión.

Una vez tengáis terminado el programa y le deis a ejecutar tardará bastante en realizar las conexiones, y además que irá uno por uno. Por esto es recomendable tener un botón de control en el Front Panel de LabVIEW que impida que los NXT ejecuten nada de código hasta que lo aprietes. Así podrás esperar tranquilamente a que todos los NXT se conecten, y una vez conectados iniciar el programa apretando dicho botón. Si no ponéis este botón cada NXT empezará a ejecutar el programa según se conecte, con lo que empezarán totalmente a destiempo.

Programa de multicontrol: control simultaneo de seis NXT:

¿Por qué manejar dos o tres NXT si podemos manejar muchos más?… Para probar el experimento hemos hecho un multicontrol con nada menos que seis NXT. Debido a las limitaciones del Bluetooth no actúan de manera completamente simultanea como sí pasaría con un menor número de NXT, pero sin embargo el resultado es más impresionante.

El programa consiste en un pequeño control remoto de los NXT desde el ordenador. Podemos ordenar a los NXT que se muevan marcha adelante o marcha atrás, giren hacia uno u otro lado, o frenen. El programa tarda varios minutos en realizar las seis conexiones, pero como el movimiento está controlado por botones no pulsaremos ninguno hasta que no estén todos conectados, cosa que podemos comprobar si en el displays de los NXT ya aparece el mensaje de la Shell. Hemos usado estructuras Case y un bucle cuya condición de salida es apretar otro botón creado por nosotros llamado Stop. El Block Diagram ha quedado de la siguiente manera:

Como veis sigue una estructura lineal, es básicamente un Case que comprueba en cada iteración que botón esta presionado. La condiciones se podrían comprobar de manera simultánea en distintos bucles, lo cuál incrementaría la velocidad del programa, aunque esto no tendría un efecto visible en los NXT ya que el mayor retardo lo produce el Bluetooth.

El Panel Frontal tiene este aspecto:

Y finalmente el vídeo de demostración. El modelo de tribot es en este caso un modelo ultraligero con muy pocas piezas inventado por mí. En algún momento subiré las instrucciones de montaje al igual que el modelo que podéis ver en otros vídeos (el tribot modular en el que puedes colocar los sensores rectos y a la distancia que quieras):

Como veis no están completamente coordinados, y tampoco se mueven del todo igual. Esto es debido a varios factores: los retardos del Bluetooth sobre todo estando conectados a tantos NXT, que los robots no son exactamente iguales y con que tengan las ruedas algo separadas ya recorren distancias diferentes, y que no están perfectamente alineados al principio, lo que crea un error de navegación acumulativo. Resolver estos problemas no son el principal objetivo de nuestro experimento, sino el ser capaces de manejar varios NXT radio controlados mediante LabVIEW.

Tenemos planteado manejar decenas de NXT mediante este sistema en algún momento (la tienda entera en movimiento), así que estad atentos al blog. Si tenéis alguna duda no tengáis reparos en preguntar en el foro que para eso está.

Apéndice: Uso de la terminal de NXTs de LabVIEW:

Existe una utilidad en LabVIEW para poder conectaros a cualquier NXT disponible, cambiarle el nombre, ver el estado de la batería, actualizar el firmware… Para acceder a esta utilidad tenéis que ir a: Tools → NXT Tools → NXT Terminal…. Os saldrá el siguiente panel:

Como veis podéis realizar todas las operaciones que tenéis en el NXT-G, como renombrar el NXT, o manejar los ficheros que hay dentro del NXT. Este panel es bastante útil para actualizar el firmware, ya que normalmente tendrá una versión más actualizada que nuestro NXT-G.

• English

En el artículo de hoy vamos a ver qué diferencias hay a la hora de ejecutar un programa para NXT mediante el modo orientado a PC o a NXT. Trataremos además el tema de cómo crear un SubVI, que es la forma que se emplea en LabVIEW para crear funciones o métodos que después podamos usar fácilmente en otros programas.

Modo orientado a NXT:

En el modo orientado a NXT del LabVIEW tenemos una gran cantidad de funciones para manejar al NXT, y todas aquellas diseñadas para manejar los tipos de datos que usa el NXT (como boolean, integer, Port …). Podemos acceder rápidamente a toda esta funcionalidad haciendo click derecho en el Block Diagram. Muchas de estas funciones y métodos se encuentran también en el modo orientado a PC, pero no todas. Por ejemplo toda la funcionalidad de NXT Native I/O situada en la sección NXT I/O sólo la tenemos disponible en el modo orientado a NXT, y nos da gran precisión a la hora de manejar motores y sensores (podemos, por ejemplo, girar un motor los grados que queramos).

Este modo funciona de manera parecida al NXT-G, una vez hemos creado el programa y le damos a ejecutar, éste es descargado al NXT y, una vez ahí, el NXT lo ejecutará. Por tanto en este caso no necesitamos que el NXT esté conectado al ordenador para ejecutar el programa, simplemente bastará con que esté descargado. Sin embargo, si trabajamos en este modo no podremos usar la funcionalidad del Panel Frontal de LabVIEW, ya que en el PC no se estará ejecutando nada.

Modo orientado a PC:

En el modo orientado a PC tenemos la desventaja de que por un lado las funciones para manejar el NXT no están tan accesibles y, por otro lado, de que no contamos con la funcionalidad de NXT Native I/O, que nos permitiría un control preciso sobre los motores y sensores. Otra desventaja de este modo es que, como el programa se ejecuta en el ordenador, y éste va enviando señales al NXT, necesitamos tener al NXT conectado con el PC. Sin embargo tenemos otras ventajas. La principal ventaja es que como el programa se ejecuta en el PC podemos hacer uso de toda la funcionalidad del Panel Frontal de LabVIEW (una de las características más útiles de LabVIEW). Así podremos mostrar gráficas y llevar un seguimiento del valor de las variables, así como contar con controles para manejar todo lo que queramos.

Otra ventaja evidente de la ejecución en el ordenador es que su capacidad de procesado es muy superior, y puede hacer muchas más operaciones y de muchos más tipos que el NXT. Por ejemplo, podemos implementar cases que no dependan solo de True o False, sino de rangos de valores numéricos por ejemplo.

Para cambiar entre un modo y otro no tenéis más que meteros en File (estándo en el Block Diagram por ejemplo) y elegir Target to Computer o Target to NXT según a cuál deseéis cambiar. Es posible ejecutar un mismo programa en los dos modos siempre que tenga componentes que ambos conozcan y puedan ejecutar:

Cómo crear un subVI:

Un subVI no es más que un programa que podemos utilizar dentro de otros programas. Si por ejemplo tenemos un programa que recibe una temperatura en grados Celsius y los transforma a Fahrenheit podríamos crear un SubVI, y así poder usarlo en otros programas. El objetivo fundamental que se persigue con ello es el de reutilizar código y, por otra parte, el de reducir y simplificar visualmente el vi. El aspecto de un SubVI es el de un bloque, como los que usamos para programar los NXT: tendrá sus entradas y sus salidas.

Para crear nuestro SubVI lo primero que hacemos es crear el programa deseado. Una vez terminado conectaremos las entradas como Controles (por ejemplo en la siguiente imagen hemos creado tres controles de entrada: Un tipo Puerto, otro NXT, y otro entero). Las salidas sin embargo las pondremos como Indicator (como la salida del flujo de NXT de la siguiente imágen):

Una vez terminado este proceso nos vamos al Front Panel donde podréis ver los controles e indicadores de vuestras variables de entrada y salida. Haced click derecho sobre el icono de LabVIEW que está situado en la parte superior derecha de la ventana y elegid Show Connector:

Veréis unas pequeñas celdas, las de la izquierda representan las entradas y las de la derecha las salidas. Debéis clickear en cada celda, y posteriormente en el control o indicador con el que queráis enlazar. Deberíais enlazar por tanto todos los conectores de entrada con los controles, y los de salida con los indicadores, de forma que quedara algo así:

Si volvéis a hacer click derecho sobre este panel de conexiones de la parte superior derecha podéis editar el icono que queréis que tenga vuestro SubVI. Una vez hayáis terminado con todo este proceso guardad el archivo como si se tratará de un VI normal. Para usarlo vuestro SubVi en otro programa no tenéis más que clickear con el botón derecho en el Block Diagram y elegir Select a VI… Se abrirá una ventana donde podréis elegir el VI que habéis creado anteriormente. Veréis que os crea un cuadrado con el icono que habéis dibujado antes, y con las entradas y salidas que le pusisteis:

Espero que este artículo os sea de utilidad. Comentarios bienvenidos en el foro.

• English

Continuamos con la serie de artículos de LabView, esta vez con un programa un poco más complicado. Como sabréis, una máquina de estados finita o autómata finito es un sistema que dependiendo de unas entrada de datos, opera con ella y devuelve una salida. Hay muchas máquinas de estados que nos podemos encontrar en el día a día; por ejemplo las máquinas expendedoras son máquinas de estados, los semáforos son máquinas de estados, hasta los interruptores de luz de nuestra casa son una máquina de estados.

Sigue líneas como máquina de estados:

En este caso estamos hablando de máquinas de estados finitos porque tienen un número finito de estados. Por ejemplo, un interruptor tendrá dos estados: dejando pasar la corriente o cortando su paso. Un dispensador de bebidas tiene muchos estados, como: esperando pedido o devolviendo cambio. En el caso de la máquina de estados finitos que vamos a hacer hoy vamos a tener tres estados. Se trata de un robot sigue líneas que además esquiva obstáculos situados en su camino. Los estados posibles con los que vamos a trabajar serán: “dentro del blanco”, “dentro del negro”, y “obstáculo”.

Dicha máquina de estados tendrá como entrada los valores de un sensor de ultrasonidos, y del sensor de luz en modo activo. Según sea el valor de esas entradas actuará de una manera u otra. Por ejemplo si esta en lo negro se moverá a lo blanco y viceversa. Sin embargo si detecta un obstáculo a menos de cierta distancia le dará prioridad y tratará de esquivarlo. Por tanto siempre que reciba por la entrada que un obstáculo está a menos de x cm. se moverá al estado “obstáculo”, independientemente del valor de luz captado por el otro sensor.

Implementación en LabVIEW:

En primer lugar vamos a explicar la estructura case. En LabVIEW se pueden crear estructuras case que podrán ejecutar distintos trozos del programa según qué entrada reciban. Todo esto es configurable, y al crearlo ya viene con una entrada que lee booleanos y con dos estados: uno para false y otro para true. Para crear una estructura case tenéis que situaros en el diagrama de bloques de vuestro VI, darle click derecho → Structures → Case Structure:

Una vez seleccionado, estiramos para dejarlo del tamaño que queramos y hacemos click para ponerlo. Si clickeáis encima de donde pone true, podéis cambiar a la parte que ejecutaría si la entrada valiese False:

Podemos añadir nuevos casos además de True y False, para ello haced click derecho sobre el case y darle a Add Case After (después) o Before (antes) del caso actual:

Podemos movernos de uno a otro y ver que hace en cada caso. Por supuesto está vacío en un principio, para que lo rellenemos con nuestro código. Nuestro problema requiere de dos case: el primero comprobará que no haya obstáculos, y el segundo en que parte estamos (blanco o negro). Según en que estado nos encontremos debemos ejecutar solo la parte de código correspondiente, por ejemplo si detectamos un obstáculo es innecesario que comprobemos si estamos en blanco o en negro, ya que no nos sirve para nada, y además es un fallo conceptual (el estado es “obstáculo”, no “obstáculo y en negro” y “obstáculo y en blanco”, ya que si no nuestra máquina tendría cuatro estados y no tres).

Una vez tengamos la máquina de estados, es necesario conectarle las entradas (en este caso las lecturas del sensor de ultrasonidos y de luz). Además debemos meterlo todo en un bucle para que se ejecute hasta que apretemos el botón ENTER. El programa quedaría de la siguiente manera:

Estado “dentro del blanco”:

Estado “dentro del negro”:

Estado “obstáculo”:

En este vídeo podéis observar su funcionamiento:

Ya sabéis que si tenéis dudas podéis escribir en el foro.

En artículos anteriores como el artículo sobre reconocimiento básico de objetos con OpenCV y el artículo sobre segmentación básica en OpenCV hemos visto como detectar distintos objetos de color determinado en una imagen, e incluso calcular sus puntos medios y distancias entre ellos. En el artículo de hoy vamos a aplicar todos estos conocimientos para realizar un ejemplo práctico en el que gracias a dos imágenes tomadas por la cámara sabremos dónde se encuentran dos bolas rojas respecto al Robot, y lograremos esquivarlas con el robot mientras se mueve en línea recta.

Un poco de trigonometría:

Puesto que vamos a tomar dos fotos, y sabemos:

1) a qué altura está la cámara respecto del suelo, y
2) la inclinación de la cámara en grados,

podemos saber muchos datos, como por ejemplo la distancia hasta la que es capaz de ver la cámara. Teniendo en cuenta la siguiente imagen:

Si la cámara está a una altura b del suelo, mirando hacia abajo con un ángulo α, sabemos que la hipotenusa es:

c = b/cos(α)

y que la distancia a abarcada por la cámara es igual a:

a = c*sen(α)

por tanto la relación entre b y a será:

a = b*sen(α)/cos(α)

Así que con tan solo esos dos datos ya podemos saber muchas cosas. Pero, ¿cómo traducir las distancias que hemos hallado en píxeles a centímetros? Es fácil, ya que si sabemos la altura de la imagen (100 píxeles por ejemplo) y la distancia nos ha dado 50 píxeles, solo tenemos que dividir 50 entre 100, que serán 0.5, y multiplicarlo por a, de forma que nos dará más o menos la distancia equivalente en el mundo real (estamos suponiendo que la imagen abarca todo el plano horizontal cuando no es cierto). En cualquier caso es un método bastante preciso.

Programa de OpenCV:

Para procesar las imágenes usaremos OpenCV, y cuando terminemos guradaremos los datos necesarios en un archivo que moveremos al NXT, y que utilizará nuestro programa en RobotC para esquivar las pelotas. Hemos tomado mediante una cámara situada en el NXT las dos imágenes siguientes:

con la cámara situada a 27 cm del suelo y con una inclinación de 25º, y:

con la cámara situada a 30 cm del suelo (sube un poco al rotarla), y con una inclinación de 50º. De la primera imagen podemos sacar la distancia aproximada del robot a la primera pelota (supondremos que el robot está situado en el píxel central de la última linea de la imagen). De la segunda imagen podemos sacar la distancia entre las dos pelotas. Ya sabemos como calcular distancias y puntos medios de objetos de determinado color en OpenCV, así como distinguir dos objetos del mismo color. Incluso como escribir los datos en un fichero para que RobotC los entienda (revisad el artículo sobre manejo de ficheros en RobotC). El programa completo sería:

#include
#include
#include
#include
#include
#include
#include