RoboByte

Práctica 5: Auto-localización basada en filtro de partículas

2010-04-22T22:00:00.127+02:00

Volvemos a la carga ya con la última práctica sobre el robot Lego NXT, gracias a dios porque ya nos iba teniendo algo amargadillos ;-). En ella continuamos en la misma linea que la anterior, con filtros de partículas, pero esta vez enfocándonos más a un sistema final de auto-localización.

Visualización del mapa y de las partículas
En este primer ejercicio se pretende que cargado un mapa desde fichero, dibujar este en el LCD del robot junto con las partículas del un filtro (método estadístico de localización de Montecarlo).
Controlar el filtro de partículas no ha requerido ninguna dificultad, ya que en la práctica anterior casi implementamos un sistema de auto-localización, y el método de mostrar las partículas estaba ya implementado.
No nos ha sido tan fácil hacer lo propio con el mapa, ya que la clase LineMap solo dispone del método inside al que se le pasa un punto y determina si este está dentro o no del Mapa.
En una primera implementación traducíamos los puntos del mapa real a los del LCD, determinado cuales estaban dentro y cuales fuera. Esto tenía varios problemas, el primero es que al ser el mapa tan grande, el cálculo tardaba del orden de minutos, y el segundo, es que se necesitaba un algoritmo que eliminara los puntos interiores del mapa, dejando solo los bordes (algoritmo de erosión).
La segunda implementación trataba de mejorar la primera, traduciendo inversamente los puntos del LCD al los del mapa, al igual que se hace en las rotaciones de imágenes, pero seguían habiendo problemas, como el de tiempo, que aun habiéndose reducido, tardaba del orden de 1 minuto , y nuevamente había que implementar un algoritmo de erosión.
Surgió entonces la idea de realizar un programa externo, que calculara el borde del mapa mediante la segunda implementación, pero esto no nos convencía.
La tercera y última implementación, y debido a que anteriormente nos habíamos mirado el código de la clase LineMap para determinar la distancia entre las partículas y el mapa, algo que se supone que está implementado pero que no nos funcionaba en la práctica anterior, sabíamos que esta clase guarda los segmentos del mapa, con los cuales se puede determinar fácilmente los bordes. Dicho y hecho, copiamos el código fuente de la clase y creamos una nueva con un método que devolviera los segmentos (no se puede heredar de la clase porque el atributo está con visibilidad privada), para que otra función determina su longitud y orientación en pantalla, y lo pinte píxel a píxel.
Como una tontería como dibujar un mapa, nos puede complicarnos tanto la vida, :-)

Diseño de un radar
Este ejercicio consiste en realizar un radar con el sensor de ultrasonidos, devolviendo las mediciones de cada uno de los ángulos. Ya en la práctica 3 vimos que nos podría ser de utilidad para medir la distancia y ángulo al obstáculo, en la 4 para medir la distancia al mapa en el filtro de partículas, y en la 5 mejorar lo anterior para devolver las mediciones asociadas a sus ángulo en un tipo RangeReadings.
Además, se han implementado un par de funciones para mostrar las mediciones y el histograma de estas por pantalla:

Reconocimiento de posición y orientación
La realización de la práctica la hemos divido en 2 proyectos diferentes uno de ellos encargado de escanear con el Radar puntos bien conocidos del mapa y volcar esos datos en archivos que llamaremos measures(i).dat que serán nuestras muestras de aprendizaje. En nuestro caso particular y para realizar la autolocalización barriamos 360º con una resolución de 10º.

Una vez tuvimos las muestras de aprendijaze y tras varios problemas de espacio en el ladrillo teniamos una referencia con la que comparar nuestra nueva medición.

Como las mediciones del ultrasonido variaban con respecto a la orientación del mismo prodecimos a normalizar esos valor como un array de frecuencias de la siguiente manera:
En primera instancia y como el ultrasonidos tiene cierta incertidumbre (para una misma medición puede devolver valores dentro de una elipse que discretizamos en prácticas anteriores) decidimos englobar los valores del array siendo cada posición del índice i*(5cm) y para hallar el índice en que que dada un medida incrementar uno utilizamos :

