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:

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:

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:

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:

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:

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.

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.

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

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

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:

Ya tenemos toda la información que necesitamos dentro de fichero.dat. Ahora necesitaremos mover ese fichero al NXT, para ello podemos utilizar el File Managment de RobotC.

Programa de RobotC:

El programa de RobotC se encargará de, con los datos recibidos en el fichero de OpenCV, hacer los cálculos necesarios y moverse a lo largo de la línea esquivando las bolas. Para eso necesitamos los siguientes datos: altura y ángulo de la cámara en la primera foto, altura y ángulo de la cámara en la segunda foto, diámetro de la rueda (lo usaremos para saber cuántos cm se mueve el robot), altura de la imagen en píxeles, tamaño del robot en cm., y distancia de seguridad con la bola que necesitamos para realizar el giro para esquivarla. El programa quedaría de la siguiente manera:

Ahora una breve explicación del programa:

1 a 14 - Declaración e inicialización de variables.

20 a 22 - Leemos del fichero y mostramos su contenido.

24 - Hacemos el cálculo de la distancia en cm, tal y como os he puesto en el apartado de trigonometría de este artículo.

26 – Para saber cuantos grados necesitamos rotar los motores para que el robot recorra determinada distancia, se multiplica la distancia por 360, y se divide entre el diámetro de las ruedas. Como en este caso es la distancia entre las dos bolas, a la distancia calculada anteriormente necesitamos restarle tanto la longitud del robot como la distancia de seguridad con la bola para poder realizar el giro necesario para esquivarla.

35 - En este caso es la distancia a la primera bola, por lo que solo le restaremos la distancia de seguridad para esquivarla.

40 a 44 - Aquí nos movemos hasta la primera bola, rotando los motores el número de grados calculados en la línea 35 del programa.

46 a 60 - Esta es la maniobra evasiva. Esta programada a mano, sin ningún cálculo, mediante ensayo y error para que el robot quedara justo pegado a la primera bola, entre la primera y la segunda bola. Esta maniobra de evasión variará mucho en función del objeto a esquivar, así como la distancia de seguridad en cm para realizarla.

62 a 66 - Aquí nos movemos hasta la segunda bola, rotando los motores el número de grados calculados en la línea 26 del programa.

71 a 79 - Otra maniobra para esquivar la segunda bola.

81 a 82 - Paramos el robot, y fin del programa

Y ahora os dejo un vídeo demostrativo del programa:

Espero que os haya gustado. Se que todo esto es un poco complicado, pero es solo una muestra de las cosas que se pueden hacer con una cámara. En un futuro los LEGO Mindstorms NXT tendrán cámaras, y su manejo será más sencillo que todo esto. Ante cualquier pregunta no dudéis en postear en el foro.

El objetivo de este experimento es lograr una representación de la visión que obtiene el robot mediante un movimiento del sonar en dos ejes. Para ello se ha situado al sensor ultrasónico en una plataforma capaz de moverse con dos grados de libertad y se han realizado lecturas medidas en varias posiciones. En este caso haremos una representación transformando los datos obtenidos anteriormente a coordenadas esféricas.

El objetivo de este artículo es doble: por un lado realizar una representación más acorde a la realidad, puesto que los datos se están capturando mediante un sistema de coordenadas esféricas y la representación que hemos elegido en gnuplot es mediante representación cartesiana. Aprovechando el hecho de que hemos realizado previamente un artículo sobre tratamiento de ficheros en RobotC y de que debemos hacer una transformación de coordenadas, para trabajar ambos conceptos dividiremos el proceso en dos partes:

• En una primera parte haremos uso del programa implementado en el artículo anterior, NXT Sonar 3D en RobotC, modificándolo para que escriba la información de las lecturas realizadas en coordenadas esféricas como floats en un fichero.
• La segunda parte la realiza un segundo programa que se encarga de leer la información del fichero que ha creado el primero, convertir los datos a coordenadas de esféricas a cartesianas, y crear un segundo fichero que será el que gnuplot leerá y representará.

Coordenadas esféricas:

El sistema de coordenadas esféricas se utiliza para determinar la posición espacial de un punto mediante una distancia y dos ángulos. En este caso contamos con esos datos, ya que tenemos los grados que ha girado horizontalmente, la elevación (grados verticales), y la distancia, medida por el sensor de ultrasonidos. Teniendo entonces un punto de la siguiente manera:

Podríamos hallar las coordenadas cartesianas (x, y, z) del punto mediante las siguientes formulas:

Puesto que RobotC dispone de funciones trigonométricas para hallar senos y cosenos es posible implementar esta conversión.

Modificación del primer programa:

Modificaremos el primer programa para que escriba los datos como float, y así practicaremos lectura y escritura de ficheros (revisad el artículo sobre manejo de ficheros en RobotC). La parte del código donde se escribe en el fichero es la siguiente:

La parte que está comentada es lo que teníamos escrito anteriormente. Ahora ya podemos crear nuestro programa que leerá de este archivo y escribirá los datos ya procesados en uno nuevo.

