Encoders incrementales y absolutos

(Diferencia entre revisiones)

Revisión actual

Voy a delinear lo que conozco de los encoders.

El encoder absoluto me entrega la posición absoluta en qué está parado desde el mismo momento en que se enciende el sistema.

No importa si hay un reinicio o cualquier cambio de situación, el encoder no se puede perder porque está codificado dentro de él: entrega la posición absoluta. Hay de 360 y 720 posiciones por vuelta. También hay de menos resolucion. Son pequeños.

El encoder incremental sirve para un sistema rotativo a velocidad. Si estamos hablando de movimientos de algunos grados, no tiene resolución a menos que se usen ranuras microscópicas. Y éstas no son fáciles de "leer". Para nada.

Pero además necesita un reposicionamiento de "home" al inicio, cuando el sistema se enciende o se reinicia.

Ojo que no es fácil: al encender, en el robot no se sabe dónde está "parada" cada articulación del sistema.

Hay que girar libre hasta llegar a una marca de "home". ¿Para qué lado? Ojo con esto.

Y si uno quiere una buena resolución, y debido a los movimientos en relativamente baja velocidad, hay que tener un exclente sistema de lectura de las ranuras.

Miren que no es sólo ver la ranura. Hay que tener un método de seguridad que evite que el sistema quede parado justo sobre el borde de una ranura y se quede contando pulsos al pepe. Esto pasa SIEMPRE en los sistemas caseros.

Generalmente se usa más de un sensor, desplazados... micrones. En un sistema como el nuestro deberían ser micrones, nada más.

Por supuesto que ambos tipos de encoder se compran hechos, y los incrementales entonces no van a tener los problemas del sensor, pero repito, generalmente se usan en sistemas de giro a velocidad, no en movimientos acotados pero muy precisos, como el nuestro.

Bueno, es mi opinión. Ojo que aquí más que nunca hay que tener en mente el precepto "lo barato sale caro".

He tenido muchas, muchas luchas con encoders.

--Edu 19:23 21 mar 2008 (ART)

Estoy de acuerdo con el encoder absoluto. --Adrian S.A. 19:33 21 mar 2008 (ART)

Edu: vos sos el que sabes! tiene que ser absoluto, por el reinicio en caliente

--Mastromec 19:52 21 mar 2008 (ART)

Una pregunta, si usamos el gray code, para grabar un disco, el encoder es absoluto? De cuantos bites necesitamos el encoder con gray code? de 8? Me pueden pasar un dibujito de un disco de gray code de los bites que nesecitemos para ver las posibilidades? podemos usar los leds de montaje superficial girados en el disco?, con un angulo entre ellos me refiero. la lectura de los pulsos es en un fototransistor? si fabricamos en cantidad podemos lograr un buen precio.

--Mastromec 21:57 21 mar 2008 (ART)

y sino un Resolver. http://en.wikipedia.org/wiki/Resolver_(electrical)

--Adrian S.A. 10:05 22 mar 2008 (ART)

Juan, el disco codificado Gray tiene una pista circular por cada bit que hace falta para lograr la resolución. Y debe hacer un juego de led emisor y fototransistor por dada pista, y MUY bien alineados. Para lograr 360 posiciones por giro, necesitamos 9 bits (9 pistas). Para lograr 720 posiciones por vuelta se necesitan 10 bits. Hay que tener cuidado con los problemas de detección falsa de flancos. En este artículo hay una imagen de como sería (menor resolución en este ejemplo) el disco:

http://robots-argentina.com.ar/SensoresAngulares_resolver.htm

Aquí hay un calculador para el código Gray (y de otras cosas también)

http://www.theory.cs.uvic.ca/~cos/gen/comb.html

Calculé allí el código Gray para 9 bits, pero como es un chorizo (512 valores), no lo copié.

Adrián, a mi entender (yo siempre mido con mi vara, y lo que es elctromagnético de algún modo me espanta) los resolver son bien complejos para hacer: problemas de núcleo de la permeabilidad magnética adecuada, bobinados muy prolijos, escobillas de muy buena calidad, maquinado preciso...

--Edu 13:18 22 mar 2008 (ART)

Tenemos que hacer intervenir en el analisis de la resolución necesaria, que la mayoria de los movimientos son angulos parciales, por lo tanto podriamos tener menos resolución aplicada al angulo maximo.

--Mastromec 16:40 22 mar 2008 (ART)

Tal vez se pueda solucionar poniendo 2 discos, uno de ellos montado sobre un engranaje multiplicador....
Como que con 2 discos de 4 bits (16 combinaciones) lograrías 16x16=256 combinaciones. ¿me explico?

--Adrian S.A. 17:09 22 mar 2008 (ART)

Por lo que estuve viendo tendremos que trabajar con 8 bites nomas, de este modo no es tan complejo el disco, saque una foto a un led de montaje superficial que podríamos usar, este tiene un cuadradito de 2x2 que seria lo que limita el tamaño de la ranura del disco. Todo no deberia superar los 40mm de diametro.

La lupa es la que se usa para medir la dureza, viene graduada en milimitros

--Mastromec 17:16 22 mar 2008 (ART)

con dos discos, uno de ellos montados sobre un engranaje multiplicador, podes multiplicar la resolución.--Adrian S.A. 17:21 22 mar 2008 (ART)

