13.12.11

NAO Next Gen

13.12.11
Aldebaran Robotics ha presentado la actualización de su robot más futbolero: NAO. Este incorpora un Intel Atom a 1.6GHz, dos cámaras de alta definición y cuatro microfonos para el reconocimineto de voz.

No solo va más rapido su cerebro, también han sido mejorado su algoritmo de caminar, así como el de colisiones.


Fuente: Xakata
Más información: Aldebaran Robotics

9.12.11

El primer cable eléctrico elástico

9.12.11
La empresa japonesa Roboden ha desarrollado un cable eléctrico elástico, con un factor de elasticidad de 1.5, la misma que la piel humana. Un avance respecto de los cables en espiral de toda la vida :)

Fuente: Xakata

Arduino IDE 1.0 y Arduino, el documental

El día 30 noviembre se anunció oficialmente la llegada del IDE 1.0 de Arduino. A ver si un día de estos me animo y le echo mano a un plaquita de estas.

Aprovechando este post, un breve documental sobre Arduino:

Pequeños motores

Impresionante trabajo de José Manuel Hermo Barreiro, quien a sus 73 años y disfrutando de su jubilación, se ha dedicado a fabricar diminutos motores totalmente funcionales (con aire comprimido). 

El proceso de fabricación se basa en un torno de 80 años, que él mismo reparó, y  limar. A día de hoy ya ha fabricado 10 motores, y esperemos que no pare de deleitarnos con tan estupendo trabajo.

Bajo estas lineas el video del proceso de fabricación de un motor V-12. Y si quereis más siempre podeis acudir a su propio canal de youtube.


Fuentes: BricoGeek, lainformacion.

5.12.11

Cuadrícopteros

5.12.11
La existencia de este blog se limitó en su día a mostrar los avances en las prácticas de la asignatura de Robótica de la URJC, y logró su objetivo con creces a pesar de nuestro lamentable ejemplo de robot equilibrista. A día hoy me pareció buena idea mantener la actividad del blog para mostrar vídeos, noticias y demás actualidad del mundo de la robótica.

Ya habíamos comentado alguna vez por aquí la existencia de los cuadricópteros construyendo estructuras. Hoy otra entrega más pero con unas dimensiones algo más grandes, y parte de la exposición del museo de Orléans en París.


Fuente: Microsiervos
Más información: IEEE Spectrum

20.4.11

EL FIN

20.4.11
Ayer 19 de abril de 2011, a las 8:11 PM, RJV11 tomó conciencia de si mismo. El juicio final se acerca.

7.4.11

Práctica 5 - Entorno simulado Gazebo y JDE

7.4.11
En esta práctica, nos centraremos en el simulador 3D Gazebo, ya que usaremos otro tipo de robot "virtual" ya que no siempre se puede comprar un robotito para hacer prácticas. También usaremos JDE, para poder desarrollar comportamientos para el robot.

En esta práctica, nuestro objetivo será que el robot siga la línea sin perderla y que lo haga en el menor tiempo posible, combinando ambas cosas.

[fotos, gazebo y jde]

Para ello usaremos la cámara del robot cómo recolector de información, lo que haremos será trabajar solo con una fila de píxeles por debajo de la mitad de la imagen. Sobre esa línea de píxeles detectamos donde comienza la línea y donde termina, calculamos el punto central de esos dos puntos y hallamos el error respecto de nuestro punto de equilibrio que se encuentra en el centro de la línea de píxeles. De esta forma, mediante un control P respecto del error cometido podemos centrar al robot en la línea dándole mayor o menor velocidad angular al robot, lo que provoca que nuestro robot gire con mayor o menor velocidad, y en un sentido u otro. Por ejemplo, si se acumula mucha cantidad de rojo en la parte derecha de nuestra muestra, ordenaremos al robot que gire hacia la derecha para no perder la línea, y viceversa.

Ejemplo del procesamiento de la linea de pixeles para obtener el error.

En el caso de que nuestro robot pierda la línea completamente de vista, su comportamiento está programado para que se pare y gire sobre si mismo. De esta manera en algún momento debería volver a encontrar la línea.

Mejorando los tiempo:

Un método que empleamos también es coger otra fila de píxeles por encima de la anterior fila de píxeles, y comparando el punto central de ambas filas podemos decidir que el robot vaya más o menos despacio, por ejemplo, si en las dos puntos hay rojo quiere decir que estamos centrados en la linea y esta es una recta, por lo que habrá que decirle al robot que acelere la marcha para minimizar el tiempo del recorrido, por el contrario si la fila de arriba no detecta rojo y la de abajo si es que vamos a tener que girar pronto por lo que disminuiremos la velocidad para no salirnos de la línea y tomar la curva con mayor control.A


Los puntos marcados son los comparados para determinar si estamos en una linea recta o no. En este caso así es, puesto que los dos puntos son rojos.

24.3.11

Práctica 4 - Control PID: el robot equilibrista

24.3.11



-Descripción de controlador PID

Esta es la formula que del controlador PID, dicha formula, a la hora de pasarla a la práctica, no se puede usar tal cual en el código, por lo tanto convertimos la integral en un sumatorio, y la derivada en la variación del error.
El resultado, u, es la velocidad que los motores deben de dar a las ruedas en cada momento para que mantenga el equilibrio

-Obtención de parámetros e implementación (kp 22, ki 1.2,kd 14, Lim de i 200)

La constante kp es una constante proporcional al error medido entre la posición en la que está y de la que debería estar

La constante kd es una costante proporcional a la derivada del error, por lo cual, esta constante es la que hace posible que cuando desequilibres al robot, el vuelva al equilibrio

La constante ki es una constante proporcional a la integral del error, la cual hace que cuanto mas alejado, o mas tiempo este alejado del punto de equilibrio, más fuerza de a los motores para recuperar la posición.

-Video del robot equilibrista


-Gráficas de la ejecución:

Con el objetivo de intentar interpretar el movimiento a partir de las constantes, del error, la integral y la derivada del error, nos propusimos capturar los datos que maneja RJV11 en cada momento. Para ello leJOS incluye un par de herramientas muy útiles, el nxjmonitor y el nxjdataviewer.

Lo óptimo hubiera sido poder monitorear todos los datos durante la ejecución del programa, casi en tiempo real, para lo cual el nxjmonitor hubiera sido la herramienta perfecta. Pero debido a la imposibilidad de conseguir ejecutarlo en nuestros ordenadores personales, y no poder usarlo en los ordenadores del laboratorio debido a la ausencia de los paquetes necesarios para la conexión bluetooth, no fue posible hacer uso del nxjmonitor. En su lugar usamos el nxjdataviewer, un pequeño programa que nos hacia posible recoger los datos de un log que íbamos generando durante la ejecución de RJV11. El nxjdataviewer cumplió su propósito perfectamente, con la pega de poder obtener solo los últimos datos recogidos, debido a la limitación de la memoria del ladrillo.

A continuación unas gráficas correspondientes a una ejecución que consiguió mantener el equilibrio durante unos 10 segundos antes de estrellarse. Las gráficas han de leerse de derecha a izquierda:

Puede observarse como las gráficas en su parte izquierda aumentan/disminuyen repentinamente, mostrandonos los valores que manejaba RJV11 en el momento de caerse.

-Conclusión

Nos ha costado mucho dar con las constantes adecuadas, pero nos hemos acercado ya que RJV11 nos aguanta 13 segundos en equilibrio. Hemos probado muchas constantes basandonos experimentalmente en las pruebas anteriores y modificando segun veiamos que necesitabamos en cada momento, y tambien basandonos en las gráficas extraidas.

Cuando aumentamos la kd, dejando las demas igual, se aumenta la velocidad de las ruedas, si disminuimos dicha constante, tambien se disminuye la velocidad.
Cuando aumentamos la ki, a la minima acumulacion de error se dispara la velocidad de las ruedas, y si se disminuye se le permite mas error y por lo tanto mas inclinacion del cuerpo del robot.
Cuando aumentamos la kd, se me hace muy sensible a la variacion de error, pero si se disminuye, no responde bien a los posibles desequilibrios externos.

Próxima entrega: Práctica 5 - Entorno simulado Gazebo y JDE

10.3.11

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

10.3.11
En esta práctica debemos hacer uso de dos sensores de contacto, dos sensores de luz, y de un sensor de ultrasonidos. Decidimos hacer un montaje el cual nos permitiera incorporar todos los sensores al mismo tiempo, se estén usando o no, esto nos permitió no perder tiempo en montajes y desmontajes, puesto que la propia naturaleza de la práctica nos obligaba a usar distintas combinaciones sensores. El resultado final es el siguiente:

