Robot Movil Controlado Por Internet TESIS

Autorizada la entrega del proyecto: Desarrollo de un robot mvil controlado desde Internet: Comunicaciones Wi-Fi Realizado por: Jaime
Alonso lvarez
V B de los Directores del Proyecto:
Firmado: lvaro Snchez Miralles Fecha: //
Firmado: Rafael Palacios Hielscher Fecha: //
V B de los Coordinadores de rea:
Firmado: Sadot Alexandres Fernndez Fecha: //
Firmado: lvaro Snchez Miralles Fecha: //
UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)
Ingeniero Industrial
PROYECTO FIN DE CARRERA
DESARROLLO DE UN ROBOT MVIL CONTROLADO DESDE INTERNET: COMUNICACIONES Wi-Fi
AUTOR:
Jaime Alonso lvarez MADRID, Junio 2005
DESARROLLO DE UN ROBOT MVIL CONTROLADO DESDE INTERNET: COMUNICACIONES Wi-Fi Autor: Alonso lvarez, Jaime. Directores: Snchez Miralles, lvaro. Palacios Hielscher, Rafael. Entidad Colaboradora: ICAI-Instituto de Investigacin Tecnolgica RESUMEN DEL PROYECTO:
Este proyecto forma parte de un desarrollo conjunto, constituido por dos proyectos en total, cuyo objetivo final es lograr implementar un robot mvil cuya principal habilidad radica en la posibilidad de ser controlado por un usuario remoto, conectado desde Internet, a travs de una red Wi-Fi funcionando con el protocolo TCP/IP. De esta forma, el usuario podr telecontrolar los movimientos del robot, a la vez que a travs de una cmara tambin conectada a
travs de Wi-Fi, visiona el discurrir del robot mediante un navegador Web. El objetivo concreto de este proyecto, motivado por un trabajo
Figura 1: Esquema de concepto del proyecto
anteriormente publicado en esta universidad 2, es el lograr implementar una solucin hardware/software que, funcionando sobre el propio robot, le permita conectarse al programa de control que facilita actuar al usuario desde Internet, a fin de recibir rdenes de actuacin y ejecutarlas satisfactoriamente. A tal efecto, se cuenta con una plataforma de desarrollo cuyo principal componente es un mdulo de comunicacin Wi-Fi controlado por un microprocesador. En este microprocesador residen toda la necesidad de proceso y el control de las comunicaciones de toda la plataforma. La tarjeta que controla los motores (TCS),
Resumen y el protocolo antes mencionado, son el resultado de un proyecto realizado en esta misma escuela el pasado ao 1. La Figura 1 recoge el concepto global del proyecto. El primer paso consisti en familiarizarse con el entorno de desarrollo proporcionado. El lenguaje de programacin utilizado para el microprocesador es C/C++. El principal problema en esta etapa radic en la inexistencia de una documentacin adecuada que recogiese la forma de utilizacin y programacin en el entorno de desarrollo proporcionado. Toda informacin tuvo que ser deducida a partir de aplicaciones de ejemplo proporcionadas por el fabricante, y de la lectura profunda de los archivos de cabecera del entorno de desarrollo. Por ello, la tarea de documentacin ha ocupado un papel crucial. A continuacin, los esfuerzos se centraron en el establecimiento de una conexin va Wi-Fi entre un PC cliente y el mdulo embebido, actuando como servidor. El funcionamiento de esta conexin es el siguiente: el mdulo crea un socket bajo el protocolo TCP/IP y lo asocia a un puerto proporcionado en el propio cdigo, dependiendo de su disponibilidad en la red a operar. Desde el momento en que el socket queda abierto, el mdulo permanece a la escucha en ese socket hasta que un PC cliente solicita una conexin. Llegado ese momento, se acepta la conexin y comienza un proceso de comunicacin bidireccional continua entre ambos: el mdulo servidor recibe cadenas de caracteres y manda al cliente una cadena de confirmacin de dicha recepcin. Para comprobar el buen funcionamiento de la conexin Wi-Fi, se desarroll un pequeo programa de prueba en Microsoft Visual C++ 6.0 (TCPTest.exe) que permite conectarse como cliente al servidor y mandarle cadenas de caracteres, comprobando su correcta recepcin. Una vez logrado el establecimiento de la conexin a travs de la red Wi-Fi y comprobado el correcto intercambio de informacin a travs de este canal, se pas a establecer una conexin serie con la TCS mediante el protocolo RS232, a fin de poder convertir la informacin recibida desde el usuario en actuaciones del robot. La TCS acta de acuerdo a un protocolo preestablecido (Ver referencia 1, captulo 3, Tarjeta de 2 PICs), consistente en una serie de caracteres enviados por el puerto serie a cada uno de los dos PICs que la componen. Lo realizado en este apartado es la adicin de un nuevo hilo de proceso que abre y configura el puerto serie del mdulo conforme a los parmetros de funcionamiento de la TCS
Resumen (Baudrate, paridad, etc.), enviando a travs del mismo las rdenes generadas a partir de la informacin recibida por va Wi-Fi en otro hilo de proceso que se ejecuta paralelamente. As pues, tenemos dos hilos de proceso simultneos: un primer hilo que constantemente se comunica con el usuario a travs de la red inalmbrica e interpreta las rdenes recibidas, generando una cadena acorde con el protocolo antes mencionado, y un segundo hilo cuya misin es enviar a travs del puerto serie a la TCS las cadenas para desencadenar la actuacin del robot. La comunicacin entre ambos hilos se establece a travs de una variable en memoria compartida que almacena las cadenas a enviar y un sistema de flags de exclusin mutua para evitar conflictos por acceso simultneo de ambos hilos a la memoria compartida y para indicar si hay instrucciones nuevas que enviar. Posteriormente se construy un robot sencillo, en LEGO, como plataforma de prueba para demostrar la correcta integracin del robot con el control remoto desarrollado en el otro proyecto. La Figura 2 muestra el resultado final obtenido. En conclusin, se ha logrado
Figura 2: Resultado final
desarrollar una plataforma que permite telecontrolar un robot conectado a travs de una red inalmbrica por parte de un usuario remoto, que adems tiene la posibilidad de observar la evolucin del mismo en la misma ventana de control gracias a una cmara Web Wi-Fi, as como realizar una documentacin que suple la inexistencia detectada durante el desarrollo del proyecto de la proporcionada por el fabricante del mdulo, de forma que se facilite la utilizacin del mismo para desarrollos posteriores.
Referencias: 1. Prrizas Fernndez, Francisco Javier. Plataforma para el control de robots mviles autnomos: Driver de comunicacin entre PDA y plataforma. Fuente: Biblioteca de proyectos fin de carrera, Universidad Pontificia Comillas, Escuela Tcnica Superior de Ingeniera (ICAI), Madrid, Junio 2004.
2. Snchez Miralles, lvaro y Palacios Hielscher, Rafael. Sistema para el control remoto de un robot
mediante un navegador de Internet (I y II). Revista Anales de mecnica y electricidad. Asociacin de ingenieros del ICAI. Volumen LXXVIII, fascculos II y III. Marzo-Abril y Mayo-Junio 2001.
Resumen
DEVELOPMENT OF A MOBILE ROBOT CONTROLLED FROM THE INTERNET: Wi-Fi COMMUNICATIONS Author: Alonso lvarez, Jaime. Managers: Snchez Miralles, lvaro. Palacios Hielscher, Rafael. Collaborating Entity: ICAI-Instituto de Investigacin Tecnolgica ABSTRACT:
This project is a part of a global development, carried out by two projects in total, whose final aim is to achieve the implementation of a mobile robot whose main ability lies in the possibility of being controlled by a remote user, connected through the Internet by means of a Wi-Fi TCP/IP protocol network. This way, user could remote-
control robot movement while he could also view its progress through a Wi-Fi webcam, all of this integrated in his web browser. The concrete goal this project wants to achieve, based in a development
Picture 2: Global project concept
formerly carried out at this university [2], is to implement a hardware/software solution which, working inside the robot, will allow it to get connected to the control software which will make the user able to act from the Internet, in order to receive orders from that user and to satisfactorily execute them. So that, there has been bought a development kit whose main component is a communication Wi-Fi module controlled by a microprocessor. In this microprocessor resides every kind of process requirement and the control of communications between every piece of the platform. The Sensor Control Board (SCB) and the protocol previously
Resumen mentioned, are the final results for a project carried out in this engineering school last year [1]. Picture 1 shows the global project concept. The first step consisted in becoming familiar with the development platform given. The programming language used for developing software to the module is C/C++. The main problem found at this stage was the lack of an appropriate documentation including how to deal with the many libraries provided with this developing environment. Every piece of information about using the APIs provided as well as port configuration, etc., had to be inferred from sample programs provided by the manufacturer, and from the deep study of header files which contained function declarations, parameters, constants, etc. This fact has slowed down the course initially planned for the project, making the documentation process play a more important role than it was expected to when the project was proposed. Then, the efforts were aimed at the establishment of a Wi-Fi connection between a client PC and the embedded module, acting as a server. This connection works as explained: the module creates a socket under the TCP/IP protocol and binds it to a port provided in the source code, depending on its availability in the network its going to work on. From that moment on, the module stands listening on that port until a client PC requests a connection. When that fact occurs, the connection is accepted and a bidirectional continuous communication process between both of them begins: the server module receives character chains and sends to the client a confirmation for the successful reception. To check the correct operation of the Wi-Fi connection, a simple testing program was developed under Microsoft Visual C++ 6.0 (TCPTest.exe) which allows to get connected as a client to the module server and to send it character chains, checking its successful reception. Once a connection establishment through the Wi-Fi network was achieved and the correct exchange of information through that connection was checked, we went on to set up a serial connection under RS232 protocol to the SCB, in order to be able to transform the information received from the user into movements on the robot. The SCB works under a fixed protocol (See [1], chapter 3, 2 PICs board), consisting in a set of characters sent through the serial port through each one of the PICs its made up of. What has been done at this stage is the addition of a new thread to the program, intended to open and make the setup of a modules
Resumen serial port as its fixed in the configuration parameters of the SCBs serial port (Baudrate, parity control, etc.), sending through it the orders generated from the information received through the Wi-Fi connection by the other program thread being executed at the same time. So that, we have two threads running simultaneously: a first one constantly communicating with the user through the wireless network and interpretting the received orders, generating a chain according to the protocol previously mentioned, and a second one whose work is to send the chains through the serial port to the SCB to unleash the movement of the robot. The communication between the two threads is possible thanks to a shared memory variable and a system of mutual exclusion flags to avoid crashing caused by simultaneous writing access of both threads to shared memory, and to indicate if there are new instructions to send. Subsequently, a simple robot was built, using LEGO, as a testing platform to show the correct
integration of the robot with the remote control interface developed by the other project. Picture 2 shows the final result for this
Picture 2: Final result
development.
In short, it has been achieved the development of a platform which allows to remote-control a robot connected through a wireless network, by a remote user who also has the possibility of watching its movements through the same control window, thanks to a Wi-Fi webcam, as well as making a documentation and a user manual which makes up for the lack of information provided by the module manufacturer, in order to make its use easier for future developments.
Bibliography: 1. Prrizas Fernndez, Francisco Javier. Plataforma para el control de robots mviles autnomos: Driver de comunicacin entre PDA y plataforma. Fuente: Biblioteca de proyectos fin de carrera, Universidad Pontificia Comillas, Escuela Tcnica Superior de Ingeniera (ICAI), Madrid, Junio 2004.
2. Snchez Miralles, lvaro y Palacios Hielscher, Rafael. Sistema para el control remoto de un robot
mediante un navegador de Internet (I y II). Revista Anales de mecnica y electricidad. Asociacin de ingenieros del ICAI. Volumen LXXVIII, fascculos II y III. Marzo-Abril y Mayo-Junio 2001.
1 Parte I Memoria ..................................................................................................3
Prlogo ....................................................................................................................4 Captulo 1

1 2 3 4 5
Introduccin....................................................................................6
Estudio de los trabajos / tecnologas existentes ................................................. 7 Motivacin del proyecto .................................................................................... 12 Objetivos............................................................................................................. 15 Metodologa / Solucin desarrollada................................................................ 16 Recursos / herramientas empleadas................................................................. 20
Captulo 2
1 2
Comunicacin Wi-Fi ....................................................................22
Breve introduccin a los sockets, el protocolo TCP/IP y las redes Wi-Fi ..... 22 Desarrollo del software de comunicaciones..................................................... 25
2.1 Pseudocdigo................................................................................................................... 27
Captulo 3
1
Comunicacin Serie......................................................................32
Breve introduccin al funcionamiento de los puertos serie segn norma
RS232........................................................................................................................... 32
1.1 La UART......................................................................................................................... 36 1.2 El control de flujo............................................................................................................ 37
Desarrollo del software de envo de rdenes a travs del puerto serie a la
TCS. ............................................................................................................................. 38
2.1 Pseudocdigo................................................................................................................... 50
Captulo 4
1 2 3
Resultados/Experimentos .............................................................55
Pruebas del software de comunicaciones Wi-Fi: Programa TCPTest.exe ... 56 Pruebas del software de comunicacin por va serie con la TCS .................. 60 Integracin del sistema con la Web desarrollada en el proyecto
complementario y construccin del robot ................................................................ 62
Captulo 5 Captulo 6
Conclusiones .................................................................................66 Futuros desarrollos.......................................................................68
Bibliografa ...........................................................................................................71 Parte II Clculos.............................................................................................72
2 Parte III Parte IV Captulo 1

1
Estudio econmico............................................................................74 Manual de usuario............................................................................77 Creacin y gestin de sockets .......................................................78
Archivos de cabecera (*.h) ................................................................................ 79

1.1 sockapi.h.......................................................................................................................... 79 1.2 socket.h............................................................................................................................ 85 1.3 in.h................................................................................................................................... 86
Captulo 2
1
Configuracin y uso del puerto serie RS232 ...............................89
Archivos de cabecera (*.h) ................................................................................ 90

1.1 serParam.h ....................................................................................................................... 91 1.2 termios.h.......................................................................................................................... 92
Captulo 3
1 2
Entorno de desarrollo ...................................................................98
Compilacin del entorno de desarrollo............................................................ 99 Compilacin y carga de programas en el mdulo......................................... 100

2.1 Compilacin del programa ............................................................................................ 105 2.2 Carga del programa en RAM ........................................................................................ 105 2.3 Carga del programa en Flash ROM............................................................................... 108
Configuracin de los parmetros de la placa de desarrollo y del mdulo.. 109
Parte V Captulo 1
1
Anejos ..............................................................................................110 Cdigo de la aplicacin de comunicacin Wi-Fi.......................111
Cdigo de servidor.c ........................................................................................ 112
Captulo 2
1
Cdigo de la aplicacin completa de control remoto.................116
Cdigo de controlRemoto.c............................................................................. 117
Captulo 3
1
Cdigo de la aplicacin TCPTest.exe ........................................130
Cdigo de TCPTest.cpp .................................................................................. 131
Memoria.
Parte I MEMORIA
Memoria. Prlogo
PRLOGO
Este proyecto forma parte de un concepto conjunto integrado por dos proyectos en total, cuyo objetivo final es lograr desarrollar una plataforma para el control de robots mviles a travs de Internet gracias a las posibilidades ofrecidas por las redes inalmbricas Wi-Fi. El resultado final busca ser una plataforma que permita controlar las evoluciones de un robot mvil inmerso en una red Wi-Fi, envindole rdenes remotas desde Internet a travs de un interfaz Web, a la vez que en ese mismo interfaz se pueden observar fsicamente dichas evoluciones gracias a una cmara de vdeo Web tambin conectada a la red Wi-Fi y gestionada de forma independiente por la Web. Finalmente, se pretende comprobar el buen comportamiento de los resultados obtenidos construyendo un sencillo robot, mediante tecnologa LEGO, que permita mostrar el funcionamiento real de la plataforma. A tal efecto, el proyecto se ha dividido en dos partes diferenciadas de manera natural, a saber, una encargada de la realizacin del interfaz Web y el control de la cmara integrada en el robot, y la otra encargada de la comunicacin del robot con el exterior a travs del enlace Wi-Fi, y de la comunicacin interna entre el mdulo de acceso Wi-Fi y su microprocesador integrado con la tarjeta de control de sensores del robot (en adelante, TCS), a travs de un interfaz serie. El desarrollo de ambos proyectos se ha llevado a cabo de forma coordinada, aunque con planes de trabajo definidos individualmente para cada uno de los dos proyectistas. Sobre todo en el nexo de unin que permite darle cohesin y forma final al conjunto, correspondiente con el objetivo de integrar la Web con el robot, es decir, el establecer un enlace y comunicacin adecuados, creando un pequeo protocolo que permita a la Web enviar rdenes al mdulo y a ste interpretarlas y ejecutarlas. Ambos proyectos han sido dirigidos conjuntamente por D. lvaro Snchez Miralles y D. Rafael Palacios Hielscher, y los proyectistas encargados de cada una de las partes han sido los que siguen:
Memoria. Prlogo
Creacin del interfaz Web y control de la cmara: D. Juan Marn Bernal. Comunicacin Wi-Fi con el exterior y serie interna del robot: D. Jaime Alonso lvarez.
En la presente memoria queda recogido el desarrollo del proyecto correspondiente con las comunicaciones Wi-Fi del robot con el exterior, as como la comunicacin por puerto serie entre el mdulo de comunicaciones y proceso con la TCS. Por todo lo dicho anteriormente, se trata ste de un proyecto de corte innovador, pero partiendo de dos diseos ya establecidos, como son el mdulo Wi-Fi y la TCS, cuyo reto fundamental es adaptar cada uno de ellos, creados en un principio sin intencin de funcionar conjuntamente, para lograr una comunicacin fluida y eficiente entre todas las partes existentes, en principio inconexas. Por tanto, en este proyecto se propicia una aplicacin prctica de gran parte de conocimientos electrnicos adquiridos a lo largo de la carrera, y la relacin de todos ellos para finalmente obtener el resultado deseado. Se aplican conocimientos de electrnica analgica y digital, programacin estructurada y orientada a objetos, estudio e interpretacin de hojas de caractersticas reales, protocolos de comunicaciones informticas, etc. Una parte muy importante del proyecto, como se explicar ms adelante, se ha constituido en un estudio intenso del mdulo Wi-Fi, ya que debido a la ausencia de una buena documentacin por parte del fabricante, se ha dedicado una parte fundamental del tiempo de proyecto en extraer poco a poco informacin de programacin genrica del estudio profundo de cdigos de ejemplo particulares. Esto hace que pase a ser un objetivo principal del proyecto el redactar una buena documentacin/manual para el mdulo que permita retomar con facilidad el trabajo en posibles proyectos futuros.
Memoria. Introduccin
Captulo 1 INTRODUCCIN
En este captulo se hace una introduccin de este proyecto. En la seccin Estudio de los trabajos / tecnologas existentes se aborda una introduccin y un somero anlisis de los desarrollos tecnolgicos actuales, ya sean comerciales o en estudio, as como para desarrollos profesionales, relacionados con el tema del presente proyecto. A partir de ese anlisis se aborda, en la seccin Motivacin del proyecto, las razones que nos llevan a idear este desarrollo y una propuesta global del mismo, concretada en objetivos palpables en el apartado tercero, Objetivos. Finalmente, en las secciones Metodologa / Solucin desarrollada y Recursos / Herramientas empleadas, se detalla a grandes rasgos el proceso seguido para la consecucin final de los objetivos del proyecto, que en captulos posteriores se detallar convenientemente, as como los recursos empleados en ese desarrollo.
1 Estudio de los trabajos / tecnologas existentes

En la actualidad, gracias al amplio desarrollo de las tecnologas de comunicaciones de banda ancha, y en concreto de las conexiones inalmbricas, se estn investigando y poniendo en el mercado gran cantidad de productos aprovechando este hecho, y la robtica mvil no es ajena al mismo. Los beneficios de aunar las tecnologas de comunicacin de banda ancha inalmbricas con los desarrollos en robtica mvil son evidentes, y ello hace que la investigacin en este campo sea intensa y con un amplio espectro de enfoques y posibilidades. Un gran nmero de universidades tanto en Espaa como en el extranjero trabajan en proyectos y diseos similares al que a este proyecto atae, si bien en mltiples ocasiones se trata de plataformas grandes y pesadas, basadas en la adaptacin de recursos inicialmente diseados, por ejemplo para informtica porttil. As, por ejemplo, es comn la utilizacin de tarjetas Wi-Fi PCMCIA para ordenadores porttiles como recurso para acceder a las redes Wi-Fi, y no es raro que se utilicen ordenadores porttiles o PDAs como soportes para albergar el software necesario para gestionar tanto el acceso a la red como el tratamiento de la informacin y el control de los dispositivos del robot. La programacin de estos dispositivos es sencilla, ya que el uso de ordenadores porttiles o PDAs permite programar en lenguajes estndar de alto nivel, pero a cambio obliga a construir robots pesados, poco maniobrables y con grandes bateras y sistemas de alimentacin. Suponiendo que se cuenta desde un principio con los recursos informticos necesarios, este tipo de soluciones son de bajo coste, lo que las hace apropiadas para investigacin, pero sin embargo tienen los elevados inconvenientes constructivos de tener que integrar dispositivos grandes en el diseo, y ello constituye un factor muy negativamente condicionante a la hora de evaluar la posibilidad de xito comercial de dichos proyectos. De igual modo, existen soluciones comerciales muy avanzadas que ofrecen robots autnomos controlados desde Internet, que, al igual que el desarrollado en este proyecto implementan cmaras que permiten al usuario observar los movimientos del robot de forma remota, adems de muchas otras funcionalidades adicionales. Tambin existen soluciones verstiles de bajo coste que permiten conectar dispositivos serie RS232 a Internet de manera que pueden ser controlados de
forma remota. Sin embargo, esta opcin no es inalmbrica, sino que requiere la conexin directa por cable del dispositivo a la red, limitando en gran medida la funcionalidad del robot. Adems, se trata de dispositivos de relativo gran tamao y con una capacidad de proceso limitada, lo que les resta inters, a pesar de su ventaja de bajo coste. Una de estas soluciones es la ofrecida por SitePlayer [1], consistente en un kit de desarrollo (Figura 1) que proporciona un servidor Web el cual puede albergar las pginas que el usuario desee, descargadas al mismo mediante ethernet. Estas pginas pueden utilizarse como interfaz para el control remoto de dispositivos serie (Como por ejemplo microprocesadores o microcontroladores) conectados mediante el protocolo RS232 por una conexin DB-9. Este kit de desarrollo se proporciona acompaado de software y documentacin para facilitar la programacin, y se pueden aadir nuevos mdulos para albergar programas ms extensos. La utilizacin y programacin es sencilla, y el precio es de 99,95 US$. Este kit de desarrollo permite programar varios mdulos SitePlayer, que se pueden adquirir por separado a 29,95 US$ cada uno, pero ya incluye uno preinstalado y tiene la ventaja de llevar incorporados los conectores ethernet y serie, as como la alimentacin a 12V, y una serie de leds y pulsadores que facilitan la tarea de desarrollo. Cada mdulo SitePlayer (Figura 2) es de pequeo tamao (23 x 33 mm), cuenta con 48 Kbytes de espacio para albergar las pginas Web y puede utilizarse por separado, eso s, aadiendo el pertinente conector ethernet y el serie si fuese necesario, y se alimenta a 5V. Puede utilizarse tanto como cliente como servidor, soporta transmisin de datos binarios por protocolos TCP/IP y UDP, longitudes de datos de 7 u 8 bits, baudrates entre 50 y 115000 baudios, diferentes controles de paridad, etc., por lo que en principio resulta verstil. Sin embargo, tiene el principal inconveniente de precisar un enlace por cable ethernet RJ45 que limita enormemente sus aplicaciones.
Figura 1: SitePlayer development kit
Figura 2: Mdulo SitePlayer
En lo que a las soluciones comerciales avanzadas ya mencionadas anteriormente, las funcionalidades son ms similares a las que en este proyecto se persiguen, pero a un precio enormemente elevado, que las hace slo asequibles por un segmento muy reducido del mercado. Sirvan como ejemplo de este hecho los modelos que se detallan a continuacin. La empresa Dr Robot [2] proporciona todo tipo de soluciones para la construccin de robots mviles, tanto a nivel de componentes como de robots ya completos. A modo de ejemplo, mostramos dos robots ya montados, ilustrando su funcionalidad y precio. Debe tenerse en cuenta que todos los componentes de dichos robots pueden adquirirse por separado, pero ello incrementa el coste total del montaje. El modelo X80 (Figura 3) tiene un peso de 3,5 Kg., puede llevar hasta una carga adicional de 10 Kg., y alcanza una velocidad mxima de 1 m/s, propulsado por dos motores de 12V. Puede conectarse a una red Wi-Fi 802.11b, y ofrece captacin y transmisin de imgenes y sonidos, sensores y encoders preinstalados con posibilidad de ampliacin para necesidades especficas. Sus dimensiones son
10
38 cm. de dimetro y 25,5 cm. de altura. Viene complementado por software de desarrollo de aplicaciones y documentacin para adaptarlo a necesidades especficas, y es compatible con lenguajes y entornos estndar como Microsoft Visual Basic y Visual C++. Puede complementar su capacidad de proceso con la instalacin de un ordenador porttil en una plataforma destinada a tal efecto, gracias a su capacidad de carga. Por tanto, nos encontramos ante una solucin excelente, verstil, destinada al desarrollo de aplicaciones por ejemplo en universidades, pero quiz excesiva en tamao y de elevado coste: 2550 CAD$.
Figura 3: X80 de Dr Robot
Otro modelo ofrecido por la misma empresa es el DRK8080 (Figura 4), una solucin con prestaciones y contenido similares a la anterior, pero que adems ya ofrece avances en materia de esttica, como aspecto de humanoide. Contina siendo configurable y programable para aplicaciones especficas ideadas por el usuario, y compatible con entornos de desarrollo estndar como los antes mencionados de Microsoft. Sin embargo, nuevamente el precio es un gran inconveniente: 2950 CAD$.
Figura 4: DRK8080 de Dr Robot
11
La empresa ActivMedia Robotics [3] ofrece diferentes soluciones robticas ya montadas y funcionando, aunque configurables a travs de cualquier compilador C/C++ y un puerto serie. Una de ellas es el AmigoBot [4] (Figura 5), que como es habitual, ofrece la posibilidad de ser controlado a travs de una red inalmbrica, un puerto serie libre para poder ampliar sus funcionalidades, soluciones sensoriales integradas, sistemas de adquisicin de audio y vdeo, programas de control ya diseados y funcionando, y posibilidad de crear nuevas aplicaciones, en definitiva, similar a las dos alternativas antes presentadas, y a un precio del mismo modo elevado: el kit completo, que incluye las funcionalidades de control va WiFi, cmara de vdeo y software de control, as como APIs para diferentes funciones, tiene un precio de 3195 US$.
Figura 5: AmigoBot de ActivMedia Robotics
12
2 Motivacin del proyecto

