Se ha anunciado el OSHWCon 2012 que tendrá lugar los días 21, 22 y 23 de septiembre en Madrid. Segunda edición de este evento organizado por Synusia, cuya entrada es gratuita, y totalmente recomendable para todos los que nos gustan estos temas. El año pasado asístimos y sin duda este año repetiremos.

Copio el correo que ha enviado la organización para quien no conozca este encuentrro:

Por segundo año consecutivo, desde Synusia queremos anunciar que durante los días 21, 22 y 23 de septiembre se celebrará el OSHWCon 2012 en Madrid. El OSHWCon es un encuentro anual de 3 días que tiene como objetivo difundir el uso del Hardware Libre y  promocionar la electrónica y la filosofía del «Hazlo tú mismo». Tendrá lugar en el Centro de Formación Padre Piquer de Madrid los días 21, 22 y 23 de septiembre de 2012.

http://oshwcon.org

La anterior edición del OSHWCon, el año pasado, fue un auténtico éxito gracias a la calidad de las ponencias y al interés de los asistentes. Más de 350 personas acudieron a compartir conocimientos y a poner en común técnicas y proyectos basados en el conocimiento libre.

Durante la OSHWCon se ofrecerán charlas, talleres, mesas redondas, exposición de proyectos personales y sobre todo, un lugar de encuentro para profesionales y aficionados al mundo de la electrónica. La asistencia es libre y gratuita y está pensada para que nadie se quede fuera. Se programarán desde actividades de iniciación, hasta charlas y talleres de alto nivel técnico.

A partir del día 14 de Mayo queda abierto el plazo de aceptación de ponencias, talleres y presentaciones de proyectos personales, que este año tendrán premio. Los temas de interés de la organización quedan recogidos en el call4papers que puede ser consultado en:

http://oshwcon.org/es/call4papers (Castellano)
http://oshwcon.org/ca/call4papers (Catalán)
http://oshwcon.org/en/call4papers (Inglés)

El plazo de presentación de actividades termina el día 23 de julio y en próximos días comunicaremos los premios para los mejores proyectos personales OSHW que se presenten, así como las bases del concurso.

Las páginas para realizar las propuestas de actividades están disponibles en:

http://oshwcon.org/es/propuesta_charla (Castellano)
http://oshwcon.org/ca/proposa_activitat (Catalán)
http://oshwcon.org/en/suggestyourtalk (Inglés)

Como parte de nuestra idea de compartir el conocimiento la entrada es totalmente gratuita, aunque por motivos de aforo es necesario realizar inscribirse. Dispondremos de 450 plazas para asistentes que quedarán disponibles a partir del día 1 de junio.

Por favor, rogamos máxima difusión del call4papers y animamos a toda la comunidad del Hardware Libre a participar con alguna actividad. Así mismo, agradecemos cualquier tipo de ayuda organizativa. Para cualquier duda o consulta podéis consultarnos en oshwcon@oshwcon.org.

Además, anunciamos la creación de una lista de anuncios para que podáis manteneros informados fácilmente. Esta lista sólo se usará para correos importantes y es de sólo lectura. Está disponible en:

http://lists.oshwcon.org/listinfo/oshwcon-announce

Esperamos veros este año en el OSHWCon. ¡Impulsemos el uso de tecnologías abiertas y libres!

EL viernes por la tarde después de quedar en el Medialab salimos para Barcelona en el AVE, llegar, cenar y quedamos a las 12:00 de la noche con Jonathan de la organización del AESSBot (gracias), que venía con un equipo de Sevilla para recogernos y llevarnos al hostal que la organización había reservado a los participantes, donde también nos encontramos con la gente de A.R.D.E. Madrid que había preparado un robot de sumo para el concurso.

El concurso empezaba a las 8 de la mañana, nos recibieron con un desayuno y nos dieron una bolsa de comics a cada equipo y una camiseta del concurso a cada participante, dejamos todos los trastos en la habitación que había para ello, con comida, mesas y herramientas para trabajar en los robots y poder pasar la homologación de los distintos robots hasta las 10 de la mañana que empezaban las fases clasificatorias, homologamos un minisumo y cuatro velocistas (uno de ellos en el último minuto) y tras la charla de la organización a todos los participantes empezaron las clasificatorias de minisumo y velocistas.

La ronda de clasificación de velocistas no era la clásica de sumar el tiempo de 2 vueltas que se suelen ver en la mayoría de los concursos, la organización se había currado un sistema para medir el tiempo que tardaba el robot en dar cada vuelta, con varios sensores distribuidos a lo largo del recorrido lo que permitía conocer el tiempo que hacía el robot en los distintos sectores de la pista (estilo Fórmula 1),

En la imagen se puede ver parte de la pista de velocistas, donde Arnau (uno de los participantes) se prepara para comenzar la ronda de clasificación de su robot, los arcos miden el tiempo que tarda en recorrer el robot los distintos sectores del circuito, creo recordar que había 6 arcos a lo largo de los algo más de 12 metros de recorrido, arriba en el monitor se puede ver el robot en la pista según la vista de una de las cámaras, también aparece el tiempo de vuelta actual y de los distintos sectores, el tiempo de carrera y el tiempo de vuelta más rápido durante la carrera de clasificación del robot, que sería el que contaría para pasar a las finales.