Programa de conversión de coordenadas esféricas a cartesianas:

Este programa lee datos de tipo float de un archivo, calcula las correspondientes coordenadas (x, y, z) , y las escribe en un nuevo archivo de texto que gnuplot sea capaz de interpretar. El código es el siguiente:

Ahora una explicación de algunas líneas:

12 - Borramos el archivo, para que al abrirlo cree uno nuevo y vacío.

13 y 14 - Abrimos tanto para lectura el que tiene los datos, como para escritura el que vamos a crear.

16 - Este bucle nos asegura que leeremos el fichero entero, ya que sabiendo que tenemos 40 lecturas horizontales por 25 lecturas verticales.

20 – Aquí realizamos un filtrado que tiene por objeto eliminar las medidas que hayan podido ser erróneas (eliminamos los 255).

21 a 23 - Hacemos la transformación de coordenadas esféricas a cartesianas.

24 a 26 – Y finalmente las escribimos en el nuevo fichero.

Ya solo nos queda representar los datos que hemos calculado con el gnuplot.

Representación con el gnuplot:

Hemos puesto a nuestro radar enfrente de un enorme camión de LEGO, y después de pasarle el radar3D, y usar el nuevo programa para convertir las coordenadas esféricas estamos listos para representarlo. Lo primero que hay que hacer es descargar el archivo del NXT, y emplazarlo en la carpeta binary del gnuplot. Una vez hecho esto ejecutamos el wgnuplot.exe, se abrirá una ventana donde tenemos que copiar estos datos:

11 – Aquí es donde va el nombre de vuestro archivo.

Si todo sale bien os saldrá una gráfica, donde se verá más o menos representado el objeto que hubiese enfrente del NXT. En nuestro caso sale lo siguiente:

Se ve el perfil del camión, con su altura aproximada de 30cm y posicionado en diagonal.

English

Una de las funcionalidades más pobres, peor implementadas, y con menor documentación de RobotC es el manejo de ficheros. El manejo de ficheros es una herramienta muy útil que nos puede servir para guardar información y usarla con otros programas, independientemente de su lenguaje de programación. Por tanto es la universalidad de los ficheros la que nos permitiría comunicar RobotC con otro programa de cualquier lenguaje. Sin embargo los creadores de RobotC no vieron está utilidad cómo algo importante, y por tanto no han implementado la funcionalidad necesaria para el correcto manejo de ficheros.

Apertura y cierre de ficheros:

Antes de poder operar con un fichero es necesario abrirlo. En la mayoria de lenguajes de programación hay dos modos de apertura, modo lectura y modo escritura. Abrimos en modo lectura si queremos leer la información que hay en el archivo, sin modificarlo. Abrimos en modo escritura si queremos escribir en el archivo, modificando su contenido.

OpenRead(fichero, error, nombre_fichero, tamaño_fichero) :  Abre el fichero con el nombre indicado en modo lectura. En tamaño_fichero tenemos que indicar el tamaño del fichero. La variable error será distinta de 0 si ha habido algún error a la hora de abrir el fichero. A partir de que este abierto trabajaremos con el fichero usando el nombre que le hayamos dado a la variable fichero.

Nota: La variable fichero es de tipo TFileHandle, y la variable error es de tipo TFileIOResult.

OpenWrite(fichero, error, nombre_fichero, tamaño_fichero) : En este caso se abre el fichero en modo escritura. En caso de que el fichero no exista se crea automáticamente, y si existe se borra su contenido antes de empezar a escribir.

Close(fichero, error) : Cierra el fichero. Como siempre la variable error nos indicará si ha habido algún problema, en este caso a la hora de cerrar el fichero.

Es muy importante cerrar los ficheros cuando hemos acabado de usarlos, o podrían generar errores la próxima vez que queramos utilizarlos.

Lectura de ficheros:

En RobotC hay diversas funciones para leer de ficheros, se diferencian principalmente en el tipo de dato que leen. Para que la lectura sea correcta el dato tiene que haber sido escrito con el mismo tipo que vamos a leer. El principal problema de RobotC es que no tiene capacidad de leer strings, lo que es un gran problema a la hora de tratar de leer archivos con strings. Las funciones para leer de archivos en RobotC son las siguientes:

ReadByte(fichero, error, nParm): Lee una variable tipo byte (8-bit) del fichero especificado. El valor de la variable error es distinto de cero si ocurre algún error de lectura.

ReadFloat(fichero, error, fParm): Lee una variable tipo float del fichero especificado.  El valor de la variable error es distinto de cero si ocurre algún error de lectura.

ReadLong(fichero, error, nParm): Lee una variable tipo long (32-bit) del fichero especificado.  El valor de la variableerror es distinto de cero si ocurre algún error de lectura.

ReadShort(fichero, nIoResult, nParm): Lee una variable tipo short(16-bit) del fichero especificado.  El valor de la variableerror es distinto de cero si ocurre algún error de lectura.

