Noticias:

¿Has Leído las Normas de HispaLUG? LEER AHORA

Menú Principal

Automatizar trenes en grandes dioramas

Iniciado por nxtorm, 03 de Enero de 2012, 20:47:56 PM

Tema anterior - Siguiente tema

0 Miembros y 1 Visitante están viendo este tema.

nxtorm

Sí, sí, trenes RC.

Al principio de mi propuesta de estándar de automatización de trenes de los dioramas proponía 1 o 2 sensors de luz (o color) en cada estación. De todas formas, con el método propuesto, no es posible que se junten o choquen trenes en vías comunes, ya que solo hay 1 en circulación. La propuesta a debate solo desarrolla cómo hacerlo, pero a priori la idea parece sencilla y factible (creo). Por concretar mucho sería así:



Resumen del estándar.

Cada estación mantiene 1 tren de cercanías (circuito cerrado corto) en circulación. Cada 5 minutos (o 10), el cercanías se detiene en el andén y se envía un segundo tren de una estación a otra (circuito largo) en el sentido de las agujas del reloj. Una vez ha llegado, el ciclo se repite. El sistema es ampliable a más participantes.



pulipuli

#16
Mosquis, hacía mucho que no entraba en este subforo y descubro este hilo :)
Lo marco para leer con calma en cuanto tenga tiempo que he visto así por encima que algunas de las cosas que me planteaba ya están sobre la mesa.

Bueno, leído y entendido (creo :P) lo hasta ahora escrito.

Me encanta como se están concretando las cosas porque es más o menos la idea que yo tenía in mente: RC para dar órdenes a los trenes (hasta 4 y así dejar otros 4 canales para que pueda haber otras cosas RC por la sala sin que interfieran, importante en exposiciones... y en una casa con hijos que tienen coches RC jejeje), y cableado para comandar los desvíos.

Lo primero que hice fue entender por encima el esquema de estación oculta de Henrik. Para no haber visto nunca uno, creo que más o menos entiendo su funcionamiento, un conjunto de sensores, un conjunto de servos, y que en modo automático el que se abra una vía haga que a continuación se abra la siguiente. Lo siguiente fue entender lo de los cantones, que más o menos ya había leído algo del tema sobre trenes analógicos, pero es implementable en este caso sólo con el sistema 9V, o a lo sumo con trenes con motor PF "a piñón fijo" activados por un interruptor/sensor ubicado en su parte inferior.

Lo de los SRK no me lo había planteado, aunque doy fe de que es muy práctico... de hecho recuerdo que había un sistema de slot digital que los usaba como detectores. Yo había pensado más bien en sensores electro-ópticos, que son fáciles de construir aunque requieren soldaduras y un circuitillo básico, que devuelven una tensión alta o baja según si detectan o no un objeto a unos 2cm del sensor. Ahí es donde empecé a trabajar hará un añito, inicialmente para controlar un simple semáforo y bajar unas barreras, un circuitillo simplón a más no poder pero que ya requiere andar soldando, cosa que a la mayoría de treneros les echará para atrás. Por eso, pensé incluso en hacer un diseño de una plaquita fácil de montar y compacta para facilitar la vida a los que vinieran detrás, pero me faltaba el elemento clave: la modularidad, lo que yo hice estaba pensado para el fin que estaba pensado, por lo que para poder hacer algo "replicable" por más gente, primero había que definir una norma modular que permitiera enchufarlo... y ahí me quedé, porque el NXT lo controlo lo justito para hacer cuatro cosas con la caja NXT2.0 de mi hijo mayor, pero siempre en el mundo LEGO, no me puse a buscar como conectarla con el mundo exterior. Todo este párrafo para decir que si hay algún módulo que permita monitorizar "contactos" ya sean electrónicos, magnéticos o físicos con el NXT, se pueden "hacer palomitas" ;), da igual de que tipo sea el contacto si tenemos unos parámetros de tensión/corriente a respetar por cada sensor, y se pueden implementar todo tipo de sensores. A mi me gustan más los optoeléctricos porque cambias el sensor y cambias la distancia, o un módulo sencillito puede controlar varios puntos de un tramo de vías (para detectar p.ej. trenes largos)... pero todo se puede hacer con contactos mecánicos y más fácil y limpio aún, con SRK.
Mi duda es: ¿Como alimento el NXT con sensores externos? Pero aquí están los maestros del NXT que seguro que nos lo resuelven (tengo que echar un ojo con calma a tu web NXTorm)

Visto esto, está resuelto el tema de detectar trenes, y con un ladrillo se pueden enviar órdenes a trenes dentro de su rango de acción. Si el diorama tiene varios ladrillos controlando zonas, es tan fácil como enmascarar los emisores con unas pantallas para que no se desvíen las órdenes fuera de su rango, pero tampoco es problema si el número de trenes a controlar es discreto, y me explico: puede haber circuitos con 4 trenes en marcha pero con hasta Nx4 trenes aparcados siempre que cada grupo de 4 trenes parados esté en un andén que no reciba más que al emisor de "entrada/salida de su estación"... habría varios trenes "1, 2, 3 o 4" pero sólo uno de cada tipo en movimiento cada vez, y tantas dársenas con su IR-Link independiente como grupos de 4 trenes hubiera en movimiento. Esto, se puede obviar por ahora, es rizar el rizo, pero lo dejo escrito porque cuando se quiera crecer en número de trenes es una alternativa que conviene considerar.

Con esto están resueltas las dos primeras incógnitas: saber donde hay un tren y dar órdenes a los trenes de forma individual. La tercera incógnita son los desvíos, pero pueden hacerse mediante un sistema cableado usando los 3 puertos de motores del NXT que permitirían controlar hasta 3 desvíos o accesorios por cada ladrillo NXT (si se multiplexan, son más). Aquí veo un problemilla... me parecen pocas salidas por cada módulo NXT. Si es para desvíos, un ladrillo puede gestionar bien una estación sin problemas, pero si se quieren meter p.ej. barreras móviles, semáforos... o se ponen en paralelo con los desvíos, o se consumen puertos de salida. A eso aún no le he encontrado más solución que multiplexar las salidas, supongo que habrá algún adaptador para hacerlo (no me gusta meterme en tanto adaptador, que la economía no está para excesos, me gustaría hacer cosas con lo que tengo y si me gusta ya ampliaré).

Por otra parte está el tema módulos. El esquema último que has colgado, NXTorm, me gusta cuando pretendes con un ladrillo controlar un circuitillo único, con una estación y unas cuantas vías. De hecho el esquema viene muy bien porque permite optimizar un NXT y da directrices para implementar otros módulos.