En el concurso había 23 velocistas (si recuerdo correctamente) de los que 8 pasarían a las finales de la tarde, los participantes tenían dos intentos de 3 minutos donde se les anotaba el tiempo de vuelta más rápido, en este tiempo el participante podía coger el robot y cambiar la configuración de éste (sin que se parase el reloj de los 3 minutos), los 8 robots que tardasen menos tiempo en dar una vuelta en uno de sus dos intentos de 3 minutos pasarían a las carreras de robot contra robot de la tarde. Entre el primer y segundo intento había aproximadamente una hora que los participantes aprovecharon para trabajar en los robots (más sobre ésto más tarde).

Al haber tenido la pista con poco tiempo (una semana) no tuvimos tiempo de preparar y probar un programa para detectar las curvas y rectas y establecer distintas constantes y velocidades en éstas, así que llevamos un programa muy simple de velocidad constante y Kp y Kd fijas durante todo el recorrido, con el que tuvimos la suerte de clasificar los 4 robots que llevabamos entre los 3 para la tarde. El robot que entró octavo fue la versión del Robot Zero de este blog (que marcó un tiempo de vuelta rápida de 4.9s (2.5 m/s de velocidad media en la vuelta aproximadamente), los otros tres robots que lelvamos con la nueva electrónica (sin usar los encoders ya que no llevabamos el programa preparado) entraron tercero, sexto y séptimo, 4.6 s el más rápido.

Junto a nosotros entraron los robots de Dani y Alberto (segundo y cuarto clasificado), Silvestre y Piolin, ya conocidos por la mayoría de los que seguimos los concursos y que suelen ser los robots favoritos este año, y dos robots de Andreu del equipo Smith (que domina últimamente el sumo), Smith Pelopincho y Peloondulado (primero y quinto clasificado, 4.4-4.5 s el tiempo de vuelta más rápido), que para mi fueron la sorpresa del concurso e hicieron sudar a Piolin en las finales de la tarde. Otros robots con bastante trabajo quedaron fuera de las finales pero que seguro nos lo pondrán difícil en el futuro, estuve viendo los robots que llevaban los participantes y alguno de ellos promete bastante.

Pelopincho:

Pelopincho es un robot parecido al que hemos estado desarrollando aquí en el blog, según me contaba Andreu que nos has seguido desde que empezamos con el Robot Zero (gracias), usa motores de Pololu, una Baby Orangutan como microcontrolador y placa de sensores de Pololu (creo recordar que me dijo que sólo usa 4 sensores), la novedad es que lleva una hélice para aumentar la normal del robot. El robot tan sólo pesa 65 gramos, la hélice le proporciona un empuje de 15 gramos más, lo que le da una mayor fuerza de rozamiento y por tanto entrar y correr más en las curvas. Un robot que espero poder seguir comentanto en este blog, ya que también implementaba una idea para detectar las curvas y las rectas sin que dependan del radio y que puede funcionar muy bien en los robots (nada más que tenga un rato me miro lo que me has mandado Andreu).

Al mismo tiempo que la clasificatoria de Velocistas se realizaba también la de MiniSumo, donde me dieron una buena paliza en mi primer intento de minisumo de entradas anteriores en este blog..

Los combates se podían ver en los monitores y las cámaras podían medir el tiempo de encendido de los minisumo, por si alguno de ellos empezaba a moverse antes de los 5 segundos reglamentarios. Creo recordar que eramos 12 robots incritos en esta prueba y teníamos que luchar todos contra todos, pasando a la tarde los 8 robots que mejor lo hiciesen. Destacar los robots del equipo Smith que llevaba 5 minisumos (me ganaron los 5 x_x) consiguiendo que entrasen todos a las finales. Mi robot ganó a 3 oponentes (uno de ellos no se presentó) y perdió contra el resto.

Una vez terminadas las clasificaciones de sumo y velocistas, serían las dos de la tarde más o menos, tuvieron lugar la de rastreadores y sumo. Me suena que había 21 robots de sumo y 9 de rastreadores, pasaban los 8 mejores de cada categoría a la tarde. No seguí la clasificatoria ya que aproveché para irme a comer los bocadillos que nos había preparado la organización.. Lo que si recuerdo es al equipo ESIBOT que se había dejado encendido el robot por la noche y por la mañana no les funcionaba, se dieron cuenta cuando empezó la prueba y tuvieron que desmontar y montar el sumo entero mientras ya estaban en marcha los combates, aún así pasaron a las finales e hicieron un buen papel.

No tengo fotos de la ronda de clasificación de sumo y rastreadores (es más las anteriores se las he cogido prestadas a Terraguea45 del foro de Arduino =P).

A las 3 ó las 4 de la tarde comenzaron las finales, las gradas estaban llenas de gente (en algunos momentos como se saliese fuera podría resultar difícil hasta volver a entrar), y siendo el recinto donde se desarrollaba el evento tan grande no hubiese estado mal que le hubieran dejado un poco más de espacio al concurso..

Se comenzó con la final de Rastreadores, no puedo contar mucho sobre esta prueba y robots que participan en ella ya que nunca la he seguido, gana el robot que tarde menos tiempo en recorrer el circuito desde que pasa por el arco de entrada al de salida, las líneas negras en las bifurcaciones indican el camino más corto, el robot ganador hizo un tiempo cercano a los 9 s.

Concluida la final de rastreadores emepezó la de MiniSumo, donde había 5 robots de un mismo participante!, el ganador fue Mini-JMV del equipo D.P.E. Bots que venció la final a uno de los robots del equipo Smith.

Mini-JMV es el robot negro que gana el primer combate al robot del equipo Smith ya que éste pierde un componente durante el transcurso del combate (no se puede caer ninguna pieza).

Terminado el sumo comenzaron los velocistas donde teníamos nuestros cuatro robots, estabamos muy lejos de los puestos de premios ya que los robots de Dani y Alberto por un lado y los de Andreu por otro eran muy superiores a los nuestros, ya que los nuestros llevaban un programa simple de velocidad y constantes fijas. No tengo todos los vídeos de estas pruebas ya que estabamos los tres participando, pongo los que tengo y me resultan más interesantes, pudimos ver varias carreras muy largas en estas finales.

Enfrentamiento para pasar a semifinales de Pelopincho (o peloondulado, no sé cuál es de los dos) contra Piolin, carreras igualadísimas, las dos primeras resultaron en empate, se acabo el tiempo y en la tercera creo recordar que Pelopincho pisó una línea roja, pasando a la siguiente eliminatoria Piolin. Y es que las carreras estuvieron tan emocionantes que hasta el árbitro que llevaba la cuenta del tiempo no se dió cuenta del paso de éste…

Una de las carreras Piolin (robot más ancho) vs Pelopincho/ondulado (robot más fino), 4 minutos de duración.

Nuestros robots iban a velocidad constante haciendo buen tiempo para lo que teníamos de programa (en este vídeo Pelayo le da una paliza a Maiki mientras yo grabo ¬¬):

El ganador del concurso fue Silvestre ganando la final 2-0 a Piolin, no tuvo ni que ponerlo al máximo de velocidad para ganar el concurso, el tercer clasificado fue Pelopincho/ondulado que ganó a uno de nuestros robots 2-1. El único vídeo que tengo de Silvestre (robot verde) es éste, eliminando a uno de nuestros robots (robot rojo) en semifinales:

Por último quedaba la final de sumo, donde los mejores 8 robots de la mañana se veían en las eliminatorias, los ganadores fueron dos sumos del equipo Smith (no tengo el vídeo) que ganaron las semifinales a Pegasus (uno de los robots más veteranos de los concursos, 8 años) y a ESIBOT (que al principio del día no funcionaba y todo pintaba bastante mal para él).

El tercero fue Pegasus (robot negro) en unos combates igualadísimos con SuperESIBOT (robot rojo).

Pues esto fue el sábado en el AESSBot 2012, un concurso muy entretenido con un nivel alto en todas las pruebas donde los robots favoritos han hecho lo que se esperaba de ellos..El que quiera competir con estos robots va a tener que currarselo bastante.

El domingo entregaban los premios y había otra prueba, no fuimos ya que nos dimos un paseito por Barcelona hasta que salió el tren a las cinco y media de la tarde, a las ocho en Atocha, no se puede pedir más.

No sé si la organización pasará un cuestionario a los participantes, por si no lo pasa dejo aquí algunas de mis impresiones (lo que he podido ver del concurso, que debido a que estabamos con los robots no han sido todas las pruebas):

Según la normativa cuando se homologan los robots no se puede cambiar nada de éstos, ni recargar las baterías. Nosotros como muchos de los participantes ajustamos los robots un poco (no mucho ya que con el programa que llevábamos no había mucho que tocar, más bien nada, cambiamos alguna rueda para probar y poco más..) y dejamos cargando la batería cuando nos fuimos a comer en algún robot, tampoco teníamos la necesidad ya que con una batería podemos hacer varios concursos, además llevamos un dc-dc por lo que la alimentación del motor no depende de la batería. Muchos de los participantes hacían lo mismo o almenos yo escuchaba continuamente a los cargadores de Lipo avisar de batería cargada. En el resto de concursos yo siempre he visto a los participantes tocar el programa sobre la pista del concurso.

Por lo que esta norma la mayoría de los casos no se aplica ya que no tiene sentido, si tenemos 12 horas de concurso lo normal es poder trabajar en los robots, además es lo que nos gusta y por lo que vamos al concurso.

Una vez que empiezan las finales comprendo que los robots no se puedan tocar y recargar, a no ser que haya que hacer una reparación en un tiempo establecido, ya que no se le puede estar haciendo esperar al público, nosotros en las finales no tocamos nada. Lo que si permitiría (como surgió el tema en el concurso) es el cambio de baterías, mientras este cambio se haga en un tiempo muy rápido (inferior al minuto) que no haga esperar a la gente que ve el concurso. Si el objetivo es obtener la mayor velocidad y que la prueba sea más espectacular, no poder cambiar la batería de una forma rápida es una limitación en el diseño que puede tener un efecto importante en lo anterior.

Evitar que pase todo lo anterior en un concurso largo es imposible de hacer, ya que para eso los robots tendrían que estar bajo llave.

Por lo demás sólo felicitar a los participantes y a la organización. Su actitud era la correcta (aquí todos venimos (o la mayoría) a divertirnos) y la preparación técnica de las pruebas del concurso estaba muy bien, a mi el concurso de velocistas me ha encantado, aquí se ve que la organización ha trabajado en la prueba tanto como los constructores en sus robots, y esto es muy importante ya que para que esto vaya a más tienen que hacerlo tanto los organizadores como los participantes.

Por otro lado el trato recibido también ha sido genial, y los pequeños detalles como desayuno, comida y camiseta cuentan bastante y animan a volver.

Estos son los concursos y organizadores por los que los patrocinadores deben apostar

Gracias por este AESSBot!, esperamos poder volver al próximo (Noviembre).

Debido al poco tiempo que hemos tenido para preparar el robot hemos hecho lo primero que ha salido.. La idea ha sido colocar los sensores lo más bajo posibles para detectar a los robots más pequeños, como sensor según nos han recomendado varios participantes de las pruebas de sumo (gracias) hemos elegido dos GP2Y0D340K, que se encargan de detectar al oponentes a larga distancia, y un GP2Y0D310K (sensor central) que detecta al oponente a una distancia más corta, ambos modelos son sensores digitales que sólo nos indican si hay un objeto delante.

Junto a los sensores de suelo que venían con el robot estos son todos los sensores que lleva el robot, para integrarlos en el robot se han hecho un par de pcbs, un pcb que lleva los sensores para detectar al oponente y donde se conectan los sensores de suelo delanteros, y otro pcb para acoplar cada sensor de suelo al robot, se pueden ver en las imagenes (el esquema de los sensores es el recomendado en su datasheet).

En la imagen se puede ver que hay dos baterías, una de 7.4 V para alimentar a los motores y otra de 3.7 V como la que llevamos en los robots velocistas, para alimentar al microcontrolador y sensores del robot.

Con esta placa de sensores se pretende detectar hacia donde se mueve el oponente, de tal forma que si lo perdemos mirando cuál ha sido el último sensor que lo ha detectado podemos saber hacia que lado ir a buscarlo. Si el oponente está muy cerca los sensores pueden dar una lectura falsa, los sensores de larga distancia darán esa lectura falsa antes que el sensor central de corta distancia, también con este sensor sabemos cuando el robot está más cerca, llevar sensores de varias distancias nos da más opciones en la programación a la hora de solucionar los problemas que puedan surgir en el combate.

Los robots de sumo además de los sensores delanteros suelen llevar sensores en los lados y detrás para detectar al oponente, en este robot no hemos tenido tiempo de incluirlos.

En el vídeo un ejemplo del funcionamiento de los sensores, el robot sigue a la caja y cuando el sensor central detecta que está cerca avanza, cuando los sensores de suelo ven la línea negra el robot retrocede.

Los sensores van muy bajos y por lo tanto es posible que se lleven los primeros golpes, por lo que hay que protegerlos, sin herramientas para trabajar los materiales que estos robots requieren lo único que he puesto es un trozo de aluminio, esperemos que sea suficiente..

Para tener el robot completo falta la placa de la electrónica que lea los sensores y controle los motores, para controlar los motores un puente en H de Pololu que tenía de otro robot conectando dos motores a cada canal, es más que suficiente para estos motores tan pequeños.

En esta placa del puente pinchamos otra con un ATmega328p, pcb, que se va a encargar de leer los sensores del robot y establecer el sentido de giro y velocidad de los motores.

La placa incluye un dc-dc de Pololu para subir la tensión de la lipo de 3.7V a los 5V que necesitan los sensores y el microcontrolador para trabajar, en este caso un poco más ya que también he añadido un regulador disipativo para proteger la electrónica, no sea que se toque el ajuste del dc-dc dando éste más de 5V y quememos la electrónica (sensores, micro y puente en H), la electrónica es cara y la diferencia de consumo no la vamos a notar ya que la capacidad de la lipo es más que suficiente para muchos combates, se va a descargar antes la batería de los motores.

Un pulsador para comenzar el combate, conector de sensores, conector al puente en H y unos pocos leds para ayudar a la programación, lo primero que ha salido =)

