Acabo de escribir una parrafada y he dado a cerrar el firefox... En fin, la idea era:

- Si el encoder se pone dentro del motor, hay holgura en la rueda y la odometría no va bien si hay holgura.
- Si el encoder se pone fuera, en las ruedas, hay holgura en el motor, pudiendo suceder que el control mande a la rueda que se mueva un poco y ésta no se mueva nada.

La única solución parece ser minimizar la holgura.

Por si acaso, lo que necesitamos es un motor que cumpla:

- Unos 15 vatios.
- Con eje pasante.
- Reductora de 25:1 o 30:1
- Un encoder de cuadratura de al menos 100 pasos por vuelta.

Si conocéis uno de menos de 360€ y me avisáis me haríais un gran favor. El caso es que han buscado y no han visto nada más barato.

Si el encoder lo pones en la rueda ves en todo momento el desplazamiento real. Si le mandas al motor moverse y la rueda no lo hace, hay una realimentación que entrará a un PID que metera más duty al motor para que la rueda alcance la velocidad deseada.

Yo creo que para vuestro caso lo mejor es un encoder en la rueda, al que podéis dar bastante resolución o poner ruedas mayores en el peor de los casos, no sé me parece lo más exacto.

Hola a todos,

Voy a exponer mi opinión sobre el tema.

- Utilización de un PC como sistema de control:

Definitivamente si. Acorta enormemente el tiempo de desarrollo, permite el manejo de multitud de drivers y librerías gratuitas que en ningún caso que puede equiparar a los códigos disponibles para VHDL (o Verilog) en OpenCores.

Por otra parte existen ya placas nano-itx con procesadores Atom, suficiente para tratar imágenes.

Hay que añadir que el coste de las FPGAs y material de desarrollo no es precisamente económico en la mayoría de los casos.

- Plataformas grandes:

Estoy a favor, el pasado y el futuro de la robótica está en la simplificación de tareas que realizan personas, abaratando costes o aumentando en calidad de vida, así que es necesario experimentar con plataformas que puedan realizar tareas reales. 6 Kg de robot no me parece ninguna barbaridad.

- Odometría en ruedas:

Pese a que la holgura entre engranajes y ejes es cierto que da un error, este error no es acumulativo porque nunca será mayor que la holgura del sistema mecánico. El error incremental proviene de las zonas de apoyo de las ruedas, me explico.

Las ruedas están recubiertas de materiales gomosos que dan mejor agarre y son ligeramente deformables. Cuando sobre las ruedas se produce una aceleración, estas bandas gomosas se deforman lo que produce que el punto de apoyo no sea el esperado, o que el diámetro de la rueda se modifique durante un corto periodo de tiempo.

Por otro lado, si no existiese la zona gomosa, la rueda tendería a derrapar, lo que es un desastre desde el punto de vista de la odometría.

La conclusión desde mi punto de vista es que habría que cuantificar cual es la diferencia en la calidad de la odometría desde un punto práctico, ya que lo que se evalúa es el conjunto motor + rueda, y que únicamente dependiendo de la calidad de ambos se puede saber si es realmente provechoso gastar el dinero en motores, ruedas y/o precisión en los sistemas de fijación.

Perdón por el tocho que os acabo de soltar.

luisj, has pensado en pasar el código que tenéis desarrollado en ICE a Orca?

Un saludo,
Joviwap

Hablaré largo y tendido mañana en el laboratorio respecto a vuestros comentarios de la odometría y los motores... a ver qué sale.

joviwap:
La verdad es que yo soy poco más que un mandado en el laboratorio. Al principio se barajó la idea de basarnos en Orca, el problema es que, en nuestra opinión, han tomado una mala decisión a la hora de entender las conexiones. Me explico:
Cuando se usa Ice se puede usar "a pelo" o con servicios de suscripción. Según me dijo "el que manda", Orca funciona con suscripción, y esto es inapropiado en robótica porque fuerza a una de dos:
a) Que se desperdicie mucho ancho de banda en transmisiones que los clientes quizás no necesitan. Dado que lo más probable es que se transmita por wifi, el ancho de banda es un recurso limitado. Esto es grave sobre todo cuando se mandan imágenes.
b) A suscribirte y quitar la suscripción dinámicamente. Esto no desperdicia ancho de banda pero queda muy feo.

En resumen, creemos que es mejor no imponer ese tipo de restricciones y que cada componente interaccione como qiera según lo vaya necesitando. También es cierto que RoboComp tiene la mayoría de la funcionalidad que tiene Orca.

De todas formas, no nos parece mala idea hacerlo compatible. Sin embargo no es algo que tengamos en mente porque por ahora sólo estamos colaborando en el proyecto cuatro personas y estamos más preocupados de que el robot haga más cosas. Si tu o cualquier otro se quiere unir a RoboComp ( http://robocomp.wiki.sourceforge.net/ ) será recibido calurosamente. De hecho ubanov se está pensando hacer un módulo de reconocimiento de voz.