Yo sigo pensando en comprar encoders ya hechos, y cambiaré de idea cuando sepa que no los podemos comprar. Esto es muy crítico, el alma de la precisión y seguridad de los movimientos.

Cuando el ángulo de recorrido es chico, yo le pondría un engranaje. Si el ángulo máximo de recorrido es de 30º --por decir un valor--, bueno, un juego de engranajes con relación 1:12, es decir, que cuando la articulación recorra los 30º, el encoder da una vuelta completa. Seguro que entonces podemos usar encoders con menor precisión, pongámosle con 64 mediciones por vuelta, que valen menos o son menos complicados de hacer.

--Edu 18:09 22 mar 2008 (ART)

Edu: La primera opcion es comprarlos, estoy de acuerdo, y tambien me parece critico ya que "muchos" otros sistemas dependen de esta lectura. Sin embargo creo que podemos discutir la posibilidad de hacerlos en "paralelo" en algun momento. (seria bueno si es mas adelante y termino el talón)

Lo ultimo que paso de este tema y sigo con lo que creo estoy mas preparado, es un dibujo del disco gray que ya lo tengo en cad, y esta en diametro 46 exterior, ranuras de 1.4, espacio entre ranuras 0.7, diametro inicial 12, para un rodamiento SKF623, diametro de eje 3mm

pueden ver en amarillo 2 led de los 8 que llevaria. podemos cambiar los paso a paso por encoders??

--Mastromec 18:39 22 mar 2008 (ART)

A ver si me pasás el dwg de ese disco...
¿A que te referís con -"...cambiar los paso a paso por encoders"?
--Adrian S.A. 19:14 22 mar 2008 (ART)

Juan, supongo que la pregunta es si podremos hacer que un motor de CC con reducción avance y se ubique sobre cada uno de los valores del encoder, es decir, si tiene 32 posiciones, que dé 32 pasos por vuelta. Si tiene 200 valores, 200 pasos por vuelta. La respuesta es sí. Pero es mejor que el motor pap, porque al arrancar el sistema sabe dónde está. Obviamente, es el servo ideal para nuestro diseño.

--Edu 10:38 23 mar 2008 (ART)

Queria saber si podemos controlar los motorcitos de continua como los pap (me respondiste)

Era una pregunta directa, perdón, me referia a los paso a paso que puse a disposición del grupo, en verdad la experiencia con los pap que tengo, es que siempre me "falta" un plus de fuerza para que no salte, quizas no trabaje lazo cerrado (y soy mecanico claro), pero me gusta mucho mas la idea de usar los motorcitos IGNIS y controlarlo con una llave H, entonces nos estarian sobrando los pap que los podemos vender o canjear...

Adrian te paso el Cad del disco, si puedo hago cortar uno o dos para probar en plastico opaco.

--Mastromec 14:01 23 mar 2008 (ART)

Dibuje el disco en 3d, esta todo hecho con variables, o sea que pueden cambiar lo siguiente:

ancho de ranura

espacio entre ranuras

diametro de la primera ranura

angulo donde comienza la pista (esta es buena)

y puedo generar el cad para cortar el laser

--Mastromec 18:37 23 mar 2008 (ART)

una idea de como seria hacer un encoder:

1 disco en plastico opaco de diametro 46mm x 1mm de espesor

3 partes de corte laser en acrilico de 3mm 1 parte tiene un agujero de 47mm en el centro 2 partes con alojamiento para rodamiento SKF623 d3xD10x4

4 tornillos M4 Roscados en el acrilico de abajo

1 eje diametro 3mm con un resalto de 6mm para centrar el disco y un resalto de 8mm para hacer tope

los leds y los transistores de montaje superficial cortados en las tapas y pegados.

--Mastromec 19:36 23 mar 2008 (ART)

Los paso a paso, no me doy cuenta del tamaño de los que ofreciste, pero se podrían usan en las muñecas de las manos (dos movimientos) y en el cuello.

Si hacemos un enconder que funcione, será un muy buena experiencia y hasta podemos encontrarnos con un producto comercial para ofrecer. Fototransistores y diodos emisores se consiguen de 1,5 mm de diámetro.

--Edu 20:21 23 mar 2008 (ART)

Ok, dame los datos de UN diodo led y de UN fototransistor para montar

se me acaba de ocurrir como contrarrestar el tamaño del disco y la cantidad de bits. hacer un tambor formado por tantos discos de 2mm como bits quieras, cortados con las marcas 2,4,8,16 etc y leer a travez del tambor, en el interior los leds y exterior los transistores. una pregunta los leds estan todos encendidos siempre?

--Mastromec 20:45 23 mar 2008 (ART)

Los leds se pueden encender sólo al pedir una lectura. Ya te busco una hoja de datos.

Hubo un problema de interpretación mío: esos fototransistores tienen 1,5 mm de diámetro pero vienen montados en una cajita de 4,5 mm x 5,7 mm. Luego están los cilíndricos, de 3 mm de diámetro.

Habrá que buscar SMD (hay de 1,6 x 0,8 mm y de 2 x 1,2 mm, pero tengo que encontrar si los venden aquí).

--Edu 21:22 23 mar 2008 (ART)

Buscate uno común, yo lo acomodo, no te preocupes