Un diseño muy sencillo de robot con el que comenzar en la prueba, 474 gramos y es que el lastre ayuda bastante a alcanzar los 500 gramos necesarios para maximizar nuestra fuerza de empuje.

En cuanto a la programación del robot lo que ha dado tiempo a hacer esta tarde y así se queda, y es que la pista de velocistas salió el viernes pasado y aún nos queda programarlos… un programa simple de girar y moverse para detectar al oponente a una velocidad baja, y cuando el sensor central de corta distancia lo detecta poner el pwm al máximo.

Pues éste es nuestro primer intento de minisumo que esperemos homologue y tenga sus primeros combates en el AESSBot 2012.

Adjunto el código del segundo vídeo hecho esta tarde (probablemente lleno de errores =) ) y que va a llevar el robot a falta de cambiar los sensores de línea.

//MiniSumo
#define F_CPU 16000000UL	
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
 
//Motores
 
#define INA1 PORTB2
#define INB1 PORTB1
#define PWM1 PORTD5
#define PWM2 PORTD6
#define INB2 PORTD7
#define INA2 PORTB0
 
//Leds
 
#define LEDY PORTC5
#define LEDR PORTC4
#define LEDV PORTC3
#define LEDA PORTC2
 
//Entradas
 
#define PULSADOR PORTC0
#define SENSORST PORTC1
#define SENSORSD PORTD0
#define SENSORSI PORTD4
#define SENSORI PORTD3
#define SENSORC PORTD2
#define SENSORD PORTD1
 
