Automatizar trenes en grandes dioramas

[pulipuli]

Mosquis, que poquito alcance tiene el puñetero IRlink, si hay que poner dos para una estación me parece una pasada.

Ya estoy deseando ver ese vídeo :) jeje, un pequeño paso para el minifig y un gran paso para la humanidad :D

[nxtorm]

jajja, si, así es.

Bueno, después de mil ajustes, por fin he depurado el programa y ha salido. El vídeo es tal cual, a la primera toma, y sin retoques ni nada. El pobrecito Emerald, después de tantas pruebas, está sequito de batería, así que va despacito. A un poco más de mitad del vídeo, se acelera 4x el vídeo. Todo lo que va antes es un ciclo, y lo que va después, otro.

http://www.youtube.com/watch?v=TMs_j0yBuNE#

Un ciclo consiste en: circulación de un tren (cada vez uno) por el circuito corto interno (cercanías). En paralelo, un reloj del programa cronometra 5 minutos (bueno, en el caso del vídeo lo he dejado en 1 min). Pasado ese tiempo, un tren es enviado por el circuito exterior, da la vuelta y llega de nuevo a la estación. Entonces el ciclo se repite.

Los trenes son detectados por un sensor de color a la entrada de la estación.

Como podéis ver, el primer y el segundo ciclo no han expedido el mismo número de trenes. Supongo que se debe a que he tocado los cronómetros para el video, no he probado más. Eso es ya solo cuestión de ajustar.

Para añadir un segundo módulo, tal como ya expliqué en el estándar, al que por cierto tendré que hacer algún retoque después de la experiencia acumulada:



Si tuviera ocasión, intentaré "testarlo" para 2 estaciones y 4 trenes con algún valenciano que se preste, paellita mediante. Si no va mal, simplemente es cuestión de duplicar el circuito, cargar el programa y listo. Ahora me queda documentar más el tema, escuchar opiniones y ver si puede resultar útil en eventos, ya decís.

Yo creo que puede funcionar y es 100% LEGO. Seguro que es posible mejorarlo con aportaciones, pero ya hay una base concreta sobre la que discutir. Bueno, y si no, me lo he pasado más que bien. Y sigo atento a los avances de Pulipuli  en este terreno y leander (y compañía) en el otro hilo. Ale, seguimos.

[Blastem]

Como aplicación inicial es fantástica!!!

Atención, duda, respondeme pensando que nunca he usado desvíos.
La aguja de salida de la "estación" está en una posición intermedia para que pasen los trenes? No descarrilan?

Me gusta que sea todo LEGO y es una gran base para empezar a pensar en automatizar dioramas con RC  :}

[daniracer]

Los trenes pasan igual en cualquier posición, porque la aguja tiene un muellecito que permite que se pueda mover aun estando bloqueada.
Lo que ocurre es que algunos trenes que pesen poco la aguja se queda bloqueada por que no tienen el peso suficiente como para quedarse pegados a la vía y desplazar la aguja entonces si que pueden descarrilar.



SaLuDoS.

[Parda]

Me gusta, se que solo es una prueba, pero se podría tener los dos trenes a la vez en marcha? o en sentidos opuestos??

Solo con que funcione bien asi, tal cual ya es un primer éxito, muy importante para estos mega-proyectos.

[daniracer]

hay que camuflar un poco el emisor que ro va genial, lo único que le veo es que si los trenes van rápido o la sala tiene luz fluorescente puede que el tren no capte la orden de parada. Yo pondría el sensor de ultrasonidos delante de la salida de trenes para verificar que el tren ha llegado y se a parado, para que no salga el otro.

SaLuDoS.

[nxtorm]

Gracias!

La aguja de salida de la "estación" está en una posición intermedia para que pasen los trenes? No descarrilan?

Como bien dice Dani, es el muellecito el que evita el problema. El desvío es una "Y". Cuando el tren entra por arriba de la Y, da igual cómo esté el desvío, sale por abajo de la "Y". Solo cuando entra por abajo es cuando el tren va a un lado o a otro.

Me gusta, se que solo es una prueba, pero se podría tener los dos trenes a la vez en marcha? o en sentidos opuestos??