index = (int)((measure + (HIST_RESOLUTION/2)) / HIST_RESOLUTION);

Tras normalizar tomamos una nueva medición, la normalizamos y la comparamos con las de aprendizaje obteniendo la que mayor compatibilidad, la que con más probabilidad cuadra con nuestra posición.

Con esto obtenemos la posición y con ella la muestra en RageReading que más se corresponde así que con una función de desplazamiento que implementamos y volcando previamente los datos de la muestra de aprendizaje y la de nuestra posición real obtenemos la orientación como elegimos la resolución de 10º tenemos al menos +- 10º de error en la medida.

El único problema que encontramos fue que aparte de que el mapa se movía de forma constante, en ciertas mediciones la diferencia entre compatibilidades era relativamente pequeña.

Auto-localización
En este ejercicio se pretende combinar casi todo lo aprendido anteriormente sobre el robot NXT, desde los ejercicios anteriores de visualización de partículas, reconocimiento de la posición y orientación, y como no, filtro de partículas.
Para la implementación del filtro de partículas se ha utilizado la clase TachoLocalizer, que no aporta más ayuda que en la gestión del movimiento de las partículas, e incluso el método de actualizar las partículas (updatePosition) tiene un pequeño bug en el paso de parámetros, teniendo el ángulo y la distancia intercambiados:

Original: mv = new Movement(MovementType.TRAVEL, angle, distance, isMoving);

Modificación: mv = new Movement(MovementType.TRAVEL, distance, angle, isMoving);

Además es necesario tener en cuenta llamar a la función de actualización cada vez que se realiza un movimiento, ya que no puede saber si primero realizar el 'avance' o la 'rotación'.

Para la obtención de el array de medidas de tipo RangeReadings hemos modificado nuestra famosa clase Radar para en vez de guardar estas en un array de forma interna, las pase a este tipo de estructura y la devuelva. Uno de los errores que teníamos en esto era que el sensor volviera a la posición inicial en la que partía, ya que lo hacíamos rotando el mismo número de grados en sentido contrario en vez de tener en cuenta la odometría del motor. Tan solo nos bastó la instrucción motor.rotateTo(0).

Otro de los problemas que hemos tenido ha sido la actualización de los pesos de las partículas, que el diseño propuesto por LeJOS (MCLParticle - calculateWeight) no era el más correcto cuando el número de mediciones sobrepasaba las 3, y nosotros nada menos que 360º/10=36.

Original: weight *= (float) Math.exp(-(diff * diff) / divisor);

Modificación: weight *= (float) Math.exp(-(diff * diff) / (divisor*divisor));

Vídeo resumen

Y sin más un video resumen de lo acontecido las últimas semanas

Nos vemos próximamente ya en la última práctica sobre "visión" en Gazabo & JDE.

Saludos!!!

Práctica 4: Filtro de partículas y cálculo de trayectorias

2010-03-25T22:00:00.241+01:00

Buenas a todos como todas las semanas para enseñaros todos los avanzes que realizamos con nuestro NXT.
En este caso utilizaremos un filtro de partículas para localizarnos en un mapa y aprenderemos a ir de un punto A a un punto B con una orientación específica ya sea en línea recta o en curva.

Filtro de Partículas
En este apartado se nos pide implementar una 'simulación' de un filtro de partículas, en el que inicialmente estas se sitúan en una posición preestablecida del mapa y se mueven al mismo tiempo que lo hace el robot, consiguiendo esto mediante la odometría de los motores.

Cálculo de la Incertidumbre
Para determinar el movimiento de las partículas es necesario calcular la incertidumbre al avanzar y al rotar el robot, para lo cual hemos implementado un sencillo programa que os dejamos aquí.

Tras realizar 10 muestras de cada tipo, hemos obtenido los siguientes valores:

Vemos que la indertidumbre en la rotación es enorme, nada menos que de -26 grados, y esto se debe a que el robot empleado (spirit) no tiene tracción a las cuatro ruedas, arrastrando las dos de delante. Hemos corregido este error adecuando la distancia entre ruedas pasada a la clase TachoPilot.