//Funciones
 
void inicializar_micro(void);
void motor_derecho(char movimiento, unsigned char velocidad);
void motor_izquierdo(char movimiento, unsigned char velocidad);
 
//Variables
unsigned char velocidada = 255; 
unsigned char velocidadg = 190; 
unsigned char velocidad = 127;
unsigned char velocidad_avance = 100;
unsigned char velocidadl = 64;
volatile unsigned char retroceder = 0;
volatile unsigned char ultimo_sensor = 0;
 
int main( void ) 
{
 
	char pulsador = 1;
	char sentido = 0;
	static int tiempo = 0;
 
	inicializar_micro();
 
	PORTC |= (1<<LEDR);
	while(pulsador != 0 )
	{
		pulsador = PINC & (1<<PULSADOR);
	}
 
	PORTC &= ~(1<<LEDR);
	_delay_ms(500);
	_delay_ms(500);
	PORTC |= (1<<LEDR);
	_delay_ms(500);
	_delay_ms(500);
	PORTC &= ~(1<<LEDR);
	_delay_ms(500);
	_delay_ms(500);
	PORTC |= (1<<LEDR);
	_delay_ms(500);
	_delay_ms(500);
	PORTC &= ~(1<<LEDR);
	_delay_ms(500);
	_delay_ms(500);
 
	sei(); //Habilitar interrupciones globales.
 
	motor_derecho(0,255);
	motor_izquierdo(0,255);
 
	while ( 1 ) 
	{
 
		if(retroceder == 1)
		{
			PORTC &= ~(1<<LEDY);
			PORTC &= ~(1<<LEDV);
			PORTC &= ~(1<<LEDR);
			motor_derecho(2,velocidad);
			motor_izquierdo(2,velocidad);
			tiempo = 0;
 
			_delay_ms(500);
			retroceder = 0;
 
			PORTC |= (1<<LEDA);			
		}
 
 
		else if((PIND & (1<<SENSORC)) == 0) //sensore central
		{
			motor_derecho(1,velocidada);
			motor_izquierdo(1,velocidada);
			PORTC |= (1<<LEDR);
			PORTC &= ~(1<<LEDV);
			PORTC &= ~(1<<LEDY);
			PORTC &= ~(1<<LEDA);
			tiempo = 0;
//			_delay_ms(300);
		}
 
		else
		{
			PORTC &= ~(1<<LEDA);
 
			if( ( (PIND & (1<<SENSORI)) == 0) &&  ((PIND & (1<<SENSORD)) == 0) )
			{
				motor_derecho(1,velocidad);
				motor_izquierdo(1,velocidad);
				PORTC |= (1<<LEDV);
				PORTC |= (1<<LEDY);
				PORTC &= ~(1<<LEDR);
				tiempo = 0;
			}
 
 
			else if(((PIND & (1<<SENSORI)) == 0) && ((PIND & (1<<SENSORD)) != 0) )
			{
				motor_derecho(1,velocidadg);
				motor_izquierdo(1,velocidadl);
				sentido = 1;
 
				PORTC |= (1<<LEDV);
				PORTC &= ~(1<<LEDR);
				PORTC &= ~(1<<LEDY);
				tiempo = 0;
			}
 
			else if( ( (PIND & (1<<SENSORI)) != 0) &&  ((PIND & (1<<SENSORD)) == 0) )
			{
				motor_derecho(1,velocidadg);
				motor_izquierdo(1,velocidadl);
				sentido = 0;
				PORTC |= (1<<LEDY);
				PORTC &= ~(1<<LEDR);
				PORTC &= ~(1<<LEDV);
				tiempo = 0;
			}
			else
			{
				PORTC |= (1<<LEDY);
				PORTC &= ~(1<<LEDV);
				PORTC &= ~(1<<LEDR);
				PORTC |= (1<<LEDA);
 
				if(tiempo < 900)
				{
					if(sentido == 1)
					{
						motor_derecho(1,velocidad);
		  	 			motor_izquierdo(2,velocidad);
					}
					else
					{
						motor_derecho(2,velocidad);
		  	 			motor_izquierdo(1,velocidad);
					}
					tiempo++;
				}
				else
				{
						motor_derecho(1,velocidad_avance);
		  	 			motor_izquierdo(1,velocidad_avance);
				}
			}
		}
 
		_delay_ms(3);
	}
	return 0;
}
 
 
void inicializar_micro(void)
{
	DDRC = 0x3C;  //0011 1100
	PORTC = 0x00; //0000 0000
	DDRB = 0x07;  //0000 0111
	PORTB = 0x00;
	DDRD = 0xE0;  //1110 0000
	PORTD = 0x00;
 
	//Configurar PWM timer0
	TCCR0A = 0xA3; //1010 0011
	TCCR0B = 0x02; //0000 0010
	OCR0A = 0;
	OCR0B = 0;
 
	//Interrupciones
	PCICR |= (1<<PCIE1); // Interrupción sensor trasero suelo
    PCMSK1 |= (1<<PCINT9); //Habilitar pin
 
	PCICR |= (1<<PCIE2); // Interrupción sensore delantero suelo
    PCMSK2 |= (1<<PCINT16); //Habilitar pines
	PCMSK2 |= (1<<PCINT20);
}
 