A la primera, creo que no hay problema. Con configurar el NXT con el programa A y el B, quedaría solucionado. Con tal de que el tren del circuito corto llegue antes y se pare, no habría problema. A fin de cuentas, el "tren regional" (entre estación y estación) siempre debe ser un circuito bastante más largo y debería darle tiempo. Aunque es un poco peligroso...

A la segunda, creo que solo si los andenes son muy largos. Me explico: imagina los dos trenes parados en la estación, mirando en sentidos contrarios y con el IRLink arriba. El IRLink los habrá parado justo cuando la locomotora con el receptor estuviera justo debajo. Por tanto las colas de los trenes apuntarán en sentidos contrarios, con las locomotoras a la misma altura en paralelo. No quedaría muy bonito, pero así pararían.  Espero haberme explicado algo.

[...]lo único que le veo es que si los trenes van rápido o la sala tiene luz fluorescente puede que el tren no capte la orden de parada. Yo pondría el sensor de ultrasonidos[...]

La info del IRLink va codificada, no creo que interfiera, pero tampoco puedo poner la mano en el fuego. A mi nunca me ha dado problema por ese motivo. El problema del Ultrasonidos es la zona muerta, y habría que separarlo sficientemente de las vías (y del público!) pero desde luego es una opción.

Lo de la velocidad SI puede ser un problema. El vídeo está hecho a velocidad 3 para ambos. El mercancías va bastante más rápido y ese ha sido uno de los ajustes para que no diera problemas, y lo he resuelto, pero no he probado a más velocidad. También es cierto que el mercancías iba sin mercancías... :D

Y, tomándome una cierta libertad, añado aquí la respuesta a un comentario de Hoexbroe publicado en Proyectos de automatización de trenes PF para guardar la coherencia del hilo:

Por otro lado tampoco veo factible el sistema propuesto por Nxtorm, en el sentido que no es suficientemente solida la idea de usar varios IR´s con el mismo canal, y intentar "apantallarles" entre si, para no mezclar los ordenenes. Creo que nunca va a funcionar en una exposicion en la vida real.

Para que el sistema sea viable y valido para una LUG, opino que debe ser "standard" Lego. Dificil! [...]

2) Como suele ser habitual en sistemas similares al que usa Lego, un poco de "hacking" del receptor y emisor POSIBLEMENTE (¿me atrevo decir "probablemente"?) mostraria muchas más canales disponibles que los 4x2 que usa Lego en sus productos actuales. Asi podria usarse el sistema propuesto por Nxtorm, haciendo usa de estos "ocultos" canales, evitando el problema de la necesidad de "apantallar" emisores con el mismo canal.
Inconveniente; No es "standard" tener que modificar electronicamente el receptor IR, aunque me imagino que se podria realizar sigiendo una guia, bastante sencillo, y sobre el NXT supongo que no necesita ninguna modificacion...¿?

El IRLink tiene tan poca potencia si lo pones en vertical y a poca altura que no es necesario en absoluto apantallar, no es ningún problema. Por darte un ejemplo, en el vídeo de más arriba está a unos 20 cm aprox de altura. Al principio de los ajustes, con el sensor más bajo, en las "pasadas de frenada" cuando llegaban a la estación ya no conseguía comunicarme con ellos en el siguiente ciclo por estar fuera de rango. Es decir, 4 o 5 cm fuera del alcance bajo el sensor y dejaba de funcionar. Lo mismo en vías laterales. Así que de estación a estación ni te cuento, no llega nada y de verdad que he hecho muchas pruebas al sensor. Lógicamente, si elevas el sensor tiene más campo útil, pero ni así sería problema, ya que la señal va en vertical.

Por tanto, la opción 2) no se hace necesaria, aunque algo he leído y a mí tambien me suena que esa opción de trastear el receptor es posible (creo que algo puso yagodiaz). De todas formas, intentaré hacer más pruebas y si puedo subo un vídeo y ya ves. El único problema real de interferencias en un evento podría venir cuando Sheepo y Parda se pongan a hacer una carrera de coches RC, ahí sí que habría que parar los trenes  xD

PD. Puli, no desaparezcas, que (espero) aquí aún hay mucho que rascar y seguro que sacamos algo por un sitio o por otro entre tod@s  ;). No me resisto a que podamos tener un tren algo más automatizado en algún próximo evento. 