Estas funciones solo nos servirán a la hora de leer variables que hayamos escrito con la función de escritura correspondiente que escriba el mismo tipo de dato en el fichero. Hay que ser muy cuidadoso a la hora de escribir ficheros en otros lenguajes de programación para que los lea RobotC, ya que muchas veces no funcionará. Los más compatibles serán lógicamente C y C++.

Escritura de ficheros:

Al contrario que con la lectura, sí se pueden escribir ficheros con strings, lo cuál nos ayudará bastante a la hora de usar datos capturados por RobotC con otro programa (por ejemplo dibujar gráficas con el gnuplot). Otros tipos de datos escritos por RobotC pueden ser leídos por RobotC con la función de lectura correspondiente, o por otros lenguajes de programación. Las funciones para la escritura en ficheros en RobotC son:

WriteByte(fichero, error, nParm): Escribe un byte en el fichero especificado. El valor de la variable error es distinto de cero cuando existe algún error de escritura.

WriteFloat(fichero, error, fParm): Escribe un float en el fichero especificado. El valor de la variable error es distinto de cero cuando existe algún error de escritura.

WriteLong(fichero, error, nParm): Escribe un long (32-bit) en el fichero especificado. El valor de la variable error es distinto de cero cuando existe algún error de escritura.

WriteShort(fichero, error, nParm): Escribe un short (16-bit) en el fichero especificado. El valor de la variable error es distinto de cero cuando existe algún error de escritura.

WriteString(fichero, error, sParm): Escribe una cadena de texto con el terminador null en el fichero especificado. El valor de la variable error es distinto de cero cuando existe algún error de escritura.

WriteText(fichero, error, sParm): Escribe una cadena de texto sin el terminador null en el fichero especificado. El valor de la variable error es distinto de cero cuando existe algún error de escritura.

La escritura de ficheros en RobotC esta más desarrollada que la lectura, lo que potencia la compatibilidad e itercambio de datos con otros programas. Aún así es curioso que el manejo de ficheros en RobotC sea más limitado que en NXT-G, cuando NXT-G debería ser mucho más limitado en este aspecto.

¿Qué escribe RobotC en los ficheros?:

Para ver qué escribe RobotC en los ficheros hemos hecho unas pruebas: escribimos ficheros con las distintas funciones de RobotC, y luego vemos su contenido con un editor hexadecimal. Los resultados son los siguientes:

WriteByte(fichero, error, (byte)  ”a”):

Veamos cómo efectivamente escribe un byte (8 bits)

WriteFloat(fichero, error, (float) 17.0):

Vemos que los float ocupan unos 32 bits (4 bytes).

WriteFloat(fichero, error, (float) 1.5):
WriteFloat(fichero, error, (float) 1.5):

Entre float y float no se escribe ningún byte, sino que van seguidos. A la hora de leerlos simplemente se leerán 32 bits y se interpretarán. Esto sucede también con todos los demás tipos de escritura.

WriteLong(fichero, error, (long) 17):

Los long también se componen de 32 bits como vimos en su definición.

WriteShort(fichero, error, (short) 17):

Así como los short se componen de solo 16 bits (la mitad).

WriteString(fichero, error, “hola”):

Se escribe hola, a byte por carácter, añadiendo el null al final (el byte 00).

WriteText(fichero, error, “hola”):

Aquí podemos ver cómo WriteText no escribe el carácter null al final de cada cadena de texto.

Cómo escribir ficheros en C++ para leerlos en RobotC:

Para escribir datos en un fichero de tipo float, long … necesitaremos crear un archivo de tipo binario. Luego necesitaremos escribir en dicho fichero haciendo un casting especial, indicando el tipo de archivo que vamos a escribir, y su tamaño. Por último cerraremos el fichero. El código que escribe un float en un fichero binario capaz de ser leído por RobotC sería así:

Espero que os haya gustado el artículo, ante cualquier duda podéis preguntar en el foro, que para eso estamos.

P.D.: Este artículo hace referencia a la versión 2.02 de RobotC, la versión más actualizada a fecha de publicación de este artículo.

El objetivo de este experimento es lograr una representación de la visión que obtiene el robot mediante un movimiento del sonar en dos ejes. Para ello se ha situado al sensor ultrasónico en una plataforma capaz de moverse con dos grados de libertad y se han realizado lecturas medidas en varias posiciones.

Dado que la posición del robot que sostiene el sensor es fija y sólo se trabaja con movimientos de ángulo horizontal y vertical del mismo, si tomamos las lecturas del robot enfrentado a una pared y las representamos deberíamos obtener una figura similar a una de las hojas de un hiperboloide de dos hojas. Como el alcance del sensor es limitado, esta figura será truncada por el alcance del sensor. Existirán además otras distorsiones derivadas de la dependencia que tiene la medida de la distancia con ángulo con el que la superficie se enfrenta al sensor.