void motor_derecho(char movimiento, unsigned char velocidad)
{
	OCR0B = velocidad;
	switch(movimiento)
	{
		case 0:
		{
			PORTB &= ~(1<<INA1);
			PORTB &= ~(1<<INB1);
		}
		break;
 
		case 1:
		{
			PORTB |= (1<<INA1);
			PORTB &= ~(1<<INB1);
		}
		break;
 
		case 2:
		{
			PORTB &= ~(1<<INA1);
			PORTB |= (1<<INB1);
		}
		break;
 
		default:break;
	}
}
void motor_izquierdo(char movimiento, unsigned char velocidad)
{
	OCR0A = velocidad;
	switch(movimiento)
	{
		case 0:
		{
			PORTB &= ~(1<<INA2);
			PORTD &= ~(1<<INB2);
		}
		break;
 
		case 1:
		{
			PORTB |= (1<<INA2);
			PORTD &= ~(1<<INB2);
		}
		break;
 
		case 2:
		{
			PORTB &= ~(1<<INA2);
			PORTD |= (1<<INB2);
		}
		break;
 
		default:break;
	}
}
 
ISR(PCINT1_vect) //Trasero
{
	if((PINC & (1<<SENSORST)) != 0) //cambiar a línea blanca
	{
//		motor_derecho(1,velocidad);
//		motor_izquierdo(1,velocidad);
//		_delay_ms(200);
 
		if(ultimo_sensor == 0) //Derecho
		{
			motor_derecho(1,velocidadg);
			motor_izquierdo(1,velocidadl);
			_delay_ms(200);	
			motor_derecho(0,255);
			motor_izquierdo(0,255);			
		}
 
		else if(ultimo_sensor == 1) //Izquierdo
		{
			motor_derecho(1,velocidadl);
			motor_izquierdo(1,velocidadg);
			_delay_ms(200);	
			motor_derecho(0,255);
			motor_izquierdo(0,255);			
		}
	}
 
	PCIFR  |=(1<<PCIF1); //Limpiamos el flag de interrupción.
}
 
