Joystick con NXT-G

joystickYa publicamos un artículo sobre distintas versiones de joystick con NXT y hablamos de sus posibilidades y el hardware necesario. Hoy queremos centrarnos en la programación de un joystick con NXT-G.

Usaremos como base hardware el diseño del joystick de Philo. Partiendo de esta base hemos añadido un nuevo sensor de contacto para ampliar las funciones. Comentar, sin restar méritos, que el modelo es algo endeble y ciertas partes de desmontan con facilidad – sometido, por ejemplo a la tensión de un combate de sumo-, nada que no pueda solucionarse con un poco de inventiva y algún refuerzo.

Referente al software, tenemos los programas del mando y del vehículo disponibles para descarga, pero al intentar cargarlos a nuestros robots para realizar las pruebas, usamos la versión 2.0 Educativa, no funcionaban.

Vamos a ver los programas originales -atención a los signos de exclamación que aparecen en los iconos, indicando problemas de compatibilidad. Conviene que amplieis la imagen para poder apreciar los detalles.

Programa del joystick (original)

Original Philo Joystick

Programa del vehículo (original)

Original Philo vehiculo

Encontramos los siguientes problemas:

1. Los bloques pertenecen a una versión distinta del software y nuestro NXT-G no los reconocía.
2. Algunos de los intercambios de información entre los bucles/bifurcaciones y los bloques externos a ellos resultan caóticos.
3. El sistema no permite la posibilidad de girar si no se está avanzando o retrocediendo, limitando así las posibilidades de giros rápidos sin desplazamiento.

La solución inicial pasa por reescribir los programas con los bloques nuevos, añadir variables para clarificar los intercambios de información (tutorial de variables) y volver a probar.

Veamos los nuevos programas.

Joystick

Incluye un sensor de contacto adicional y elimina las operaciones innecesarias.
Nuevo Joystick

En el programa original del joystick podemos ver cómo antes de enviar la información se realiza una operación matemática que tiene como fin dotar a la lectura del sensor de rotación de un signo (que nos indicará la dirección del movimiento).

Original dato con signo

En los bloques actuales la lectura del sensor de rotación ya tiene signo, y por lo tanto la información puede ser enviada directamente omitiendo esta operación, tal y como se observa en la segunda versión.

Nuevo dato con signo

Vehículo

Añade variables para facilitad la legibilidad del programa, atención al inversor de la señal lógica (Verdadero/Falso) que indica la dirección de giro de los motores: sólo es necesaria en nuestro montaje de pruebas – un tribot – ya que los motores están dados la vuelta.

Nuevo Vehiculo

Además quiero destacar el escalado del valor numérico a partir del cual obtendremos el giro (variable Buzón 2) que utiliza una fórmula:

Valor escalado = signo(mensaje recibido)* mensaje² / 30

Como hemos dicho antes, el valor numérico procedente del sensor de rotación, ya tiene signo, pero nuestra fórmula elevamos ese valor al cuadrado (mensaje²), lo que lo elimina; de ahí la necesidad de añadírselo de nuevo (signo(mensaje recibido)*).
No debemos olvidar que el elemento Dirección del bloque Mover está representado como un valor numérico comprendido entre -100 y 100, donde los valores inferiores a 0 representan movimientos hacia la izquierda, y los valores mayores que 0 movimientos hacia la derecha.

Esta implementación que acabamos de ver soluciona los dos primeros problemas. Veremos cómo resolver el tercer problema en otro artículo.

Información adicional:

Comments are closed.