jueves, 31 de octubre de 2013
miércoles, 19 de enero de 2011
PC - NXT Communications
One of the great successes of LEGO MINDSTORMS NXT development is the native implementation of Blutetooth Serial communications layer.
This means that we have a wireless serial communications interface that allows us to develop programs that interact with our robots and perform remote control and telemetry in real time.
NXT communication between devices is documented in Appendix 1 of BtDeveloperKit, but the PC-NXT communication requeire undocumented technique both for the host device settings, and to control data flow.
If you work in c, my recommendation is to create a library that allows communication NXT TXRX.h added as file in any program that subsequently perform well have the concept of "communication layer that allows us to abstract and focus on the object programming.
From the host side (PC in our case), we must also develop a small code that will allow us to abstract the process.
And advancement, resolved in an efficient communication process is to develop a communication interface to provide us with certain communication services.
For example, our development has developed two types of service:
Service 1 º Sending information
Service 2º Consultation Service Information
Both services are symmetrical and are located at each end of the interface. The purpose of these services is to have a mechanism that allows us to send asynchronous commands (remote) and request information (telemetry). In the definition of service we set the format of the information, so the maximum length. Advance and we may be interested in having a short data or a large amount of data, and therefore we must establish mechanisms to fragment and reconstruct the information at the other end.
NXT BT SDK
In the LEGO website, you can download the SDK Bluetooth where we describe the characteristics of the packet format used, along with communication services that this layer implements.
Although we have a lot of services 'high' as access to files, internal variables, etc, which interests us is the generic coumunicaciones on MailBox (0-9), which allows us to send a packet of 64bytes (6 bytes payload) on a 'connection' that will be glued to 5 packets (messages) on the other end and managed automatically returning overflow error in the host side to let us know that we can not continue to transmit.
This will be the communications service will use to build our application interface, allowing us to have up to 10 Mailboxes (0-9) (lines of communication or different data streams) to our communication process. In our case only use a single stream of information.
This means that we have a wireless serial communications interface that allows us to develop programs that interact with our robots and perform remote control and telemetry in real time.
NXT communication between devices is documented in Appendix 1 of BtDeveloperKit, but the PC-NXT communication requeire undocumented technique both for the host device settings, and to control data flow.
If you work in c, my recommendation is to create a library that allows communication NXT TXRX.h added as file in any program that subsequently perform well have the concept of "communication layer that allows us to abstract and focus on the object programming.
From the host side (PC in our case), we must also develop a small code that will allow us to abstract the process.
And advancement, resolved in an efficient communication process is to develop a communication interface to provide us with certain communication services.
For example, our development has developed two types of service:
Service 1 º Sending information
Service 2º Consultation Service Information
Both services are symmetrical and are located at each end of the interface. The purpose of these services is to have a mechanism that allows us to send asynchronous commands (remote) and request information (telemetry). In the definition of service we set the format of the information, so the maximum length. Advance and we may be interested in having a short data or a large amount of data, and therefore we must establish mechanisms to fragment and reconstruct the information at the other end.
NXT BT SDK
In the LEGO website, you can download the SDK Bluetooth where we describe the characteristics of the packet format used, along with communication services that this layer implements.
Although we have a lot of services 'high' as access to files, internal variables, etc, which interests us is the generic coumunicaciones on MailBox (0-9), which allows us to send a packet of 64bytes (6 bytes payload) on a 'connection' that will be glued to 5 packets (messages) on the other end and managed automatically returning overflow error in the host side to let us know that we can not continue to transmit.
This will be the communications service will use to build our application interface, allowing us to have up to 10 Mailboxes (0-9) (lines of communication or different data streams) to our communication process. In our case only use a single stream of information.
Comunicaciones PC-NXT
Uno de los grandes aciertos de LEGO en el desarrollo del NXT MINDSTORMS es la implementación nativa de la capa de comunicaciones Serial Blutetooth.
Esto significa que disponemos de un interfaz de comunicaciones serie inalámbrico que nos permite desarrollar programas que interactúen con nuestros robots y realizar control remoto o telemetría en tiempo real.
La comunicación entre dispositivos NXT está documentada en el Apéndice 1 del BtDeveloperKit, pero la comunicación PC-NXT requeire de una técnica no documentada, tanto de configuración para el dispositivo host, como para el control de flujo de datos.
Si trabajas en c, mi recomendación es la de crear una librería de comunicaciones NXT que permita agregar como fichero TXRX.h en cualquier programa que realicemos posteriormente y así disponer del concepto de "capa de comunicaciones" que nos permita abstraernos y centrarnos en el objeto de la programación.
Desde el lado del host (PC en nuestro caso), también tenemos que desarrollar un pequeño código que nos permitirá abstraer dicho proceso.
Así como adelanto, resolver de una forma eficiente el proceso de comunicaciones consiste en desarrollar un interfaz de comunicaciones que nos aporte ciertos servicios de comunicación.
Para nuestro desarrollo de ejemplo se han desarrollado dos tipos de servicio:
Servicio 1º Envío de información
Servicio 2º Consulta de información
Ambos servicios son simétricos y se encuentran en cada extremo del interfaz. El objeto de estos servicios es disponer de un mecanismo asíncrono que nos permita enviar órdenes (control remoto) y requerir información (telemetría). En la definición del servicio deberemos establecer el formato de la información, su longitud máxima etc. Ya adelanto que nos puede interesar disponer de un dato breve o de una gran cantidad de datos, y por ello deberemos establecer mecanismos que permitan fragmentar la información y reconstruirla en el otro extremo.
NXT BT SDK
En la web de LEGO, podemos descargar el SDK Bluetooth donde nos describe las características del formato de paquete que utiliza, junto con los servicios de comunicación que esta capa implementa.
Aunque disponemos una gran cantidad de servicios de 'alto nivel' como acceso a ficheros, variables internas, etc, el que nos interesa, es el de coumunicaciones genéricas sobre MailBox (0-9), que nos permite enviar un paquete de 64bytes (6 bytes payload) sobre una 'conexión' que permitirá encolar hasta 5 paquetes (mensajes) en el otro extremo y automáticamente gestionará el desbordamiento devolviendo error en el lado host para hacernos saber que no podemos seguir transmitiendo.
Este servicio de comunicaciones será el que utilizaremos para construir nuestra interfaz de aplicación, ya que nos permite disponer de hasta 10 Mailboxes (0-9) (colas de comunicación o flujos diferenciados de datos) para nuestro proceso de comunicación. Para nuestro caso únicamente utilizaremos un único flujo de información.
Esto significa que disponemos de un interfaz de comunicaciones serie inalámbrico que nos permite desarrollar programas que interactúen con nuestros robots y realizar control remoto o telemetría en tiempo real.
La comunicación entre dispositivos NXT está documentada en el Apéndice 1 del BtDeveloperKit, pero la comunicación PC-NXT requeire de una técnica no documentada, tanto de configuración para el dispositivo host, como para el control de flujo de datos.
Si trabajas en c, mi recomendación es la de crear una librería de comunicaciones NXT que permita agregar como fichero TXRX.h en cualquier programa que realicemos posteriormente y así disponer del concepto de "capa de comunicaciones" que nos permita abstraernos y centrarnos en el objeto de la programación.
Desde el lado del host (PC en nuestro caso), también tenemos que desarrollar un pequeño código que nos permitirá abstraer dicho proceso.
Así como adelanto, resolver de una forma eficiente el proceso de comunicaciones consiste en desarrollar un interfaz de comunicaciones que nos aporte ciertos servicios de comunicación.
Para nuestro desarrollo de ejemplo se han desarrollado dos tipos de servicio:
Servicio 1º Envío de información
Servicio 2º Consulta de información
Ambos servicios son simétricos y se encuentran en cada extremo del interfaz. El objeto de estos servicios es disponer de un mecanismo asíncrono que nos permita enviar órdenes (control remoto) y requerir información (telemetría). En la definición del servicio deberemos establecer el formato de la información, su longitud máxima etc. Ya adelanto que nos puede interesar disponer de un dato breve o de una gran cantidad de datos, y por ello deberemos establecer mecanismos que permitan fragmentar la información y reconstruirla en el otro extremo.
NXT BT SDK
En la web de LEGO, podemos descargar el SDK Bluetooth donde nos describe las características del formato de paquete que utiliza, junto con los servicios de comunicación que esta capa implementa.
Aunque disponemos una gran cantidad de servicios de 'alto nivel' como acceso a ficheros, variables internas, etc, el que nos interesa, es el de coumunicaciones genéricas sobre MailBox (0-9), que nos permite enviar un paquete de 64bytes (6 bytes payload) sobre una 'conexión' que permitirá encolar hasta 5 paquetes (mensajes) en el otro extremo y automáticamente gestionará el desbordamiento devolviendo error en el lado host para hacernos saber que no podemos seguir transmitiendo.
Este servicio de comunicaciones será el que utilizaremos para construir nuestra interfaz de aplicación, ya que nos permite disponer de hasta 10 Mailboxes (0-9) (colas de comunicación o flujos diferenciados de datos) para nuestro proceso de comunicación. Para nuestro caso únicamente utilizaremos un único flujo de información.
Suscribirse a:
Entradas (Atom)