Bueno, fruto de los intensos debates surgidos del hilo de automatización de trenes en grandes dioramas (http://www.hispalug.com/foro/index.php?topic=14680.msg247243#msg247243), separo este por claridad y por ser una propuesta bastante avanzada.
Esta es una propuesta de un estándar de trenes funcionando con motores PF y controlados por IR y NXT, todo con material 100% LEGO y orientado a eventos. :D
http://www.youtube.com/watch?v=TMs_j0yBuNE# (http://www.youtube.com/watch?v=TMs_j0yBuNE#)
Las premisas para crear la propuesta de estándar han sido:
- sencillo de entender (eso espero)
- ampliable a número indefinido de participantes
- programa único para todos los NXT
Con todo esto, las normas serían las siguientes:
Módulo básico: material.
4 desvíos: 2 automatizados (con flecha en la imagen de abajo) y 2 no.
2 motores PF para las automatizaciones
1NXT+1IRLink para dar las órdenes a los trenes.
1 Receptor IR de LEGO más su caja de baterías.
1 sensor de color situado a la entrada de la estación.
2 trenes PF por estación.
Módulo básico: configuración.
(http://www.hispalug.com/galeria/albums/userpics/45155/a0_basico.jpg)
La estación (en rojo) debe disponer de 2 andenes suficientemente largos para alojar cualquier convoy del diorama. El desvío automatizado de entrada de la estación (flecha) reparte los trenes al andén 1 o al 2. El circuito interior ("cercanías") es de trazado libre. En caso de un único NXT, sería el único trazado existente y es el caso del video. La vía superior es "abierta" para salidas de trenes con su desvío automatizado y otra inferior también "abierta" para llegadas de otros trenes.
2 módulos: conexión.
(http://www.hispalug.com/galeria/albums/userpics/45155/a1_dos.jpg)
Cada estación cuenta con un "circuito interno" controlado desde esa estación más la conexión al resto. Cada estación expide los trenes por la vía de su color. Este circuito es absolutamente equivalente a hacer esto:
(http://www.hispalug.com/galeria/albums/userpics/45155/a2_complejo.jpg)
Funcionamiento.
Los trenes podrán circular por cercanías libremente. Y ahora el kit de la cuestión: CADA 5 MINUTOS, SE EXPEDIRÁ SIMULTANEAMENTE UN TREN DE UNA ESTACION A OTRA. TODOS ESOS TRENES (regionales) USARAN EL CANAL 1A EN EL RECEPTOR IR. El otro tren (cercanías) deberá quedar parado en la estación. A la recepción del tren, los trenes de cercanías podrán volver a circular con normalidad. La recepción se detecta con el sensor de color.
Coordinación.
Los trenes entre estaciones tardarán tiempos distintos en llegar, no llegarán a la estación receptora a la vez. No es problema. Si un tren tarda 1 minuto en llegar, les quedan 4 minutos disponibles a ambos para circular por el circuito corto (cercanías). Si le cuesta 2 minutos, solo dispondrán de 3 min. Al vencer los 5 minutos estipulados, cada estación expide un nuevo convoy y el ciclo se repite.
La única condición para que todos los NXT estén coordinados es la de iniciar la ejecución del programa en todos ellos a la vez y que un tren por estación use el canal 1A del receptor de LEGO IR.
Ampliaciones.
Ampliar con nuevos módulos/participantes es sencillo:
(http://www.hispalug.com/galeria/albums/userpics/45155/a3_tres.jpg)
Notas finales.
Los trazados pueden ser libres, con tal de que se respete el esquema (la topología). El programa del NXT, una vez creado, puede ser único para cualquier participante, evitando fallos una vez depurado y haciendo que nadie se quede fuera por este motivo. Esto es una gran ventaja.
El único parámetro modificable del programa son los 5 minutos de expedición de los trenes según las distancias de los trazados o los gustos, pero siempre en múltiplos de 5 minutos.
Otra ventaja es que siempre hay trenes circulando.
Creo que son normas sencillas, incluso con algún paralelismo con estándares que han podido consolidarse como el GBC. Ahora ya es turno vuestro para decir cuánto de disparatada es la propuesta y/o para mejorarla si es que puede ser útil en eventos. Y si no se entiende algo, este es el sitio para consultar.
Adjunto mis últimos avances. Como estándar ya veo que no triunfa, aunque me gustaría saber vuestras opiniones, quiero decir, qué puntos negativos tiene el proyecto para no poder trasladarlo a un evento. Quizás así pudiera (pudiéramos) mejorarlo, ya que todo funciona correctamente. Os dejo el último vídeo, acelerado a mitad 4x para ver la secuencia:
http://www.youtube.com/watch?v=BvjIkvJxtlU# (http://www.youtube.com/watch?v=BvjIkvJxtlU#)
Tal como está programado (y esto es modificable) la secuencia que podéis ver en el video es:
cercanías-cercanías-regional, y así sucesivamente.
Algunas (no todas) de las cosas que en su momento propuso Legofan en sus Normas ferroviarias (http://www.hispalug.com/foro/index.php?topic=13707.msg228281#msg228281) podrían ser compatibles con esto (andenes, túneles, etc), ya lo que propongo es sólo el "esqueleto" del asunto.
De todas formas, adjunto aquí los últimos avances, que son más bien ajustes. El "núcleo duro" de las normas sigue siendo exactamente el mismo. El problema más importante que había encontrado en el vídeo anterior era que los trenes, en su frenada, a veces (1 vez cada 5 o 6 vueltas) quedaban fuera del alcance del sensor. Esto ha quedado definitivamente solucionado de una forma muy sencilla. Y más cuando se cuenta, que hasta parece tonto.
Me estaba planteando poner un segundo IRLink para cubrir más campo, pero encarecía, complicaba y hacía que menos participantes pudieran optar a construir un módulo completo. Otra opción era reorientar el sensor, pero era expuesto, ya que cualquier movimiento echaba al traste la cobertura. La última opción barajada era elevar el sensor para que abarcara más área, pero también tenía el problema estético, los cables volando, la longitud de los mismos...
La solución es de lo más simple. Y por cierto, tenedla en cuenta los del resto de proyectos que estéis usando el IRLink, ya que es común. Simplemente consiste en... frenar el tren en seco. Es decir, usar la orden "Break" en lugar del "Coast" tal como lo tenía antes programado. Así, queda a una altura más que razonable para camuflarlo y sin problemas de frenada:
(https://lh4.googleusercontent.com/-XvX8Rgh6y_A/Txv0w41pZtI/AAAAAAAABJg/jPp46T5ylws/s500/A_0088.jpg)
Lo que sí es inevitable es que es necesario alargar al menos 1 de los dos cables del sensor al NXT. Es lo único no LEGO para lo que no encuentro solución. En la imagen anterior se ve el prolongador, muy sencillo de hacer. Es absolutamente necesario si se quiere hacer un anden en condiciones más largo. El resto, es 100% LEGO. Intentaré solucinarlo, pero me parece dífícil.
El único problema que resta por mejorar son los desvíos. Este problema también es común al resto de proyectos que se están desarrollando. Me gustaría hacerlo más robusto, aunque funcionar, funciona.
Pasos pendientes
Los siguientes posibles pasos son: crear el sistema de semáforos para que trabaje de forma complementaria a lo anterior y crear un "check list" de tareas para poner en marcha el invento (posición inicial de los desvíos, codificación de los trenes, su posición inicial, etc). Así no habría ningún problema al juantar módulos.
De todas formas, si en algún evento, alguien se anima a hacer un módulo de 2 estaciones y probarlo en una zona de algún diorama, estaré encantado, sigo pensando que tiene potencial.
Bien, de estas pequeñas chorraditas es de donde más se aprende :) ¿Cuantos CM más o menos tiene de frenada un tren desde que recibe el "break" hasta que se detiene? Es un parámetro que quiero tener en cuenta (con distancia de seguridad) para las distancias entre sensores (si se implementan, que como dije dependerá de como cada quien quiera hacer su módulo)
A mi tu propuesta como módulo simple para eventos ME ENCANTA, porque es fácil de montar, vale para dejar moviendo sin preocuparte un par de trenes y es 100% LEGO, lo que pasa es que yo quiero llegar un pasito más allá, y ver si añadiendo un poco más de lógica se puede conseguir un sistema que mueva 7 u 8 trenes y pueda gestionar circuitos complejos o más grandes sin necesidad alguna de operación manual.
Si se describe un sistema abierto 100%, se podrán hacer tantas versiones como personas se pongan a ello, que compartirán parte del código (incluso todo) o no compartirán nada, compartirán sensores "no lego", o no... cada uno a su gusto, pero lo importante realmente es que los módulos de circuito se entenderán entre sí y el gran circuito será totalmente autónomo, bastará con cargarlo de trenes y dejarle que los vaya moviendo tal vez con algún pequeño ajuste.
Lo de los semáforos, ¿te refieres a señalización luminosa, no? es que yo llamo semáforos también al sistema de bloqueo jajaja. Tendré que cambiar mi forma de hablar a "bloqueo" a secas para evitar que me ponga a hablar de dar una instrucción y lo confundáis con una lucecita :P
Por cierto, ¿Montaste un botón de pánico? ;) es importante si se va a enfrentar a otros módulos o si un niño de repente se pone a jugar con los trenes cuando despistas la vista...
Lo del check-list de arranque, habría que pensar en una rutina de arranque estándar, con los desvíos los pondría todos por defecto "directos" (|), pero lo que más me da que pensar es "como alimentar de trenes el sistema". Yo lo haría partiendo de "estaciones a cero, sin trenes", y que al ir introduciéndolos a mano desde una vía previa, el sensor de la estación lo computa y se lo traga...
Por cierto, para los desvíos, hay que encontrar un vocabulario común para las dos posiciones, como por ejemplo "directo" cuando está así | y "desvío" cuando está así / o así \ . Lo digo para que todos usemos las mismas palabras para hablar de lo mismo... si hay alguna forma estándar de marcar la posición de los desvíos, usémosla.
Sigo dando vueltas a lo del amplificador IR... tengo que contactar con la gente de Eurobricks, que parece que saben una jartá de electrónica, y hacer alguna prueba. Estuve echando una pensada y debería bastar con un operacional que amplifique la señal y alimente a una batería de diodos IR en paralelo, siempre que el operacional tenga un ancho de banda superior al de funcionamiento de los emisores (creo recordar que 38?), pero no se si habrá que intercalar algún componente pasivo para que vaya fino. Las pruebas son baratas jejeje, un día de estos me acerco a una tienda de componentes y me hago con media docena de diodos, resistencias, dos o tres tipos de operacionales y otro par de receptores IR. En el peor caso, se pone de por medio un integrado que regenere la señal... no se me va de la cabeza de poder implementar el protocolo PF en un PIC y así hacer un módulo IRLink casero jejeje, pero cada cosa a su tiempo.
Al principio tenía miedo de excederme de cobertura con los repetidores IR, pero si sólo se usan los IR para comandar trenes, y sólo hay un tren en el circuito en cada uno de los 8 canales, da igual que una torre IR llegue hasta la estación de en frente, dado que sólo un tren tendrá ese canal. Vamos, que mejor que sobre potencia a que falte, y así si alguien es capaz de meter en un solo enclavamiento un diorama entero, nos ahorramos una pasta en IR-Links xD.
Por cierto, ahora que digo la palabra "enclavamiento", la he copiado de los enlaces que estuve leyendo de modelismo ferroviario. Un enclavamiento en ferrocarriles es un punto desde el cual se controla un tramo de vías concreto, sea una estación, un apartadero, etc. Esa palabra me gusta más que hablar del NXT, pues habrá quien quiera implementar su módulo controlado por PC, por el móvil, por Arduino, Pics... enclavamiento es un genérico.
Gracias Puli lo primero, me alegro que te guste.
Para no liar este hilo, te comento solo lo referente al estándar. Si veo alguna cosa que se quede en el tintero, ya ta la contesto en el otro hilo o por MP ¿ok?
Respecto de la primera pregunta, te adjunto una foto cenital (con "g" lo dice un amigo...)
(https://lh4.googleusercontent.com/-xAOTzPWPvHU/Txw_GcAK5iI/AAAAAAAABJ8/0oh0DhlILWY/s500/A_0090.jpg)
La distancia de frenada es la que corresponde a esa raya azul sobre el tren amarillo y son 9,5 cm. De todas formas, como en otras ocasiones, "me alegra que me hagas esta pregunta" :D. La distancia de frenada del tren verde es mucho menos, ya que incorpora un motor XL. El tren amarillo lleva un motor mediano, mucho más rápido. Otra cuestión que afectará (y que no puedo comprobar) es el peso conjunto del convoy. Ya sabes, a más vagones, más peso, más inercia y más distancia de frenada. De todas formas, ya te da una orientación.
La distancia ha sido medida desde el cntro del receptor (tren) al centro del sensor, aunque la orden seguramente se ha dado antes de que el tren llegue a la vertical del sensor, pero eso no hay forma de saberlo. Por cierto, que la altura del sensor es de 26 cm.
Pulipuli: A mi tu propuesta como módulo simple para eventos ME ENCANTA, porque es fácil de montar, vale para dejar moviendo sin preocuparte un par de trenes y es 100% LEGO, lo que pasa es que yo quiero [...] ver si [...] se puede conseguir un sistema que mueva 7 u 8 trenes y pueda gestionar circuitos complejos o más grandes sin necesidad alguna de operación manual.
No, Puli, NO es un sistema para 2 trenes. Con este estándar se pueden mover TODOS los trenes que quieras de forma automática, no solo 8. Y en cuanto al circuito, el de la imagen se podría transformar en un circuito de 1 km de largo y seguiría funcionando igual. La longitud y forma del trazado es libre. La imagen y el vídeo son solo ejemplos. Lo que no puede cambiar es la topología, es decir, no se pueden añadir más desvíos automáticos (decorativos sí). Y todo funciona automáticamente. Revisa la propuesta para el caso de 2 estaciones y verás lo que quiero decir.
El sistema que comento es abierto en: número de participantes; número de trenes; longitudes del trazado; trazado libre. Y es cerrado respecto a la topología (solo están permitidas las conexiones descritas); respecto a los elementos usados (sensores, etc); el programa usado (para que no haya que programar nada cada vez) y el NXT. Bueno, en realidad es según se describe en la propuesta.
Sí, con semáforo me refería solo a las indicaciones luminosas. Ignorancia por mi parte...
Respecto del botón de pánico, este sistema no lo permite. Para parar todos los trenes necesitarías que todo el diorama estuviera cubierto por sensores IRLink para parar el tren en cualquier punto y esto... es inviable, claro.
La nomenclatura que propones de los desvíos me parece fantástica y muy clara: | , / o \. El único problema es encontrar el símbolo en el teclado, pero con práctica se consigue :D
De lo del "enclavamiento", tomo nota, aunque ese concepto no es necesario aquí y es más fácil hablar simplemente de "módulos", ya que no ha lugar a implementaciones libres con PC, Arduino, etc.
Un comentario rápido sobre el botón de pánico. Aunque no permita parar los trenes por alcance del emisor IR, si que debe implementarse para que la estación deje de sacar trenes cada cierto tiempo.
Otra cosita, el modo de añadir trenes al circuito supongo que será ir poniéndolos a mano a la entrada de una estacióny empujarlos para que el sensor de color los detecte. En la propuesta que estoy preparando, que compartiré en unos días cuando tenga cuerpo, he pensado en una vía muerta donde ir montándolos para evitar choques con otros trenes en marcha. Esa vía incluso he pensado incorporarla aúna estación para UE una vez puesto el tren, la estación sea la encargada de meter el tren al circuito.
Por último, entiendo que el número de trenes lo marca el sensor de color de las entradas, no? Si lo he cogido bien, habría que decir a cada módulo en que frecuencia trabaja cada tren o bien hacer una tabla con la que configurar los canales según el color de los mismos,y que todos los módulos compartan la tabla. Que pasaría si metemos dos trenes iguales o del mismo color?
No pienses que le pongo pegas, jejeje, sólo es un intento de llenar posibles lagunas que me he planteado estos días de atrás para perfeccionar el sistema y evitar potenciales puntos de conflicto que lleven a un mal funcionamiento. Cuantas más cosas estén previstas, más robusto será el sistema.
Te comento que todo lo que estoy trabajando es compatible al 100% de tu propuesta, que es una implementación funcional y probada, y de hecho fue la que me incitó a empezar a redactarlo como una aproximación al problema mostrando paso a paso como ir resolviendo los escollos que van apareciendo.
Me alegro Puli servir de "liebre" en ese sentido. Y también fantástico que le busques pegas al modelo, por si yo no hubiera pensado en ellas. Gracias. En principio lo que comentas está contemplado en líneas generales.
Respecto al botón del pánico (como mola el palabro) en NXT es muy sencillo con el botón "cancelar". Con eso se para el programa y dejan de emitirse trenes. "Solo" habría que parar los trenes que estuvieran en movimiento en ese momento.
El modo de añadir trenes es también simple y es una de las premisas de la propuesta: todos los programas NXT-G de todos los participantes deben iniciarse a la vez para la sincronización de sus relojes partiendo de la posición inicial. La posición inicial es la que puedes ver en la foto cenital más arriba. Al iniciar el programa, la mitad de los trenes que haya en el diorama se ponen en marcha a la vez y se turnan con el otro. Es decir, no hay que añadir trenes poco a poco, le das al botón y ya está todo sincronizado.
No hay límite al número de trenes. El número de trenes no viene limitado por el sensor de color ni por nada, no hay límite. De los 2 trenes que hay en cada estación, uno funciona en el canal 1A. Si hay 100 trenes, 50 de ellos funcionan en el canal 1A. Esto es posible ya que el IRLink apuntando verticalmente a 20 cm del suelo tiene un alcance limitadísimo. ¡¡¡Lo tengo comprobado, no hay problema en esto!!!, no afecta la señal al resto.
Dos trenes del mismo color. El sensor de color está autocalibrado y solo detecta cuando pasa un tren por delante con luz, no su color. No hay problema pues. Ejemplo (ficticio): cuando no hay trenes en circulación, el sensor mide un valor de 43 de luz. Al pasar el Emerald (verde), mide 15 y al pasar el amarillo, 30. Todo lo que sea inferior a 43, activa el desvío. Dicho de otra forma, la luz cuando no hay tren siempre es distinta de cuando hay, y eso activa el desvío.
Mi (casi) convicción es que funcionando 1 estación, funcionan todas. O al menos con pocos ajustes que no puedo probar por falta de material. Digo esto porque todo el estándar ya está programado y completo en el NXT que he probado y funciona :}.
Entiendo pues que toda la sincronización entre módulos, el saber en qué vía va cada tren y el momento en el que enviar un tren está determinado por un reloj ¿cierto?.
Me entra la duda de qué pasaría si las distintas patas que conectan entre sí los módulos fueran de longitudes dispares, pues habría que calcular que el tiempo de recorrerlas fuera inferior al tiempo con el que saca un cercanías por el "circuito corto", y así evitar colisiones. No veo problema en que haya que chequear esto, pero sí hay que tener en cuenta que eso sea una variable del programa fácil de modificar para poder ajustarlo al montar el módulo sin necesidad de retocar en media docena de sitios en el programa, mejor tocar sólo en uno.
Yo es que soy muy reticente a sincronizar por tiempos :D. Lo poco que he estado leyendo estos días de atrás sobre sistemas de bloqueo dice que en los principios de los tiempos se usaban los horarios como sistema de bloqueo, cada estación sabía cuando había que mandar un tren de aquí a allá y cuando debía pasar el siguiente. Pero esos sistemas por una parte no permitían mucha densidad de trenes, obligaban a veces a esperas eternas cuando las vías llevaban tiempo libres, y daban lugar a demasiadas colisiones si alguna cosa se salía de la rutina.
Sobre el botón del pánico, más que a parar el programa me refería a que las estaciones se pararan a la hora de sacar trenes, sin más, para así no tener que alimentar de nuevo cada módulo y poner los trenes uno a uno dentro del circuito para que los reconozca, pero si la solución que has implementado usa como situación de partida "dos vías, cada una con un tren", y luego el arranque tiene que ser sincronizado entre todos los módulos, ese sistema es suficiente.
Por último, yo creía que detectabas qué tren entraba en cada momento a la estación y según cual fuera se le ordenaba hacer una cosa u otra, pero veo que lo que hace la estación es que en cada momento "espera" que suceda una cosa, y se prepara para ello. Cuando llega el tren que toca, le manda donde toca, cuando hay que sacar un tren concreto lo saca, etc... Es operativo, y no dará problemas en interconectar módulos, pero me parece que limita las posibilidades de un sistema controlado por NXT.
Lo mismo sobre el esquema de compartir códigos de trenes entre módulos... es cierto que permite tener tantas parejas de trenes como módulos, pero limita en cierta manera el poder hacer más cositas. OJO, no es una crítica, ya que lo importante es que es un sistema que funciona y además lo hace bien, sino que a mi me gustaría llegar un pasito más allá, permitiendo que los módulos puedan decidir qué hacer en cada momento, o incluso poder controlar a mano si quieres que una estación saque en un momento un tren concreto en lugar del que tocaba porque p.ej. estás haciendo una demo.
Por último, una cosa que inicialmente me parecía un inconveniente "tener que parar todo para meter trenes o sacar trenes", pues te obliga a parar varios módulos a la vez, etc, puede ser una ventaja, porque el meter trenes con el circuito en funcionamiento si no tienes un módulo capaz de meter trenes... es una lata. Igual pasa si quieres guardar un tren en cocheras (automática o manualmente), que basta con parar y arrancar, mientras que si el circuito tiene algo más de inteligencia es un problema porque a lo mejor un módulo contabiliza que ese tren está aquí o allá y si lo sacas a mano puedes hacer que un algoritmo se vuelva loco esperando a que suceda algo que no va a pasar.
En fin, que me gusta pero a mi parecer es algo limitado en cuanto a funcionalidad, seguro que le puedes dar una vuelta a las ideas que tienes por la cabeza para, con un poco de señalización, pero sin soluciones rebuscadas, que se puedan hacer más cosas automatizadas sin tener que depender del tiempo.
Entiendo que si la gente no está comentando es porque no es fácil encontrar treneros con NXT para que hagan las pruebas, y no hemos logrado enganchar a más NXTeros que tengan ganas de probar... lo cual me hace pensar si el sistema que estoy pergeñando no será aún menos comentado cuando lo ponga aquí precisamente por lo mismo, pero con el agravante de que yo estoy pensando en añadir además unos módulos caseros basados en el 8574 y repetidores de IR por todas partes... y eso te obliga no sólo ya a conjugar las aficiones de trenes y robótica, sino a meterle mano a un soldador, etc... espero que en lugar de desanimar a la gente, que alguien se atreva a ir probándolo para poder llegar a ver estas moderneces en nuestros saraos.
Yo, por lo pronto, tengo a los peques emocionados con el proyecto y me han prometido que montan el circuito y me ayudan a montar los desvíos motorizados si compro el IR-LINK para hacer pruebas... aún estoy dudando si "cabrá" en un pedido que tengo a medio terminar (que ya me he pasado tres pueblos echando cosas a la cesta), si esperar un mesecito o dos a recuperarme del palo leguero (es que los peques cumplen años en un mes y estamos saturados de cajas sin montar), o si armarme de valor y programar un emisor PF usando un PIC alimentado por un 8574... (creo haber visto algo de documentación online). Si pudiera, me decantaría por esto último, pero si me las veo mal para tener tiempo delante de un PC estos días (gracias a Android puedo ir siguiendo el hilo y estudiando cosas nuevas), pensar en estar dos horas delante de una placa de prototipos es ya una quimera jejeje, por lo que acabaré comprando un IRLink y me curaré en salud aunque tenga que dejar algo aparcado mi proyecto hasta lograr fabricar un repetidor IR-PF o un emisor casero baratito y con emisores remotos.
Gracias por comentar Puli. Así sirve para poder explicar los puntos poco claros y revisar ideas. No tengas problema en sacarle pegas, al contrario, así reviso si la propuesta es sólida. Vamos allá:
Entiendo pues que toda la sincronización entre módulos, el saber en qué vía va cada tren y el momento en el que enviar un tren está determinado por un reloj ¿cierto?.
A medias. Lo único que viene dado por el reloj es el envío de trenes entre estaciones (trenes regionales). Todo lo demás, no. Es decir, la elección de la vía, la expedición de trenes de cercanías, etc, NO va gestionado por el reloj. Estoy seguro que lo primero que viene a la cabeza, sobre todo para los que tenéis experiencia de programación, es que esto trae problemas, tal como describes (magníficamente, por cierto) en tu mensaje con los inicios del tren. A ver si logro cambiar la percepción.
Creo (ya me corrige tú) que la sincronización con relojes solo trae problemas en sistemas con trazados complejos y/o abiertos. La complejidad hace que el sistema sincronizado por reloj no sea bueno. Pero no es el caso de la propuesta. En la propuesta se sacrifica nº de desvíos a favor de "infinitos" trenes y sencillez. Siempre se sacrifica algo. La cosa funciona así:
Punto de partida: cada 5 minutos (o múltiplos) todas las estaciones envían un tren.
¿Problemas en un circuito real? Puede pasar que el camino de ida regional no sea igual al de vuelta (provocando desfases); puede pasar que cuando se de la orden de salida, haya un cercanías rodando y haya que esperar hasta que llega para sacar al regional; puede que los botones de inicio de programa no se hayan pulsado exactamente a la vez; seguro que los caminos de ida y vuelta tendrán longitudes distintas en el caso de varias estaciones/módulos, etc
Solución. No hay problema en todo esto. Te explico la secuencia para explicarme (y que puedes comprobar en el video).
EN LA ESTACION EMISORA
Iniciamos el programa. Sale un cercanías y llega (detectado por el sensor de color). Sale el otro tren, también por el circuito corto de cercanías y llega y así sucesivamente. En cada llegada de tren, se comprueba si se han excedido los 5 minutos. Cuando eso suceda, sale el regional (canal 1A). La distancia a recorrer hasta la siguiente estación es distinta para cada tren regional del diorama (y por tanto, emplearán distintos tiempos).
EN LA ESTACION RECEPTORA
La estación receptora tiene al cercanías parado y está a la espera del regional. Esto lo detecta el sensor. Da igual lo que tarde, hasta que el sensor no detecte, no empiezan a turnarse los trenes por el circuito corto. ¿Cuánto tiempo estarán saliendo trenes por el circuito corto? Pues 5 minutos menos lo que le haya costado llegar al regional desde la estación anterior. Si tardó 1,45m, le quedan 3,15m a los cercanías para dar vueltas. Otro tren que haya tardado 1,05m dejará a los cercanías 3,55s para rodar. Eso, ni más ni menos, es lo que sale en el vídeo.
De esta forma, cada estación compensa los desfases de tiempo, resetea el cronómetro y todo vuelve a empezar, como si tuviera un "colchón" de tiempo. Y todas las estaciones hacen esto a la vez ya que todos los programas han empezado a la vez. El reset del cronómetro es independiente de todo lo demás, claro. Cada 5 minutos se resetea independientemente de lo que hagan los trenes.
Como bien dices, la identificación de cada tren no hace falta. La secuencia de los desvíos para el caso de 1 estación es: sale tren del andén 1, da la vuelta y llega al andén 1. El desvío de acceso a andenes cambia al andén 2. Sale tren del andén 2, da la vuelta y llega al andén 2. Cambia el desvío al andén 1... Y efectivamente este sistema limita el diseño de los desvíos permitidos, pero no limita la forma del trazado ni distancia de ellos. Algo hay que sacrificar para que la complejidad no tumbe a los participantes y sea factible.
Para mayor control sobre desvíos, trenes, trazados complejos y distintos en cada módulo (sea eso lo que sea), esta propuesta no vale: turno para vuestras propuestas. Es solo un intento lo más sencillo que he podido, los trenes de por si ya son complicados, para meter mucho tren y mucha vía con PF para eventos y lo más abierto a la participación. Si le añades complejidad (electrónica, programación, NXT...) será más chulo, habrá más control y ... menos participación. También más complejo de cuadrar y coordinar todo en un evento. Bueno, creo yo.
La prueba está en lo que acertadamente dices respecto a estos hilos: cuanto más complejos o técnicos o específicos de un desarrollo personal, menos participación. Ojo, no es una crítica, es una constatación, que me parece fantástico. El tema de añadir algún elemento adicional está abierto (barreras, semáforos...) manteniendo la "filosofía" del invento.
PD: Puli, anímate con el IRLink!
PD2: ni idea si me he explicado algo, no me resulta sencillo. Si no doy pie con bola, decidme por favor.
Jajaja, clar o y cristalino. No se si será el mejor sistema o no, pero lo que es cierto es que, salvando el Nxt, es una propuesta asequible a mas de uno y por lo tanto hay que probarla. Como decía yo quiero ir un paso más allá, pero como meto un módulo casero de detección y el amplificador IR... doy por hecho que a lo sumo dos o tres personas se atreverían, y ni siquiera se si yo seré uno de ellos :P porque soy de los que cuando hay que sacar tiempo para cacharrear tiene mil y un problemas (el día da lo que da, y suerte tengo de poder estar una horita o dos leyendo o webeando
Cita de: pulipuli en 24 de Enero de 2012, 20:25:43 PM
No se si será el mejor sistema o no, pero lo que es cierto es que, salvando el Nxt, es una propuesta asequible a mas de uno y por lo tanto hay que probarla.
Espero que sí, que haya ocasión y alguien se anime. Con tener el material (o partes de él y juntarlo entre vari@s) ya podríamos intentar un segundo módulo para añadir.
Cita de: pulipuli en 24 de Enero de 2012, 20:25:43 PM
Como decía yo quiero ir un paso más allá, pero como meto un módulo casero de detección y el amplificador IR... doy por hecho que a lo sumo dos o tres personas se atreverían [...]
Según lo complicado que sea la cosa, si consigues el ampli y un sistema que pueda funcionar, pillo ya mismo el soldador :angel:
Bueno, no sabía muy bien si poner este vídeo aquí o en Mindstorms, pero bueno, ha surgido para este proyecto. No es de gran calidad y se ve un tanto oscuro, pero con fondo blanco, todo eran sombras y aún se veía peor.
La idea del vídeo es (de)mostrar el poco alcance del IRLink en la posición en la que se han grabado los vídeos anteriores, a unos 23 cm de altura y en posición vertical.
http://www.youtube.com/watch?v=kZeXL7eAzvM# (http://www.youtube.com/watch?v=kZeXL7eAzvM#)
El sensor, cuando se activa con el sensor de contacto, está contínuamente dando la orden de marcha. Lo que voy moviendo es un receptor IR y su batería, intentando "cazar" cualquier señal o cualquier rebote de la señal. Pruebo alrededor del IRLink, en el suelo, e incluso al revés por si hay rebote de la señal en el suelo. Y nada.
He grabado varias tomas porque a veces me pasaba de cerca y se activaba. Esas tomas (lógicamente) no están, ya que lo que me interesa mostrar es que a partir de cierta distancia, no llega la señal.
Para el análisis (http://www.hispalug.com/foro/index.php?topic=14532.msg244671#msg244671) del sensor IRLink hice muchísimas más pruebas del alcance, pero al menos hay un pequeño vídeo para que se vea directamente.
Resumiendo: no hay problema de interferencias de unas estaciones a otras con el sensor en esa posición. El único peligro es que Parda y Sheepo hagan un rally con emisores PF cerca de los trenes. Y aun así, mientras no usen el canal 1 y 2 (trenes y desvíos) tampoco hay problema en un evento y todo sería compatible.
yo ya estoy trabajando en el extensor de ir, lo considero algo básico. Tengo ya un par de esquemas para trabajar con ellos primero usando piezas de desguace de viejos cacharros que tengo por casa y aun así voy a pedir un ts7238 que es un buen receptor para amplificar la señal con el mínimo de ruido. Si no me convence, regeneraré la señal de cero y no descarto crear un emisor basado en PIC que poder tunear para ponerle varios emisores remotos conectados con cable.
Enviado desde el móvil, perdonadme si se cuela alguna errata
Edito:
Ya tengo en camino un IR-LINK para hacer pruebas con el NXT :) Convenceré a mi hijo mayor para que sea él quien se encargue de las pruebas, que tiene tantas ganas como yo de mezclar el ladrillo con los trenes, y así tengo excusa para pasar una horita o dos al día "jugando" con el ordenador y el NXT :P :P... y de paso él refuerza un poco sus conocimientos de programación, que los tiene cogidos con alfileres. Dos pájaros de un tiro ;) espero que funcione... porque estas próximas semanas con los cumples de los peques y un pico de curro en el trabajo las voy a tener más liadas de lo que me gustaría, como no sea así, me va a costar avanzar una barbaridad.
Estuve leyendo ayer, creo que en un artículo de Philo o en un RailBricks, que el estándar de sensores NXT, al ser TAN cuidadoso con el consumo de energía, es lo que obliga a que el emisor IR no tenga tanta chicha como nos gustaría a sus usuarios. Se me ha ocurrido abrirlo para sacar el esquema (no he encontrado ningún destripe ni en la web de Philo) y ver si se le puede añadir alimentación extra para aumentar el rango, o incluso incorporar aunque quede cutre un mini-amplificador de una etapa IR alimentado por una pila externa (una de 9V p.ej. que ocupa poco).
Enviado desde el móvil, perdonadme si se cuela alguna errata
Bueno, vuelvo un poco a la carga con esto. Una vez establecido el estándar de una forma más o menos sólida, he estado pensando cómo mejorar las opciones con configuraciones que se pueden adoptar siendo compatibles con las normas (sin modificarlas) y que queden resultonas. Y de ahí, la "variante" que presento a continuación. Mi empeño sigue siendo que sea un estándar potente en eventos sin tener una complejidad excesiva y abierto a la participación.
Con esto dicho, lanzo esta configuración particular, que no es más que un módulo de una estación dentro de otro módulo de estación. Al ser dos módulos no conectados (1+1), casi podría decir que está ya testado según el primer vídeo que ya subí. Sería así:
(http://www.hispalug.com/galeria/albums/userpics/45155/normal_estandar_tren_D1.jpg)
La forma es rectangular, pero recordad que se puede adoptar cualquier forma irregular (ver el punto de las reglas "2 módulos: conexión"). Siguiendo las reglas, se podría enlazar un segundo módulo (o los que se quieran) al módulo verde, de forma que el circuito exterior de esta variante tuviera dos estaciones (en verde y azul en la imagen), encerrando así al módulo rojo. Quedan por tanto 2 circuitos independientes, así:
(http://www.hispalug.com/galeria/albums/userpics/45155/normal_estandar_tren_D2.jpg)
Es solo un ejemplo. Las opciones son infinitas y totalmente adaptables al diorama de turno. Y se podrían reproducir (creo) planteamientos como en este hilo (http://www.hispalug.com/foro/index.php?topic=15001.msg251020#msg251020) de nuestros amigos portugueses (ver minuto 6,53 en el siguiente video), que es el que me dió el punto de partida para esta variante:
http://www.youtube.com/watch?v=HJXH9jHotO0#ws (http://www.youtube.com/watch?v=HJXH9jHotO0#ws)
¿Qué se consigue con esta variante?
Se consigue de una forma muy sencilla que 2 trenes puedan circular en sentidos contrarios sin modificar programas, ni el estándar, ni configuración... Esto en un evento queda muy vistoso. Otra ventaja es cubrir todo el diorama de forma versátil, ya que el trazado es fácilmente adaptable sin más que añadir módulos.
En general, siempre se cumple que tendremos tantos trenes circulando a la vez como número de estaciones/módulos haya en el diorama.
Como ejemplo de cubrir cualquier zona, se pone al lado de esta variante 1+1 otra exactamente igual y tenemos 4 trenes simultáneos en movimiento (como en el vídeo 2º Arte em Peças). Y así todos los que queramos, sin limitación. Por ejemplo, así:
(http://www.hispalug.com/galeria/albums/userpics/45155/normal_estandar_tren_D3.jpg)
Ya mostré en un vídeo que el alcance de cada IRLink puesto en vertical en las estaciones no envía interferencias hacia otras estaciones lejanas. Con estas disposiciones de ejemplo de estaciones/módulos no conectados se pueden cubrir todas las zonas que se quieran cubrir y se puede complicar el trazado todo lo que se quiera para adaptarlo a cualquier diorama.
Solo es cuestión de quedar de acuerdo en los trazados o adaptarlo en el propio evento, ya que la longitud de los trazados no afecta a la programación del NXT y se puede variar sobre la marcha si surge algún imprevisto en forma de casa o mesa que se cae. Es decir, permite tanto la planificación como la improvisación en el trazado durante el evento. También se pueden combinar módulos conectados y módulos no conectados, las reglas son las mismas.
Para que no sea todo perfecto, hoy por hoy el mayor problema que le veo es en la detección del sensor de color, que pueda dar falsas detecciones en algún momento, pero creo que es un tema "menor". Es mejorable vía programación, poniendo un muro delante del sensor, sustituyendo por el ultrasonidos, etc. El segundo punto flojo sería mejorar el desvío, que lo veo poco robusto para funcionar durante horas. Pero ambos "inconvenientes" son menores y comunes a cualquier otro estándar y no me preocupan, es cuestión de ver opciones y mejorarlo.
En fin, que esto son solo ejemplos de posibles conexiones, partiendo de la "pieza básica" que es el módulo y las reglas descritas en el mensaje inicial. Por cierto Puli, no había visto tu "EDIT". Me alegro que ya tengas un bicho de estos, a ver que sacas.
Me gustan las propuestas, pardiez. A ver si monto el irlink para unas pruebas básicas y pongo en una placa de pruebas el diseño de reemisor ir, que cuando empiece a cruzar impresiones y me meta a saco con la programación, la libre tilla de notad se me va a quedar pequeña jeje
Enviado desde el móvil, perdonadme si se cuela alguna errata
Holas;
Tal y como os escribí en el otro hilo, resúltame muy interesante esto.... la cosa es conseguir tiempo.
¿Posibilidades de control sin NXT? Abriría puertas a mucha gente que no lo tiene, por coste o por el carácter del set....
Pues poderse, se puede, sólo necesitas "algo" capaz de controlar motores o servos para activar los desvíos. ¿Qué puede ser ese algo? Depende de tus conocimientos de electrónica/robótica... lo más sencillo es NXT puro, pero te quedas rápido sin puertos, si te metes en un poco de electrónica simple puedes hacer palomitas con el NXT, si quieres gastar menos aún y no te importa tener una placa de circuito sobre tu mesa y además sabes programar en C... un módulo de Arduino es lo más fácil, pues te dan "el entorno de trabajo" prácticamente listo. Si te va la marcha electrónica, pues puedes pasar de Arduino y hacerlo directamente programando microcontroladores (PIC, AVR... a gusto del consumidor), y si te va mucho muchísimo, incluso puedes desarrollar una interfaz para el PC.
En cuanto a comunicación con los trenes la dificultad también es creciente si usas PF... lo más inmediato sería usar NXT, y luego más o menos sigue la misma línea de dificultad arriba mencionada (Arduino p.ej. puede controlar el IR-LINK y creo que hay librerías para programarlo con microcontroladores también). Luego hay opciones como la comunicación por RF o incluso protocolos DCC usando vías metálicas, pero hace falta meterse aún más en harina.
El problema lo has identificado muy bien: el tiempo. Es una actividad que consume muchas horas entre pruebas y más pruebas, salvo que alguien ya haya andado el camino y te desbroce un poco la senda. Un ejemplo, si ya tienes un NXT y te compras un IR-LINK, con la experiencia de NXTorm, en un par de tardes tienes tu módulo funcionando. Si quieres trabajar con RF, y sigues los pasos de Leander, tendrás mucho camino ganado, etc.
Lo que hace falta son ganas y tener algo de inquietud y ganas de probar, aparte de unos conocimientos mínimos y disponibilidad de acceder a "piezas no convencionales" (NXT+IRLINK) o algo de electrónica.
Holas bis;
Yo pensaba en algo más asequible y alcanzable para muchos más, como por ejemplo algo mecánico implementado mediante Technic. Sé que te parecerá labor muy complicada, y lo es, pero no inalcanzable. Sería mucho más complejo pero, por contra, más barato e intuitivo....
¿Y con Pneumatics? Ando rumiando algo....
¡Ay!, si tuviera tiempo.... quizá dentro de unos años, cuando las fieras de 4 y 2,5 en vez de robármelo me ayuden en estos menesteres (eso espero, que les gusten....).
Con technic el otro día vi un vídeo en el blog de ALE! Con una idea genial para un tranvía 100% mecánico
Enviado desde el móvil, perdonadme si se cuela alguna errata
Ea, un ejemplo aprisa y corriendo. Tomando un esquema del primer mensaje del hilo:
(http://www.hispalug.com/galeria/albums/userpics/45155/a3_tres.jpg)
Imaginemos que no hay los bucles cortos y que los trenes circulan en el sentido de las agujas del reloj de estación a estación. En cada una, en su desvío de entrada, un motor. En cada vía, un sensor mecánico de contacto. Y un montaje Technic que:
- al 'pisar' un tren el sensor de la vía directa, mueva la aguja a desviada y dé orden de parada a un mando del emisor IR, por ejemplo el derecho, y orden de marcha al mando izquierdo.
- al 'pisar' un tren el sensor de la vía desviada, mueva la aguja a directa y dé las órdenes al emisor IR inversas al caso anterior.
Se puede conseguir con un motor, un emisor IR y dos sensores de contacto por estación.
Podríamos tener n+1 trenes circulando (n=número estaciones), la mitad de ellos en un canal y la otra mitad en el otro.
Habría que depurar la idea, pero ya avisé de que era 'aprisa y corriendo'....
Sencillo y eficaz, basta con definir el canal ir de los trenes directos y el de los desviados. Solo habría que echar una pensada al numeró de trenes para evitar colisiones, porque si los circuitos son de distinta longitud se acaban desincronizando las estaciones que siempre tienen un tren parado que sale cuando llega el siguiente
Enviado desde el móvil, perdonadme si se cuela alguna errata
La idea es muy interesante, pero creo que Puli da en el clavo: lo más fácil es que los trenes acaben desincronizados (creo). Vi también el montaje en ALE (espectacular) y lo veo más factible para GBC o tramos cortos o telesféricos y cosas así. De todas formas, seguiré atento por si hay progresos al respecto.
Cita de: Vi en 23 de Febrero de 2012, 23:27:45 PM¿Posibilidades de control sin NXT? Abriría puertas a mucha gente que no lo tiene, por coste o por el carácter del set....
Quizás en esto tengamos una orientación un poco distinta. La propuesta del estándar era para eventos. Por orden me propuse que fuera funcional en un evento y a continuación, que fuera lo más abierto y participativo posible, por ejemplo aportando vías, trenes, estaciones... En ese sentido creo que la automatización aporta mucho, no es excesivamente compleja y ya está toda programada.
Si invertimos los términos priorizando la participación con material más o menos estándar, al final supongo que tendremos más o menos lo de siempre aunque quizás explorando esta nueva posibilidad también se pueda sacar algo resultón, que ya digo, me parece muy intresante. Si al final saliera algo, y dado que hay tiempo hasta el "próximoeventodenombredesconocido" se podrían probar incluso ambos estándares a la vez por zonas, todo es cuestión de organizarse. Intentaré aportar en lo que pueda, la mecánica no es lo mío... :-\
Seguiremos atentos, si se logra algo más sencillo que con NXT y suficientemente llamativo en un evento (por nº de trenes, posibilidades, complejidad, etc), mejor que mejor, ya que sería una propuesta más abierta que la actual. Lo dicho, aportaré en lo que pueda.
Holas;
Pulipuli y nxtorm: no deberían desincronizarse pues en ese tipo de explotación no entra el factor tiempo, hasta que no llega una circulación a la estación 'x' no sale el tren 'y', y así consecutivamente. Sería algo a probar.
De todas formas, yo quise proponer otro punto de vista. La sugerencia de implementar ambos estándares y probarlos es lo mejor, pero requiere de tiempo, y éso es algo que ahora mismo no puedo aportar. Espero que a medio plazo sí.... :B
Ea, aunque no escriba mucho, que sepáis que por aquí andaré leyéndoos....
Buenas,
Sé que este tema está abandonado hace tiempo pero "rebuscando" vídeos por el YouTube me he encontrado con lo siguiente
http://www.youtube.com/watch?v=QIq_2onsLmg# (http://www.youtube.com/watch?v=QIq_2onsLmg#)
No utiliza NXT pero puede permitir ahorrar mecanismos más complicados para algunos tramos concretos. No es la gran solución pero como pequeño parche a recorridos concretos y viendo lo cerca que está el encuentro Hispalug he pensado que podría resultar de ayuda.
Un saludo.
La idea es muy buena, gracias por el,apunte. hace tiempo un modulo de GBC auto controlado mecánico la usaba para mover continuamente una vagoneta, y es simple y eficaz. Esta versión tiene la pega de no ser reversible, pero supone solo u.nos cuantos studs para que un vagón no tropiece si llega del sentido contrario.
A ver si le doy una vuelta a mis apuntes y me pongo de nuevo, que lo malo de tener mil frentes abiertos es que no remato ninguno :D
La ventaja es que variando la posición de la pieza que aparece debajo del vagón puedes disponer de varios trenes circulando por diferentes partes del circuito (en un mismo sentido) y "de forma autónoma" se desplazan por el que más nos interese, no es que entienda mucho de esto pero supongo que puede mejorar la cantidad de dispositivos necesarios y, como bien dices, con un poco de estudio seguro que se pueden ampliar sus posibilidades, aunque sean dos posiciones con diferentes combinaciones seguro que se puede sacar algo interesante.
Un saludo
Sí. :) lo realmente interesante es que permite que haya dos circuitos a la salida de una estacion, y que según el,tipo de tren, le enviará por uno u otro.
Ideas posibles, mil. P.ej. largo recorrido vs corto recorrido, o algo mas divertido aun: los 9v por un tramo y los PF por el otro...
Enviado desde el tablet conTapatalk HD. Perdonad si se escapa alguna errata