Desafortunadamente la teoría anterior no se traduce tan fácilmente en resultados acordes. El motivo es que la distancia devuelta por el sensor ultrasónico se basa en el principio del tiempo de vuelo, pero las ondas de sonido emitidas por el sonar no siempre rebotan en la superficie más cercana y vuelven directamente. La dirección de reflexión dependerá de varios factores, como las características de la superficie sobre la que se refleja el sonido y el ángulo de incidencia entre el haz de sonido y la superficie. Si el ángulo entre el haz y la superficie es muy bajo y la superficie es lisa, es probable que el haz no vuelva al emisor sino que siga otro camino alejándose (es lo que se denomina reflexión especular), por lo que si vuelve en algún momento al emisor, la distancia que interpretará el sonar no será la distancia correcta existente entre el sonar y la superficie, sino mayor. En el peor de los casos el haz se perderá y no tendremos ninguna lectura de distancia. Este problema puede desaparecer si la superficie con la que se encuentra es rugosa porque al llegar el haz a la misma se producen reflexiones irregulares y en este contexto es más probable que alguno de esos haces dispersos sea devuelto directamente al emisor, proporcionando una lectura correcta.

Vista la limitación anterior, una forma de obtener medidas estadísticamente más correctas sería alterar el medio en el que opera el robot y cubrirlo con una capa rugosa. Podríamos emplear para ello papel de lija, por ejemplo, forrando las superficies sobre las esperamos que incida el haz ultrasónico. Esto puede ser factible en un entorno conocido y controlado o con fines educativos, como cuando hacemos experimentos dentro de un laberinto, pero en un entorno “real” será prácticamente imposible, como por ejemplo si tratamos de medir el fondo marino.

Como la sugerencia de alterar el entorno no es posible en la práctica, nos vemos forzados a solucionar el problema de dos modos posibles, bien incrementando el hardware y trabajando con un array de sensores desfasados que realizan medidas sobre un mismo objeto, o bien complicando el programa que interpreta los datos recibidos: la idea en este segundo caso sería realizar un procesado posterior sobre las medidas que el robot fuera tomando y, almacenando dichas medidas, aceptar como válidas aquellas que fuesen variando de forma paulatina. Esta técnica puede ser combinada con ciertas acciones, como forzando al robot a tomar medidas sobre un mismo punto desde diferentes ángulos en zonas con discontinuidades o incongruencias [1]. Por ejemplo: si nos acercamos hacia una supuesta pared, las medidas recibidas deberán ir reduciéndose y, si no es así, podríamos tomar las medidas como incorrectas o revisar la suposición de la existencia de dicha pared.

Otra forma posible de elevar la garantía de las medidas en un proceso de localización del robot es combinando las lecturas del sonar con las de un segundo dispositivo, como por ejemplo un sistema de visión.

La siguiente es una vista típica de un sonar en dos dimensiones en la que el robot estaría situado en el triángulo rojo. Nos fijamos en que muchas de las dimensiones crecen en líneas que siguen la dirección de un radio que partiría del robot.

En el diagrama anterior podemos ver varias zonas en las que se producen saltos bruscos de medidas de distancia, como el señalado con la flecha azul: es bastante sensato pensar que la discontinuidad en la medida entre la parte superior de la zona señalada por el extremo de la línea azul y la parte inferior de la misma sea debida a una reflexión especular. Para confirmar la medida de esa zona podría ser necesario desplazar el robot a una posición como la señalada por el triángulo verde y volver a tomar la medida desde un angulo diferente.

Para el siguiente programa, implementado en robotC, se debe tener en cuenta que el motor A es el encargado de realizar el barrido horizontal, mientras que el motor B es el que proporciona la elevación. En cada barrido horizontal se realizan tantas lecturas como indique el parámetro nr_h_readings, mientras que el parámetro nr_v_readings indica el número de barridos horizontales realizar. Si int nr_v_readings = 1 transformamos el radar 3D en un radar 2D.

Cada una de las lecturas del sensor ultrasónico, situado en el puerto 1 según el programa, se almacena en una línea del fichero de texto testfile.dat. Para que la representación mediante gnuplot sea correcta, en cada una de las líneas del fichero mencionado se incluyen, junto al valor de la lectura de distancia del sensor, las coordenadas de ángulo y elevación.

El siguiente es el inicio del fichero con unas lecturas a modo de ejemplo:

1.0 1.0 39.0
2.0 1.0 39.0
3.0 1.0 39.0
4.0 1.0 39.0
5.0 1.0 38.0

Los datos se graban en un fichero que, finalizada la ejecución del programa, debe ser enviado posteriormente al PC para su representación gráfica. La aplicación que hemos empleado para representar los datos leídos es gnuplot y el programa encargado de ello es el siguiente:

Os ponemos un vídeo del proceso de escaneo, acelerado 3x. El robot de la parte inferior es el que realiza el escaneo del modelo TETRIX que tiene enfrente.

Y un vídeo que muestra los resultados del escáner en gnuplot. La depresión que vemos en el gráfico representa la zona en la que se está encontrando al robot Tetrix. La parte plana superior se corresponde a las medidas devueltas con valor 255, valor que devuelve el sensor cuando la distancia está fuera de rango, por lo que esas zonas medidas hay que descartarlas o interpretarlas como fuera de rango.