Montaje final de RJV11 para la prática 3.
Los sensores de contactos serán usados a modo de parachoques, permitiéndonos detectar cuando hemos colisionado con un objeto para cualquier punto de la parte frontal de RJV11. La importancia de distinguir si la colisión se produjo por la izquierda o por la derecha es vital para saber por que lado debemos sortear el obstáculo. Por ello optamos por hacer un parachoques individual para cada uno de los sensores.

Detalle de los sensores de contacto con su doble parachoques individual.
En un principio nuestros sensores de luz estaban orientados en 90º y -90º respecto del frontal de RJV11. Dada la dificultad de estos sensores para captar la luz se decidió colocar con orientación 45º y -45º, con la esperanza de que obteniesen mejores lecturas de luz al darle más directamente.

Sensores de luz RCX con orientaciones 45º y -45º.
El sensor de ultrasonidos era necesario montarlo de tal manera que pudiera girar hacia la izquierda y la derecha con el fin de detectar obstáculos. No se nos ocurrió manera más sencilla de colocarlo que directamente sobre un eje conectado a un motor. De esta manera podemos girar el sensor facilmente gracias a la odometría interna del motor.

Sensor de ultrasonidos conectado a un motor.


Comportamiento de evitación de obstáculos usando sensores de contacto:

Para este ejercicio, hemos usado dos sensores de contacto, ya que si RJV11 choca contra un obstáculo que está a su izquierda, el robot retrocede un poco para esquivarlo, y viceversa.
Para calcular como esquivar los objetos, hemos implementado el codigo basándonos en el caso extremo, en el que el objeto está en en centro del robot ,de tal forma que lo esquive sin chocar.
También, al chocar el robot e ir hacia atrás, se descolocaba de su eje inicial y al girar no se quedaba en la misma trayectoria que al principio, por lo que decidimos que el robot se parara un intervalo de tiempo desde que choca hasta que retrocede.



Comportamiento de evitación de obstáculos usando el sensor de ultrasonidos:

En este ejercicio hay que esquivar obstaculos antes de llegar a el, para ello usamos el sensor de ultrasonidos y un motor que lo hace girar desde -45 a 45 grados de la direccion del robot.
Para calcular como esquivar ese obstaculo hemos usado funciones trigonometricas para calcular una suma ponderada de las coordenadas de las fuerzas de atraccion y repulsion. Dicha ponderacion depende de la distancia a la que se encuentre el objeto.



Comportamiento ir hacia la luz:

En una intuición inicial los sensores de luz fueron utilizados en modo pasivo, de tal manera que no emitieran luz, y fuera únicamente la luz ambiente la que les influyera. Lamentablemente pudimos comprobar como al estar en modo pasivo las lecturas de luz eran mucho menos precisas que en modo activo. Por que se pusieron otra vez en modo activo.

La orientación de los sensores pudo hacerse perfectamente en 90º y -90º, pero debido a la dificultad que tienen estos sensores para captar la luz que no le llega directamente, se decidió orientarlos en 45º y -45º, con la intención de que mejorase los resultados.

Uno de los mayores problemas de este ejercicio es el sensor de luz en si mismo. La sensibilidad que ha demostrado ha sido bastante pobre, lo cual nos ha dificultado mucho las cosas a la hora de implementar un algoritmo con los valores de luz captados.

Otro de los problemas que se pudo solucionar fue el hecho de que a pesar de que los dos sensores son del mismo modelo, ante igual exposición a la luz, nos daban valores de lectura considerablemente diferentes. Esto se arregló durante el proceso de calibrado de la oscuridad, de tal manera que le hallaba el error sistematico entre un sensor y otro ante la misma cantidad de luz (dentro de lo posible), y posteriormente se usaba ese error sistematico para equilibrar el error cometido entre los dos sensores en cada una de las lecturas.

Finalmente, y como en prácticas anteriores, para guiar a RJV11 hacia la luz se optó por un control reactivo P respecto del error cometido entre las lecturas de los dos sensores (teniendo en cuenta el error sistemático entre ambos). De esta manera si el sensor izquierdo capta más luz que el derecho, RJV11 girara a la izquierda para orientarse a la luz mediante el método steer con un valor de ratio de giro proporcional al error, y viceversa. El resultado se puede ver en el siguiente video:




Comportamiento ir hacia la luz evitando obstáculos:

En este ejercicio hemos mezclado los comportamientos tanto el de esquivar un obstaculo por contacto, como el de esquivar un obstaculo con ultrasonidos, con el comportamiento de seguir hacia la luz, por lo cual RJV11 sigue la luz esquivando los obstaculos.

seguir la luz esquivando con contacto


seguir la luz esquivando con ultrasonidos



Próxima entrega: Práctica 4 - Control PID: el robot equilibrista

24.2.11

Prática 2 - Obteniendo información sensorial

24.2.11
Presentamos el nuevo modelo de RJV11



Obteniendo información:

En este vídeo se ve como se va actualizando la información referente al ultrasonidos, sensor de luz, tensión de la batería y memoria libre.
Mostramos el nombre del robot, el valor recogido por el ultrasonidos medido en milímetros, el valor crudo y porcentaje de la luz medida por el sensor de luz, la tensión de la batería y la memoria libre.



Control del robot por sonido:

RJV11 gira para calibrar el sensor de sonido con el ruido de las ruedas en movimiento, al dar una palmada, si esta estático, inicia el movimiento hacia adelante, si esta en movimiento, se para.



Bump & Go! usando sensores de contacto:

En este vídeo podemos comprobar como el robot, al chocar contra un ostaculo, y por lo tanto presionar el sensor de contacto, se detiene, retrocede y gira un angulo aleatorio.



Bump & Go! usando sensores de ultrasonido:

En este vídeo podemos comprobar como el robot, al detectar un obstaculo cerca, se detiene, retrocede y gira un ángulo aleatorio.



Comportamiento sigue-pared para salir de un laberinto:

Hemos programado el robot con un controlador de tipo P para que de potencia a las ruedas según el error de la distancia a la que esta de la que debería estar, de este modo conseguimos que el robot gire a la izquierda cuando esta muy cerca de la pared, o a la derecha cuando se aleja, y si el error es 0 avance hacia adelante.



En una primera aproximación para resolver el problema de seguir la pared, se nos ocurrió hacerlo con un control reactivo por casos, según unos rangos de error. Este método resulto ser demasiado brusco.

En una segunda aproximación hicimos un control reactivo P proporcional al error. No funciono del todo mal, pero aun seguía siendo bastante brusco.

Como solución final seguimos usando un control reactivo P proporcional al error, pero en lugar de usar la ecuación de una recta, nos decidimos por usar la ecuación del cubo del error. De esta manera si el error es pequeño corregirá más suavemente, y según el error sea más grande la velocidad de las ruedas aumente/disminuya más rápidamente. Con este sistema probamos diferentes combinaciones y al final nos quedamos con el correspondiente a la gráfica azul.

Aquí podemos ver algunas de las formulas que seguimos para la velocidad de los motores:


Calibración del sensor de ultrasonidos:

1. ¿Cuál es la distancia real máxima y mínima que puede medir el sensor?

Distancia mínima : 40 mm
Distancia máxima : 2070 mm aunque hay casos en los que nos llegaba a detectar hasta 2520 mm

2. ¿Cual es el máximo ángulo con respecto a la pared para los que los valores son válidos?

El ángulo máximo que llega a medir son 50º, a partir de este ángulo ya no llega a medir distancia.

3. ¿Tiene el sensor un error sistemático, es decir, la media de su error no es
cero?

Desde la distancia de 200 mm hasta 1000 mm, el error es siempre 0, por lo tanto no tiene error sistemático.

4.
-1- Error sistemático

Medida real Valor medio
20 cm 21 cm
30 cm 30 cm
40 cm 40 cm
50 cm 50 cm
60 cm 60 cm
70 cm 70 cm
80 cm 80,4 cm
90 cm 91,1 cm
100 cm 101,5 cm
110 cm 111 cm
120 cm 127,7 cm

-2- Cono de apertura

Medida en x Medida en y
10 cm 9 cm
20 cm 13 cm
30 cm 13,5 cm
40 cm 11,5 cm
50 cm 18,5 cm
60 cm 20 cm
70 cm 24 cm
80 cm 16 cm
90 cm 21 cm
100 cm 20,5 cm
110 cm 20 cm
120 cm 7,5 cm