[daniracer]

Esque es un problema lo de la rapidez por que puesto que no puedes cambiar el programa según el tren que pongas... por eso te dige de poner el infra al final de la vía para que sea instantáneo, (llega el tren y se para) de lo contrario te puedes quedar corto o incluso pasarte.

SaLuDoS.

[leander]

Anda, no había visto el vídeo, ¡como mola!.
¡Animo! poco a poco.
Con el tema NXT yo ni papa, y me pierdo con las explicaciones y comentarios que poneis.

[pulipuli]

Jajaja, Leander, tu eres más de litrónica :D es normal que el NXT de primeras te suene a chino. Piensa que es un arduino que tiene posibilidad de meter 4 sensores y tres motores PaP, que se comunica con los sensores usando I2C bus, y que se puede programar en Java, C... aunque la herramienta preferida de la comunidad es NXT-G, un entorno 100% gráfico donde no picas texto sino que insertas instrucciones que son iconos,  a los que puedes modificar parámetros. Como ves, está muy limitado en cuanto a puertos de sensores... pero es muy fácil de usar, y es 100% LEGO :)

NXTorm, enhorabuena por el resultado de las pruebas, es más que prometedor, y creo que no habría problema en enfrentarlo a un módulo equivalente para que dos estaciones se pasen trenes entre sí, y cada una tenga su circuito de cercanías, a lo sumo habría que añadir alguna pequeña puntillita... pero lo importante es que PROMETE!!!

A la pregunta de Parda, tal como está diseñado, puede tener los dos trenes en marcha, pero hay potenciales puntos de colisión como son el  cruce donde se unen los circuitos corto y largo. Se pueden implementar mecanismos para evitar la colisión a base de temporizadores o medición de velocidad media de cada tren, pero son pequeñas ñapas. Lo único que evitaría las colisiones es implementar más sensores y poder "parar/arrancar" allá donde sea necesario.

Por las mismas, si queremos implementar bidireccionalidad en los circuitos hay que añadir complejidad poniendo más sensores. Al final todo es cuestión de poner más sensores y aumentar el rango del IR-LINK, que para todas las ideas que tengo en la cabeza es con gran diferencia el principal escollo.

PD: NXTorm, no desaparezco jeje, sigo rascando, pero entre el trabajo, los niños, la casa... entro a ratitos mientras echo un pitillín con el móvil, mientras hago la cena con el ipad, mientras espero en el médico... a ver si junto un par de horitas con un PC y puedo avanzar un trecho en las especificaciones funcionales, intentando sacar una básica para poder unir dos circuitos como el que has implementado, cada uno con su vía de cercanías. Por cierto, ¿Qué alcance tiene el sensor de color que has puesto a la entrada? ¿cuanto se le puede separar de las vías?

[leander]