Implementación
Nos ha parecido tan interesante el tema del filtro de partículas que no nos hemos limitado simplemente a la simulación, hemos realizado el algoritmo completo, que ajusta el peso de las partículas en función de la medición real del sensor de ultrasonidos.

Hemos diferenciado varias clases:

CInit: inicializa el algoritmo de 'Condensation'.
C: Clase principal del algoritmo.
CUpdate: Clase que llama a actualiza el peso de las partículas y la pantalla.

CUpdateScreen: Dibuja las partículas por pantalla.
CUpdateWeight: Recalcula el peso de las partículas.

CUScan: Calcula la distancia entre el robot y la pared del mapa, haciendo un pequeño barrido de 20 grados. Esta librería ya fue implementada en la práctica 3 y esta vez si hemos conseguido sacarle provecho.

A continuación se detalla el esquema del programa:

Problemas & Soluciones
La principal dificultad en el diseño del algoritmo, ha sido el remuestrear el filtro de partículas, ya que en un primer diseño había dos hilos de ejecución, uno actualizando la pantalla y otro reculculando el peso de las partículas. Esto era incompatible porque al remuestrear, las partículas que se salen del mapa, se crea nuevas instancias de ellas y entonces el hilo de actualizar la pantalla puede coger partículas inexistentes.
Una primera solución fue la de que al avanzar 40 cm y girar 90 grados, y a continuación remuestreara el filtro y actualizara la pantalla, pero esto llevaba consigo una pausa de entre 2 y 4 segundos, algo que no nos convenció.
La segunda opción fue aprovechar el tiempo que dura el siguiente movimiento de avanzar y rotar para realizar los cálculos. El problema ahora es que podía solaparse 2 hilos de actualización, provocando nuevamente una excepción en el programa. La solución definitiva fue que el hilo de actualización comprobara que el hilo anterior hubiera termina, y en caso de que no fuera así esperarlo.

Otro problema fue el cálculo de la distancia de la partícula, con el fin de poder compararla con la distancia 'real' obtenida por el sensor de ultrasonidos, y así determinar el peso de cada partícula. Cabía pensar que esto iba a resolver fácilmente con el método range de la clase LineMap, pero este casi siempre devolvía un valor de -1. La solución fue imprementar un algoritmo que calculaba la intersección de la recta del vector de la partícula con las rectas de los lados del mapa, quedándose con la menor distancia.

Pruebas
Hemos construido de la manera más artesanal posible nuestro mapa de 10x10 cm, donde hemos realizando las pruebas de localización ;-)

Cálculo de Trayectorias
En esta práctica hemos encontrado muchos problemas al menos en su segundo apartado en el cual hay que caminar girando, para ello no hemos ayudado de la interfaz de la practica 1 "menu p1" añadiendo en configuración un nuevo menú ruta en la que especificar el X el Y y su orientación.