-3- Matriz de covarianza
[4.415833 , 4.5333333 ]
[ 4.5333333 , 56.32639 ]

10.2.11

Práctica 1 - Primeros pasos con el API e instalación eclipse

10.2.11
Control básico del motor:

- BasicMotor1: en este ejercicio hicimos uso de los métodos forward() y stop() del motor, y del método waitForPress() de los botones. No hubo mayor complicación para realizarlo, y el resultado se puede ver en el siguiente vídeo.


- BasicMotor2: para este ejercicio usamos el método rotate() del motor y seguimos usando el método waitForPress() de los bonotes para controlar la siguiente rotación de motor, de la misma manera que en el ejercicio anterior. El resultado en el siguiente vídeo.


- BasicMotor3: en este caso al usar el método rotateTo() del motor conseguimos que el motor se desplace para orientarse según su odometría interna. Sucesivas llamadas a rotateTo() con el mismo argumento no tienen efecto, puesto que el motor ya esta orientado a los grados indicados, como puede verse en el siguiente vídeo.


Para obtener el mismo resultado que en el apartado anterior, es necesario que la odometría interna del motor sea puesta a cero antes de efectuar la rotación, con la ayuda del método resetTachoCount(). De esta manera conseguimos que el motor rote 45º respecto de donde se encuentra. El resultado de este ejercicio es el mismo que el del apartado anterior.

Visualización de la odometría del motor:

Lo primero que se hizo en este apartado fue resetear la odometría del motor para ajustarla a la posición del brazo acoplado a él, para tener una mejor visualización de la coordenadas. Gracias al método getTachoCount() obtenemos en cada momento la odometría del brazo según lo vamos moviendo. El último punto que se trato fue conseguir que la visualización de la odometría en el LCD trabajara en un rango de [0º,360º), para ello hubo que hacer ciertas conversiones de módulo a la odometría obtenida en cada momento. En el siguiente vídeo se muestra el valor de la odometría según se varía el ángulo del brazo.



Cuadrado de calibración de movimiento:

La realización del recorrido para hacer un cuadrado es algo sencillo, 4 rectas y 4 giros. Lo interesante de este ejercicio fue comprobar que a pesar de alinear a RJV11 en el punto de salida con la mayor precisión posible, el punto final del movimiento varía en cada una de las repeticiones del experimento, como se puede apreciar en la siguientes fotos.

Alineando lo mejor posible a RJV11

El punto 0 representa donde debería haber acabado el robot. Del 1 al 7 representan el punto donde acabó RJV11 en cada una de las siguiente 7 repeticiones del ejercicio.

Por otra parte, el cuadrado descrito por RJV11 dista mucho de ser perfecto.



Esto es debido en parte a que a pesar de introducir las medidas del diámetro y separación de ruedas correctamente, estas se ven alteradas por el peso del robot y por las sacudidas de su estructura debido al movimiento. Para intentar minimizar este efecto, a la hora de hacer el montaje de RJV11 intentamos seguir ciertas directrices: minimizar el peso del montaje, concentrar la mayor parte del peso sobre las ruedas tractoras, conseguir una estructura estable. También a la hora de efectuar los movimiento se tuvo en cuenta dejar cierto tiempo de margen para que la estructura del robot quedase en equilibrio antes de efectuar otro movimiento.

También las irregularidades, desniveles y distintos materiales del terreno tienen efecto sobre la trayectoria de RJV11, por ello se decidió utilizar una velocidad prudente para la realización del ejercicio.

Por otra parte también hay que tener en cuenta el error sitemático de los encoders de los motores.

Visualización de la trayectoria:

Usamos como base el programa del cuadrado para este apartado. No fue especialmente dificultoso una vez nos dimos cuenta de que hay que pasar los grados a radianes. Al igual que en el ejercicio de visualizar la odometría, trabajamos en un rango de [0º,360º). A continuación se puede ver un video del LCD mientras se hace el recorrido.


Una de las cosas que nos dimos cuenta en este punto, es que la odometría interna de los motores tampoco es perfecta, puesto que en condiciones iguales, la ejecución del mismo programa nos proporciona salidas distintas por el LCD. a continuación se pueden ver cuatro capturas de cuatro ejecuciones distintas del mismo programa con salidas distintas.