He reprogramado el pic receptor para que cuando reciba la señal una vez deje el led encendido constantemente...
Me he llevado el emisor hasta el buzón que hay en la vuelta de la esquina (20 metros a ojo) y he apretado el botón... :P
...cuando he vuelto a casa ahi estaba... el led encendido  xD
A ver si me llegan el resto de los componentes para poder avanzar esta semana.  :_(

[pulipuli]

Me bajé a fumar un cigarro haciendo un kit-kat en el curro, y me puse a darle vueltas a "como vería yo un proyecto de trenes a lo grande", con bloques de software autónomos que controlan cada módulo sin necesidad de estar comunicados con el resto de bloques de software que controlan el resto del circuito, y he sacado unas cuantas conclusiones:

1.- Todo módulo de circuito debe tener a su entrada un detector de qué tren entra para poder pararlo. Si no se sabe que tren entra, no se sabe cual hay que parar
2.- Todo cantón de circuito (Cantón: tramo de vía única, sin desvíos, en el que como mucho puede haber un tren) debe tener a su salida un sensor para saber cuando se queda vacío. Ese sensor no hace falta que detecte el tren, sólo debe saber cuando queda vacío.
3.- Se pueden hacer circuitos bidireccionales, para ello es necesario tener sensores de detección de código de tren en cada una de las vías que entra/sale de un módulo.
4.- Todo módulo de circuito debe monitorizar el cantón o cantones de salida para saber cuando puede enviar un tren. Obviamente, si el módulo controla un tramo de vías (p.ej. el módulo de estación con circuitos corto y largo de NXTorm), no es necesario monitorizar ya que el propio programa sabe donde hay un tren en cada momento.
5.- La capacidad básica de direccionamiento de un sensor I2C 8574 son 8 puertos, y la máxima de 255 puertos. Esto obliga a que si se usa un sensor de tipo de tren con capacidad de hasta 7 máquinas (3 bits), se pueden implementar hasta 32 sensores (5 bits) por puerto del NXT, y si el sensor tiene capacidad de hasta 15 trenes (4 bits), se pueden implementar hasta 16 sensores por puerto del NXT.
6.- Si se implementa el control de los motores de los desvíos mediante puertos I2C con 8574, se gastan 2 bits por cada desvío, uno para girar a izquierda y otro para girar a derecha. El desvío debe llevar una pequeña electrónica que al recibir las órdenes por uno de esos dos pines, active el motor en el sentido correcto, y no hará nada si se recibe por las dos simultáneamente. Esto exige diseño electrónico. La otra opción es controlar los desvíos con puertos NXT estándar.
7.- El cableado de puertos de cualquier circuito debe estar planificado de antemano, y debe poder introducirse a los programas en forma de tabla preferiblemente para poder configurar el software fácilmente. De hacerse "a piñón fijo", cada vez que cambiemos un puerto de sitio en un módulo, vamos a tener que revisar toooooodo el código. No se si esto puede hacerse con NXT-G.
8.- Aunque más o menos creo que lo he comentado más arriba... cada vez que ponga un cruce con dos vías que pasan a una, hay que tener detectores en ambas, y tengo que tener la posibilidad de parar a uno de los dos trenes (con el algoritmo que sea). Así, cada cruce se puede considerar internamente como un pequeño sub-módulo. Si es un módulo independiente, los sensores deben ser capaces de saber qué tren es el que se aproxima, si es un sub-módulo de software, podrá saberlo consultando las variables del programa.

Y me surge alguna duda que los programadores NXT-G sabréis contestarme.
Cada módulo de software controlará un módulo de circuito, y será independiente del resto de módulos de software. ¿Puedo en un mismo NXT correr simultáneamente varios módulos? No se si se puede hacer directamente, o si tengo que guardar cada módulo en un fichero independiente y luego ir copiando y pegando los que vaya a utilizar en un nuevo proyecto, lanzando al principio del programa una bifurcación para que se ejecuten todos en paralelo.

Edito:
Para los que quieran juguetear un poco con circuitos digitales viendo lo que hacen o dejan de hacer las señales, un compi me ha recomendado este programa muy sencillito que te ahorra tener que estar pinchando y despinchando. Lo voy a usar para jugar a multiplexar/demultiplexar la salida de un PFC8574 y así tener las 255 entradas/salidas que puede proporcionar. Una vez "jugueteado", hay que hacer el diseño en fino con un programita más versátil, pero este te permite probar en la pantalla tirando hilitos antes de pinchar y despinchar

[Hoexbroe]

Hola,

Efectivemente habia colgado la mayoria de mis comentarios en el hilo equivocado; el de Leander.
Lo siento, ya que era más relevante aqui, asi que intento continuar aqui!

Con frenar "bruscamente", solo refiero a cortar la alimentacion al motor en lugar de bajar la velocidad secuencialmente dando ordenens por IR.
Es cierto que se necesita un interuptor fisico. Que tal ese;
[pbricklink]bb97[/pbricklink]
Este funciona con "roce mecanico" y funciona de p.m. Tenia un set de esos (con dos semaforos) cuando era niño.

Con NXT´s comunicando entre ellos, pienso que no tiene porqué ser limitado a solo 3-4, pero enviando cadenas de bytes se puede direccionar más unidades, si todos los NXT que recibe el señal primera mira si es para ello; P.e; Si 10 NXTs ven el valor "3" en el primer byte recibido por comunicacion, solo el NXT con el programa numero 3 reacciona, ya que sabe que es el numero 3. -Como el sistema por radio-frecuencia de Leander.

Me interese mucho el video de Nxtorm, pero por desgracia no le puedo ver donde estoy ahora...

[nxtorm]

Madre mía, empiezo a estar desbordado... Bueno, muchas gracias por los ánimos, comentarios, etc. El video efectivamente es una prueba, pero ha funcionado perfectamente.

No se bien cómo organizar la respuesta, hay mucho y creo que lo separaré en 2... Empezaré por la primera respuesta de Puli. Usaré el azul para citar el tema del que se habla. Entiendo que es un lío, pero...

[...] dos trenes en marcha [...] mecanismos para evitar la colisión a base de temporizadores [...] más sensores [...]

El "mecanismo" por el que sale el regional (circuito largo) es un reloj: cada 5 minutos sale un tren. Es como el juego de las sillas: al toque del silbato, se pasa un tren de una estación a otra en el sentido de las agujas del reloj. Siempre que el cercanías (circuito corto) regrese a la estación antes de que llegue el regional, se podría hacer. Pero el riesgo es que se juntaran varias personas en un evento con su módulo, haciendo que el circuito largo fuera demasiado corto y no le diera tiempo al cercanías a llegar a estación. Solución "posible": que una estación no envíe tren hasta que el tramo no quede libre (sistema de cantones). Esto colapsaría al sistema como un dominó, ya que al golpe del silbato todos deben enviar un tren. Yo lo descartaría. Recordad que en cada instante hay tantos trenes simultáneos en circulación como participantes/módulos.

[...] si queremos implementar bidireccionalidad en los circuitos hay que añadir [...] más sensores [...] y aumentar el rango del IR-LINK [...]

Hasta donde yo se, el alcance del IRLink no se puede aumentar. Lo que se puede es optimizar (ver review). En cuanto a la bidireccionalidad sí se puede implementar. Como todo, tiene ventajas e inconvenientes. Me explico mejor con una foto:



Se ahorra un desvío automatizado, ya que los 2 desvíos de las flechas serían fijos. Solo queda automático el desvío del círculo de la imagen, ya que es el que envía al tren al circuito de cercanías (corto) o regional (largo). Como inconvenientes, varios: un sensor adicional. Antes con un sensor detectábamos los 2 trenes que entraban por el mismo sitio. Si quisiéramos estaciones (módulos) de 2 y 1 sentidos conviviendo en el mismo diorama, habrá que tener a disposición 2 programas diferentes. Por último, el problema ya comentado a Parda de andenes largos, ya que los trenes pararían cuando las locomotoras estuvieran en paralelo en la vía y justo debajo del IRLink. Complica un poco pero es una opción, aunque yo empezaría por lo sencillo.

[...] a ver si [...] puedo avanzar [...] intentando sacar una básica para poder unir dos circuitos [...]

No se si te entiendo bien Puli, pero ya está todo definido en el estándar que propuse ¿te refieres a eso?. Revisa a ver por favor.

¿Qué alcance tiene el sensor de color que has puesto a la entrada? ¿cuanto se le puede separar de las vías?

Me alegra que me hagas esta pregunta  :D. La respuesta rápida sería "muy poco, cuanto más cerca, mejor". La respuesta sesuda sería que depende de las condiciones. Por poner un ejemplo burdo, con el sensor de color en modo luz ambiente (como ha sido el caso), podrías detectar el sol, que está muy lejos. O un coche lejano de noche en una carretera oscura acercándose. Si hablamos de superficies lisas de color uniforme (sin luz propia), el negro refleja mucho menos que el blanco y todo ello influido por la luz ambiente de ese momento y que está en constante cambio...

Para que te hagas idea de la diferencia, un sensor de ultrasonidos no puede hacer ninguna de estas cosas que acabo de decir, ni tampoco se ve afectado por ninguno de esos problemas. En resumen, mejor no separes el sensor de la vía más de 3-4 cm. Si las condiciones ambientales fueran fijas, se podría alargar mucho más el rango. Alternativa: usa ultrasonidos o un led blanco apuntando al sensor desde el otro lado de la vía a modo de "fotocélula en barrera".

CONTINUA EN EL SIGUIENTE MENSAJE

[nxtorm]

SIGUE EL MENSAJE ANTERIOR

Respecto al segundo post que envías, el "Proyecto de trenes a lo grande" (cómo mola el título), lo que te puedo ofrecer es mi colaboración, en la medida de mi tiempo, si lo quieres implementar en NXT-G. Todo eso, verás que se complica bastante y se hace muy engorroso de programar, pero dicho queda. Lo digo porque a mí me queda grande en algunos puntos, tanto de electrónica como de programación, pero si te lanzas a ello, intentaré colaborar en lo que pueda, ya que el enfoque es distinto en mi propuesta estándar.

Puedo también comentarte puntos que domine más y que no vea claros. Voy a ello:

1. Saber el tren. Alternativo al tema de imanes bajo el tren, existe el "Sistema de Identificación por RF", conocido por RFID. Personalmente ya te puedes imaginar que preferiría emular esto de forma casera con los imanes como propones, pero lo veo complicado como ya te expliqué. Te dejo los enlaces: tag y sensor. Existen otras formas de emularlo, ya te daré info.

2. Sensor a la salida del cantón. Si no lo he entendido mal, eso obligaría a cables muy largos desde el sensor hasta el NXT de la estación de origen. Si por el contrario, el sensor está conectado a la estación destino, esto obliga a establecer comunicación entre una estación y otra (entre un NXT y otro) para pasarle la info. Complica la programación, el testado (necesitas 2 NXT) etc.

6. Controlar motores con I2C. Ni idea de cómo hacerlo, pero me resulta muy interesante, también por motivos obvios. Respecto a controlar el desvío con puertos del NXT, es perfectamente posible. Yo he usado motores PF para conservar la máximo la batería del NXT, ya que me sobran canales del IRLink. Otro motivo adicional: no existen cables de prolongación para NXT, cosa que no ocurre con PF, que sí hay prolongadores de cable. Bueno, y en ambos casos se puede cortar y hacer uno casero, eso sí.

7.- programas en forma de tabla.
El NXT-G no dispone de manejo de tablas. Con eso te lo digo todo. Sí que hay arrays 1D, pero nos salimos porque no es software original. Si quieres, en mi web hay un tutorial de arrays. De todas formas, este punto no lo acabo de comprender del todo, creo que por la nomenclatura que usas.

8.- sensores en cruces.
Este punto tampoco lo he seguido bien, pero ten en cuenta que si quieres parar un tren, en su cocorota debe haber un IRLink, que parece que ese punto estaba claro.

9.- Módulos de software en paralelo.
Sí, NXT-G lo permite, pero está desaconsejado. O mejor dicho, aconsejado solo cuando sea estrictamente necesario. La gestión de información compleja en paralelo en el NXT no la he probado nunca, no se cómo responde. En ese sentido, otros lenguajes (C, Java, etc) son mucho más potentes. Aunque se pueden hacer grandes cosas, el NXT-G es lo que es. Y bueno, comparado con un PC, el procesador del NXT también es limitado (supongo yo).

10.- Programa PCF8574. No está el enlace Pulipuli.

Y ahora, turno para Hoexbroe. Y no te preocupes Hoex, ya entiendo que no es sencillo precisamente seguir el hilo de este hilo  :D
Respecto del (no se cómo llamarlo) bb97, ¿podría alguien dar alguna info adicional de lo que hace? No lo conocía y parece interesante artilugio. De todas formas, el IRLink da la orden de parar en seco. Meter ese elemento antiguo en un estándar complicaría las cosas para hacerlo fácil a la gente. Pero me ha llamado mucho la atención, desde luego.

Y de las conexiones BT con otros NXT, llevas razón, se puede y el NXT-G permite comunicarse con infinitos otros NXT (creo, evidentemente no he probado). Pero, simultáneamente, solo 1 master a 3 esclavos emparejados. Para comunicar con un 4º, hay que usar la función "cerrar conexión" y luego "abrir conexión" con el nuevo NXT. Esta función no la he usado nunca, pero descarta cualquier intento porque debe ser muy lenta en conjunto (seguro que más allá de los 20s si no más).

Bueno, siento el tostón ¿cuándo se habilita la videoconferencia en el foro??? Saludos