En su primera versión el robot se orienta hacia el objetivo obteniendo el angulo al objetivo y rotando para ello o bien lo calculamos a mano o bien mediante la librería Pose, acto seguido andamos la distancia que nos separa del objetivo que es simplemente la distancia euclidea y por último calculamos la rotación necesaria para posicionarnos como ordena nuestro parámetro de orientación (teniendo en cuenta el acumulado al posicionarse.

En su segunda versión nuestra orientación determina el eje de coordenadas y así las coordenadas del objetivo.
¿Como vamos de A a B rotando? pues difícil sin duda tras mucho pensar y probar con métodos como steer y arc que se basan en un ratio y observar que no podíamos trazar todos los arcos optamos por utilizar travelarc(radio, distancia) pero claro necesitamos radio de giro, dependiente de la distancia e inversamente proporcional al ángulo( a más ángulo menor radio) y distancia que se obtiene mediante el perímetro de la circunferencia y dividendo por el ángulo a girar tras eso actualizamos la orientación y nos reorientamos a la orientación pedida mediante un rotate.

Podeis ver en el vídeo resumen el resultado.

Vídeo Resumen
A continuación os dejamos un vídeo resumen de estas dos semanas de desarrollo:

Esperamos que nos volváis a visitar.
Hasta la próxima!!

Práctica 3: Navegación local evitando obstáculos

2010-03-11T21:54:00.003+01:00

Esta práctica ha consistido en el manejo de comportamiento y navegación mediante Vectores de Fuerza Virtuales (VFF - Virtual Force Field) en nuestro Lego NXT.

Sensor de Contacto
Su implementación a sido muy sencilla. Tiene un primer comportamiento que trata de detectar que el sensor de contacto se pulse (takeControl), y en caso de hacerlo (action) evitar el obstáculo retrocediendo unos cm para girar aleatoriamente 90º en uno de los sentidos y volver a enderezar el robot con otro giro de 90º grados.

Sensor de Luz
En este hemos innovado algo más de lo que realmente bastaba para resolverlo. En primer lugar hemos utilizado 3 sensores (2 del RCX y 1 del NXT) de luz en vez de 2, lo que nos ha permitido una mayor precisión para poner los sensores a 0 grados respecto al robot. Por otro lado hemos implementado un Thread de calibración de la luz, determinando la luz mínima, durante toda la ejecución, y la máxima en función de la luz ambiente actualizada cada cierto periodo de tiempo. De esta manera conseguimos que frente a condiciones lumínicas de menos luz el estímulo para el movimiento sea menor, y en las de más luz sea mayor.

Sensor de Ultrasonidos & Luz + Ultrasonido
Esta ha sido la parte que más nos ha complicado, principalmente por el control el velocidad de los motores junto con el cálculo de los vectores de fuerza. Resumimos las distintas partes desarrolladas:

Hilo para calcular la posición (ángulo, distancia, ...) del objeto, para lo que va moviendo la cabeza del últrasonido entre un rango de -20 y +20 grados. Puede parecer sencilla implementarla, pero la última versión llega a tener 480 lineas de código, con comentarios y Javadoc, claro ;-)
Librería para el control en velocidad de los motores, vamos, una implementación del TachoPilot.
Podéis ver los principales cálculos para determinar el ángulo de giro entre ruedas: SpeedTachoPilot
Comportamiento de detección de Movimiento, cuya condición de entrada es que el Hilo haya detectado un objeto (takeControl). Una vez detectado, se obtiene su posición para así determinar su vector de fuerza (de repulsión), y sumarla a la del objetivo, seguir hacia delante o hacia la luz, según sea el caso. No finaliza el comportamiento hasta no sobrepasar el objeto.

Vídeo Resumen
Os dejamos un vídeo resumen de nuestro progreso durante las dos semanas de desarrollo:

Nos vemos la siguiente semana con más novedades sobre Filtros de Partículas, ;-)
Saludos!!!

RoboByteDemo: Añadida práctica 2

2010-03-04T19:43:00.000+01:00

Acabamos de subir los siguientes ficheros pertenecientes a la práctica 2 a RoboByteDemo, con el fin de que los podáis probar:

BumpGO: motores en los puertos A y B y sensor de contacto en el 3.
ClapControl: motores en cualquier puerto y micrófono en el 4.
Information: sensor de ultrasonidos en el puerto 1 y el de luz en el 4.
Laberinto: motores en los puertos A y B y sensor de ultrasonidos en el 1.
USonicBG: motores en los puertos A y B y sensor de ultrasonidos en el 1.

Si no sabéis de que va todo esto de RoboByteDemo, os invito a que os paséis por un post anterior donde lo explica que como utilizarlo.

Saludos!!

Práctica 2: Aplicaciones básicas con sensores

2010-02-25T23:41:00.003+01:00

Durante éstos últimos días hemos estado centrados en cómo obtener información de nuestro entorno gracias a los sensores de nuestro NXT, para lo cual realizamos unas sencillas aplicaciones para familiarizarnos con ellos.
Algunas de ellas como obtener información básica de los sensores como el infrarrojo, ultrasonidos o nivel de batería no se comentarán en éste blog debido a su simplicidad y a la gran documentación que se puede encontrar al respecto en la red.

