GiroPlay: un display giratorio con vistas

[Nocturno]

Siempre me han gustado mucho los displays giratorios y siempre he estado tentado de hacer uno


Al final me ha parado una pregunta: ¿para qué lo quiero, qué haré con él?
Pues bien, ayer paré en una gasolinera Repsol para repostar y me encontré colgando del techo un maravilloso display giratorio de unos 60cm de diámetro con mensajes publicitarios a todo color de la marca Repsol. Os puedo garantizar que el efecto conseguido enganchaba a todo el que pasaba por allí.
Ya han encontrado un uso ideal para estos ingenios; ¿me animaré a montarlo ahora?

P.D.: Diego, la gasolinera está junto a tu casa, en la carretera que va de La Pañoleta a Urende.

[RedPic]

Pues lo tenemos claro ... si tu quieres yo quiero. Lo montamos y abrimos un nuevo canal de negocio. Mas fácil imposible. 

[navaismo]

Hola Nocturno, por ese mentado "proppeller Clock" fue que tambien me adentre en esto de los PICs desde que lo conozco he querido hacer uno y me fui metiendo mas y mas en esto. Aun no poseo el suficiente "skill" para fabricar uno. Pero de que sigue en mi mira sigue. Y yo lo queria para mi cuarto, para mi, es una accesorio muy chido en y da efecto 3D. Un antiguo master mio y de muchos LEDROJ se hizo uno y usando PBP si no mal recuerdo

[Nocturno]

Sí Max, ese de la foto que yo he puesto, es del querido Ledroj.

[Nocturno]

Pensando en voz alta sobre los problemas que podríamos encontrarnos en la hipotética fabricación del famoso display giratorio (en adelante, GiroPlay) se me ocurren varios:
- máxima resolución: relación entre nº de leds, distancia de pixel y MIPS
- cómo alimentar la parte móvil desde la parte fija
- cómo actualizar la información del GiroPlay
- mantener el motor a la velocidad que queremos
- condicionamientos mecánicos: equilibrio, ruido al girar

Seguro que se me van ocurriendo más ideas, pero hoy me apetece hacer unos cálculos sobre la resolución.

RELACIÓN ENTRE RESOLUCIÓN Y MIPS
Es obvio que un giro siempre tiene 360º, y que cada uno de estos grados se traduce en un desplazamiento en el perímetro del círculo. Este desplazamiento es mucho mayor cuanto más grande sea el radio de giro.

Por otra parte, como los leds están en movimiento, debemos determinar cuándo queremos que un led cambie de un pixel al pixel de al lado, puesto que el movimiento le hace pasar por todos los puntos del espacio entre un pixel y el contiguo.

En mi ejercicio, utilizaré estas hipótesis:
- los leds cambian de pixel cada 5mm, que coincide con el grosor de los leds de 5mm. ¡Qué casualidad, eh!
- voy a utilizar un radio de giro de 40cm, lo que nos dará una presencia importante del dispositivo, que ocupará una anchura visual de 80cm a todo el que lo mire.
- utilizaremos una frecuencia de barrido equivalente al cine comercial: 24 fps. Eso supone el motor tendrá que girar a 24 * 60 = 1.440 rpm

Para ese radio, tendremos un perímetro de:
   Perímetro = 2 * pi * R = 2 * 3.1416 * 400mm = 2.513mm

En ese perímetro nos caben 502 pixels de 5 mm. aproximadamente.

A la velocidad que estaremos moviendo el GiroPlay, disponemos por tanto del siguiente tiempo por píxel:
   Tiempo por píxel = Periodo de Giro / 502 = 1 / Frecuencia de Giro / 502 = 1 / 24 / 502 = 83us

Si utilizamos un PIC 16F a 1MIPS tendremos por tanto 83 instrucciones para poder encender los leds.
Si utilizamos un dsPIC 33F a 40MIPS dispondremos de 3320 instrucciones para la misma tarea.