pienso usar el area de trabajo del transistor y giro como un caracol los demas, el angulo girado lo corrijo en el inicio de la pista que corresponda. si podes pasame las medidas del formato

--Mastromec 22:14 23 mar 2008 (ART)

Una cosa: cuanto más grosor tenga el disco, más exactamente perpendiculares deben estar los sensores a su superficie, y más exactamente alineados, para que la pared del agujero no cambie momentánamente una lectura. No sé si me explico. A esa escala, el agujero es como un pozo: tiene una pared. Esto es importante, porque si leemos la posición justo en un flanco del cambio, podemos tomar mal el valor.

Quizás lo mejor es un disco transparente con sólo una cara pintada con pintura opaca muy delgada.

--Edu 22:38 23 mar 2008 (ART)

Vienen parejas diodo-fototransistor en forma de U. Se pueden poner múltiples discos del mismo diámetro, cada disco correspondiente con el peso del bit que le toque. Cada U envuelve a un disco. Creo que eso es lo que explicaba Juan, no?--Adrian S.A. 22:47 23 mar 2008 (ART)

Uno de estos encoders iría a parar al pie para medir el ángulo de la punta del pie.--Adrian S.A. 22:55 23 mar 2008 (ART)

Era la idea, pero no usando herraduras aunque podria ser...

yo pensaba grabar sobre el filo del disco y juntar los discos como un paquete con forma de tambor, es decir hueco, entrar dentro de este hueco con una herradura de 8 leds por fuera como alineados con el eje del tambor, y 8 fototr. por dentro.

En ves de cortar el tambor solo grabar una profundidad.

--Mastromec 22:57 23 mar 2008 (ART)

En algo así pensaba yo.(por lo que comentaste vos). En el dibujo no son exactamente optoacopladores. Son la pareja diodo - fototransistor en forma de U a los que se le intercepta la luz en medio.

--Adrian S.A. 23:34 23 mar 2008 (ART)

Imagino que deben haber encoders que usen la tecnología del dvd (ahora el bluray). Lectura de algún tipo de información mediante esa tecnología. Imagino la precisión. Supongo que ya debe estar inventado eso.--Adrian S.A. 01:25 24 mar 2008 (ART)

¿se acuerdan de los mouses a bolita? :)

O imaginen usar esta tecnología...

Here's how the sensor and other parts of an optical mouse work together:

The CMOS sensor sends each image to a digital signal processor (DSP) for analysis.
The DSP detects patterns in the images and examines how the patterns have moved since the previous image.
Based on the change in patterns over a sequence of images, the DSP determines how far the mouse has moved and sends the corresponding coordinates to the computer.
The computer moves the cursor on the screen based on the coordinates received from the mouse. This happens hundreds of times each second, making the cursor appear to move very smoothly.

--Adrian S.A. 01:32 24 mar 2008 (ART)

Concentrando un poco los pensamientos en la cosa práctica.

Analicemos qué necesitamos del encoder:

Necesitamos que nos dé la posición con exactitud en cualquier situación. Un fallo podía ser catastrófico (imagínense una pierna disparándose como en una persona por el reflejo del golpe de martillo en la rodilla)
Necesitamos que la posición sea absoluta. Ante cualquier situación que se presente, desde el encendido a reinicios, el robot tiene que saber en qué posición están sus partes móviles.

Las dos cosas nos indican algo: necesitamos una enorme precisión.

Una experiencia personal: el problemas de los encoders está en los flancos de paso de la banda de información.

El código Gray evita ciertos errores, pero persiste un problema.

Pido mucha atención aquí: ¿En qué condiciones se usan los encoders generalmente? Busquen en Internet y fíjense que los encoders tienen como parámetro los RPM que soportan. Es decir, una de las situaciones es aquella en la que hay un giro continuo. También hay encoders de una vuelta única.

¿Qué pasa cuando no hay un giro continuo?

Se presenta una situación: el sistema puede detenerse o hacer una medición sobre el flanco de cambio de código. ¿Qué pasa entonces? Como los sensores no van a estar alineados perfectamente (digamos en un orden submicroscópico) puede llegar a leerse cualquier cosa. ¿Cómo se evita? Con una enorme precisión mecánica y de alineación óptica. Es probable que haya algún método de computación de la lectura, porque los encoders suelen tener microcontroladores. Muchos entregan los datos como PWM o por un port serie.

¿Es fácil filtrar este problema? No es fácil.

Sería más fácil si estamos hablando de controlar una máquina girando constante y en un solo sentido. ¿Como? Se retrasa un poco electrónicamente el flanco de la pista del bit menos significativo y se toma esto como pulso de reloj para aceptar el cambio. ¿Qué produce esto? Asegurarse de que todas las otras pistas ya hayan cambiado cuando se toma la medición.

Pero que pasa si tenemor un sistema que se mueve de vez en cuando y se puede parar justo sobre el flanco. Difícil, difícil.

Ahora nosotros queremos armarlo.

¿Se puede lograr una gran precisión mecánica en un montaje de los sensores? No sé. Supongamos que usamos fototransistores SMD (la posición más critica es la del fototransistor, mucho menos la del LED). ¿Cómo los vamos a soldar para que queden bien alineados? No tenemos un armador de placas robótico, ¿o sí? Si usamos optoacoples de ranura (¿hay bien pequeños?, no estoy muy seguro) en el diseño de tambor propuesto, ¿podremos alinearlos bien a todos? Se sueldan con cuatro patitas, y el haz puede quedar o no alineado con el haz de los otros discos. Debereríamos hacer ajustes muy finos con osciloscopio, usando un cilindro con discos de ajuste o inventando un ajuste que nos permita asegurarnos de ver cómo está alineado todo.