Algunos sin embargo, pese a su simplicidad, si los trataremos por sus vistosos resultados como un Bump&GO tanto por contacto como ultrasonidos, un "sigueparedes" o un robot controlado por sonido.

Para el Bump&GO decidimos realizar el giro en un valor aleatorio entre 90 y 180º puesto que menos de 90 produciría de nuevo un choque con el mismo objeto y más de 180 sería una andar de más porque en sentido contrario llegarías antes.
Este mismo algoritmo se utiliza también en su versión ultrasónica sin más cambio que el evento que produce el retroceso.

Para el ClapControl y debido al los numerosos escenarios donde podría utilizarse hemos desarrollado un filtro adaptativo, que como su propio nombre indica adapta la sensibilidad del sensor al ruido ambiente gracias unas tomas de muestra.

El robot sigue paredes en su forma original mantenía la pared y cuando una de sus medidas rebasaba el límite paraba y giraba. Ahora sigue andando y una nueva hebra de ejecución se encarga de los giros apropiados sin necesidad de parar el robot.

La parte de mediciones del ultrasonido supuso todo un reto, ya que además de que en función de la distancia fuese más o menos preciso dependiendo de la distancia nuestro sensor medía algo o 255.
Para evitar todo tipo de "ruido" repetimos las pruebas, con ese y con otro sensor diferente obteniendo para nuestra sorpresa valores completamente distintos.

Tras eso procedimos a realizar una tanda de 10 medidas a distintas distancias para obtener su incertidumbre.

Al hacerlo nos dimos cuenta que dependiendo a la distancia a la que midiésemos obteníamos un error sistemático que se aprecia perfectamente en la siguiente gráfica.

Aquí podemos comprobar la incertidumbre en Y

Y nuestra ventana de "visión" de ultrasonidos en función del ángulo:

En las matrices de covarianza vemos que conforme la distancia del ultrasonido aumenta, la incertidumbre es mayor, tanto en el eje X como en el Y:
Distancia de 40 cm
    0.1000    0.0844
    0.0844    1.5071

Distancia de 120 cm
    0.2333   -0.3678
   -0.3678    2.5623

Un vídeo resumen del trabajo de esta semana.

Bienvenidos al principio del fin

2010-02-22T15:43:00.001+01:00

Bueno señores se acuerdan de tomatito?

Pues bien tras mucho trabajo y esfuerzo nuestro tomatito ha evolucionado, tras una gran lucha interna entre el bien y el mal dentro de tomatito su alma impura se separó de su cuerpo dando lugar a un ente maligno sin cuerpo llamado Brutus cuyo único deseo es destruir a todos y cada uno de los robots que se encuentre por su camino.

Tal maldad lejos de ser destruida ha sido canalizada y nuestros esfuerzos han dado su fruto al conseguirle a Brutus un nuevo cuerpo, y así tenerlo controlado y a mano por si nos pudiese ser de ayuda en un futuro contra ciertos robots enemigos.

Aquí podéis ver parte del proceso de creación del cuerpo de Brutus y antes de que se fundiese con el, debido a su inmenso poder y maldad tuvimos que incorporar al diseño original además del paragolpes que veis instalado, ya una jaula de protección antivuelco para prevenir males mayores.

Aquí podéis ver a Brutus con su primera jaula instalada. Aunque simple y arcaica su primera jaula de protección hizo su cometido durante el proceso de fusión con su alma maldita.
Proceso en el cual aun teniendo cuidado sufrimos graves daños personales y materiales.

Por el momento Brutus permanece encerrado en una celda de adamantium esperando su propio destino...

Bienvenidos al fin de los días de la mano de Brutus

RoboByteDemo: Prueba nuestras prácticas en tu robot

2010-02-21T16:28:00.014+01:00

Hemos estado pensando en que podáis probar los desarrollos de nuestras prácticas de Robótica, pero sin llegar a ofrecer el código fuente (todavía no, xD), y una opción era ir publicando los binarios junto a cada uno de los post en esta web, pero eso lleva el inconveniente de mantenerlo actualizado.

Por esto motivo hemos creado RoboByteDemo, un Script al más puro estilo de repositorio de Linux para bajar de forma automática todos los binarios que vayamos colgando.