Podemos pensar que es tarea fácil incluso para un 16F pero no olvidemos que en ese tiempo hay que:
-   leer la memoria para conocer la información que hay que enviar a los leds
-   enviar la información al puerto (o puertos) de salida
-   atender la interrupción externa que marca el inicio de cada vuelta
-   atender al mecanismo de comunicación que se establezca para actualizar la información mostrada
-   atender al RTC para saber qué hora es, puede ser un dato a representar
-   atender al sensor de temperatura para poder representarla

Si además complicamos la cosa con:
-   resolución vertical de 32 leds
-   Full color, utilizando leds RGB

Puede que nos quedemos cortos incluso con el 33F. No sé, la verdad es que habría que meterse en faena para determinarlo.

[J1M]

Hola manolo,

Hace un tiempo quise empezar también con el cacharrito este, de hecho tengo en casa casi todo para ponerme manos a la obra, pero el verano se ha convertido en un no hacer ni un huevo! Te respondo a lo que yo tenía pensado para solucionar los problemas:


- cómo alimentar la parte móvil desde la parte fija:

Para esto yo había pensado utilizar dos rodamientos de bolas, uno encima del otro y separados por una arandela de plástico, que irían al eje del motor. De esta forma, a la parte 'externa' del rodamiento irían conectados los cables de alimentación desde 'la fuente' mientras que a la interna (habría que hacerle una pequeña muesca al eje) irían los cables de alimentación a la parte rotatoria. Hay muchos métodos, a mí este es el que me parece más 'limpio', menos follonero (otros implican desmontar el motor, perforar el eje, etc.) y fácilmente realizable. Otro método bastante curioso y que merecería la pena plantearse es el del motor-dinamo, es el método que utiliza el ventilador que puse en el otro post sobre el tema.

- cómo actualizar la información del GiroPlay

La forma más sencilla aunque no se que tal se andaría de velocidad debido al protocolo SPI, sería utilizar una memoria MMC/SD. Tienen buena capacidad y son rápidas.

- mantener el motor a la velocidad que queremos

Para mantener la velocidad había pensado en un control PWM para alimentar al motor, y un sensor infrarrojo para detectar cuando se ha completado una vuelta. Si hiciera falta teoría de control, con un PI sería suficiente.

[aitopes]

Hola!
Me engancho al proyecto.

Siempre que pense en estos carteles me complicaba pensando en como alimentar la parte movil. Ahora ya lo se, gracias al post anterior.

Respecto de la velocidad del motor, es algo con lo que me ha tocada trabajar en algunas oportunidades, y es mas bien sencillo:

Ponemos un sensor que envie un pulso (o dos) por vuelta del eje. Yo uso sensores HALL y dos imanes (2 para no desbalancear el motor), pero en definitiva es lo mismo.
Supongamos que quiero mantener fija una velocidad de 2000 rpm. Ajusto el PWM al 90% (como para empezar, un valor arbitrario cualquiera serviria), y mido el tiempo entre dos pulsos. Ese sera el tiempo que le tomo al motor dar una vuelta (o media, si tengo dos sensores). Si el tiempo es mayor que el correspondiente a 2000 rpm (que deberia ser 0.03 segundos si las cuentas no me fallan), significa que voy muy lento, asi que aumento el PWM (a 91%, por ejemplo) y vuelvo al paso anterior. Si el tiempo es menor, resto 1 al PWM, y vuelvo al paso anterior. Y listo!

Yo arranco con el pwm = 50%, y en unas pocas vueltas la velocidad alcanza el valor deseado. Suele ser conveniente promediar 10 vueltas y despues ajustar el pwm. Eso hace mas lenta la respuesta, pero evita que el motor cambie de velocidad constantemente. Esta "paradoja" se da por la inercia mecanica del motor:

Supongamos que con PWM=50% la velocidad es baja. Ponemos 51% y volvemos a medir. Sigue siendo baja, ponemos 52%, etc. Quizas cuando lleguemos a 70% la velocidad sea la correcta. Pero, a la vuelta siguiente, la velocidad resulta ser excesiva. ¿Por que ocurre eso? Sencillo: pasar de 50% a 70% solo nos tomo 20 vueltas del motor (o 10 si tenemos dos sensores), lo que significa que debido a la inercia mecanica el motor este todavia acelerando y al llegar a la velocidad requerida "se pase".