Ahora me pregunto, porque me ha pasado en algunos diseños. ¿Cuánto tiempo nos va a llevar esto?

Quiero decir una cosa para cerrar: un encoder absoluto es algo en teoría simple, se nos ocurre que un fabricante debería poder "sacarlo del horno" al toque. Sin embargo, en las empresas especializadas vemos que estos encoders son más bien caritos. ¿Por qué es? ¿Son estúpidos?

--Edu 11:19 24 mar 2008 (ART)

Es cierto. Igual, debe haber forma de contrarrestar esto por software. Algún tipo de predicción de movimientos como para que no haga lo que no es lógico que tiene que hacer. Sabiendo que debería existir una especie de "cadencia" en los movimientos, lo que salga de ese ritmo debería estar mal.
Está sabiamente planteado lo que dijiste. Hay que estudiarlo mas a fondo.
Respecto del diseño de los encoders, se puede encarar pero hay que abrir un proyecto aparte. Y así, cualquier cosa que querramos diseñar.Propongo que abramos un proyecto aparte para trabajar en ese tema. Por ahí se prende mas gente que esté interesada solo en ese tema.
--Adrian S.A. 12:16 24 mar 2008 (ART)

Edu: en un 100% tenes la razón, yo tambien e tenido problemas con discos y el sentido de giro. ademas no es la intencion del proyecto (y hay que aprovechar el tiempo disponible)

Ya te habia dicho que me parecia correcto y adecuado usar encoders comerciales y te propuse cambiar o vender los pap para comprar encoders que son muchos, pero la presicion lo requiere.

pase todo el desarrollo porque ya me habia lanzado con esta idea antes y 2 cosas, 1 no podia parar, 2 queria compartirlo para ver su opinión.

Usaremos encoder comerciales si es posible mini y los mas economicos, si podes averiguar alguno lo voy montando en el modelo virtual.

--Mastromec 13:31 24 mar 2008 (ART)

Ya pedí precios en Silge, si querés ir viendo lo que hay buscá los encoder absolutos en esta página http://www.silge.com.ar/productos_beta.php?pagina=2&marca_id=4&letra=

--Edu 14:36 24 mar 2008 (ART)

Tengo la impresión de que ya es hora de hacer una prueba: Montar un brazo a un encoder, el que se defina, para poder moverlo en todas direcciones y a distintas velocidades. Registrar los datos del encoder y ver, en algún gráfico, el comportamiento y analizar qué tipo de falla puede aparecer. No se si me expliqué bien.
De paso irán apareciendo parte de los algoritmos que necesitaremos. Supongo.
Este banco de pruebas servirá para probar todo encoder que se cruce por el camino, aún si es diseñado por nosotros.
Algo así: (después lo borran)

--Adrian S.A. 16:37 24 mar 2008 (ART)

Copio para que vean qué buenos comerciantes son algunas empresas (Silge en este caso). Parientes de Gran Hermano, hacen preguntas en lugar de responder el dato solicitado.

«Le pido pueda informarnos los datos completos de la firma (razón social, CUIT, dirección, teléfonos, etc) para poder ingresarlos a nuestra base y emitir la cotización solicitada. Atte.»

--Edu 11:46 26 mar 2008 (ART)

Edu, se podra usar esto?, parece ser economico http://www.vishay.com/docs/57090/120e.pdf

--Mastromec 10:02 28 abr 2008 (ART)

Es un encoder incremental, es decir, manda pulsos al girar y nada más. Este es el sistema que, para saber dónde está ubicado el eje de giro, tiene que tener una posición de "home" (con otro sensor). Más bien sirven para controlar velocidad en giro libre.

Ya pregunté a Varitec por los encoders que ofrecen, pero no me respondieron. Hay gente que pone una página web y una dirección de mail, pero luego ni los miran.

Estuve pensando que si no conseguimos encoders absolutos a precio accesible, podemos usar los potenciómetros que vienen en los servos. Un servo cuesta alrededor de 25 a 35 pesos (us$ 8-10). Y no es un gasto que s ehace por el potenciómetro solo, luego de sacar el pote nos queda el motor con su reductor y su circuito de control y potencia (así se usan en muchos robotitos). Yo tengo algún potenciómetro de estos que saqué de un servo para hacerlo de giro libre.

No sé nada de estos potenciómetros, pero es de suponer que son mucho más resistentes y menos ruidosos que los potenciómetros comunes, ya que esto es crítico para que el servo funcione bien. Si tenemos en cuenta que un servo de estos se usa para volar modelos, algunos muy caros, y que se los usa muchas, muchas veces (en estos modelos el servo se mueve continuamente mientras el bicho está volando), es de suponer que la calidad del cursor y de la pista de deslizamiento/resistor debe ser muy buena.

Si ponemos dos o tres potenciómetros en lugar de uno y los leemos a todos para hacer un sistema redundante, es posible que obtengamos muy buenos resultados.