Os animo a que lo probéis!! Saludos!

Instrucciones de uso:

Se le dan permisos de Ejecución

chmod uo+x robobytedemo.sh
Se ejecuta

./robobytedemo.sh

Descarga: RoboByteDemo v1.00

Avances en robotica

2010-02-20T14:12:00.000+01:00

Esto que veis aquí que podría parecerse al mismísimo Bin Laden es el primer robot humanoide capaz de mantener una conversación fluida con una persona el árabe.

El artilugio capaz de hablar y entender árabe se encuentra deambulando por el aeropuerto de Dubai ayudando a los viajeros. Que pensarías vosotros si se os acercase este individuo mecanizado a echaros una mano?

Via:
www.rtve.es

Práctica 1: Calibración y Trayectoria

2010-02-18T11:00:00.000+01:00

El apartado más costoso de la primera práctica ha consistido en configurar el cuadrado de calibración y determinar el error cometido en las distintas pruebas realizadas. En el resto de apartados, como el control del motor, su odometría, y el manejo del LCD no nos paramos a comentarlos, ya que su manejo ha sido trivial.

Diseño del programa
Además de que el programa proporcione la funcionalidad lógica del Robot, hemos desarrollado una interfaz de usuario, que entre sus características tiene:

Ejecución de la Inteligencia Artificial del robot mediante Hilos.
Configuración: puertos de los motores, distancia entre ejes y diámetro.
MultiIdioma (Castellano/Inglés)
Soporte Multitactil (esto sí es broma, xD)

El esquema de transiciones del menú sería el siguiente:

Cuadrado de Calibración

Como se puede comprobar el robot se comporta de diferente forma en función de la superficie en la que ruede, por lo que de alguna manera nos apoyábamos en el ancho entre ejes para calibrarlo de forma más exacta en cada superficie en tiempo de ejecución.

Errores de Ruta
Para hacer los cálculos de los errores cometido hemos utilizado nuestro cuadrado de calibración, previamente determinados los ejes, una regla, paciencia y MatLab para facilitarnos los cálculos de la matriz de covarianza. Estos han sido nuestros resultados:

Prueba 1: sobre papel rugoso, distancia entre ejes de 11,5 cm

0.4767 0.2750
0.2750 4.7579

Prueba 2: sobre folios D4 y distancia entre ejes de 11,6 cm

4.3856 -3.6440
-3.6440 5.1768

Prueba 3: sobre papel rugoso y distancia entre ejes de 11,5 cm

1.0569 -0.5262
-0.5262 0.9729

Prueba 4: sobre papel rugoso y distancia entre ejes de 11,4 cm

5.4200 -7.2287
-7.2287 10.3953

Comentar que el diámetro de la rueda se ha mantenido constante a 5,6 cm en todas las pruebas.

Esperamos volver a escribiros pronto, como siempre para contaros nuestros avances.
Saludos!!

Configurar LeJOS en Eclipse [2º Parte]

2010-02-16T20:19:00.000+01:00

Vamos a continuar mejorando la configuración de LeJOS en el entorno Eclipse, y en esta ocasión se tratará de hacer un script en bash que nos compile, enlace y suba automáticamente nuestro proyecto, con tan solo un clic.

Para empezar creamos un fichero llamado "all.sh" en nuestro directorio de LeJOS (/opt/lejos/bin):
cd /opt/lejos/bin
sudo nano all.sh
Copiamos este script, pegándolo con CTRL + INSERT
#!/bin/bash

#Constantes
lego_name="" #Nombre del Lego
lego_address="" #Dirección del Lego