A la vista de los desarrollos y tecnologas ya existentes, tanto puramente comerciales como orientadas al desarrollo y la investigacin, por ejemplo en universidades, se plantea la existencia de una evidente carencia de posibilidades de eleccin y de gama entre las opciones existentes. Esto es, se han desarrollado componentes y modelos a nivel bsico, con poca capacidad de proceso y funcionalidad muy limitada, como es el caso del primer kit comentado en el apartado anterior, y desde este nivel bsico en funcionalidad y precio, se pasa a un estatus muy alto, con productos muy funcionales y configurables, con gran cantidad de posibilidades y de alta tecnologa, pero de muy elevado precio. Este precio no est justificado en muchos casos, ya que es muy posible que existan potenciales clientes que no vayan a utilizar todo ese abanico de funciones, y que por el contrario, prefieran contar con una plataforma ms bsica (Y por tanto de precio ms ajustado) con funciones adaptadas a sus necesidades y totalmente configurable, tanto en el mbito electrnico (Sensores presentes, disposicin de los mismos, programacin de comportamientos especficos) como en el mecnico, ofreciendo el kit electrnico perfectamente operativo, y dejando total libertad al usuario para acomodarlo en el robot que mejor cubra sus necesidades. Con este razonamiento, y partiendo de la idea general reflejada en el artculo [10], se hace necesario el hecho de crear una plataforma de control de robots mviles a travs de una red Wi-Fi, en una posicin intermedia entre las alternativas comerciales ya comentadas. Aprovechando la tarjeta de control de sensores (TCS) desarrollada en esta misma universidad el pasado ao [5] (Versin de 2 PICs), que ofrece muchas posibilidades para controlar sensores de todo tipo, servos, motores, etc., a eleccin del usuario, la solucin para el control de robots va red inalmbrica est servida si se dota a esta tarjeta de una va de comunicacin con el exterior por Wi-Fi. A tal efecto se considera oportuno el ampliar la plataforma con un pequeo mdulo capaz de albergar un servidor embebido y un microprocesador, con capacidad de conexin Wi-Fi. As, en poco espacio logramos dotar de una gran funcionalidad al conjunto de TCS + mdulo. Dicho mdulo ser capaz de recibir rdenes de un usuario remoto a travs de la red WiFi, y gracias a su microprocesador, podr interpretarlas y transmitirlas a travs del puerto RS232 a la TCS, que se encargar de ejecutarlas fsicamente.
13
Si adems aadimos a esta verstil plataforma un interfaz Web a travs del cual el usuario pueda enviar sus rdenes al robot, y a la vez monitorizar sus evoluciones gracias a una cmara Wi-Fi integrada en el cuerpo del robot y controlada por ese mismo interfaz Web, tenemos una plataforma completa para el control remoto de robots mviles. Esta solucin barata respecto a las soluciones ya existentes, y con suficiente funcionalidad y capacidad de configuracin a las necesidades propias de cada usuario. El esquema general de funcionamiento del conjunto a desarrollar se muestra en la Figura 6:
Figura 6: Esquema de concepto
Con este sistema se hace muy sencillo el llevar a cabo desarrollos de tele presencia, monitorizacin de entornos remotos y potencialmente peligrosos (Por ejemplo, podra utilizarse como explorador de estructuras inestables, de incendios, entornos contaminados qumica y/o biolgicamente, etc.), control y vigilancia remota (por ejemplo de almacenes), cuidado de ancianos o nios solos en casa, etc. En definitiva, abre una gran cantidad de posibilidades en cuanto a desarrollo de aplicaciones de tele presencia y tele vigilancia a un precio ajustado y sin necesidad, salvo para aplicaciones especiales, de asumir largos y costosos desarrollos de programacin de software de comunicaciones y de una pgina Web
14
para el control del robot, ya que toda la comunicacin inalmbrica entre el robot y el exterior, as como la comunicacin interna (va serie) est solucionada desde un principio. De esta manera la comunicacin entre el usuario conectado a Internet y el robot se convierte en algo directo y transparente, sin tener que prestar atencin a toda la labor de comunicacin intermedia, protocolos, puertos, etc., ya completamente integrada y operativa desde un principio.
15
3 Objetivos
Para lograr la consecucin y el desarrollo final del proyecto, se han establecido los siguientes objetivos: Desarrollo de un sistema que permita controlar un robot mvil integrado en una red inalmbrica Wi-Fi desde un PC remoto conectado a Internet. Implementacin fsica del sistema en una plataforma mecnica LEGO a modo de ejemplo. Documentacin exhaustiva y redaccin de un manual de usuario completo para la utilizacin y ampliacin futura de la plataforma.
16
4 Metodologa / Solucin desarrollada

Para dotar de conexin a redes Wi-Fi al robot, se escogi una solucin proporcionada por la empresa Digi International [6], consistente en un pequeo mdulo que integra al mismo tiempo un dispositivo de cliente a redes Wi-Fi 802.11b, con una velocidad de transferencia mxima terica de 11 Mbit/s y un alcance de hasta 100 m, y un microprocesador Netsilicon Net+ARM de 32 bits modelo NS7520, con 4 MB de memoria Flash y 8 MB de memoria RAM. Este mdulo cuenta adems con dos puertos serie de alta velocidad. Estas caractersticas lo hacen idneo para nuestras aspiraciones, ya que en muy pequeo espacio y con poco consumo, algo muy importante para la autonoma energtica de los futuros desarrollos basados en este proyecto, podemos incorporar el acceso y comunicacin a redes inalmbricas, la capacidad de proceso y almacenamiento necesarias para poder implementar los comportamientos y habilidades de que se quiera dotar al robot, y un interfaz serie estndar para poder finalmente comunicarse con la tarjeta de control de sensores sin problemas. El nombre comercial del mdulo es Digi Connect Wi-ME (Figura 7), y se adquiri en conjunto con un kit de desarrollo que permitiese implementar en l nuestro propio software. Para ello, el mdulo cuenta con un interfaz JTAG que permite descargar en l los programas realizados. El kit de desarrollo (Digi Connect Wi-ME Development Kit) cuenta, adems del propio mdulo con una placa de desarrollo que facilita el acceso a los diferentes puertos, y el conexionado y alimentacin del mdulo, as como las labores de prueba y depuracin del software. Con este kit se incluye un entorno de desarrollo especfico y los cables y conexiones necesarias para el correcto funcionamiento del kit. Asimismo, se incluyen programas de ejemplo y documentacin, todo con licencia GNU. Sin embargo, durante el desarrollo del proyecto se ha podido comprobar que la documentacin proporcionada es muy escasa, catica y poco aclaradora, dejndose todo el trabajo al desarrollador mediante el desglose y anlisis de los programas de ejemplo, parcos en comentarios y aclaraciones sobre el uso y utilidad de funciones, variables, parmetros, etc. Ello ha propiciado que la mayor parte del tiempo dedicado al presente proyecto se enfocase al estudio de los ejemplos, tratando de deducir las generalidades de uso de las funciones y parmetros, de manera que fuese posible desarrollar a posteriori un software personalizado y adecuado a
17
nuestras necesidades. En la presente memoria, se dedicar un esfuerzo importante a documentar la utilizacin de las herramientas de programacin correspondientes al uso y configuracin de sockets y puertos serie en este mdulo en concreto, como medio de suplir las carencias de documentacin del fabricante para facilitar el retomar el trabajo desde una posicin avanzada a futuros proyectistas.
Figura 7: Mdulo Digi Connect Wi-ME
Una vez comprendida la forma de utilizar las diferentes APIs para la gestin de sockets y puerto serie, se pas a desarrollar el software pertinente que, como se expondr en captulos sucesivos, bsicamente consiste en un servidor albergado en el mdulo que constantemente se mantiene a la escucha hasta recibir una peticin de conexin desde un PC cliente. Una vez establecida la conexin, el mdulo recibe las rdenes, las procesa, las traduce a un lenguaje comprensible por la TCS segn el protocolo definido en [5], captulo 3.2, y las enva a la TCS a travs del puerto serie, que ejecuta finalmente las instrucciones recibidas. Como es de suponer, al tener que integrar el mdulo con la placa TCS ya desarrollada anteriormente, paralelamente al desarrollo del software, se llev a cabo el estudio de los apartados necesarios recogidos en [5], vase, protocolo de comunicacin con los dos PICs de la TCS, parmetros de configuracin del puerto serie, metodologa de acceso a cada uno de los PICs, etc. A grandes rasgos, los pasos seguidos para completar estos objetivos han sido los siguientes:
Memoria. Introduccin COMUNICACIN Wi-Fi:
18
Estudio del kit de desarrollo Wi-Fi, familiarizacin con el entorno de desarrollo, compilador, descarga y ejecucin de programas en el mdulo, etc.
Estudio pormenorizado de programas de ejemplo para establecimiento de comunicacin Wi-Fi. Comprensin de las APIs correspondientes. Documentacin bsica acerca del funcionamiento y programacin de un sencillo servidor. Funcionamiento y establecimiento de conexiones por sockets TCP/IP.
Escritura de un sencillo programa para el mdulo que le permita actuar como servidor, aceptar conexiones, recibir datos desde un PC cliente, enviar la confirmacin de recepcin y mostrar los resultados por pantalla.
Creacin de un programa para un PC en Microsoft Visual C++ que permita establecer una conexin TCP/IP ya sea como servidor o como cliente y enviar y recibir datos, de modo que pueda comprobarse el funcionamiento de la red y en concreto, como medio para monitorizar y comprobar el buen funcionamiento del programa servidor del mdulo.
Depuracin de ambos programas hasta lograr el establecimiento fiable y estable de la conexin.
COMUNICACIN SERIE: Estudio pormenorizado de programas de ejemplo para la apertura, configuracin y gestin del puerto serie del mdulo. Comprensin del funcionamiento de los puertos serie. Estudio del protocolo de comunicacin con la TCS, as como de los parmetros de configuracin del puerto serie con los que se trabaja, a fin de integrar y comunicar el mdulo Wi-Fi y la TCS. Ampliacin del programa servidor con las funcionalidades de
comunicacin va serie con la TCS. Recepcin de rdenes remotas,
19
conversin segn protocolo de comunicacin definido en [5], captulo 3, y envo a la TCS. Depuracin del programa y comprobacin de la buena integracin de mdulo y TCS. Construccin de un sencillo robot en plataforma mecnica LEGO como banco de pruebas para el desarrollo. Integracin del robot con el interfaz Web y la cmara. Pruebas de conexin. Documentacin: redaccin del resumen y memoria del proyecto.
En la Tabla 1 se muestra la distribucin temporal de las actividades fundamentales llevadas a cabo en el presente proyecto:
Tabla 1: Distribucin temporal de actividades
20
5 Recursos / herramientas empleadas

El proyecto se ha realizado a caballo entre el lugar de residencia del proyectista, donde se llev a cabo la labor de documentacin y desarrollo del software, y un puesto de trabajo sito en el Instituto de Investigacin Tecnolgica (IIT), donde se realizaron todas las pruebas de funcionamiento e integracin de lo desarrollado. El material y recursos empleados en la realizacin de este proyecto se detallan a continuacin: Digi Connect Wi-ME Development Kit (GNU). Referencia Internacional: DC-WME-01T-GN. (Figura 8) Ver [6].
Figura 8: Mdulo Digi Connect Wi-ME
Cable Interfaz para depuracin y programacin OCDemon de Macraigor Systems [8] para ARM7, JTAG de 14 pines (Figura 9).
Figura 9: OCDemon de Macraigor Systems
Tarjeta de Control de Sensores (TCS). Versin de 2 PICs (Figura 10). Ver [5].
21
Figura 10: Tarjeta de Control de Sensores (TCS) Versin 2 PICs
Microsoft Visual C++ 6.0 jGRASP versin 1.8.0 Beta 3 (Edicin de cdigo fuente). Ver [7]. Osciloscopio digital. Red Inalmbrica Wi-Fi del Instituto de Investigacin Tecnolgica (IIT). Punto de acceso Wi-Fi. Piezas de LEGO. Motores Elctricos Technic Mini-Motor 9V. Adaptador de corriente universal para la TCS. PC y puesto de trabajo en el IIT. PC Porttil. Cables de conexin serie.
Memoria. Comunicacin Wi-Fi
22
Captulo 2 COMUNICACIN WI-FI

En este captulo se desarrolla la metodologa y programas utilizados para implementar y establecer la comunicacin del mdulo de control del robot con el PC cliente desde el cual el usuario monitoriza y controla sus evoluciones. En Captulo 1 se incluye la documentacin necesaria para comprender y utilizar las APIs proporcionadas junto con el entorno de desarrollo en lo que a creacin y gestin de sockets se refiere.
1 Breve introduccin a los sockets, el protocolo TCP/IP y las redes Wi-Fi

Una aplicacin servidor normalmente escucha a un puerto especfico esperando una peticin de conexin de un cliente. Cuando llega una peticin de conexin, el cliente y el servidor establecen una conexin dedicada sobre la que poder intercambiar informacin mediante un protocolo que previamente han acordado. Durante el proceso de conexin, el cliente es asignado a un nmero de puerto, y ata un socket a ella. El cliente habla al servidor escribiendo sobre el socket y obtiene informacin del servidor cuando lee de l. Por tanto, puede definirse un socket como un punto final de un enlace de comunicacin de dos vas entre dos programas que se ejecutan a travs de la red. El cliente y el servidor deben ponerse de acuerdo sobre el protocolo, esto es, deben ponerse de acuerdo en el lenguaje para transferir la informacin de vuelta a travs del socket. TCP/IP es el protocolo de bajo nivel. El nombre TCP/IP proviene de dos de los protocolos ms importantes de la familia de protocolos Internet, el Transmission Control Protocol (TCP) y el Internet Protocol (IP). La principal virtud de TCP/IP estriba en que est diseado para enlazar ordenadores de diferentes tipos, incluyendo PCs, minis y mainframes que ejecuten sistemas operativos distintos sobre redes de rea local y redes de rea extensa y, por tanto, permite la conexin de equipos distantes geogrficamente. Internet se encuentra estrechamente unida a un sistema de
23
protocolo de comunicacin denominado TCP/IP (Transmission Control Protocol/ Internet Protocol). TCP/IP es el nombre de un protocolo de conexin de redes. Un protocolo es un conjunto de reglas a las que se tienen que atener todas la compaas y productos de software con el fin de que todos sus productos sean compatibles entre ellos. Estas reglas aseguran, por ejemplo, que una mquina que ejecuta la versin TCP/IP de Digital Equipment pueda hablar con un PC Compaq que ejecuta TCP/IP. TCP/IP es un protocolo abierto, lo que significa que se publican todos los aspectos concretos del protocolo y cualquiera los puede implementar. TCP/IP esta diseado para ser un componente de una red, principalmente de la parte del software. Todas las partes del protocolo de la familia TCP/IP tienen unas tareas asignadas, como enviar correo electrnico, proporcionar un servicio de acceso remoto, transferir ficheros, asignar rutas a los mensajes o gestionar cadas de la red. Una red TCP/IP transfiere datos mediante el ensamblaje de bloque de datos en paquetes. Cada paquete comienza con una cabecera que contiene informacin de control, tal como la direccin del destino, seguida de los datos. Cuando se enva un archivo a travs de una red TCP/IP, su contenido se enva utilizando una serie de paquetes diferentes. El protocolo TCP es un protocolo de transporte, es decir, controla el movimiento de datos entre dos mquinas. Se trata de un servicio basado en una conexin, lo que significa que las mquinas que envan y reciben datos estn conectadas y se comunican entre ellas en todo momento. Si una de ellas se desconecta, la otra queda en espera hasta que la desconectada vuelva a enviar datos. De esta manera se garantiza que lleguen todos los datos y que esos datos lleguen correctamente, a diferencia del protocolo UDP (User Datagram Protocol), que es un servicio sin conexin, eso es, que los datos se envan aunque no haya una conexin entre las mquinas, con lo cual se garantiza que los datos lleguen correctamente de haber conexin, pero no se asegura que lleguen todos los datos. El protocolo IP es un protocolo de rutas, es decir, gestiona el direccionamiento de los datos. La direccin IP de un equipo es su identificacin unvoca dentro de una red TCP/IP.
24
En el presente proyecto, la va de acceso a la red de comunicaciones es la comercialmente denominada Wi-Fi, segn el estndar denominado IEEE 802.11b. Se trata ste de un sistema de comunicaciones inalmbricas va radio. El estndar 802.11b trabaja en una banda de 2,4GHz, y es capaz de transmitir datos a una velocidad terica de 11Mbps, que supera con creces los requerimientos de la presente aplicacin en lo que a capacidad de transmisin de datos se refiere. Se trata del estndar que ms equipos utilizan en la actualidad, y es totalmente compatible con un nuevo estndar, el 802.11g, ms rpido, que est ganando terreno en la actualidad. Por tanto, la eleccin de este estndar nos proporciona una velocidad de transmisin de datos adecuada a nuestras necesidades, y una compatibilidad muy amplia, para facilitar el uso de la plataforma de control desarrollada en casi cualquier red inalmbrica que necesitemos. El estndar 802.11b utiliza la tecnologa DSSS (Direct Sequence Spread Spectrum o Espectro Amplio Mediante Secuencia Directa), la cual, a diferencia de la tcnica de transmisin de Espectro Amplio (Spread Spectrum) FHSS, no precisa enviar la informacin a travs de varias frecuencias sino mediante transmisores; cada transmisor agrega bits adicionales a los paquetes de informacin y nicamente el receptor que conoce el algoritmo de estos bits adicionales es capaz de descifrar los datos. Es precisamente el uso de estos bits adicionales lo que permite a DSSS transmitir informacin a 10Mbps y una distancia mxima entre transmisores de unos 100 metros.
25
2 Desarrollo del software de comunicaciones

La programacin implementada en el mdulo, en lo que a su conexin a red se refiere, se identifica con un sencillo servidor. El concepto bsico es sencillo: al iniciarse el programa, el mdulo abre un socket y lo ata a un puerto dado. Desde ese momento, se queda a la escucha en ese puerto, hasta que recibe una solicitud de conexin por parte de un PC cliente. En el momento en que el cliente se conecta, se acepta esa conexin y comienza el intercambio de informacin en forma de cadenas de 32 caracteres como mximo (El nmero de caracteres mximo se ha establecido de manera arbitraria, para asegurar que se puede transmitir siempre la informacin necesaria, pero no necesariamente tiene que utilizarse este tamao de cadena). El mdulo recibe lo enviado por el cliente, y si la recepcin es satisfactoria, enva al cliente una cadena de caracteres a modo de confirmacin de la recepcin, y muestra lo recibido por pantalla. Se trata, pues, de un sencillo servidor que slo puede gestionar un cliente a la vez (Es factible realizarlo para ms de una conexin simultnea. Ver Parte IV Captulo 1 1). Esto, sin embargo, es coherente con el objeto del proyecto, dado que no tiene sentido prctico que ms de un mismo usuario a la vez est conectado al robot para tele controlarlo. Por ello, para lograr la funcionalidad requerida, es suficiente con establecer y mantener una nica conexin bidireccional con un nico cliente, rechazando todas las que lleguen posteriormente, si es el caso, ya que el robot slo puede ser controlado a la vez por un nico usuario. De lo contrario, las intenciones de diferentes usuarios a la vez, podran dar lugar a rdenes contradictorias y conflictos innecesarios en la informacin transmitida al robot. En la Figura 11, se muestra el diagrama de flujo correspondiente a este programa de prueba de la comunicacin a travs de la red inalmbrica, actuando el mdulo como un sencillo servidor capaz de establecer comunicacin con un nico cliente a la vez. Se observa que, consecuentemente con lo mencionado en el apartado 1 del presente captulo acerca del protocolo TCP, el servidor no enva nada al cliente hasta haber recibido correctamente lo que aqul enva, como modo de asegurar que existe realmente conexin con el cliente y que ste est esperando su respuesta. As no se pierde nada de informacin en ningn momento.

Abrir Socket
26
Atar Puerto
Ponerse a la escucha
Peticin de conexin?
No
S Aceptar la conexin
Recibir datos
Recepcin OK?
No
S Enviar confirmacin
Mostrar datos recibidos por pantalla
Figura 11: Diagrama de flujo del servidor
27
Cabe hacer notar que el programa descrito en este apartado no es ms que un medio de probar que la conexin funciona correctamente. El representar en pantalla lo recibido desde el cliente y el nmero de bytes enviados y recibidos es, simplemente, una forma de monitorizar que todo ha resultado como lo esperado, que llegan todos los datos y se interpretan de forma correcta. Obviamente, una vez finalizada la depuracin e implementado el sistema en el robot, estas salidas por pantalla no tienen sentido y pueden ser eliminadas del cdigo, al constituir una carga de proceso innecesaria.
2.1 Pseudocdigo Antes de proceder a detallar en forma de pseudocdigo el programa desarrollado para comprobar la funcionalidad de la comunicacin en red, ha de justificarse la metodologa de programacin utilizada. En este caso, dada la sencillez del algoritmo a programar, no se ha juzgado necesario, pese a ser posible, el utilizar programacin orientada a objetos, sino que se desarroll utilizando programacin estructurada. En casos de esta sencillez facilita tanto la programacin como la comprensin del algoritmo, que aparece programado de manera directa a partir de lo representado en el diagrama de flujo, sin necesidad de realizar abstracciones de ningn tipo. La programacin orientada a objetos estara ms recomendada en caso de precisar, por ejemplo, una cierta estandarizacin, esto es, para poder recibir diferentes tipos de datos a travs del enlace inalmbrico, interpretarlos de diferente manera, etc. Sin embargo, en el caso que nos concierne, los datos a enviar y recibir a travs del enlace se corresponden con un protocolo fijo y cerrado, no necesariamente conocido por el usuario, que no tiene que preocuparse de qu o cmo se manda. Por ello, el formato de datos ser siempre el mismo, y ello permite utilizar sin problemas una metodologa de programacin estructurada. El lenguaje utilizado es C, con las particularidades propias de este entorno de desarrollo en concreto, y utilizando las APIs proporcionadas, por ejemplo, para gestin de sockets, y que se detallan ms adelante en los anejos destinados a la documentacin para programacin de este mdulo (Parte IV).
Memoria. Comunicacin Wi-Fi 2.1.1 Cdigo de servidor.c
28
Este archivo contiene el cdigo ntegro del programa de prueba del servidor embebido en el mdulo. La funcin principal se denomina servidor, y es la que arranca directamente el hilo de proceso. En ella vienen dadas la direccin IP del servidor (En formato estndar, es decir, una cadena de caracteres en las que los cuatro grupos de nmeros van separados por puntos) y el puerto a travs del cual se establecer la conexin, como nmero entero. Estos dos parmetros deben chequearse antes de compilar el programa y cargarlo en la memoria del mdulo para asegurarse de que se corresponden realmente con lo establecido en esa concreta, es decir, que la direccin IP es la que tiene asignada el mdulo en la red y que el puerto a utilizar est realmente libre. Con esos datos, la funcin servidor da paso al cuerpo del programa, donde realmente se ejecuta el cdigo del servidor, que es la funcin TCPsend, la cual devuelve un entero por si se desease hacer control de errores. Si la creacin del socket es exitosa, esta funcin entrar en un bucle infinito de envo y recepcin de datos, y no devolver ya el control a no ser que haya un error. Si se produjese un error, el mdulo debera ser reinicializado, ya que no es posible liberar el puerto atado al socket que se crea, de manera que aunque se cierre el socket, el puerto queda reservado y no puede volver a utilizarse hasta que se reinicie el programa. Esto es un grave inconveniente, ya que en caso de perderse la conexin, efectuar un reset es imprescindible y no hay solucin de programacin para ello, ya que no es asumible el reservar un nuevo puerto cada vez que se perdiese la conexin, que sera lo nico que evitara el reset. Otros sistemas operativos, como Windows, s que automticamente liberan el puerto al cerrar el socket, pero ste no es el caso. A continuacin se muestran los pseudocdigos de ambas funciones (Nota: para informacin detallada de todas las funciones utilizadas y sus parmetros, acudir al Manual del Usuario, Parte IV):
29
Funcin TCPsend:
int TCPsend(const char *sHost, int iPort, char * sDatos){
int sock;
; Crear descriptor del socket
struct sockaddr_in
fsin;
;Crear estructura para almacenar la direccin donde se crear el socket
sock = socket(familia de protocolos + tipo TCP);
;Abrir el socket TCP
;Si hay error al abrir el socket, se aborta la ejecucin
memset((void *)&fsin, 0, sizeof(fsin));
;Se reserva memoria para la direccin del socket
;Configurar la direccin del socket con la familia de protocolo, una direccin IP genrica y el puerto
Bind (descriptor del socket + direccin); ;Atamos el socket al puerto correspondiente ;Si hay error al atar el puerto, cerramos el socket y abortamos la ejecucin
Listen(Descriptor
del socket); ;Ponerse a la escucha en el socket
int acceptsock = socket(familia de protocolos + tipo TCP); ;Crear descriptor de socket auxiliar necesario para aceptar la nueva conexin ;Esperamos a que haya una peticin de conexin y la aceptamos
while (1) {
;Iniciamos bucle infinito para esperar al cliente
acceptsock = SOCKET_ERROR; while ( acceptsock == SOCKET_ERROR ) { ;Intentar la conexin hasta que haya xito

acceptsock = accept( sock, NULL, NULL ); } printf( "Client Connected.\n"); sock = acceptsock; ;Asignamos al socket general el que ya tiene conexin break; } ;Con el cliente ya conectado, salimos del bucle infinito
30
;Crear las variables para controlar la cantidad de datos enviados y recibidos y la cadena de caracteres para almacenar lo enviado desde el cliente int bytesSent; int bytesRecv = SOCKET_ERROR; char recvbuf[32] = ""; ;Cadena inicializada vaca
while(1){
;Bucle infinito para la recepcin y envo contnuo de datos a travs del socket
bytesRecv = recv( sock, recvbuf, 32, 0 ); ;Recibir los datos if(bytesRecv!=-1){; ;Slo si se reciben datos
printf (Datos recibidos); ;Mostrar lo recibido ;Enviar confirmacin al cliente bytesSent = send( sock, sDatos, strlen(sDatos), 0 ); } } ;Fin del bucle infinito. Slo se pasa de aqu si hay algn problema ;Como ha habido problema, se cierra el socket
close (sock);
return; ;Devolvemos el control. Se requerir un reset del programa para volver a establecer una conexin sin reservar nuevos puertos } ;Fin del cdigo del servidor embebido en el mdulo
Funcin servidor
void servidor(ULONG thread_input){ ;Aplicacin principal que arranca al iniciarse el hilo de proceso char sHost[16]="190.206.71.20"; ;Direccin IP del mdulo en la red (servidor)

char sDatos[32]="Recibido OK"; ;Datos a enviar en la confirmacin de recepcin al cliente
31
int iPort=1234;
;Puerto en el que escuchar
while(1){
;Bucle infinito, slo funcin decorativa, ya que si TCPsend devuelve el control, se requerir indefectiblemente un reset del sistema
TCPsend((const char *)sHost, iPort, sDatos);
} return; } ;Fin de la funcin principal
Memoria. Comunicacin Serie
32
Captulo 3 COMUNICACIN SERIE