Nota: Dado que todos los datos se toman desde el mismo punto, lo ideal sería representar la gráfica en coordenadas esféricas y filtrando las mediciones erróneas de 255, pero por simplicidad se ha realizado una representación cartesiana, cuyos valores habría que corregir. Como una primera representación aproximada puede ser suficiente, puesto que no es ése el objetivo de este artículo.

Información adicional:

• A Method of Ultrasonic Sensor Data Integration for Floorplan Recognition, Joong Hyup Ko, et al.

English

Los vehículos de Braitenberg fueron concebidos por el investigador Italo-Autriaco Valentino Braitenberg para ilustrar de manera evolutiva las habilidades de agentes simples. Los vehículos representan la forma más simple de inteligencia artificial basada en comportamientos o conocimiento corporal, por ejemplo el comportamiento inteligente que surje de la interacción sensor-motor entre el agente y su entorno, sin necesidad de una memoria interna, representación del entorno, o inferencia.

¿Qué es un vehículo de Braitenberg?:

Un vehículo de Braitenberg es un agente que puede moverse de forma autónoma por un entorno. Tiene sensores primitivos (capaces de medir estímulos), y ruedas (cada una manejada por su propio motor) que funcionan como actuadores o efectores. Un sensor, en su forma más simple, está directamente conectado a un efector, de manera que una señal o estímulo en dicho sensor produce una respuesta inmediata en el motor (moviendo la rueda, por ejemplo).

Dependiendo de la forma en que estén conectados los sensores y motores, el vehículo mostrará distintos comportamientos. Basándonos en esta idea podemos definir dichas conexiones con objeto de cumplir cierto objetivo o comportamiento. Parecerá que el vehículo intenta lograr llegar a ciertas situaciones y evadir otras, cambiando su trayectoria cuando la situación cambia.

Ejemplos de vehículos de Braitenberg:

Los siguientes ejemplos son algunos de los vehículos de Braitenberg más simples:

Un primer agente tiene un sensor detector de luz que estimula directamente a su única rueda, implementado las siguientes reglas:

• Más luz produce un movimiento más rápido.
• Menos luz produce un movimiento más lento.
• La oscuridad produce que se quede quieto.

Este comportamiento puede ser interpretado como una criatura que teme a la luz y que se mueve rápido para salir de ella. Su objetivo es encontrar un hueco oscuro en el que ocultarse.

Un segundo agente algo más complicado tiene dos sensores de luz (izquierdo y derecho), cada uno estimulando a la rueda de su mismo lado. Obedece las siguientes reglas:

• Más luz en la derecha → la rueda derecha gira más rapido → gira hacia la izquierda, fuera de la luz.
• Más luz en la izquierda → la rueda izquierda gira más rapido → gira hacia la derecha, fuera de la luz.

Este es más eficiente como un comportamiento para escapar de la fuente de luz, ya que la criatura puede moverse en diferentes direcciones, y tiene a orientarse hacia la dirección desde la que procede menos luz.

En otra variación las conexiones son negativas o innovadoras:

• Más luz en la derecha → la rueda derecha gira más lento → gira hacia la derecha, hacia la luz.
• Más luz en la izquierda → la rueda izquierda gira más lento → gira hacia la izquierda, hacia la luz.

En este caso el agente huye de la oscuridad, moviéndose hacia la luz.

Configuración de motor y sensores mediante el menú de RobotC:

Una manera cómoda de configurar los sensores y motores en RobotC es mediante el menú de configuración de motores y sensores (Motors and Sensores Setup). Para acceder al mismo seguid la siguiente ruta: Robot → Motors and Sensores Setup y os saldrá el siguiente menú:

En la pestaña de motores podremos elegir qué motores vamos a usar y ponerles el nombre que deseemos, y si queremos que tenga el PID (Controlador Proporcional Integral Derivativo) activado. En la pestaña de sensores podemos elegir qué tipo de sensores queremos anclar a cada puerto, así como el nombre que deseemos darles. Una vez configurado todo le dais a aceptar y ya os escribe el código directamente:

Vehículo de Braitenberg en RobotC:

Como ya habréis supuesto los vehículos de Braitenberg no son problemas muy complejos de resolver con RobotC. En este caso vamos a implementar el último de los ejemplos que he puesto:

• Más luz en la derecha → la rueda derecha gira más lento → gira hacia la derecha, hacia la luz.
• Más luz en la izquierda → la rueda izquierda gira más lento → gira hacia la izquierda, hacia la luz.

Necesitaremos construir un robot con dos sensores de luz y dos motores. Es importante que los sensores de luz miren más o menos hacia los lados y no hacia adelante, o no podremos medir bien la cantidad de luz que proviene de cada lado. Con un ángulo de 45º es suficiente, como el robot que hemos construido nosotros:

A la hora de configurar los sensores de luz es importante que los pongáis en modo pasivo, o sea sin que emitan luz, ya que en este caso dicha luz nos entorpecería en nuestro cometido. Ponedle nombres intuitivos a los motores y a los sensores, como motorDerecho, sensorIzquierdo… Así se os hará mucho más fácil programarlos, y ver qué es lo que falla en caso de problemas. El código del programa sería así:

Y aquí os dejo un vídeo de muestra para que veáis como funciona:

Ante cualquier duda podéis visitar el foro.

English

En el artículo de hoy voy a explicar el Bump&Go en RobotC. El Bump&Go es un programa en el que el robot se mueve aleatóriamente por una habitación esquivando obstáculos cuando los detecta. Puesto que el movimiento es aleatorio llegará un momento en que se haya movido por toda la habitación. Este tipo de robot ya existe, y tiene uso comercial, como la aspiradora Roomba, que es capaz de aspirarte la casa automáticamente.

El Bump&Go es un programa bastante sencillo que se puede implementar de varias maneras, en nuestro caso lo haremos con sensores de contacto. A diferencia del de LeJOS, este lo haremos con dos sensores de contacto, para tener una mayor precisión. Como montaje recomiendo un tribot modificado, de manera que el parachoques quede mirando hacia adelante y no no en diagonal como el montaje estandar de tribot del del LEGO Mindstorms NXT. pero no es muy difícil de implementar.

Manejo básico de los motores:

Vamos a hacer un pequeño recordatorio del manejo de motores en RobotC. La forma más sencilla de manejar los motores era mediante la función motor:

motor[nombre_motor] = int potencia: Ponemos el motor deseado (MotorA, MotorB, MotorC, o motores que hayamos definido nosotros mismos) a la potencia indicada. Potencias negativas significan que el motor rotará en sentido contrario, y una potencia de 0 parará el motor.

Si queremos que el motor A se mueva hacia adelante a máxima potencia sería:

No serán necesarias más funciones para este programa.

Manejo del sensor de contacto:

El sensor de contacto es el más simple de los sensores del NXT. Básicamente tiene dos estados, pulsado o sin pulsar. Por tanto la función que se utiliza para determinar su estado devolverá un booleano con true en caso de que esté presionado, o false en caso contrario. Lo primero que necesitamos hacer es definir los puertos a los que van anclados dichos sensores, esto se hace de la siguiente manera:

#pragma config(Sensor, puerto, nombre, tipo_sensor): Anclamos el sensor del tipo deseado al puerto que elijamos, utilizaremos el nombre que le hemos dado aquí para referirnos a el dentro del programa.

Si quisiésemos poner dos sensores de contacto, en los puertos 1 y 2, se haría de la siguiente manera:

Una vez definidos podremos utilizarlos. Se usa la función SensorValue(nombre_sensor) para tomar el valor del sensor. En este caso nos devolverá un booleano, por lo que podríamos utilizarlo en las condiciones de los bucles o de las sentencias selectivas if. Un ejemplo sería:

Bump&Go:

Bump&Go es un robot móvil que se mueve erráticamente por una habitación o piso, esquivando cualquier obstáculo que encuentre a su paso. En este caso, y dado que usaremos el sensor de contacto, podemos decir que más que esquivar lo que el robot irá haciendo cada vez que colisione con un obstáculo es dar marcha atrás y girar para encontrar otra posible ruta sin obstáculos. Puesto que contamos con dos sensores de contactos podemos tener en cuenta si se ha presionado uno, otro o los dos, para saber a donde girar para esquivar dicho obstáculo. Si queremos además que el giro sea un número aleatorio de grados, usaremos la función matemática random(max) de RobotC, que nos devuelve un número aleatorio entre 0 y max. Suponiendo que queramos un rango entre un número distinto de 0 y el máximo que elijamos no tendríamos más que sumarle nuestro valor min, por ejemplo:

Nos devolveria en aleatorio un valor entre 1000 y 6000.

Puesto que su comportamiento va a ser aleatorio, está claro que será capaz de recorrer una habitación entera. Es solo cuestión de tiempo el que lo logre. Implementado así es un tipo de navegación muy simple, y tiene la ventaja de no exigir la necesidad de ningún sistema de localización, puesto que al tratarse de un movimiento aleatorio no se requiere conocer la posición del robot. (Versiones más avanzadas permiten que el robot pueda volver a la base para recargar las baterías. El problema de volver a una ubicación determinada sí requiere de un sistema más evolucionado).

El programa en RobotC sería:

A continuación explicaré las lineas más importantes:

13 - En mi caso el contacto1 esta en el lado derecho del parachoques, teniendo en cuenta esto:

14 – Calculamos un tiempo aleatorio de milisegundos para dar marcha atrás, este número estará entre 200 y 500 milisegundos.

15, 16 y 17 - Damos marcha atrás durante el tiempo deseado.

18 - Calculamos un tiempo aleatorio de giro en milisegundos, este número estará entre 200 y 600 milisegundos. Por supuesto los tiempos los elegís vosotros, quizás os venga mejor otro número para vuestro robot.

19 y 20 - IMPORTANTE, aquí giramos el robot hacia la izquierda (motorC es dondo está mi rueda izquierda, al rotar marcha atrás el robot girará hacia la izquierda). Hacemos esto lógicamente porque nos hemos chocado por la derecha, por lo que es la mejor manera de esquivar el obstáculo.