#Comprueba el número de parámetros
if [ $# -eq 2 ]
then
echo "Uso: $(basename $0) "
exit
fi

#Variable de Compilación
CLASSPATH=$PWD
mainFile=$(basename $1 .java)

#Programa
echo "Compilando..."
for file in *.java
do
echo -e "\t$file"
nxjc $file
done

echo "Enlazando..."
nxjlink $mainFile -o $mainFile.nxj

echo "Subiendo a Lego..."
nxjupload -n $lego_name $mainFile.nxj
Establecer las variables
lego_name: nombre del lego (carrarro, hansF1, ...)
lego_address : la dirección del lego (en el script no se utiliza)
Le damos permisos de ejecución
sudo chmod o+x all.sh
Creamos el enlace en Eclipse como explicamos en el post anterior
Name: leJOS All
Location: ${env_var:NXJ_HOME}/bin/all.sh
Working Directory: ${project_loc}/src/
Arguments: ${java_type_name}.java

Aquellos que manejen el scripting de bash verán que no es gran cosa la que proponemos, pero cumple su cometido sin demasiadas florituras ;-)
Saludos!!

Instalación de LejOS en MacOS Snow Leopard

2010-02-11T18:20:00.000+01:00

Debido a que apenas se encuentra documentación sobre la instalación de LejOS el los equipos de la manzana, me he decidido a hacer este mini videotutorial el el que veremos paso a paso su instalación el un Macbook Pro (Late 2009) con Snow Leopard.