En este captulo se desarrolla la metodologa y programas utilizados para posibilitar que las rdenes recibidas por va Wi-Fi segn lo desarrollado en el captulo anterior, lleguen a la Tarjeta de Control de Sensores con un formato entendible por la misma (Segn protocolo de comunicacin definido en [5]), de manera que sta sea capaz de ejecutarlas. El medio de comunicacin entre el mdulo Wi-Fi y la TCS es un puerto serie RS232. En Parte IV Captulo 2, se detallar el funcionamiento y utilizacin de las APIs que para gestin de puertos serie se proporcionan con el kit de desarrollo Wi-Fi.
1 Breve introduccin al funcionamiento de los puertos serie segn norma RS232

La comunicacin de datos en un puerto serie, se usa normalmente para efectuar comunicaciones asncronas, es decir, sin tiempo preestablecido para iniciarse, a saber, los datos llegan en rfagas o paquetes de informacin. Normalmente cada paquete es de 8 bits (1 byte, equivalente a un carcter en cdigo ASCII), algunos equipos envan carcter por carcter, otros guardan muchos caracteres en la memoria y cuando les toca enviarlos, los envan uno tras otro. Uno de los parmetros ms importantes en la comunicacin serie, es la velocidad con la que los datos se transmiten, para el caso del RS232, pueden transmitir de los 300 Baudios (1 Baudio = 1 bit/seg) hasta 115,200 Baudios. La velocidad depende de los equipos conectados en el puerto serie y la calidad y longitud de los cables. Otro de los parmetros de trascendencia es el bit de inicio, es decir, el bit que le indica al puerto receptor que va a llegar un Byte de informacin. El nmero de bits que se emplean para cada paquete, pueden ser 5, 6, 7 u 8. Es as como la comunicacin serie RS232 es la comunicacin de datos ms empleada en el mundo, ya que utiliza pocos cables para lograrlo y mediante los mdems, es la forma de intercomunicar computadoras, comunicarse a travs de Internet, control a distancia y muchas otras aplicaciones.
Memoria. Comunicacin Serie Los valores elctricos para los circuitos RS232 son:
33
Valor Mximo: 25 V / Valor Mnimo: -25 V / Valor ptimo: -9,-14 V (Se considera valor 0 los valores comprendidos entre -3 V y +3 V) Las seales con las que trabaja este puerto serie son digitales, de aproximadamente +15V (0 lgico) y -15V (1 lgico), para la entrada y salida de datos, y a la inversa en las seales de control. Si no se est transmitiendo ningn carcter, la lnea est en un estado alto, mientras que si se transmite algn carcter estar en estado bajo. Una vez que ha comenzado la transmisin de un dato, los bits tienen que llegar uno detrs de otro a una velocidad constante y en determinados instantes de tiempo. Por eso se dice que el RS232 es asncrono por carcter y sncrono por bit. Se envan los datos empezando por el bit menos significativo y terminando por el ms significativo. Seguidamente, vendr el bit denominado bit de paridad, utilizado para detectar errores en la transmisin. Este bit se puede controlar de forma par o impar, o simplemente, no se controla la paridad. Para finalizar aparece el llamado bit de parada o stop, el cual seala el final de la transmisin de un carcter. El protocolo permite para este bit tres valores: 1, 1.5 2. El bit de parada siempre est en estado alto. Los pines que portan los datos son RXD y TXD. Los dems se encargan de otros trabajos: DTR indica que el ordenador est encendido, DSR que el aparato conectado a dicho puerto esta encendido, RTS que el ordenador puede recibir datos (porque no esta ocupado), CTS que el aparato conectado puede recibir datos, y DCD detecta que existe una comunicacin, presencia de datos. Tanto el aparato a conectar como el ordenador (o el programa terminal) tienen que usar el mismo protocolo serie para comunicarse entre si. Puesto que el estndar RS232 no permite indicar en qu modo se est trabajando, es el usuario quien tiene que decidirlo y configurar ambas partes. Por lo tanto para conseguir una transmisin con el puerto serie debemos seleccionar una serie de parmetros como: Velocidad: Expresada en baudios o bps (bits por segundo). Bits de datos (5, 6, 7 u 8): Nmero de bits usados en la transmisin.
34
Paridad (Par, impar o sin control de paridad): Tipo de control de errores y deteccin de los mismos.
Bit de parada (1, 1.5, 2): Indicar el final del carcter enviado.
Los conectores utilizados para las conexiones por puerto serie, pueden ser de 25 9 pines. En el presente proyecto, se utilizar el conector de 9 pines, DB-9 (Figura 12), ya que es ms barato, est ms extendido, y para nuestra comunicacin slo ser necesario utilizar tres pines, por lo que utilizar el conector de 25 pines no estara justificado en ningn caso.
Figura 12: Conectores DB-9 macho y hembra
En el puerto serie siempre se cumple que: Para un conector de 9 pines, toda mquina en estado de actividad tiene una lgica negativa en tres circuitos: 3, 7 y 4.
Memoria. Comunicacin Serie La Tabla 2 muestra la asignacin de pines en un conector DB-9:
35
Nmero de Pin 1 3 2 7 8 6 5 1 4 9
Seal TxD RxD RTS CTS DSR SG
Descripcin Masa chasis Transmit Data Receive Data Request To Send Clear To Send Data Set Ready Signal Ground
E/S S E S E E E S E
CD/DCD (Data) Carrier Detect DTR RI Data Terminal Ready Ring Indicator
Tabla 2: Asignacin de pines
Segn su funcionalidad, los pines pueden agruparse en: Grupo de datos: controlan la recepcin y envo de datos. Pines 3 y 2 del conector DB-9. Grupo de control: realizan determinados controles en la lnea y el dispositivo. Pines 7, 8, 6, 1, 2 y 9 del DB-9. Grupo de referencia: realizan un control elctrico de los dems circuitos durante la transmisin. Pin 5 del DB-9.
36
En la Figura 13 se muestra el sentido de los flujos de informacin en una conexin entre dos equipos va serie RS232:
Figura 13: Flujos de informacin en comunicacin serie
El DTE (Equipo terminal de Datos) lleva instalado el conector macho y el DCE (Equipo de Comunicacin de Datos) dispone del conector hembra.
1.1 La UART La UART (Universal Asynchronous Receiver Transmitter, Transmisor receptor asncrono universal) es un chip que rige todas las acciones a travs del puerto serie. Controla en todo momento las circunstancias de la transmisin as como la deteccin de los posibles errores que puedan ocurrir. Su funcionamiento (Figura 14): Si se quiere enviar un carcter cualquiera por la lnea de datos, se transfiere en primer lugar a un registro denominado THR (Transmisin Holding Register). En este registro se almacena el carcter hasta que ha sido completamente procesado el carcter enviado anteriormente. Completada esta fase se transfiere el carcter al registro TSR (Transmisin Shift Register) donde la UART lo enviar bit a bit a la lnea de datos.
37
La UART tambin se encarga de aadir a este grupo de bits que se va a enviar la configuracin sobre el bit de paridad y parada seleccionada para tal operacin.
Figura 14: Funcionamiento de la UART
1.2 El control de flujo Este control permite detener el envo de caracteres cuando la memoria temporal de un punto de conexin se llena. Existen dos formas de realizar este control, por software y por hardware. Control de Flujo por software o XON/XOFF. La deteccin de buffer o memoria temporal llena la realiza el programa de comunicaciones que se este usando en ese momento. No todos los programas de comunicaciones tienen esta facultad. Control de Flujo por hardware. La deteccin del buffer o memoria temporal llena se realiza por medio de tres circuitos de la norma: DSR, CTS y CD. Cuando se realiza un control de flujo distinto en ambos extremos de la comunicacin, puede acarrear problemas de funcionamiento en la lnea de enlace.
38
2 Desarrollo del software de envo de rdenes a travs del puerto serie a la TCS
Para el desarrollo de este software, se parte en principio del programa descrito en el captulo anterior, que permite recibir datos a travs del enlace inalmbrico. El diseo del software que engloba ya la comunicacin de la plataforma con el cliente remoto va red inalmbrica y la comunicacin interna va serie entre el mdulo Wi-Fi y la TCS, se ha basado en el establecimiento de dos hilos de proceso independientes que se ejecutan en paralelo en el microprocesador, con unas variables en memoria compartida para comunicacin entre ambos. Es obvia la diferenciacin de funciones que se establece en un programa de estas caractersticas, y que ha dado lugar a la divisin del proyecto en las etapas ya descritas: la comunicacin con el exterior y la interna entre los diferentes elementos de la plataforma pueden y deben funcionar de manera independiente, teniendo un nico nexo de unin, que es la orden recibida desde el cliente remoto. As pues, esta divisin deba reflejarse en la estructura del programa final, por lo que se establecieron dos hilos de proceso independientes: uno de ellos se encarga de todas las funciones antes descritas para un servidor, a saber, creacin del socket de comunicacin, escucha en la red en espera de cliente, establecimiento de la conexin con el cliente e intercambio de informacin, y el otro de los hilos tiene como nica misin controlar si hay datos nuevos que mandar a la TCS, y en caso afirmativo, proceder a su envo por va RS232. Aprovechando el servidor ya probado y funcionando, lo que se hace es ampliar su funcionalidad, de manera que no slo reciba y enve datos a travs del enlace inalmbrico. Lo que ahora debe hacer es recibir las rdenes que enva el PC remoto e interpretarlas segn un sencillo cdigo establecido, consistente en un nico carcter. De este modo, el recibir una a desde el PC remoto se interpreta como una orden de inicializacin de los motores y una activacin de los mismos, una b se interpreta como orden de avanzar, etc. La Tabla 3, muestra la correspondencia entre el carcter recibido por el mdulo y la orden enviada consecuentemente a la TCS. Si el carcter recibido no se corresponde con alguno de los considerados, se responde como comunicacin correcta, pero se ignora. Igualmente, de recibirse varios caracteres, a efectos de interpretar la orden, slo se
39
considera el primero de ellos. Es importante recalcar que siempre la primera comunicacin debe ser la orden de configuracin, para asegurar una correcta inicializacin de la TCS.
Cdigo recibido (Cadena de caracteres ASCII con un nico carcter) a
Orden interpretada
Configuracin inicial de los PICs y de los motores (Imprescindible enviarla la primera vez)
b c d e f
Arrancar motores y avance recto Detencin Giro a la derecha Giro a la izquierda Retroceso
Tabla 3: Cdigo de rdenes
Una vez recibida e interpretada la orden correspondiente, se genera la cadena que ha de enviarse por va serie a la TCS para que el elemento correspondiente ejecute la accin consecuentemente. Para ello se ha tomado como referencia el protocolo definido en [5] (Ver Tabla 4), en el captulo 3, correspondiente al desarrollo de la versin de TCS que se utiliza en el presente desarrollo. La cadena a enviar a la TCS por el puerto serie se trata de una sucesin de caracteres de 8 bits que se envan secuencialmente por el puerto serie. Bsicamente, el formato de dichas rdenes es un nmero que indica cul es dicha orden seguido de uno o dos nmeros que son los parmetros a configurar. As, basta con enviar todas las rdenes que se deseen con sus correspondientes parmetros una detrs de la otra, componiendo la cadena. A fin de identificar las rdenes que se envan en el cdigo fuente proporcionado, en la Tabla 4 se muestran las utilizadas en el presente proyecto. Si se desea conocer este protocolo con ms detenimiento, acudir a la referencia antes indicada.
Memoria. Comunicacin Serie Cdigo numrico de instruccin 1 Descripcin de la instruccin Configuracin (Siempre
debe enviarse la primera vez para inicializar la TCS)
40 Parmetros
Activar motores
Los bits 0 y 1 de un byte representan cada uno de los dos motores. Con un 1, el motor se activa. As un 3 activara los dos motores, y un 2 un 1 activara uno u otro motor
Perodo de los motores (Establecer

tambin la primera vez)
100
10
Duty cicle motores (Velocidad; 50=parado)
Nmero comprendido entre 0 y 100 para cada uno de los dos motores. Ejemplo: 25 , 25
Tabla 4: Instrucciones bsicas de la TCS
As, una orden tpica de configuracin de la TCS sera una cadena de caracteres con los siguientes nmeros: 1,4,8,100,10,25,25,92,1,1,4,92,49 Una orden para arrancar ambos motores, pero una vez configurada la TCS con una orden del estilo de la anterior, sera, por ejemplo: 7,3,92,1,92,49 Notar que los nmeros 92,1,92,49 que siempre existen al final de las cadenas se corresponden con unos indicadores de fin de comunicacin descritos detalladamente en [5], que no incumben a este proyecto.
Esa cadena as generada se almacena en una variable residente en memoria compartida, y por tanto accesible para ambos hilos de proceso, servidor y
41
comunicacin serie. Ello se consigue con una estructura conteniendo la cadena de caracteres y un entero que indica el nmero de caracteres que hay que enviar a travs del puerto serie. Esta estructura se crea como memoria compartida para que sea accesible por ambos hilos de proceso y sirva de nexo de comunicacin entre ellos. Para evitar conflictos entre los dos hilos por acceso simultneo a la variable intermedia para lectura y/o escritura en la misma, se utiliza un sencillo sistema de flags: existen dos variables globales de tipo entero (A modo de semforos mutex). Cuando el hilo de comunicaciones Wi-Fi accede a la variable intermedia para actualizarla segn las rdenes recibidas, primero comprueba que el otro hilo no est escribiendo en la variable en ese momento, para lo cual comprueba que el flag correspondiente est en valor 0. Si ese no es el caso, espera a que el otro hilo termine, colocando el flag a 0. En el momento de comenzar a escribir en la variable, coloca su correspondiente flag a 1, impidiendo que el otro hilo acceda en ese lapso de tiempo a la variable intermedia. Una vez actualizada la variable, resetea el flag, permitiendo el acceso al otro hilo (Ver Figura 18). La Tabla 5, muestra la identificacin de los flags en el cdigo del programa, los valores que toman y el significado de cada uno de esos valores, as como el hilo de proceso que accede a los mismos para cambiarlos o leerlos, es decir, qu hilo tiene permiso para escribir sobre ellos y qu hilo slo accede a los mismos para chequear su estado.
Memoria. Comunicacin Serie Nombre del Flag Acceso hilo de comunicacin Wi-Fi Acceso hilo de comunicacin serie Significado valor 1 Hilo de comunicacin Wi-Fi actualizando la variable intermedia con nueva orden Significado valor 0 Hilo de comunicacin Wi-Fi no escribiendo
Tabla 5: Descripcin de los Flags
42 iFlagEscribe Escritura iFlagBorra Lectura
Lectura
Escritura
Hilo de comunicacin serie reseteando la variable intermedia tras envo satisfactorio a TCS Hilo de comunicacin serie no reseteando
Antes de iniciar el hilo de proceso para gestin y envo de rdenes a travs del puerto serie a la TCS, es necesario configurar el puerto para que sea compatible con los parmetros establecidos en la programacin de la TCS. Tomando como referencia la configuracin recogida en los cdigos del driver de comunicacin desarrollado en [5], los parmetros a fijar al inicializar el puerto serie, se recogen en la Tabla 6.
Parmetro de configuracin Baudrate N de bits por carcter N de bits de stop Control de flujo Paridad
Valor a configurar 57600 baudios 8 bits 1 bit Ninguno Ninguna
Tabla 6: Parmetros de configuracin del puerto serie
43
Como ya se ha mencionado en lneas anteriores, la misin del hilo de comunicacin serie con la TCS es simplemente comprobar si hay instrucciones nuevas para enviar a la tarjeta y en caso afirmativo, proceder a su escritura en el puerto serie para ser ejecutadas por la TCS. La forma que tiene para comprobar si hay o no datos nuevos, es chequear el entero de la variable estructura en memoria compartida que indica el nmero de caracteres a enviar. Si ese ndice est a 0, quiere decir que no hay datos nuevos que enviar. De lo contrario, ha habido una nueva recepcin de rdenes y se procede a su envo. Completado el envo con xito, y tras comprobar mediante el sistema de flags que el otro hilo no est accediendo a la memoria compartida como se explic anteriormente, se procede a la limpieza de la variable para evitar volver a enviar de nuevo la misma orden. Para ello, simplemente basta con poner a cero el ndice de control de los datos a enviar dentro de la estructura intermedia, ya que ste es el que indica si hay o no datos nuevos que enviar. Este ndice permanecer a cero hasta que el hilo de comunicaciones Wi-Fi lo actualice tras recibir una orden desde el PC remoto, por lo que hasta ese momento no se volvern a enviar rdenes a la TCS. No resulta necesario borrar tambin la cadena de caracteres, ya que cuando el hilo de comunicaciones Wi-Fi la actualice se sobrescribir y actualizar del mismo modo la variable de control del nmero de caracteres a enviar por el puerto serie, por lo que slo se enviarn en todo momento los necesarios correspondientes a la orden nueva recibida, independientemente del contenido del resto de la cadena, que puede albergar restos de comunicaciones anteriores que sern ignorados, al caer fuera de los lmites marcados por el ndice del nmero de caracteres a enviar. La Figura 15, muestra un esquema general del funcionamiento del programa, los mdulos en los que est dividido y el flujo de datos y relaciones establecidas entre ellos, segn se ha venido explicando hasta el momento.
44
Memoria compartida
Datos a enviar ndice de datos
iFlagEscribe
IFlagBorra Hilo de proceso comunicacin Wi-Fi Hilo de proceso comunicacin serie
Wi-Fi
Rs232
NOTA: El flujo de los datos viene indicado por el sentido de las flechas. Flechas entrantes a los hilos de proceso indican lectura y flechas salientes de los mismos indican escritura.
Figura 15: Flujo de datos entre mdulos de programa
Hay que resear que al ser este programa una prueba de funcionalidad cuya misin es asegurar una comunicacin estable entre todos los elementos que integran la plataforma, y a fin de propiciar la transparencia del cdigo facilitando su comprensin por desarrolladores futuros, no se han considerado opciones de configuracin dinmica para el usuario, por ejemplo el poder configurar los motores (Su duty-cicle y perodo, por ejemplo) desde el interfaz de usuario. Por ello, es preciso predefinir estas opciones de configuracin en el cdigo fuente, a la hora de generar las cadenas a enviar a la TCS. La implementacin de la funcionalidad de configurar de forma remota los parmetros de los motores es sencilla, pero no es necesaria en estadios iniciales del desarrollo, que es lo que nos
45
ocupa, ya que para lograr un buen control remoto del robot no es necesario establecer una regulacin de velocidad en un principio. Por ello, los esfuerzos en este proyecto se han centrado en afianzar el concepto y diseo global de la comunicacin, creando una base razonablemente robusta, transparente y bien documentada para facilitar la implementacin futura de nuevas funcionalidades sobre ella. En la Figura 16, se muestra el diagrama de flujo que ilustra el funcionamiento del hilo de proceso correspondiente a la comunicacin y recepcin de rdenes desde el PC remoto. En l no se muestra la gestin de los flags para el control de los posibles conflictos de acceso a la memoria compartida entre los dos hilos porque significara complicar innecesariamente su claridad. La Figura 17, muestra el diagrama de flujo que muestra el funcionamiento del hilo de proceso encargado de comprobar si existen rdenes que enviar a la TCS en espera, y en caso afirmativo, enviarlas va serie RS232. Para comprobar la interconexin entre los hilos de proceso, revisar la Figura 15: Flujo de datos entre mdulos de programa. La Figura 18 muestra la gestin de flags para evitar conflictos de acceso
simultneo a la memoria compartida. Este sistema presenta un pequeo bug que est provocado por la posibilidad de que entre el instante en que se comprueba que el hilo complementario no est accediendo a la memoria compartida y se pone el flag correspondiente a 1 para reservar la variable, se d paso al turno de proceso del otro hilo y ste acceda a la memoria compartida, con lo cual, cuando el primer hilo acceda a esa memoria, se producira una excepcin al producirse la colisin entre ambos hilos de proceso. Sin embargo, esta posibilidad de error es muy remota dada la escasa frecuencia de transferencia de rdenes, infinitamente inferior a la velocidad de ejecucin de las instrucciones del microprocesador. La solucin para evitar este hecho pasa por utilizar un semforo que permita reservar el acceso a la memoria justo en el mismo instante en que se comprueba que el otro hilo no est accediendo, con lo que ese lapso de tiempo en que puede producirse el error se elimina. Otra solucin alternativa es establecer una seccin crtica una vez que se comprueba que la memoria compartida no est en uso y se decide acceder a ella, de manera que hasta que se finalice la operacin de acceso, se
46
impida al otro hilo realizar accin alguna. Queda este pequeo bug como punto pendiente para futuras ampliaciones, con la seguridad de que su posibilidad es lo suficientemente remota como para que pueda asumirse dados los estadios iniciales en los que se encuentra el desarrollo.

Abrir Socket
47
Atar Puerto
Ponerse a la escucha
Peticin de conexin?
No
S Aceptar la conexin
Recibir datos
Recepcin OK?
No
S Enviar confirmacin
No
Orden vlida?
Memoria compartida en uso?
No Actualizar la variable
Figura 16: Diagrama de flujo del hilo de proceso de comunicacin Wi-Fi

Abrir Puerto serie
48
Configurar Puerto serie
Orden lista para envo?
No
Escribir en puerto serie
No
Todos enviados?
Memoria compartida en uso?
No Resetear la variable
Figura 17: Diagrama de flujo del hilo de proceso de comunicacin serie
49
Hilo comunicacin Wi-Fi

Necesidad de escribir en memoria compartida
Hilo comunicacin Rs232