Para concatenar varios módulos en un circuito grande, yo me planteo las cosas en términos de estaciones y playas de vías por una parte, y en control de tráfico en el diorama por otra parte. Me explico: Una estación o una playa de vías es autónoma, y puede funcionar sola sin mayor problema independientemente de que haya más módulos controlados por NXT en otra parte del diorama, o que sea ella solita la única zona controlada. Si defino el módulo "estación", pienso en los imputs del módulo (tren aproximándose), las variables internas (Vía uno, vía 2, vía 3..., presencia de tren en vía 1, en vía 2, en vía 3..., estado de los desvíos de entrada) y en las salidas del módulo (dar marcha al tren 1, 2, 3..., activar desvíos...). Hasta ahí es fácil y es similar a un sistema como el que pinta Hoexbroe más arriba en su mega-diagrama (bien detallado, pardiez... aquí está el URL de la imagen, que alguien no podía verlo en grande http://www.majhost.com/gallery/Hoexbroe/Layout/Details/schattencontrolplc_1.gif). Una vez pensado el módulo, su gestión es una máquina de estados que no es muy difícil de calcular para implementarla en NXT, de hecho si definimos un estándar de como numerar sensores y desvíos en un módulo, ese código puede aprovecharse para replicarlo y tener varias instancias según el tipo de funcionamiento que queramos (secuencial, aleatorio, manual...).

Es laborioso, pero relativamente sencillo de montar, aunque tiene un pero bien grande, que igual no es "tan pero":
¿Como se qué tren viene? Pueden venir el 1, el 2, el 3 o el 4, y yo lo aparcaré en una vía. Cuando tenga que decirle "vete", dejará su hueco en la vía, pero ¿Como se qué tren está en cada vía? Puedo saber qué vías tengo libres poniendo un sensor en cada vía, pero si quiero clasificar los trenes (esta vía para trenes largos, esta para los cercanías...) tengo que saber identificar al tren que llega. Ahí se puede p.ej. implementar un detector por colores o poner hasta 4 imanes pequeños bajo cada tren (coincidiendo con los 4 studs de las vías) y en cada stud poner un sensor. Así, pegando una plaquita de imanes a la base de cada tren, el sensor de "entrada" del módulo, sabrá si llega el tren 1, el 2... y luego sabrá donde está exactamente porque el mismo módulo lo habrá colocado en una u otra vía.

Resumiendo, una estación según este enfoque debería tener un sensor que diga cuando llega un tren (y que diga al módulo qué tren es el que llega),  a continuación activará los desvíos para ubicarlo en una vía libre y adecuada al tren que llega, tendrá un algoritmo interno que pare los trenes tanto o cuanto tiempo, y los saque según las condiciones que nos vengan en gana, un sensor de salida que nos diga si podemos ordenar a un tren salir de la estación, y sensores bajo las distintas vías de la estación que detecten cuando el tren que llegaba ha llegado a su posición de parada para ordenarle detenerse.

Así, con un módulo se puede controlar una estación. Si quedan puertos libres, se puede, como en el ejemplo que pone NXTorm controlar algún desvío adicional, pero eso prefiero considerarlo un módulo aparte. ¿Por qué digo esto? porque es más fácil resolver el problema "despiezándolo" que tratándolo como un todo. Para resolver ese circuito casero con una estación sencillita con dos vías, y un desvío para tener trenes en dos tramos distintos, haría un módulo aparte, y si el número de entradas y salidas del módulo caben en un NXT que ya tenga montada una estación, es cuestión de ponerlos juntos. ¿Qué os parece?

Así, el módulo de desvío que controle dos circuitos (los voy a llamar exterior e interior, o A y B, según gustos), es igual que el módulo de estación, una entrada diciendo qué tren llega, un desvío que manda los trenes por el circuito A o B, un sensor a la salida de cada tramo para saber que puedo enviar el tren "más allá de donde yo controlo" sin que choque con otro, y yatá. El módulo verá que viene un tren, y según el tren que venga, o según qué circuito está libre, lo enviará por uno u otro. El circuito tendrá sensores que eviten colisión de trenes antes de llegar a un desvío que une dos vías, o entrar en un tramo... algo así como los cantones que planteaba Hoexbroe en su circuito plano: para dejar pasar un tren de un punto tengo que saber que a partir del mismo no hay ningún tren.
Este módulo es algo más complejo de programar porque permite muchas variaciones, pero si lo consideramos como un tramo de circuitio interior y otro exterior, básicamente funciona idéntico al módulo de estación.

Si voy a implementar un circuito de estación y uno de circuito simple usando un único NXT podemos ahorrarnos el detector de qué tren llega al desvío que hay tras la estación, porque a ese punto llegará el tren que hemos mandado salir de la estación. A la hora de programar, yo lo programaría como una variable externa, pero al unir los dos módulos "se cortan las puntas" y se considera variable interna. Así se puede resolver el esquema en dos trozos independientes, requiere un pelín de trabajo inicial más, pero una vez hecho permite reutilizar todo para módulos más grandes.

¿Como uno módulos de circuito?
Una estación es autónoma, siempre y cuando no le envíen más trenes de los que es capaz de absorver. Lo mismo pasa con un circuito "X", que tiene una capacidad de trenes. Para ello es imprescindible hacer cantones, de tal modo que todo módulo sepa si a su salida puede enviar un tren, sabiendo que el módulo siguiente ya lo parará cuando llegue si no puede aceptarlo.

Para circuitos complejos, como un gran diorama, hay que diseñar todo en base a cantones: cada NXT controla su cantón/cantones, y sólo su cantón/cantones, y debe tener sensores a la entrada y salida de cada cantón. Supongo que todo esto está resuelto por los modelistas ferroviarios, yo hablo desde mi desconocimiento de la forma habitual de proceder, pensando en un circuito como una máquina de estados finitos. Lo explico mejor con un ejemplo:

Un circuito alargado, de sentido único "cuadrado" con una estación en cada estremo con dos vías cada una, que creo que es fácil de explicar sin pintar hablando de "norte, sur, este y oeste" como los cuatro lados del cuadrado:

Módulo 1: estación oeste
Módulo 2: estación este.

Cantón 1: Estación oeste
Cantón 2: línea norte
Cantón 3: estación este
Cantón 4: línea sur.

El módulo 1 debe tener un sensor que detecte cuando viene un tren por la línea sur (cantón 4) y lo detecte a la entrada de su cantón. Internamente funcionará como un módulo de estación, detectando el tren que viene, poniéndolo en la vía correcta, parándolo el tiempo determinado en la programación... y sacando un tren "cuando toque y pueda": es decir, tendrá un sensor para saber que la línea norte está libre (cantón 2), y sólo sacará un tren cuando toque si hay una vía libre. Si la línea de salida está llena, no podrá sacar trenes, e irá almacenando trenes hasta ocupar todas sus vías internas, y si llegan más trenes de los que puede albergar, los parará a la entrada.

El módulo 2 hace lo mismo, sólo que su entrada está por el norte y su salida por el sur.

Para saber que un cantón tiene "vía libre" yo pondría un sensor a la entrada y otro a la salida: Si pasa un tren por el sensor de entrada, el cantón está ocupado, y si pasa uno por el de salida, el tramo está libre. Todo módulo tiene que tener dos sensores para saber que el tramo de salida está libre, y un sensor con detector de tipo de tren a la entrada para saber que está llegando un tren.


En fin, creo que es demasiado ladrillo por hoy, espero que me haya explicado bien. Mi intención es que se pueda replicar todo en base a módulos, aplicando la filosofía de los cantones que comenta Hoexbro más arriba, y que cada módulo pueda programarse en un NXT. Habrá módulos complejos que puedan requerir varios NXT (p.ej. estaciones grandes), habrá otros tan pequeñitos que me quepan más de uno en un NXT, y circuitos que puedan implementarse por completo usando un único NXT con un sensor IR-Link y un módulo de muchas entradas por contactos, y tantos motores como desvíos. Las órdenes a los trenes irían siempre por RF con el IR-Link, y a los desvíos por cable. Los sensores estarían todos conectados por cable. Se pueden acoplar "funciones" auxiliares como semáforos autónomos (activados p.ej. por uno de los sensores), o controladas usando motores o puertos de salida del NXT.

Tengo que sentarme a intentar pintarlo, que seguro que facilitará la comprensión, e investigar sobre esos módulos para poder meterle un puñado de sensores a base de contactos al NXT.

PD: aquí radica la ventaja de un sistema DCC: Todos los sensores, motores, mecanismos, accesorios, están conectados a la vía y reciben de la misma o inyectan en ella la información, y un sistema central controla todo. Se ahorran kilómetros de cableado y la complejidad se reduce mucho... un sistema hecho con este sistema se puede implementar con soluciones "casi 100% LEGO", peeeerooooo.... requiere tirar cables por doquier, lo cual no es muy aconsejable para un gran diorama en un evento: un ejemplo: pensad que las dos estaciones del ejemplo están separadas entre sí 10 metros, hay que poner sensores al quinto pimiento de cada estación para saber que el cantón de salida está libre  :s

Edito: He estado dándole vueltas a la cabeza mientras recogía a los peques del cole. Tiene que haber una forma más simple de saber que el cantón de salida no tiene trenes sin necesidad de tirar un cable largo hasta la entrada del siguiente módulo.

Re-Edito: adjunto un esquema de módulos de las dos estaciones que comento más arriba. Sólo pinto los puntos con sensor de la estación Este y cantón norte (salida de la estación este). El cantón sur y estación oeste son lo mismo pero girado 180º. Se puede controlar la estación usando un IR-Link para comandar los trenes dentro de la zona de cobertura bordeada con trazos de color azul, dos sensores en el cantón norte para saber si está ocupado, un sensor en cada vía para saber cuando detener el tren, un sensor con detector de número de tren que entra, y un motor para ativar el desvío motorizado de entrada.

Para el esquema una estación y un circuito corto y largo, pinto sólo el dibujo con los mismos colores que en el gráfico de dos estaciones, para que se vea que básicamente es el mismo módulo


nxtorm

Glubs...  :D

Como insertar cita puede ser un poco liado, lo pongo en rojo y respondo a algunos temas. Vamos allá.

RC para dar órdenes a los trenes y cableado para comandar los desvíos.
Ok, coincidimos, aunque no necesariamente deben ser 4 para desvíos y 4 para trenes.

Si hay algún módulo que permita monitorizar "contactos" ya sean electrónicos, magnéticos o físicos con el NXT, se pueden "hacer palomitas" [...] y se pueden implementar todo tipo de sensores.
No sé bien a qué te refieres con módulos, pero con NXT es posible controlar un buen número de contactos y leds. Por ejemplo, se podrían conectar 8 Reed's (SDK) a un puerto y 8 LEDs a ese mismo puerto. Aunque esto ya es harina de otro costal. Ya sabes dónde tienes amplia info.

¿Como alimento el NXT con sensores externos?
Esta no la entiendo bien Puli...

Si el diorama tiene varios ladrillos controlando zonas, es tan fácil como enmascarar los emisores con unas pantallas para que no se desvíen las órdenes fuera de su rango, pero tampoco es problema si el número de trenes a controlar es discreto.
El rango del IRLink es corto (hacia los laterales) si lo pones en vertical sobre las vías, por lo que no sería necesario enmascarar.

Puede haber circuitos con 4 trenes en marcha pero con hasta Nx4 trenes aparcados [...] y tantas dársenas con su IR-Link independiente como grupos de 4 trenes hubiera en movimiento.
Esta es una idea interesante. Yo también la anoto por si pudiera acoplarla al estándar en el que ando enzarzado.

Con esto están resueltas las dos primeras incógnitas: saber donde hay un tren y dar órdenes a los trenes de forma individual.
Bueno, no dudo de que sea factible, pero a mí personalmente creo que me queda grande. Más abajo volveré sobre esto.

La tercera incógnita son los desvíos. Aquí veo un problemilla... me parecen pocas salidas por cada módulo NXT.
Con un IRLink ya sabes que se puede ampliar. Incluso dejando 4 para trenes, tendrías 4 desvíos PF y 3 desvíos NXT (o barreras o lo que fuera).

El esquema último que has colgado, NXTorm, me gusta cuando pretendes con un ladrillo controlar un circuitillo único, con una estación y unas cuantas vías.
En realidad, se pueden añadir los módulos que se quieran. Cada módulo implica 2 trenes más a sumar al diorama. Y en cuanto a las vías, se pueden hacer toooodo lo largas que se quieran y todo lo "complejas" (en trazado, no en cuanto a desvíos) que se quieran. Eso sí, respetando el esquema.

Resumiendo, una estación debería tener un sensor que diga cuando llega un tren (y que diga al módulo qué tren es el que llega), a continuación activará los desvíos para ubicarlo en una vía libre y adecuada al tren, un sensor de salida y sensores bajo las distintas vías para ordenarle detenerse.
He de reconocer que me cuesta seguir el hilo del esquema. En ese breve resumen que haces, coincide con lo que vengo proponiendo, aunque no tanto en su desarrollo y la implementación. Por ejemplo, tu segunda imagen al final es lo que yo he considerado prácticamente 1 módulo y coincide en el caso de un único NXT. Tampoco serían necesarios sensores bajo las vías.

Ahora mismo estoy intentando sacar el circuito estándar para un NXT e intentar un video si lo consigo para que lo veáis en funcionamiento. Intento sacrificar elementos y conseguir algo vistoso en un evento. No entendería una maqueta fija sin vías muertas, control total sobre trenes, etc pero en un evento es muy complicado (creo) cuadrar todos los programas de los distintos NXT. Entiendo que en lo que explicabas no existe comunicación entre los distintos NXT, con el consiguiente peligro de que se acumulen trenes en una estación y otra quede vacía ¿no?

La "madre del cordero" de lo que propongo (y así desvelo el punto clave) es el siguiente: los trenes circulan en el circuito cerrado. Cada 5 minutos, se para ese cercanías y sale el regional. Es decir, cada 5 minutos, cada estación "pasa" un tren a la siguiente. 

El truco para poder hacer esto y que no sean necesarios sensores en cada vía, etc es que todos esos trenes (la mitad concretamente del total) van codificados en el canal 1 motor A del mando PF
. Imagina 16 estaciones y 16 trenes con el receptor IR en el canal 1A. La estación emisora dará las órdenes de salida en ese canal y la estación receptora también. Bien sencillo, 16 trenes en danza en un diorama, todos codificados en 1A con un programa en NXT-G de "pocas líneas". Una vez han llegado, todos parados y se activan los cercanías durante 5 minutos más y sucesivamente.

Respecto a la detección, ya he comprobado que un único sensor de color estándar (del que viene en el set NXT) a la entrada de la estación detecta colores dispares como el Emerald (verde oscuro) y el mercancías (amarillo) sin problema y ejecuta el cambio de vía. Y el tema de semáforos etc, podría programarse de forma independiente al control de trenes (otro NXT en comunicación BT con cada estación o aprovechando los puertos libres) si se quiere ampliar, pero incluso esto podría sacrificarse en un evento.

No se cómo lo harán en otros eventos, pero creo que al final los intentos se caen por una cierta complejidad, ya he visto varios casos de propuestas. Mi intento es el de simplificar y poner en movimiento el máximo número de trenes, de forma que sea viable para "mucha" gente. Suelen ser magníficas ideas, desde luego más elaboradas que la mía, pero que requerirían mucho tiempo de coordinación que en un evento no existe. O mucho esfuerzo de comprensión. Al final lo que funciona son normas sencillas tipo GBC o microcity.

De todas formas Puli, intentaré releer la segunda mitad con más calma. Eso sí, me ha gustado mucho, ya que en realidad lo que busco (más bien propongo) es debatir un modelo común sobre el que nos podamos poner de acuerdo y sumemos esfuerzos para su mejora, ya que hasta ahora, vamos proponiendo modelos personales distintos para luego poder mejorarlo de forma conjunta. Y tu propuesta es un modelo sobre el que basarse para debatir y que creo que tenemos bastantes puntos en común y buenas ideas que se pueden aprovechar. A ver si sigue la cosa.

pulipuli

#18
Bueno, relee, que yo lo que pretendo es lo mismo, simplificar al máximo todo, por eso lo dividí en módulos mas pequeños... La idea parte de que una estación es un modulo independiente del resto y solo manda trenes si los tiene, y además puede ser tan grande como se quiera pero al ser independiente, el resto de módulos no necesitan saberlo.

El modulo de estación que he definido es el mas básico, y permite añadir al nxt que la controla el control de otro modulo, y así queda el circuito que has diseñado.

Me gustó mucho tu idea de que las estaciones y módulos no requieran conexión entre si, pues simplifica la programación. ESto convierte al conjunto de módulos en bloques autónomos con programaciones que pueden ser dispares, y ahí es donde aparece el problema que mencionas, que una estación puede llegar a acumular trenes y otra estar medio vacía... Esto obliga a que todo modulo deba tener unos parámetros de configuración fáciles de configurar sobre la marcha para que la cadencia de trenes sea homogénea.

Al ser bloques independientes, solo se comunican entre si enviando se trenes... Y con el sistema de cantones se previene que haya colisiones, pues un tren solo entra en un Cantón si esta libre. Habría que programar, se me ocurre, en cada estación para que si detecta trenes entrando se salte los timers internos y saque un tren para dejar espacio y que haya fluidez.

Sigo teniendo pendiente leer con calma tu web para ver cual es el sensor ese que permite leer sensores externos de contacto... Pero ahora me quedo sin tiempo, que mi mujer me dice que vaya para la cama de una vez :P mañana sigo e intento ser menos abstracto y pintar los bloques de funciones... Ea, mañana mas


nxtorm

ok, Puli, vamos bien pues con el espíritu Zen...

En su momento, cuando pensaba en todo esto, y leyendo otros modelos, pensé en el tema de los cantones. Pero le encontré un problema "mu gordo" para lo que andaba pensando, quizás por mi desconocimiento: ese sistema multiplicaría los IRLink a lo largo del circuito.

Ya me corriges, pero el sistema de cantones implica la capacidad de poder parar un tren en sus límites ¿es así?. Quiero decir, bien a la entrada o bien antes de abandonarlo. Eso, así a bote pronto, implicaría un IRLink por cantón, lo que lo hace casi inviable ¿no? 

Trasladando el concepto de cantones al estándar con el que estoy, sería así:

- Si hay 1 módulo (1 solo NXT y 1 IRLink) solo hay un cantón. Es decir, 1 solo tren en circulación, pero al menos siempre hay 1.
- Si hay 2 módulos (2 NXT y 2 IRLink) hay 2 cantones, el de ida y el de vuelta. Ya tenemos 2 trenes simultáneos. etc

De esta forma, toda la gestión (emisión-recepción) recae en cada estación. 

Cita de: pulipuli en 14 de Enero de 2012, 00:23:20 AM
Sigo teniendo pendiente leer con calma tu web para ver cual es el sensor ese que permite leer sensores externos de contacto...
Aquí tienes la forma de leer un pulsador (o un Reed Switch):

http://www.nxtorm.es/digitales/sd-g-un-switch.html

En la sección justo a continuación, viene como conectar 8 pulsadores. Se puede llegar hasta 128 si no recuerdo mal, doy también la forma de hacerlo pero más adelante. Lo malo es que NXT-G es un lenguaje poco versátil para programar todo esto. Quiero decir, no es precisamente C y la cosa se hace muy muy engorrosa, pero poder, se puede.


pulipuli

Bien!!!, veo que es sencillo y barato leer interruptores. Se le puede añadir a lo sumo un ci para que convierta la información de 255 pulsadores/sensores a los 8 bits del Pfc8574 y así ampliar el numero de sensores usando solo un puerto del nxt.

Vuelvo a la carga con lo de los módulos, aunque estoy con el tablet y no puedo ponerme a dibujar. Para entender el texto, se puede seguir el dibujo que puse mas arriba.

Modulo estación
//define el comportamiento de una estación no terminal, con trenes en un unico sentido, visto desde fuera y sin importar el numero de vías que tenga o su funcionamiento interno

Entradas
Tren detectado a la entrada: código tren
//indica que un tren se aproxima a la entrada, y nos dice el código del tren si se uso un sensor capaz de identificarlo. El código será 0 si no se detecta un tren y un valor superior a 0 si se identifica un tren. Si el sensor solo detecta un tren, vale cualquier valor (por defecto 1), si detecta tipos de tren por color o de otro modo, indica un código. Pendiente de definir

Tren en vía (numero de vía): verdadero/falso
//indica si un tren está en el punto de parada en una vía. Pongo el numero de vía como argumento para que el modulo sirva para estaciones de 1 a N vías

Tren saliendo de Cantón de salida
//la estación tiene que llevar internamente el estado de libre/ocupado del Cantón de salida. Cuando un tren atraviesa la salida del cantón, el modulo debe detectar el flanco de bajada (es decir, detecta cuando ya ha salido). Importante: dependiendo del tipo de sensor empleado, habrá que depurar esta entrada... P.ej. Si se usa un sensor magnético ubicado en la cabecera del tren se puede quedar la cola parada dentro del cantón

Salidas del modulo
Parar tren (código de tren)
//si la estación no está lista o no tiene capacidad para albergar un tren más, debe detenerlo. Si se sabe el código del tren que entra, parará solo ese tren, si no, parará todos por si las moscas.
//también se usará para detener un tren en un andén.

Arrancar tren entrante(tren, velocidad, tiempo)
//lo inverso al anterior, hace entrar el tren a la estación o salir de un andén. Debe saber qué tren es, lo cual me lleva a pensar que es necesario un detector de tren a la entrada... Luego explico al final como hacerlo con interruptores magnéticos sencillos y baratos e imanes adheridos bajo el tren
//se puede indicar la velocidad a la que mover el tren.
//se puede mantener la orden durante un tiempo o hacer que se de una orden permanente si el valor de tiempo es cero.

Activar desvío (código desvío, izquierda/derecha, tiempo)
//acciona un desvío concreto y lo deja en la posición deseada. el parámetro de tiempo indica durante cuanto tiempo se debe activar el desvío pues según su diseño unos tardarán más que otros o incluso puede que un tipo de desvío solo necesite un pulso para activarlo y él se encarga automáticamente de arrancar y parar. Si tiempo=0, la activación es infinita, hasta que llegue otra orden. Esto permite desvíos accionados por un interruptor que se detienen solos al final del recorrido del motor/servo

Variables internas
Estado desvio(desvio)
//Debe conocerse siempre el estado de todos los desvíos motorizados. Cada desvio podrá estar a la izquierda o derecha. Devuelve el estado de un desvio concreto

Tren en via(vía)
//devuelve el código del tren presente en una vía concreta

Posición del tren (tren); vía, Cantón
//devuelve dos variables, la vía en la que esta el tren y el Cantón. Así sabemos donde esta cada tren, entrando, saliendo, o en una vía


Tren en Cantón de salida
//cuando un tren haya atravesado el sensor del Cantón de salida, esta variable se pone como falso. Cuando se saque un tren de la estactón, esta variable se etiquetará como verdadero.

Funciones internas

Tren entrando en estación (código del tren)
//Se lanza cuando se activa la entrada de un tren entrando en la estación en el flanco de subida
Si los desvíos apuntan a una vía libre, no hace nada o simplemente baja la velocidad del tren entrante
Si no apuntan a una vía libre, detiene el tren, localiza la vía a la que enviarlo, cambia los desvíos, y envía al tren la orden de marcha a baja velocidad
Se puede complicar definiendo etiquetas para acciones por tipo de tren, como trenes en paso, que enviará por una vía en paso libre sin bajar la velocidad, trenes largos que enviara a una vía determinada, etc

Desviar tren entrante a vía (vía)
//acciona los desvíos para que apunten a la vía señalada. Esta función debe conocer la topología de los desvíos y vías de la estación

Cola de salida de trenes (tren)
//función a ejecutar cada vez que un tren deba abandonar la estación, tanto si estaba parado en un anden como si es un tren en paso.
Añade un tren a la cola de salida, no hace nada mas

Salida de trenes
//esta funcion es un bucle continuo que comprueba la cola de salida de la estación y saca los trenes por orden.
//si hay un tren en la cola de salida, arranca la maniobra de sacar tren, si no, espera a que haya un tren. Si el Cantón de salida está ocupado, da la instrucción de parar el tren (por si era un tren en paso)y espera a que esté libre. Cuando el Cantón de salida esté libre, da la instrucción de marcha. Cuando el sensor de la via en la que estaba elmtren está libre, limpia la variable de la vía en la que estaba el tren. Espera a que el Cantón de salida esté libre y solo entonces quita el tren de la cola y vuelve al principio para sacar el siguiente tren de la cola.
La función A cada paso que da actualiza la variable de posición del tren.

Ahora no puedo seguir, luego lo repaso, lo paso a limpio, e intento dibujar los bloques. La definición del modulo es un poco enrevesada porque esta pensada para estaciones grandes o pequeñas, pero se puede simplificar mucho. Lo bueno es que facilita mucho la vida al programar el modulo.

Me queda pendiente lo de aclarar como hacer un detector de códigos de trenes con imanes de forma bar ata y sencilla

Enviado desde el tablet, disculpad las faltas de ortografía


nxtorm

Pulipuli, sigo sin tener claro cómo enviarás las órdenes a los trenes. ¿1 IRLink en cada posición o cantón o semáforo en los que el tren deba parar o arrancar? Si es así, eso es un pastizal... Lo digo por tener claro el "hard" antes de entender a fondo la parte de programación.

Por mi parte sigo haciendo progresos. Confirmo que un sensor de color estándar antes del desvío delante de la estación es suficiente para detectar el paso del tren. Le he añadido una función de autocalibración según la luz ambiente, ya que ésta influye mucho y puede dar al traste con la detección. A una mala, se puede poner una pared de bricks blancos enfrente para convertirlo en una fotocélula por reflexión más segura, pero no es necesario.

Con paciencia creo que lo acabaré sacando adelante, aunque no se si me dará tiempo a ajustarlo todo y sacar el video para mañana. Ya veremos.

pulipuli

La idea es un único irlink por modulo, y si resolvemos la limitación de motores, un modulo puede controlar todo un dio rama. El modulo de estación controla solo una estación, y si en el nxt cabe algo mas es donde podría haber problemas de cobertura si el circuito es grande. El cantón de salida, aunque sea larguísimo no necesita dar ordenes mas que a su entrada, lo que si que hay que llevar es un cable a la salida para poner el detector de tren saliendo.

En el peor caso, se pueden usar repetidores ir que no son tan caros como un irlink.

El detector de tren por imanes necesita cuatro sensores magnéticos que se ponen en la vía separados entre si 8mm, es decir, un stud. El código de cada tren se monta en una plate de 4 studs, poniendo o quitando en cada stud un imán pequeño de 4mm... Un lote de 50imanes salía por unos 10euros creo recordar. Lo importante es probar en imanes distintos para que no de error de lectura el que un imán muy potente active no el sensor que tiene debajo sino al de al lado también, es cuestión de hacer unas pruebas.

El plate con el código se adhiere a los bajos del tren, por lo que queda centrado con el sensor del suelo. Al pasar por encima se activaran solo alguno de los cuatro imanes,por lo que detectaría hasta 15 trenes diferentes. Como digo el único problema es que se usen imanes tan potentes que activen también el sensor de al lado o tan poco potentes que haya que ponerlos rozando el suelo, pero es cuestión de hacer unas pruebas.

El hard de un modulo de estacion es el ladrillo nxt, tantos sensores como vías, uno para el Cantón de salida y uno de 4 contactos (o sensor de color) para la entrada. Un irlink y tantos motores como desvíos. Si se consigue activar motores usando una salida y algo de hardware soldado (barato y sencillo, si no, lo descarto), un único ladrillo puede controlar un circuito grande y complejo... El limite son las entradas y salidas que se logren meter al ladrillo y su capacidad de proceso. El código, si se hace modular, puede ser un montón de bloques repetidos a base de copy paste, programas una vez y te olvidas.


Blastem

Como proyecto vivo y en el que en cierta manera me siento identificado, porque uno de mis objetivos es automatizar un GBC con tren, he de decir que este tema me tiene enamorado.
En cuanto acabe exámenes quiero proponer alguna cosa al respecto, pero tengo que probar antes.

Nominado a MDM del mes  :}
Blog - Colección - Wanted List --- Look down, look down, Don't look 'em in the eye, Look down, look down, You're here until you die