ISR(PCINT2_vect) //Delantero 
{
//	if(((PIND & (1<<SENSORSD)) != 0) || ( (PIND & (1<<SENSORSI)) != 0))
//	{
//		retroceder = 1;
//	}
 
	if((PIND & (1<<SENSORSD)) != 0)	//cambiar a línea blanca
	{
		retroceder = 1;
		ultimo_sensor = 0;
	}
	else if((PIND & (1<<SENSORSI)) != 0) //cambiar a línea blanca
	{
		retroceder = 1;
		ultimo_sensor = 1;
	}
 
	PCIFR  |=(1<<PCIF2); //Limpiamos el flag de interrupción.
}

El Medialab-Prado, esta institución que ha servido para reunirnos, probar nuestros proyectos, conocernos en persona y mucho más cierra sus puertas hasta el próximo Otoño para continuar las obras de rehabilitación que se estaban haciendo en el edificio contiguo, llamado Serrería belga. El último Viernes Openlab (que era donde nos reuníamos) será el 4 de Mayo y a partir de entonces seguirán habiendo reuniones, pero con menos contenido, en Intermediae-Matadero hasta que terminen las citadas obras.

Por unos 90 euros más envio (sobre los 15 euros por correo normal, 13 días ha tardado) podemos comprar en Fingertech Robotics esta base de robot minisumo, incluye cuatro motores de corriente continua (podemos elegir la reductora entre varias opciones) con sus cuatro ruedas de gran agarre, tres sensores de fotodiodo y fototransistor para detectar la línea blanca que delimita la zona de la prueba de minisumo, y una base bien construida donde integra todo lo anterior. Los motores vienen pegados a la base, las ruedas se acoplan en el eje del motor y se sujetan mediante un tornillo que atraviesa la rueda, los sensores se situan en la parte inferior de la base con los taladros correspondientes para que pasen sus patas a la parte superior, en la parte inferior encontramos una plancha de acero que nos proporciona un centro de gravedad bajo y nos ayuda a conseguir los 500 gramos de robot permitidos en la normativa para maximizar nuestra fuerza de empuje.

Si tenemos que montar esto nosotros, entre comprar los 4 motores, las ruedas y en fabricar la base nos va a costar lo mismo o más, sin tener en cuenta el tiempo y la necesidad de herramientas para poder trabajar estos materiales, supongo que lejos del alacance de la mayoría. Por 120-130 euros de robot con envio y aduanas me parece un precio bastante bueno para lo que ofrecen (primera impresión sin probar el kit por mi parte).

El envio viene bien empaquetado (las baterías no vienen con el kit, se pueden comprar en la tienda junto a muchas otras cosas).

Kit de la base de minisumo (click en la imagen para mayor tamaño):

Por defecto la base del robot se envia con los motores 50:1, yo lo he pedido con los motores 20:1 que según mis cálculos (espero que no los hiciese muy mal) serían suficientes para mover el robot, enlace a los motores.

