Proyecto AndroidePortada | Acerca de | Ayuda | FAQ | Páginas especiales | Registrarse/Entrar

Categorías: Estructura | Comunicación
Versión para imprimir | Aviso legal | Política de protección de datos | Revisión actual

Estructura de comunicaciones

(Diferencia entre revisiones)

Revisión de 04:25 12 mar 2008
Marianobustos (Discusión | contribuciones)

← Ir a diferencia anterior		 Revisión actual
Edu (Discusión | contribuciones)

Línea 3: Línea 3:
Aunque todavía está por definir, por el momento yo pienso en un transmisor y un receptor en comunicación constante, pero intercalada. Desde el robot se transmite un paquete de datos con información de estado de sensores y luego se pasa a espera de recepción. El otro lado (una PC de comando) recibe este paquete e inmediatamente transmite órdenes, si es necesario, o un OK, y pasa a su vez a espera. La situación se mantiene indefinidamente, y sólo se modifica cuando por un comando desde la computadora, o por una solicitud del programa del robot, se establece —momentáneamente— la transmisión de un bloque de datos más amplio, por ejemplo, una descarga de rutinas. O un informe más detallado de estado del robot (posiciones, temperaturas, registros de movimientos realizados, etc). Aunque todavía está por definir, por el momento yo pienso en un transmisor y un receptor en comunicación constante, pero intercalada. Desde el robot se transmite un paquete de datos con información de estado de sensores y luego se pasa a espera de recepción. El otro lado (una PC de comando) recibe este paquete e inmediatamente transmite órdenes, si es necesario, o un OK, y pasa a su vez a espera. La situación se mantiene indefinidamente, y sólo se modifica cuando por un comando desde la computadora, o por una solicitud del programa del robot, se establece —momentáneamente— la transmisión de un bloque de datos más amplio, por ejemplo, una descarga de rutinas. O un informe más detallado de estado del robot (posiciones, temperaturas, registros de movimientos realizados, etc).
-Este sistema lo implementé en un robot (uno de tres ruedas) que funciona en contacto con una PC u otra computadora. La [[RF]] está implementada con módulos [http://robots-argentina.com.ar/Comunicacion_RF.htm TWS y TRS de Wenshing], aunque seguramente en el robot hay que buscar alternativas más profesionales. El diseño lleva un [[PIC16F628A]] en el lado de transmisión y uno igual en el lado de recepción. Esto porque había cosas que me resultaba difícil compartir, por lo cual me pareció que el costo de un PIC más no era importante ante la simplificación en el uso y en la programación (agregado el 10 de marzo por Edu).+Este sistema lo implementé en un robot (uno de tres ruedas) que funciona en contacto con una PC u otra computadora. La [[RF]] está implementada con módulos [http://robots-argentina.com.ar/Comunicacion_RF.htm TWS y TRS de Wenshing], aunque seguramente en el robot hay que buscar alternativas más profesionales. El diseño lleva un [[PIC16F628A]] en el lado de transmisión y uno igual en el lado de recepción. Esto porque había cosas que me resultaba difícil compartir, por lo cual me pareció que el costo de un [[PIC]] más no era importante ante la simplificación en el uso y en la programación (agregado el 10 de marzo por Edu).
--[[Usuario:Edu|Edu]] 21:34 9 mar 2008 (ARST) --[[Usuario:Edu|Edu]] 21:34 9 mar 2008 (ARST)
Línea 98: Línea 98:
'''Figura 2'''.<br><br> '''Figura 2'''.<br><br>
-Con lo cual cada módulo puede acceder a la base de datos para ir grabando sus mediciones y la CPU tendría una tarea cada X tiempo para enviar los datos que sean necesarios al exterior.+Con lo cual cada módulo puede acceder a la base de datos para ir grabando sus mediciones y la [[CPU]] tendría una tarea cada X tiempo para enviar los datos que sean necesarios al exterior.
En dicha [http://es.wikipedia.org/wiki/Memoria_%28inform%C3%A1tica%29 memoria] podríamos guardar los datos que menciona Juan. En dicha [http://es.wikipedia.org/wiki/Memoria_%28inform%C3%A1tica%29 memoria] podríamos guardar los datos que menciona Juan.
Línea 141: Línea 141:
Me parece que, al menos inicialmente, para el bus de comunicación intermódulos deberíamos adoptar [http://www.i2c-bus.org/ I2C], por su facilidad de implementación y compatibilidad con cualquier microcontrolador que se elija luego para cada parte. El módulo principal que mencionábamos antes haría de Master y cada módulo de operación (pie, rodilla, cadera, etc) sería un Slave. Me parece que, al menos inicialmente, para el bus de comunicación intermódulos deberíamos adoptar [http://www.i2c-bus.org/ I2C], por su facilidad de implementación y compatibilidad con cualquier microcontrolador que se elija luego para cada parte. El módulo principal que mencionábamos antes haría de Master y cada módulo de operación (pie, rodilla, cadera, etc) sería un Slave.
-Hacia afuera propongo que el mencionado módulo principal de comunicaciones (MPC) se base en algún [http://es.wikipedia.org/wiki/Microcontrolador_PIC PIC] con soporte para [http://es.wikipedia.org/wiki/USB USB], además de [http://es.wikipedia.org/wiki/Puerto_serie puerto serie]. De este modo podríamos conectar una PC mediante un cable USB cuando necesitamos transferir muchos datos, modificar el programa, etc. y dejar el puerto serial para conectar a cualquier medio inalámbrico, seguramente algun módulo RF (esperemos más confiable que los Wenshing), [[Zigbee]], Bluetooth o lo que fuere.+Hacia afuera propongo que el mencionado módulo principal de comunicaciones (MPC) se base en algún [[PIC]] con soporte para [http://es.wikipedia.org/wiki/USB USB], además de [http://es.wikipedia.org/wiki/Puerto_serie puerto serie]. De este modo podríamos conectar una PC mediante un cable USB cuando necesitamos transferir muchos datos, modificar el programa, etc. y dejar el puerto serial para conectar a cualquier medio inalámbrico, seguramente algun módulo RF (esperemos más confiable que los Wenshing), [[Zigbee]], Bluetooth o lo que fuere.
El mismo MPC debería también gestionar el teclado y display que mencionaba [[Usuario:Mastromec|Mastromec]] ya que también son una forma de comunicación. El mismo MPC debería también gestionar el teclado y display que mencionaba [[Usuario:Mastromec|Mastromec]] ya que también son una forma de comunicación.
Línea 150: Línea 150:
---- ----
-Para mí también el [http://robots-argentina.com.ar/Comunicacion_busI2C.htm I2C] está bien y es suficiente, y si se diera el caso de dos módulos que deban transferir en algún momento bloques grandes de información y muy velozmente, se puede implementar otro bus, por ejemplo el que se puede implementar usando el port paralelo esclavo de los [http://es.wikipedia.org/wiki/Microcontrolador_PIC PICs] 16F87x.+Para mí también el [http://robots-argentina.com.ar/Comunicacion_busI2C.htm I2C] está bien y es suficiente, y si se diera el caso de dos módulos que deban transferir en algún momento bloques grandes de información y muy velozmente, se puede implementar otro bus, por ejemplo el que se puede implementar usando el port paralelo esclavo de los [[PIC|PICs]] 16F87x.
Si tuviésemos sucesos tan tremendamente urgentes que se podrían "perder" o atender tarde por culpa del tráfico en [http://robots-argentina.com.ar/Comunicacion_busI2C.htm I2C], simplemente habrá que cablearlos como [http://es.wikipedia.org/wiki/Interrupci%C3%B3n interrupciones]. Si tuviésemos sucesos tan tremendamente urgentes que se podrían "perder" o atender tarde por culpa del tráfico en [http://robots-argentina.com.ar/Comunicacion_busI2C.htm I2C], simplemente habrá que cablearlos como [http://es.wikipedia.org/wiki/Interrupci%C3%B3n interrupciones].
Línea 161: Línea 161:
No me convence mucho la otra idea de dejar tantas conexiones hacia el exterior, osea, si es en un principio como debug me parece perfecto, pero tendría que ser autónomo y solo dejar al exterior las conexiones para poder programar a los distintos módulos. Ver [http://en.wikipedia.org/wiki/In-System_Programming ISP] No me convence mucho la otra idea de dejar tantas conexiones hacia el exterior, osea, si es en un principio como debug me parece perfecto, pero tendría que ser autónomo y solo dejar al exterior las conexiones para poder programar a los distintos módulos. Ver [http://en.wikipedia.org/wiki/In-System_Programming ISP]
-Propongo otras alternativas al [http://es.wikipedia.org/wiki/Microcontrolador_PIC PIC], como el [http://es.wikipedia.org/wiki/Arm ARM], quizás éstos últimos están mas orientados a portar un sistema operativo (Ver [http://es.wikipedia.org/wiki/RTOS RTOS]) lo cual seria una buena base para el MPC.+Propongo otras alternativas al [[PIC]], como el [http://es.wikipedia.org/wiki/Arm ARM], quizás éstos últimos están mas orientados a portar un sistema operativo (Ver [http://es.wikipedia.org/wiki/RTOS RTOS]) lo cual seria una buena base para el MPC.
También se me ocurre que una solución para transferir muchos datos a la pc (como dice Miguel) es usar una tarjeta [http://es.wikipedia.org/wiki/Secure_Digital SD] las cuales son muy seguras y hoy en día hasta los teclados vienen con lectores para estas tarjetas. También se me ocurre que una solución para transferir muchos datos a la pc (como dice Miguel) es usar una tarjeta [http://es.wikipedia.org/wiki/Secure_Digital SD] las cuales son muy seguras y hoy en día hasta los teclados vienen con lectores para estas tarjetas.
 +En cuanto a los módulos [[Zigbee]] yo estoy trabajando con los [http://beta.octopart.com/MaxStream__XBP24-ACI-001.pdf XBEE] y la verdad que funcionan muy bien, tengo hechas placas de desarrollo con interfaz Serie. Los bluetoth son módulos que consumen mas que el Zigbee y no están orientados a una red "punto a multipunto" sino a una "punto a punto". Y pensando en la integración del robot a una sociedad de robot nos jugaría en contra.
[[Usuario:Marianobustos|Marianobustos]] 02:25 12 mar 2008 (ARST) [[Usuario:Marianobustos|Marianobustos]] 02:25 12 mar 2008 (ARST)
 +----
 +
 +El tema de transferir datos a la PC es porque es la mejor forma de monitorear qué es lo que está pasando en un sistema así, lo digo por experiencia. No es difícil hacer que los datos que uno quiere monitorear se vean en forma gráfica. Ayuda mucho.
 +
 +Lo otro, lo de la [[CPU]], bueno, claro que sí. La verdadera unidad central del robot está sin definir, hablamos de tarjetas en las que pueda correr un sistema operativo, pero no decidimos nada.
 +
 +Cuando menciono un [[PIC]] es para dar una comparación, ya que es lo que más conozco de lo actual, y porque son baratos y disponibles, y algunos los dominamos muy bien, así que podremos hacer los [[módulos de control local]] con ellos.
 +
 +En el caso de las comunicaciones, los microcontroladores locales estarían colgados en el bus [http://robots-argentina.com.ar/Comunicacion_busI2C.htm I2C] (y no es necesario que haya un solo bus [http://robots-argentina.com.ar/Comunicacion_busI2C.htm I2C], puede haber más de uno), y éstos serían manejados y concentrados en un módulo de bus que maneje estas comunicaciones, decida prioridades, genere las interrupciones de la [[CPU]], etc.
 +
 +En este módulo es en el que pensaba cuando hablaba de un [http://ww1.microchip.com/downloads/en/DeviceDoc/39582b.pdf PIC16F87x]. Seguro que hay [[PIC|PICs]] más grandes y por supuesto que hay otras líneas. El [http://ww1.microchip.com/downloads/en/DeviceDoc/39582b.pdf PIC16F877A] y hermanitos es uno de mis caballitos de batalla preferidos, tiene de todo y tiene ese lindo port esclavo que se puede colgar en el bus de memoria de un microprocesador, por dar un ejemplo, para tener comunicaciones veloces con el sistema.
 +
 +--[[Usuario:Edu|Edu]] 15:39 12 mar 2008 (ARST)
---- ----

Revisión actual

Comunicaciones externas

Aunque todavía está por definir, por el momento yo pienso en un transmisor y un receptor en comunicación constante, pero intercalada. Desde el robot se transmite un paquete de datos con información de estado de sensores y luego se pasa a espera de recepción. El otro lado (una PC de comando) recibe este paquete e inmediatamente transmite órdenes, si es necesario, o un OK, y pasa a su vez a espera. La situación se mantiene indefinidamente, y sólo se modifica cuando por un comando desde la computadora, o por una solicitud del programa del robot, se establece —momentáneamente— la transmisión de un bloque de datos más amplio, por ejemplo, una descarga de rutinas. O un informe más detallado de estado del robot (posiciones, temperaturas, registros de movimientos realizados, etc).

Este sistema lo implementé en un robot (uno de tres ruedas) que funciona en contacto con una PC u otra computadora. La RF está implementada con módulos TWS y TRS de Wenshing, aunque seguramente en el robot hay que buscar alternativas más profesionales. El diseño lleva un PIC16F628A en el lado de transmisión y uno igual en el lado de recepción. Esto porque había cosas que me resultaba difícil compartir, por lo cual me pareció que el costo de un PIC más no era importante ante la simplificación en el uso y en la programación (agregado el 10 de marzo por Edu).

--Edu 21:34 9 mar 2008 (ARST)

Se podría decir entonces, que el robot tendrá un módulo de comunicaciones gestionado por (al menos) un micro-----. Ese módulo será independiente del resto del sistema y lo contactará solo cuando sea necesario.
Así como este módulo, es posible que aparezcan otros más...

Siguiendo el lineamiento entonces puede pasar que tengan que coexistir muchos distintos módulos dedicados, cada uno, a tareas específicas, que tengan en común el mismo diseño electrónico (como para que ayude a que el costo de diseño sea más bajo).

Comunicación interna

Además es seguro que entre módulos sea necesaria alguna forma de comunicación interna que normalmente se resuelven por un bus y un protocolo.
El protocolo puede ser uno que dependa del tipo de micros utilizados o que sea uno completamente nuevo.

        ________
       |        |
Al ext.|Mod.    |.............<---- bus interno
       |Comunic.|            .
       |________|            .
                             .
        ________             .
       |        |            .
(¿?)   |Mod.    |.............
       |(---)   |            .
       |________|            .
                             .
        ________             .
       |        |            .
(¿?)   |Mod.    |.............
       |(---)   |            .
       |________|            ........al resto de los módulos



       Figura 1.

Aún así, el método de interconectar todos los módulos a un mismo bus podría resultar lento. Esto obligaría a disponer los módulos en una especie de estructura de árbol. ( es fácil decirlo pero habría que demostrar que la comunicación entre módulos dispuestos en una estructura de árbol puede llegar a ser, en determinadas circunstancias o siempre, mas eficiente que la comunicación entre módulos colgados a un mismo bus). Implica que todos los módulos preprocesen información de otros módulos que tienen por detrás.
Podría pasar que, (por dar un ejemplo), cada tobillo del robot necesite su propio módulo. Lo mismo la cadera, y así varios otros puntos clave del robot. De ser así hay que prever el espacio y el lugar para colocar cada uno de esos módulos.

En este punto es posible que se haga necesario comenzar a pensar entonces en un algoritmo para las comunicaciones internas entre módulos.

Resumiendo lo anterior, los planteos serían:

--Adrian S.A. 11:35 10 mar 2008 (ARST)


Parece que está bien separar los modulos para un control más específico, y para acelerar la comunicación. Ahora creo que deberíamos disponer de un módulo de control local de todo lo referente a movimientos, para evaluación, Pap y cambio de variables simples. Se me ocurre tener en alguna parte un teclado flexible con una pantallita de dos líneas, y usar algún protocolo para comunicarme con la central dentro del androide.

--Mastromec 14:30 10 mar 2008 (ARST)

Como opción para la comunicación con el exterior, yo implemente módulos Zigbee que son de muy bajo consumo, tienen interfaz uart (lo uso a 115200 bps) y se puede trabajar con varios módulos simultáneos en una misma red (topologia COORDINADOR/CLIENTES). También es una opción para usar como "teclado remoto" si quieren :)

Por otro lado, se me ocurre que podemos crear un protocolo, como decía Adrian, genérico para todo el sistema de manera que haya 3 partes centrales en el androide:

1- Cabeza: Control general del sistema y comunicación con el exterior. 2- Torso y Caderas: Se encargaría de la movilidad y de actualizar las variables de su estructura, etc. (todavía falta para especificar mas funcionalidades) 3- Piernas: Maneja los motores, las mediciones de posición, actualiza los datos en su estructura, etc.

Veran que menciono una "Estructura", esto es porque pense en la posibilidad de tener un Propeller (por la capacidad de 8 cogs al mismo tiempo, puede ser cualquier otro) como un dispositivo de "base de datos". Es decir, la idea es simplificar cuestiones para la inteligencia de la cabeza y que ésta solo interactúe con los otros dos modulos para tomar decisiones. 


        ________      _____
       |        |    |     |
Al ext.|Mod.    |....| CPU |...<---- bus interno
       |Comunic.|    |     |  .
       |________|    |_____|  .
                              .
                   ________   .
                  |        |  .
(¿?) Modulos .....|Mod.    |...
        2º        |TORSO   |  .
                  |________|  .
                              .
                   ________   .
                  |        |  .
(¿?) Modulos .....|Mod.    |...        _________
        2º        |PIERNAS |  .       |         |
                  |________|  ........| Memoria |
                                      |  Datos  |
                                      |_________|

                 Figura 2.

Con lo cual cada módulo puede acceder a la base de datos para ir grabando sus mediciones y la CPU tendría una tarea cada X tiempo para enviar los datos que sean necesarios al exterior. En dicha memoria podríamos guardar los datos que menciona Juan.

Marianobustos 15:13 10 mar 2008 (ARST)

Se me ocurre que debería haber un módulo dedicado al equilibrio (balance/equilibrium):
De esta manera, como el equilibrio tiene que ver con todos los elementos móviles del sistema, sería mas fácil programar al respecto. 

        ________      _____
       |        |    |     |
Al ext.|Mod.    |....| CPU |...<---- bus interno
       |Comunic.|    |     |  .
       |________|    |_____|  .
                              .
                   ________   .
                  |        |  .
 ¿?) Modulos .....|Mod.    |...
        2º        |TORSO   |  .
                  |________|  .
                              .
                   ________   .
                  |        |  .
 ¿?) Modulos .....|Mod.    |...        _________
        2º        |PIERNAS |  .       |         |
                  |________|  ........| Memoria |
                              .       |  Datos  |
                              .       |_________|
                              .
                   ________   .
                  |        |  .
    (¿?)     .....|Mod.    |...
                  |BALANCE |  .
                  |________|  .
                 (equilibrio) .

               Figura 3.

--Adrian Adrian S.A. 17:23 10 mar 2008 (ARST)

Sin dudas el esquema de dos tipos de comunicaciones, una interna entre módulos, y la otra desde un módulo principal hacia afuera es el que se necesita.

Me parece que, al menos inicialmente, para el bus de comunicación intermódulos deberíamos adoptar I2C, por su facilidad de implementación y compatibilidad con cualquier microcontrolador que se elija luego para cada parte. El módulo principal que mencionábamos antes haría de Master y cada módulo de operación (pie, rodilla, cadera, etc) sería un Slave.

Hacia afuera propongo que el mencionado módulo principal de comunicaciones (MPC) se base en algún PIC con soporte para USB, además de puerto serie. De este modo podríamos conectar una PC mediante un cable USB cuando necesitamos transferir muchos datos, modificar el programa, etc. y dejar el puerto serial para conectar a cualquier medio inalámbrico, seguramente algun módulo RF (esperemos más confiable que los Wenshing), Zigbee, Bluetooth o lo que fuere.

El mismo MPC debería también gestionar el teclado y display que mencionaba Mastromec ya que también son una forma de comunicación.

Podríamos considerar además la posibilidad de agregarle un sensor IR, de modo de poder enviar comandos de acción directa con un control remoto de mano. Me refiero a paradas de energencia y otros comando útiles para las demos, je, je (Asimo falling down)

--Migrassi 14:36 11 mar 2008 (ARST)

Para mí también el I2C está bien y es suficiente, y si se diera el caso de dos módulos que deban transferir en algún momento bloques grandes de información y muy velozmente, se puede implementar otro bus, por ejemplo el que se puede implementar usando el port paralelo esclavo de los PICs 16F87x.

Si tuviésemos sucesos tan tremendamente urgentes que se podrían "perder" o atender tarde por culpa del tráfico en I2C, simplemente habrá que cablearlos como interrupciones.

--Edu 15:08 11 mar 2008 (ARST)

Me gusta la idea de utilizar el bus I2C y a las tareas urgentes asignarles interrupciones.

No me convence mucho la otra idea de dejar tantas conexiones hacia el exterior, osea, si es en un principio como debug me parece perfecto, pero tendría que ser autónomo y solo dejar al exterior las conexiones para poder programar a los distintos módulos. Ver ISP

Propongo otras alternativas al PIC, como el ARM, quizás éstos últimos están mas orientados a portar un sistema operativo (Ver RTOS) lo cual seria una buena base para el MPC.

También se me ocurre que una solución para transferir muchos datos a la pc (como dice Miguel) es usar una tarjeta SD las cuales son muy seguras y hoy en día hasta los teclados vienen con lectores para estas tarjetas.

En cuanto a los módulos Zigbee yo estoy trabajando con los XBEE y la verdad que funcionan muy bien, tengo hechas placas de desarrollo con interfaz Serie. Los bluetoth son módulos que consumen mas que el Zigbee y no están orientados a una red "punto a multipunto" sino a una "punto a punto". Y pensando en la integración del robot a una sociedad de robot nos jugaría en contra.

Marianobustos 02:25 12 mar 2008 (ARST)

El tema de transferir datos a la PC es porque es la mejor forma de monitorear qué es lo que está pasando en un sistema así, lo digo por experiencia. No es difícil hacer que los datos que uno quiere monitorear se vean en forma gráfica. Ayuda mucho.

Lo otro, lo de la CPU, bueno, claro que sí. La verdadera unidad central del robot está sin definir, hablamos de tarjetas en las que pueda correr un sistema operativo, pero no decidimos nada.

Cuando menciono un PIC es para dar una comparación, ya que es lo que más conozco de lo actual, y porque son baratos y disponibles, y algunos los dominamos muy bien, así que podremos hacer los módulos de control local con ellos.

En el caso de las comunicaciones, los microcontroladores locales estarían colgados en el bus I2C (y no es necesario que haya un solo bus I2C, puede haber más de uno), y éstos serían manejados y concentrados en un módulo de bus que maneje estas comunicaciones, decida prioridades, genere las interrupciones de la CPU, etc.

En este módulo es en el que pensaba cuando hablaba de un PIC16F87x. Seguro que hay PICs más grandes y por supuesto que hay otras líneas. El PIC16F877A y hermanitos es uno de mis caballitos de batalla preferidos, tiene de todo y tiene ese lindo port esclavo que se puede colgar en el bus de memoria de un microprocesador, por dar un ejemplo, para tener comunicaciones veloces con el sistema.

--Edu 15:39 12 mar 2008 (ARST)

Obtenido de "https://robots-argentina.com.ar/androide/index.php?title=Estructura_de_comunicaciones"