Recomendamos verlo a pantalla completa para las líneas a introducir.
Referencias (http://lejos.sourceforge.net/)

Configurar LeJOS en Eclipse [1º Parte]

2010-02-10T20:36:00.000+01:00

Al igual que días pasados hicimos en referencia a la práctica 0, donde explicamos paso a paso como instalar LeJOS en Linux, en esta ocasión hacemos lo propio con el entorno de desarrollo Eclipse, explicado en la práctica 1.

Instalación de Entorno Eclipse

Para los que se instalen por primera vez la versión 3.5.1, avisar de que esta tiene problemas con la gestión de ventanas de Gnome (debido a recientes cambios en Gtk). Cuando no funcionen los botones utilizar el INTRO ó ALT+Tecla Botón.

Instalamos Eclipse si todavía no lo tenemos
Bajar la versión Classic desde Eclipse.org
Lo descomprimir en un directorio cualquiera y lo ejecutamos
Añadir el Plugin a Eclipse
Help > Install New Software > Add...
Name: leJOS
Location: http://lejos.sourceforge.net/tools/eclipse/plugin/nxj/
Lo instalamos
Para la versión 3.5.1 es necesario desmarcar la opción "Group items by category"
Establecer las preferencias: Window > Preferences > leJOS NXJ
NXJ_HOME: /opt/lejos
Marcar "Conection Type > USB"
Marcar "Run program after upload"
Marcar "Verbose"

Crear un Proyecto

Para crear un proyecto para nuestro lego lo hacemos como uno normal de Java
File > New > Java Project
Convertimos el proyecto Java en leJOS
Sobre el Proyecto, botón derecho: leJOS NXJ > Convert to leJOS NXT Project

Añadir documentación Javadoc

Seleccionamos la librería desde el Package Explorer
References Libraries > classes.jar > (botón derecho) >Properties > Javadoc Location
Javadoc URL: http://lejos.sourceforge.net/p_technologies/nxt/nxj/api/

Compilar un Proyecto

Podemos compilar el proyecto manualmente cada vez que queramos probarlo, pero resultará a la larga más cómodo tener unos accesos directos ya puestos en Eclipse. Vamos a crear tres enlaces, para compilar, enlazar y subir al Lego.

Nos dirigimos a: Run > External Tools > External Tools Configuration
Sobre: Program > New launch configuration
Creamos el enlace de compilacion con los siguientes parámetros
Name: LeJOS Compile
Location: ${env_var:NXJ_HOME}/bin/nxjc
Directory: ${project_loc}/src/
Arguments: ${java_type_name}.java
Creamos el enlace de enlazado
Name: LeJOS Link
Location: ${env_var:NXJ_HOME}/bin/nxjlink
Directory: ${project_loc}/src/${java_type_name} -o ${java_type_name}.nxj
Arguments: ${java_type_name} -o ${java_type_name}.nxj
Creamos el enlace para subir el programa al lego
Name: LeJOS Upload
Location: ${env_var:NXJ_HOME}/bin/nxjupload
Working Directory: ${project_loc}/src/
Arguments: ${java_type_name}.nxj
Creo obvio decir que para compilar y subir el programa habrá que seguir los pasos de forma ordenada: Compilar, Enlazar y Subir, xD

Como último paso, hacemos un simple "Hello World" para comprobar que toda la configuración está correcta y que ya podemos ponernos manos a la obra.

Referencias
LeJOS Manual - Using Eclipse

Robótica - I.T.I.Sistemas (URJC)

Instalar LeJOS en Ubuntu 9.10

2010-02-05T14:53:00.000+01:00

Aunque disponemos de la práctica 0 donde explica como instalar el entorno de Lego NXT para Ubuntu, esta no es del todo completa ni tan detallada como la vamos a hacer ahora, donde se explica cada uno de los pasos a seguir. Por último decir que la instalación es idéntica para entornos de 32 y 64 bits, habiendo sido hecha en una máquina de 64 bits.

Instalación JDK (Java Developmed Kit)

Antes de instalar leJOS, debemos disponer del paquete de desarrollo de Java. Puedes obviar este paso si tienes instalada una versión relativamente reciente.

De mi experiencia en el pasado, no recomiendo usar ninguna de las versiones que dispone Ubuntu en sus repositorios.
Bajamos la versión de la web de Sun Microsystem desde aquí
Bajar el .bin y NO el rpm.bin
La ejecutamos para que extraiga todos los ficheros
chmod u+x jdk_6u18-linux.bin
sudo ./jdk_6u18-linux.bin
Movemos el directorio /usr/lib/jvm
sudo mv jdk1.6.0_18 /usr/lib/jvm

Instalación de leJOS

Instalamos los paquetes: libusb-0.1.4, libusb-dev, libbluetooth3, libbluetooth-dev, ant, nano para lo que podemos usar:
apt-get install libusb-0.1.4 libusb-dev libbluetooth3 libbluetooth-dev ant nano
Bajar la última versión de leJOS desde aqui. Actualmente es la 0.85beta.
Extraemos el archivo, para lo que podemos usar:
tar xvfz lejos_NXJ_0_8_5beta.tar.gz
Renombramos la carpeta a lejos y la copiamos (o cortamos) a /opt/lejos/
mv lejos_nxj lejos
cp lejos /opt/lejos/

cd /etc/profile.d/

export NXJ_HOME="/opt/lejos"
export PATH=$PATH:$NXJ_HOME/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$NXJ_HOME/bin

Compilamos la librería
cd /opt/lejos/build
ant

Permisos para acceder a Lego NXT

Por defecto no tenemos permisos de escritura en los dispositivo USB o Bluetooth, o lo que es lo mismo, no se nos permite programar nuestro lego por temas de seguridad. Os voy a explicar dos maneras de hacerlo:

Dar permisos solo al dispositivo (Recomendado)
Creamos un grupo de usuarios llamado "lego", que serán los que tengan permiso para programa el dispositivo:
sudo addgroup lego
Añadimos nuestro usuario al grupo "lego":
sudo usermod -a lego tuusuario
Añadimos una regla para acceder al dispositivo:
sudo nano /etc/udev/rules.d/70-lego.rules
# Lego NXT
BUS=="usb", SYSFS{idVendor}=="03eb", GROUP="lego", MODE="0660"
BUS=="usb", SYSFS{idVendor}=="0694", GROUP="lego", MODE="0660"

Dar permiso a todos los usuarios (No recomendado)
sudo chmod a+w /dev/busmonX, donde X es donde se encuentre montado el dispositivo

Espero que os haya resultado de utilidad, porque aunque sea fácil de configurar, son bastantes pasos. Saludos y hasta la próxima!!!

Referencias
LeJOS Manual - Getting Started on Linux

Robótica - I.T.I.Sistemas (URJC)

Bienvenidos a tod@s

2010-01-28T18:45:00.001+01:00

Bienvenidos a tod@s a nuestra página web, con ella queremos compartir con todos vosotros nuestros avances en robótica.
En esta web iremos colgando nuestros vídeos para que podáis comentarlos y aportar nuevas ideas para que mejoremos poco a poco.