Cálculo de la matriz de covarianza:

Para el cálculo de la matriz se repitió 10 veces desde el mismo punto, dirección y sentido, un movimiento de 1 metro. Marcando en cada una de las repeticiones donde acabó el movimiento, y comprobando al igual que en el ejercicio del cuadrado, que difícilmente el movimiento acaba donde esta previsto, ni en el mismo sitio. A continuación una imagen donde se puede apreciar donde debería haber acabado el movimiento teóricamente, y donde lo hizo en realidad.

El teórico punto final es el centro de coordenadas. Y cada uno de los números se corresponde con cada una de las repeticiones del movimiento.

Para calcular la matriz de covarianza, medimos cada uno de los puntos respecto del origen punto de inicio del movimiento, y con ayuda de un programa en java especificamente diseñado para ello, la obtenemos. Los valores resultantes son los siguientes:

[0.006025 , 0.033375]
[0.033375 , 1.136125]


Próxima entrega: Práctica 2 - Obteniendo información sensorial

Niños que pueden "asistir a clase" gracias a robots

Buenas a todos, esta mañana he visto una noticia en la tv y me a resultado interesante, por eso la comparto con los blogueros, asi podemos comentarla cada uno aver que les parece.

Lyndon Baty, es un estudiante de secundaria en Estados Unidos, quien no puede asistir a la escuela debido a que su sistema inmune es casi inexistente, producto de una enfermedad que afecta su riñón, utiliza un avatar robot va a clases por el para seguir aprendiendo y no perder su vida social.

El avatar robótico que tiene una altura de 1.20 metros, está equipado con una pantalla, micrófon, parlantes y una cámara.

Baty se conecta al dispositivo desde su casa por medio de una computadora, se traslada de salón como cualquier otro alumno y también puede seguir en contacto con sus compañeros.

El costo del robot es de US$ 4800 más US$ 1200 del servicio anual, tiene compatibilidad con red WiFi, calidad de imagen similar a la del Skype, baterías con una duración de 6-12 horas.

Lydnon no sólo va a clases, también va a la cafetería y platica con sus amigos en el patio de la escuela.

La madre de Lyndon dice que el avatar ha cambiado su vida, haciendo que el adolescente tenga un motivo por que vivir.

27.1.11

Práctica 0 - Introducción al entorno Lego NXJ

27.1.11
La última versión de leJOS ya está instalada en los ordenadores del laboratorio, por lo que este paso nos lo hemos ahorrado. Pero para realizar experimentos en casa no viene mal tenerlo instalado en nuestros ordenadores personales, en este caso en uno con el sistema operativo Ubuntu. Para lo cual debemos tener instalados los paquetes necesarios en nuestro ordenador, para ello debemos ejecutar los siguientes comandos en la terminal:

sudo apt-get install sun-java6-jdk
sudo apt-get install libusb-dev libbluetooth3 ant nano


Una vez tenemos estos paquetes, la instalación no tiene mayor dificultad que seguir los pasos del manual de prácticas: descargar leJOS, descomprimirlo, configurar las variables de entorno, y compilar leJOS con el comando ant.

La instalación del firmware en el ladrillo también nos la hemos podido saltar, puesto que ya teníamos instalada la ultima versión (0.85).

Ejecutando los primeros ejemplos:

En este paso aprendemos como poder ejecutar código propio en RJV11. Para practicar usamos programas de ejemplo suministrados por leJOS, que posteriormente nos servirán para curiosear por su código. Mostramos el procedimiento a seguir para el fichero HelloWorld.java:

- Entramos dentro del directorio donde esté ubicado el fichero.
- Compilamos el código fuente con nxjc HelloWorld.java. Esto nos crea el fichero HelloWorld.class.
- Enlazamos y creamos el fichero con nxjlink HelloWorld -o HelloWorld.nxj.
- Ya tenemos creado el fichero ejecutable (HelloWorld.nxj). Ahora debemos descargar el fichero en el ladrillo. Para ello enchufamos el robot al ordenador a través de USB, lo encendemos, y ejecutamos sudo /usr/local/lejos/bin/nxjupload HelloWorld.nxj. El ladrillo emitirá un sonido indicándonos que la descarga se ha realizado con éxito.
- Para que RJV11 ejecute el programa, debemos navegar por el menú del ladrillo hasta Files > HelloWorld.nxj > Execute program. RJV11 nos saluda con un emotivo "Hello World" por su pantalla.