También es posible que se consigan potenciómetros en el mercado con calidad así, y durabilidad a muchos movimientos. Tenenos que averiguar. (Claro, siempre que cuesten menos que un servo.)

--Edu 11:15 30 abr 2008 (ART)

Ok, ya me habias explicado que necesitabamos encoders incrementales...

--Mastromec 17:11 30 abr 2008 (ART)

Los que necesitamos son los absolutos.

--Edu 16:45 2 may 2008 (ART)

si, absolutos

--Mastromec 16:48 2 may 2008 (ART)

Absolutamente los absolutos. :)

--Adrian S.A. 21:25 2 may 2008 (ART)

Lo mejor que consigo en precio, en varitel son de 8bit codigo gray $500 c/u AEW 8 GC H 6050

--Mastromec 13:34 5 may 2008 (ART)

Tendremos que hacerlos nosotros o comprar afuera, varían desde los us$ 50 (aunque yo tengo idea de haber visto unos a 15-20) a los u$ 750. Aquí deben traer los más caros.

--Edu 14:44 6 may 2008 (ART)

Obtenido de "https://robots-argentina.com.ar/androide/index.php?title=Encoders_incrementales_y_absolutos"

Proyecto Androide	Portada \| Acerca de \| Ayuda \| FAQ \| Páginas especiales \| Registrarse/Entrar
	Categorías: Electrónica \| Sensores Versión para imprimir \| Aviso legal \| Política de protección de datos \| Revisión actual

 Por lo que estuve viendo tendremos que trabajar con 8 bites nomas, de este modo no es tan complejo el disco, saque una foto a un led de montaje superficial que podríamos usar, este tiene un cuadradito de 2x2 que seria lo que limita el tamaño de la ranura del disco. Todo no deberia superar los 40mm de diametro.
-led 01.jpg
+[[Imagen:led 01.jpg]]
 La lupa es la que se usa para medir la dureza, viene graduada en milimitros
 --[[Usuario:Mastromec|Mastromec]] 17:16 22 mar 2008 (ART)
+----
+con dos discos, uno de ellos montados sobre un engranaje multiplicador, podes multiplicar la resolución.--Adrian S.A. 17:21 22 mar 2008 (ART)
 ----