Necesidad de escribir en memoria compartida
IFlagBorra=1?
iFlagEscribe=1?
No
No
IFlagEscribe=1
IFlagBorra=1
Actualizar variable en memoria compartida
Resetear variable en memoria compartida
IFlagEscribe=0
IFlagBorra=0
Fin de actualizacin de memoria compartida
Fin de actualizacin de memoria compartida
Figura 18: Gestin de Flags de exclusin mutua
Memoria. Comunicacin Serie 2.1 Pseudocdigo
50
De manera anloga a lo explicado en el captulo anterior (Parte ICaptulo 22.1), la programacin utilizada en esta parte del proyecto es estructurada, ya que no se consider necesario recurrir a programacin orientada a objetos dada la sencillez del software a implementar. El lenguaje de programacin es C, con las particularidades propias del kit de desarrollo, utilizando las APIs proporcionadas tanto para gestin de sockets, como del puerto serie, que se explicarn detalladamente en los anejos a ello destinados (Parte IVCaptulo 2). A continuacin se detalla en forma de pseudocdigo el software desarrollado. Bsicamente, el cdigo principal est contenido en el archivo controlRemoto.c. Dentro del mismo se distinguen tres funciones: Serialone, TCPsend y servidor. La funcin Serialone es la que contiene el cdigo correspondiente al hilo de proceso de comunicacin serie. Es iniciada por uno de los dos threads creados. El funcionamiento de servidor es similar al descrito en el captulo anterior. Constituye el punto de entrada del hilo de proceso de comunicacin con el PC remoto, conteniendo los parmetros de configuracin de la red (Direccin IP, puerto y mensaje de respuesta enviado desde el servidor al PC cliente tras recibir datos de forma satisfactoria), e iniciando con ellos la funcin TCPsend, que es la encargada de iniciar el socket, establecer la comunicacin, recibir las rdenes e interpretarlas, generando las cadenas que ms tarde se enviarn a la TCS gracias al otro hilo de proceso. 2.1.1 Cdigo de controlRemoto.c Funcin Serialone
;Punto de inicio del hilo de proceso
void Serialone(ULONG thread_input){ int zeroFd; int baudrate; puerto
;Creamos descriptor del puerto serie ;Creamos variable para poder configurar el Baudrate del
int bytetosend = 0; ;Creamos variable para controlar la cantidad de datos a enviar por el puerto serie
;Rutina estndar para establecer las opciones de configuracin para la UART
51
sendBuffer0.iLongitud=0; ;Inicializo la memoria compartida indicando que no hay nada que enviar por el puerto zeroFd = open ("/com/1", O_RDWR); ;Abrir el com1 para lectura y escritura (Dejo el com0 para control por pantalla mediante los printf del desarrollo del programa si se considera necesario)
if (zeroFd <0)
;Comprobar apertura del puerto satisfactoria
;Mostrar mensaje y abortar rutina ;Si todo OK, continuar baudrate = SIO_57600_BAUD; tcgetattr(zeroFd, &tios); cfsetospeed(&tios, baudrate); ;Rutinas de configuracin del resto de opciones ;Configurar el resto de parmetros: No controles de flujo, 8 bits de datos, un bit de stop y sin paridad iOptions.cflags = (SIO_NO_HANDSHAKING | CS8 | SIO_ONE_STOP_BIT | SIO_NO_PARITY); iOptions.iflags = (0); ;Rutinas de configuracin tios.c_cflag = iOptions.cflags; tios.c_iflag = iOptions.iflags; ;Configurar el Baudrate a 57600 baudios
result = tcsetattr( zeroFd, TCSANOW, &tios ); ;Fin de la rutina de apertura y configuracin del puerto serie while(1){ ;Abro bucle infinito para comenzar la lectura de rdenes y escritura en el puerto serie de forma cclica bytetosend = sendBuffer0.iLongitud; a enviar leyendo del buffer intermedio numBytesSent = 0; ;Establezco la cantidad de datos
;Reseteo el control de datos enviados
if (numBytesSent < bytetosend) ;Compruebo que realmente hay datos nuevos que enviar en espera en el buffer write(descriptor puerto serie, byte a enviar, bytes pendientes de enviar)); if(numBytesSent==bytetosend){ reseteo el buffer intermedio ;Si ya he mandado todo lo que tena,
while(iFlagEscribe){ ;Espero a poder escribir sobre la cadena para resetearla, ya que si iFlagEscribe est a 1, quiere decir que el hilo del servidor est actualizando la variable. Bucle cerrado hasta que la variable est libre

}
52
iFlagBorra=1; ;Pongo este flag a 1 para evitar que mientras reseteo la variable acceda a ella el otro hilo. Reservo la variable. sendBuffer0.iLongitud=0; ;Reseteo la variable. Slo es necesario borrar el indicador de bytes a enviar iFlagBorra=0; } } }while (numBytesSent < todo por el puerto serie bytetosend); ;Repito hasta que haya mandado ;Libero el acceso a la variable intermedia
} ;Vuelvo al inicio del bucle infinito para volver a comprobar si hay nuevas instrucciones que enviar a la TCS result = close (Descriptor del puerto serie); ;En caso de que haya habido algn error grave, devuelvo el control cerrando el puerto serie. Necesidad de reiniciar el programa.
;Fin del hilo de proceso de la comunicacin serie
Funcin servidor
void servidor(ULONG thread_input){ ;Aplicacin principal que arranca al iniciarse el hilo de proceso
char sHost[16]="190.206.71.20"; (servidor)
;Direccin IP del mdulo en la red
char sDatos[32]="Recibido OK"; ;Datos a enviar en la confirmacin de recepcin al cliente
int iPort=1234;
;Puerto en el que escuchar
while(1){
;Bucle infinito, slo funcin decorativa, ya que si TCPsend devuelve el control, se requerir indefectiblemente un reset del sistema
TCPsend((const char *)sHost, iPort, sDatos); } return; } ;Fin de la funcin principal
Memoria. Comunicacin Serie Funcin TCPsend:
53
int TCPsend(const char *sHost, int iPort, char * sDatos){
int sock;
; Crear descriptor del socket
struct sockaddr_in
fsin;
;Crear estructura para almacenar la direccin donde se crear el socket
sock = socket(familia de protocolos + tipo TCP);
;Abrir el socket TCP
;Si hay error al abrir el socket, se aborta la ejecucin
;Se reserva memoria para la direccin del socket
;Configurar la direccin del socket con la familia de protocolo, una direccin IP genrica y el puerto
Bind (descriptor del socket + direccin); ;Atamos el socket al puerto correspondiente ;Si hay error al atar el puerto, cerramos el socket y abortamos la ejecucin
Listen(Descriptor
del socket); ;Ponerse a la escucha en el socket
int acceptsock = socket(familia de protocolos + tipo TCP); ;Crear descriptor de socket auxiliar necesario para aceptar la nueva conexin ;Esperamos a que haya una peticin de conexin y la aceptamos
while (1) {
;Iniciamos bucle infinito para esperar al cliente
acceptsock = SOCKET_ERROR; while ( acceptsock == SOCKET_ERROR ) { ;Intentar la conexin hasta que haya xito acceptsock = accept( sock, NULL, NULL ); }

printf( "Client Connected.\n"); sock = acceptsock; conexin break; } ;Asignamos al socket general el que ya tiene
54
;Con el cliente ya conectado, salimos del bucle infinito
;Crear las variables para controlar la cantidad de datos enviados y recibidos y la cadena de caracteres para almacenar lo enviado desde el cliente int bytesSent; int bytesRecv = SOCKET_ERROR; char recvbuf[32] = ""; ;Cadena inicializada vaca
while(1){
;Bucle infinito para la recepcin y envo contnuo de datos a travs del socket
;Recibir los datos if(bytesRecv!=-1){; ;Slo si se reciben datos
;Interpretar lo recibido, es decir, leer primer carcter de la cadena recibida y comprobar que se corresponde con una orden definida. De lo contrario, ignorar lo recibido ;Si hay correspondencia con alguna orden { while(iFlagBorra){ variable el otro hilo } ;Espera a que acabe de escribir sobre la
;Bucle cerrado hasta liberacin de la variable
iFlagEscribe=1; ;Reservo la variable intermedia para que el otro hilo no acceda mientras la actualizo ;Actualizar la variable intermedia con la cadena correspondiente a la orden recibida, segn el protocolo establecido iFlagEscribe=0; ;Libero la variable intermedia para que el otro hilo pueda acceder a ella si es necesario } ;Enviar confirmacin al cliente de recepcin satisfactoria } ;Terminada la comunicacin, volvemos a escuchar la red para iniciar la siguiente } ;Fin del bucle infinito. Slo se pasa de aqu si hay algn problema ;Como ha habido problema, se cierra el socket
close (sock);
return; ;Devolvemos el control. Se requerir un reset del programa para volver a establecer una conexin sin reservar nuevos puertos } ;Fin del cdigo del servidor embebido en el mdulo y de la rutina de reconocimiento de rdenes y generacin de la cadena a enviar a la TCS va serie
Memoria. Resultados/Experimentos
55
Captulo 4 RESULTADOS/EXPERIMENTOS
En este captulo se exponen fundamentalmente los mtodos que se siguieron para localizar los errores en los programas desarrollados, corregirlos, y finalmente comprobar su funcionamiento satisfactorio en el mdulo Wi-Fi. Como punto final al desarrollo del proyecto, y para mostrar de manera clara el resultado final del mismo, se mont el conjunto sobre un robot real construdo sobre una plataforma mecnica LEGO. Por lo tanto el presente proyecto qued montado y perfectamente integrado con el resultado del desarrollo del otro proyecto constituyente en la comunicacin desde un navegador Web y la recepcin de imgenes a travs de la cmara Web Wi-Fi instalada a tal efecto en el robot, que adems puede ser orientada gracias a rdenes transmitidas por el mismo usuario desde el interfaz Web.
56
1 Pruebas
del
software
de
comunicaciones
Wi-Fi:
Programa TCPTest.exe
El primer desarrollo del proyecto tuvo por objeto el lograr establecer una conexin estable entre el mdulo Wi-Fi y un cliente remoto, a travs del enlace inalmbrico con que el mdulo cuenta a tal efecto. Sin embargo, llegado a este punto, se plantea la incgnita de cmo comprobar que el servidor embebido en el mdulo realmente es capaz de recibir y enviar informacin a travs de la red, y no slo eso, sino asegurarnos de que la informacin enviada y recibida es bien entendida en ambos extremos de la comunicacin. Para dar respaldo a esta necesidad planteada, se llega a la conclusin de que es necesario desarrollar un sencillo programa que permita conectarse al servidor del mdulo y enviarle unos datos concretos, conocidos por nosotros, al tiempo que pueda recibir la respuesta del servidor ante la recepcin de datos completa, tambin establecida por nosotros. El resultado de este desarrollo es el programa de pruebas TCPTest.exe. Se trata de un sencillo programa realizado en el entorno de programacin Microsoft Visual C++ 6.0 bajo Windows. El cdigo ntegro del mismo se facilita en la Parte V Captulo 3 (anejos destinados a los cdigos de aplicaciones), al final de este proyecto. Se ejecuta en ventana de comandos, y permite tanto crear un servidor para recibir la conexin de un cliente e intercambiar datos, como conectarse como cliente a un servidor (que en nuestro caso ser el embebido en el mdulo). Una vez establecida la conexin, se puede enviar una cadena de caracteres de hasta 32 bytes de longitud, lo cual permite conocer perfectamente cules son los datos enviados. El programa recibe posteriormente los datos procedentes del otro extremo de la conexin y muestra el resultado de la comunicacin por pantalla, a saber, bytes enviados y recibidos, y mensaje recibido desde el otro equipo, con lo que en todo momento se tiene controlada la comunicacin por ambos lados, ya que el servidor embebido en el mdulo opera de manera anloga, enviando siempre la misma respuesta a una recepcin satisfactoria y mostrando el resultado de la comunicacin por pantalla. La manera de utilizar TCPTest es muy simple: Al iniciarse el programa aparece un men (Figura 19) que permite seleccionar si se desea crear un servidor en
57
espera de conexiones, o bien, conectarse como cliente a un servidor remoto. Se selecciona la opcin pertinente y se establece la conexin oportuna. Hay que sealar que Windows (en concreto, la versin XP Service Pack 2) tiene restricciones de seguridad que pueden impedir al programa acceder a la red, por lo que es necesario aplicar al programa los permisos de acceso a la red necesarios en las opciones de seguridad del sistema.
Figura 19: Pantalla de men inicial
Una vez seleccionada la opcin, por ejemplo 2 para conectarse como cliente a un servidor en espera de conexiones, deben proporcionarse la direccin IP y el puerto donde se encuentra el servidor. La direccin IP debe proporcionarse en el formato estndar de cuatro campos entre 0 y 255 separados por puntos (tpicamente es la direccin IP del mdulo Wi-Fi). Con los datos del servidor, intenta establecerse una conexin. Si en un determinado tiempo no se logra, el programa regresa a la pantalla inicial. Si todo va como lo esperado, el programa establece la conexin y espera a que el usuario proporcione los datos a enviar. Concludos el envo y la recepcin de datos, se muestra una pantalla con los resultados, como la mostrada en la Figura 20, correspondiente al equipo conectado como cliente, y en la Figura 21,
correspondiente al equipo servidor. Notar que si por un casual el servidor se desconecta, el cliente no podr enviar datos, con lo que mostrar un mensaje
58
diciendo que se han enviado -1 bytes indicando el error, y volver a la pantalla inicial. En lo que al servidor respecta funciona exactamente igual que el servidor implementado en el mdulo, creando un socket y ponindose a la escucha en el puerto dado hasta que llegue una peticin de conexin de un cliente. En ese momento se pone en situacin de recibir datos, devolviendo tras la recepcin correcta Recibido OK.
Figura 20: Pantalla correspondiente al equipo cliente
Figura 21: Pantalla correspondiente al equipo servidor
59
En las primeras versiones del programa servidor embebido en el mdulo, tras cada recepcin se cerraba el socket, intentando abrir uno nuevo cada vez que se estableciese una nueva comunicacin. Ello permitira a un cliente desconectarse, dejando paso al siguiente. Del mismo modo actuaba el programa TCPTest, que tras cada comunicacin volva al estadio inicial. Cuando la conexin se estableca as entre dos equipos ejecutando el TCPTest, no haba problema alguno al efectuar comunicaciones sucesivas siempre utilizando el mismo puerto. Sin embargo, cuando se comprob el funcionamiento con el mdulo, se comprob que tras la primera comunicacin, a la hora de intentar abrir la segunda, el programa se quedaba bloqueado definitivamente. Se prob entonces a cambiar el puerto con cada nueva conexin, con lo que el problema desapareci. Este hecho llev a la conclusin de que cuando el programa servidor del mdulo cierra un socket, no libera a la vez el puerto atado a ese socket, que queda reservado irremisiblemente al no existir funcin alguna para liberarlo. Cuando se intentaba establecer una nueva conexin utilizando ese mismo puerto, al estar ste bloqueado, el programa quedaba consecuentemente interrumpido al intentar realizar la operacin de bind(), mostrndose de manera continuada el error congruente con este problema, es decir, se indicaba un error en la operacin de bind(). Sin embargo, este problema no ocurre con TCPTest, y ello ha de ser debido a que la operacin de clausura de un socket bajo Windows s que libera al mismo tiempo el puerto utilizado para esa conexin, permitiendo su uso posterior para otra nueva conexin. Para solucionar el problema se ha intentado establecer una opcin de configuracin para el socket descrita en los archivos de cabecera como Allow port reuse, pero ello no soluciona el problema. Al no ser asumible el reservar un nuevo puerto para cada nueva comunicacin, se opta por la solucin de no cerrar en ningn momento el socket, estableciendo una comunicacin cclica sin fin una vez lograda la conexin, pero siempre con el mismo socket abierto. ste ha sido el procedimiento adoptado finalmente. Sin embargo, presenta el problema de precisar un reset del sistema si por alguna razn se pierde en algn momento la comunicacin entre ambos equipos, lo que, por otro lado, no suele ser habitual si se trabaja con una red relativamente potente en
60
lo que a nivel de seal se refiere, es decir, con una seal razonablemente intensa en el entorno de operacin del robot.
2 Pruebas del software de comunicacin por va serie con la TCS

El principal problema que se present a la hora de implementar la conexin serie del mdulo con la TCS radic en asegurarse de que la configuracin aplicada a la UART del mdulo era la necesaria, de forma que fuese realmente comprensible por la TCS. En unos primeros instantes del desarrollo, no se lograba que la TCS respondiese a las instrucciones enviadas desde el PC cliente. En principio, pareca que se segua correctamente el protocolo de comunicaciones establecido en [5] y resumido en el Captulo 3 2 de esta memoria. Para comprobar si realmente las rdenes recibidas por el mdulo eran entendidas, y las cadenas enviadas a travs del puerto serie hacia la TCS, de manera que se pudiese acotar el origen del problema, se utiliz un osciloscopio digital, el cual fue colocndose en los diferentes puntos crticos de los circuitos (A saber, salida del pin de transmisin serie del mdulo, entrada a la TCS, etc.), de manera que se fue comprobando, por un lado que la seal digital emitida por el puerto serie llegaba correctamente a su destino, y por otro lado, que realmente esta seal se correspondiese con las caractersticas de bits por carcter, velocidad de transferencia, bit de stop, etc. Se analiz detenidamente la trama enviada por el puerto serie, enviando caracteres cuyos trenes de pulsos siguiesen patrones fciles de reconocer, a fin de comprobar que todo se generaba de forma correcta. Comprobado que todo funcionaba conforme a lo previsto, finalmente se lleg a la conclusin de que el problema no era ni de hardware, ya que la seal alcanzaba perfectamente todos los puntos de su recorrido, ni de configuracin del puerto serie del mdulo, que funcionaba conforme a lo requerido. Por tanto, la nica posibilidad era que las cadenas que se estaban enviando no fuesen correctas desde el punto de vista del protocolo de comunicaciones antes mencionado. Tras probar varias posibilidades, se logr hacer funcionar la plataforma. El problema era que no se haba configurado la TCS con las rdenes oportunas. Como se seala en el cuadro resumen del
61
protocolo, lo primero que debe enviarse a la TCS tras conectar la alimentacin o efectuar una operacin de reset es una orden de configuracin, que hasta ese momento no se haba enviado. Comprendido este hecho, se logr que la plataforma funcionase de acuerdo a lo esperado, ejecutndose sin problemas las rdenes enviadas desde el cliente. Un hecho que se ha observado es que tras un cierto perodo de tiempo sin actividad, la TCS se coloca en un estado que podra llamarse de standby. Cuando ocurre este hecho, la primera instruccin que se le enva tras el perodo de inactividad, se pierde, por lo que es necesario enviarla una segunda vez, reanudndose de esta manera la comunicacin normal. Sin embargo, cabe sealar que en general, en unas condiciones normales de operacin no suele pasar el tiempo suficiente entre instruccin e instruccin como para que suceda este hecho.
Una vez afianzada y consolidada la comunicacin serie por la cual el mdulo poda escribir rdenes en el puerto de manera que fuesen captadas y ejecutadas por la TCS, se trat de leer las respuestas enviadas a travs del puerto serie por la TCS, por ejemplo con las medidas de los sensores. Esta lectura se hace necesaria para poder implementar habilidades de supervivencia en el robot. Existen una serie de rdenes, definidas en el protocolo de comunicacin con la TCS que permiten pedir las medidas de los sensores. Enviando dichas rdenes a la TCS, se comprob que la misma responda sin problemas a la peticin, enviando consecuentemente la respuesta a travs del puerto serie. Este hecho se comprob del mismo modo que anteriormente colocando el osciloscopio digital en el pin de salida de la va serie de la TCS. Sabiendo que la TCS s escriba la informacin en el puerto serie sin problemas, se trat de leer dicha informacin por parte del mdulo Wi-Fi, utilizando la instruccin read(), que permite leer del puerto serie y que se utiliza de manera anloga a write() (Ver Parte IV Captulo 2 1.2). Ejemplo de uso de la funcin read(), donde se observa que los parmetros que utiliza son exactamente los mismos que write():
result = read(zeroFd, (rcvBuffer0 + numBytesRcvd), (bytetorecv - numBytesRcvd))
As, el prototipo de la funcin read viene a ser: int read(int fd, char *recvbuf, int bytetorecv)
62
Ejecutando la funcin de forma sucesiva hasta completar la lectura de todos los datos a recibir del puerto. Sin embargo, pese a utilizar la funcin read() de manera aparentemente correcta y coherente con ejemplos de uso proporcionados con el entorno de desarrollo, ya que adems se utiliza exactamente igual que la funcin write(), que funciona a la perfeccin, el intentar la lectura del puerto serie para tratar de obtener las medidas de los sensores, nicamente se traduca en bloqueos del programa. Debido a la falta de tiempo (Tiempo empleado en toda la fase de documentacin y de preparacin de los manuales de las APIs pertinentes, objetivo que sustituy al de implementar habilidades de supervivencia al robot), se decidi posponer este objetivo para futuros desarrollos. Como ayuda para ellos, mencionar que la fuente de bloqueo ms probable es que los datos enviados por la TCS se perdiesen al no haberse implementado ningn sistema en el mdulo para detectar la presencia de datos en el puerto serie, y que el intentar leer del puerto sin que hubiese datos produjese dicho bloqueo. Se intent a tal efecto crear un hilo de proceso exclusivo para lectura del puerto serie que monitorizase constantemente dicho puerto para evitar la prdida de datos, pero tampoco solucion el problema. Para lograr este objetivo, sera necesario trabajar con interrupciones para saber exactamente cundo llegan datos al puerto serie. De cualquier modo, la consecucin de este objetivo ha de ser premisa importante en desarrollos futuros.
3 Integracin del sistema con la Web desarrollada en el proyecto complementario y construccin del robot
Una vez logrado el funcionamiento de la plataforma, con el establecimiento de una comunicacin satisfactoria del mdulo con el exterior por va inalmbrica y con la TCS por va serie, y todo controlado desde el programa TCPTest.exe, se hace necesaria la integracin de los dos trabajos que constituyen el concepto conjunto descrito en el resumen del presente proyecto. Esto requiere comprobar la buena comunicacin entre el servidor embebido en el mdulo (Programado en C/C++), y el cliente remoto (Programado en Java para poder ser integrado en un interfaz Web). En unos primeros pasos, no se logra establecer la conexin entre ambos elementos. Finalmente, se llega a la conclusin de que existen restricciones
63
de seguridad en las redes que impediran acceder a un equipo con tal facilidad. Baste con decir que finalmente se logra que las restricciones no tengan ese efecto mediante una firma digital que garantiza la seguridad del software. Una vez conocido el hecho de la restriccin de seguridad, se logra establecer una conexin satisfactoria entre el cliente y el mdulo, y un intercambio de datos que permite tele controlar el robot desde el software del cliente. Asimismo, este software permite observar las imgenes captadas por una cmara Wi-Fi, que ir situada sobre el robot para captar sus evoluciones y seguirlas desde la distancia, y dirigir la misma a nuestro antojo gracias a una serie de controles paralelos a los del robot, todos integrados en el mismo interfaz grfico. Con la seguridad de la existencia de una buena comunicacin entre todos los elementos, y de una integracin satisfactoria de ambos proyectos, se aborda el ltimo paso, que es la construccin de un sencillo robot en plataforma mecnica LEGO que integre toda la electrnica programada en este proyecto y la cmara Wi-Fi objeto de estudio del proyecto conjunto al presente. El objeto de construir este robot es proporcionar una idea visual rpida de cmo puede utilizarse la plataforma creada, demostrar su funcionalidad. No se documenta el proceso de construccin del robot porque su importancia, fuera de ser una plataforma para mostrar los resultados finales obtenidos en ambos proyectos, es escasa, ya que no integra ningn sistema de sensores ni comportamientos especficos de ningn tipo que requieran unas caractersticas mecnicas o geomtricas concretas. Es, bsicamente, un robot mvil telecontrolado, y para realizar esta funcin es vlida cualquier construccin que simplemente integre la electrnica y la cmara de una forma satisfactoria. El resultado del desarrollo de este robot, se muestra en la Figura 22, Figura 23, Figura 24 y Figura 25.
64
Figura 22: Vista cenital del robot finalizado que muestra la disposicin del mdulo y su placa
Figura 23: Vista lateral que muestra las salidas serie de la placa del mdulo
65
Figura 24: Vista lateral trasera. Bajo la placa del mdulo se observa la TCS
Figura 25: Vista frontal del robot que muestra la sujeccin de la cmara
Memoria. Conclusiones
66
Captulo 5 CONCLUSIONES
El presente proyecto ha permitido desarrollar una plataforma bsica para facilitar el control remoto de robots mviles desde un PC cliente a travs de una red inalmbrica Wi-Fi estndar. Como resultado final al proyecto, se cuenta fundamentalmente con un mdulo programado para funcionar como servidor en una red inalmbrica. Este mdulo est preparado para establecer una conexin con un cliente y recibir datos a travs de dicha conexin. Adems, cuenta con la capacidad de interpretar dichos datos recibidos y discriminar si se trata de rdenes destinadas al control del robot mvil. En caso de identificar una orden vlida, el mdulo es capaz de codificarla segn un protocolo determinado implementado en dicha programacin y enviarla por va puerto serie RS232 a la Tarjeta de Control de Sensores, que ejecuta las rdenes. Como resultado adicional al proyecto, existe un robot mvil construdo en plataforma LEGO que integra todo lo desarrollado tanto en este proyecto como en el complementario. Este robot puede ser telecontrolado a travs de un interfaz Web diseado expresamente, y sus evoluciones pueden ser seguidas gracias a las imgenes enviadas va Wi-Fi por una cmara Web integrada en el propio robot. Conforme se fue desarrollando el proyecto, se identific una carencia de documentacin muy importante en lo que a utilizacin del mdulo Wi-Fi y programacin del mismo se refiere. No exista una documentacin lo suficientemente clara y estructurada acerca de cmo compilar, programar y depurar el microprocesador del mdulo, ni tampoco un manual que proporcionase informacin acerca de las APIs facilitadas para la gestin de las diferentes funcionalidades del sistema. Esta carencia supuso un importante obstculo a la hora de avanzar y obtener resultados en el desarrollo del proyecto, ya que exigi una larga y costosa tarea de documentacin, de estudio de ejemplos prcticos de programacin proporcionados por el fabricante. Asimismo, se consumi una gran cantidad de tiempo en pruebas y tentativas acerca de cmo compilar los programas, opciones de compilacin, carga de los mismos en la memoria del mdulo, tanto provisional como definitiva, etc., debido a que los manuales de
Memoria. Conclusiones
67
usuario proporcionados son confusos y, sobre todo, incompletos, con ausencia de informaciones muy importantes para la utilizacin del entorno de desarrollo y la creacin y prueba de nuevos programas para el mdulo. Este hecho, por el tiempo invertido en el mismo, supuso una modificacin de los objetivos primitivos del proyecto, encaminando una parte muy importante del mismo al desarrollo de una documentacin ms completa y estructurada que permita reflejar todo el trabajo de estudio y abstraccin antes mencionado, de manera que pueda ser aprovechado para desarrollos futuros basados en el mdulo. El resultado final de estos esfuerzos es un Manual de Usuario que proporciona toda la informacin obtenida durante el desarrollo del proyecto, expresada de forma general para facilitar su uso independiente de las aplicaciones desarrolladas en este proyecto, tanto en lo referente a la programacin de funciones de comunicacin inalmbrica o por va serie del mdulo, como en lo referente a aspectos prcticos acerca de cmo compilar, cargar los programas, depurarlos, etc. Por tanto, el resultado final del proyecto ha sido positivo, logrndose una buena funcionalidad de la plataforma, con el establecimiento de una conexin suficientemente estable, que permite tele controlar el robot desde un PC remoto sin problemas. En resumen, los objetivos fundamentales del proyecto se han cumplido satisfactoriamente, a saber: Desarrollo de una plataforma para el control de un robot mvil a travs de Internet. Implementacin del resultado final en un robot mvil construdo a tal efecto. Creacin de una documentacin sobre el mdulo Wi-Fi que suple las carencias de la proporcionada por el fabricante y facilita el trabajo a desarrolladores futuros trabajando sobre esta plataforma.
Memoria. Futuros desarrollos
68
Captulo 6 FUTUROS DESARROLLOS

Puesto que se trata de un proyecto que se ha iniciado prcticamente desde cero, las posibles ampliaciones y mejoras que daran pie a futuros desarrollos son muchas. Adems, el mdulo Wi-Fi utilizado ofrece una amplsima variedad de posibilidades, puesto que la capacidad de proceso del microprocesador que incorpora es muy elevada, y posee una gran cantidad de funcionalidades y posibilidades de programacin. Es una lstima que la carencia de documentacin sea tan acusada, lo que obliga a una labor de documentacin intensa previa a cualquier nuevo desarrollo que se desee implementar. De este modo, un objetivo que debe ampliarse es el manual de usuario, al que debern ir aadindose nuevos apartados conforme se vayan estudiando nuevas funcionalidades para el mdulo. Teniendo presente esto, facetas que quedan pendientes o cuya posibilidad de implementacin se abre a partir del presente proyecto, podran ser las siguientes:
Estudio de las funcionalidades que para gestin de tiempo real posee el mdulo, y documentacin de las APIs correspondientes, por ejemplo, a semforos para mejorar la gestin de memoria compartida entre los hilos de proceso.
Implementacin de un sistema de reset software, que en caso de error (Como por ejemplo cada de la conexin de red inalmbrica) permita al sistema reiniciarse automticamente, sin necesidad de intervencin fsica del usuario.
Implementacin de la posibilidad de lectura de datos a travs del puerto serie por parte del mdulo como medio de obtener lecturas sensoriales de la TCS. Esto permitir obtener informacin del estado del robot y comunicarla al cliente, y de forma inmediata implementar habilidades de supervivencia en el robot, que le permitan desenvolverse sin que haya necesidad de tener un cliente conectado tele controlndolo. Adems de habilidades de supervivencia, podran programarse comportamientos
69
especficos, como barrido inteligente de entornos, para bsqueda o inspeccin remota. Un ejemplo de aplicacin seran operaciones de tele vigilancia domstica, para supervisar a distancia cualquier rincn de nuestra casa sin necesidad de tener que instalar complicados sistemas de cmaras, sino que con el robot movindose por toda la casa sera suficiente, pudiendo implementarse en l un sistema de rastreo automtico y avisar en caso de deteccin de contingencias especiales, etc. En general, cualquier aplicacin de tele presencia o tele vigilancia sera de muy sencilla implementacin con esta plataforma. Dichos comportamientos podran implementarse tanto en el propio mdulo como en el PC remoto. En caso de implementarse en el mdulo, la versatilidad de la plataforma disminuira, ya que resulta complicado de programar y testear. Sin embargo, la implementacin de los
comportamientos en el PC remoto resulta muy interesante, ya que facilitara el poder implementar diferentes comportamientos sin necesidad de variar la programacin del mdulo. Estos comportamientos podran programarse de forma sencilla con un lenguaje de alto nivel, como Java o C++. En este caso, el mdulo se convertira en un nexo de unin entre el PC y el robot. Su misin consistira en recibir constantemente rdenes del PC, transmitirlas a la TCS y, acto seguido, recoger las lecturas sensoriales de la TCS y remitirlas de vuelta al PC, que se encargara de procesarlas y generar la orden consecuente con el comportamiento programado, que sera nuevamente enviada al mdulo, cerrando el bucle. De este modo, se obtendra una plataforma muy flexible y fcil de programar para controlar cualquier tipo de robot simplemente a travs de una red inalmbrica.
Adems de desarrollos software, quedara pendiente el disear un sencillo soporte hardware para disminuir el tamao, peso y precio final de la plataforma. Una vez programada su Flash ROM, el mdulo Wi-Fi es totalmente independiente de la placa facilitada con el entorno de desarrollo, muy buena para operaciones de depuracin, pero grande, pesada y con un consumo elctrico elevado a la hora de funcionar normalmente de forma autnoma y con bateras. Para operar con l posteriormente, bastara con una sencilla placa con un zcalo adecuado para
70
insercin del mdulo, en la que debera colocarse simplemente una entrada de alimentacin adecuada y una conexin serie para la comunicacin con la TCS, que sera ms que suficiente que contase con los tres nicos pines utilizados por dicha placa, a saber, Tx, Rx y GND. Construida esta sencilla placa, el tamao final del conjunto sera poco superior al del mdulo, y el coste final disminuira enormemente, al poder comprarse mdulos programables independientes, mucho ms baratos que el kit de desarrollo, ser programados desde una nica placa de desarrollo y finalmente transferidos al soporte desarrollado.
Memoria. Bibliografa
71
BIBLIOGRAFA
[1] [2] [3] [4] [5] Pgina Web de SitePlayer: www.siteplayer.com Pgina Web de Dr Robot: www.drrobot.com Pgina Web de ActivMedia Robotics: www.activrobots.com Pgina Web del AmigoBot: www.amigobot.com Prrizas Fernndez, Francisco Javier. Plataforma para el control de robots mviles autnomos: Driver de comunicacin entre PDA y plataforma. Fuente: Biblioteca de Proyectos Universidad Pontificia Comillas, Escuela Tcnica Superior de Ingeniera (ICAI). Madrid, Junio 2004. [6] [7] [8] [9] Pgina Web de Digi International: www.digi.com Pgina Web de jGRASP: www.jgrasp.org Pgina Web de Macraigor Systems: www.macraigor.com MSDN Library de Microsoft: msdn.microsoft.com/library Pgina de Microsoft con completa informacin y recursos acerca de varios lenguajes de programacin, til para obtener informacin acerca de funciones de uso genrico. [10] Snchez Miralles, lvaro y Palacios Hielscher, Rafael. Sistema para el control remoto de un robot mediante un navegador de Internet (I y II). Revista Anales de mecnica y electricidad. Revista de la Asociacin de Ingenieros del ICAI. Volumen LXXVIII, Fascculos II y III, Marzo-Abril y Mayo-Junio 2001.
Clculos.
72
Parte II CLCULOS
Clculos.
73
El desarrollo del presente proyecto no ha requerido la realizacin de clculos de entidad suficiente como para justificar la inclusin de los mismos en una seccin aparte. De existir algn clculo, queda recogido a lo largo del desarrollo de la memoria del proyecto.
Estudio econmico.
74
Parte III ESTUDIO ECONMICO
Estudio econmico.
75
La posibilidad de hacerse con un equipo que permita al usuario manejarlo de forma remota desde cualquier PC con conexin a una red local o a Internet, al tiempo que dicho equipo permite observar su entorno desde dicho PC, es sumamente atractiva, ms an cuando nos encontramos en una poca donde las tecnologas de acceso inalmbrico a redes Wi-Fi estn ganando terreno a pasos agigantados, a la par que su coste de instalacin cada vez es menor. Si adems aadimos el hecho de que dicho equipo telecontrolado puede obtenerse a bajo coste respecto a otras opciones existentes en el mercado, que trabaja con tecnologas absolutamente estndar y compatibles en cualquier red inalmbrica y que permite un nivel de personalizacin a las necesidades del usuario muy elevado, el inters que suscita un proyecto de las caractersticas del que aqu se ofrece es evidente. Las tecnologas de tele presencia y tele vigilancia estn cobrando una relevancia indiscutible en la sociedad de la informacin. Hoy en da casi desde cualquier punto del planeta puede tenerse acceso a Internet, y la posibilidad de ver en todo momento lo que ocurre en un lugar alejado, a la par que el poder interactuar con dicho entorno a travs de un dispositivo telecontrolado, slo por disponer de dicho acceso a Internet, abre un abanico de posibilidades muy amplio, tanto para el mbito profesional/empresarial como para el domstico, en lo que a materias de seguridad, vigilancia e incluso entretenimiento se refiere. El conjunto de proyectos que componen este desarrollo, ofrecen una plataforma verstil y totalmente configurable por el usuario, al tiempo que hacen absolutamente transparente para el mismo el acceso desde Internet al robot. El usuario no se preocupa de los estadios intermedios de comunicacin interna que se establecen, sino que simplemente comprueba que las rdenes que enva desde el interfaz Web, son ejecutadas por el robot situado a distancia. Adems, la labor de personalizacin est facilitada por el hecho de que se adjunta una completa documentacin por si es necesario sumergirse en los entresijos de funcionamiento de la plataforma. Esta doble vertiente la hace atractiva tanto para usuarios sin
Estudio econmico.
76
ningn tipo de conocimientos acerca de programacin, redes o robtica mvil como para usuarios de corte investigador, desarrolladores o universidades que deseen ampliar el diseo partiendo de lo aqu desarrollado. Por tanto, est asegurada la viabilidad tanto de los presentes proyectos como de futuros desarrollos, dada la amplia variedad de aplicaciones que lo hacen atractivo a gran cantidad de potenciales compradores. La viabilidad econmica est tambin respaldada por la relacin prestaciones/precio/versatilidad que ofrece la plataforma aqu desarrollada frente a otras soluciones comerciales ya lanzadas y funcionando. Adems, el despegue actual de las tecnologas de esta rama, hace a este conjunto de proyectos colocarse en una posicin de vanguardia, ltimas tecnologas y desarrollos originales e innovadores, con el valor aadido que ello supone.
Manual de usuario.
77
Parte IV MANUAL DE USUARIO
Manual de usuario. Creacin y gestin de sockets
78
Captulo 1 CREACIN Y GESTIN DE SOCKETS

En el presente captulo, se desarrolla una gua que recoge la explicacin de la metodologa general para la creacin de sockets, as como para el establecimiento de una comunicacin a travs de ellos. Para comprender cmo se crea y gestiona una conexin a travs de sockets, la metodologa a seguir, etc., se recomienda acudir a la Parte I Captulo 2, donde se documenta el desarrollo del software de comunicaciones, as como revisar detenidamente el cdigo completo de dicho software, a modo de ejemplo prctico, proporcionado en los anejos destinados a tal efecto en el presente proyecto. El objeto fundamental de este captulo es documentar convenientemente las APIs proporcionadas con el kit de desarrollo del mdulo Wi-Fi utilizado en este proyecto: archivos de cabecera en que se incluyen estas APIs, localizacin y contenidos fundamentales de los mismos, funciones a utilizar, definicin de las mismas, parmetros que utilizan y resultados que proporcionan.
79
1 Archivos de cabecera (*.h)

En esta seccin se hace un breve repaso a los archivos de cabecera que contienen las definiciones de parmetros y funciones utilizadas en el desarrollo del software de comunicaciones. Si se desea ms informacin acerca de los mismos, se recomienda su lectura detenida. A tal efecto, se proporcionan las rutas en las que se encuentran dentro de la instalacin del entorno de desarrollo para el mdulo considerado en este proyecto. Para cada uno de los archivos de cabecera, se ha seleccionado como objeto de estudio detallado el contenido que afecta especficamente a lo desarrollado en el presente proyecto, a fin de no extender la presente documentacin innecesariamente. El resto de definiciones y parmetros contenidos en cada archivo se explica someramente, advirtiendo su existencia y situndolos para facilitar su estudio en desarrollos futuros si se hace necesario. 1.1 sockapi.h Localizacin en el sistema de archivos: C:\netos60_gnu\h\sockapi.h En este archivo de cabecera se definen los prototipos de las funciones utilizadas para la gestin de sockets, as como los cdigos de error que generan en caso de que haya algn problema, que en caso de implementar control de errores en nuestro programa, ayudan a identificar y solucionar la fuente del error. La definicin ms importante que se hace, utilizada en nuestro programa a la hora de controlar si hay o no peticiones de conexin por parte de un cliente, es la de el parmetro SOCKET_ERROR, un entero de valor -1. De haber algn error, la funcin correspondiente devolver un -1, que podr ser identificado dentro de nuestro programa como SOCKET_ERROR o, simplemente como -1. Igualmente, se define el descriptor para los sockets como una variable de tipo entero, identificada como SOCKET. Ello hace que a la hora de crear un socket, la funcin utilizada para ello devuelva una variable de tipo entero que sirve para identificar el socket creado (Descriptor del socket). El descriptor del socket es el nombre que lo identifica, debiendo ser utilizado en todas las funciones de recepcin y envo de datos, cierre del socket, etc., como se detallar ms adelante.
80
Funciones definidas en este archivo, utilizadas en los programas desarrollados en este proyecto: SOCKET socket(int domain, int type, int protocol)
Funcin que crea un nuevo socket. Devuelve una variable de tipo SOCKET (O lo que es lo mismo, un entero), que es el descriptor del nuevo socket creado, que deber ser usado para identificarlo en adelante. De haber un error a la hora de crear el socket, la funcin devuelve SOCKET_ERROR (O lo que es lo mismo, -1). Parmetros de la funcin: 1. int domain: Variable de tipo entero que define la familia de direcciones a utilizar en este socket creado. Las definiciones posibles para esta variable se detallan en socket.h (Ver 1.2 Punto 2 en este mismo captulo). El valor ms usual es AF_INET (Correspondiente a un valor 2), que es la forma estndar de dar las direcciones en el protocolo de Internet (Forma decimal de cuatro campos entre 0 y 255 separados por puntos). 2. int type: Variable de tipo entero que define el tipo de socket a crear, esto es, fundamentalmente, un socket orientado a la transmisin de datagramas (Socket de protocolo UDP) o a la transmisin de streams (Socket de protocolo TCP), que es el caso. Para protocolo TCP, el valor del parmetro es SOCK_STREAM (Correspondiente con un valor 1). Para ver los otros valores posibles definidos, ver el apartado correspondiente a socket.h (1.2 Punto 2 en este captulo). 3. int protocol: Variable de tipo entero que define el protocolo a utilizar en el socket creado. Los posibles valores para este parmetro se definen en el archivo in.h (Ver apartado 1.3 de este captulo). En ente caso, el protocolo a utilizar es IP (Internet Protocol), que se corresponde con un parmetro IP_IP (O lo que es lo mismo, un valor 0).
int
bind(SOCKET s, struct sockaddr_in *addr, int addrlen)
81
Funcin que ata el socket creado anteriormente al puerto asignado en la red, a travs del cual se establecer la comunicacin. Para saber ms sobre cmo se establece una conexin por este medio, revisar Parte I Captulo 2 1. Una vez asignado un puerto a un socket, este puerto queda reservado de manera irreversible, no pudiendo ser reasignado a otro socket a menos que se reinicie el programa. Ni siquiera se libera al cerrar el socket, ya que no existe ninguna funcin para deshacer esta atadura. Tampoco se libera de forma automtica (Como sucede al programar sockets bajo Windows, por ejemplo). El entero que devuelve la funcin sirve para controlar errores en la operacin. En caso de no poderse completar el proceso, la funcin bind() devuelve SOCKET_ERROR. Parmetros de la funcin: 1. SOCKET s: Descriptor del socket al que atar el puerto, resultado del uso de la funcin socket() antes explicada. 2. struct sockaddr_in *addr: Puntero a estructura definida en el archivo in.h (Ver apartado 1.3 punto 3 en este mismo captulo para descripcin detallada de la misma, su creacin y configuracin con los datos necesarios), que almacena los datos referentes al puerto a utilizar, as como la familia de direcciones a utilizar, la direccin del servidor al que conectarse (En caso de funcionar como cliente, que no es lo que ocurre en este proyecto), y otros parmetros sin inters. 3. int addrlen: Variable de tipo entero que almacena el tamao de la estructura definida en el punto anterior. Por tanto, es el resultado de aplicar la funcin estndar de C, sizeof(), a la variable estructura utilizada en el parmetro anterior.
int
listen(SOCKET s, int backlog)
Funcin que coloca un socket en estado de escucha en un puerto a la espera de una peticin de conexin por parte de un cliente remoto. La funcin devuelve SOCKET_ERROR en caso de que la operacin no puede completarse, y 0 si
82
todo termina correctamente. El socket que se coloca a la escucha debe estar atado a un puerto y tener conexiones libres. Parmetros de la funcin: 1. SOCKET s: Descriptor del socket que se quiere colocar a la escucha. Previamente ha debido ser sometido a una operacin exitosa de bind(). 2. int backlog: Nmero de conexiones posibles a establecer con este socket. En el caso que nos ocupa, slo interesa conectarse a un nico usuario, por lo que el valor a utilizar ser 1.
int
accept(SOCKET s, struct sockaddr_in *addr, int *addrlen)
Funcin que acepta la peticin de conexin por parte de un cliente remoto, en caso de existir, tras haber colocado el socket a la escucha mediante el uso de la funcin listen(). Si no hay peticin de conexin alguna, la funcin devuelve SOCKET_ERROR. La forma de uso de esta funcin es la siguiente: se crea un socket auxiliar sobre el que monitorizar la existencia de conexiones entrantes conforme a lo explicado en lo referente a la funcin socket(). Se inicializa este socket al valor SOCKET_ERROR, y se entra en un bucle en el cual se ejecuta la funcin accept(), guardando su devolucin en el descriptor del socket auxiliar antes creado. Mientras que no haya conexiones entrantes, este descriptor continuar siendo SOCKET_ERROR, con lo que el bucle deber volver a ejecutarse. En el momento que haya una peticin de conexin entrante, la funcin accept() la aceptar, devolviendo un valor concreto sobre el descriptor del socket auxiliar y saliendo del bucle. Ese valor se corresponde a la identificacin del socket en el que se ha establecido la conexin satisfactoria. Para terminar, se asigna el valor del descriptor del socket auxiliar al socket inicialmente creado, que estaba a la escucha. A partir de este
momento, puede comenzar la recepcin y envo de datos a travs del socket. Para comprender sobre el papel el uso de esta funcin, vase el cdigo fuente de los programas desarrollados en el presente proyecto, contenido en los anejos destinados a tal efecto. Parmetros de la funcin:
83
1. SOCKET s: Descriptor de un socket previamente creado, atado a un puerto y colocado a la escucha en espera de conexiones entrantes. 2. struct sockaddr_in *addr: Puntero a variable de tipo estructura que permite almacenar la direccin del cliente remoto cuya peticin de conexin se ha aceptado, en caso de que sta est disponible en la red. El formato de la direccin contenida en esta estructura depender de los protocolos y familias de direcciones utilizados. Este parmetro puede definirse como NULL, caso en el cual, se desconocer la
direccin del equipo conectado al servidor. 3. int *addrlen: Puntero a variable de tipo entero para almacenar el tamao de la direccin del equipo conectado, contenida en la variable correspondiente al parmetro anterior. De igual modo, si se define como NULL, no se almacenarn datos del cliente remoto conectado.
int
recv(SOCKET s, char *buf, int len, int flags)
Funcin que permite recibir datos desde un cliente remoto conectado a travs de un socket. Los datos se reciben en un buffer establecido a tal efecto. La funcin devuelve un entero que representa el nmero de bytes recibidos. Si hay algn error al recibir, como por ejemplo que no haya ningn dato enviado por el cliente, la funcin devuelve SOCKET_ERROR (Es decir, -1). Parmetros de la funcin: 1. SOCKET s: Descriptor del socket a travs del cual est establecida la conexin con el cliente, y que ser la va por la que se acceder a los datos a leer. 2. char *buf: Cadena de caracteres que guardar los datos recibidos a travs del socket. Es un buffer intermedio que posibilitar trabajar con los datos recibidos tras completar la operacin de lectura. Deber tener una extensin suficiente para recoger todo lo enviado por el cliente. 3. int len: Variable de tipo entero que recoge la longitud de la cadena, en bytes, que sirve de buffer para guardar los datos recibidos a travs de la conexin. Puede ser resultado de aplicar la funcin strlen() (Librera
84
de C string.h) a la cadena de caracteres buffer. Establece el nmero mximo de datos a recibir por la conexin para evitar desbordar el buffer. 4. int flags: Opciones acerca de cmo se establece la conexin para la recepcin. En general, no es necesario configurar ninguna opcin de este tipo, por lo que el valor usual a utilizar ser 0.
int
send(SOCKET s, char *buf, int len, int flags)
Funcin que permite enviar datos a travs de la conexin establecida por el socket, al cliente remoto. Del mismo modo que la funcin recv(), los datos a enviar se proporcionan en una cadena de caracteres que hace las veces de buffer de envo. La funcin devuelve un entero que se corresponde con el nmero de bytes enviados a travs de la conexin como resultado de la ejecucin de la operacin. En caso de que no se realice el envo, devolver SOCKET_ERROR. Parmetros de la funcin: 1. SOCKET s: Descriptor del socket a travs del cual est establecida la conexin con el cliente, y que ser la va por la que se enviarn los datos. 2. char *buf: Cadena de caracteres que almacena los datos en espera de ser enviados a travs del socket. Es un buffer intermedio que posibilitar almacenar los datos a enviar. 3. int len: Variable de tipo entero que recoge la longitud de la cadena, en bytes, que sirve de buffer para guardar los datos a enviar a travs de la conexin. Puede ser resultado de aplicar la funcin strlen() (Librera de C string.h) a la cadena de caracteres buffer. Establece el nmero de datos a enviar al cliente. 4. int flags: Opciones acerca de cmo se establece la conexin para la recepcin. En general, no es necesario configurar ninguna opcin de este tipo, por lo que el valor usual a utilizar ser 0.
Manual de usuario. Creacin y gestin de sockets int closesocket(SOCKET s)
85
Funcin que cierra un socket, y con l la conexin establecida a travs del mismo, una vez que ya no se desea continuar con una conexin o bien, si se detecta algn error en algn momento de las fases de creacin, escucha, binding, conexin, etc. Al no poder liberarse tambin el puerto, en caso de romperse la conexin, ser necesario efectuar un reset del programa. La funcin devuelve 0 si todo se desarrolla normalmente y SOCKET_ERROR si hay algn problema a la hora de cerrar el socket. Parmetros de la funcin: 1. SOCKET s: Descriptor del socket que se desea cerrar.
1.2 socket.h Localizacin en el sistema de archivos: C: \netos60_gnu\h\tcpip\socket.h Este archivo de cabecera contiene importantes definiciones de variables y parmetros utilizados en las funciones destinadas a la creacin y gestin de comunicaciones basadas en sockets, entre ellas, las descritas en el apartado anterior (Ver 1.1 en este mismo captulo). Adems de los parmetros y variables que se detallarn a continuacin, por ser los utilizados en el software desarrollado para el presente proyecto, se declaran constantes para el establecimiento y lectura de las opciones de configuracin de los sockets (Revisar las funciones utilizadas para ello en caso necesario, setsockopt() y getsockopt(), declaradas en sockapi.h, no detalladas en la presente documentacin por no ser necesario cambiar la configuracin de los sockets por defecto. Puede ser til consultar para comprender su funcionamiento el recurso [9], de Microsoft.). Tambin se declaran gran cantidad de estructuras utilizadas para el uso de sockets de otros protocolos distintos al utilizado en el presente proyecto, TCP/IP. De todos modos, en la presente documentacin slo se har referencia expresa a los recursos utilizados en este proyecto. Son los siguientes: Declaracin de constantes para indicar la familia de direcciones a utilizar entre otras, como parmetro domain en la funcin socket() (Ver 1.1
86
sockapi.h). Valor ms comn utilizado: AF_INET (Forma estndar de indicar las direcciones en formato de puntos). Declaracin de constantes para indicar el tipo de socket a abrir, como parmetro type en la funcin socket() (Ver 1.1 sockapi.h). Valor utilizado en el presente proyecto: SOCK_STREAM (Correspondiente a socket TCP). 1.3 in.h Localizacin en el sistema de archivos: C:\netos60_gnu\h\tcpip\in.h Este archivo de cabecera contiene multitud de definiciones de constantes, estructuras y funciones fundamentalmente destinadas al trabajo con sockets en lo que a almacenamiento, conversin y gestin de formatos de direcciones y puertos se refiere, as como ms opciones de configuracin para adaptar el funcionamiento de los diferentes sockets de mltiples protocolos. De entre todo lo definido dentro de este importante archivo de cabecera, lo correspondiente o relacionado con el software desarrollado en el presente proyecto se detalla a continuacin: Estructura utilizada en la funcin bind() (Ver 1.1 sockapi.h) para configurar el puerto al que atar el socket, y, si es necesario, la direccin IP del servidor, as como el parmetro que define la familia de direcciones utilizada. Hay que mencionar que se equiparan dos nombres equivalentes para designar la misma estructura: sockaddr_in e in_sockaddr. La forma de la estructura es la siguiente:
struct in_sockaddr { i16 u16 struct char }; sin_family; sin_port; in_addr sin_addr; sin_zero[8];
Manual de usuario. Creacin y gestin de sockets Cada uno de los elementos de la estructura representa lo siguiente:
87
1. i16 sin_family: Familia de direcciones a utilizar. Entero de 16 bits. Ver 1.2 socket.h. Valor utilizado correspondiente al estndar habitual de direcciones para Internet: AF_INET 2. u16 sin_port: Puerto al que atar el socket. El nmero de puerto se proporciona como un entero de 16 bits transformado a formato de red mediante la aplicacin del modificador htons() tambin definido en este mismo archivo de cabecera. Para aclarar la configuracin de este parmetro, consultar el cdigo fuente completo del programa de prueba de comunicaciones o del hilo de proceso para comunicacin Wi-Fi, proporcionado en los anejos destinados a tal efecto en el presente proyecto. 3. struct in_addr sin_addr: Estructura que almacena la direccin IP del servidor que gestiona la conexin. Para simplificar la operacin de bind() al crear un servidor, puede utilizarse como direccin una genrica representada por la constante INADDR_ANY, declarada tambin en este mismo archivo de cabecera. La direccin debe tener un formato de 32 bits y ser transformada a formato de red mediante la aplicacin del modificador htonl() definido en este archivo. Consultar cdigo fuente para aclaracin del uso de esta estructura. La subestructura struct in_addr tambin se define en este archivo de cabecera de la siguiente manera:
struct in_addr { u32 s_addr; };
La variable u32 s_addr es la que almacena la direccin IP correspondiente. 4. char sin_zero[8]: No es relevante. No necesita configuracin alguna.
88
Declaracin de constantes para indicar el tipo de protocolo IP para el socket a abrir, como parmetro protocol en la funcin socket() (Ver 1.1 sockapi.h). Valor utilizado en el presente proyecto: IP_IP (Valor 0. Correspondiente a Internet Protocol).
Manual de usuario. Configuracin y uso del puerto serie RS232
89
Captulo 2 CONFIGURACIN Y USO DEL

PUERTO SERIE
RS232
El objeto de este captulo es proporcionar, al estilo de lo realizado en el captulo anterior, una documentacin que recoja el modo de utilizar los puertos serie con los que cuenta el mdulo Wi-Fi utilizado como principal recurso en este proyecto. A tal efecto, se detallarn los archivos de cabecera que contienen las APIs proporcionadas con el entorno de desarrollo para todo lo referente al puerto serie, prestando especial atencin a la explicacin de las funciones que permiten abrir y configurar los puertos serie del mdulo, as como enviar datos a travs del mismo. El objeto de este captulo se limita a la documentacin de las herramientas de programacin ya mencionadas. Para completar la comprensin del
funcionamiento del puerto serie, se recomienda acudir a la Parte I Captulo 3, donde se detalla el desarrollo del software que incluye la comunicacin serie realizado en el presente proyecto. All se detalla la metodologa y base conceptual del uso de los puertos serie. Asimismo es recomendable consultar el cdigo fuente completo proporcionado en los anejos de este proyecto, a modo de ejemplo ilustrativo de utilizacin de las funciones aqu descritas.
90
1 Archivos de cabecera (*.h)

En esta seccin se hace un breve repaso a los archivos de cabecera que contienen las definiciones de parmetros y funciones utilizadas en el desarrollo del software de comunicaciones por va serie RS232. Si se desea ms informacin acerca de los mismos, se recomienda la lectura detenida de ellos. A tal efecto, se proporcionan las rutas en las que se encuentran dentro de la instalacin del entorno de desarrollo para el mdulo considerado en este proyecto. Para cada uno de los archivos de cabecera, se ha seleccionado como objeto de estudio detallado el contenido que afecta especficamente a lo desarrollado en el presente proyecto, a fin de no extender la presente documentacin innecesariamente. El resto de definiciones y parmetros contenidos en cada archivo se explica someramente, advirtiendo su existencia y situndolos para facilitar su estudio en desarrollos futuros si se hace necesario. Es necesario resear que para la gestin de puertos serie, el entorno de desarrollo proporciona dos APIs diferentes, debiendo seleccionarse una de ellas para realizar nuestro programa. En este proyecto, se ha seleccionado la API ms moderna de las dos, al ser ms fcil de utilizar, ya que se encuentra mejor documentada. Adems, la API antigua est tendiendo al desuso total, recomendndose utilizar siempre la nueva API para desarrollar nuevos programas. La API utilizada es la contenida en el archivo de cabecera termios.h, que se explicar detalladamente en este captulo. La otra API proporcionada est contenida en el archivo de cabecera netosIo.h, que obviamente, no se detallar en el presente manual. Simplemente, queda mencionada su existencia. El tener que elegir una de las dos posibilidades, hace imprescindible comprobar que el entorno de desarrollo y el compilador estn configurados para funcionar conforme a las especificaciones de dicha API en lo que al puerto serie se refiere. Para ello, hay que acceder al archivo bsp.h, localizado en la siguiente ruta: C:\netos60_gnu\src\bsp\platforms\connectwime\bsp.h En dicho archivo, hay que localizar la lnea correspondiente a la configuracin de la API utilizar, y comprobar que se encuentra en el siguiente estado:
#define BSP_SERIAL_PORT_API BSP_SERIAL_API_TERMIOS
91
Si la constante BSP_SERIAL_PORT_API en lugar de estar puesta al valor BSP_SERIAL_API_TERMIOS, correspondiente a la API que queremos utilizar, se encuentra definida como BSP_SERIAL_API_LEGACY, quiere decir que el entorno de desarrollo est configurado para utilizar la API errnea. En ese caso, cambiar el valor a BSP_SERIAL_API_TERMIOS, guardar el archivo, y recompilar el entorno de desarrollo segn se explica en el siguiente captulo de este manual (Ver Parte IVCaptulo 31). El chip integrado en el mdulo Wi-Fi cuenta con dos puertos serie que pueden utilizarse libremente. Para poder utilizarlos con esta API, es necesario que en el mismo archivo mencionado anteriormente, bsp.h, respectivamente las constantes BSP_SERIAL_PORT_1 y BSP_SERIAL_PORT_2, estn definidas como BSP_SERIAL_UART_DRIVER, de manera que se implemente el driver UART para cada uno de los puertos al recompilar el entorno de desarrollo de la misma forma que se mencion anteriormente (Ver Parte IVCaptulo 31). Una vez comentada la seleccin y manera de configuracin de la API a utilizar, se procede a detallar el contenido de los archivos de cabecera de inters.
1.1 serParam.h Localizacin en el sistema de archivos: C:\netos60_gnu\h\serParam.h El inters de este archivo de cabecera es bastante reducido, ya que su contenido responde nicamente a definiciones de parmetros y opciones de todo tipo para su uso con la API antigua que en este proyecto no tiene absolutamente inters alguno. La nica razn para haber decidido incluirla en el cdigo desarrollado segn la API moderna es que en l se encuentran definidas todas las posibilidades del mdulo en lo que a baudrates se refiere y algunas opciones de configuracin extra ms claramente definidas que en el archivo de la otra API, pero igualmente vlidas. Atendiendo a la configuracin para la UART de los PICs de la TCS, detallada en la Tabla 6: Parmetros de configuracin del puerto serie, el parmetro a utilizar ser SIO_57600_BAUD, correspondiente, como es obvio, a una velocidad de transferencia de 57600 baudios del puerto serie.
Manual de usuario. Configuracin y uso del puerto serie RS232 1.2 termios.h Localizacin en el sistema de archivos: C: \netos60_gnu\h\termios.h
92
Este archivo de cabecera contiene toda la informacin referente al uso de la API de gestin de puertos serie. En este sentido, presenta una gran ventaja respecto a lo tratado en el captulo anterior en lo referente a la gestin de sockets, y es que toda la informacin se concentra en este nico archivo, con lo que es ms fcil asociar las declaraciones de las funciones y el significado de sus parmetros, los tipos de variables especiales creados, etc. A continuacin se hace una descripcin detallada de cada una de las funciones utilizadas para el control del puerto serie en este proyecto, as como de tipos de variables o valores de constantes definidos de forma especfica para este uso, y su aplicacin:
int
open(char *port, option)
Funcin que permite abrir un puerto serie para comenzar a recibir o enviar datos a travs de l. Devuelve un entero que es el descriptor del puerto serie, que lo identifica a la hora de utilizar el resto de funciones. Si no puede llevarse a cabo la apertura, se devuelve -1 para indicar el error. Parmetros de la funcin: 1. char *port: Cadena de caracteres que identifica cul de los puertos serie existentes se est intentando abrir. El chip Net+ARM incluido en el mdulo Wi-Fi cuenta con dos puertos serie RS232 cuyos identificadores al efecto de uso como este parmetro son por defecto respectivamente /com/0 y /com/1. Para ms
informacin acerca de cmo cambiar estos nombres por defecto, consultar el archivo ntegro termios.h. 2. option: Parmetro que indica el modo de apertura para el puerto serie. Se definen, entre otras, las siguientes posibilidades: a) O_RDONLY: Abrir para slo lectura. b) O_WRONLY: Abrir para slo escritura.
Manual de usuario. Configuracin y uso del puerto serie RS232 c) O_RDWR: Abrir para lectura y escritura.
93
int
tcsetattr(int fd, int optional_actions, struct termios * termios_p)
Funcin que permite cambiar las opciones de configuracin correspondientes para la UART del puerto serie previamente abierto. Devuelve 0 en caso de xito en la operacin, y -1 en caso contrario. Parmetros de la funcin: 1. int fd: Descriptor del puerto serie a configurar, resultado de una operacin de open() satisfactoria. 2. int optional_actions: Opciones de configuracin adicionales que modifican el momento de hacer efectivos los cambios de configuracin. La ms comn es TCSANOW, que hace efectivos los cambios inmediatamente. Para opciones de configuracin adicionales, consultar directamente este archivo de cabecera, termios.h. 3. struct termios *termios_p: Puntero a una estructura que almacena las opciones de configuracin a establecer. La definicin de la misma, realizada en este mismo archivo de cabecera, es la siguiente:
struct termios { tcflag_t c_iflag; tcflag_t c_oflag; tcflag_t c_cflag; tcflag_t c_lflag; tcflag_t c_xflag; cc_t c_cc[NCCS]; speed_t baud; }; /* input modes */ /* output modes */ /* control modes */ /* local modes */ /* Xtra flags */ /* control chars */
En el propio archivo se definen los tipos de variable tcflag_t, cc_t y speed_t como equivalentes a unsigned long. La variable speed_t
94
baud almacena la velocidad de transmisin de datos del puerto, en baudios; para actualizar su valor con una velocidad concreta a fin de cambiar la configuracin del puerto, debern usarse las funciones cfsetospeed() cfsetispeed(), descritas ms adelante en este mismo captulo. En el propio termios.h aparecen detalladas las posibles opciones a establecer en cada uno de los campos de la estructura termios. Para el caso particular de este proyecto, adems de la velocidad de transmisin, todas las opciones a configurar (Ver Tabla 6) estn comprendidas dentro de la variable c_cflag, y se configuran haciendo la suma de todas ellas mediante el operador |. Es decir:
(SIO_NO_HANDSHAKING | CS8 | SIO_ONE_STOP_BIT | SIO_NO_PARITY)
Notar que los valores de las constantes que indican los parmetros de configuracin, estn definidos en el archivo serParam.h (Ver 1.1 en este mismo captulo). En realidad, no es necesario configurar en principio ms que el nmero de bits por carcter, ya que todo lo dems viene bien configurado por defecto, pero se ha juzgado conveniente realizar la configuracin completa como medio de significar de manera explcita en el cdigo el funcionamiento exacto del puerto serie. Para una mejor comprensin de la metodologa utilizada a la hora de asignar estos valores a la estructura se recomienda acudir al cdigo fuente completo proporcionado en anejos al final de este proyecto.
int
tcgetattr(int fd, struct termios * termios_p)
Funcin que permite leer la configuracin actual del puerto serie, til despus de efectuar la operacin de configuracin para comprobar que todos los parmetros se han establecido correctamente. La funcin devuelve 0 si todo se ejecuta correctamente, y -1 si se produce algn error en el proceso. Parmetros de la funcin:
95
1. int fd: Descriptor del puerto serie cuyos parmetros actuales de configuracin deseamos leer. 2. struct termios *termios_p: Puntero a estructura de tipo termios (Ver definicin de la misma dentro de la descripcin de la funcin inmediatamente anterior a la que nos ocupa), destinada a almacenar la configuracin del puerto serie leda por tcgetattr().
int
cfsetospeed(struct termios * termios_p, speed_t speed)
Funcin que permite configurar la velocidad de transmisin de datos del puerto serie. La funcin configura la velocidad de datos salientes, pero al mismo tiempo queda establecida la de datos entrantes, ya que el driver no permite velocidades asimtricas para entrada y salida. Por tanto, es indiferente el uso de esta funcin o de cfsetispeed(). Esta funcin actualiza el valor del parmetro correspondiente a la velocidad de transmisin en la estructura termios proporcionada como parmetro, y posteriormente deber transmitirse esta configuracin al puerto serie correspondiente utilizando la funcin antes detallada tcsetattr(), con esta misma estructura conteniendo la velocidad ya configurada como parmetro. Esta funcin devuelve un 0 si se actualiza el valor en la estructura correctamente. Parmetros de la funcin: 1. struct termios *termios_p: Puntero a la estructura de tipo termios (Ver definicin de estructura termios en puntos precedentes de este apartado) cuyo campo correspondiente a velocidad de transferencia de datos queremos actualizar al nuevo valor para posteriormente configurar el puerto serie. 2. speed_t speed: Variable equivalente a un tipo unsigned long que indica la velocidad de transferencia que queremos establecer para el puerto serie (Ver archivo serParam.h en 1.1 de este mismo captulo para conocer una lista completa de las posibles velocidades de transferencia que pueden establecerse para los puertos serie proporcionados por el chip Net+ARM incluido en el mdulo).
Manual de usuario. Configuracin y uso del puerto serie RS232 speed_t cfgetospeed(struct termios * termios_p)
96
Funcin que permite extraer la informacin referente a la configuracin de la velocidad de transferencia de datos salientes de un puerto serie, de una estructura termios resultado de la lectura de la configuracin de dicho puerto a travs de tcgetattr(). La funcin devuelve una variable de tipo speed_t (O lo que es lo mismo, unsigned long) que se corresponde con la velocidad en baudios a la que est configurado el puerto en cuestin. Como ya se ha dicho antes, el driver no permite la configuracin asimtrica del puerto (Es decir, velocidades diferentes para la entrada y la salida de datos), por lo que es indiferente utilizar a este fin la funcin descrita en este apartado o su homloga para velocidades de transferencia de datos entrantes cfgetispeed(). Parmetros de la funcin: 1. struct termios *termios_p: Puntero a estructura de tipo termios de la cual queremos extraer la velocidad de transferencia a la que est configurado el puerto cuya configuracin se refleja en la propia estructura.
int
write(int fd, char *sendbuf, int bytetosend)
Funcin que permite enviar datos a travs del puerto serie. Devuelve un entero que se corresponde con el nmero de bytes escritos de forma satisfactoria en el puerto. En caso de producirse un error al acceder al puerto para escritura, se devolver -1. Parmetros de la funcin: 1. int fd: Descriptor del puerto serie en el cual se quieren escribir los datos a enviar. 2. char *sendbuf: Inicio de la cadena de caracteres que se quiere enviar a travs del puerto serie. 3. int bytetosend: Nmero de caracteres que se quieren enviar en la operacin de escritura. Puede ser la longitud total de la cadena de caracteres a enviar o no. Los caracteres se envan uno a uno por el
97
puerto serie, y esta operacin se repite cclicamente hasta haber enviado el nmero de caracteres indicado por este parmetro.
Anlogamente a la funcin write() descrita en este punto, existe una funcin read() para leer datos enviados por otro dispositivo a travs del puerto serie, que se opera de forma anloga a la de escritura.
int
close(int fd)
Funcin que permite cerrar el puerto serie una vez terminada la necesidad de su uso. Devuelve 0 si el cierre del puerto se efecta correctamente, y -1 si se produce algn error. Parmetros de la funcin: 1. int fd: Descriptor del puerto serie a cerrar.
Existen algunas funciones adicionales a las aqu explicadas, definidas en el archivo termios.h para enviar o recibir datos a travs del puerto serie en condiciones especiales, gestionar las colas de datos de entrada y salida, etc. En caso de necesitarse informacin adicional, consultar el propio archivo termios.h. Se aconseja recurrir al cdigo fuente completo referente a la comunicacin serie con la TCS proporcionado en el presente proyecto como ejemplo prctico de aplicacin de todo lo detallado en este captulo del manual.
Manual de usuario. Entorno de desarrollo
98
Captulo 3 ENTORNO DE DESARROLLO

En el presente captulo del manual de usuario, se pretende proporcionar una sencilla gua que abarque todos los aspectos bsicos en lo que al uso del entorno de desarrollo proporcionado con el mdulo se refiere, a saber, aspectos prcticos y gua paso a paso acerca de: Cmo compilar tanto los programas realizados para el mdulo como el propio entorno de desarrollo en el caso de que sea necesario cambiar su configuracin. Archivos que es necesario incluir en nuestros programas con las opciones de compilacin y configuracin de entradas, salidas, etc. Cmo cargar los programas en la RAM del mdulo para ejecutarlos y depurarlos. Una vez consolidados, cmo escribirlos en la Flash ROM para que se ejecuten automticamente al reiniciar el mdulo, sin necesidad de cargarlos desde el PC, etc. El que se proporcione este manual adaptado a las necesidades de este proyecto en concreto, aadiendo informacin til y consejos prcticos que no aparecen en los manuales proporcionados por el fabricante, no quiere decir que se hagan innecesarios dichos manuales, ya que contienen informacin adicional que puede ser de utilidad en posibles ampliaciones futuras del presente proyecto, o para dar otros usos diferentes al mdulo. Dicho mdulo ofrece un abanico de posibilidades muy amplio, si bien a cambio de resultar poco intuitivo y farragoso en el proceso de desarrollo, en gran medida por una ausencia de documentacin que este manual pretende paliar en la medida de lo posible, como fruto del trabajo de documentacin que ha consumido gran parte de este proyecto, convirtindose en objetivo prioritario.
99
1 Compilacin del entorno de desarrollo

La primera vez que se utiliza el entorno de desarrollo tras la instalacin del software que acompaa al mdulo, as como siempre que se haga necesario hacer algn cambio de configuracin de los drivers, dispositivos, etc., en el mismo, habr que compilarlo para nuestro dispositivo en particular (DIGI Connect WiMe). Los pasos a seguir para compilar el entorno de desarrollo son los siguientes:
1. Abrir la utilidad de compilacin: Programas\NET +OS 6.0e GNU\GNU X-Tools v3.0 Shell 2. Seleccionar el juego de instrucciones a utilizar para el micro en concreto, escribiendo en la lnea de comandos: xtools arm-elf 3. Acceder al directorio en el que se encuentra el entorno de desarrollo, escribiendo en lnea de comandos: cd c:/netos60_gnu/src/bsp 4. Ejecutar las rdenes de compilacin para la plataforma en concreto que estamos utilizando, escribiendo sucesivamente en lnea de comandos: make PLATFORM=connectwime clean make PLATFORM=connectwime all 5. Si no se muestra ningn error en pantalla, el entorno de desarrollo se habr recompilado satisfactoriamente, implementando los cambios realizados en la configuracin.
100
2 Compilacin y carga de programas en el mdulo

A la hora de afrontar la creacin de un programa para el mdulo, es necesario considerar que, aparte de los archivos *.c y *.h de todo programa realizado en lenguaje C que sean necesarios, hay que crear una carpeta que contenga otros archivos necesarios para establecer las opciones del compilador, de los puertos, etc. A tal efecto, debe crearse una carpeta que recoja todos los archivos del programa, cuyo nombre no debe contener espacios ni tildes, etc., para que sea accesible desde el compilador. Dentro de esa carpeta deben crearse los diferentes archivos *.c y *.h, y dos archivos ms, que en todos los ejemplos proporcionados se denominan root.c y appconf.h. Su contenido y funcin se describen a continuacin. Es conveniente partir de dos archivos realizados para un ejemplo determinado, y adaptarlos a nuestras necesidades particulares, ya que su configuracin es siempre la misma, y basta con cambiar contados parmetros que se detallan en las siguientes lneas.
Archivo appconf.h: Debe estar incluido en el archivo root.c, existiendo la lnea:

#include <appconf.h>
En este archivo de cabecera se encuentran las opciones de configuracin concretas para ese programa en lo referente fundamentalmente a si al iniciar el programa se pedirn los parmetros de configuracin de la placa y el mdulo, a saber, direccin IP, punto de acceso a la red, clave de acceso, direccin MAC, etc., y cul es el puerto serie por el que se establecer dicha comunicacin. Tambin puede especificarse hacia qu puerto serie se dirigirn las instrucciones de entrada y salida del programa (Es decir, los printf() que se utilicen), el ttulo con el que se identificar el programa en el dilogo con el PC, de existir (Comunicacin a travs del puerto serie, mediante HyperTerminal), etc. Es recomendable leer detenidamente todas las posibilidades a configurar, pero en general, no es necesario cambiar nada excepto el nombre identificador del programa, pudiendo incluirse el archivo tal cual. Notar que por defecto, la comunicacin con el PC para pedir los datos de configuracin y la salida
101
de los printf() estn preparados para establecerse a travs del /com/0, debiendo tenerse esto en cuenta para los programas que utilicen el puerto serie, abriendo el puerto /com/1 o teniendo cuidado de establecer en este archivo las opciones pertinentes a tal efecto.
Archivo root.c: Este archivo tiene una importancia clave, ya que es en el que se crean los hilos de proceso que sern los responsables de iniciar la ejecucin de las funciones principales de nuestros programas. As, las funciones que deban iniciarse al iniciar el programa, debern incluir como parmetro una variable de thread. Ejemplo:
void servidor(ULONG thread_input)
La funcin servidor() ser iniciada automticamente por un hilo de proceso creado en el root.c correspondiente. La mejor manera de explicar la utilizacin de este archivo es analizar un ejemplo comentado. En el ejemplo que sigue, se crea un nico hilo de proceso que deber arrancar la funcin servidor antes mencionada.
/***************************************************************** * * En este archivo se crean los hilos necesarios para cada * aplicacin. * Es suficiente con crear tantos punteros a void y bloques de * control como hilos vayamos a necesitar, reservar memoria e * iniciar cada uno de ellos de manera anloga a como se hace en * este ejemplo con el hilo del servidor, cambiando slo el * identificador del hilo y el puntero al stack. * * *****************************************************************/
#include #include #include #include #include #include
<stdio.h> <stdlib.h> <tx_api.h> <bsp_api.h> <appconf.h> <sysAccess.h>
/* * Set this to 1 to run the system POST tests during startup. */ const int APP_POST = 0;
/* * Set this to 1 to run the manufacturing burn in tests. */ int APP_BURN_IN_TEST = 0;

