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

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

Estructura de comunicaciones

Revisión de fecha 17:59 10 mar 2008; Ver revisión actual
← Revisión anterior | Revisión siguiente →

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 4me 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 esta bien separar los modulos para un control mas especifico, y para acelerar la comunicacion. Ahora creo que deberíamos disponer de un modulo 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 lineas, y usar algun 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 interactue 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 modulo 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)



Encontrar
Hojear
Portada
Categorías
Portal de la comunidad
Actualidad
Cambios recientes
Página aleatoria
Ayuda
Donaciones
Editar
Editar esta página
Ayuda de edición
Opciones de página
Discutir esta página
Poner un comentario
Versión para imprimir
Información de página
Historial
Lo que enlaza aquí
Seguir enlaces
Mis opciones
Registrarse/Entrar
Páginas especiales
Páginas nuevas
Lista de imágenes
Estadísticas
Informes de error de software
Más...