23 a 31 - Repetimos el proceso, pero en este casi si nos hemos chocado por la izquierda. Por tanto el robot después de dar marcha atrás girará hacia la derecha.

Todo esto está dentro de un búcle infinito. En caso de que se presionen los dos sensores a la vez se ejecutará el primer if, como si hubiera chocado por la derecha. En realidad nos es indiferente en este caso.

En resumidas cuentas lo que hace este programa es que el robot ande marcha adelante hasta chocarse con un obstáculo; entonces dará marcha atrás, girará en una dirección determinada según que sensor de contacto haya sido presionado un número aleatorio de grados, y seguirá otra vez moviéndose adelante. El robot solo detendrá la ejecución del programa cuando presionemos el botón ESCAPE del NXT. Aquí os pongo un vídeo demostrativo con el mismo programa que os he escrito en el artículo (recordad hacer un buen parachoques o puede que se os atasque):

Si tenéis alguna duda podéis postearla en el foro.

English

En el artículo anterior vimos como implementar el sonar básico. En este artículo voy a expandir el sonar para que tenga una mayor funcionalidad, y se puedan observar mejor los objetos por pantalla. Para ello usaremos nuevas funciones del LCD del NXT, y seguiremos utilizando la trigonometría para mostrar de forma precisa objetos por pantalla.

Funciones para el LCD:

La nueva función del LCD que vamos a utilizar es nxtDrawLine, que dibuja una línea entre dos puntos píxeles). La sintaxis es:

nxtDrawLine(punto1x, punto1y, punto2x, punto2y): Dibuja la recta que une los píxeles cuyas coordenas son las de punto1 y punto2.

Usaremos esta función para dibujar líneas negras entre donde detecta el objeto y el borde de la circunferencia del sonar. De esta manera los objetos quedarán representados por píxeles de color negro, mientras que el espacio libre será todo lo que esté en blanco.

Dibujo de objetos:

En el programa anterior, cada vez que detectábamos un objeto, lo representábamos como un punto, dibujándolo a la misma altura y en la que hubiéramos dibujado el borde de la circunferencia:

Sin embargo es una representación muy poco precisa, ya que en realidad el objeto se debería dibujar en una coordenada y distinta, ya que es un punto intermedio de la recta que une el punto central de la circunferencia con su borde:

Por tanto habría que modificar la coordenada y, de forma que su valor sea igual a la distancia por el seno, igual que la coordenada x es la distancia por el coseno:

Para dibuja la recta necesitamos dos puntos. El otro punto será por supuesto el borde de la circunferencia de radio 32 píxeles donde estamos representando el sonar. Por tanto para pintar el recta sería:

A la hora de detectar un objeto grande, dibujará varias lineas negras, una por cada grado que lo detecte, quedando como resultado un bloque negro representando dicho objeto.

Eliminación de errores:

Es sabido que el sensor de ultrasonidos falla bastante, generando una gran cantidad de lecturas erróneas con valor 255. Por ello es importante eliminar estos errores de medida para que no aparezcan representados en el dibujo (por ejemplo que este dibujando en el sonar una caja que tenga enfrente y de repente dibuje una línea de color blanco en medio de todas las negras).

Una buena idea es controlar cuando el el sensor marque 255 y actuar en consecuencia. Pero, ¿qué se podría hacer?, tratar de dibujar una línea negra cuando el objeto quizás se encuentre a más de 2 metros es igual de erróneo. Por tanto nos debemos fijar más bien en las medidas tomadas recientemente, y basarnos en ellas para saber si dibujar o no una línea, y de que longitud. Para ello tenemos que guardar todas las distancias medidas anteriormente.

Una vez tenemos las distancias anteriores guardadas podemos hacer que cada vez que detecte 255 cm, tome en cuenta un pequeño espectro de medidas anteriores (por ejemplo las diez medidas anteriores), calcule una media de esas medidas, y la use como referencia. Suponiendo que tengamos un vector llamado distancias, quedaría de la siguiente manera:

Con estos dos conceptos podemos crear un radar bastante mas eficaz, aunque como siempre dependemos de la poca precisión del sensor de ultrasonidos de LEGO.

Programa del Sonar:

Aplicando los conceptos vistos anteriormente, el programa del sonar ampliado gana precisión en la representación de los objetos que detecta. Todo esto nos facilitará comprender más el funcionamiento del sensor de ultrasonidos. Recordad repasar el artículo sobre ultrasonidos, para tener más claro el uso avanzado de motores. El programa completo es el siguiente:

5 – Creamos bastantes variables que nos ayudarán a manejar nuestro programa, como rango del sonar, el valor actual actual, o espectro para realizar la media en caso de lectura errónea.

7 - Así es como se define una tabla de 360 elementos, en ella guardaremos todas las distancias.

18 a 24 - Aquí controlamos los valores 255.

26 a 33 – Aquí realizamos el dibujo.

Y aquí está el video que os prometí:

Por favor visitad el foro si tenéis alguna duda.

English