nxtorm

Lo primero de todo, agradecer la nominación de Blastem. Y lo segundo... me arremango y al tema.

Una cuestión previa para aclararnos: usaré como "módulo" tu segunda imagen o mi "módulo estándar", que en el caso de un único NXT es totalmente coincidente (ya tenemos algo).

Bueno, pues la verdad es que voy aclarando poco a poco lo que propones, pero me da la sensación de que me pierdo en cosas fundamentales, no consigo hacerme una idea de conjunto, torpe que es uno. Digo esto por lo siguiente: propones el tema de codificar los trenes, pero el módulo solo dispone de 2 andenes. Ya aclarabas al final de otro mensaje que "1 IRLink y tantos motores como desvíos", entiendo que para los andenes. Ahora mismo estoy con pruebas reales en mi comedor, no quieras ver cómo está esto. Cuento con 2 andenes y un sensor de color.

Añadiendo un tercer andén, tendría que elevar el IRLink para que cubriera las 3 vías y entonces el cable del sensor de color ya no llegaría. Si pusiéramos en el módulo estándar 4 andenes,  el IRLink tendría que estar a unos 45cm de altura sobre las vías para cubrir los 36 cm de separación de esas 4 vías!! (ver review del sensor). Tampoco conozco el "repetidor" del que hablas, solo conozco el IRLInk.

En fin, que sobre el papel lo veo factible, pero al trasladarlo a la realidad, se me complica la imagen de lo que voy entendiendo que propones. Te pediría Puli que hiciéramos al revés, que me dieras tu opinión (bueno, la de cualquiera que quiera opinar) sobre el estándar que propongo, dudas, reservas, desacuerdos, etc. Me servirá a mi también para aclararme con lo que dices y que intentáramos mejorarlo con tus propuestas (y las nuevas opiniones también) si es que es un buen estándar.

Haré un poco de campaña al respecto:
El GBC y el microCity funcionan con un módulo muy sencillo, simple más bien. La complejidad allí se consigue por adición de módulos, no por dotar de mucha funcionalidad al módulo básico. Esa es la idea, "copiar" la filosofía que ha funcionado en otros ejemplos.

Trenes es un poco diferente, pero siguiendo esta idea, el estándar permite ampliar todos los usuarios que quieran entrar, aunque quisiera participar el foro entero. Esto es posible porque todos los trenes que circulan entre estación y estación se mueven en el canal 1A. Y permite meter el trazado entre toda la city presente en el diorama, ya que el trazado puede ser libre.

He puesto 2 andenes por simplicidad, es lo mínimo para un cambio de tren en cada estación. Con ello se necesitan 2 receptores IR (4 canales de PF estándar): 2 canales para 2 trenes y 2 canales para 2 desvíos. Incorporar más desvíos al módulo básico implica meter más receptores IR, más altura del IRLink, más longitud de cables del NXT, más desvíos... Cuantos más elementos, más programación, más encarece y más se complica que un usuario lo pueda reproducir para hacer pruebas en casa y llevarlo ya configurado.

Cada nueva estación, incorpora 2 nuevos trenes funcionando, sin límite de estaciones. Otra ventaja es que el programa también es único y estándar. Meter variaciones en el NXT-g según la configuración de cada estación si éstas fueran distintas sería un cacao a la hora de cuadrarlo en un evento.

Y para más gracia, no es necesario codificar trenes, evitando cables adicionales y meter la programación en NXT-G, que sería compleja por lo engorroso de programar ahí cosas extensas. Solo la programación del ejemplo que estoy haciendo ya ocupa un trozo.

Aunque lo parezca, perfecto no lo veo (y más ahora que lo estoy programando), también le veo puntos débiles, pero de momento no digo nada porque quizás los pueda solucionar (van por el tema de programación).
Lo dejo aquí para no extenderme más, ya me das tu opinión al respecto.

Y de las últimas cuestiones que comentabas, sí te puedo aportar alguna prueba con imanes si te sirve la información, ya me dices. Tengo algunos imanes por casa y sensores Reed (SDK). Lo veo complicado de instalar como dices porque me dió la sensación de que necesitan un imán relativamente gordo y cercano para activarse (tipo enganche de tren), pero si quieres puedo probar cosas cuando pueda (ahora no) y te digo. Un saludo

pulipuli

Bueno, cuento por encima para profanos en que consistiría un modulo de entradas y otro de salidas? La página de nxtorm tiene unos capitulillos muy bien explicados que todos deberíamos entender pues es un montaje MUY asequible tanto en precio como en facilidad de montaje

Modulo de entradas.
Hay un chip que sabe transmitir la información digital presente en ocho puntos al bus del nxt. El chip lo hace todo, nosotros solo debemos poner en cada pin una tensión de 5v p.ej cerrando un interruptor, y el chip envía instantáneamente la información al nxt.

El chip lo podemos alimentar con un interruptor simple y una resistencia, o de mil maneras. Como ejemplo,modelos usar interruptores magnéticos que se cierran al aproximarles un imán, una fotocélula que detecta cuando hay o no luz, un micro que detecta cuando hay sonido, un foto detector que detecta cuando hay un objeto que pasa junto a él, etc. Si no sabemos de electrónica no hay que preocuparse en como funciona cada submodulo, serán media docena de componentes que valen unos céntimos cada uno y se montan así o asá

Módulo de salidas
El mismo chip del módulo de entradas puede transmitir la información del nxt a 8 pines. Podemos pedir que se activen o desactiven originando con ello acciones. La aciión más sencilla es activar un LED, pero usando un pequeño circuito de media docena de componentes, podemos hacer que active un motor. Si el circuitín lo es algo más complejo, podemos incluso conseguir que el motor se encienda para más o menos potencia y en un sentido u otro.

Si ponemos a cualquiera de los módulos un chip más, con los 8 bits que da un módulo básico podemos leer la información de hasta 256 puntos. Si quisiéramos p.ej. Implementar un sensor de cantidad de luz, podríamos usar hasta 256 niveles de intensidad, pero como en este proyecto queremos recibir solo información de encendido/apagado, podemos recibir información de hasta 256 puntos usando solo un puerto de sensor del nxt.

Por las mismas, un modulo de salida podría usarse para encender una bombilla con 256niveles de intensidad, o bien controlar el encendidomo apagado de hasta 256 dispositivos usando un único puerto del nxt.

Traducido esto a lenguaje vulgar, si me gasto unos pocos eurillos (muchos menos de lo que cuesta un sensor barato del nxt) y tengo una plaquita de circuito impreso, un soldador, estaño, y un alicate, puedo hacer una cajita de la que salgan hasta 256 cables con los que leer hasta 256 interruptores o sensores de información binaria (On/off, luz/oscuridad, sonido/silencio, detecto algo/no detecto nada), y otra cajita con la que encender o apagar hasta 256 dispositivos varios.

La caja de entrada es la mas simple, al menos si lo que quiero detectar es apertura o cierre de interruptores/contactos, la de salida requiere que si quiero controlar un motor ponga antes un pequeño circuitín para que pueda darle toda la corriente de alimentación, ya que el chip de control da sólo una tensión baja y con poca corriente... Ese circuitín es muy sencillo, un transistor y tres o cuatro resistencias, que son componente muy baratos (céntimos) que podemos poner junto al motor camuflados p.ej. Dentro de un brick 2x4

Con tantos puertos para un nxt se pueden hacer palomitas, ya que al igual que los sensores comerciales de nxt leen solo una magnitud pero con muchas posibles graduaciones, con estos caseros no vamos a poder detectar muchas graduaciones por puerto, sino muchos sensores sencillos

Por ahora, para las pruebas, se stá trabajando en un esquema sencillo, en el que solo se usan los 8 bits del circuito integrado que se comunica con el nxt, pero aun así permite leer la información de 8 interruptores o activar hasta 8 motores con un solo puerto, lo cual es mucho mas de lo que da un ladrillo nxt con sensores comerciales.

La programación nxt-g es sencilla, si usáramos las 256potenciales entradas solo habría que preguntar al sensor "haz esto cuando el sensor tenga un uno valor 37" pues eso implicaría que se ha activado el interruptor/contacto/puerto 37. Si trabajamos solo con 8 puertos la programación es un pelín más liosa, pues hay que interpretar los puertos en binario... Así, el primer pin de todos bastará con preguntar al sensor si se ha activado un numero par, el segundo si es múltiplo de 4, etc... Con una tabla como la que pone nxtorm en su web se hace rápido, pero esa pequeña dificultad añadida es el precio a pagar por tener un esquema eléctrico mas sencillo te, con solo un chip.

Moraleja:

el que quiera meterse en la parte de electrónica del proyecto podrá ponerse a jugar con pastilla tras, cables y placas de prueba, y el resultado de su trabajo serán unos esquemas eléctricos, un listado de componentes, un dibujo de placa de circuito impreso sobre la que soldar, y las instrucciones para hacerlo.  Con que esto lo haga una persona es suficiente, pero para ser productivos, como en todo, está bien que alguien más opine o contraste opiniones para que el desarrollo sea mas fluido y estar mas motivados

Lo mismo con la programación, habrá quien esté acostumbrado a programar en nxt-g y no le cueste hacer programo tras varios... Otros como yo que no están acostumbrados al entorno de programación pero que se les da bien el ver los módulos de programa como bloques relacionados entre sí, y otros que solo quieran hacer copy paste para probar sus circuitos

Por ultimo, habrá quien quiera solo pasar a ver que se cuece, y biene muy bien que esas personas den sunopinión abstrayéndose de las tripas y centrándose en el funcionamiento. Solo hay que tener ganas de leer mucho, y proponer ideas, que alguien habrá quien las aplique a sus campos de conocimiento y entre todos avanzaremos a tope

Ah, y no sempuedemolvidarbalmconstructor de lego sin mas que puede probar soluciones para construir o decorar desvíos, camuflar sensoresny cables... Todas las contribuciones pesan por igual porque el resultado final requiere tocar todos los palos, y es muy valiosa la aportación incluso del que solo pasa a ver que se cuece e idea una forma de escamotear un sensor entre dos bricks, que si no lo hace el, otro tendrá que hacerlo

En otro orden de cosas, alguien conoce algún libro o web de modelásemos ferroviario de la que pueda aprender como plantear el funcionamiento de un dio rama? Igual que me costó un buen rato hacerme a los rudimentos del funcionamiento de los cantones, seguro que hay algún sitio donde pueda leer algo que me facilite la visión de conjunto de un gran diorama para así poderlo aplicar a nuestros módulos

Quiero pasar a limpio el bloque de estación, y aprovechare para pensar como funcionaría una estación bidireccional, pero eso mejor para mas adelante que por ahora con el esquema simple es mas que suficiente

Igual que dije en el otro hilo, si alguien se pierde o no entiende algo que pregunte. Es preferible ir mas despacio si podemos ser más personas aportando ideas, porque no hay prisa y cualquier idea por peregrina que parezca es valiosa. Animaos a escribir algo los que solo sois lectores del hilo, que seguro que podéis aunque solo sea preguntar dudas... Por ahí se empieza jejeje

PD: enviado desde el móvil, disculpad las faltas de ortografía y los palabros raros


pulipuli

Sorrostrada por el flooding, hemos cruzado mensajes.

Nxtorm, yo tiendo a pensar en abstracto el modulo de una estación lo mas genérico posible, para que abarque de lo mas sencillo a lo mas complejo. Luego, una vez hecho el diseño abstracto, es muy fácil recortar e implementar casos específicos. Un ejemplo es como traducir mi "ladrillo" a las pruebas que estás haciendo: no hay sensor de trenes, sino un detector de color, solo dos vías... El módulo se simplifica mucho. A la hora de programarlo, se obviaran variables y entradas, pero el funcionamiento básico es el mismo: un bloque de programa que espere a tener un tren a la entrada para ver que hace con él, un bloque que gestione la salida de trenes, y en tu caso otro que gestione los circuitos corto y largo. Los cantones de entrada y salida de cada modulo requerirán sensores, y en tu implementación irán a este o aquel canal... Son detalles de implementación.

No queramos que las pruebas sean el estándar, sino solo pruebas para ver que quitar o poner para hacer un estándar. Vale que se aproximan mucho a la realidad, pero creo que si se piensa en abstracto, luego solo hay que aterrizar el concepto, pero si empezamos desde el suelo habrá que subir y baja varias veces cada vez que se añada o quite algo. El resultado final será como dices algo muy sencillo, unos diagramas de vías, una forma de numerar sensores y motores y una forma de poner el irlink para que cubra el espacio a controlar, además de un bloque de programa con unas variables que permitan ajustar el funcionamiento cuando juntas un modulo con otros.

Sobre el extensos de Ir, hay cachar ritos que reciben los ir en una banda y los transmiten normalmente mediante un cable para emitirlos de nuevo en otro punto. No son muy caros y se podría probar si pueden usarse para que un solo irlink controle una zona mas grande.

Me encantan las pruebas que estas haciendo, tienen mu buena pinta y seguro que funcionan a nada que le dediques un rato, son el germen de algo grande. De todas las cosas que me pasaron por la cabeza a la hora de pensar en el modulo abstracto, solo creo que deberías tener en cuenta los dos bloques básicos del programa, uno que permite a los trenes entrar y otro que les da salida. En el de salida, implementaría una cola para que el modulo dos partes del programa no intenten sacar a la vez los trenes, sino que todas las partes del programa los encolen y haya un bucle mirando esa cola y saquen al tren que toca cuando puedan. Si todo va como esperamos todos con ansia,yo,lo complicaría un poco para luego simplificarlo todo recortando lo superfluo, y así podrás dejar mas cosas probadas. Yo voy a intentar dedicar un rato a los moldes de conectores de motores, y otro a probar a hacer unos módulos de entradamy salida como los de tu web para verlo físicamente, además de aprender a programar nxt-g de una vez, que me da rabia verlo todo desde tan arriba y no poder aterrizar las ideas por falta de conocimiento especializado


nxtorm

ok Puli, gracias. Cualquier duda al respecto de NXT-G, a tu disposición.

Lo malo de los "repetidores" de IR es que la info de Power Functions va codificada, así que será complicado. Parece que tenemos aproximaciones distintas, tu vas "podando". Es perfecto. Seguro que aporta cosas, ya que yo parto de una idea distinta y es dejarlo en mínimos para ampliar con más módulos.

Respecto a dedicarle un rato... estoy a piñón... tengo grandes avances y seguro que sale y subo el video, pero ahora mismo, lo que más más me está dando por... quiero decir, lo que más problemas me está dando es el desvío que posteé en el otro hilo. Pero ya caerá, ya... Es menos "robusto" de lo que pensé en un principio cuando lo gestiono con el NXT. Eso sí, los trenes aceptan las órdenes perfectamente, salen cuando toca, no salen a la vez, paran bien, etc. Lo dicho, a ver si me hago con ello y puedo presentar algo en breve.

Comentarios de las pruebas: dada la inercia del tren cuando para, no se queda debajo justo del sensor, pero en el siguiente ciclo se activa bien y sin problemas. Para que lo tengas en cuenta. La realidad es lo que tiene. Y lo segundo, la función de autocalibración del sensor de color no solo va perfecta sino que además es necesaria, ya que la luz ambiente varía mucho a lo largo del día. Si alguien quiere detalles al respecto, que hable.

pulipuli

miraré con calma los repetidores buscando algunos por internet y viendo experiencias, y luego compraré alguno y haré pruebas con los mandos de trenes PF a ver como va la cosa. Creo que tengo alguno básico de algún extensor de TV que andará sepultado en el taller... es un sitio por donde empezar.

Todo se anda a pasitos, sin prisas, jeje, ¿alguien tiene prisa? cuando se avanza, se avanzó, cuando no... pues damos palique y hablamos de otras cosas que no todo es cebarse con los puntos críticos ;) Sobre las inercias, un punto a tener en cuenta es frenar al tren cuando entra en la estación, así se quedará parado más cerca del sensor y no saldrá arrastrando. Lo importante es que se quede parado, el programa ya sabe que está en la vía por lo que da igual un poquito más alante o atrás, mientras no se meta de cabeza al cruce estorbando. Es un problema más estético que funcional.

Lo de la autocalibración, ¿como la haces? supongo que la hará el programa al arrancar, viendo lo que mide el valor e la pared blanca de enfrente, pero no se como programas el que detecte un color u otro a partir de ese valor... la verdad es que estoy algo pez en el tema, por lo que cualquier refresco es bienvenido.


nxtorm

ok, perfecto Puli.

Respecto de las inercias, lo he resuelto orientando de nuevo el sensor, más centrado con las vías. Para parar el tren a la entrada de la estación se necesitaría un IRLink adicional. Pararía al tren justo debajo del segundo segundo sensor. Es la ventaja de poder experimentar en casa, luego te (os) puedo contar los avances.

Para la autocalibración, uso lo siguiente (más o menos, aquí está adaptado): (pincha en la imagen para agrandar)



Usa el sensor de color en modo "sensor de luz". Ninguna luz del sensor está encendida. La lectura sin tren delante oscila entre 42-43 ahora mismo, pero esto cambia. Con tren, según el color, 15.

El programa inicia leyendo la luz ambiental, que se almacena en una variable. Esto se repite en cada ciclo, cada 5 minutos aprox. Luego compara ese valor con el valor actual y si es menor, es que delante tiene un tren. En ese momento, el programa deja el bucle y avanza. Lo del  "-3" es por seguridad, para posibles fluctuaciones de luz. Espero que se entienda.

Bueno, y hace un rato he conseguido que funcione todo!!! oeoeoeoe!!.   :) Voy a editar, subir, etc y de aquí a un rato lanzo el video... con las explicaciones oportunas, que no os váis a librar. Ale, luego más.