Con la modificación del firmware, me vi obligado a cambiar la forma en la que el ordenador y el Pc se comunicaban. Hasta ahora, el Pc se conectaba con el robot por medio de bluetooth, y escribía en los registros de este de forma directa. Esto ya no sería posible, así que había que buscar una solución elegante.
En un primer momento pensé que el Pc, ejecutando Python (Pp), establecería conexión con el Robot, que ejecuta Java (Rj). Rj quedaría a la escucha de peticiones de conexión que vendrían por parte de Pp, una vez establecida existiría un paso de mensajes entre Pp y Rj. Estos mensajes indicarían al robot que acción debería tomar. Pero algo no salió bien, los mensajes llegaban al buffer de entrada de Rj, pero no logré obtenerlos por completo.
Así que hice una segunda aproximación, y situé un servicio intermedio, escrito en Java (Pj) que se encarga de arrancar un puerto de escucha, recibe una petición de conexión por parte de Pp. Entonces es él quien se conecta con Rj para continuar haciendo de intermediario entre Pp y Rj. Esta segunda solución si funcionaba, ya que el servidor Pj si se comunica correctamente con Rj.
Ante la necesidad de utilizar un servidor que me hiciese de intermediario entre Pp y Rj, decidí aprovechar todas las ventajas que podía sacarle a Pj. Ahora tenía un nuevo componente software, que se ejecuta como servidor en alguna parte del mundo. Por medio de TCP/IP recibe peticiones de conexión de un cliente y negocia una conexión (mediante bluetooth) con un robot, haciendo llegar a este los mensajes del cliente. La ventaja mas inmediata era aprovechar la programación en hilos, de tal forma que un sólo servidor escuchando en un puerto determinado pudiese establecer múltiples conexiones Pp-Rj.
De esta forma di un tercer paso para implementar por completo una arquitectura cliente servidor, en la cual entran en juego tres elementos: Pp, Pj y Rj. Para cada petición de conexión recibida de Pp, Pj crea un hilo que servirá de intermediario en el envío de mensajes Pp <-> Rj, una vez que Pp desea terminar la conexión el hilo termina su ejecución.
Un último detalle que quedaba por rematar era crear un protocolo de conexión, de tal forma que Pj supiese con que Rj deseaba conectarse Pp. Con este protocolo remataba la gestión de las conexiones.
Finalmente he introducido un elemento nuevo con el que en principio no contaba. Aunque al principio lo consideré una desventaja, ahora dispongo de un sistema de comunicaciones independiente del lenguaje empleado en el Pc (Px), de tal forma que pueden establecerse complejos comportamiento en lenguajes como LISP, Python o C y comunicar de una forma fiable y segura a los robots las acciones a tomar.
En un primer momento pensé que el Pc, ejecutando Python (Pp), establecería conexión con el Robot, que ejecuta Java (Rj). Rj quedaría a la escucha de peticiones de conexión que vendrían por parte de Pp, una vez establecida existiría un paso de mensajes entre Pp y Rj. Estos mensajes indicarían al robot que acción debería tomar. Pero algo no salió bien, los mensajes llegaban al buffer de entrada de Rj, pero no logré obtenerlos por completo.
Así que hice una segunda aproximación, y situé un servicio intermedio, escrito en Java (Pj) que se encarga de arrancar un puerto de escucha, recibe una petición de conexión por parte de Pp. Entonces es él quien se conecta con Rj para continuar haciendo de intermediario entre Pp y Rj. Esta segunda solución si funcionaba, ya que el servidor Pj si se comunica correctamente con Rj.
Ante la necesidad de utilizar un servidor que me hiciese de intermediario entre Pp y Rj, decidí aprovechar todas las ventajas que podía sacarle a Pj. Ahora tenía un nuevo componente software, que se ejecuta como servidor en alguna parte del mundo. Por medio de TCP/IP recibe peticiones de conexión de un cliente y negocia una conexión (mediante bluetooth) con un robot, haciendo llegar a este los mensajes del cliente. La ventaja mas inmediata era aprovechar la programación en hilos, de tal forma que un sólo servidor escuchando en un puerto determinado pudiese establecer múltiples conexiones Pp-Rj.
De esta forma di un tercer paso para implementar por completo una arquitectura cliente servidor, en la cual entran en juego tres elementos: Pp, Pj y Rj. Para cada petición de conexión recibida de Pp, Pj crea un hilo que servirá de intermediario en el envío de mensajes Pp <-> Rj, una vez que Pp desea terminar la conexión el hilo termina su ejecución.
Un último detalle que quedaba por rematar era crear un protocolo de conexión, de tal forma que Pj supiese con que Rj deseaba conectarse Pp. Con este protocolo remataba la gestión de las conexiones.
Finalmente he introducido un elemento nuevo con el que en principio no contaba. Aunque al principio lo consideré una desventaja, ahora dispongo de un sistema de comunicaciones independiente del lenguaje empleado en el Pc (Px), de tal forma que pueden establecerse complejos comportamiento en lenguajes como LISP, Python o C y comunicar de una forma fiable y segura a los robots las acciones a tomar.
No hay comentarios:
Publicar un comentario