Mirando la tabla de esta página para los motores 20:1 nos dan un par de 0.75 kg-cm @ 6V, con una rueda de 3 cm de alto, 4 motores @ 6V, y poniendo un coeficiente estático de la rueda por lo alto (o eso espero x_x), me sale que los 20:1 son suficientes para transmitir la fuerza máxima de empuje que puede hacer el robot con una masa de 500 gr, si no me he equivocado en el cálculo que por otro lado tampoco es que lo haya pensando mucho.. y otro tema pueden ser las aceleraciones e inercias. Ante la duda lo mejor es coger los 50:1 que recomiendan las personas que han hecho este kit (ya que si los ponen por defecto es que serán los más adecuados) y tienen experiencia llevando este robot a concursos. Las ruedas tienen un agarre muy alto, si se deja el robot sobre un papel o cartulina al levantar el robot el papel se pega.

Para detectar la línea blanca de la zona de combate tenemos tres sensores (dos delante en los lados y uno detrás en el centro) que se colocan por la parte inferior del robot:

Vista lateral del robot donde aparece un sensor delantero de suelo.

El peso total de la base es de unos 344 gramos, con la batería, electrónica y materiales adicionales para la construcción del robot será fácil alcanzar los 500 gramos máximos permitidos.

Las dimensiones del sumo son próximas a las máximas de 10 x 10 cm permitidas, quedando un espacio entre los motores de 26 x 53 x 26 mm según la página para meter una batería lipo pequeña.

Con este kit tenemos los motores, las ruedas y una base para el robot de minisumo, nos quedaría añadir los sensores para detectar al oponente (si los llevamos), la batería y la electrónica del robot. Si queremos colocar los sensores lo más bajo posibles el espacio es limitado.

El sensor grande que se suele usar de infrarrojos va muy justo en ese espacio (no lo he probado aún), por lo que si queremos llevar los sensores bajos puede que haya que pensar en sensores más pequeños.

Mi primera impresión de esta base (a falta de probarla) es muy buena para su precio (si, esto de hacer robots es similar a quemar el dinero), ideal para empezar con minisumo y para quien no tiene las herramientas y medios para trabajar los materiales necesarios en los robots de sumo. Ahora queda ver si conseguimos un robot con ella para el concurso..

Respecto al velocista tenemos el robot que empezamos a preparar para el concurso de Madrid, por lo que la electrónica ya la tenemos más o menos lista y funcionando desde principios de año.

Nos queda la parte difícil, la programación e intentar hacer que corra, ya que el nivel de velocistas en los concursos es bastante alto, con robots muy probados y que funcionan muy bien.

La electrónica nos está funcionando bien y podemos poner el pwm al 100% en las rectas sin tener reseteos, ésta era una de las dudas que teníamos ya que estamos usando el dc-dc de Pololu que nos proporciona muy poca corriente de salida.

En el vídeo se puede ver con el pwm al 100% en las rectas cuando se enciende el led verde.

Pues con esto andamos este mes en las reuniones semanales, por otro lado a ver si sale ya la pista del concurso!, que no queda mucho y nos gustaría poder probar el robot antes de ir en su pista, para intentar hacerlo lo mejor posible =).

A la espera de que salga la placa oficial de Arduino Leonardo (y nos enteremos de como van los pines…) seguimos desarrollando versiones de placas compatibles con la oficial en el foro de Arduino en español. La última en llegar ha sido vinciDuino evo Proto, vinciDuino evo es una serie de placas que toman como base la vinciDuino inicial y añaden distintas funcionalidades, como puede ser una zona para prototipar, un conector de tarjetas uSD, un módulo de comunicación integrado, etc.. Lo que se nos vaya ocurriendo en este hilo del foro de Arduino en español en el que todo el que quiera puede participar, bien en la parte técnica del desarrollo de las distintas versiones de placas o con sus ideas y opiniones.

La primera placa que se ha diseñado y pedido es la vinciDuino evo Proto en la que ha estado trabajando F. Malpartida, es una placa similar a la vinciDuino original que añade una pequeña zona de islas/topos para prototipar, si alguien está interesado en probar esta placa quizás pueda conseguir alguna primera unidad en electroFun.

Toda la información de las nuevas vinciDuino evo se irá añadiendo a la página de vinciDuino, de momento aquí dejo sólo el esquemático y archivos de eagle de la evo Proto rev A (hay que modificar alguna cosilla de la serigrafía):

• Esquema.
• Ficheros de eagle.

Y unas imagenes de la placa montada:

Si te gusta esto del “hardware libre” (antes conocido como “electrónica”) y quieres colaborar en el desarrollo de distintas versiones de vinciDuino puede hacerlo aquí.

De momento éstas son las distintas versiones que hemos hecho de la familia vinciDuino:

Para quien no lo conozca, Pachube es una web donde poder transmitir la información que generan nuestros dispositivos (lo que se conoce como Internet de las cosas). Todos alguna vez hemos creado/tenido un dispositivo que genera información que nos gustaría consultar: Un sensor de temperatura o de humedad, un contador de entradas a un recinto, cuantas veces se ha ejecutado un comando, etc. Cualquier cosa que queramos saber y se pueda medir es susceptible de usarse con Pachube. Eso si, nuestro dispositivo debe tener una conexión a Internet para poder subir los datos (Wifi, ethernet, GPRS u estar conectado a otro dispositivo que lo tenga como un PC). La ventaja es que mediante nuestro ordenador/móvil/tablet podremos consultar los datos que nuestro dispositivo envía en la web de Pachube de una forma gráfica. El servicio es gratuito, podemos hacer que nuestros feeds sean públicos o privados, podemos consultar el historial de datos y enviar alarmas y notificaciones a nuestros dispositivos. Tiene limitaciones como que no se puede hacer más de 100 peticiones por minuto, pero en la mayoría de los casos nos da de sobra.