Soy una animal explicandolo, pero creo que el concepto queda claro. Si no, posteo un trozo de codigo que seguramente se va a entender mejor. 

Saludos!

[LABmouse]

Yo también estaba haciendo uno, pero me quede a medias, compre el motor y todo, pero esta guardado en un cajón. 

Pero a mi parecer no es necesario controlar la velocidad del Motor, lo unico necesario es saber la velocidad del motor y una referencia para saber cuando el motor va por determinado punto del recorrido y a partir de ese momento empezar a contar tiempos para encender y apagar los leds.

Coincido con aitopes, creo que lo mejor es usar sensor de efecto hall.

Lo que si es interesante es la forma de controlar los LEDs RGB. se necesitan 3 puertos PWM por pixel RGB.  Y si se hace de 8 pixeles de alto (A mi parecer lo suficiente) Necesitaríamos 24 puertos PWM....  O un micro muy pero muy rapido para poder trabajar todos los PWM por software o algo que extienda esos puertos PWM.

[aitopes]

Hola Pic!

El control de la velocidad del motor puede servir para hacer desplazar el texto en sentido horario o antihorario simplemente cambiando las rpm...

[aitopes]

Obviamente, mi post anterior es una broma.

Es necesario mantener razonablemente estables las RPM para evitar que el texto se estire o contraiga, ya que el punto de comienzo del texto lo da el paso por el sensor, indicando nuestra columna virtual "0". Pero si asumimos tiempos fijos entre columna y columna, es evidente que variaciones en las RPM hara que las columnas se junten o separen, cambiando el aspecto del texto.

Respecto de los leds RGB, es cierto, son muuuchos RPM. Quizas los hilos que tratan sobre el control de servos puedan ayudar en este problema (Diego, a ti te hablo!  )

Saludos!

[LABmouse]

Pero ese efecto se puede lograr con solo tener el motor girando a toda mecha en un solo sentido. Conociendo el punto en donde se encuentra el extremo donde están los leds, se hace lo que sea.

Lo que si se puede hacer, es tener 2 extremos con LEDS, de esa forma "Se multiplica" la velocidad de giro del motor" ya que tenemos que recorrer la mitad del tiempo para ocupar los 360

[aitopes]

PICMOUSE, tienes razon.

Pero el controlar la velocidad del motor sirve para que independientemente del motor que consiga cada uno, el soft funcione igual....Es decir, si mi motor "a toda marcha" es mas rapido que el tuyo, mis textos seran mas "apretados" si usamos el mismo soft...no?  Ahora, si todos ponemos motores que se mantienen mediante PWM a 2500 rpm, todos tendremos el mismo texto.

(quizas me estoy equivocando mal....y no logro darme cuenta! )

[J1M]

Estoy con Ariel, creo que suponer que un motor va a mantener constantes sus rpm es ser muy atrevido! :p, además ya que hay que medirlas... en cualquier caso, como lo que hay detrás del control del motor es algo 'sencillo' no creo que esté de más.

saludillos!

[LABmouse]

En eso si tienes toda la razón. Si se quiere algo mas universal, si es mejor colocar el control del motor, y para cual sea el motor, con el control, tendrán la misma RPM.

Me convenciste.. 

[aitopes]

Bueno, me gusta que esten de acuerdo, por que yo no estaba 100% seguro de que fuese la mejor manera.

Asi que el soft implicado en esto deberia ser capaz de:

1) Leer un pulso y en base a ello ajustar un PWM (motor)
2) Controlar el encendido de 7 LEDs para representar los textos
3) Gestionar una memoria externa con los textos (y fuentes?)

En principio, para un cartel con LEDS convencionales no parece complicado. Con RGB, la cosa se complica, pero no es imposible.