eprimucci Publicado 24 de Enero del 2017 Publicado 24 de Enero del 2017 En 2016 hicimos un viaje con Leo Julio y otros amigos a los observatorios chilenos. En el viaje nos tocaron lindos tramos de avión pero también interminables tramos de bondi... hasta 18 horas para llegar a San Pedro de Atacama desde La Serena. Hice un par de posts al respecto. Pero ese es otro tema. Lo traigo a colación ya que durante esas interminables horas hablamos de todo un poco. Un tema que siempre nos tiene activos es la automatización. Leo tiene un observatorio muy pero muy bueno en La Pampa. El observatorio La Banderita tiene un domo de 1 tonelada de peso. La idea era poder de alguna dejar que el Maxim controle el domo en las largas sesiones de fotos. Ya seguramente han visto varios posts donde voy automatizando mi observatorio de a poco, pero no tengo domo. La Banderita era un desafío! Lo primero fue ver el sistema actual de movimiento del domo. Utiliza un motor bastante avanzado, con infinidad de posibilidades de customización. Cómo arranca en forma escalonada para no dar "tirones",qué velocidad utiliza para frenar el movimineto, etc. etc. La controladora dispone de entradas y salidas digitales... y eso me disparó el tema Arduino... y si podemos "hablar" con el motor? La idea entonces era medir la rotación de alguna manera. Un encoder rotativo? Lo que tenía más a mano era un potenciómetro de volúmen de una radio común y corriente. Ese potenciómetro tiene 20 pasitos por revolución. Diseñé una pieza estrambótica para contener al paquete de encoder y cablerío. Eso luego iba conectado a una Arduino que recibiría la data del encoder. Y en consecuencia activaría relays para mover el motor a izquierda y derecha... mientras seguía leyendo la posición que marcaba cada click del encoder. Una de las cosas más divertidas de este proyecto (que fuimos haciendo en ratos libres!) fue la de preparar todo a cientos de kilómetros del destino final, llegar, poner las piezas en su lugar y.... que todo ajustase a lo planeado! El asunto fue que en la primera prueba, luego de gritar de alegría porque "el domo se mueve solo"... notamos unas leves diferencias cuando el domo giraba de izquierda a derecha con respecto al sentido contrario... Para un lado daba 1089 "clicks" del encoder (potenciómetro rotativo) y para el otro... 1083.... perplejos. Nos volvimos sin antes no hacer unos tiros al cielo con el terrible equipo de La Banderita, unas reflex y volar un poco el dron. El regreso fue con un éxito a medias. El Maxim ponía el shutter del domo donde debía, pero luego de dar algunas vueltas un pequeño error se acumulaba y adiós! No más alineación del shutter con el tubo. Una desilusión. Aprovechando el tiempo para probar otros proyectos: Sobrevuelo de La Banderita: Intentamos decenas de veces... tanto que la rueda de tracción del motor se deshizo! Como cuando se sale la banda de rodamiento de una cubierta de auto! Ganas de llorar! Mismo error de encoder... Nuevo diseño de rueditas... nuevo diseño de caja contenedora. Nueva rueda de tracción del motor al domo... Nuevo viaje a La Pampa. El segundo para este tema! Esta vez el encoder iría acoplado al motor, para evitar errores de la rueda. Nos mantuvo despiertos gran parte de la noche. Entre ruidos de zorros cazando y una noche INCREIBLEMENTE oscura... cambié el firmware (software de la arduino) para compensar con ese defecto. Cambié las librerías que leían el encoder rotativo. De todo. Al día siguiente cambiamos la goma que hacía contacto entre la ruedita de plástico y el domo... nada. Para poder cambiar las librerías necesitaba conectarme a la red. Hoy La Banderita tiene su torre de enlace a la red (está en un lugar muy remoto), pero el año pasado tuvimos que manejar hasta un pueblo a algunos kilómetros y tomar internet gratis de la plaza del pueblo. Un pueblo de 200 habitantes. No me quiero imaginar las historias que habrán contado los lugareños al ver el auto parado en la plaza (se conocen todos) con una laptop adentro por un buen rato... y desaparecer a las 2am! en fin... nada sirvió. El error de medición prevalecía. Regreso sin gloria... Ahora, en su tercera versión, los cambios fueron más drásticos: Nuevo encoder de alta resolución con elementos ópticos (U$S 15 en ebay). Pero lo más importante, un ingeniero me comentó que yo estaba desarrollando un sistema abierto sin feedback. Es decir, mi lógica dentro de la arduino SI tenía en cuenta errores del encoder. Podía detectar saltos propios del encoder, pero NO podía detectar si habái deslizamientos de la ruedita o bien algún otro error físico de medición. Cómo se soluciona eso? Dándole feedback al sistema. La idea es poner varios sensores infrarrojos a lo largo del domo y cuando "pasan" por un sector con pintura especial, marcan una posición, sincronizando con la Arduino. Es como corrección de errores constante. Arduino recibe que el encoder está una determinada posición, pero si los sensores marcan otra, corrige. Estos sensores están fijos y no tiene posibilidad de error, a menos que esté dañados. Lo bueno es queno dan falsos positivos, simplemente no reportarían posición. Pedí 4 a China... debimos reclamar el pedido al fabricante. Costo fue menos de U$S 5!!!! 4.86 para ser exactos. La semana pasada, 5 meses después de iniciar este proyecto me llega un telegrama de correo argentino diciendo que debo abonar $100 e ir a retirar los sensores de 5 dólares! Debí haber pedido a Atlanta (donde viajo cada 3 meses por trabajo...) En fin... ya tenemos los sensores a disposición. Estimo que en Marzo podré viajar nuevamente a poner a punto el nuevo sistema. La tercera será la vencida? javieriaquinta, Leoyasu, Nicolas Alarcon y 3 otros reaccionaron a esto 6
leochino Publicado 25 de Enero del 2017 Publicado 25 de Enero del 2017 Tremendo laburo te está dando Piri! Super completo todo el informe en detalle. Agradezco todo el esfuerzo brindado. En marzo lo tenemos funcionando! Ojalá le sirva a más gente que necesite automatizar. Gracias Piri.
jwackito Publicado 25 de Enero del 2017 Publicado 25 de Enero del 2017 Una masa este laburo. Me alegra enormemente que Piri se ponga a contar las cosas que hace. Ya me estoy dando una vuelta por los otros post. Abrazo grande.
eprimucci Publicado 2 de Febrero del 2017 Autor Publicado 2 de Febrero del 2017 (editado) avances y archivos colgados... falta menos! 1. En el Sketchup el primer soporte 2. Impreso el soporte, con branding 3. Primer modelo de caja de control 4. Segundo modelo, con relays en la misma caja 5. El driver ASCOM!!! 6. El primer encoder experiemntal, que perdía 4 pasos cada 1000: 7. Soporte para el nuevo encoder, más preciso 8. El nuevo encoder listo para ser montado 9. Nueva rueda de contacto para el encoder. Más grande, mayor superficie de contacto. Falta revestimiento. Editado 2 de Febrero del 2017 por eprimucci Nicolas Alarcon reaccionó a esto 1
eprimucci Publicado 17 de Marzo del 2017 Autor Publicado 17 de Marzo del 2017 Update al topic: Ayer, (Marzo 16, 2017) quedó publicado el código tanto del driver C#: https://github.com/eprimucci/BanderitaDome como el del hardware (Arduino) en Github https://github.com/eprimucci/ASCOM_Arduino_Dome Le agregué un par de cosas, incluyendo un "Find Home": al momento de conectar el software de control (Maxim DL, POTH Dome control, ACP o cualquier otro que sea ASCOM) provoca que el domo gire hasta disparar el sensor definido como "HOME" y sincronizar los grados de azimuth. Luego, si se lo pone en modo "Slave", que es la idea principal y objetivo del proyecto, el domo va recibiendo actualizaciones de la posición de la montura cada pocos segundos y se mueve acompañando al tracking del telescopio. Todo esto ya funcionaba, pero teníamos un problema de pérdida de sincronicidad entre el domo y el encoder luego de unas cuantas vueltas de domo u operaciones de "Slew". El nuevo encoder es de 2400 pasos (China ebay U$S 15), contra 20 pasos del proyecto anterior. La tasa de refresco es tan alta que por medio de software (operación de módulo) lo limité y actúo sólo cada 50 clicks. Al ser configurable ese parámetro, puedo darle más o menos precisión a las mediciones. Igualmente el standard ASCOM no es tan exigente y con tener los grados de Azimuth en enteros (sin minutos ni segundos) ya puede acompañar el tracking de la montura. Otra funcionalidad agregada es la de Park. Usando un Profile de ASCOM se pued definir el azimuth donde el domo queda "parkeado". Es decir, cuando cerramos el observatorio y ponemos los candados Para lograr todas estos extras hicieron falta sensores de contacto. En un primer momento conseguí unos sensores de contacto robustos y económicos (U$S 1.39 cada uno en ebay China). Los pedí y los recibí en Atlanta en 2 semanas (viajo seguido por trabajo) Pero luego encontré unos mejores que son infrarrojos! (U$S20 el paquete de 5). Lamentablemente los pedí a Buenos Aires en Septiembre y en Febrero hice el trámite de importación en AFIP (si... como lo leen) y aún no llegan por el correo. Viva la patria proteccionista pero burocrática! En fin.. son éstos: Si llegan, ponemos esos, si no, van los de contacto. El desafío es posicionarlos. El domo de metal de 1 tonelada de peso no es amigo de las brújulas. Por eso la idea es posicionar la montura en una estrella de catálogo preseleccionada, foto, resolver el plato y convertir al ALT-AZ para sacar los grados donde apunta la montura. Luego marcar y poner el sensor ya calibrado para esa posición. Suena divertido. Veremos si lo logramos. Estamos viajando en breve con @leochino a terminar la instalación. Prometo fotos y reporte, en especial para @jwackito que sigue el tema muy de cerca y es capaz de hacer andar todo el linux!! Saludos a todos! Nicolas Alarcon reaccionó a esto 1
Cristopher B. Publicado 17 de Marzo del 2017 Publicado 17 de Marzo del 2017 Felicitaciones por lo que están creando! Son unos verdaderos Tony Stark eprimucci reaccionó a esto 1
Publicaciones recomendadas
Crear una cuenta o conéctate para comentar
Tienes que ser miembro para dejar un comentario
Crear una cuenta
Regístrese para obtener una cuenta nueva en nuestra comunidad. ¡Es fácil!
Registrar una nueva cuentaConectar
¿Ya tienes una cuenta? Conéctate aquí.
Conectar ahora