#define STACK_SIZE TX_THREAD 4096 servidorprueba; //Bloque de control para //el hilo de proceso. //crear uno diferente //para cada hilo de //proceso que vayamos //a iniciar
102
extern void
servidor(ULONG thread_input); //Prototipo de la //funcin que iniciar el hilo //Poner aqu todos los //prototipos de las funciones //que deban ser iniciadas //automticamente por cada //hilo, en este caso slo una //porque slo crearemos un hilo.
/* * * * * * * * * * * * * * * * * * * * * * * * * */
Function: void applicationTcpDown (void) Description: This routine will be called by the NET+OS root thread once every clock tick while it is waiting for the TCP/IP stack to come up. This function can increment a counter everytime it's called to keep track of how long we've been waiting for the stack to start. If we've been waiting too long, then this function can do something to handle the error. This function will not be called once the stack has started. Parameters: none Return Values: none
void applicationTcpDown (void) { static int ticksPassed = 0; ticksPassed++; /* * Code to handle error condition if the stack doesn't come up goes here. */ } /* * * * * * * * * * * * * * * * * * *
Function: void applicationStart (void) Description: This routine is responsible for starting the user application. It should create any threads or other resources the application needs. ThreadX, the NET+OS device drivers, and the TCP/IP stack will be running when this function is called. Parameters: none Return Values:

* * */ none
103
void applicationStart (void) { void *stack; int ccode; //Creamos tantos punteros a void como hilos //vaya a haber. En este caso, slo uno //Parmetro para controlar que no haya error //al crear el hilo. Slo hace falta uno.
/*
Add application Username and password to the System Access Database */ NAsetSysAccess (NASYSACC_ADD, "Netsilicon", "sysadm", NASYSACC_LEVEL_RW, 0); stack = malloc (STACK_SIZE); //Reservamos memoria para el //stack de cada hilo
if (stack == NULL) { netosFatalError ("Unable to allocate thread stack.", 5,5); } /*Creamos el hilo, recordar cambiar para cada uno el bloque de control, el nombre, la funcin de entrada y el stack. Para crear cada hilo, habr que repetir siempre la misma funcin que sigue, es decir, tx_thread_create(), pero poniendo en cada una los cuatro parmetros correspondientes a cada hilo, a saber, el bloque de control (control block), el nombre del hilo (thread name), que puede ser el que queramos, el nombre de la funcin que deber iniciar (entry function), y el puntero al stack (stack), que es el puntero a void que creamos al inicio del fichero y sobre el que anteriormente reservamos la memoria.*/
ccode = tx_thread_create (&servidorprueba,/* control block for thread*/ "Servidor", /* thread name*/ servidor, /* entry function*/ 0, /* parameter*/ stack, /* start of stack*/ STACK_SIZE, /* size of stack*/ NABspMediumPriority, /* priority*/ NABspMediumPriority, /* preemption threshold */ 1, /* time slice threshold*/ TX_AUTO_START); /* start immediately*/
if (ccode != TX_SUCCESS) //Control de errores { netosFatalError ("Unable to create thread.", 5, 5); } }
Si se desea contemplar un ejemplo de creacin de varios hilos a fin de fijar lo hasta ahora detallado, acudir al archivo root.c correspondiente al software completo desarrollado en este proyecto, donde se crean dos hilos de proceso, uno para la comunicacin Wi-Fi y otro para la comunicacin serie.
Adems de estos dos archivos, en la carpeta correspondiente a nuestro programa deberemos crear una subcarpeta denominada 32b en todos los ejemplos proporcionados. Esta carpeta albergar todos los archivos generados al compilar,
104
tales como las imgenes a escribir en memoria RAM (image.elf), til para operaciones de depuracin, y la que finalmente se escribir en la Flash ROM del microprocesador, quedando almacenada en el mismo de forma definitiva (image.bin). Pues bien, en esta subcarpeta, antes de compilar, han de copiarse dos archivos fundamentales, uno denominado makefile, sin extensin alguna, y otro denominado gdbconnectwime.raven, que puede encontrarse en C:\netos60_gnu, y ser copiado a nuestro subdirectorio 32b. El archivo gdbconnectwime.raven contiene las particularidades propias de la plataforma utilizada en el presente proyecto, y deber ser ejecutado antes de cargar los programas en la RAM del mdulo como se explicar ms adelante. En lo que al archivo makefile se refiere, contiene la informacin de compilacin en lo que a archivos a compilar e imgenes a generar se refiere. Se trata de un archivo editable con cualquier editor de texto, como wordpad o similar, pero no debe tener extensin alguna, a fin de ser localizado automticamente por el compilador. En este archivo deben indicarse cules son los archivos *.c a compilar en nuestro programa, cul es el ttulo de dicho programa y si queremos que se generen las imgenes para RAM y ROM, o slo alguna de ellas. En general, bastar con actualizar el campo APP_DESCRIPTION con el nombre del programa que deseemos para identificarlo, y el campo APP_C_FILES con los archivos a compilar. Ejemplo:
APP_DESCRIPTION="Programa de control remoto de robot mvil" APP_C_FILES=root.c \ controlRemoto.c
As indicaramos al compilador que debe compilar los archivos root.c y controlRemoto.c, los cuales debern estar localizados en el directorio que hayamos creado para la aplicacin, y que contiene la carpeta 32b donde se encuentra el mencionado archivo makefile.
Manual de usuario. Entorno de desarrollo 2.1 Compilacin del programa
105
Una vez creado el sistema de archivos descrito en el anterior epgrafe, la carpeta conteniendo el programa deber colocarse en el siguiente directorio: C:\netos60_gnu\src\examples\ Con la carpeta colocada en dicha ubicacin tenemos todo lo necesario para compilar el programa. Para ello, los pasos a seguir son los siguientes: 1. Abrir la utilidad de compilacin: Programas\NET +OS 6.0e GNU\GNU X-Tools v3.0 Shell 2. Seleccionar el juego de instrucciones a utilizar para el micro en concreto, escribiendo en la lnea de comandos: xtools arm-elf 3. Acceder al directorio en el que se encuentra programa a compilar, escribiendo en lnea de comandos: cd c:/netos60_gnu/src/examples/(Nombre carpeta programa)/32b 4. Ejecutar las rdenes de compilacin para la plataforma en concreto que estamos utilizando, escribiendo sucesivamente en lnea de comandos: make PLATFORM=connectwime clean make PLATFORM=connectwime all Si no se muestra ningn error en pantalla, el programa se habr compilado satisfactoriamente, habindose generado dentro del directorio 32b los archivos compilados correspondientes.
2.2 Carga del programa en RAM A fin de comprobar el correcto funcionamiento de nuestro programa, lo ms indicado es cargarlo en un principio en la memoria RAM del mdulo, lo que permitir ejecutarlo a travs del debugger, pero teniendo en cuenta que al resetear el mdulo o desconectar la alimentacin, el programa se perder, y el mdulo se reinicializar con el programa que en ese momento tenga grabado en la memoria
106
permanente Flash ROM. El mtodo para cargar los programas en RAM es el siguiente: 2.2.1 Realizacin del montaje Insertar el mdulo Wi-Fi en el zcalo correspondiente de la placa de desarrollo. Conectar el cable serie a uno de los puertos del ordenador y al COM0 de la placa de desarrollo. Insertar el conector del cable programador OCDemon en los conectores JTAG que se encuentran junto al mdulo. Conectar el cable programador al puerto paralelo del PC. Conectar las alimentaciones de la placa de desarrollo y del cable programador. 2.2.2 Proceso de carga 1. Iniciar la comunicacin por va serie de la placa de desarrollo con el PC a travs del programa HyperTerminal, ejecutando: Programas\NET +OS 6.0e GNU\HyperTerminal Connection on Com1 Programas\NET +OS 6.0e GNU\HyperTerminal Connection on Com2 Dependiendo de a qu puerto serie del ordenador se ha conectado el cable correspondiente. El programa debe estar configurado para comunicarse a 9600 baudios, 8 bits por carcter, sin paridad y 1 bit de stop. 2. Iniciar el programa que transforma las seales de programacin enviadas desde el ordenador a travs del puerto paralelo a seales JTAG para programar el microprocesador: Programas\NET +OS 6.0e GNU\OcdLibRemote 3. Iniciar la utilidad de compilacin: Programas\NET +OS 6.0e GNU\GNU X-Tools v3.0 Shell
107
4. Seleccionar el juego de instrucciones a utilizar para el micro en concreto, escribiendo en la lnea de comandos: xtools arm-elf 5. Acceder al directorio del programa que ya tenemos compilado donde se encuentra la imagen a cargar: cd c:/netos60_gnu/src/examples/(Nombre carpeta programa)/32b 6. Iniciar el programa de carga y depuracin indicando la imagen que ha de cargarse en RAM, escribiendo en la lnea de comandos: gdbtk se image.elf 7. En la nueva ventana de programa que se ha abierto, correspondiente al programa de depuracin y carga, abrir la consola de comandos seleccionando en el men contextual: ViewConsole 8. Se abrir una ventana de comandos vaca con un identificador (gdb). Cargar las particularidades de la plataforma en concreto, ejecutando el archivo previamente copiado a la subcarpeta 32b de la carpeta principal de nuestro programa, gdbconnectwime.raven, escribiendo: source gdbconnectwime.raven 9. Aparecer un mensaje de confirmacin preguntando si queremos cambiar el tamao de los paquetes de datos. Aceptar. 10. Iniciar la carga del programa en RAM escribiendo el comando load en la consola. 11. La carga tarda alrededor de un par de minutos en completarse. Al terminar, aparece de nuevo la lnea de comandos esperando instrucciones. Para iniciar la ejecucin del programa, introducir el comando c.
Nota: Es bastante habitual que la carga del programa sea fallida, o bien que a la hora de ejecutarlo, no se inicie. En ese caso, resetear la placa de desarrollo, bien
108
mediante el pulsador de reset con que cuenta, bien desconectando y volviendo a conectar la alimentacin, desconectar la alimentacin del cable de programacin y volver a conectarla, cerrar todos los programas e iniciar de nuevo el proceso antes descrito.
2.3 Carga del programa en Flash ROM Cuando ya se ha comprobado el correcto funcionamiento del programa desarrollado, es necesario grabarlo de manera definitiva en la memoria ROM del mdulo, para que se inicie de manera automtica al conectar la alimentacin o resetear la placa, sin tener que realizar siempre el proceso de carga desde el PC. La actualizacin de la memoria Flash se realiza a travs de un servidor ftp que debe estar funcionando en el mdulo. Este servidor viene preinstalado de fbrica, pero se ha eliminado al reprogramar el mdulo para este proyecto. Por tanto, para volver a actualizar la ROM, ser necesario cargar y ejecutar desde la RAM dicho servidor ftp. ste se encuentra en la siguiente ruta: C:\netos60_gnu\src\examples\naftpapp Debe compilarse el programa anterior y cargarse en RAM siguiendo el mtodo enunciado en el epgrafe anterior. Una vez se tenga el servidor ftp funcionando (apareciendo en la pantalla de HyperTerminal el mensaje: RAM based FTP server ready), puede procederse a la actualizacin de la Flash ROM del mdulo. Para ello: 1. Iniciar la aplicacin de programacin: Programas\NET +OS 6.0e GNU\NET +OS Programmer 2. Iniciar el proceso de actualizacin de la Flash ROM escribiendo en la lnea de comandos: netosprog /upload /firmware=C:\(Ruta de archivos donde se encuentre el image.bin del programa que queramos cargar) /ip=(Direccin IP del mdulo) 3. Comenzar el proceso de carga. Esperar a que termine (Tarda varios minutos) y a que el mdulo se reinicie por s mismo, lo cual podr comprobarse a travs de los mensajes mostrados en HyperTerminal.
109
3 Configuracin de los parmetros de la placa de desarrollo y del mdulo

Si el programa est configurado a tal efecto, al iniciarse mostrar durante unos segundos una pantalla con la configuracin acerca de parmetros como su direccin IP, su direccin MAC, la direccin del punto de acceso a la red, el tipo de red para la que est configurado, etc. Esta pantalla aparece a travs del HyperTerminal cuando el mdulo se reinicia. Por defecto est configurada para esperar a que el usuario inicie el proceso de configuracin pulsando una tecla slo durante 5 segundos. Si pasado ese tiempo no se ha hecho nada, se contina la carga normal del programa. Si se desea cambiar algn parmetro, pulsar una tecla en ese lapso de tiempo, y se iniciar el proceso de configuracin. Aparece entonces un dilogo que pregunta si aceptar la configuracin o modificarla. Introducir la opcin deseada, en este caso M para modificar los datos. Se pide una clave de acceso que por defecto es Netsilicon. A partir de aqu, comenzar el proceso de configuracin parmetro por parmetro. Para aceptar el valor actual, presionar ENTER, y si se desea modificar, introducir el nuevo valor y pulsar ENTER. Nota: En el momento de concluir este proyecto, el mdulo est configurado para acceder a una red inalmbrica denominada (es decir, su SSID es) wlanrobot cuya clave de acceso es 1234abcd1234abcd1234abcd12. El robot est configurado para utilizar una IP fija, reservada en la red del IIT, que es 130.206.71.20. Para el resto de parmetros, consultar la utilidad de configuracin. Para configurar el programa para que pida los parmetros de configuracin al iniciarse, debe estar activa (Es decir, no entre comentarios: /* */) la siguiente lnea en el archivo appconf.h (Ver Epgrafe 2 del presente captulo):
#define APP_DIALOG_PORT "/com/0"
Anejos.
110
Parte V ANEJOS
Anejos. Cdigo de la aplicacin de comunicacin Wi-Fi
111
Captulo 1 CDIGO DE LA APLICACIN DE

COMUNICACIN
WI-FI
En el presente captulo de los anejos a este proyecto, se incluye el cdigo ntegro comentado perteneciente al programa cuyo desarrollo se detall en la Parte I Captulo 2. nicamente se incluye el cdigo del archivo que se corresponde al propio programa. No se adjuntan los cdigos de los archivos root.c, appconf.h y makefile dado que responden a una estructura estndar reflejada en Parte IV Captulo 3 2. De existir inters en dichos archivos, pueden encontrarse en la documentacin electrnica entregada junto al proyecto.
112
1 Cdigo de servidor.c
/***************************************************************************** * * * * * * * * Antes de compilarse, debe chequearse que la direccin IP del servidor y * el puerto sobre el que escuchar son los correctos segn la configuracin * particular de cada red. * * servidor.c : Versin 1.0 * * Realizado por : Jaime Alonso lvarez * * *****************************************************************************/ Junio 2005 Aplicacin de prueba para evaluar las posibilidades de conexin, envo y recepcin de datos del mdulo Wi-Fi. En ella el mdulo acta como servidor, esperando a que un cliente pida una conexin, momento en el que la conexin se cierra y comienzan a enviarse y recibirse datos cclicamente.
#include <string.h> #include <stdio.h> #include <tx_api.h> #include <sockapi.h> #include <socket.h> #include <in.h>
int TCPsend(const char *sHost, int iPort, char * sDatos) {
int
sock;
//Descriptor del socket

struct sockaddr_in fsin; //Estructura que almacena la direccin // donde se crear el socket
113
sock = socket(AF_INET, SOCK_STREAM, 0); if (sock < 0) { printf("socket failure.\n"); exit(1); }
//Abre el socket TCP
//Se configura la direccin //del socket
fsin.sin_family fsin.sin_addr.s_addr fsin.sin_port
= AF_INET; = htonl(INADDR_ANY); = htons(iPort);
//Atamos el socket al puerto correspondiente if ( bind( sock, (struct sockaddr_in *) &fsin, sizeof(fsin) ) == SOCKET_ERROR ) { printf( "bind() failed.\n" ); closesocket(sock); return; }
if ( listen( sock, 1 ) == SOCKET_ERROR )
//El servidor se pone a la //escucha en el socket
printf( "Error listening on socket.\n");
//Abrimos un socket auxiliar para el proceso de aceptar conexiones int acceptsock = socket(AF_INET, SOCK_STREAM, 0);
//Esperamos a que haya una peticin de conexin y la aceptamos

printf( "Waiting for a client to connect...\n" ); while (1) { acceptsock = SOCKET_ERROR; while ( acceptsock == SOCKET_ERROR ) { acceptsock = accept( sock, NULL, NULL ); } printf( "Client Connected.\n"); sock = acceptsock; break; }
114
int bytesSent; int bytesRecv = SOCKET_ERROR; char recvbuf[32] = ""; while(1){ //Comienza la recepcin y envo contnuo de datos a travs //del socket
bytesRecv = recv( sock, recvbuf, 32, 0 );
//Recibimos los datos
if(bytesRecv!=-1){
printf( "\nBytes Recv: %ld\n", bytesRecv ); printf( "%s\n", recvbuf );
bytesSent = send( sock, sDatos, strlen(sDatos), 0 );
//Enviamos
// la confirmacin de recepcin printf( "Bytes Sent: %ld\n", bytesSent );
} }
close (sock);

return; }
115
void servidor(ULONG thread_input)
//Aplicacin principal que arranca al //iniciarse el hilo de proceso
char sHost[16]="190.206.71.20";
//Direccin IP del mdulo en la red //(servidor)
char sDatos[32]="Recibido OK";
//Datos a enviar en la confirmacin de //recepcin al cliente
int iPort=1234;
//Puerto en el que escuchar
while(1){
printf("\nDireccion IP del servidor: %s", sHost); printf("\nPuerto: %d", iPort);
return; }
Anejos. Cdigo de la aplicacin completa de control remoto
116
Captulo 2 CDIGO DE LA APLICACIN

COMPLETA DE CONTROL REMOTO
En el presente captulo se ofrece el cdigo completo de la aplicacin final desarrollada en este proyecto, que permite conectarse desde un PC remoto al mdulo Wi-Fi de control del robot, envindole las rdenes de su movimiento, que posteriormente se transmiten a la TCS para su ejecucin. El desarrollo de este programa se detalla en Parte I Captulo 3. nicamente se incluye el cdigo del archivo que se corresponde al propio programa. No se adjuntan los cdigos de los archivos root.c, appconf.h y makefile dado que responden a una estructura estndar reflejada en Parte IV Captulo 3 2. De existir inters en dichos archivos, pueden encontrarse en la documentacin electrnica entregada junto al proyecto.
117
1 Cdigo de controlRemoto.c
/***************************************************************************** * Aplicacin que permite controlar de manera remota el robot combinando la * funcionalidad como servidor desarrollada en el software de prueba de * comunicaciones Wi-Fi incluido tambin en el presente proyecto con la * posibilidad de mandar rdenes a la TCS a travs del puerto serie. * * Est compuesta por dos hilos de proceso que se ejecutan simultneamente, * uno de ellos encargado de establecer la comunicacin Wi-Fi con el cliente * y de transcribir las rdenes recibidas a cadenas entendibles por la TCS * y el otro encargado de comprobar si existen rdenes que enviar a la TCS * y de escribirlas en el puerto serie. * * Antes de compilarse, debe chequearse que la direccin IP del servidor y * el puerto sobre el que escuchar son los correctos segn la configuracin * particular de cada red. Asimismo debe comprobarse que las velocidades de los * motores utilizadas a la hora de generar las cadenas a enviar a la TCS son * las apropiadas a las necesidades particulares del robot. * * controlRemoto.c : Versin 1.0 * * Realizado por : Jaime Alonso lvarez * * *****************************************************************************/ Junio 2005
#include <stdio.h> #include <string.h> #include <serParam.h> #include <termios.h> #include <tx_api.h> #include <sockapi.h>

#include <socket.h> #include <in.h>
118
#include "appconf.h"
//Definicin de estructura auxiliar para almacenar opciones de configuracin //que ms tarde se actualizarn en una estructura de tipo termios para //finalmente establecerlas mediante la funcin tcsetattr() struct ioflags_t { tcflag_t cflags; tcflag_t iflags; }; //Estructura que permite controlar la longitud de las cadenas que se van a //escribir en el puerto serie
typedef struct { unsigned char sEntrada[32]; int iLongitud;
}BufferEntrada;
BufferEntrada sendBuffer0; //Variable que almacenar lo que se vaya a // enviar por el puerto serie (Memoria compartida) int iFlagEscribe=0; //Flag de control para evitar acceso simultneo de //ambos hilos al buffer intermedio int iFlagBorra=0; int numBytesSent; //Idem //Variable para controlar los datos enviados por el //puerto serie
//HILO DE PROCESO CORRESPONDIENTE AL PUERTO SERIE
void Serialone(ULONG thread_input)

{ int zeroFd; int result; //Descriptor del puerto serie //Variable para controlar que las operaciones de //configuracin son exitosas int baudrate; //Variable para poder configurar el Baudrate del puerto
119
int bytetosend = 0;
//Variable para utilizar en la funcin de escritura //en el puerto para //controlar la cantidad de datos a enviar
//Creo las variables para establecer las opciones
struct ioflags_t iOptions; struct termios tios;
sendBuffer0.iLongitud=0;
//Inicializo la estructura para evitar // problemas
//Comienzo de la rutina para apertura y configuracin del puerto serie //Rutina genrica para abrir y configurar puertos. Es suficiente con //establecer las opciones oportunas para cada uso
zeroFd = open ("/com/1", O_RDWR);
//Abro el com1 para lectura y //escritura (Dejo el com0 para //control por pantalla //mediante los printf del desarrollo //del programa
if (zeroFd <0) { printf ("Can't open com1 [%d].\n", getErrno()); return; } else //Si todo OK configuro el puerto

{
120
printf("\nApertura del puerto correcta\n");
baudrate = SIO_57600_BAUD;
//Configuro el Baudrate a 57600 baudios
tcgetattr(zeroFd, &tios); cfsetospeed(&tios, baudrate);
//Configuro el resto de parmetros: No controles de flujo, 8 bits de //datos, un bit de stop y sin paridad
iOptions.cflags = (SIO_NO_HANDSHAKING | CS8 | SIO_ONE_STOP_BIT | SIO_NO_PARITY); iOptions.iflags = (0);
tios.c_cflag = iOptions.cflags; tios.c_iflag = iOptions.iflags;
result = tcsetattr( zeroFd, TCSANOW, &tios ); if (result < 0) { printf ("ioctl(Set attributes) failure: errno[%d]\n", getErrno()); return; }
//Compruebo que todos los parmetros se han configurado //correctamente
if ( cfgetospeed(&tios) != baudrate ) { printf ("ioctl(Baud set)\n", getErrno()); return; }

if ( (tios.c_cflag != iOptions.cflags) || (tios.c_iflag != iOptions.iflags) ) { printf ("ioctl(Flag settings) failure\n", getErrno()); return; }
121
//Fin de la rutina de apertura y configuracin del puerto serie
printf("\nComienzo del bucle de escritura\n");
while(1){
bytetosend = sendBuffer0.iLongitud;
//Establezco la cantidad de //datos a enviar leyendo de //la memoria compartida
numBytesSent = 0;
//Reseteo el control de datos enviados
do { if (numBytesSent < bytetosend) //Compruebo que realmente hay //datos nuevos que enviar en //espera en el buffer { printf("\nVoy a escribir en el puerto serie\n");
result = write(zeroFd, (sendBuffer0.sEntrada + numBytesSent), (bytetosend - numBytesSent));
if (result < 0){ printf ("write failed [%d].\n", getErrno() ); }

else { numBytesSent += result;
122
if(numBytesSent==bytetosend){
//Si ya he mandado todo lo //que tena, reseteo el //buffer intermedio
while(iFlagEscribe){
//Espero a poder escribir sobre //la cadena para resetearla //ya que si iFlagEscribe est a //1, quiere decir que
//el hilo del servidor est //actualizando la variable }
iFlagBorra=1;
//Pongo este flag a 1 para evitar que //mientras reseteo la variable acceda a //ella el otro hilo
sendBuffer0.iLongitud=0; iFlagBorra=0;
//Reseteo la variable
//Libero el acceso a la memoria //compartida
} } } }while (numBytesSent < bytetosend); //Repito hasta que haya
//mandado todo por el puerto serie
result = close (zeroFd);
if (result<0)

{ printf ("Close failed [%d].\n", getErrno() ); }
123
//HILO DE PROCESO DEL SERVIDOR
int TCPsend(const char *sHost, int iPort, char * sDatos) {
int sock;
//Descriptor del socket fsin; //Estructura para almacenar los datos del //socket a abrir
struct sockaddr_in
sock = socket(AF_INET, SOCK_STREAM, 0);
//Abrimos el socket TCP
if (sock < 0) {
//Comprobamos apertura correcta
printf("socket failure.\n"); exit(1); }
//Configuramos el socket estableciendo la familia del protocolo y el puerto donde escuchar
memset((void *)&fsin, 0, sizeof(fsin)); fsin.sin_family fsin.sin_addr.s_addr fsin.sin_port = AF_INET; = htonl(INADDR_ANY); = htons(iPort);
124
//Atamos el socket al puerto
if ( bind( sock, (struct sockaddr_in *) &fsin, sizeof(fsin) ) == SOCKET_ERROR ) { printf( "bind() failed.\n" ); closesocket(sock); return; }
//Ponemos el servidor a la escucha en el puerto dado
if ( listen( sock, 1 ) == SOCKET_ERROR ) printf( "Error listening on socket.\n");
//Creamos un socket auxiliar para aceptar la conexin solicitada por un cliente
int acceptsock = socket(AF_INET, SOCK_STREAM, 0);
printf( "Waiting for a client to connect...\n" );
//Esperamos a que un cliente solicite la conexin a la escucha en el puerto
while (1) { acceptsock = SOCKET_ERROR; while ( acceptsock == SOCKET_ERROR ) { acceptsock = accept( sock, NULL, NULL ); //Aceptamos la conexin //de haberla } printf( "Client Connected.\n"); sock = acceptsock; //Asignamos el socket con la conexin ya //establecida al socket principal break;

}
125
//Una vez establecida la conexin, comenzamos el intercambio de datos
int bytesSent;
//Variable para controlar los datos enviados //Variable para controlar los datos //recibidos
int bytesRecv = SOCKET_ERROR;
char recvbuf[32] = "";
//Buffer para almacenar los datos recibidos
while(1){
bytesRecv = recv( sock, recvbuf, 32, 0 ); caracteres en el socket
//Recibimos la cadena de
if(bytesRecv!=-1){
//Si se ha recibido algn dato vlido
while(iFlagBorra){
//Espera a que acabe de escribir sobre la //variable el otro hilo
iFlagEscribe=1;
//Reservo la variable intermedia para que el otro //hilo no acceda mientras la actualizo
//Dependiendo de la instruccin recibida desde el cliente, genero la cadena de rdenes entendible por la TCS //y la coloco en el buffer intermedio para que sea accesible por el otro hilo
if(recvbuf[0]=='a'){
//Encender motores
printf("Voy a generar la cadena para encender");
sendBuffer0.sEntrada[0]=1;

sendBuffer0.sEntrada[1]=5; sendBuffer0.sEntrada[2]=8; sendBuffer0.sEntrada[3]=100; sendBuffer0.sEntrada[4]=10; sendBuffer0.sEntrada[5]=25; sendBuffer0.sEntrada[6]=25; sendBuffer0.sEntrada[7]=92; sendBuffer0.sEntrada[8]=1; sendBuffer0.sEntrada[9]=1; sendBuffer0.sEntrada[10]=4; sendBuffer0.sEntrada[11]=92; sendBuffer0.sEntrada[12]=49;
126
} if(recvbuf[0]=='b'){ //Arrancar motores marcha adelante
printf("Voy a generar la cadena para arrancar");
sendBuffer0.sEntrada[0]=10; sendBuffer0.sEntrada[1]=25; sendBuffer0.sEntrada[2]=25; sendBuffer0.sEntrada[3]=7; sendBuffer0.sEntrada[4]=3; sendBuffer0.sEntrada[5]=92; sendBuffer0.sEntrada[6]=1; sendBuffer0.sEntrada[7]=92; sendBuffer0.sEntrada[8]=49;
127
} if(recvbuf[0]=='c'){ //Parar motores
printf("Voy a generar la cadena para parar");
sendBuffer0.sEntrada[0]=7; sendBuffer0.sEntrada[1]=0; sendBuffer0.sEntrada[2]=92; sendBuffer0.sEntrada[3]=1; sendBuffer0.sEntrada[4]=92; sendBuffer0.sEntrada[5]=49;
} if(recvbuf[0]=='d'){ //Girar izquierda
printf("Voy a generar la cadena para girar a la izquierda");
} if(recvbuf[0]=='e'){ //Girar derecha
128
printf("Voy a generar la cadena para girar a la derecha");
} if(recvbuf[0]=='f'){ //Marcha atras
printf("Voy a generar la cadena para ir marcha atras");
sendBuffer0.sEntrada[0]=10; sendBuffer0.sEntrada[1]=75; sendBuffer0.sEntrada[2]=75; sendBuffer0.sEntrada[3]=7; sendBuffer0.sEntrada[4]=3; sendBuffer0.sEntrada[5]=92; sendBuffer0.sEntrada[6]=1; sendBuffer0.sEntrada[7]=92; sendBuffer0.sEntrada[8]=49;

iFlagEscribe=0; //Libero la variable para que sea accesible por //el otro hilo
129
bytesSent = send( sock, sDatos, strlen(sDatos), 0 ); confirmacin de todo OK
//Mando la
} }
close (sock);
return; }
void servidor(ULONG thread_input) {
//Punto de entrada del hilo de proceso
char sHost[16]="130.206.71.20"; char sDatos[32]="Recibido OK"; int iPort=1234;
//Direccin IP del servidor en la red
//Puerto al que atar la conexin
while(1){
//Iniciamos realmente //el proceso del //servidor con los //datos //proporcionados en //esta funcin
} return; }
Anejos. Cdigo de la aplicacin TCPTest.exe
130
Captulo 3 CDIGO DE LA APLICACIN TCPTEST.EXE

En el presente captulo se adjunta el cdigo que se utiliz para la creacin del programa de prueba para enviar y recibir datos a travs de una red TCP. Este programa se realiz utilizando el entorno de desarrollo Microsoft Visual C++ 6.0. Est programado para ser ejecutado en modo de lnea de comandos, y tiene capacidad de actuar tanto como servidor, como conectarse a un servidor como cliente, que es la utilidad fundamental que se le dio en el presente proyecto, y la razn por la cual se plante su necesidad. El cdigo adjunto apenas tiene comentarios, ya que su concepto es prcticamente idntico al del servidor creado para el mdulo, y su inters no va mucho ms all de tener una ligera nocin de cmo se crea un cliente y cmo se gestionan sockets bajo Windows. Para ms informacin consultar [9].
131
1 Cdigo de TCPTest.cpp
#include <stdio.h> #include <stdlib.h> #include "winsock2.h"
void ServidorTCP(char * sDireccionIP, int iPuerto); void ClienteTCP(char * sDireccionIP, int iPuerto);
void main(){
int iOpcion=1, iPuerto=27015; char sDireccionIP[16]="127.0.0.1";
do{
fflush(stdin);
printf("\n\nIntroduzca la opcion deseada:\n\n"); printf("\t1-Actuar como servidor\n"); printf("\t2-Conectarse a un servidor como cliente\n"); printf("\t3-Salir del programa\n\n"); printf("Esperando opcion...");
scanf("%d",&iOpcion);
switch(iOpcion){ case 1: printf("\n\nIntroduzca la direccion IP del servidor (xxx.xxx.xxx.xxx): "); scanf("%s",sDireccionIP);

printf("\nIntroduzca el puerto a utilizar: "); scanf("%d",&iPuerto); ServidorTCP(sDireccionIP,iPuerto); break; case 2:
132
printf("\n\nIntroduzca la direccion IP del servidor (xxx.xxx.xxx.xxx): "); scanf("%s",sDireccionIP); printf("\nIntroduzca el puerto a utilizar: "); scanf("%d",&iPuerto); ClienteTCP(sDireccionIP,iPuerto); break; case 3: break; default: break; }
}while(iOpcion!=3); }
void ServidorTCP(char * sDireccionIP, int iPuerto) {
// Initialize Winsock. WSADATA wsaData; int iResult = WSAStartup( MAKEWORD(2,2), &wsaData ); if ( iResult != NO_ERROR ) printf("Error at WSAStartup()\n");
// Create a socket. SOCKET m_socket; m_socket = socket( AF_INET, SOCK_STREAM, IPPROTO_TCP );
if ( m_socket == INVALID_SOCKET ) {

printf( "Error at socket(): %ld\n", WSAGetLastError() ); WSACleanup(); return; }
133
// Bind the socket. sockaddr_in service;
service.sin_family = AF_INET; service.sin_addr.s_addr = inet_addr( sDireccionIP ); service.sin_port = htons( iPuerto );
if ( bind( m_socket, (SOCKADDR*) &service, sizeof(service) ) == SOCKET_ERROR ) { printf( "bind() failed.\n" ); closesocket(m_socket); return; }
// Listen on the socket. if ( listen( m_socket, 1 ) == SOCKET_ERROR ) printf( "Error listening on socket.\n");
// Accept connections. SOCKET AcceptSocket;
printf( "\nWaiting for a client to connect...\n" ); while (1) { AcceptSocket = SOCKET_ERROR; while ( AcceptSocket == SOCKET_ERROR ) { AcceptSocket = accept( m_socket, NULL, NULL ); } printf( "\nClient Connected.\n"); m_socket = AcceptSocket;

break; }
134
// Send and receive data.
char sendbuf[32] = "Recibido OK";
while(1){
int bytesSent; int bytesRecv = SOCKET_ERROR; char recvbuf[32] = "";
bytesRecv = recv( m_socket, recvbuf, 32, 0 );
if(bytesRecv!=-1){
printf( "Bytes Recv: %ld\n", bytesRecv ); printf( "%s\n", recvbuf ); bytesSent = send( m_socket, sendbuf, strlen(sendbuf), 0 ); printf( "Bytes Sent: %ld\n", bytesSent ); printf("________________________________\n");
return; }
void ClienteTCP(char * sDireccionIP, int iPuerto) {

// Initialize Winsock. WSADATA wsaData; int iResult = WSAStartup( MAKEWORD(2,2), &wsaData ); if ( iResult != NO_ERROR ) printf("Error at WSAStartup()\n");
135
// Create a socket. SOCKET m_socket; m_socket = socket( AF_INET, SOCK_STREAM, IPPROTO_TCP );
if ( m_socket == INVALID_SOCKET ) { printf( "Error at socket(): %ld\n", WSAGetLastError() ); WSACleanup(); return; }
// Connect to a server. sockaddr_in clientService;
clientService.sin_family = AF_INET; clientService.sin_addr.s_addr = inet_addr( sDireccionIP ); clientService.sin_port = htons( iPuerto );
if ( connect( m_socket, (SOCKADDR*) &clientService, sizeof(clientService) ) == SOCKET_ERROR) { printf( "Failed to connect.\n" ); WSACleanup(); return; }
// Send and receive data.
while(1){
136
int bytesSent; int bytesRecv = SOCKET_ERROR; char recvbuf[32] = ""; char sendbuf[32] = "";
printf("Introduzca los datos a enviar (29 caracteres max):"); fflush(stdin); fgets(sendbuf,30,stdin);
bytesSent = send( m_socket, sendbuf, strlen(sendbuf), 0 ); printf( "Bytes Sent: %ld\n", bytesSent );
while( bytesRecv == SOCKET_ERROR ) { bytesRecv = recv( m_socket, recvbuf, 32, 0 ); if ( bytesRecv == 0 || bytesRecv == WSAECONNRESET ) { printf( "Connection Closed.\n"); break; } if (bytesRecv < 0) return;
printf( "Bytes Recv: %ld\n", bytesRecv ); printf( "%s\n", recvbuf ); printf("________________________________\n");
return; }
PLIEGO DE CONDICIONES
Pliego de condiciones.
Captulo 1 1 2
Pliego de condiciones generales y econmicas. ....................3
Condiciones generales. ..............................................................................3 Condiciones econmicas............................................................................5 Pliego de condiciones tcnicas y particulares .......................6
Captulo 2 1 2
Equipo informtico....................................................................................6 Placas de circuito impreso. .......................................................................6 2.1 Soporte.......................................................................................................6 2.2 Diseo de las pistas....................................................................................7
3 4 5 6 7
Sistema de radiofrecuencia. ......................................................................7 Normas de calidad. ....................................................................................8 Normas de Seguridad e Higiene. ..............................................................8 Vida til del producto................................................................................8 Otros criterios de diseo. ..........................................................................8
Pliego de condiciones. Pliego de condiciones generales y econmicas.
Captulo 1 PLIEGO DE CONDICIONES

GENERALES Y ECONMICAS.
Condiciones generales.
Las condiciones y clusulas que se establecen en este documento son de obligado cumplimiento por las partes contratantes. I. Tanto el administrador como el cliente se comprometen desde la fecha de la firma del contrato a llevar a cabo lo que se estipule. II. Ante cualquier reclamacin o discrepancia en lo concerniente al cumplimiento de lo pactado por cualquiera de las partes, una vez agotada toda va de entendimiento, se tramitar el asunto por la va de lo legal. El dictamen o sentencia que se dicte ser de obligado cumplimiento para las dos partes. III. Al firmarse el contrato, el suministrador se compromete a facilitar toda la informacin necesaria para la instalacin y buen funcionamiento del sistema, siempre que sea requerido para ello. IV. Asimismo, el cliente entregar al suministrador todas las
caractersticas distintivas del equipo comprado y aquellas otras que considere oportunas para el necesario conocimiento de la misma a efectos del diseo del presente equipo. V. El plazo de entrega ser de nueve meses, a partir de la fecha de la firma del contrato, pudiendo ampliarse en un mes. Cualquier modificacin de los plazos deber contar con el acuerdo de las dos partes. VI. En caso de retrasos imputables al suministrador, se considerar una indemnizacin del 1 % del valor estipulado por semana de retraso.
VII. Existir un plazo de garanta de dos aos a partir de la entrega del sistema. Dicha garanta quedar sin efecto si se demostrase que el sistema ha estado sometido a manipulacin o uso indebido. VIII. Cumplido dicho plazo de garanta, el suministrador queda obligado a la reparacin del sistema durante un plazo de cinco aos, fuera del cual quedar a su propio criterio atender la peticin del cliente. IX. En ningn momento tendr el suministrador obligacin alguna frente a desperfectos o averas por uso indebido por personas no autorizadas por el suministrador.
Condiciones econmicas.
I. Los precios indicados en este proyecto son firmes y sin revisin por ningn concepto, siempre y cuando se acepten dentro del periodo de validez del presupuesto que se fija hasta Diciembre de 2004. II. El pago se realizar como sigue: h h 75% a la firma del contrato. 25% en el momento de entrega.
III. La forma de pago ser al contado mediante cheque nominativo o mediante transferencia bancaria. En ningn caso se aceptarn letras de cambio. IV. El suministrador se har cargo de los gastos de embalaje y del transporte, dentro de la ciudad donde se encuentre la instalacin. En caso de ser necesario transporte interurbano, el gasto correr por cuenta del cliente. En todo caso, el responsable de los posibles desperfectos ocasionados por el transporte ser el suministrador. V. Durante el plazo de garanta, la totalidad de los gastos originados por las reparaciones corrern por cuenta del suministrador. VI. Fuera de dicho plazo y durante los siguientes cinco aos, los costes sern fijados mediante acuerdo por ambas partes. Pasados cinco aos, stos los fijar exclusivamente el suministrador.
Pliego de condiciones. Pliego de condiciones tcnicas y particulares
Captulo 2 PLIEGO DE CONDICIONES

TCNICAS Y PARTICULARES
Equipo informtico.
El equipo informtico debe estar homologado conforme a la normativa Europea y Espaola a fecha de Junio de 2005. El equipo informtico debe instalarse conforme a las indicaciones del fabricante, manteniendo las condiciones de humedad y temperatura entre los lmites marcados. Los programas informticos empleados han de contar con la licencia preceptiva y cumplir con las condiciones de la misma. En caso de usar programas de licencia GNU, se debern respetar las condiciones de la misma.
Placas de circuito impreso.
2.1 Soporte. El tipo de soporte aislante utilizado en las placas de circuito impreso ser de fibra de vidrio, con las caractersticas siguientes (recomendadas): Resistencia superficial en M Resistencia volumtrica en M Constante dielctrica (a f=1 MHz) Temperatura mxima de trabajo Temperatura mxima de soldadura (mx. 20 seg.) 105 107 0,25 125C 260C
El espesor de las placas ser de 1,6 mm (valor normalizado). Las placas sern de una o dos caras, fabricadas por el mtodo sustractivo basado en mscaras. Debern acompaarse de un esquema que contenga los taladros a realizar, as como la colocacin exacta de los componentes. 2.2 Diseo de las pistas. El diseo se realizar teniendo en cuenta las recomendaciones para equipos de alta frecuencia y de telecomunicaciones que dicta la normativa Europea en cuanto a: Compatibilidad electromagntica (89/36/EEC). Niveles de tensin (73/23/EEC).
Asimismo, se realizarn las pistas con el siguiente grosor recomendado (suponiendo un espesor tpico): Grosor(pulgadas) 0.010" 0.015" 0.020" 0.025" 0.05" 0.1" 0.15" Corriente Mxima 0.3 A 0.4 A 0.7 A 1A 2A 4A 6A
Sistema de radiofrecuencia.
El sistema de radio frecuencia cumplir con los requisitos establecidos en la normativa Europea (R&TTE Directive 1999-5-EC). El sistema de radiofrecuencia se atendr a la normativa vigente de proteccin del espacio radioelctrico y proteccin de la salud: LEY
GENERAL DE TELECOMUNICACIONES 11/1998, DE 24 DE ABRIL DE 1998.
Normas de calidad.
Los sistemas se disearn de forma que cumplan las normas UNE, CEI y EN aplicables a este tipo de productos, as como las normas ETSI (European Telecommunications Standards Institute) para sistemas de radiofrecuencia.
Normas de Seguridad e Higiene.
El proyecto cumplir con la Ley 31/95 de Prevencin de Riesgos Laborales.
Vida til del producto.
Los sistemas se disearn para una vida til no inferior a 10 aos en funcionamiento continuo.
Otros criterios de diseo.
Se emplearn componentes normalizados para los circuitos electrnicos.
PRESUPUESTO
Presupuesto.
Captulo 1 1 2 3
Mediciones ..............................................................................3
Consideraciones generales. .......................................................................3 Equipos y componentes utilizados............................................................4 Mano de obra .............................................................................................5 Sumas Parciales .....................................................................6
Captulo 2 1 2
Equipos y componentes utilizados............................................................6 Mano de obra .............................................................................................7 Presupuesto general ...............................................................8
Captulo 3
Presupuesto. Mediciones
Captulo 1 MEDICIONES
Consideraciones generales.
A la hora de detallar los conceptos que se vern incluidos en el presupuesto final correspondiente al presente proyecto, se han seguido las premisas que se exponen a continuacin: El precio imputado a la Tarjeta de Control de Sensores incluida en la plataforma desarrollada, corresponde al detallado en el proyecto de cuyo desarrollo es resultado, fechado en junio de 2004. No se incluyen los costes correspondientes al equipo informtico ni el software utilizado en el desarrollo del proyecto, por no entenderse que formen parte integrante del mismo, siendo propiedad del desarrollador y de la entidad colaboradora previa al inicio del desarrollo del proyecto, y considerndose la amortizacin de los mismos incluida en los costes de mano de obra imputados. Los precios de los componentes detallados corresponden al importe pagado en su fecha de compra, y pueden no coincidir con el importe de compra en caso de requerirse una reproduccin del proyecto, en cuyo caso el presente presupuesto podr ser revisado y actualizado. El presupuesto final aqu desglosado incluye la totalidad de los componentes empleados en los dos proyectos que constituyen el concepto global desarrollado, pero la mano de obra incluida se corresponde nicamente con la empleada por el proyectista encargado de la parte del concepto global desarrollada en el presente proyecto. El coste imputable a las piezas y motores de LEGO utilizados para la construccin del robot no se incluye en el presente presupuesto al no constituir el robot parte imprescindible del desarrollo, siendo una
simple plataforma de exposicin de resultados, no necesariamente reproducible para implementar la solucin aqu desarrollada. S se incluyen en el presupuesto los costes de los instrumentos de medida, accesorios y equipos utilizados tanto para el desarrollo como para las pruebas realizadas para comprobar la correcta funcionalidad de la plataforma, aunque finalmente no se incluyan como parte constituyente del proyecto.
2 Equipos y componentes utilizados

Descripcin Digi Connect Wi-ME Development Kit (GNU) Referencia Internacional: DC-WME-01T-GN Tarjeta de Control de Sensores (Versin de 2 PICs) Cmara Web Veo Wireless Oberver Punto de acceso Wi-Fi 802.11b Industrial ScopeMeter 123 Fluke Adaptador CA/CC NORU Cable conexin serie DB-9 hembra-hembra Cable de conexin serie especfico TCS (3 pin) a DB-9 hembra Digital Multimeter Adaptador de enchufe estndar estadounidense a europeo con toma de tierra 1 1 1 1 1 1 1 1 1 Cantidad 1
3 Mano de obra
Descripcin Documentacin Previa Estudio del Entorno de Desarrollo Estudio de las APIs Desarrollo Software Tests y Depuracin Diseo y Construccin del Robot Integracin entre proyectos Redaccin de documentacin Cantidad 70 horas 50 horas 150 horas 50 horas 70 horas 15 horas 20 horas 150 horas
Presupuesto. Sumas Parciales
Captulo 2 SUMAS PARCIALES
1 Equipos y componentes utilizados

Descripcin Digi Connect Wi-ME Development Kit (GNU) Referencia Internacional: DCWME-01T-GN Tarjeta de Control de Sensores (Versin de 2 PICs) Cmara Web Veo Wireless Oberver Punto de acceso Wi-Fi 802.11b Industrial ScopeMeter 123 Fluke Adaptador CA/CC NORU Cable conexin serie DB-9 hembrahembra Cable de conexin serie especfico TCS (3 pin) a DB-9 hembra Digital Multimeter Adaptador de enchufe estndar estadounidense a europeo con toma de tierra Total equipos y componentes 3307,61 1 1 12 12,80 12 12,80 1 5 5 1 1 1 1 1 350 60 1220 10 3 350 60 1220 10 3 1 99,81 99,81 Cantidad 1 Precio/ud. 1535 Precio total 1535
Presupuesto. Sumas Parciales
2 Mano de obra
Descripcin Total mano de obra Cantidad 575 horas Precio/ud. 50 Precio total 28750
Presupuesto. Presupuesto general
Captulo 3 PRESUPUESTO GENERAL
Descripcin Total equipos y componentes Total mano de obra TOTAL PRESUPUESTO TOTAL PRESUPUESTO + 16% IVA
Importe 3307,61 28750 32057,61 37186,83

Robot Movil Controlado Por Internet TESIS

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Robot Movil Controlado Por Internet TESIS

Загружено:

Авторское право:

Доступные форматы

Autorizada la entrega del proyecto: Desarrollo de un robot mvil controlado desde Internet: Comunicaciones Wi-Fi Realizado por: Jaime

V B de los Directores del Proyecto:

Firmado: lvaro Snchez Miralles Fecha: //

Firmado: Rafael Palacios Hielscher Fecha: //

V B de los Coordinadores de rea:

Firmado: Sadot Alexandres Fernndez Fecha: //

Firmado: lvaro Snchez Miralles Fecha: //

UNIVERSIDAD PONTIFICIA COMILLAS

PROYECTO FIN DE CARRERA

DESARROLLO DE UN ROBOT MVIL CONTROLADO DESDE INTERNET: COMUNICACIONES Wi-Fi

Jaime Alonso lvarez MADRID, Junio 2005

1 Parte I Memoria ..................................................................................................3

Prlogo ....................................................................................................................4 Captulo 1

Comunicacin Wi-Fi ....................................................................22

Breve introduccin al funcionamiento de los puertos serie segn norma

Desarrollo del software de envo de rdenes a travs del puerto serie a la

complementario y construccin del robot ................................................................ 62

Conclusiones .................................................................................66 Futuros desarrollos.......................................................................68

Bibliografa ...........................................................................................................71 Parte II Clculos.............................................................................................72

2 Parte III Parte IV Captulo 1

Estudio econmico............................................................................74 Manual de usuario............................................................................77 Creacin y gestin de sockets .......................................................78

Archivos de cabecera (*.h) ................................................................................ 79

Configuracin y uso del puerto serie RS232 ...............................89

Archivos de cabecera (*.h) ................................................................................ 90

Entorno de desarrollo ...................................................................98

Compilacin del entorno de desarrollo............................................................ 99 Compilacin y carga de programas en el mdulo......................................... 100

Configuracin de los parmetros de la placa de desarrollo y del mdulo.. 109

Anejos ..............................................................................................110 Cdigo de la aplicacin de comunicacin Wi-Fi.......................111

Cdigo de servidor.c ........................................................................................ 112

Cdigo de la aplicacin completa de control remoto.................116

Cdigo de controlRemoto.c............................................................................. 117

Cdigo de la aplicacin TCPTest.exe ........................................130

Cdigo de TCPTest.cpp .................................................................................. 131

1 Estudio de los trabajos / tecnologas existentes

Figura 1: SitePlayer development kit

Figura 2: Mdulo SitePlayer

Figura 3: X80 de Dr Robot

Figura 4: DRK8080 de Dr Robot

Figura 5: AmigoBot de ActivMedia Robotics

2 Motivacin del proyecto

Figura 6: Esquema de concepto

4 Metodologa / Solucin desarrollada

Figura 7: Mdulo Digi Connect Wi-ME

Memoria. Introduccin COMUNICACIN Wi-Fi:

Depuracin de ambos programas hasta lograr el establecimiento fiable y estable de la conexin.

comunicacin va serie con la TCS. Recepcin de rdenes remotas,

Tabla 1: Distribucin temporal de actividades

5 Recursos / herramientas empleadas

Figura 8: Mdulo Digi Connect Wi-ME

Figura 9: OCDemon de Macraigor Systems

Figura 10: Tarjeta de Control de Sensores (TCS) Versin 2 PICs

Memoria. Comunicacin Wi-Fi

Captulo 2 COMUNICACIN WI-FI

1 Breve introduccin a los sockets, el protocolo TCP/IP y las redes Wi-Fi

Memoria. Comunicacin Wi-Fi

Memoria. Comunicacin Wi-Fi

Memoria. Comunicacin Wi-Fi

2 Desarrollo del software de comunicaciones

Memoria. Comunicacin Wi-Fi

Mostrar datos recibidos por pantalla

Figura 11: Diagrama de flujo del servidor

Memoria. Comunicacin Wi-Fi

Memoria. Comunicacin Wi-Fi 2.1.1 Cdigo de servidor.c

int TCPsend(const char sHost, int iPort, char sDatos){