El sonar (del inglés SONAR, acrónimo de Sound Navigation And Ranging, ‘navegación y alcance por sonido’) es una técnica que usa la propagación del sonido bajo el agua (principalmente) para navegar, comunicarse o detectar otros buques.

El sonar puede usarse como medio de localización acústica, funcionando de forma similar al radar, con la diferencia de que en lugar de emitir señales de radiofrecuencia se emplean impulsos sonoros. De hecho, la localización acústica se usó en aire antes que el radar, siendo aún de aplicación el SODAR (la exploración vertical aérea con sonar) para la investigación atmosférica.

El término «sonar» se usa también para aludir al equipo empleado para generar y recibir el sonido. Las frecuencias usadas en los sistemas de sonar van desde las infrasónicas a las ultrasónicas.

Aunque algunos animales (como delfines y murciélagos) han usado probablemente el sonido para la detección de objetos durante millones de años, el uso por parte de humanos fue registrado por vez primera por Leonardo Da Vinci en 1490. Se decía que se usaba un tubo metido en el agua para detectar barcos, poniendo un oído en su extremo. En el siglo XIX se usaron campanas subacuáticas como complemento a los faros para avisar del peligro a los marineros.

Manejo de sensores:

El manejo básico del sensor de ultrasonidos lo vimos en el artículo Manejo del sensor de ultrasonido en RobotC. En este artículo no añadiremos más funcionalidad al ultrasonido , aunque si veremos una nueva función para mostrar datos por pantalla. En este caso usaremos una función para dibujar píxeles, ya que necesitaremos dibujar obstáculos. La función es:

nxtSetPixel(int x, int y): Dibuja el píxel de la posición indicada. Recordad que la pantalla tiene 100 píxeles de ancho (del 0 al 99) por 64 de alto (del 0 al 63).

Un poco de trigonometría:

Para dibujar el sonar en forma de círculo y los objetos que detectemos necesitamos utilizar senos y cosenos. Suponiendo que queramos crear un circulo de radio 32 (la mitad de 64 que es el ancho de la pantalla), centrado en medio de la pantalla (coordenadas x = 50 e y = 32 aprox) necesitaremos dibujar 360 píxeles. La posición de cada píxel será igual a:

x = 50 + 32*cos(número de píxel)
y = 32 + 32*sen(número de píxel)

En RobotC existen funciones para calcular senos y cosenos:

sinDegrees(angulo_en_grados): Devuelve el seno del ángulo cuyos grados son los indicados.
cosDegrees(angulo_en_grados): Devuelve el coseno del ángulo cuyos grados son los indicados.

Programa de prueba:

Lo que hará este programa es realizar un giro completo de 360º mientras va tomando mediciones de distancia con el sensor de ultrasonidos, y a la vez dibujando un círculo y dentro de el todos los objetos que se encuentren a menos de 100 cm en este caso. Una vez finalizado el recorrido el sensor de ultrasonidos volverá a su posición. Aquí tenéis el código:

En breve colgaremos un vídeo de muestra.

Espero que os guste el programa. Si tenéis dudas, preguntad en el foro.

English

Actualmente es posible crear Robots avanzados que sean capaces de seguir a una persona guiándose por determinados patrones: como por el color de la ropa, su altura, … Aunque estos robots no tienen gran utilidad en la actualidad, es una funcionalidad que podría ser útil para complementar otras en un futuro. Con los LEGO Mindstorms NXT no es posible ser tan preciso, pero se puede conseguir un comportamiento parecido. Para ello usaremos el sensor de ultrasonido.

Programa de prueba:
Puesto que hoy no dispongo de mucho tiempo, el artículo no es tan largo como de costumbre. Antes de poneros con este programa os recomiendo que os leáis mis anteriores artículos de RobotC, especialmente el del manejo del sensor de ultrasonidos.

Este robot lo que hará principalmente es seguir a un objeto que se encuentre en línea con el. Cuando el objeto avance el robot lo seguirá avanzando también. Si el objeto se acerca demasiado el robot dará marcha atrás para no chocar con el.

Es importante definir unos buenos umbrales de distancia para saber cuando el robot tiene que seguir al objeto, o cuando tiene que dar marcha atrás. Teniendo en cuenta que el sensor de ultrasonidos suele fallar bastante en distancias menores a los 15cm, es aconsejable que la distancia para empezar a dar marcha atrás sea mayor (unos 25 cm por ejemplo). También es buena idea que no sean la misma distancia, que haya un margen de más de 10cm entre ellas. Por ejemplo si estoy diciendo que el robot de marcha atrás cuando me acerque a el a menos de 30 cm, le tendré que decir que se mueva para adelante solo cuando me encuentre a más de 40 cm. Si el robot se encuentra dentro de ese intervalo deberá estar parado.

Es también recomendable que cuando el sensor de utrasonidos detecte 255 cm (que en la mayoría de casos significa error) se quede quieto. Así evitaremos que el robot acelere cuando nos acercamos demasiado a el y las lecturas fallan. El código del programa no es muy largo, os lo escribo a continuación:

Aquí os dejo un vídeo bastante orientativo de como se comportaría el robor con dicho programa: