Luison, de todas formas sigues teniendo el problema de sincronización, no he hecho cálculos pero teniendo en cuenta que la velocidad del sonido en el aire (a una temperatura de 15 °C) es de 340 m/s (1.224 km/h) habría que calcular que resolución espacial tenemos (diferencia de caminos) y si al micro le dará tiempo a leer esa resolución.

S2

Ranganok Schahzaman

Sí, puede que a la hora de la verdad igual no sea 100% exacto, aunque si se conoce ese "retardo" se podría compensar sumando o restando "lo que sea" a la lectura. Y sino, que use los chulis eso de 36 euros, que es un proyecto para una empresa no?

Hola:

Dos días sin leer, y la que se ha montado.

NO es un proyecto para ninguna empresa. Lo que pasa, es que los receptores (que también son emisores) son industriales, y por tanto no quiero/puedo poner información sobre los mismos 'on line'.

El sistema debería ser para uso y disfrute de cualquiera que sea aficionado a la robótica. Por eso lo cuelgo aquí. Como creo que a muchos les gustaría tenerlo, las plaquitas de RS-485 las he preparado para colgar del proyecto entrenadora, estoy preparando las comunicaciones ModBus (para AVR's en GCC, para PC en C# Express) para colgarlas también, y busco ayuda para que todos podamos colaborar y usar este proyecto.

Lo que comenta Ranganok respecto de los pines me parece correcto, aunque yo hubiese apostado por coger una de las entrenadoras. Cualquiera me vale.

Lo de emitir no es necesario, pero si uno puede emitir y recibir con la misma placa, puede hacer que el sistema se autodetecte y posicione.

Recordad que el emisor en teoría es móvil, es decir, va sobre nuesto querido robot.

La sincronización no es muy crítica. A 34 cm por ms, con unos pocos us de precisión hay de sobra (unas decenas, como máximo pediría 100).

Mi experiencia me dice que con sólo un emisor (de los de dos o tres euros) enchufado a dos pines en contrafase de un temporizador, podemos cubrir una buena distancia. Con un sólo pin reducimos el alcance, pero tampoco es problema, ya que se puede usar un inversor externo. Además, un MAX232 puede elevar la tensión de alimentación, de manera que tenemos más chicha disponible para tales fines. Aún así, esto no es crítico. Lo más 'complejo' es la parte del receptor.

Por mi parte, para un sistema algo más complejo como el equipo industrial que tengo, el programa completo tal y como lo tengo, incluido el ModBus y bastantes más funciones, me ocupa menos de cuatro KB de programa (ATmega64). Y lo más complejo son las librerías de ModBus, que tal y como comento, haré públicas. Así que para programadores expertos como vosotros, debe estar chupao el hacer las pocas rutinas importantes de control de los temporizadores (uno para el modbus, otro para la recepción, y un tercero, opcional, para la emisión, que incluso puede ser el mismo que para el modbus).

¿Además, donde está la diversión si uno lo compra hecho?

Bueno, voy a ver si acabo el control de ModBus de C#, que es con lo que estoy ahora. La parte de AVR parece bastante adelantada, y sólo me queda depurar posibles problemas y pulirla un poquito.

Seguiré informando.

Por cierto, el RS-485 es un serie igual que el RS-232, pero permite la comunicación con más de un periférico. El 'problema' está en el protocolo, ya que debe gestionar semidúplex y direccionamiento. Por eso el ModBus, que es abierto, gratuito y muy usado me viene que ni al pelo. Sin contar con que ya tengo experiencia en el mismo.

Saludos.

Lo que comenta Ranganok respecto de los pines me parece correcto, aunque yo hubiese apostado por coger una de las entrenadoras. Cualquiera me vale.
Para desarrollar el firmware y el software si que podemos usar la entrenadora (me parece muy buena idea).
La sincronización no es muy crítica. A 34 cm por ms, con unos pocos us de precisión hay de sobra (unas decenas, como máximo pediría 100).
Tengo que mirarme los apuntes porque no estoy muy seguro, pero pensaba que era más crítico.

S2

Ranganok schahzaman

Hola:

Si la velocidad del sonido, aproximadamente es e 340m/s, en 100 us recorre una distancia de 3.4 cm. A mi me vale con esa precisión, aunque sinceramente, espero que sea mejor, alrededor de 0.5 cm.

Esta precisión es del temporizador y del sistema de sincronización, y nada tiene que ver con las comunicaciones. Propongo una señal digital diferencial, que se pueda transmitir por cable, por ejemplo, aunque estoy abierto a otras opciones. Incluso tengo pensado la posibilidad de usar un sistema inalámbrico a medias, pero hay que meditarlo.

Este es un tema abierto totalmente. Mi sugerencia del cable diferencial viene a cuento precisamente del ModBus/RS-485: es un sistema diferencial de comunicaciones muy robusto que permite largas distancias, cosa que con un I2C no prodríamos hacer. Por eso es el método de comunicaciones propuesto.

Por otro lado, basar la sincronización en esta señal sería complejo y problemático, así que conviene una señal aparte. Se podría hacer con transceivers 485 aparte y usando otro cable diferencial, por ejemplo, con un coste reducido (alrededor de uno o dos euros el SP485 que compré el otro día).

Para el receptor de ultrasonidos, tengo muy claro que el necesario es uno de los pequeños que se pueden encontrar en Farnell o RS, igual luego miro referencias. Por suerte, la sensibilidad necesaria no es muy elevada.

Para el emisor, tanto podemos usar la pareja del receptor elegido, por ejemplo para el nodo de detección, o bien se puede aprovechar un sistema de medición de distancias instalado en el robot, como pueden ser los que pusísteis en los links anteriores. De esta manera, el robot puede detectar distancias o lo que sea que haga con dicho sensor.

Por otro lado, había pensado en usar un Wirless USB de Cypress, que es SPI, de bajo consumo, cuesta unos 10€ en Farnell, y es fácil de usar. Con dicho aparato se pueden enviar datos al robot (y/o recibirlos), y la señal de interrupción que proporciona puede servir de señal de sincronización.

Recuerdo que lo importante, es que los nodos estén sincronizados entre sí, y que el emisor no tiene porqué estarlo (aunque mejor si lo está).

Saludos.