Voy a explicar de una forma sencilla cómo enviar los datos, aunque si queréis profundizar tendréis que leer la documentación. Lo primero que hay que hacer es registrarse en su web. Es un proceso sencillo y rápido.

Lo segundo es crear una key en el menú My keys. Esta sirve para poder autentificarnos en las acciones que enviamos a Pachube. Además se les asignan permisos para que pueda ser usando en cualquier feed, en todos nuestros feeds (públicos o privados) o en unos determinados feed de nuestra elección. Además se les asigna los permisos de lectura de feeds, creación de feeds, actualización de feeds o borrado de feeds. Igualmente tiene restricciones avanzadas como caducidad de la key, sólo dejar a una IP o acceder desde una URL concreta para ejecutar el comando. La guardamos y ya nos aparecerá en el menú de My keys.

El siguiente paso es crear un feed en el menú Create a feed. Un feed no es nada más que un servicio donde se almacenarán los datos que envíe nuestro dispositivo y que puede ser consultado a posteriori. Puede ser creado directamente desde las web de Pachube o desde la API de Pachube. Para crearlo debemos rellenar datos sobre su nombre, la ubicación de nuestro dispositivo, si es privado (sólo lo podemos consultar nosotros) o público (cualquier puede consultarlo), etc. Finalmente tenemos que añadir tantos datastreams como distintos datos envía nuestro dispositivo: Si por ejemplo es un sensor de temperatura y de humedad tendremos que dar de alta dos datastreams. Los datastreams necesitan un identificador único en ese feed, un tag (nombre) que lo identifique, un nombre de la unidad en que se va a medir y el símbolo que se usa para esa unidad de medida. Lo guardamos y ya nos aparece en el menú de My feeds.

Ahora si accedemos al menu de My feeds podemos ver nuestro feed y si pulsamos sobre el podemos observar entre otras cosas qué número único le ha asignado Pachube en el campo Website.

Para meterle datos simplemente tenemos que rellenar los datapoints, que son los datos de nuestro sensor. Podemos hacerlo manualmente desde la misma página del feed, pero no tiene sentido ya que se supone que será nuestro dispositivo (u otro intermediario) conectado a internet el que los proporcione. Este debe tener la opción de comunicarse mediante peticiones HTTP a la web de Pachube. Yo lo voy a enseñar desde el nivel más bajo, pero si el dispositivo intermedio es un PC podéis usar curl mediante scipts o las librerías que vuestro dispositivo tenga para usar TCP/IP y HTTP. Voy a poner un ejemplo de una petición PUT para actualizar un feed que contiene como datastream el uso de una supuesta CPU de un servidor ubicado en la isla Perejil. Me conecto al puerto 80 del host api.pachube.com y le envío esto:

PUT /v2/feeds/48063.csv HTTP/1.0
Host:api.pachube.com
Content-Length:6
X-PachubeApiKey:nL8l2h_XRp62DSXwV48jhFtjXtWSAKxZUmJUZlExNmpXOD0g
 
cpu,90

Después de lanzar esa petición, si todo ha ido bien, recibiremos esta respuesta del servidor de Pachube:

HTTP/1.1 200 OK
Date: Tue, 13 Mar 2012 16:22:37 GMT
Content-Type: text/plain; charset=utf-8
Connection: close
X-Pachube-Logging-Key: logging.AzQG9Tniho13k7PtFTBo
X-PachubeRequestId: a498efd825d85bbeaab4be98ba3fa014874ca175
Cache-Control: max-age=0
Content-Length: 1
Age: 0
Vary: Accept-Encoding

Que indica con el código 200 que todo ha ido bien y que se ha guardado el datapoint en nuestro datastream. En nuestra petición le hemos indicado la URL de nuestro feed con la extensión csv para indicar que los datos que queremos subir están en ese formato, pero también podemos subirlos en XML o JSON (ver aquí una guía rápida). También hemos de enviar la key que tiene permisos para escribir en nuestro feed. Finalmente enviamos los datapoints en formato <datastream>,<valor> (uno por línea).

Así si nos vamos a la URL de nuestro feed (en este caso https://pachube.com/feeds/48063) podremos ver toda la información del feed: nombre, localización, lectura de los datos en formato JSON, XML y CSV y finalmente un gráfico que podemos configurar a nuestro gusto para ver cómo han ido evolucionando los valores:

Se ha anunciado el AESSBot 2012 que este año cumple su 15 edición, este concurso de robótica tendrá lugar del viernes 4 al 6 de Mayo dentro de la 30 edición del Salón Internacional del Cómic, en la Fira de Barcelona en Montjuic.

El concurso tendrá las siguientes categorías: velocistas, sumo, minisumo, rastreadores, humanoides y AESSBots, con premios para los 3 mejores en cada una de ellas.

Hay una bolsa de ayudas para los gastos del viaje para las personas de fuera de Cataluña, así como un 30% de descuento en los viajes de renfe.

La preinscripción al concurso está abierta hasta el 31 de Marzo, más información en la guía del participante o en su página web.

Por las distintas categorías, facilidades para ir, ubicación y premios.. el concurso tiene una pinta estupenda, me parece que por aquí nos vamos a plantear seriamente el ir.