A continuación probamos el comando nxjbrowse. Para ello ejecutamos sudo /usr/local/lejos/bin/nxjbrowse. Este comando nos ofrece una interfaz gráfica para gestionar los ficheros y memoria del ladrillo, y nos da la posibilidad de ejecutar desde aquí los programas que tiene cargados. También nos permite configurar el nombre de nuestro robot, y así lo hicimos, por lo que finalmente nuestro robot fué bautizado oficialmente con el nombre de RJV11.

Ya sabemos como poder usar los programas que escribamos en RJV11, pero aún nos queda saber programarlo. Hasta la próxima clase de prácticas nos entretendremos en curiosear con los códigos de ejemplo.

Siguiente entrega: Práctica 1 -Primeros pasos con el API e instalación eclipse

22.1.11

Habemus nuevo template

22.1.11
Ya puestos a hacer un blog, ¡pues que quede curioso! Por eso hemos decidido personalizarlo un poco más allá de lo que permiten los templates que trae por defecto blogger. Hemos tomado como base el template City Sleep, cambiando poquitas cosas: la imagen de cabecera con siluetas de seis famosos robots, y la imagen para citar texto, porque la que venía por defecto era bastante fea. No descartamos hacer algún cambio adicional más adelante.

Modificaciones posteriores:
26.1.11: añadimos también un favicon de fabricación propia (se nota).

Helicópteros constructores colaborando

Me acabo de topar con este vídeo de helicópteros robot colaborando entre ellos para construir una estructura. Una vez reciben que tipo de estructura tienen que construir funcionan de manera autónoma, y deben coordinarse para construirla. Es un trabajo de la Universidad de Pensilvania.


Visto en Microsiervos.
Más información en GRASP Laboratory, University Of Pennsylvania.

20.1.11

El Valle inexplicable

20.1.11
Tras la clase de ayer, en la que José María Cañas hizo mención a la mayor aceptación y respuesta por parte de los humanos ante robots con forma y apariencia reconocibles, me vino a la mente el llamado Valle inexplicable. Un principio propuesto por el robotista japones Masahiro Mori en 1970:
La respuesta emocional de un humano hacia un robot hecho en apariencia y comportamiento muy similar al humano, incrementará positivamente y de forma empática, hasta alcanzar un punto en el que la respuesta emocional se vuelve de repente fuertemente repulsiva. Cuando la apariencia y comportamiento del robot se vuelven indistinguibles al ser humano, la respuesta emocional vuelve a crecer de forma positiva y se va aproximando a niveles de empatía como los que se dan entre humanos.
Fuente y más información: Wikipedia, Microsiervos, Kiari.

19.1.11

El 4º miembro del grupo

19.1.11






RJV11













Faltaba por presentar al 4º componente del grupo, este es RJV11, nuestro robot de practicas

Las tres leyes

Aderecemos con un poco de literatura nuestro mundo de unos y ceros recordando las tres leyes de la robótica escritas por Isaac Asimov:
1. Un robot no debe dañar a un ser humano o, por su inacción, dejar que un ser humano sufra daño.

2. Un robot debe obedecer las órdenes que le son dadas por un ser humano, excepto si estas órdenes entran en conflicto con la Primera Ley.

3. Un robot debe proteger su propia existencia mientras dicha protección no entre en conflicto con la Primera o la Segunda Ley.
Esperemos que podamos implementarlas en nuestro pequeño RJV11, si no tened miedo, mucho miedo...

El grupo!

Como somos personas educadas y de buen hacer, lo primero es presentarse con una bonita foto de grupo:


A continuación nos presentamos individualmente para que no haya lugar a confusión:
 Rubén Hijas Martín
 Juan Manuel Fernández Galeano
 Víctor Fernández Rielves

Las mentes más despiertas ya habrán deducido de donde proviene el nombre de nuestro blog, y del que será nuestro futuro robot. RJV11 será presentado oficialmente lo antes posible.

Proximamente más.
 
◄Design by Pocket, BlogBulk Blogger TemplatesThe Blog Full of Games;