Muchas gracias, tiene mucho sentido lo que decis. Yo ya habia pensado no procesar todos los pixels... Pero los calculos que dais son esclarecedores. Esta claro que tendria que usar otros micros (e.g. dsPIC)

Como veo que cuando me meta con el video voy a tener que trabajar mucho aspectos que hoy no controlo. Antes de meterme con micros nuevos me parece que voy a empezar con un proyecto menos ambicioso, pero que me de tablas con el analisis sencillo de datos y con las comunicaciones con el PC

Un robot que con ayuda de GPD12 asociado a un motor paso a paso pueda escanear distancias a los objetos proximos, en cada paso el motor toma una distancia formando el par (angulo, distancia). Dotarle de odometria (aprovechando el sistema de bola de algun raton de PC) y dejarle que rastree las habitaciones. Pasar las lecturas de distancias y recorrido a un PC via RF y analizando los datos levantar un plano de la habitacion y los objetos que hay en el suelo.

No es ver como seria con la camara, pero se le parece 😉 . Podria el robot tomar decisiones si cabe por un hueco o no. Me parece que con los PIC16 podre hacer esto. Aun asi tendre que ponerme las pilas con algunas cosas que no controlo:

-comunicaciones via RF o bluetooth con el PC (puerto serie o USB)
-darle una vuelta como representar los datos que seran una sucesion de tablas de distancias y angulos y recorrido del robot. para poder representar lo que seria el plano de la habitacion. A priori, no me parece imposible ya que solo es trigonometria puesta en accion (angulos y distancias) Pensaba usar Excel y/o Mathematica para el analisis de datos puesto que no tengo experiencia en programar en Windows o Linus.

Le voy a dar unas vueltas, a ver hasta donde llego. Cuando lo tenga mas maduro y avanzado lo comparto con vosotros en el blog (Nunca lo he hecho, supongo que no sera dificil subir proyectos).

gracias,

zapa

Espero no desviarme del tema: Si quieres te puedo asesorar en la parte de los mapas, pues hice un PFC con un nomad200 en la uni:

http://www.victoralbendin.org/docs/robotica.html " onclick="window.open(this.href);return false;

En mi caso hice un sistema multiagente behabior based con lógica difusa, que se encargaba de cartografiar un mapa, identificando los obstáculos.

Opté por un "mapa de ocupacion", en base al cual, a través de campos de potencial (fuentes y sumideros) servía de base para diversos comportamientos, como:
-evitar obstátuculos
-evitar pasado.
-caminar por zonas seguras.

No utilicé una cámara ya que ya había otros compis trabajando en ese aspecto.

Lo crucial en estos proyectos bajo mi experiencia es que:

-Hay que Utilizar varios tipos de sensores para actualizar el mapa (sonar+infrarrojos), como los sentidos en los humanos.
-Cómo integrar una lectura instantánea de los sensores con la información que tengas ya del mapa.
-los obstáculos se pueden mover, por lo que las celdas de ocupación "caducan" pasado un tiempo.
-Ha de ser "tolerante"; es decir, ni la odometría ni los sensores son perfectos: has de introducir la incertidumbre de alguna manera.

Os puede parecer una "paranoia", pero a mi me vino de perlas lo siguiente, para la actualización del mapa:
http://es.wikipedia.org/wiki/Teorema_de_Bayes " onclick="window.open(this.href);return false;
http://es.wikipedia.org/wiki/Hist%C3%A9resis " onclick="window.open(this.href);return false;

La compañía esta de Nomad liberó el simulador un tiempo después, de manera que puedes utilizarlo para probar tus algoritmos de control:

http://nomadic.sourceforge.net/ " onclick="window.open(this.href);return false;

Te comento todo esto porque me da la sensación leyendo este foro que lo complicado siempre es el hardware y lo fácil el software. Yo creo que es un 50%, 50% salvando las distancias y el objetivo de los proyectos.

También tengo que admitir que, en mi caso, moviendo un slider del interfaz gráfico puedes hacer que el robot se mueva como quieras, incluso que varíe su forma de pensar en función si una agenda de objetivos. Lo mismo esto en un prototipo que evite obstáculos y poco más sobra.

victorblue, no te confundas, la parte hardware es la más fácil con muchísima diferencia (en este caso al menos). Otra cosa es que tú mismo te metas donde nadie te ha llamado y líes la madeja de tal forma que complica todo lo que en un principio era fácil.

Por otro lado, si usas la visión, en teoría sería más que suficiente ese "sentido", ya que nosotros ni tenemos infrarrojos ni ultrasonidos 😛 , pero ya de ponerte a detectar... http://www.robotshop.ca/high-end-lasers-obstacle-detectors-2.html " onclick="window.open(this.href);return false; son bastante "económicos" 😕

Tanto la mecánica, como la electrónica, como el software deben ir compensadas tanto en esfuerzo como en dificultad. Hay muchos problemas de electrónica que se pueden resolver fácilmente modificando el software o la mecánica, igualmente que hay muchos problemas de mecánica que se pueden solucionar modificando el software o la electrónica y muchos problemas de sofware que se pueden solucionar modificando la mecáncia o la electrónica.

Sin embargo esto se debe hacer en fase de diseño ya que una ve montado la dificultad para modificar la mecánica es mayor que modificar la electrónica y esta es mayor que el software (por lo que terminamos cargando todos los problemas al software). Una buena planificación y un par de prototipos suelen compensar esto pero muchas veces no se hace por desconocimiento, por falta de tiempo o de recursos, etc.

S2

Ranganok Schahzaman

PD: victorblue, me ha encantado lo del proyecto VAGO (y el toque retro que tiene), ¿se podría minimizar la estructura para meterlo dentro de la mascota? envíame un MP y hablamos

Estupendo, vuestras respuestas son fuente de inspiracion, va en serio. Da gusto pertenecer a esta asociacion/foro.

Muchas gracias.

zapa