+Yo sigo pensando en comprar encoders ya hechos, y cambiaré de idea cuando sepa que no los podemos comprar. Esto es muy crítico, el alma de la precisión y seguridad de los movimientos.
+Cuando el ángulo de recorrido es chico, yo le pondría un engranaje. Si el ángulo máximo de recorrido es de 30º --por decir un valor--, bueno, un juego de engranajes con relación 1:12, es decir, que cuando la articulación recorra los 30º, el encoder da una vuelta completa. Seguro que entonces podemos usar encoders con menor precisión, pongámosle con 64 mediciones por vuelta, que valen menos o son menos complicados de hacer.
+--[[Usuario:Edu|Edu]] 18:09 22 mar 2008 (ART)
+----
+Edu:
+La primera opcion es comprarlos, estoy de acuerdo, y tambien me parece critico ya que "muchos" otros sistemas dependen de esta lectura.
+Sin embargo creo que podemos discutir la posibilidad de hacerlos en "paralelo" en algun momento. (seria bueno si es mas adelante y termino el talón)
+Lo ultimo que paso de este tema y sigo con lo que creo estoy mas preparado, es un dibujo del disco gray que ya lo tengo en cad, y esta en diametro 46 exterior, ranuras de 1.4, espacio entre ranuras 0.7, diametro inicial 12, para un rodamiento SKF623, diametro de eje 3mm
+[[Imagen:codigo 8 bits.jpg]]
+pueden ver en amarillo 2 led de los 8 que llevaria.
+podemos cambiar los paso a paso por encoders??
+--[[Usuario:Mastromec|Mastromec]] 18:39 22 mar 2008 (ART)
+----
+A ver si me pasás el dwg de ese disco...<br>
+¿A que te referís con -"...cambiar los paso a paso por encoders"?<br>
+--Adrian S.A. 19:14 22 mar 2008 (ART)
+----
+Juan, supongo que la pregunta es si podremos hacer que un motor de CC con reducción avance y se ubique sobre cada uno de los valores del encoder, es decir, si tiene 32 posiciones, que dé 32 pasos por vuelta. Si tiene 200 valores, 200 pasos por vuelta. La respuesta es sí. Pero es mejor que el motor [[pap]], porque al arrancar el sistema sabe dónde está. Obviamente, es el servo ideal para nuestro diseño.
+--[[Usuario:Edu|Edu]] 10:38 23 mar 2008 (ART)
+----
+Queria saber si podemos controlar los motorcitos de continua como los [[pap]] (me respondiste)
+Era una pregunta directa, perdón, me referia a los paso a paso que puse a disposición del grupo, en verdad la experiencia con los [[pap]] que tengo, es que siempre me "falta" un plus de fuerza para que no salte, quizas no trabaje lazo cerrado (y soy mecanico claro), pero me gusta mucho mas la idea de usar los motorcitos IGNIS y controlarlo con una llave H, entonces nos estarian sobrando los [[pap]] que los podemos vender o canjear...
+Adrian te paso el Cad del disco, si puedo hago cortar uno o dos para probar en plastico opaco.
+--[[Usuario:Mastromec|Mastromec]] 14:01 23 mar 2008 (ART)
+----
+Dibuje el disco en 3d, esta todo hecho con variables, o sea que pueden cambiar lo siguiente:
+ancho de ranura
+espacio entre ranuras
+diametro de la primera ranura
+angulo donde comienza la pista (esta es buena)
+y puedo generar el cad para cortar el laser
+[[Imagen:3d disco codigo gray.JPG]]
+--[[Usuario:Mastromec|Mastromec]] 18:37 23 mar 2008 (ART)
+----
+una idea de como seria hacer un encoder:
+disco en plastico opaco de diametro 46mm x 1mm de espesor
+partes de corte laser en acrilico de 3mm
+parte tiene un agujero de 47mm en el centro
+partes con alojamiento para rodamiento SKF623 d3xD10x4
+tornillos M4 Roscados en el acrilico de abajo
+eje diametro 3mm con un resalto de 6mm para centrar el disco y un resalto de 8mm para hacer tope
+los leds y los transistores de montaje superficial cortados en las tapas y pegados.
+[[Imagen:3d encoder.JPG]]
+--[[Usuario:Mastromec|Mastromec]] 19:36 23 mar 2008 (ART)
+----
+Los paso a paso, no me doy cuenta del tamaño de los que ofreciste, pero se podrían usan en las muñecas de las manos (dos movimientos) y en el cuello.
+Si hacemos un enconder que funcione, será un muy buena experiencia y hasta podemos encontrarnos con un producto comercial para ofrecer. Fototransistores y diodos emisores se consiguen de 1,5 mm de diámetro.
+--[[Usuario:Edu|Edu]] 20:21 23 mar 2008 (ART)
+----
+Ok, dame los datos de UN diodo led y de UN fototransistor para montar
+se me acaba de ocurrir como contrarrestar el tamaño del disco y la cantidad de bits.
+hacer un tambor formado por tantos discos de 2mm como bits quieras, cortados con las marcas 2,4,8,16 etc y leer a travez del tambor, en el interior los leds y exterior los transistores.
+una pregunta los leds estan todos encendidos siempre?
+--[[Usuario:Mastromec|Mastromec]] 20:45 23 mar 2008 (ART)
+----
+Los leds se pueden encender sólo al pedir una lectura. Ya te busco una hoja de datos.
+Hubo un problema de interpretación mío: esos fototransistores tienen 1,5 mm de diámetro pero vienen montados en una cajita de 4,5 mm x 5,7 mm. Luego están los cilíndricos, de 3 mm de diámetro.
+Habrá que buscar SMD (hay de 1,6 x 0,8 mm y de 2 x 1,2 mm, pero tengo que encontrar si los venden aquí).
+--[[Usuario:Edu|Edu]] 21:22 23 mar 2008 (ART)
+----
+Buscate uno común, yo lo acomodo, no te preocupes
+pienso usar el area de trabajo del transistor y giro como un caracol los demas, el angulo girado lo corrijo en el inicio de la pista que corresponda.
+si podes pasame las medidas del formato
+--[[Usuario:Mastromec|Mastromec]] 22:14 23 mar 2008 (ART)
+----
+Una cosa: cuanto más grosor tenga el disco, más exactamente perpendiculares deben estar los sensores a su superficie, y más exactamente alineados, para que la pared del agujero no cambie momentánamente una lectura. No sé si me explico. A esa escala, el agujero es como un pozo: tiene una pared. Esto es importante, porque si leemos la posición justo en un flanco del cambio, podemos tomar mal el valor.
+Quizás lo mejor es un disco transparente con sólo una cara pintada con pintura opaca muy delgada.
+--[[Usuario:Edu|Edu]] 22:38 23 mar 2008 (ART)
+----
+Vienen parejas diodo-fototransistor en forma de U. Se pueden poner múltiples discos del mismo diámetro, cada disco correspondiente con el peso del bit que le toque. Cada U envuelve a un disco. Creo que eso es lo que explicaba Juan, no?--Adrian S.A. 22:47 23 mar 2008 (ART)
+----
+Uno de estos encoders iría a parar al pie para medir el ángulo de la punta del pie.--Adrian S.A. 22:55 23 mar 2008 (ART)
+----
+Era la idea, pero no usando herraduras aunque podria ser...
+yo pensaba grabar sobre el filo del disco y juntar los discos como un paquete con forma de tambor, es decir hueco, entrar dentro de este hueco con una herradura de 8 leds por fuera como alineados con el eje del tambor, y 8 fototr. por dentro.
+En ves de cortar el tambor solo grabar una profundidad.
+--[[Usuario:Mastromec|Mastromec]] 22:57 23 mar 2008 (ART)
+----
+En algo así pensaba yo.(por lo que comentaste vos). En el dibujo no son exactamente optoacopladores. Son la pareja diodo - fototransistor en forma de U a los que se le intercepta la luz en medio.<br>[[Imagen:Discos-optoacopladores.gif]]<br>--Adrian S.A. 23:34 23 mar 2008 (ART)
+----
+Imagino que deben haber encoders que usen la tecnología del dvd (ahora el bluray). Lectura de algún tipo de información mediante esa tecnología. Imagino la precisión. Supongo que ya debe estar inventado eso.--Adrian S.A. 01:25 24 mar 2008 (ART)
+----
+¿se acuerdan de los mouses a bolita?  :)
+http://static.howstuffworks.com/gif/mouse9.jpg
+O imaginen usar esta tecnología...
+Here's how the sensor and other parts of an optical mouse work together:
+* The CMOS sensor sends each image to a digital signal processor (DSP) for analysis.
+* The DSP detects patterns in the images and examines how the patterns have moved since the previous image.
+* Based on the change in patterns over a sequence of images, the DSP determines how far the mouse has moved and sends the corresponding coordinates to the computer.
+* The computer moves the cursor on the screen based on the coordinates received from the mouse. This happens hundreds of times each second, making the cursor appear to move very smoothly.
+http://static.howstuffworks.com/gif/qotd631-led-mice-2.jpg
+--Adrian S.A. 01:32 24 mar 2008 (ART)
+----
+Concentrando un poco los pensamientos en la cosa práctica.
+Analicemos qué necesitamos del encoder:
+* Necesitamos que nos dé la posición con exactitud en cualquier situación. Un fallo podía ser catastrófico (imagínense una pierna disparándose como en una persona por el reflejo del golpe de martillo en la rodilla)
+* Necesitamos que la posición sea absoluta. Ante cualquier situación que se presente, desde el encendido a reinicios, el robot tiene que saber en qué posición están sus partes móviles.
+Las dos cosas nos indican algo: necesitamos una enorme precisión.
+Una experiencia personal: el problemas de los encoders está en los flancos de paso de la banda de información.
+El código Gray evita ciertos errores, pero persiste un problema.
+'''Pido mucha atención aquí''': ¿En qué condiciones se usan los encoders generalmente? Busquen en Internet y fíjense que los encoders tienen como parámetro los RPM que soportan. Es decir, una de las situaciones es aquella en la que hay un giro continuo. También hay encoders de una vuelta única.
+¿Qué pasa cuando no hay un giro continuo?
+Se presenta una situación: el sistema puede detenerse o hacer una medición sobre el flanco de cambio de código. ¿Qué pasa entonces? Como los sensores no van a estar alineados perfectamente (digamos en un orden submicroscópico) puede llegar a leerse cualquier cosa. ¿Cómo se evita? Con una enorme precisión mecánica y de alineación óptica. Es probable que haya algún método de computación de la lectura, porque los encoders suelen tener microcontroladores. Muchos entregan los datos como PWM o por un port serie.
+¿Es fácil filtrar este problema? '''No es fácil'''.
+Sería más fácil si estamos hablando de controlar una máquina girando constante y en un solo sentido. ¿Como? Se retrasa un poco electrónicamente el flanco de la pista del bit menos significativo y se toma esto como pulso de reloj para aceptar el cambio. ¿Qué produce esto? Asegurarse de que todas las otras pistas ya hayan cambiado cuando se toma la medición.
+Pero que pasa si tenemor un sistema que se mueve de vez en cuando y se puede parar justo sobre el flanco. Difícil, difícil.
+Ahora nosotros queremos armarlo.
+¿Se puede lograr una gran precisión mecánica en un montaje de los sensores? No sé. Supongamos que usamos fototransistores SMD (la posición más critica es la del fototransistor, mucho menos la del LED). ¿Cómo los vamos a soldar para que queden bien alineados? No tenemos un armador de placas robótico, ¿o sí?
+Si usamos optoacoples de ranura (¿hay bien pequeños?, no estoy muy seguro) en el diseño de tambor propuesto, ¿podremos alinearlos bien a todos? Se sueldan con cuatro patitas, y el haz puede quedar o no alineado con el haz de los otros discos. Debereríamos hacer ajustes muy finos con osciloscopio, usando un cilindro con discos de ajuste o inventando un ajuste que nos permita asegurarnos de ver cómo está alineado todo.
+Ahora me pregunto, porque me ha pasado en algunos diseños. ¿Cuánto tiempo nos va a llevar esto?
+Quiero decir una cosa para cerrar: un encoder absoluto es algo en teoría simple, se nos ocurre que un fabricante debería poder "sacarlo del horno" al toque. Sin embargo, en las empresas especializadas vemos que estos encoders son más bien caritos. ¿Por qué es? ¿Son estúpidos?
+--[[Usuario:Edu|Edu]] 11:19 24 mar 2008 (ART)
+----
+Es cierto. Igual, debe haber forma de contrarrestar esto por software. Algún tipo de predicción de movimientos como para que no haga lo que no es lógico que tiene que hacer. Sabiendo que debería existir una especie de "cadencia" en los movimientos, lo que salga de ese ritmo debería estar mal.<br>
+Está sabiamente planteado lo que dijiste. Hay que estudiarlo mas a fondo.<br>
+Respecto del diseño de los encoders, se puede encarar pero hay que abrir un proyecto aparte. Y así, cualquier cosa que querramos diseñar.Propongo que abramos un proyecto aparte para trabajar en ese tema. Por ahí se prende mas gente que esté interesada solo en ese tema.<br>
+--Adrian S.A. 12:16 24 mar 2008 (ART)
+----
+Edu: en un 100% tenes la razón, yo tambien e tenido problemas con discos y el sentido de giro. ademas no es la intencion del proyecto (y hay que aprovechar el tiempo disponible)
+Ya te habia dicho que me parecia correcto y adecuado usar encoders comerciales y te propuse cambiar o vender los pap para comprar encoders que son muchos, pero la presicion lo requiere.
+pase todo el desarrollo porque ya me habia lanzado con esta idea antes y 2 cosas, 1 no podia parar, 2 queria compartirlo para ver su opinión.
+Usaremos encoder comerciales si es posible mini y los mas economicos, si podes averiguar alguno lo voy montando en el modelo virtual.
+--[[Usuario:Mastromec|Mastromec]] 13:31 24 mar 2008 (ART)
+----
+Ya pedí precios en Silge, si querés ir viendo lo que hay buscá los encoder absolutos en esta página
+http://www.silge.com.ar/productos_beta.php?pagina=2&marca_id=4&letra=
+--[[Usuario:Edu|Edu]] 14:36 24 mar 2008 (ART)
+----
+Tengo la impresión de que ya es hora de hacer una prueba: Montar un brazo a un encoder, el que se defina, para poder moverlo en todas direcciones y a distintas velocidades. Registrar los datos del encoder y ver, en algún gráfico, el comportamiento y analizar qué tipo de falla puede aparecer. No se si me expliqué bien.<br>De paso irán apareciendo parte de los algoritmos que necesitaremos. Supongo.<br>
+Este banco de pruebas servirá para probar todo encoder que se cruce por el camino, aún si es diseñado por nosotros.<br>
+Algo así: (después lo borran)<br><br><br>
+[[Imagen:BPencoder.gif]]
+--Adrian S.A. 16:37 24 mar 2008 (ART)
+----
+Copio para que vean qué buenos comerciantes son algunas empresas (Silge en este caso). Parientes de Gran Hermano, hacen preguntas en lugar de responder el dato solicitado.
+«Le pido pueda informarnos los datos completos de la firma (razón social, CUIT, dirección, teléfonos, etc) para poder ingresarlos a nuestra base y emitir la cotización solicitada.
+Atte.»
+--[[Usuario:Edu|Edu]] 11:46 26 mar 2008 (ART)
+----
+Edu, se podra usar esto?, parece ser economico
+http://www.vishay.com/docs/57090/120e.pdf
+--[[Usuario:Mastromec|Mastromec]] 10:02 28 abr 2008 (ART)
+----
+Es un encoder incremental, es decir, manda pulsos al girar y nada más. Este es el sistema que, para saber dónde está ubicado el eje de giro, tiene que tener una posición de "home" (con otro sensor). Más bien sirven para controlar velocidad en giro libre.
+Ya pregunté a Varitec por los encoders que ofrecen, pero no me respondieron. Hay gente que pone una página web y una dirección de mail, pero luego ni los miran.
+Estuve pensando que si no conseguimos encoders absolutos a precio accesible, podemos usar los potenciómetros que vienen en los servos. Un servo cuesta alrededor de 25 a 35 pesos (us$ 8-10). Y no es un gasto que s ehace por el potenciómetro solo, luego de sacar el pote nos queda el motor con su reductor y su circuito de control y potencia (así se usan en muchos robotitos). Yo tengo algún potenciómetro de estos que saqué de un servo para hacerlo de giro libre.
+No sé nada de estos potenciómetros, pero es de suponer que son mucho más resistentes y menos ruidosos que los potenciómetros comunes, ya que esto es crítico para que el servo funcione bien. Si tenemos en cuenta que un servo de estos se usa para volar modelos, algunos muy caros, y que se los usa muchas, muchas veces (en estos modelos el servo se mueve continuamente mientras el bicho está volando), es de suponer que la calidad del cursor y de la pista de deslizamiento/resistor debe ser muy buena.
+Si ponemos dos o tres potenciómetros en lugar de uno y los leemos a todos para hacer un sistema redundante, es posible que obtengamos muy buenos resultados.
+También es posible que se consigan potenciómetros en el mercado con calidad así, y durabilidad a muchos movimientos. Tenenos que averiguar. (Claro, siempre que cuesten menos que un servo.)
+--[[Usuario:Edu|Edu]] 11:15 30 abr 2008 (ART)
+----
+Ok, ya me habias explicado que necesitabamos encoders incrementales...
+--[[Usuario:Mastromec|Mastromec]] 17:11 30 abr 2008 (ART)
+----
+Los que necesitamos son los absolutos.
+--[[Usuario:Edu|Edu]] 16:45 2 may 2008 (ART)
+----
+si, absolutos
+--[[Usuario:Mastromec|Mastromec]] 16:48 2 may 2008 (ART)
+----
+Absolutamente los absolutos.   :)
+--Adrian S.A. 21:25 2 may 2008 (ART)
+----
+Lo mejor que consigo en precio, en varitel son de 8bit codigo gray $500 c/u
+AEW 8 GC H 6050
+--[[Usuario:Mastromec|Mastromec]] 13:34 5 may 2008 (ART)
+----
+Tendremos que hacerlos nosotros o comprar afuera, varían desde los us$ 50 (aunque yo tengo idea de haber visto unos a 15-20) a los u$ 750. Aquí deben traer los más caros.
+--[[Usuario:Edu|Edu]] 14:44 6 may 2008 (ART)
+----
-[[Categoría:Opiniones]]
+[[Categoría:Electrónica]]
+[[categoría:Sensores]]