Java y Tiempo Real RTSJ Aplicada a un Robot...

Java y Tiempo RealRTSJ Aplicada a un Robot Hexapodo

Alberto D. Prieto Lofkrantz

2 de noviembre de 2004

Indice General

1. Introduccion 13

1.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3. Estructura de la Memoria. . . . . . . . . . . . . . . . . . . . . . 15

1.4. Contenido del CD adjunto. . . . . . . . . . . . . . . . . . . . . 18

I Estado del Arte 21

2. Sistemas de Tiempo Real 23

2.1. Definicion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2. Caracterısticas de los STR. . . . . . . . . . . . . . . . . . . . . 24

2.3. Tipos de requisitos temporales. . . . . . . . . . . . . . . . . . . 25

3. Sistemas Operativos de Tiempo Real 27

3.1. Caracterısticas Basicas . . . . . . . . . . . . . . . . . . . . . . . 27

3.2. Campos de Aplicacion de losSOTR . . . . . . . . . . . . . . . . 28

3.3. Taxonomıa de las Arquitecuras de Software para Tiempo Real. . 29

3.4. Algunos ejemplos deSOTR . . . . . . . . . . . . . . . . . . . . 37

4. GNU/Linux y Tiempo Real 39

4.1. Caracterısticas de Linux . . . . . . . . . . . . . . . . . . . . . . 39

4.2. Breve resena historica . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3. Proyecto GNU . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4. Problemas mas comunes al usar Linux para Sistemas de TiempoReal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

4.5. Diferentes lıneas de diseno deSOTRbasados en Linux. . . . . . 43

2 Indice General

5. TimeSys Linux 45

5.1. Funcionalidades de TimeSys Linux. . . . . . . . . . . . . . . . . 45

5.2. Comparativa entre TimeSys Linux y Linux estandar . . . . . . . . 46

5.3. Comparativa entre TimeSys Linux y los SOTR estandar. . . . . . 47

5.4. Componentes Basicos de TimeSys Linux. . . . . . . . . . . . . 48

5.5. Arquitectura de TimeSys Linux. . . . . . . . . . . . . . . . . . . 49

6. Real Time Specification for Java (RTSJ) 51

6.1. Requerimientos del NIST. . . . . . . . . . . . . . . . . . . . . . 51

6.2. Requerimientos definidos por el JRTEG. . . . . . . . . . . . . . 52

6.3. Threads (Hilos) . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.4. Scheduling (Planificacion) . . . . . . . . . . . . . . . . . . . . . 54

6.5. Memory Management (Gestion de memoria). . . . . . . . . . . . 55

6.6. Synchronization (Sincronizacion) . . . . . . . . . . . . . . . . . 57

6.7. Time (Tiempo) . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.8. Timers (Contadores). . . . . . . . . . . . . . . . . . . . . . . . 58

6.9. Asynchrony (Eventos asıncronos) . . . . . . . . . . . . . . . . . 59

6.10.System and Options (Manejo del Sistema). . . . . . . . . . . . . 60

6.11.Exceptions (Excepciones). . . . . . . . . . . . . . . . . . . . . . 61

6.12.Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7. Robots con Patas 63

7.1. Monopodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.2. Bıpedos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.3. Cuadrupedos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.4. Hexapodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.5. Octopodos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.6. Otras Configuraciones. . . . . . . . . . . . . . . . . . . . . . . 68

II Diseno Mecanico 71

8. Diseno Mecanico para NC 73

8.1. Requisitos del Sistema. . . . . . . . . . . . . . . . . . . . . . . 73

8.2. Diseno Escogido . . . . . . . . . . . . . . . . . . . . . . . . . . 74


Indice General 3

8.3. Mecanizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9. Diseno Mecanico para PVC 81

9.1. Requisitos del Sistema. . . . . . . . . . . . . . . . . . . . . . . 81

9.2. Diseno Escogido . . . . . . . . . . . . . . . . . . . . . . . . . . 82

9.3. Proceso de Fabricacion . . . . . . . . . . . . . . . . . . . . . . . 85

9.4. Montaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

III Electr onica y Software de Bajo Nivel 97

10. Electronica 99

10.1.Requisitos del sistema. . . . . . . . . . . . . . . . . . . . . . . . 99

10.2.Diseno escogido. . . . . . . . . . . . . . . . . . . . . . . . . . .102

10.3.Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . .107

11. Software de Bajo Nivel 113

11.1.Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113

11.2.Diseno escogido. . . . . . . . . . . . . . . . . . . . . . . . . . .114

11.3.Herramientas de Desarrollo. . . . . . . . . . . . . . . . . . . . .137

11.4.Pruebas y Calibracion . . . . . . . . . . . . . . . . . . . . . . . .138

IV Cliente y Servidor 139

12. Servidor 141

12.1.Modelo en Capas. . . . . . . . . . . . . . . . . . . . . . . . . .142

13. Cliente 155

13.1.Interfaz Grafica . . . . . . . . . . . . . . . . . . . . . . . . . . .155

13.2.Comunicaciones. . . . . . . . . . . . . . . . . . . . . . . . . . .158

13.3.Manejo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159

V Ampliaciones 163

14. Diseno Mecanico 165


4 Indice General

14.1.De Hexapodo a Octopodo. . . . . . . . . . . . . . . . . . . . . .165

14.2.De 2 a 4 Grados de Libertad. . . . . . . . . . . . . . . . . . . .165

14.3.Realimentacion de Esfuerzos. . . . . . . . . . . . . . . . . . . .166

14.4.Soporte Completo para Webcam. . . . . . . . . . . . . . . . . .166

15. Electronica y Software de Bajo Nivel 167

15.1.Microcontrolador . . . . . . . . . . . . . . . . . . . . . . . . . .167

15.2.Placa de Circuito Impreso. . . . . . . . . . . . . . . . . . . . . .167

15.3.Alimentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . .168

15.4.Servidor Integrado sobre el Robot. . . . . . . . . . . . . . . . .168

15.5.Software de Bajo Nivel. . . . . . . . . . . . . . . . . . . . . . .168

16. Software de Alto Nivel 169

16.1.Interfaz Grafica del Cliente. . . . . . . . . . . . . . . . . . . . .169

16.2.Comunicaciones. . . . . . . . . . . . . . . . . . . . . . . . . . .169

16.3.Navegacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170

16.4.Generacion de Trayectorias Articulares. . . . . . . . . . . . . .170

16.5.Comunicacion con el Microcontrolador . . . . . . . . . . . . . .171

17. Conclusiones 173

VI Ap endices 175

A. Ejemplo de Codigo en ISO 177

B. Instalacion de Debian Woody 179

B.1. Hardware que se va a utilizar. . . . . . . . . . . . . . . . . . . .179

B.2. Proceso de Instalacion . . . . . . . . . . . . . . . . . . . . . . .180

C. Instalacion de TimeSys Linux y JavaVM 187

C.1. TimeSys Linux . . . . . . . . . . . . . . . . . . . . . . . . . . .187

C.2. Java 2 SDK y NetBeans IDE. . . . . . . . . . . . . . . . . . . .190

C.3. Java Real-Time Implementation. . . . . . . . . . . . . . . . . .192

D. Planos del diseno para Mecanizacion en Aluminio 193


Indice General 5

E. Planos del diseno para fabricacion en PVC 195


6 Indice General


Indice de Figuras

3.1. Major y minor frames . . . . . . . . . . . . . . . . . . . . . . . .30

3.2. Ejecucion cıclica . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3. Claves de interpretacion . . . . . . . . . . . . . . . . . . . . . . . 31

3.4. Sistema orientado a eventos . . . . . . . . . . . . . . . . . . . . .32

3.5. Pipelined system . . . . . . . . . . . . . . . . . . . . . . . . . .33

3.6. Sistema cliente-servidor . . . . . . . . . . . . . . . . . . . . . . .34

3.7. Maquina de estados . . . . . . . . . . . . . . . . . . . . . . . . .35

4.1. Arquitectura UNIX . . . . . . . . . . . . . . . . . . . . . . . . .40

5.1. Arquitectura TimeSys . . . . . . . . . . . . . . . . . . . . . . . .49

7.1. Monopodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

7.2. Bıpedos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

7.3. ASIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

7.4. PINO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

7.5. Cuadrupedos . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

7.6. Hexapodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

8.1. Diseno de la pata (aluminio) . . . . . . . . . . . . . . . . . . . .75

8.2. Garra y soporte (aluminio) . . . . . . . . . . . . . . . . . . . . .76

8.3. Sonar y soporte (aluminio) . . . . . . . . . . . . . . . . . . . . .77

8.4. Montaje completo (aluminio) . . . . . . . . . . . . . . . . . . . .77

9.1. Diseno de la pata (PVC) . . . . . . . . . . . . . . . . . . . . . .82

9.2. Soportes verticales (PVC) . . . . . . . . . . . . . . . . . . . . . .83

9.3. Garra y soporte (PVC) . . . . . . . . . . . . . . . . . . . . . . .84

8 Indice de Figuras

9.4. Sonar y soporte (PVC) . . . . . . . . . . . . . . . . . . . . . . .84

9.5. Montaje completo (PVC) . . . . . . . . . . . . . . . . . . . . . .85

9.6. Plantillas de fabricacion (PVC) . . . . . . . . . . . . . . . . . . . 86

9.7. Detalle hombro . . . . . . . . . . . . . . . . . . . . . . . . . . .90

9.8. Detalle codo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91

9.9. Detalle sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . .91

9.10. Pata montada . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

9.11. Detalle garra . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

9.12. Detalle lateral . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

9.13. Detalle trasero . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

9.14. Detalle frontal . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

9.15. Robot montado . . . . . . . . . . . . . . . . . . . . . . . . . . .96

10.1. Temporizacion de los servomotores . . . . . . . . . . . . . . . .100

10.2. Temporizacion del sonar . . . . . . . . . . . . . . . . . . . . . .101

10.3. Esquematico del AT90S8515 . . . . . . . . . . . . . . . . . . . .103

10.4. Esquematico del MAX232 . . . . . . . . . . . . . . . . . . . . .104

10.5. Esquematico del LM7805 . . . . . . . . . . . . . . . . . . . . . .105

10.6. Esquematico del SRF04 . . . . . . . . . . . . . . . . . . . . . . .106

10.7. Ventana del programa PCB . . . . . . . . . . . . . . . . . . . . .107

10.8. Las dos caras de la placa . . . . . . . . . . . . . . . . . . . . . .109

10.9. Fotografıa de la placa terminada . . . . . . . . . . . . . . . . . .112

11.1. Diagrama de flujo general ASM . . . . . . . . . . . . . . . . . .115

11.2. Diagrama de flujo del bloque inicial ASM . . . . . . . . . . . . .121

11.3. Recepcion de datos por puerto serie ASM . . . . . . . . . . . . .124

11.4. Control de los servomotores ASM . . . . . . . . . . . . . . . . .127

11.5. Temporizacion del sonar . . . . . . . . . . . . . . . . . . . . . .130

11.6. Bloque final ASM . . . . . . . . . . . . . . . . . . . . . . . . . .131

12.1. Funciones de pertenencia borrosa delante, izquierda y derecha . .150

12.2. Funciones de pertenencia borrosa para distancias . . . . . . . . .151

12.3. Red de Petri para las patas . . . . . . . . . . . . . . . . . . . . .152

12.4. Capas del Servidor . . . . . . . . . . . . . . . . . . . . . . . . .153


Indice de Figuras 9

13.1. Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161

C.1. Ventana del Archiver . . . . . . . . . . . . . . . . . . . . . . . .188

C.2. Konsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188

C.3. Instalacion de J2SE y NetBeans . . . . . . . . . . . . . . . . . .191

C.4. NetBeans IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . .191

C.5. Archiver con la RTJI . . . . . . . . . . . . . . . . . . . . . . . .192


10 Indice de Figuras


Mi mas sincero agradecimiento a1:

Angel Castano CastanoAntonio Jesus Sierra ColladoBenito Fernandez Rodrıguez

Guillermo Heredia BenotIsabel Prieto Lofkrantz

Jose Miguel Reynolds BarredoJose Juan Lopez Ruiz

Manuel Mejıa RodrıguezManuel Moreno Valiente

Mariangeles Repullo LopezMis padres

Pedro Morillo Morillo

1Ordenados alfabeticamente.

1

Introducci on

A ctualmente,JAVA es uno de los lenguajes de programacion orientado aobjetos mas popular, especialmente en el mundo Internet[30, 31]. Estapopularidad es debida a varios factores, entre ellos, al famoso eslogan deSUN “Escribe una vez, ejecuta en cualquier parte”, haciendo referencia

a la independencia de plataforma deJAVA .

Pero hay un terreno inexplorado por la especificacion deSUN: el mundo deltiempo real[10]. Siendo esto ası, entre los anos 1998-1999, comenzaron a surgirlas primeras ideas para el desarrollo de una especificacion de tiempo real paraJAVA . Esto fraguo, en el ano 2000, con la publicacion de la version 1.0 de la RTSJ(The Real-Time Specification for Java[27]). Pero no fue hasta mediados del ano2003, cuando se presento la primera maquina virtual deJAVA que implementaradicha especificacion, que se pudieron comenzar a realizar los primeros programasde tiempo real, enteramente programados enJAVA . En esta ocasion solo se dabasoporte para plataformas conLinux, puesto que el desarrollo corrio a cargo de lacompanıa TimeSys, que ademas desarrollakernelsdeLinux modificados para darsoporte de tiempo real[17, 20]. Actualmente, el desarrollo en este nuevo campocontinua.

1.1. Motivaci on

E l primer contacto que el autor del presente proyecto tuvo con la RTSJ fue aprincipos de 2002, al realizar un trabajo sobre dicha especificacion, para la

asignaturaFundamentos de Telematica, asignatura optativa de la titulacion Inge-niero de Telecomunicacion, dependiente delArea de Telematica.

14 Introduccion

En el ano 2003, tras surgir la primera maquina virtual deJAVA para tiemporeal, se realizaron las primeras pruebas, para ver si era viable su uso, y viendo queera posible, se decidio buscar alguna aplicacion interesante, para poder utilizarloy realizar, con la misma, el Proyecto Fin de Carrera.

Por otra parte, en el curso 2002-2003, el autor participo en el proyectoCentol-lo, en la asignaturaControl y Programacion de Robots, dependiente delDeparta-mento de Sistemas y Automatica.

A partir de estas dos experiencias, surgio, con un espıritu integrador de co-nocimientos, adquiridos a lo largo de la carrera, la idea de aplicar la RTSJ a unnuevo prototipo de hexapodo, que ademas se tenıa intencion de desarrollar ensu totalidad, desde el diseno mecanico y electronico, hasta elsoftwarede con-trol necesario. El resultado del desarrollo de estas primeras ideas, es el presenteProyecto Fin de Carrera.

1.2. Objetivos

D esde un principio, la intencion principal al marcar los objetivos del Proyec-to era, poder aplicar, de forma practica, la mayor cantidad posible de

conocimientos teoricos adquiridos a lo largo de la carrera, siempre con la ideasubyacente de integrar dichos conocimientos. Por ello, se ha querido desarrollarun prototipo de robot hexapodo, disenando y fabricando su estructura, implemen-tando la electronica necesaria para su control y, creando una estructurasoftware,disenada en capas, que permita el uso de la plataforma para la realizacion de prue-bas diversas, a nivel de control articular y de navegacion. Para ello, se ha queridoque el robot tenga cierta capacidad de interaccion con el entorno. Por ello se haquerido que pueda detectar el contacto con el suelo de las patas, y poder hacer usode algun tipo de sensor a partir del cual poder navegar.

A nivel desoftwarede control, uno de los requistos ha sido, obviamente, el usode la RTSJ.


Introduccion 15

1.3. Estructura de la Memoria

La memoria se ha estructurado en partes bien diferenciadas, que a su vez sedividen en una serie de capıtulos. Estas partes son:

1. Estado del Arte, en el que se realiza una panoramica general, sobre lostemas mas importantes sobre los que se va a trabajar, a lo largo del proyecto.

Primero se introduce al lector, en el capıtulo 2 (Sistemas de Tiempo Real),a los sistemas cuyo correcto funcionamiento implica el cumplimiento deciertas restricciones temporales.

A partir del capıtulo 3 (Sistemas Operativos de Tiempo Real), se pasa aanalizar las implicaciones en el comportamiento que tienen los sistemasoperativos, que se utilizan en aplicaciones de tiempo real, centrandose pos-teriormente en el sistema operativo de codigo abierto por excelencia:Linux(capıtulo 4, GNU/Linux y Tiempo Real). Una vez llegado a este punto, serealiza un analisis deTimeSys Linux(capıtulo 5), que es elkernelde tiem-po real sobre el que se va a ejecutar gran parte delsoftwarede control delproyecto.

En el capıtulo 6 (Real Time Specification for Java (RTSJ)), se pasa a descri-bir la extension deJAVA para tiempo real que se va a utilizar. Y para finalizaresta parte, se incluye un capıtulo dedicado a los robots con patas (7,Robotscon Patas).

2. Diseno Mecanico, en el que se describen los pasos seguidos en el diseno dela estructura del robot.

En el capıtulo 8 (Diseno Mecanico para NC), se justifica la estructura desar-rollada, pensada para mecanizarse en aluminio, y los problemas encontradospara implementar esta primera version.

En el capıtulo 9 (Diseno Mecanico para PVC), se presenta el diseno definiti-vo y, se explica, de forma detallada, el proceso necesario para la fabricacionartesanal de las piezas, el material necesario para su construccion, ası comoel proceso de montaje a seguir, para facilitar estoultimo, los conocimientosnecesarios a futuros desarrolladores.

Los planos de ambas versiones se encuentran en los apendices D y E, (Planosdel diseno para Mecanizacion en Aluminioy Planos del diseno para fabri-cacion en PVC), y en el CD adjunto estan los ficheros de piezas y montajeen 3D de ambos disenos, realizados conSolid Edge v12.

Ademas, en el apendice A (Ejemplo de Codigo en ISO), se presenta un ejem-plo de codigo utilizado al intentar mecanizar algunas piezas de la primeraversion.


16 Introduccion

3. Electronica y Software de Bajo Nivel

En capıtulo 10 (Electronica), se justifica el diseno de la electronica escogi-do, ademas de mostrar los esquemas de conexionado de los integrados y elrutadode la placa. Ademas, en el CD adjunto, estan, tanto en PDF como enEncapsulated PostScript, el positivo delrutadode placa, como la pegatinasuperior de la misma.

En el capıtulo 11 (Software de Bajo Nivel), se presenta elsoftwareen en-samblador desarrollado para el microcontrolador de la placa, que se encargatanto de controlar los servomotores, los sensores de las patas y el sonar, co-mo comunicarse, por puerto serie, con el programa servidor.

Puesto que elsoftwaredesarrollado es complejo, a causa de estar progra-mado en ensamblador y, ademas, tiene que cumplir restricciones tempo-rales varias (tanto de las senales PWM como la temporizacion del sonar), seexplican los bloques principales de codigo, acompanados de los correspon-dientes diagramas de flujo.

4. Cliente y Servidor

Puesto que al desarrollar elsoftwareen JAVA se ha utilizadojavadoc paragenerar documentacion detallada, en HTML, de toda la implementacion, yademas, por ser el codigo de ambas aplicaciones extenso, se ha optado porno incluir en la memoria, ni listados de codigo, ni explicaciones detalladasde cadaclase, metodo, etc. que aparecen en el codigo. Todo esto se puedeencontrar en el CD adjunto, y se puede visualizar con cualquier navegador.

En vez de esto, se ha preferido dar una vision de conjunto, a nivel estruc-tural y funcional, de las dos aplicaciones desarrolladas, explicando el disenorealizado desde una perspectiva de alto nivel, sin entrar en detalles de im-plementacion. Para ello, se dedica el capıtulo 12 (Servidor), a la aplicacionque se ejecuta sobre la maquina virtual paraTimeSys Linux, explicando suestructura de capas, y comentando algunas decisiones de diseno tomadas.Tras esto, en el capıtulo 13 (Cliente), se exponen las ideas que han guiadola implementacion de esta aplicacion, esta vez comentando brevemente latecnologıa FSEM (Full Screen Exclusive Mode) utilizada.

5. Ampliaciones

Puesto que a lo largo del diseno e implementacion del sistema surgen nu-merosas ideas para ampliaciones futuras, e incluso futuras lıneas de trabajo,se ha incluido esta parte. En la misma se exponen, por capıtulos, estas ideas,desde elDiseno Mecanico (capıtulo 14), hasta elSoftware de Alto Nivel(capıtulo 16), pasando porElectromica y Software de Bajo Nivel(capıtulo15).


Introduccion 17

Por ultimo, antes de llegar a los apendices, se ha incluido un capıtulo deconclusiones (17), en el que se exponen a las que se ha llegado.

6. Apendices

Esta parte engloba informacion diversa que, siendo fundamental para elproyecto, no se considera que deba aparecer en otras partes del mismo.

En el apendice A (Ejemplo de Codigo en ISO), se muestra un ejemplo decodificacion para el mecanizado de una de las piezas del primer diseno.

En el apendice B (Instalacion de Debian Woody), se explica como con-seguir tener completamente operativa la plataforma que se ha utilizado parael desarrollo de la aplicacion servidora.

En el apendice C (Instalacion de TimeSys Linux y JavaVM), se muestracomo instalar elkernelde tiempo real utilizado, ası como la maquina virtualde timpo real paraJAVA .

En los apendices D y E (Planos del diseno para Mecanizacion en Aluminioy Planos del diseno para fabricacion en PVCrespectivamente), se incluyenlos planos de las piezas de los dos disenos mecanicos realizados.


18 Introduccion

1.4. Contenido del CD adjunto

A continuacion se especifican las carpetas y su contenido:

✵ electronica

✯ layout.pdf Rutadode las pistas y pegatina superior de la placa decircuito impreso.

✵ ensamblador

✯ 4414DEF.INC Definiciones que se incluyen al principio del codigoen ensamblador.

✯ CODIGO.ASM Fichero de texto que contiene el codigo en ensam-blador para el AT90S8515.

✯ CODIGO.HEX Codigo en hexadecimal.

✯ CODIGO.LST Codigo fuente con principio de lınea marcada con ladireccion de memoria que ocupara.

✯ CODIGO.OBJ Codigo objeto.

✵ mecanica

✯ aluminio Modelado 3D de las piezas del primer diseno, ensamblajede las mismas y planos, todo ello en formatoSolid Edge v12. Ademasse incluyen los planos en formato PDF.

✯ pvc Modelado 3D de las piezas del segundo diseno, ensamblaje delas mismas y planos, todo ello en formatoSolid Edge v12. Ademas seincluyen los planos en formato PDF.

✯ plantillas Plantillas de fabricacion, en formato PDF, para construir elprototipo.

✵ memoria

✯ portada.pdf Portada de la memoria del proyecto, generada con LATEX.

✯ memoria.pdf Memoria del proyecto, con marcadores, generada conLATEX.

✵ presentacion

✯ presentacion.pdf Presentacion del proyecto, generada con LATEX.


Introduccion 19

✵ software

✯ docCliente Documentacion en HTML, generada conJAVADOC, apartir del codigo fuente de la aplicacioncliente.

✯ docServidor Documentacion en HTML, generada conJAVADOC, apartir del codigo fuente de la aplicacionservidor.

✯ cliente Codigo fuente enJAVA , y ficheros de clase compilados, de laaplicacioncliente.

✯ servidor Codigo fuente enJAVA , y ficheros de clase compilados, de laaplicacionservidor.


20 Introduccion


Bloque I

Estado del Arte

2

Sistemas de Tiempo Real

L os sistemas y aplicaciones de tiempo real son uno de los campos quemas desarrollo esta experimentando en losultimos tiempos, tanto enla industria (control y robotica) como en el campo de las telecomuni-caciones. Este fuerte desarrollo esta generando una gran demanda de

herramientas y lenguajes especializados exclusivamente en estos campos.

2.1. Definicion

Un sistema de tiempo reales un sistema informatico [23] que:

✵ Interacciona repetidamente con su entorno fısico.

✵ Responde a los estımulos que recibe del mismo dentro de un plazo de tiem-po determinado.

Pero ademas, para que el funcionamiento del sistema sea correcto no basta conque las acciones sean correctas, sino que tienen que ejecutarse dentro de un inter-valo de tiempo especificado.

24 E�ado del Arte

2.2. Caracterısticas de los STR

1. Gran tamano y complejidad

✵ Algunos STR tienen millones de lıneas de codigo. En este grupo seengloban los SCADA, como CUBE o Genesis, que son programasde control a nivel supervisor y de adquisicion de datos, con los quees posible controlar, por ejemplo, toda una planta industrial desde ununico equipo (obviamente a nivel supervisor). Esto es posible graciasa la conexion en red, por medio de buses de control, de toda la maqui-naria (robots, maquinas de control numerico,. . . ).

✵ La variedad de funciones aumenta la complejidad incluso en sistemasrelativamente pequenos. Esto es debido a que el alto nivel de inte-gracion y la produccion en serie de microcontroladores permite dar,a un relativamente bajo coste, funcionalidades muy complejas a losdispositivos a controlar.

2. Simultaneidad de acciones (concurrencia)

✵ Los dispositivos fısicos controlados funcionan al mismo tiempo. Dehecho, en una cadena de montaje, lo ideal es conseguir que cada etapaeste sincronizada con las demas, para que no se produzcan cuellos debotella.

✵ Los componentes desoftwareque los controlan actuan concurrente-mente. Un caso tıpico puede ser el sistema de navegacion automaticade un avion, en el que son muchos los dispositivos (flaps, turbinas,estabilizadores,. . . ) que tienen que trabajar en colaboracion para queno ocurran catastrofes.

3. Dispositivos de entrada y salida especiales

✵ Los manejadores de dispositivos forman parte delsoftwarede apli-cacion. Hay que tener en cuenta que en la definicion se comento queel sistema tiene que interactuar con el entorno, y la forma que se utilizaes a traves de dispositivos de lo mas dispares, desde lıneas digitales oanalogicas hasta los mas innovadoresSmart Sensors.

4. Seguridad y fiabilidad

✵ Dentro del tiempo real estan los sistemas crıticos, en los que los fallospueden tener consecuencias graves:

✯ Perdida de vidas humanas.


Si�emas de Tiempo Real 25

✯ Perdidas economicas.✯ Danos medioambientales.

5. Determinismo temporal

✵ Las acciones suelen tener que realizarse en intervalos de tiempo deter-minados, siendo los retardos incontrolados muy perjudiciales.

✵ Es fundamental que el comportamiento temporal de los STR sea de-terminista, puesto que no se puede dejar al azar la sincronıa entre di-ferentes tareas o eventos, como puede ser la generacion de senales decontrol directo o la supervision de las secuencias de arranque y paradade sistemas grandes.

✵ Por otra parte, el sistema debe responder correctamente en todas lassituaciones, por lo que hay que prever el comportamiento en el peorcaso posible. Esto es tan importante, que el gasto que se invierte en sis-temas de simulacion y tiempo de pruebas, suele ser considerablementemayor al que se invierte en el desarrollo inicial.

2.3. Tipos de requisitos temporales

1. Tiempo real estricto (hard real-time)

✵ Todas las acciones deben ocurrir dentro del plazo especificado. En estegrupo se engloban las aplicaciones en que la perdida de un dato omuestra, o la generacion tardıa de senales de control puede inutilizaro incluso destruir el sistema.

✯ Ejemplo: control de vuelo.

2. Tiempo real flexible (soft real-time)

✵ Se pueden perder plazos de vez en cuando, y el valor de la respuestaperdida decrece con el tiempo.

✯ Ejemplo: adquisicion de datos.

3. Tiempo real firme (firm real-time)

✵ En este caso se pueden perder plazos ocasionalmente pero, a diferenciadel tiempo real flexible, una respuesta tardıa no tiene valor alguno.

✯ Ejemplo: sistemas multimedia.

Por ultimo, hay que destacar que en un mismo sistema pueden coexistir com-ponentes con distintos tipos de requisitos temporales.


26 E�ado del Arte


3

Sistemas Operativos de Tiempo Real

L os SISTEMAS OPERATIVOS DE TIEMPO REAL (SOTR) son sistemasdonde el correcto funcionamiento y ejecucion de las tareas no dependentanto de como se realicen, sino mas bien decuandose realicen. Por tan-to, para que las tareas se realicen exactamente en el momento adecuado,

los SOTRtienen que permitir predecir y controlar cuando las tareas son ejecu-tadas.

3.1. Caracterısticas Basicas

Los SOTRtienen que presentar las siguientes caracterısticas[18]:

✵ Respuesta predecible y rapidapara sucesos urgentes.

✵ Alto grado de capacidad de planificacion de tareas:Los requisitos tempo-rales del sistema tienen que ser satisfechos incluso bajo alto grado de usode recursos.

✵ Estabilidad bajo condiciones de sobrecarga temporal de sucesos:Cuandoel sistema esta saturado de sucesos y es imposible cumplir con los plazosde todas las tareas asociadas, los plazos de tareas crıticas, previamente se-leccionadas, deben ser garantizados de todas formas.

Los criterios a seguir para evaluar la calidad de losSOTRdifieren de los quese usan para los SO no de tiempo real. En la siguiente tabla se resumen estascaracterısticas:

28 E�ado del Arte

SO no TR SOTR

Capacidad Alto throughput. Capacidad deplanificacion de tareas:Habilidad del sistema paracumplir todos los plazospara todas las tareas.

Respuesta Respuesta en media lo masrapida posible.

Tiempo de respuesta peoracotado:se conocea prioriel tiempo de respuesta maslento que garantiza elsistema.

Sobrecarga El sistema hace un repartolo mas justo posible entrelas diferentes tareas.

Estabilidad: en situacionesde sobrecarga, el sistema escapaz de cumplir los plazosde las tareas mas criticas, nopermitiendo que las menoscrıticas se ejecuten hastahaber terminado con lasprimeras.

3.2. Campos de Aplicacion de losSOTR

Los usos que se hacen losSOTRincluyen los siguientes campos:

✵ Sistemas de telecomunicacion.

✵ Control en automocion.

✵ Estaciones de trabajo y servidores multimedia.

✵ Sistemas de procesamiento de senal.

✵ Sistemas de radar.

✵ Electronica de consumo.

✵ Control de procesos.

✵ Sistemas automaticos de produccion.

✵ Sistemas SCADA (Supervisory Control And Data Acquisition).


Si�emas Operativos de Tiempo Real 29

✵ Generacion y transporte de energıa electrica.

✵ Sistemas de fabricacion de semiconductores.

✵ Sistemas de defensa.

✵ Avi onica.

✵ Control del trafico aereo.

✵ Sistemas de navegacion autonoma.

✵ Sistemas de control de vehıculos.

✵ Satelites.

✵ Sistemas de control de energıa nuclear.

3.3. Taxonomıa de las Arquitecuras de Software paraTiempo Real

Practicamente todas las aplicaciones para tiempo real hacen uso de al menosuno de los siguientes cinco patrones:

1. Ejecucion cıclica.

2. Sistemas orientados a eventos, con actividades tanto periodicas como ape-riodicas.

3. Sistemas basados en comunicacion entre tareas (pipelined systems).

4. Sistemas cliente-servidor.

5. Sistemas de maquina de estados.


30 E�ado del Arte

3.3.1. Ejecucion cıclica

Un sistema de ejecucion cıclica consiste en que se repita, de forma continua, unconjunto de tareas (major frames). Cadamajor frameesta dividido en pequenasranuras de tiempo (minor frames). Las tareas son planificadas sobre este esquema,asignandolesminor framesespecıficas.

✵ Se utiliza un reloj para lanzar una tarea cadaminor frame.

✵ Un conjunto deminor framesno repetidos forman unmajor frame.

✵ Las operaciones estan implementadas como procedimientos, y esta preesta-blecido el orden de ejecucion.

✵ Cuando unminor framecomienza, la tarea que se encarga de gestionar elreloj, llama a los procedimientos que pertenezcan a dichominor frame, enel orden establecido de antemano.

✵ La concurrencia no se utiliza, las operaciones largas se tienen que dividirmanualmente en varias mas cortas, para que quepan en losminor frames.

FUNCION 1 (una vezcada 2 minor frames)




MINOR FRAMES

MAJOR FRAME

SE REPITE DEFORMA CONTINUA

MAJOR FRAME

Figura 3.1:Major y minor frames.



El esquema de ejecucion es el siguiente:

E/S DISPOSITIVO

E/S DISPOSITIVO

FUNCION 2

FUNCION 3

FUNCION 4

FUNCION 1

CICLICAEJECUCION

DE RELOJINTERRUPCION

Figura 3.2: Ejecucion cıclica.

Paraeste y siguientes diagramas, las claves para la interpretacion son las si-guientes:

INVOCACION/ACCESO

DISPARO/ACCESO DIRECCIONAL

MENSAJE UNIDIRECCIONAL

HILOACTIVO

LLAMADASA FUNCIONES

ACCESO A RECURSOSCOMPARTIDOS(SECCIONES CRITICAS)

Figura 3.3: Claves de interpretacion.


32 E�ado del Arte

3.3.2. Sistemas Orientados a Eventos

Un sistema orientado a eventos utiliza la terminacion de procesos de E/S (en-trada/salida) de tiempo real, o eventos de reloj, para lanzar las tareas programadas.Muchos sistemas de tiempo real basados en Linux siguen este modelo.

A las tareas se le pueden asignar prioridades de las siguientes formas:

✵ Las prioridades se pueden determinar por restricciones temporales.

✵ Tambien se puede manejar un sistema de dependencia semantica, aunqueesta aproximacion puede causar problemas de planificacion.

La concurrencia resultante requiere de sincronizacion (semaforos, mutex,. . . ).

✵ Para obtener una respuesta predecible, los mecanismos de sincronizaciontienen que evitar las inversiones de prioridad incontroladas.

✵ Para poder mantener que la respuesta sea predecible, los eventos aperiodi-cos tienen que cumplir con los lımites de utilizacion del sistema.


GESTOR DESALIDA 1

GESTOR DESALIDA 2

TAREA 1

TAREA 2

TAREA 3

TAREA 4

E/S DISPOSITIVO

E/S DISPOSITIVO

R1

R2

Figura 3.4: Sistema orientado a eventos.



3.3.3. Pipelined Systems

Los pipelined systemsutilizan mensajes entre procesos (preferiblemente conprioridades), ademas de la terminacion de procesos de E/S de tiempo real, y even-tos de reloj, para lanzar las tareas programadas.

El control de flujo para un evento se realiza a traves del sistema, desde origena destino.

Ası, estos sistemas se pueden describir como un conjunto de lıneas de comu-nicacion para invocar tareas.

Las prioridades entre tareas no tienen tanta importancia:

✵ Si la lınea de comunicacion es unidireccional, utilizando prioridades cre-cientes se consigue minimizar el crecimiento de la cola de espera.

✵ Si la lınea de comunicacion es bidireccional, sera mejor asignar prioridadesde tal forma que sean mas o menos iguales a lo largo de toda la lınea decomunicacion.


E/S DISPOSITIVOADQUIS DE

DATOSCOTEJO PROCESO

E/S DISPOSITIVO FILTRADOGESTOR DE

SALIDA 1CORRELACION

GESTOR DESALIDA 2

Figura 3.5: Pipelined system.


34 E�ado del Arte

3.3.4. Sistemas cliente-servidor

Los sistemas cliente-servidor usan mensajes entre tareas, ademas de la termi-nacion de procesos de E/S de tiempo real, y eventos de reloj, para lanzar las tareasprogramadas.

Lo que se hace es bloquear las tareas emisoras, o lo que es lo mismo, losclientes, hasta que reciben una respuesta de los servidores.

Ası, el control de un evento se reduce a ununico nodo del sistema, mientrasque el flujo de datos es distribuido.

Al igual que en lospipelined systems, las prioridades de las tareas tienen pocaimportancia:

✵ Idealmente, las servidores heredan las priorodades de sus clientes. Esto espoco practico, ası que para diferentes tareas las prioridades asignadas suelenser las mismas, usando prioridades solo para los mensajes, evitando ası loscuellos de botella.

E/S DISPOSITIVO

E/S DISPOSITIVOADQUIS DE

DATOS

SERVIDORDE DATOS

PETIC DEATRIBUTO

GESTOR DESALIDA 1

GESTOR DESALIDA 2FILTRADO


Figura 3.6: Sistema cliente-servidor.



3.3.5. Sistemas de maquina de estados

En este tipo de arquitectura, el sistema se divide en un conjunto de maquinasde estado finitas, concurrentes entre sı. Cada maquina de estados se utiliza paramodelar el comportamiento de un objeto activo o reactivo. Cada objeto esta cadamomento en uno de un numero finito de estados, esperando un evento. La llegadade un evento produce una transicion, que puede involucrar un cambio de estado yla ejecucion de algunas acciones asociadas a dicha transicion.

Las maquinas de estados siguen normalmente una semantica del tipo “se eje-cuta hasta completar”, en la cual la maquina no puede aceptar un nuevo eventohasta que ha terminado con el evento anterior. Para asegurar esto, la maquina deestados suele estar controlada completamente por un solo hilo, que ejecuta un bu-cle de eventos, para recibir eventos.


RE

AN

UD

A

EN MARCHA

REANUDALA MARCHA

AVANZA

FRENOACCIONADO

APA

GA

DO

DE

MO

TO

R

REANUDANDO

APAGADO

INICIO

ACELERANDO

DETENIDO

AC

EL

ER

A

ENCENDIDO ESTADOOCIOSO

Figura 3.7: Maquina de estados.


36 E�ado del Arte

3.3.6. Comparativa entre las Diferentes Arquitecturas

Beneficios Inconvenientes

Ejec. cıclica Simple.Determinista.Repetible.Facil de entender.Metodo mas comun.El mejor para sistemascrıticos y de seguridad.

Fragil: si se anade ocambia algunprocedimiento, lo masprobable es que elsistema falle.Muy complejo demantener.Solo es bueno parasistemas pequenos ysimples, que no necesitencapacidades dinamicas.

Orient. Eventos Basado en prioridades.Relativamente simple.Bueno para sistemas queson analizablesestadısticamente (sin quehaya variacionesdinamicas en la carga).

No esta tan dotado paramanejar entornosdistribuidos como otrasarquitecturas.

Pipelined Facilmente utilizable enentornos distribuidos.

Complejo de analizar.Menos predecible queotras arquitecturas.

Cliente-Servidor Trabaja bien con CORBApara tiempo real y otrosestandares orientados aobjeto.Simplifica la depuracionporque usarealimentacionbidireccional.Bueno para paradigmasorientados a objeto ydistribuidos.

Complicado de analizar.Usa gran cantidad derecursos a causa deltrafico adicional demensajes.

Maq. Estados Trabaja bien con CORBApara tiempo real y otrosestandares orientados aobjeto.

Complicado de analizar.



3.4. Algunos ejemplos deSOTR

✵ LynxOS

✵ Marte (Universidad de Cantabria)

✵ pSOS

✵ QNX

✵ RTEMS

✵ RT-Linux (FSM Labs)

✵ TimeSys Linux

✵ VRTX

✵ VxWorks


38 E�ado del Arte


4

GNU/Linux y Tiempo Real

G NU/Linux[43] es un sistema operativo de tiempo compartidoclonicode UNIX que corre sobre gran diversidad de plataformas. Su licenciapermite su libre distribucion y se suministra junto con el codigo fuente,al igual que ocurre con la mayorıa delsoftwaredisponible para Linux.

Linux no es propiedad de nadie. Se mantiene y desarrolla por una comunidad deusuarios a nivel mundial, conectada a traves de Internet.

4.1. Caracterısticas de Linux

✵ Multitarea.

✵ Multiusuario.

✵ Memoria virtual.

✵ Multiplataforma: i386, M68k, Alpha, SPARC, ARM,. . .

✵ Es abierto.

✵ Compatible POSIX.

40 E�ado del Arte

4.1.1. Arquitectura UNIX

Al ser unclon de UNIX, sigue su misma arquitectura[49]. Una de las carac-terısticas mas notables de dicha arquitectura, es que la interfaz de programacionpara el acceso a los elementoshardwarees uniforme, es decir, que la imple-mentacion especıfica se oculta al programador tras las llamadas al SO (systemcalls).

Compiladores, procesadores de textos, hojas de cálculo, ftp,telnet, navegadores web, etc.

Shell de UNIX

Bibliotecas de lenguajes: C, C++, Java, FORTRAN, etc.

Interfaz de llamadas al sistema (puntos de entrada al núcleo)

Comunicaciónentre procesos(IPC)

Admon deprocesos

Planificaciónde la CPU

archivosAdmon de

Admon delalmacenamientoprimario ysecundario

Núcleo de UNIX:

Controladores de dispositivos: controlador del ratón, deimpresora, de CD−ROM, de disco duro, etc.

Hardware

Figura 4.1: Arquitectura UNIX.


GNU/Linux y Tiempo Real 41

4.2. Breve resena historica

✵ 1969:AT&T desarrolla el SO MULTICS. Se definen nuevos conceptos quese aplicaran mas tarde a UNIX.

✵ 1971:Ken Thompson implementa UNIX en una vieja PDP-7.

✵ 1973:Ken Thompson y Denis Ritchie reescriben UNIX en lenguaje C.

✵ 1975:UNIX V.7 pasa a las universidades (Berkeley).

✵ 1980..1985:Diversas versiones de UNIX proliferan: XENIX (Microsoft),UNIX SV (AT&T), BSD, AIX.

✵ 1984:Richard Stallman comienza el proyecto GNU.

✵ 1991:Linus Torvalds escribe unkerneltipo UNIX (Linux) basado en Minixque se adapta al sistema GNU.

✵ 1992:Linux adquiere licencia GPL. Ejecuta X.

✵ 1994:Linux 1.0.

✵ 1996:Linux 2.0. Proliferan las distribuciones de Linux.

✵ 1999:Linux 2.2. Aumenta el interes de las grandes empresas por GNU/Linux.

✵ 2001:Linux 2.4.

✵ 2001..?:Millones de usuarios, cientos de libros, decenas de revistas, dis-tribuciones avanzadas, escritorios de usuario,. . .

✵ 2004 Linux 2.6. Grandes empresas, como Microsoft o Novell, inviertengrandes sumas de dinero para introducirse definitivamente en el mundo Lin-ux para empresas.

4.3. Proyecto GNU

✵ Objetivo:distribucion y promocion delsoftware.

✵ Licencia GPL (software libre):

✯ Derecho a obtener el codigo fuente.


42 E�ado del Arte

✯ Derecho a modificar, recompilar y redistribuirlo.

✯ Obligacion de conservar el Copyright y la licencia.

✯ Obligacion de proporcionar el codigo fuente.

✵ Otras licenicas de software libre:

✯ Tipo Berkeley.

✯ Software del dominio publico: sin Copyright.

4.4. Problemas mas comunes al usar Linux para Sis-temas de Tiempo Real

L inux tiene innumerables puntos fuertes como sistema operativo, tal y co-mo se ha comentado anteriormente. Pero al desarrollar aplicaciones en el

campo del tiempo real, aparecen ciertos problemas al utilizar los componentesGNU/Linux estandares. Estos problemas, fundamentalmente son:

✘ Tiene un numero reducido de niveles de prioridad.

✘ No tiene soporte para la inversion de prioridades.

✘ Soporte limitado para QoS (Quality of Service —calidad de servicio—).

✘ No tiene soporte paratimers(temporizadores) de alta resolucion.

✘ No tiene soporte para las tareas periodicas.

✘ Respuesta delkernel (nucleo del SO) potencialmente no predecible, consystem calls(llamadas al SO) que pueden llegar a ser peligrosamente largas.

✘ Soporte limitado para sistemas no de sobremesa1.

Por tanto, las extensiones y anadidos a Linux suelen ser desarrollados paramanejar y eliminar en lo posible los problemas anteriores.

1En gran cantidad de situaciones, los sistemas de tiempo real utilizan sistemas procesadoresminimalistas, lo que se conoce comoembedded systems, para realizar tareas crıticas de adquisicionde datos y control directo.


GNU/Linux y Tiempo Real 43

4.5. Diferentes lıneas de diseno de SOTR basadosen Linux

L as aproximaciones al problema de crear sistemas operativos con capacidadesde tiempo real, se ha realizado de muy diversas maneras. En el caso de Linux,

se puede hacer una division bastante clara, que engloba todos los casos conocidoshasta la fecha, haciendolo en cuatro categorıas:

1. Anadiendo un nuevokerneldebajo de la capa Linux.RT-Linux, de FSM-Labs, yReal-Time Applications Interface (RTAI), de la Politecnica de Milan,son ejemplos de esta lınea de desarrollo.

Ventajas Inconvenientes

✔ Rendimiento muy alto.

✔ Pocas modificacionesrequeridas.

✔ Codigo fuente abierto(open source).

✘ Fallos en alguna tareallevan al bloqueo einutilizacion del sistema(system crash).

✘ Necesita manejadores dedispositivo (device drivers)especıficamentedesarrollados para estacombinacion de sistemasoperativos.

✘ Interfaz de programacionde aplicaciones (API)especıfica.

2. Extendiendo elkernelLinux existente, para que provea de capacidades detiempo real. Este acercamiento es el que realizaTimeSys Linux.


44 E�ado del Arte

Ventajas Inconvenientes

✔ Soporte paraembeddedsystems.

✔ Extensiones POSIX paratiempo real.

✔ QoS garantizado.

✔ Usa los mismosdriversdesarrollados para Linux,sin modificarlos.

✔ Usa todas las aplicaciones,utilidades y compiladorespara Linux.

✔ Da soporte para Real-TimeJava.

✔ Alta resolucion en latemporizacion.

✔ Open source.

✘ Rendimiento no tan altocomo en la aproximacion 1.

3. Anadiendo un servidor de sistemas operativos sobre unmicrokernelde tiem-po real. Un ejemplo de esto consiste en ejecutarMK-Linux sobre elMachmicrokernel. Ası, se pueden ejecutar programas nativos de ambos sistemas,a la vez, sobre la misma plataforma.

4. Anadiendo compatibilidad binaria con un SOTR.


5

TimeSys Linux

TimeSys Linuxes un sistema operativo de tiempo real basado en Linux, y en unprincipio fue disenado paraembedded systems. Actualmente, se utiliza tambien enequipos de sobremesa y estaciones de trabajo (work stations).

5.1. Funcionalidades de TimeSys Linux

TimeSys Linuxes un sistema operativo de tiempo real completo. Las carac-terısticas mas importantes que se encuentran en este sistema operativo son:

✔ Verdaderas aplicaciones de tiempo real para Linux:Cualquier proceso deLinux puede convertirse en un proceso de tiempo real. Se usan los procesossin modificar respecto de una plataforma Linux normal, y se les asignancapacidades de tiempo real cuando se desea.

✔ Soporte POSIX[33] (Portable Operating System Interface) para las necesi-dades de tiempo real:El sistema provee de soporte para el paradigma tradi-cional sobre niveles de prioridad fijos con una polıtica de planificacion pre-decible, soportando 2048 niveles de prioridad. Ademas, soporta lainversionde prioridadsobre losmutexespara evitar el problema de lainversion deprioridad incontrolada.

✔ Manejo y reparto de QoS (Quality of Service):TimeSys Linuxprovee desoporte directo y explıcito para el manejo de la calidad de servicio que seda a cada aplicacion, por medio de la notacion dereserva de CPU y red.

✔ Soporte de tiempo real para aplicaciones heredadas de sistemas Linuxnormales:Se puede dotar de garantıas de calidad de servicio (QoS) a apli-caciones desarrolladas preivamente para Linux.

46 E�ado del Arte

5.2. Comparativa entre TimeSys Linux y Linux es-tandar

TimeSys Linux Linux Est andar

Tamano 500KB - 1.2MB 1 - 2MB

Planificador Precisa asignacion deprioridades (2048niveles).Reservas de CPUplenamente manejadas yrespetadas.

Planificacion estandar deUNIX.

Resolucion Llevado a la resoluciondel reloj del sistema(10µso menos).

Muy baja (10mso mas).

Herramientas TimeWiz.TimeTrace.TimeStorm.

Limitadas.

POSIX TR Sı. No.

Inv. Prioridades Sı. No.

Tareas Period. Sı. No.


TimeSys Linux 47

5.3. Comparativa entre TimeSys Linux y los SOTRestandar

L a potencia y las caracterısticas de Linux lo convierten en un punto de partidamuy bueno para crear unSOTR. El modelo de desarrollo basado en codi-

go abierto, es decir, que el codigo fuente de los programas esta a disposicion detodo el mundo, para usarlo y modificarlo, ha llevado a un autenticoboomen elcampo del desarrollo de aplicaciones para Linux. Se puede sacar partido tanto delos muchos anos de investigacion y desarrollo, como de la puesta a prueba en elfuncionamiento diario de todas estas aplicaciones. Esto da una gran fiabilidad alsistema, puntoeste muy importante a la hora de desarrollar unSOTR.

TimeSys Linux SOTR Estandar

Lic. ejecucion Gratis. De 10 centimos a 50e porlicencia.

Lic. fuentes Gratis. Mas de 200.000e porequipo.

Drivers Mas de 50.000 De 5 a 5.000

Aplicaciones Mas de 100.000 Numero limitado.


48 E�ado del Arte

5.4. Componentes Basicos de TimeSys Linux

Los componentes basicos de TimeSys Linux son:

✵ Linux kernel (TimeSys Linux).

✵ Extensiones para tiempo real (TimeSys Linux/Real-Time).

✵ Modulos de reserva de CPU (TimeSys Linux/CPU).

✵ Modulos de reserva de red (TimeSys Linux/NET).

✵ TimeTrace.

5.4.1. Caracterısticas Clave

Las caracterısticas mas notables deTimeSys Linuxson:

✵ TimeSys Linuxse diferencia de otrosSOTR basados en Linux, en que elkernelha sido modificado para manejar aplicaciones de tiempo real. Estoimplica, entre otras cosas, que si una aplicacion de tiempo real no responde(crashes), los demas procesos, y elkernel mismo, seguiran funcionandocorrectamente, como si nada hubiese pasado.

✵ La implementacion deTimeSys Linuxofrece un manejo muy preciso de latemporizacion, que mejora a su vez la calidad en el manejo de los recursosdel sistema.

✵ El soporte paraQoS(Quality of Service) esta disponible en forma de reser-vas de CPU.

✵ Soporta 2048 niveles de priordiad.

✵ Soportainversion de prioridad.

✵ Soporta tareas periodicas.

✵ Soporta elproc filesystemde Linux, el cual provee de informacion actua-lizada, en tiempo real, sobre elkernely los procesos que actualmente seestan ejecutando, ademas del estado delhardwarey el estado de reserva deelementos dentro del sistema.


TimeSys Linux 49

5.5. Arquitectura de TimeSys Linux

E n el sistema operativoTimeSys Linux, el codigo que provee de capacidadesespeciales para tiempo real, ademas de reservas de CPU y red, reside en

modulos[48], que pueden ser insertados en elkernelpara aumentar la funcionali-dad del mismo. Esta modularizacion permite dar al sistema toda la capacidad quepueda necesitar en diferentes contextos, pero manteniendo el tamano delkernellomas reducido posible.

Estos modulos (loadable kernel modules — LKM —), son codigo objeto, quepuede ser insertado o eliminado delkernel, cuando se reinicia el sistema o encualquier otro momento, cuando una aplicacion requiera de los mismos. Obvia-mente, desde el punto vista de la aplicacion, no existe distincion entre una llamadaal sistema que utilice funciones de los modulos o no, puesto queestos se ejecutandentro delkernel, en modo privilegiado (kernel mode).

A continuacion se presenta, de forma esquematica, la interaccion entre los di-ferentes elementos del sistema:

Hardware

Kernel Mode

User Mode Proceso deLinux

Proceso deLinux

Proceso deLinux

Kernel de LinuxNetwork

ReservationsModule

CPUReservations

Module

Real−TimeModules

TimeTraceHooks

LKM

Figura 5.1: Arquitectura TimeSys.


50 E�ado del Arte


6

Real Time Specification for Java(RTSJ)

6.1. Requerimientos del NIST

P ara definir laReal-Time Specification for Java, los miembros delJava Real-Time Experts Group(JRTEG) se basaron en las directrices marcadas en un

taller que hubo durante los anos 1998-1999, esponsorizado por el NIST (NationalInstitute of Science and Technology). Estas directrices [10] se pueden exponer ennueve puntos fundamentales, que son los siguientes:

1. La especificacion debe incluir un esqueleto (organizacion o estructura) parabuscar y descubrir los perfiles disponibles.

2. Toda recoleccion de basura debe tener acotados los retrasos que pueda in-troducir.

3. La especificacion debe definir las relaciones entre hilos de tiempo real de Ja-va al mismo nivel de detalle que esta disponible en los documentos estanda-res actuales.

4. La especificacion puede incluir API’s que permitan la comunicacion y sin-cronizacion entre tareas Java y no Java.

5. La especificacion debe incluir la gestion de eventos asıncronos tanto inter-nos como externos.

6. La especificacion debe incluir algun tipo de terminacion asıncrona de hilos.

52 E�ado del Arte

7. El nucleo debe proporcionar mecanismos para forzar la exclusion mutua sinbloquear.

8. La especificacion debe proporcionar un mecanismo para permitir al codigosaber si se esta ejecutando bajo un hilo de tiempo real o no.

9. La especificacion debe definir la relacion entre los hilos de tiempo real deJava y los que no son de tiempo real.

6.2. Requerimientos definidos por el JRTEG

E ste grupo, en un primer analisis, identifico ciertas carencias del lenguaje enla capacidad para que el programador pudiera predecir el comportamien-

to temporal del sistema. Identificaron como la causa de esto, tres caracterısticas:planificacion (scheduling), gestion de memoria y sincronizacion. Por ello deci-dieron anadir cuatro caracterısticas adicionales a Java, que son la gestion de even-tos asıncronos, transferencia de control asıncrona, terminacion asıncrona de hilosy acceso a memoria fısica. Aparte de estos cuatro elementos, utilizaron como prin-cipios de diseno [27] los siguientes puntos:

1. Aplicabilidad a entornos particulares Java.La RTSJ no puede incluir es-pecificaciones que restrinjan el uso para entornos particulares de Java, comoversiones del JDK o la Java 2 Micro Edition.

2. Compatibilidad hacia atras.Los programas ya existentes deben funcionaren las implementaciones de la RTSJ que se hagan.

3. Escribe una vez, ejecuta en cualquier parte (“Write once, run anywhere”).Este es tradicionalmente el punto fuerte de Java, por lo que es importantemantenerlo, pero esto puede resultar muy complicado por las restriccionestan fuertes que generan los sistemas de tiempo real.

4. Practica habitual contra capacidades novedosas.La idea es conseguir quela RTSJ sea capaz tanto de dar todas las funcionalidades que tienen actual-mente los lenguajes de tiempo real, pero a la vez sea capaz de facilitar laincorporacion, por parte de los desarrolladores desoftware, de nuevas ca-pacidades, no consideradas directamente en la especificacion.

5. Ejecucion predecible.Este es uno de los pilares del tiempo real, por lo quees imprescindible que sea prioridad de la especificacion, aunque esto puedasignificar perdidas en el rendimiento computacional.


Real Time Specification for Java (RTSJ) 53

6. No extender la sintaxis.Para facilitarle el trabajo a los desarrolladores desoftware, no se incluyen nuevas palabras reservadas ni nada parecido. Estoes muy conveniente, porque ası se tarda menos tiempo en familiarizarse conla especificacion. Esto es ası, pero para los creadores de la RTSJ resultamas engorroso, puesto que siempre es mas facil extender la sintaxis quetener que adaptarse a lo que ya hay hecho.

7. Variacion en las implementaciones.La RTSJ permite, a los implementa-dores de entornos y compiladores, cierta flexibilidad a la hora de crearlos,para adaptarlos a los requerimientos de sus posteriores usuarios.

Nota: Todas las clases e interfaces definidas por la especificacion estan dentro delpaquetejavax.realtime.

6.3. Threads (Hilos)

Este apartado contiene clases [27] que:

✔ Proveen de la capacidad para crear hilos que tienen una semantica mas pre-cisa en la planificacion quejava.lang.Thread.

✔ Permiten el uso deareas de memoria diferente de la memoria de pila parala ubicacion de objetos.

✔ Permiten la definicion de metodos que pueden ser interrumpidos de formaasıncrona.

✔ Proveen de semantica para la planificacion del manejo de eventos asıncro-nos.

La claseRealtimeThread extiende a la clasejava.lang.Thread. Los para-metros especıficos pasados al constructor, como sonReleaseParameters,SchedulingParameters y MemoryParameters permiten comunicarle al sistemalas exigencias temporales y de procesador que requiere el hilo.

La claseNoHeapRealtimeThread extiende a la claseRealtimeThread. A losobjetos de esta clase no les esta permitido referenciar o instanciar objetos de lamemoria convencional del entorno de ejecucion (heap), y pueden ejecutarse deforma segura con preferencia sobre elgarbage collector. Esto permite implemen-tar hilos de prioridad crıtica, puesto que manejan memoria separada y no tienenque sufrir el indeterminismo en la ejecucion del recolector de basura.


54 E�ado del Arte

6.4. Scheduling (Planificacion)


✔ Permiten la definicion de objetos con planificacion (schedulable).

✔ Manejan la asignacion del orden de ejecucion de objetos con planificacion.

✔ Desarrollan la facilidad de analisis para juegos de objetosschedulables.

✔ Controlan la admision de nuevos objetosschedulables.

✔ Manejan la ejecucion de instancias de objetosAsyncEventHandler yRealtimeThread.

✔ Asignan nuevas caracterısticas a los objetosschedulables.

✔ Asignan valores para la eleccion de la ejecucion de objetosschedulables.

✔ Definen contenedores temporales usados para forzar el correcto funciona-miento temporal para multiples objetosschedulables.

El planificador necesario para esta especificacion usa por defecto 28 niveles deprioridad. Esto es ası porque la mayor parte de los sitemas de tiempo real suelentener 32 niveles de prioridad, por lo que deja 4 niveles libres para el sistema, o paraposteriores modificaciones. El planificador esta reprepresentado por el interfazPriorityScheduler, que es llamado el planificador base (base scheduler). Esteinterfaz extiende a su vez al interfazjava.lang.Runnable.

El arbol de clases es:

✵ Object

✯ Scheduler

✴ PriorityScheduler

✯ SchedulingParameters

✴ PriorityParameters

✴ ImportanceParameters

✯ ReleaseParameters

✴ PeriodicParameters

✴ AperiodicParameters

✲ SporadicParameters



✯ ProcessingGroupParameters

Y por otra parte:

✵ java.lang.Runnable

✯ Schedulable

Los objetosschedulablesque necesita la especificacion estan definidos por lasclasesRealtimeThread, NoHeapRealtimeThread (vistos en el apartado anteri-or) y AsyncEventHandler.

La clase abstractaScheduler extiende ajava.lang, y esta pensada paraque se implementen los algoritmos de planificacion para gestionar a los objetosschedulabes. Deel es subclasePriorityScheduler.

De la clase abstractaSchedulingParameters son subclasesPriorityPa-rameters eImportanceParameters, usados por el planificador.

Las subclases deReleaseParameters encapsulan los requerimientos tempo-rales y de procesador de los hilos.

6.5. Memory Management (Gestion de memoria)


✔ Permiten la definicion de zonas de memoria fuera de la que es manejadatradicionalmente por java, a traves delgarbage collector.

✔ Permiten la definicion de zonas de memoria con tiempo de vida limitada(scoped memory).

✔ Permiten la definicion de zonas de memoria que contengan objetos con elmismo tiempo de vida que la aplicacion.

✔ Permiten la definicion de regiones de memoria mapeadas en zonas especıfi-cas de direcciones fısicas.

✔ Permiten la especificacion del area de memoria maxima que puede con-sumir y asignar un hilo de tiempo real.

✔ Permiten al programador preguntar por el algoritmo delgarbage collector,e introducir ciertas modificaciones en el mismo.



56 E�ado del Arte

✵ Object

✯ MemoryArea

✴ ImmortalMemory

✴ SizeEstimator

✴ ScopedMemory

✲ LTMemory

✲ LTPhysicalMemory

✲ VTMemory

✲ VTPhysicalMemory

✴ ImmortalPhysicalMemory

✯ PhysicalMemoryManager

✯ PhysicalMemoryTypeFilter

✯ RawMemoryAccess

✴ RawMemoryFloatAccess

✯ MemoryParameters

✯ GarbageCollector

MemoryArea es una clase abstracta para representarareas de memoria, fueradel alcance delgarbage collector. Sus subclases fundamentales sonImmortal-

Memory, ScopedMemory eImmortalPhysicalMemory. ConImmortalMemory seconsigue que todos sus objetos permanezcan hasta que finaliza la aplicacion. ConScopedMemory en cambio, se consigue que sus objetos tengan una vida temporallimitada, definida por medio de los parametros pertinentes.ImmortalPhysical-Memory permite por su parte, el manejo de memoria fısica, con un rango de direc-ciones definido.

Dentro deScopedMemory tenemos basicamente dos tipos de memorias:LT yVT. LT hace referencia a tiempo lineal, y requiere que los alojamientos en memoriatengan un coste en tiempo que dependa de forma lineal con el tamano del objeto,ignorando posibles optimizaciones en su uso.VT por su parte, hace referencia atiempo variable, puesto que no se usan las restricciones del caso anterior.

El PhysicalMemoryManager sirve a las clases anteriores para crear objetosde caracterısticas adecuadas, tanto teniendo en cuenta el tipo de memoria comosu uso por parte del SO.

Otra clase importante es laRawMemoryAccess, que permite crear objetos pormedio de los cuales se tiene un acceso directo a la memoria, de forma granular, anivel de byte, word, long,. . .



6.6. Synchronization (Sincronizacion)


✔ Permiten implementar el algoritmo de inversion de prioridad.

✔ Permiten la comunicacion entre hilos de tiempo real y no de tiempo real.


✵ Object

✯ MonitorControl

✴ PriorityCeilingEmulation

✴ PriorityInheritance

✯ WaitFreeWriteQueue

✯ WaitFreeReadQueue

✯ WaitFreeDequeue

MonitorControl permite un uso mas eficiente del concepto de monitor, ha-ciendo uso de dos algoritmos diferentes, uno en cada sublcase. Cabe destacar quela subclasePriorityInheritance implementa el algoritmo de inversion de pri-oridad, que consiste en que diferentes hilos, en situaciones especiales, puedenintercambiar dinamicamente sus prioridades. Un ejemplo clasico de esto es el ca-so en que un hilo, mas prioritario, requiere de un dato generado por un hilo menosprioritatio y tiene que esperar a que lo genere. En ese momento el hilo menos prio-ritario se vuelve mas prioritario, y una vez que genera el dato, vuelve a su estadode prioridad inicial.

WaitFreeWriteQueue, WaitFreeReadQueue y WaitFreeDequeue permitenla comunicacion entre hilos de tiempo real e hilos normales de Java. Esta facili-dad debe usarse con cuidado, puesto que en estos casos elgarbage collector, queintroduce indeterminsimo por parte del hilo no de tiempo real, puede afectar deforma indirecta al hilo de tiempo real.

6.7. Time (Tiempo)


✔ Permiten la descripcion de un punto temporal con una precision de hasta unnanosegundo (esta precision es dependiente del sistema subyacente).


58 E�ado del Arte

✔ Permiten distinciones entre dos puntos temporales, tiempos respecto de al-gun punto de arranque, e incluso la subdivision de un patron de periodoprincipal.


✵ java.lang.Comparable

✯ HighResolutionTime

✴ AbsoluteTime

✴ RelativeTime

✲ RationalTime

ConAbsoluteTime se definen puntos de tiempo respecto del reloj de la maqui-na, usandolo como referencia absoluta. Ası, usando el formato estandar de Java,un punto de tiempo podrıa ser “January 1, 1970, 00:00:00 GMT”.

ConRelativeTime se defienen tiempos relativos, es decir, un punto temporalposterior a un evento prefijado, por ejemplo. Ademas esta RationalTime, quepermite hacer subdivisiones de un patron de reloj. Esto es muyutil en sistemasdonde es necesaria la sincronizacion de multiples eventos a partir de unaunicasenal periodica.

6.8. Timers (Contadores)


✔ Producen tanto interrupciones periodicas comounicas, basadas en ununicoreloj del sistema.

✔ Son capaces de asociar a estas interrupciones, tanto periodicas comounicas,la ejecucion de codigo, basandose en la gestion de eventos asıncronos pro-vistos por la especificacion.


✵ Object

✯ Clock

Y ademas:



✵ AsyncEvent

✯ Timer

✴ OneShotTimer

✴ PeriodicTimer

ConClock se generan objetos capaces de controlar el o los relojes de tiemporeal del sistema. Tambien permite la identificacion del tipo de los mismos.

Timer es simplemente un interfaz, de los que cuelganOneShotTimer y Pe-

riodicTimer. OneShotTimer lanza la ejecucion de unAsyncEvent en ununicoinstante, yPeriodicTimer lo lanza de forma periodica.

6.9. Asynchrony (Eventos asıncronos)


✔ Proveen de mecanismos para condicionar la ejecucion del programa a laocurrencia de eventos tanto internos como externos.

✔ Proveen de mecanismos que permiten la transferencia asıncrona del control.

✔ Proveen de mecanismos que permiten la terminacion asıncrona de hilos.


✵ Object

✯ AsyncEvent

✴ Timer

✯ Interruptible

Por otra parte:

✵ Schedulable

✯ AsyncEventHandler

✴ BoundAsyncEventHandler

Y ademas:


60 E�ado del Arte

✵ java.lang.InterruptedException

✯ Timed

AsyncEvent se utiliza para representar algo que puede ocurrir, como una in-terrupcion hardware, una senal POSIX[33], o cualquier otro tipo de evento cuyaocurrencia tiene una fuerte dependencia con el entorno, y no con una periodici-dad temporal predecible. Por ello, es una clase importantısima para el tiempo real,puesto que permite una forma comoda de encapsular todo este tipo de eventosbasados en la interaccion con el entorno. Su mision principal es lanzar y manejarlos AsyncEventHandler, es decir, los gestores de eventos asıncronos. Los ge-stores de eventos asıncronos son muy similares a los hilos, pero ocupan compara-tivamente menos espacio y tienen ciertas caracterısticas especiales que se comen-tan a continuacion. Por una parte, se genera unAsyncEventHandler cada vez quese produce un evento, que es detectado por su correspondienteAsyncEvent, lan-zando al gestor, ocurriendo esto de forma asıncrona, a diferencia de como ocurrecon los hilos convencionales. Este gestor, en principio no tiene restricciones sobresi debe ser grande o pequeno, y no tiene limitaciones en lo que hace o deja de hac-er, pero lo que sı garantiza la especificacion es que, si se producen varios eventosseguidos del mismo tipo, su ejecucion se serializa.

Para los casos en que la generacion de un nuevo hilo produce una situacioncrıtica a causa de la falta de tiempo, se usa un objeto de la claseBoundAsync-

EventHandler, que esta permanentemente unido a un hilo.

Interruptible por su parte, es simplemente un interfaz que se utiliza paragenerar clases que manejen cierto tipo de excepciones.

Porultimo,Timed se utiliza para forzar que, al transcurrir un intervalo de tiem-po prefijado (scoped) se invoque de forma asıncrona el metodointerrupt(), queinterrumpe la ejecucion del gestor de eventos en cuestion.

6.10. System and Options (Manejo del Sistema)


✔ Proveen una forma de comunicacion de senales POSIX con eventos asın-cronos, si las senales POSIX estan disponibles en el sistema subyacente.

✔ Una de ellas permite operaciones que afectan a todo el sistema.

✔ Proveen de un sistema de seguridad adicional para el sistema, mas robustoque el requerido para las implementaciones de laJava Language Specifica-tion.




✵ Object

✯ POSIXSignalHandler

✯ RealtimeSecurity

✯ RealtimeSystem

Poco se puede comentar en este apartado, ademas de que cada clase implemen-ta una de las tres caracterısticas anteriores. Solo falta destacar que, en lo referentea seguridad, se refiere mayormente al acceso a memoria fısica.

6.11. Exceptions (Excepciones)

Y por ultimo, las excepciones.Estas simplemente van a manejar nuevas posi-bles ocurrencias, derivadas de las funcionalidades de las clases de los aparta-

dos anteriores, por tanto se referiran a cuestiones como direcciones de memoriano validas, tipos de memoria no validas, limitaciones de tiempo excedidas,. . .

6.12. Conclusiones

R especto a las directrices que se propusieron en el taller esponsorizado porel NIST, launica que no se cumple es la referente a la identificacion de los

perfiles del sistema, pero este es un detalle poco importante, puesto que no seutilizan estos tipos de parametros en la especificacion. Por lo demas, la especifi-cacion es muy completa, permitiendo manejar con soltura todas las visicitudes delos sistemas de tiempo real.

El manejo de hilos se vuelve mas robusto, puesto que se reduce notablemente elindeterminismo en el orden de ejecucion, introduciendo entre otras cosas, metodospara la sincronizacion totalmente predecibles. A parte, dentro de la sincronizacion,se implementan completamente dos algoritmos esenciales para el correcto funci-namiento de sistemas de tiempo real.

Se provee de todo tipo de facilidades para la planificacion de tareas, y se dejaabierta la posibilidad de incluir nuevas formas de gestionarla.


62 E�ado del Arte

La gestion de la memoria es un capıtulo aparte. Se desarrollan posibilidades deacceso directo a la memoria a partir de las direcciones fısicas, y la gestion librede la misma, utilizando conceptos como memoria inmortal y memoria de vidalimitada. Ademas, se facilita la identificacion y manejo de muy variados tiposde memorias fısicas, siendo esta una ventaja adicional, puesto que los sistemasactuales utilizan dispositivos de todo tipo. El control que, por otro lado permite dela misma, a traves de mejoras en la seguridad, es otro detalle a tener en cuenta.

Por otra parte esta el correcto manejo del tiempo, pudiendose acceder al relojdel sistema con mayor precision, e implementandose mecanismos para el manejode situaciones que requieren de acciones tanto periodicas como simples, despla-zadas en el tiempo. Ademas, se mejoran estas caracterısticas con el uso de unaclase capaz de subdividir la senal principal en fracciones de la misma.

Los eventos asıncronos se incorporan de forma natural en la estructura de laespecificacion, permitiendo el uso de senales POSIX[33] (muy importantes porsu gran implantacion), y manejando los eventos como si fueran hilos asıncronos.Ademas, para situaciones de tiempo crıtico, optimiza el lanzamiento de gestoresde eventos, usando para ello una subclase de la principal.


7

Robots con Patas

E n el presente capıtulo se va a realizar una breve introduccion sobre latematica de los robots con patas. Puesto que es un campo en el que sehan desarrollado infinidad de prototipos, no se pretende realizar una des-cripcion detallada de todos los robots desarrollados hasta el momento,

sino que, mas bien, dar a conocer las distintas modalidades de robots con patasque se han desarrollado hasta el momento, para ası poder tener mayor perspectivasobre este tema. Para mas informacion sobre los prototipos desarrollados, y comopunto de partida, se recomienda visitar elWalking Machine Catalogue[8].

7.1. Monopodos

P uede resultar extrano, pero sı, se han desarrollado algunos robots con unasola pata. Un ejemplo de estos prototipos es elARL Monopod II[12], desa-

rrollado en elAmbulatory Robotics Laboratory, Centre for Intelligent Machines,McGill University (figura 7.1). Este interesante ingenio es capaz de ir saltandosobre suunica pata, manteniendose en equilibrio dinamico sobre la misma.

64 E�ado del Arte

Figura 7.1: ARL Monopod II.

7.2. Bıpedos

L a problematica de los robots bıpedos esta, por una parte, en la dificultadpara conseguir queestos puedan girar a la vez que avanzan, y por otro lado,

conseguir que sean capaces de correr y saltar. Ejemplos de prototipos sonBARt-UH[7], BIP[9] y BiPed[29] (figura 7.2).

Posiblemente el mas conocido de los robots bıpedos es elHonda Human Robot,desarrollado por la companıa japonesaHONDA. El desarrollo por parte de estaempresa de robots bıpedos comenzo en 1986 conE0, y actualmente esta traba-jando enASIMO, posiblemente el robot bıpedo mas avanzado hasta el momento(figura 7.3).

Tampoco se puede dejar de lado a los primeros prototipos, como por ejemploel BLR-G2desarrollado por A. Sano y J. Furusho, en laGifu UniversitydeTokyo.

Por otra parte esta el proyecto abiertoPINO, que intenta ser el equivalente aLinux en el desarrollo de un bıpedo humanoide dediseno abierto(figura 7.4).

7.3. Cuadrupedos

E l robot de bajo coste AVRIL (Analogous Variable Robotic Insect Locomo-tion[47]), con solo dos motores, es un diseno sencillo y de muy bajo coste.

Dentro de los desarrollos nacionales, cabe destacar aSILO4, del IndustrialAutomation Institute (IAI), dependiente delCSIC. Este cuadrupedo de entorno a30kg, es capaz de adaptarse perfectamente a terrenos abruptos, y utiliza un sistema


Robots con Patas 65

(a) BARtUH (b) BIP (c) BiPed

Figura 7.2: Diferentes versiones de robots bıpedos.

de control sobre QNX, uno de los mas potentes sistemas operativos de tiempo real.

En la figura 7.5 se muestran ambos prototipos.

7.4. Hexapodos

U na mencion especial se merece el 3D-MV (3 Dimensional Moving Vehi-cle[6]), por ser una interesante aplicacion: es un robot con asiento, capaz

de subir y bajar escaleras, combinando sus seis patas con unas ruedas al final de


66 E�ado del Arte

(a) Evolucion

(b) (c)

Figura 7.3: Los robots bıpedos de HONDA son los mas conocidos por el granpublico.

cada una.

Uno de los mas antiguos hexapodos de gran tamano es elAdaptive Suspen-sion Vehicledesarrollado en elRobinson Lab, en laOhio State University, entrelos anos 1982-1990. Es un enorme hexapodo con cabina de piloto, con motor de


Robots con Patas 67

Figura 7.4: Primer plano del robot PINO.

(a) AVRIL (b) SILO4

Figura 7.5: Dos versiones de robots cuadrupedos.

gasolina y traccion hidraulica. Con una propulsion similar, pero mas moderno,


68 E�ado del Arte

esta elPlustech, desarrollado en Finlandia.

Otro prototipo, desarrollado en laCarnegie Mellon University, es elAmbler[55],a principios de los noventa.

Ejemplos de hexapodos de pequeno tamano sonAirbug[32], Ambassador[26]y Baby Beetle[41].

Especial mencion se merece elAmru Project[28], desarrollando en Rumanıadesde hace mas de 15 anos, habiendo desarrollado varios prototipos de robotshexapodos de diferentes tamanos.

Dentro de los robots acuaticos con patas, se han producido interesantes avancesen Japon, como por ejemploAQUAROBO 1[57], desarrollado por Kan Yoneda, enel Tokyo Institute of Technology.

Tambien se han desarrollado prototipos extremadamente pequenos, comoSti-quito[14], hexapodo que utiliza hilos denitinol para generar movimiento, que secontraen al aplicarles calor (corriente electrica), y se vuelven a alargar al enfriarse.

Algunas imagenes de estos hexapodos se muestran en la figura 7.6.

7.5. Octopodos

E l robot Dantees un interesante exponente de este tipo de robots con patas,desarrollado en laCarnegie Mellon University, que con sus 770kg de peso,

se utilizo para la exploracion de volcanes.

Tambien en la gama de grandes robots octopodos esta Doomsday Spider Ve-hicle, desarrollado en Suecia en 1999, con capacidad para transportar a variaspersonas.

7.6. Otras Configuraciones

P or ultimo, para que la panoramica sea completa, hay que mencionar otrosdisenos, menos usuales, pero tambien implementados. Uno de estos prototi-

pos es elPolypod[35], desarrollado y comercializado por la empresaLynxmotion,siendo capaz de desarrollar una estructura tipocienpies, por medio de modulosinterconectables de dos patas cada uno.


Robots con Patas 69

(a) AQUAROBO (b) Airbug (c) Baby Beetle

(d) Amru (e) 3D-MV

Figura 7.6: Diferentes robots hexapodos.

Otra configuracion al menos curiosa, es la que combina un eje de tracciontrasera con ruedas, con dos o mas patas delanteras. Este tipo de vehıculos hıbridospermiten cargar mayor peso, e imprimir algo mas de velocidad de avance que enel caso de robots con patas puros, pero su versatilidad en terrenos irregulares noes tan alta.


70 E�ado del Arte


Bloque II

Diseno Mecanico

8

Diseno Mecanico para NC

E n principio, y puesto que en elDepartamento de Ingenierıa de Sis-temas y Automatica hay una maquina de control numerico (EMCO PCMILL 125[36, 37]), y parece, en principio, factible la mecanizacion depequenas piezas, se plantea el diseno del robot pensando en su posterior

mecanizacion. Seguidamente se va a exponer el proceso seguido y los problemasencontrados en este primer planteamiento.

8.1. Requisitos del Sistema

Las especificaciones basicas del robot son las siguientes:

✵ Seis patas articuladas, tres a cada lado, para el desplazamiento del robot.

✵ Incorporar la capacidad de adaptarse a desniveles del terreno.

✵ En la parte delantera debera tener una garra, capaz de coger pequenos obje-tos.

✵ Ser capaz de detectar obstaculos insalvables, a causa de su altura.

✵ Soporte opcional para unawebcamcon capacidad de giro en el eje vertical.

74 Diseno Mecanico

8.2. Diseno Escogido

E l diseno se ha realizdo conSOLID EDGE V12[25]. En el CD adjunto se in-cluyen tanto los modelos 3D de todas las piezas, como su ensamblaje, ası co-

mo los planos. Ademas, en los anexos de este documento se han incorporado losplanos de todas las piezas.

8.2.1. Patas

Para producir movimiento, la solucion mas sencilla es el uso de servomotoresde aeromodelismo. Por ello, las dimensiones del robot se ven limitadas por losmismos, teniendo que usarlos siempre como referencia. Se han escogido los detipo FUTABA, puesto que son relativamente faciles de encontrar en tiendas deaeromodelismo especializadas. Este tipo de motores ademas incorporan otra ven-taja, y es que el posicionamiento se realiza mediante senales PWM (Pulse WidthModulation), por lo que la electronica asociada a la generacion de senales de con-trol se simplifica bastante.

Por otra parte, otro condicionante son los grados de libertad que se quiere dara cada pata, es decir, el numero de articulaciones que va a tener. Cada articulacionimplica holguras, ademas de incremento de peso, puesto que hace falta un ser-vomotor por cada articulacion. En principio, se puede plantear un modelo de 3servomotores, pero en este caso se ha reducido a 2, hacinedo uso de una estruc-tura que, quitando un grado de libertad, consigue que la pata siempre se apoye envertical. Esto implica varias ventajas:

✔ El algoritmo de generacion de trayectorias articulares no tiene que teneren cuenta como se apoya la pata, puesto que siempre lo hara en vertical,simplificando notablemente por ello su implementacion.

✔ El uso de sensores en el terminal1 para detectar si la pata esta apoyada o notambien se simplifica, al no darse casos en que el sensor no se active por elexceso de inclinacion de la pata.

✔ Se reduce el peso de la pata, puesto que solo se necesitan 2 servomotorespara su movilizacion.

✔ se reducen las holguras, puesto que el numero de uniones entre piezas esmenor.

1Estos sensores se anaden a las patas para que, por medio de esta realimentacion, el robot seacapaz de adaptarse a los desniveles del terreno, puesto queeste es otro requisito del sistema.


Diseno Mecanico para NC 75

La unica pieza no planar es la del hombro, que tiene una estructura capaz desujetar al servomotor con su eje de giro paralelo a la vertical. En la parte inferiorde esta pieza, ademas, se puede insertar un prolongador de eje, para dar mayorrobustez al sistema2.

Ademas, para dar soporte a un sensor, de tipo interruptor, en el terminal de lapata, se ha disenado una pieza para tal efecto. Este elemento, envuelve al interrup-tor, permitiendo ademas, su regulacion en altura, para poder calibrar la respuestade cada interruptor en contacto con el suelo por separado. El aspecto final de lapata serıa el mostrado en la figura 8.1.

Figura 8.1: Diseno de la pata para su mecanizacion en aluminio.

8.2.2. Tronco y Soportes Laterales

El tronco esta formado por dos planchas, una superior y otra inferior, unidaspor seis soportes verticales, fijados con tornillos y tuercas autoblocantes.

Tanto la parte superior como la inferior tienen agujeros pasantes equiespaci-ados, para darle mas versatilidad a la hora de anadirle elementos a la estructura,como para fijar la electronica al robot.

2Para una vista en detalle se remite al lector al apendice D.


76 Diseno Mecanico

8.2.3. Soporte para la Garra

Puesto que hay en el mercado garras para pequenos robots, accionadas pordos servomotores, con precios asequibles, se ha optado por adquirir una deestas,teniendo solo que disenar el soporte frontal para la misma. El aspecto de estesoporte, junto con el servomotor que mueve la muneca de la garra, ası como el dela garra en sı, se muestran en la figura 8.2.

(a) Garra (b) Soporte

Figura 8.2: Garra, y diseno del soporte frontal para la garra en aluminio.

8.2.4. Deteccion de Obstaculos: el Sonar

Una forma sencilla y barata de detectar obstaculos es montar un sonar sobre unservomotor, con el cual se puedan hacer barridos de180o. El modelo escogido esel SRF04, por su reducido tamano y peso, ademas de buen precio. El soporte y elsonar se muestran en la figura 8.3.

8.2.5. El Montaje Completo

Para unir todas las piezas, se utilizan tornillos y tuercas autoblocantes. El re-sultado final del diseno se muestra en la figura 8.4.



(a) Sonar (b) Soporte

Figura 8.3: Sonar SRF04, y diseno del soporte movil para el sonar en aluminio.

Figura 8.4: Montaje completo para su mecanizacion en aluminio.

8.3. Mecanizacion

U na vez realizado el diseno 3D de las piezas, hay que pasar a la imple-mentacion fısica de las mismas. En principio, las piezas planas se deberan

recortar, con las fresas, directamente de laminas de aluminio de grosor adecuado.Las que no son planas, habra que extraerlas de tacos mas gruesos, posiblementeretales que se puedan conseguir a buen precio.

El orden en que se realicen las operaciones puede resultar crıtico en algunoscasos, puesto que la sujecion de elementos puede resultar complicada, y el tenerque parar la maquina y recolocar la pieza puede introducir errores, a parte detenerse tambien que mecanizar mas piezas (agarres), simplemente para fijar la


78 Diseno Mecanico

que realmente se quiere conseguir.

Una buena idea, para las piezas planas, es realizar primero los agujeros pasan-tes, y luego recortar los bordes, con varias pasadas, a diferente profundidad, con lafresa. Un detalle muy importante, para que no salte la pieza al terminar el borde,es el uso de orejeras, es decir, a lo largo del borde, se tienen dos zonas en las que lafresa se hace subir respecto de la altura a la que se esta ejecutando la trayectoria,para que no recorte del todo el borde, y una vez terminado, se dobla y repasa conla lima. Ası se tiene la plancha sujeta en todo momento.

En el caso de piezas no planas, se hace necesario realizar el perfil, y despuesreubicar la pieza para realizar algunos agujeros. Esto complica el proceso, perono hay otra forma de hacerlo, al tener solo tres grados de libertad laEMCO PCMILL 125[37].

8.3.1. Programacion del NC

Antes de mecanizar, hay que programar la maquina de control numerico paraque procese la pieza. Esto se puede hacer de diversas formas:

✵ Utilizando algun lenguaje especıfico que entienda el controlador de la ma-quina en cuestion.

✵ Programando en el lenguaje que se conoce comoISO3, siendo realmenteuna especificacion de la ISO (International Standard Organization).

✵ Utilizar un postprocesadoren un sistemaCAM, que genere el codigo enISO.

✵ Ensenar a la maquina, con un sistema de aprendizaje, con el cual, un opera-rio experto, ejecuta el proceso a seguir por la misma una vez, y en ocasionessucesivasesta repite la secuencia de forma automatica.

Utilizar el lenguaje especıfico del controlador no tiene sentido, puesto que esmasutil aprenderISO. Por otra parte, programar unpostprocesadorpara CATIApor ejemplo, para laEMCO PC MILL 125 no tiene sentido para el reducidouso que se le va a dar. Porultimo, la EMCO PC MILL 125del laboratorio noesta preparada,a priori, para un sistema de aprendizaje, y ademas, no se disponede ningun operario experto dispuesto a realizar el trabajo. Por estos motivos, laopcion, por exclusion, es la programacion enISO.

3Norma ISO 6983.



8.3.1.1. Programacion en ISO y Simulacion con WinUnisoft

La programacion enISOes sencilla. Se van numerando las lıneas, y en cada unase pone una instruccion (funcionesG o M, o ciclosL), y un comentario opcional.En el apendice A se ha incluido un programa enISO para mecanizar la piezahombro-codo superior, como ejemplo practico de codigo.Este se ha ejecutado enla EMCO PC MILL 125.

Pero antes de pasar a la mecanizacion, se utilizo un simulador comercial, elWINUNISOFT[56]. Con el mismo, se genera el codigo para fresadoras especıficasdeFAGOR, que soportan un subjuego de instruccionesISO. Despues de comprobarque la simulacion en pantalla genera correctamente la pieza, se adapta el codigoal subjuego de instruccionesISOque soporta laEMCO PC MILL 125[36], y sepasa a ejecutar sobre el NC, no sin antes calibrar las herramientas, y cambiandoel numero de herramienta en las instrucciones de cambio de las mismas, para quese utilicen las que preivamente se hayan montado sobre elrevolver.

8.3.2. Problemas con la Mecanizacion

Una vez que se tenıa el codigo enISO para mecanizar las piezas, se paso ala fase de fabricacion. Primero se hicieron pruebas con tacos deteflon de aproxi-madamente 2cm de grosor, consiguiendo, tras adaptar el codigo al subjuego deinstrucciones de laEMCO PC MILL 125, realizar los pasantes y sacar el perfildeseado de varias piezas de las patas. Hasta aquı todo marchaba bien.

Pero al intentar realizar el mismo proceso con una pequena plancha de alu-minio surgieron varios problemas:

✘ Por una parte, la sujecion se hacıa difıcil, puesto que era necesaria una per-fecta horizontalidad, pero no se podıa colocar directamente sobre la base dela agarradera, puesto que las herramientas podrıan desgastarla, por lo quese intento de diversas formas colocarla sobre piezas que la elevaran, conescasoexito.

✘ Ademas, al recortar el perfil, se debilitaba tanto la plancha, que cuando lle-vaba la mitad del mismo, se doblaba a causa de la fuerza del agarre hidrauli-co. Ası se desperdiciaron varias piezas.

✘ Las fresas de las que se disponıa en el laboratorio se sobrecalentaban, yperdıan el perfil de corte adecuado. Se inteto refrigerarlas con agua, y seestuvo a punto de probar contaladrina, pero no sirvio de mucho. Lo querealmente hacıa falta eran fresas para aluminio, que habrıa que comprar.


80 Diseno Mecanico

✘ Las piezas mas grandes habrıa que hacerlas por partes, por lo que habrıaque disenar ademas los agarres, y fabricarlos, aumentando enormemente ladificultad.

Ante tanta adversidad, y tras numerosos intentos fallidos, se penso en otra op-cion: la mecanizacion por encargo. Se dedico tiempo y esfuerzo en contactar condiversas empresas del sector pero, como actualmente les sobra carga de trabajo, nose planteaban la posibilidad de colaborar. Solo hubo una empresa que se digno en,al menos plantearse la posibilidad de realizar las piezas:MEINSUR DT. El jefede ingenierıa de dicha empresa, Rafael Henares del Real, recibio tanto los planoscomo los modelos 3D en formatoIGES. En principio no planteo ningun inconve-niente pero, una semana mas tarde envio el presupuesto, que ascendıa a 5240e,entre programacion, mecanizado, utillaje y material. Llegado a este punto se deci-dio volver a las especificaciones de diseno, para plantear una nueva solucion, sinnecesidad de hacer uso de NC para la implementacion del prototipo.


9

Diseno Mecanico para PVC

T ras la aventura con la mecanizacion, y viendo que las dificultades quepresenta no van a compensar el aumento en precision de las piezas, niel uso de geometrıas no planas, se vuelve al punto de partida del disenoreplanteando la resolucion del problema. Seguidamente se expondra la

solucion final aportada, ası como el proceso de fabricacion y montaje de la estruc-tura mecanica.

9.1. Requisitos del Sistema

Las especificaciones basicas del robot siguen siendo las mismas:

✵ Seis patas articuladas, tres a cada lado, para el desplazamiento del robot.

✵ Incorporar la capacidad de adaptarse a desniveles del terreno.

✵ En la parte delantera debera tener una garra, capaz de coger pequenos obje-tos.

✵ Ser capaz de detectar obstaculos insalvables, a causa de su altura.

✵ Soporte opcional para unawebcamcon capacidad de giro en el eje vertical.

82 Diseno Mecanico

9.2. Diseno Escogido

E l diseno se ha realizado conSOLID EDGE V12[25]. En el CD adjunto seincluyen tanto los modelos 3D de todas las piezas, como su ensamblaje,

ası como los planos. Ademas, en los anexos de este documento se han incorporadolos planos de todas las piezas.

El nuevo plantenamiento, va a basarse en el desarrollo de un conjunto de piezasde PVC, concretamente a partir de laminas de 3mm, mas facilmente trabajablescon herramientas manuales que el aluminio, y buscando soluciones prefabricadaspara las partes conflictivas, como puede ser la fijacion del hombro, la garra, o elsoporte para el sonar. Esta decision se ha tomado en base a la experiencia adquiri-da a lo largo del primer diseno, como se habra podido comprobar en el capıtuloanterior.

9.2.1. Patas

El diseno es similar al planteado para el modelo de aluminio, pero utilizandopara el hombro unas escuadras de aluminio para fijacion de servomotores, ası co-mo una pieza plana para sujetar el sensor del terminal de la pata (pero sigue siendoregulable en altura).

El resultado de estas modificaciones se muestra en la figura 9.1.

Figura 9.1: Diseno de la pata para su fabricacion en PVC.

9.2.2. Tronco y Soportes Verticales

Para cohexionar la estructura, y buscando la simplicidad y la reduccion de pesoal maximo, se ha desarrollado un sistema para unir las dos planchas (superiore inferior) a los soportes verticales, sin necesidad de hacer uso de tornillos. El


Diseno Mecanico para PVC 83

sistema se basa en un conjunto de pequenas cunas, en total 21, que se encajan apresion en las ranuras correspondientes, dando a la vez solidez y resistencia a laestructura, sin necesidad de utilizar elementos adicionales.

Los soportes laterales y trasero se muestran en la figura 9.2.

(a) Lateral (b) Trasero

Figura 9.2: Soportes laterales y trasero, con sus respectivas cunas de fijacion a laestructura. Como se puede comprobar, todas las piezas estan hechas a partir deplanchas planas.

9.2.3. Soporte para la Garra

Como en el primer diseno, se ha optado por adquirir una garra comercial, te-niendo solo que disenar el soporte frontal para la misma. De nuevo se hace usodel sistema de cunas para fijar el soporte al tronco. El aspecto de este soporte,ası como el de la garra en sı, se muestran en la figura 9.3.

9.2.4. Deteccion de Obstaculos: el Sonar

Se mantiene el uso del sonar SRF04, pero ademas se anade el soporte comercial


84 Diseno Mecanico

(a) Garra (b)Soporte

Figura 9.3: Garra, y diseno del soporte frontal para la garra en PVC.

de aluminio, que se muestra en la figura 9.4.

(a) Sonar (b) Soporte

Figura 9.4: Sonar SRF04 y soporte comercial de aluminio.

9.2.5. El Montaje Completo

Para unir todas las piezas, en el tronco se usan las cunas, y para las patas y losservomotores se utilizan tornillos y tuercas autoblocantes, y tornillos para madera.El resultado final del diseno se muestra en la figura 9.5.



Figura 9.5: Montaje completo del segundo diseno (PVC).

9.3. Proceso de Fabricacion

E l planteamieto en este caso es completamente artesanal, y las herramientasque se van a utilizar son relativamente sencillas de encontrar. El tiempo que

se invierta en esta parte es esencial, puesto que el esmero y el empeno puesto enesta parte condicionara fuertemente el buen funcinamiento del robot. El tiempoempleado ademas puede resultar bastante largo, puesto que el avance en la fabri-cacion, si es precision lo que se busca, es realmente lento.

Antes de poder fabricar las piezas se hicieron varias pruebas, llegando a montaruna pata completa, sin que despues se haya utilizado. Esto es necesario si se quiereobtener un resultado final aceptable.

El proceso se puede dividir en 6 partes:

1. Preparacion de las plantillas.

2. Pegado de las plantillas sobre el PVC.

3. Recorte de perfiles.

4. Repaso de bordes.

5. Taladrado.

6. Limpieza de superficies y verificacion.


86 Diseno Mecanico

Seguidamente se van a comentar cada uno de estos puntos, resaltando los pro-blemas que pueden surgir, y la forma correcta en que se deben ejecutar.

9.3.1. Preparacion de las Plantillas

Para poder recortar y taladrar con facilidad las diferentes piezas, se han rea-lizado, a partir de los modelos 3D de las piezas, unas plantillas de fabricacion.Estas plantillas se encuentran en el CD adjunto, junto con los planos del modeloen PVC. En la figura 9.6 se muestran las mismas.

(a) (b)

(c) (d)

Figura 9.6: Plantillas de fabricacion para facilitar la realizacion de las piezas enPVC.

Estas se deben imprimir sobre papel adhesivo, preferentemente de superficieplastificada, para que sean mas faciles de despegar.



9.3.2. Pegado de las Plantillas sobre el PVC

Una vez preparadas las plantillas, se limpian las superficies de PVC con unpano humedo, para eliminar polvo y suciedad. Una vez que las superficies estansecas, se pegan las plantillas sobre las mismas, cuidando que no se formen burbu-jas.

Hasta aquı, el proceso es sencillo, y no tiene perdida, pero a partir de ahoracomienza el trabajo de precision.

9.3.3. Recorte de Perfiles

Para el recorte de perfices, lo ideal serıa el uso de una sierra fija de vaiven.Como este no era el caso, se ha utilizado una segueta, con pelos planos.

Para comenzar el corte, se debe fijar la plancha de PVC a la mesa de trabajo,preferiblemente con, al menos, un gato de carpintero, teniendo en cuenta que lamesa debera estar limpia, para no aranar la plancha. Ademas, entre el gato y laplancha se debera colocar otra plancha, ya sea tambien de PVC, o de otro material,como panel, para que al apretar el gato no se marque la plancha a recortar.

Siempre se debera colocar el borde de corte lo mas cerca posible tanto de lafijacion del gato, como del borde de la mesa, para evitar vibraciones. Al recortarcon la segueta se debera hacer de forma lenta, y siempre por la parte exterior dela trayectoria, puesto que despues, el sobrante se puede lijar o limar, pero lo quefalte no se podra anadir.

Si se tienen que recortar bordes interiores, como por ejemplo en la planchasuperior, o los laterales, se debera realizar un taladro primero, soltar el pelo desegueta por uno de los extremos, introducirlo en el agujero, y volverlo a fijar a laherramienta, para ası recortarlo. El orden en que se recorten este tipo de elementoses importante, puesto que se va debilitando la pieza, y hay que tener en cuenta latraccion que sera capaz de soportar la misma al proseguir con el siguiente corte.

9.3.4. Repaso de Bordes

Una vez recortados los perfiles, se deberan repasar, primero las partes rectas ylargas con papel de lija. Para ello, lo mas sencillo es utilizar un taco de corcho omadera, de superficie lisa, sobre el que se coloca la lija1. Ası se podra conseguir

1Primero se debera usar lija de grano grueso, si hay mucho que rebajar, y acabar con otra lija,de grano fino.


88 Diseno Mecanico

un borde recto, aunque el corte inicial tuviera curvas.

Una vez repasados los bordes rectos, se pasan a trabajar las curvas y transi-ciones de una recta a otra. Dependiendo de la situacion, puede serutil la lija degrano fino con el taco, o unas pequenas limas de las que se utilizan para rematarcolgantes y cadenas.

Para evitar repasos posteriores, se recomienda revisar las medidas de las piezas,especialmente en los puntos en que deban encajar con otras, como por ejemplo,huecos para servomotores, o ranuras de fijacion. Pero atencion, las cunas se de-beran dejar mas anchas de la cuenta, sin que encajen en sus ranuras, puesto que esmejor ajustarlas una a una, en el momento del montaje.

9.3.5. Taladrado

Una vez las piezas tienen sus bordes terminados, se pasa a taladrar. Lo ideales utilizar un taladro sobre soporte vertical fijo, con brocas para madera. En estecaso, sı se tenıan brocas para madera, pero no taladro fijo, por lo que hubo que serespecialmente cuidadoso en este proceso2.

Es muy importante que los agujeros se hagan exactamente en su sitio, puestoque, en la patas sirven muchos de ejes, por lo que un error no darıa la movilidadcorrecta a la pata en cuestion, y otros no permitirıan fijar en su sitio correspon-diente a los servomotores.

Si no se dispone de taladro fijo, lo que se fija es la pieza, con los gatos decarpintero, sobre una tabla, y se marcan los agujeros con un punzon, para que lasbrocas no se desvıen con el primer contacto. Para perforar se sujeta firmementeel taladro, y se pasa a realizar los pasantes con una velocidad de giro lenta. Lapresion que se realice sobre el PVC al taladrar no debe ser ni muy alta, puesto queestropea el borde de taladrado, ni demasiado baja, puesto que el PVC se funde confacilidad si se mantiene la friccion por un tiempo demasiado prolongado.

Una vez realizados los agujeros, se repasan las rebabas con una cuchilla y unalima circular de grosor adecuado.

9.3.6. Limpieza de Superficies y Verificacion

Una vez recortadas y taladradas las piezas, se pasa a retirar las pegatinas quetienen aun adheridas. Las de superficie plastica son las mas sencillas de quitar,

2Sobre las plantillas se marcan los diametros de cada agujero, pero ante la duda, se recomiendaconsultar los planos.



tirando con cuidado desde los bordes de corte y, ayudando, cuando sea necesario,con una cuchilla. Es aconsejable hacerlo despacio, puesto que los restos que sequeden pegados en medio de las piezas pueden ser difıciles de eliminar.

Si aun ası quedan restos, se limpia la superficie con un pano y aceite de cocina(de oliva por ejemplo), eliminandose los restos de pegamento que pudieran quedar.Se desaconseja el uso de quitaesmalte, puesto que puede danar el color del PVC.

Una vez acabado este proceso, hay que verificar que las piezas son del tamanoadecuado, que los servomotores encajan en sus posiciones, que los sensores sepueden fijar correctamente, y que los agujeros que deberan servir de ejes tienenla holgura suficiente (si no lo tienen la solucion es sencilla), ası como que los quedeben fijar los tornillos no sean mayores queestos (si no es ası la unica soluciones repetir la pieza).

9.4. Montaje

P ara montar el robot, se supone que ya se tiene la electronica preparada, puestoque para centrar los servomotres en su posicion neutral, es necesario conec-

tarlos al sistema de control, para posicionarlos.

A parte de las piezas de PVC, son necesarios los siguientes materiales:

1. Tornillos M2.5x10 (84 unidades).

2. Tuercas autoblocantes M2.5 (84 unidades).

3. Tornillos M3x10 (12 unidades).

4. Tornillos M3x25 (6 unidades).

5. Tuercas autoblocantes M3 (18 unidades).

6. Tornillos M1.8 para servomotores (39 unidades).

7. Prisioneros de 3mm(6 unidades).

8. Sonar SRF04 (1 unidad).

9. MinigarraLynxmotion Little Grip(1 unidad).

10. Servomotores FUTABA3003 (16 unidades).

11. Aspa de servomotor FUTM2010 (12 unidades).


90 Diseno Mecanico

12. Aspa de servomotor FUTM2000 (1 unidad).

13. Interruptor D2F-L2 (6 unidades).

14. Escuadras de aluminio para servomotores (6 unidades).

15. Prolongadores de eje para servomotores (6 unidades).

16. Burlete para la parte inferior de puertas de 2mm de grosor, para hacer unasprotecciones a los terminales de las patas.

9.4.1. Montaje de las Patas

Las patas son simetricas, por lo que habra que montarlas tres a tres.

Antes de empezar, hay que preparar la piezahombro-codo superior3. Para ello,se toman 3 tornillos M1.8, y se recortan con una radial, para que la parte roscadamida4,5mm. Seguidamente, se fija un aspa FUTM2012 alhombro-codo superiorcon los tornillos, se recortan las rebabas con una cuchilla, y se repasa con pega-mento de secado rapido (figura 9.8).

Por otro lado, hay que preparar lafijacion del sensor. Para ello, se recortan, otravez con la radial, 2 tornillos M1.8, hasta que la parte roscada mida 8mm. Despuesse fija un interruptor D2F-L2 con dichos tornillos, cuidando que no sobresalganlos tornillos por el lado opuesto (figura 9.9).

Figura 9.7: Detalle del hombro montado.

3Los nombres de piezas, escritos en cursiva, se refieren a la nomenclatura utilizada en losplanos, que se encuentran en los anexos.



Figura 9.8: Detalle del codo montado.

Figura 9.9: Detalle del sensor montado.

Tras esto, lo primero es fijar una escuadra de aluminio a la pieza delhombro.Para ello se necesitan 2 tornillos M2.5x10 y sus correspondinetes tuercas autoblo-cantes. Se aprietan bien los tornillos (figura 9.7).

Seguidamente, con un destornillador en estrella, se liberan las aspas de los 2servomotores que se van a utilizar. Para fijarlos, se utilizan 8 tornillos M2.5x10,sus tuercas antiblocantes, las protecciones de goma entre el servomotor y la su-perficie de contacto, y los cilindros de relleno (prisioneros). El servomotor que vaa accionar el hombro se fija a la escuadra (introduciendolo desde arriba, con el ejehacia el exterior del cuerpo). El que va a accionar el codo se fija albrazo(desde


92 Diseno Mecanico

Figura 9.10: Pata montada.

atras, con el eje del servomotor en la parte baja).

Ahora se pasa a fijar la piezahombro-codo inferior, por medio de 1 tornilloM3x10 y 1 tornillo M3x25 y sus tornillos antiblocantes, y un prisionero en el tor-nillo del brazo4 de 3mm, al brazoy al hombro. Se debera ajustar de tal forma quela holgura sea mınima, pero permitiendo un movimiento suave de la ariticulacion.

Hecho esto, se fija elhombroal hombro-codo superior, de nuevo con un tor-nillo M3x10 y su tuerca antiblocante. Debe permitir el movimiento suave de laarticulacion.

Ahora, se conecta el servomotor del brazo a la circuiterıa de control, posi-cionandolo en 128 (posicion neutral), y se fija, con la pata a media altura, al aspadelhombro-codo superior, y se le coloca el tornillo al eje.

Para proteger del desgaste la parte de la pata que se apoya, se recorta un trozode burlete, y se pega al final delbrazo, formando una cubierta protectora.

Una vez hecho esto, se fija, con 2 tornillos M2.5x10 y sus tuercas, lafijaciondel sensoral brazo.

El mismo proceso se realiza con las 5 patas restantes. El resultado final semuestra en la figura 9.10.

9.4.2. Montaje del Cuerpo

Llegado a este punto, se presupone que ya se tienen las seis patas montadas.Primero, se debera comprobar que lacarcasa superior, la carcasa inferior, los

4Si es demasiado ancho, debera rebajarse con una piedra de afilador. En el montaje realizadoesto fue necesario.



soportes laterales, el soporte para la garray el refuerzo traseroencajan. Se re-comienda, tras los ajustes, marcar las piezas, para saber que pestana se va a encajaren cada ranura, para aumentar la precision en el ensamblaje.

Una vez hecho esto, se toman 18 tornillos M1.8, y se recortan con una radial,para que la parte roscada mida4,5mm. Seguidamente, se fijan 6 aspas FUTM2012a lacarcasa superiorcon los tornillos, se recortan las rebabas con una cuchilla, yse repasa con pegamento de secado rapido.

Se pasan a fijar, seguidamente, los servomotores que serviran de soporte tantoal sonar como a lawebcam(opcional). Se insertan desde arriba, en el caso delsonar con el eje en la parte delantera, con la misma tecnica descrita para las patas.

Al soporte para la garrase fija otro servomotor, y se monta sobre el mismo lagarra, fijandola con el tornillo (figura 9.11). De nuevo, sera necesario hacer estocon el servomotor conectado al sistema de control, para centrarlo en una posicionneutral5.

Ahora se pasa a fijar las patas por el hombro. De nuevo sera necesario ponerlas,por medio del sistema de control, en una posicion neutral, para fijarlas a lacarcasasuperior. Esto se realiza con la carcasa apoyada boca arriba, fijando, una a una,cada pata. Este proceso y los siguientes, hasta conseguir el ensamblaje del cuerpo,son muy delicados, puesto que el peso de las patas puede combar hasta la roturalas piezas de PVC.

Una vez hecho esto, se insertan lossoportes laterales(figura 9.12), elsoportepara la garra(figura 9.11) y elrefuerzo trasero(figura 9.13). Tras ello, se colocala carcasa inferior.

Ahora, para que la estructura quede totalmente ensamblada, se van ajustandolas cunasuna a una, con limas de precision, y se van encajando en las ranurascorrespondientes.

Porultimo, se le da la vuelta y se pone de pie al robot6, se colocan los tornillosque fijan las aspas de los servomotores de los hombros, y se comprueba que todoslos elementos estan correctamente colocados y sujetos. Ademas, es recomendableregular, con el robot en pie, los sensores de las patas, para que se activen justo enel grado de apoyo deseado.

Ademas habra que montar el sonar sobre su soporte, pero como trae un pequenomanual incorporado, se obvia su mantaje aquı.

El resultado final obtenido se muestra en la figura 9.15.

5El montaje de la garra en sı no se explica aquı, puesto que trae sus propias instrucciones demontaje incorporadas.

6Lo mejor es apoyar el tronco sobre algun soporte, para que las patas no soporten el peso hastaque este totalmente montado.


94 Diseno Mecanico

Figura 9.11: Detalle de la garra montada.

Figura 9.12: Detalle del lateral, montado con las cunas.



Figura 9.13: Detalle de la parte trasera del robot.

Figura 9.14: Detalle del frontal del robot.


96 Diseno Mecanico

Figura 9.15: Robot montado.


Bloque III

Electronica y Software de Bajo Nivel

10

Electronica

U na vez desarrollada la estructura mecanica del robot, llega el momentode implementar la primera capa inmediatamente superior: la etapa decontrol directo de los dispositivos de los que consta el mismo. Para ello,se ha desarrollado una placa de circuito impreso, basada en el micro-

controlador ATMEL AT90S8515. En el presente capıtulo se presenta el procesode diseno y fabricacion de la misma.

10.1. Requisitos del sistema

D e nuevo, el punto de partida son los requisitos del sistema. En principio, haydos tipos de requisitos: requisitos temporales y numero de pines utilizables

(a parte de las dimensiones y peso de la placa).

Dentro de los requisitos temporales se tiene, por una parte, la temporizacion delos servomotores, que se controlan por medio de senales PWM:

✵ Con ciclo superior a 50Hz (Tmax= 20000µs).

✵ Tiempo mınimo a nivel altoτmin = 900µs.

✵ Tiempo maximo a nivel altoτmax= 1500µs.

A continuacion se presenta de forma grafica la senal (figura 10.1):

100 Electronica y Software de Bajo Nivel

��

��

��

��

��

��

��

��

(µs)20000 20900 224000 900 2400

5

0

(V)

Figura 10.1: Temporizacion de los servomotores.

Por otro lado, esta la temporizacion del sonar:

✵ Pulso de activacion a nivel alto, con duracion mınima (τmin > 10 µs).

✵ Tiempo entre activacion y comienzo del nivel alto de la salida de eco, enprincipio, indeterminado por el cronograma de las especificaciones tecnicasdel mismo (tespera=?).

✵ Duracion mınima de la senal de ecoτeco|min = 100µs.

✵ Duracion maxima (con deteccion) de la senal de ecoτeco|max1= 18000µs.

✵ Duracion maxima (sin deteccion) de la senal de ecoτeco|max2= 36000µs.

✵ Tiempo de recuperacion del sonar, antes de poder volver a comenzar unnuevo ciclo de medicionTdescanso= 10000µs.

Respecto al numero de pines utilizables, son necesarios los siguientes:

✵ 12 pines de salida para controlar los servomotores de las patas.

✵ 6 pines de entrada para detectar el estado de contacto o no de cada una delas patas con el suelo.

✵ 1 pin de salida para controlar el servomotor de barrido del sonar.

✵ 1 pin de salida para generar la senal de control del sonar.

✵ 1 pin de entrada para detectar la senal de eco del sonar.

✵ 1 pin de salida para controlar el servomotor de barrido de la camara.

✵ 2 pines de salida para controlar los servomotores de la garra.


Electronica 101

8 ciclos de ráfagaultrasónica a 40kHz

10ms mínimopara generarla siguienteráfaga

10µs mínimo 10µs mínimo

sonarInit

sonarEco de 100µs a 18ms

Figura 10.2: Temporizacion del sonar.

Ademas, la tarjeta debera comunicarse por puerto serie con la entidad de con-trol de nivel superior.

Por otra parte, es necesaria una etapa de alimentacion (distribucion de poten-cia) para los servomotores.



10.2. Diseno escogido

C on las especificaciones anteriores, queda claro que hace falta un microcon-trolador capaz de trabajar ejecutando varias instrucciones porµs. Ademas,

necesita al menos 24 pines de proposito general, a parte de capacidad para mane-jar un puerto serie. Por ello se ha escogido el AT90S8515[16], porque aparte desu bajo coste (actualmente 5e), tiene 4 puertos de proposito general, con 8 pinescada uno, capacidad para manejar el puerto serie, y arquitecturaHarvard, que a8 MHz ejecuta 8 MIPS, con un ciclo de0,125µs.

10.2.1. Principales Elementos del Sistema

10.2.1.1. AT90S8515

El encapsulado es de 40 pines, y la distribucion se ha realizado como sigue:

1. Puerto A:

✵ Pines 0 a 5: senales PWM de los 6 servos de las patas del lado izquier-do.

✵ Pines 6 y 7: denominadosAuxiliar 2, son dos salidas adicionales parasenales PWM.

2. Puerto B:

✵ Pines 0 y 1: denominadosAuxiliar 1, el pin 0 se conecta a la entradadel sonar SRF04, y el pin 1 se conecta a la salida, para detectar elancho de pulso.

✵ Pines 2 a 7: entradas para detectar si cada una de las patas estan encontacto con el suelo o no.

3. Puerto C:

✵ Pines 0 a 5: senales PWM de los 6 servos de las patas del lado derecho.

✵ Pines 6 y 7: denominadosAuxiliar 3, son dos salidas adicionales parasenales PWM.

4. Puerto D:

✵ Pines 0 y 1: lıneas para el puerto serie.


Electronica 103

5. XTAL1 y XTAL2: cuarzo a8 MHz.

6. RESET: pulsador de RESET.

El resto de pines (exceptuando alimentacion), van a tierra.

El esquematico del montaje utilizado se muestra en la figura 10.3.

+

++

8MHz

22pF 22pF

5 V 100nF

Servo Izq 1Servo Izq 2Servo Izq 3Servo Izq 4Servo Izq 5Servo Izq 6Aux2 (1)Aux2 (2)

Servo Der 1Servo Der 2Servo Der 3Servo Der 4Servo Der 5Servo Der 6

Aux3 (2)Aux3 (1)

Aux1 (1)Aux1 (2)Pata 1

Pata 4Pata 5

Pata 2Pata 3

Pata 6RESETRxDTxD

− +A

T90

S85

15

Figura 10.3: Esquematico del AT90S8515.



10.2.1.2. MAX232

Como toda la electronica trabaja a0−5V, hay que adaptar la salida del puertoserie a las tensiones que especifica el estandar RS232 (actualmente EIA232). Paraello se ha hecho uso del integrado MAX232[38] deMaxim. Lo unico que haceeste integrado es adaptar las tensiones de las lıneas de recepcion y transmision,por medio de sendos amplificadores, pero no involucra a las demas lıneas delestandar EIA232, por lo que no se puede hacer uso de ellas. Por ello, a la hora deprogramar desde el lado del servidor, hay que reconfigurar la UART para que nohaga uso de las lıneas de control.


5 V

R1OUT (uC)R1IN (DB9)T1OUT (DB9)

T1IN (uC)

C

C

C

C

+

+

+

+ C=1uF

−

+

MA

X23

2

Figura 10.4: Esquematico del MAX232.

10.2.1.3. LM7805

Los circuitos integrados son muy sensibles a las variaciones en la tension dealimentacion, pudiendo incluso inutilizarlos una sobretension, a parte de intro-ducir anomalıas en su comportamiento si hay un excesivo rizado sobre la misma.Para evitar estos problemas se ha hecho uso del regulador LM7805[50] que, apartir de una tension de entrada superior a5 V proporciona una salida estable a5V. Ası con, por ejemplo, una fuente de alimentacion a9V, se puede alimentarla placa con seguridad.



Electronica 105

LM7805

100uF++

330nF

in out

Figura 10.5: Esquematico del LM7805.

10.2.1.4. SRF04

Para que el robot pueda interactuar con el entorno de forma segura, se le haequipado con un sonar para medir distancias: el SRF04[44]. Dicho sonar midedistancias de3 cma3 m, con un esquema de funcionamiento muy sencillo:

1. Se aplica un pulsoτmin > 10 µs a la lınea de control del sonar.

2. Seguidamente,este genera una senal de ultrasonidos a40kHz, de 8 ciclos.

3. En ese momento pone a nivel 1 su salida, que no pondra a 0 hasta que detecteel pulso de vuelta, o considere que no hay nada que detectar (τeco|max2

=36000µs).

A partir del tiempo que este activa la senal de salida se obtiene de forma sen-cilla la distancia a la que esta el objeto detectado:

d(teco) = K teco

siendoK la constante de proporcionalidad dependiente de la velocidad del sonidoen el aire:

K =vsonido

2El esquematico del montaje utilizado se muestra en la figura 10.6.

10.2.1.5. Alimentacion de Potencia y Conectores

Se han anadido 20 conectores para alimentar a los servomotores, con 4 capaci-dades de1mF, para eliminar rizados y aliviar los problemas de picos de consumo.Comparten la toma de tierra con la electronica, pero la alimentacion esta separaday apantallada.

Por otra parte, las conexiones para las lıneas de control y supervision (de ser-vomotores y sonar), se han agrupado de forma logica, espacialmente, para queinterfieran lo menos posible unas con otras, y sean de facil conexionado.



sonarInit

sonarEco

5 V

��

��

−

+

Figura 10.6: Esquematico del SRF04.

Ademas, las entradas para deteccion del estado de las patas tienen, cada una,un diodo en serie con una resistencia, que han sido distribuidos sobre la placapara que, de una visual, se sepa cuales son las patas que detecta como apoyadas ycuales no. Esto es muyutil a la hora de depurar los programas que se ejecutan enlas capas superiroes del sistema.

Y por ultimo, se han anadido 7 conectores auxiliares para alimentar dispositi-vos electronicos, por si se quiere realizar una ampliacion posterior.


Electronica 107

10.3. Implementacion

A continuacion se presentan los pasos seguidos para obtener como resultadofinal la placa de circuito impreso que incorpora el robot.Estos son dependi-

entes de los medios disponibles para la fabricacion, pero aun ası se pueden utilizarcomo guıa para la fabricacion de placas ulteriores.

10.3.1. Rutado de la Placa

Para el diseno de la disposicion fısica de los elementos de la placa se ha uti-lizado el programaPCB[39] para Linux.

Figura 10.7: Ventana del programa PCB.

Lo primero que hay que hacer es cambiar los grosores de lıneas y puntos. Paraello en el menu Sizes, adjust active sizes. . . , se aumentan los parametros de:

✵ linewidth

✵ via hole

✵ via size

Ademas, se reajusta el tamano de la placa, desde el mismo menu:

✵ PCB width

✵ PCB height



Una vez hecho esto, de la librerıa de componentes, se van escogiendo y colo-cando sobre la placa los diferentes elementos que la compondran. Seguidamente,se van colocando pistas. La mejor forma de hacerlo es por capas. En este caso sehan utilizado tres:

✵ GND

✵ power

✵ signal1

Esta es una forma muy comoda de trabajar, puesto que da mayor orden al es-quematico. Ademas de estas tres capas, se ha utilizado una cuarta,silk, que essobre la cual estan los sımbolos de los componentes, ası como datos aclarato-rios, como valores de capacidades, numeracion de conectores, nombres de com-ponentes. . .

Una vez el diseno esta terminado se puede exportar directamente para ser im-preso. Para ello se hace a traves del menu File, print layout, dejandoPostScriptcomo fichero de salida, con las opciones por defecto. Esto generara un fichero porcapa. Pero puede que sea mas comodo tener las tres capas (GND, power y sig-nal1) en ununico ficheroPostScript. Entonces, la forma mas sencilla es editar elfichero PCB dellayout, con por ejemploEmacs, puesto que es un fichero de texto,con un formato similar al de unscript. Se copia el contenido de las tres capas albloque perteneciente a otra, y se guardan los cambios. Una vez hecho esto se abrecon elPCB, y se exporta comoPostScript. El resultado obtenido se muestra en lafigura 10.8.

10.3.2. Proceso de Fabricacion

Una vez realizado el rutado con el programa PCB, se imprime con una impre-sora laser sobre papel vegetal1.

10.3.2.1. Insolacion, Revelado yAcido

Acto seguido, con la insoladora del Laboratorio, se expone a una placa foto-sensible, previamente cortada a la medida, con el rutado sobre la misma, con eltiempo indicado en las instrucciones que la acompanan2 (2,5min). Este paso esimportante realizarlo a oscuras, porque si no la placa se vela.

1Se hizo sin inversion de color ni simetrıa en espejo, puesto que se coloca directamente el ladoimpreso contra la cara fotosensible.

2La insoladora utilizada tiene un temporizador programable con un display, con paso dedecimas de minuto.


Electronica 109

(a) Pegatina

(b) Pistas de cobre

Figura 10.8: Las dos caras de la placa.



Ahora se realiza el revelado, introduciendo la placa en un recipiente con reve-lador, durante10−15s, frotando suavemente con el dedo para dejar al descubiertoel cobre que tiene que entrar en contacto con elacido. Seguidamente se enjuagacon abundante agua, para eliminar el revelador. A partir de este punto la exposi-cion a la luz deja de ser perjudicial.

El ultimo paso es introducir la placa en elacido. Para ello, se tiene que per-forar, para poder colgarla dentro del recipiente. En este caso se puede utilizar unode los agujeros de fijacion del conector del puerto serie. Una vez hecho esto, seintroduce la placa en elacido, suspendida de un cable3. Una vez conseguido elresultado deseado, se saca la placa delacido y se enjuaga con abundandte agua.Porultimo, se sumerje en alcohol durante30s, y se vuelve a enjuagar y secar conpapel, para eliminar la capa que recubre las pistas.

10.3.2.2. Perforacion y Soldado

Inspeccionada la placa para comprobar que todas las pistas estan bien (si esnecesario se puede usar un medidor de continuidad), se pasa a la perforacion de laplaca con el taladro fijo. Para ello se colocan las pistas hacia arriba y se taladra.

Una vez todos los agujeros esten hechos, se pega la pegatina con la distribucionde componentes al otro lado de la placa, se recortan los bordes y se abren losagujeros con una cuchilla.

El paso siguiente consiste en soldar todos los componentes. Para ello se sujetala placa con el soporte dispuesto para tal efecto y, siguiendo el esquema dado porla pegatina, se van soldando las piezas. La forma correcta de hacer esto es, unavez el soldador este caliente, tocar con la punta el sitio en que se quiere fijar elestano, y un par de segundos despues, acercar el estano, para que se difunda solosobre el cobre, obtenienodse ası el mejor resultado. Una vez que el componenteeste soldado, se recortan las puntas sobrantes con unos alicates.

10.3.2.3. Pruebas

Una vez terminada la placa, y para aislar posibles fallos, es conveniente com-probar la continuidad de las pistas, a parte de cerciorarse de que no se han pro-ducido cortocircuitos al soldar. Para ello se hace uso de un polımetro con aviso

3Es conveniente tener tanto el calefactor como la bomba de aire del recipiente deacido encen-didos desde un rato antes, para que la disolucion este a una temperatura lo mas uniforme posible,para que el efecto sobre el cobre de la placa no dependa de la posicion del mismo, puesto quesi no, puede ocurrir que algunas pistas sean danadas, mientras que otras no sean correctamenteperfiladas.


Electronica 111

acustico de continuidad, y se comprueban, una a una, todas y cada una de las pis-tas. Esto puede resultar tedioso, pero puede ahorrar mucho tiempo a la hora dedetectar y aislar un posible fallo.



Figura 10.9: Fotografıa de la placa terminada.


11

Software de Bajo Nivel

A partir de aquı comienzan las etapas de desarrollo desoftware. La primeratiene que ver directamente con el control de los servomotores y el sonar,a parte de la deteccion del estado de las patas y la comunicacion con elservidor. Esta parte se lleva a cabo con el microcontrolador, por lo que

su programacion se realiza en ensamblador[1, 15, 16].

11.1. Objetivos

P ara fijar inicialmente lo que se quiere conseguir, lo primero es tener claroque es lo que tiene que realizar el sistema. Para ello, se enumera a continua-

cion la funcionalidad a cubrir por parte del mismo:

✵ Recepcion de tramas de posicion de los servomotores por el puerto serie, a38400bps.

✵ Envıo de tramas del estado de las patas y distancia medida por el sonar, a38400bps.

✵ Generacion de las 16 senales PWM que controlan a los servomotores.

✵ Manejo del sonar.


11.2. Diseno escogido

P uesto que las senales de control PWM son muy sensibles a las variacionesen la temporizacion, provocadas por la aleatoriedad de las interrupciones,

se ha decidido no hacer uso de las mismas, programando de forma sıncrona, yrealizando las lecturas, tanto del puerto serie como del estado de las patas, porpolling.

Basando el esquema en ununico bucle principal y varios bucles internos, se hasubdividido el codigo en tres partes:

1. 900µs iniciales, para daroffsetal primer bloque de servomotores1. Ademasse envıa la trama de distancia medida por el sonar, si procede.

2. 3000µs, subdivididos a su vez en 2 subbloques2 de1500µs cada uno, paragenerar los anchos de pulso de las senales PWM. Al final del segundo sub-bloque se envıa una trama de vuelta con el estado de las patas (apoyadas ono).

3. Ultimos 16000µs, con todas las salidas PWM a 0, realizando el control delsonar.

Ademas, a lo largo de todo el bucle, se realizan comprobaciones del estadodel puerto serie, y se va extrayendo del mismo la trama con las posiciones de losservomotores.

A continucacion se presenta el diagrama de flujo correspondiente al esquemade funcinamiento presentado.

1Mas adelante se expondra el porque deloffset.2Mas adelante se expondra el porque de esta subdivision.


Software de Bajo Nivel 115

900µs

1600µs

3000µs

Envía ladistanciamedida porel sónar

Controlael sónar

Init

Controlael 1erbloque deservos

Controla

bloque deservos

el 2º

Figura 11.1: Diagrama de flujo general ASM.



11.2.1. Preliminares

Antes de comenzar directamente con la forma en que se realizan las tareasrequeridas, se va a mostrar la forma en que se han asignado variables y constantes.

Primeramente, esta la asignacion de registros del microcontrolador. Para lasposiciones de los servomotores se usan los 8 primeros registros, primero para loscontrolados en el primer subbloque, y despues para los restantes 8. Esto es posibleporque las posiciones se tienen almacenadas en SRAM interna, y los registrossolo se usan para realizar las comparaciones de forma mas rapida y comoda conel contador, como se vera en el apartado dedicado a la generacion de las senalesPWM.

Posiciones de Servomotores

1. .def servoIzq1Pos = r01 ; * Posicion actual del servo izq 1

2. .def servoIzq2Pos = r02 ; * ...

3. ...4. .def servoIzq6Pos = r06 ; * ...

5. .def servoAux21Pos = r07 ; * ...


7.8. .def servoDer1Pos = r01 ; * Posicion actual del servo der 1

9. ...10. .def servoAux31Pos = r07 ; * ...


Las salidas que se dan por los puertos A y C se almacenan permanentemente en2 registros.Estos son de la mitad superior de los 32 que tiene el microcontrolador,porque si no, no se puede utilizar la instruccion de escritura en puerto con losmismos[16].

Salidas PWM

12. .def servoIzqAux2 = r16 ; * Salida para el puerto A

13. .def servoDerAux3 = r17 ; * Salida para el puerto C

Para la recepcion por el puerto serie se utilizan otros dos registros, uno paraverificar que ha llegado un dato, y otro para leer el mismo de la UART:

Puerto Serie

14. .def regusr = r26 ; * Valor del registro USR (puerto serie)

15. .def rxchar = r27 ; * Byte recibido



Ademas son necesarias una variable auxiliar y varios contadores:

Variables Auxiliares

16. .def temp = r28 ; * Variable temporal

17. .def count = r18 ; * Contador

18. ...

Y por ultimo, distancia y estado del sonar, y el estado de apoyo o no de laspatas:

Sonar y Patas

19. .def distSonar = r21 ; * Distancia medida por el sonar

20. .def estadoSonar = r22 ; * Estado del sonar

21.22. .def estadoPatas = r23 ; * Estado de las patas (apoyadas o no)

La asignacion de constantes, a parte de facilitar la programacion, elimina laaparicion de numeros magicos en el codigo. Fundamentalmente, se han utilizadoconstantes para crear mascaras de bits, y poder ası manejar los pines de control ydeteccion, con independenica de cuales fueran:

Constantes

23. .equ servoIzq1Mask = ~$01 ; * Mascara para poner a 0

24. ...25. .equ servoDer6Mask = ~$20 ; * ...

26. .equ servoAux31Mask = ~$4027. .equ servoAux32Mask = ~$8028.29. .equ patasApoyMask = $3F ; * Mascara estado patas

30.31. .equ activaSonarMask = $01 ; * Activa sonar

32. .equ desactivaSonarMask = ~$01 ; * Desactiva sonar

33.34. .equ ecoSonarMask = $02 ; * Lectura del sonar

En este punto hay que tener especial cuidado. Un problema detectado con el com-pilador utilizado es que, si las constantes se definen en binario, y no dando error encompilacion, su valor no es el correcto, provocando un funcionamiento anomalodel microcontrolador. Por ello, todas las constantes han sido definidas en hexade-cimal.



11.2.2. Inicializaci on del Microcontrolador

Siguiendo las directrices marcadas por lo que se consideran buenos habitos, ala hora de programar en ensamblador, lo primero es inicializar el puntero de pila,en este caso a SRAM interna:

Puntero de Pila

1. init:2. ldi temp, $01 ; * Puntero de pila a h015F (SRAM interna)

3. out SPH, temp4. ldi temp, $5F5. out SPL, temp

Acto seguido se pasa a configurar el puerto serie:

✵ Velocidad a38400bps.

✵ Transmisor activo, para poder mandar tramas de vuelta al servidor.

✵ Interrupcion de UART deshabilitada (el codigo tiene que ser sıncrono).

Puerto Serie

6. ldi temp, $0C ; * UART a 38400 bps

7. out UBRR, temp8. ldi temp, $18 ; * Interrupcion deshabilitada y tx activo

9. out UCR, temp

Por otra parte, se desactivan los elementos que no se van a utilizar, como elWatchdogy el comparador analogico:

Watchdog y Comparador

10. ldi temp, $0011. out WDTCR, temp ; * Watchdog Timer deshabilitado

12. out ACSR, temp ; * Analog Comparator deshabilitado

13. ...

Como al comenzar el funcionamiento del sistema, no se garantiza que el servi-dor mande directamente posiciones seguras para los servomotores, es necesarioinicializarlos convenientemente. Para ello se inicializan los valores de las 16 posi-ciones de SRAM interna que se utilizan como pila de recepcion:



Posiciones de Servomotores

14. ldi temp, $8015. sts $0080, temp ; * Init pataIzq01 a 128

16. ldi temp, $8017. sts $0081, temp ; * Init pataIzq02 a 128

18. ...

La configuracion de los puertos de proposito general es una cuestion muy de-licada, puesto que un error en este punto puede inutilizarlos, si se fuerza un nivelde tension en un pin configurado como de salida:

Puertos de I/O

19. ldi temp, $FF ; * Configura el uso I/O de los puertos

20. out ddra, temp ; * Patas lado izq y Auxiliar2: Out

21. out ddrc, temp ; * Patas lado der y Auxiliar3: Out

22. ldi temp, $FD ; * Patas apoyadas: In

23. out ddrb, temp ; * Auxiliar1[1]: Out (sonarInit)

24. ; * Auxiliar1[2]: In (sonarEco)

25.26. ldi temp, $00 ; * Pone a 0 los pines de salida

27. out porta, temp ; * y desactiva el uso de las

28. out portb, temp ; * resistencias de PULL-UP

29. out portc, temp ; * en los pines de entrada

Un detalle a tener en cuenta es la desactivacion de las resistencias depull-upen los pines de entrada. Estas resistencias conectan internamente estos pines aalimentacion[16], y si no se desactivaran, aparte de aumentar el consumo, podrıanproducir medidas erroneas, por la circuiterıa de senal que se utiliza, basada enresistencias con LEDs en serie conectados a tierra.

El control del sonar (como se vera mas adelante), se realiza pasando por variosestados. El designado por 4 corresponde con uno de espera, necesario para queel mismo arranque correctamente.Este es el motivo por el que se inicia en esteestado:

Estado del Sonar

30. ldi estadoSonar, $04 ; * Inicializa el estado del ciclo

Y hasta aquı la inicializacion del sistema. Ahora se pasa al bucle principal,que se repetira de forma continua hasta que sereseteela placa (con el pulsador



dispuesto a tal efecto en la placa, al lado del MAX232), o se desconecte de ali-mentacion.

11.2.3. Bloque Inicial

Al principio de cada vuelta del bucle principal se introduce un bloque de900µs, que a parte de generar eloffsetnecesario para el primer subbloque deservomotores, se encarga de enviar lasonarPDU si procede (distancia medida porel sonar). Como la UART solo tiene 1 registro de datos de envıo, es necesario in-troducir retardos entre la bandera de inicio de la PDU y la distancia. Esto se realizacon retardos puros, a los que se intercalan intentos de recepcion de datos, para noperder las posibles nuevas posiciones que llegan por el puerto serie3. Por otro la-do, se gestiona el llamadoestado 4del sonar, que se encarga de tenerlo inactivodespues de cada medida, durante mas de10000µs, siguendo las especificacionesdel mismo[44].

Ademas, para que esta parte no quede incompleta, se incluye al final un sub-apartado dedicado a la lectura del puerto serie, en el cual se explica con detallecomo se realiza este proceso.

Un detalle interesante es el aprovechamiento de las instrucciones de salto condi-cional para igualar la duracion de cada lınea de ejecucion, puesto que al saltar usan2 ciclos y cuando no saltan usan solo 1[15].

3Los bloques de retardo, y las lecturas del puerto serie, no se incluyen en el diagrama de flujo,para mejorar la simplicidad en su comprension.



del 1er gruposalidas PWMPone a 1 las

estadoSonar = 1 nop

nopestadoSonar = 4

estadoSonar== 3

estadoSonar== 3

estadoSonar== 3

de inicio dela sonarPDU

Envía banderanop

Retardo finalpara completarlos 900µs

distanciamedida porel sónar

Envía la

nopestadoSonar== 4

1

1

SÍ

SÍ

SÍ

SÍ

NO

NO

NO

NO

Figura 11.2: Diagrama de flujo del bloque inicial.



Lo primero, es la precarga de los valores de salida de los pines que controlanlos servomotores, pero solo activando los del primer subbloque. En el apartadodedicado al control se explica esto con mas detalle.

Carga Inicial de PWM

1. ldi servoIzqAux2, $FF2. ldi servoDerAux3, $FF3. out porta, servoIzqAux2 ; * Solo activa la mitad izquierda

Ahora se comprueba si el sonar esta enestado 4, si es ası, se sabe que ya llevapor lo menos10000µsde espera, por lo que pasa aestado 1(activacion).

Estado 4

4. cpi estadoSonar, $045. brne EstadoSonar04else6. ldi estadoSonar, $017. EstadoSonar04else:8.

Si esta enestado 3, pasa a enviar la bandera de inicio de lasonarPDU.

Estado 3

9. ldi temp, $FF10. cpi estadoSonar, $0311. brne estadoSonar03elseFF12. out udr, temp13. estadoSonar03elseFF:14.

. . . y si esta enestado 3, envıa la distancia medida por el sonar en el campo dedatos de lasonarPDU. Esta comprobacion del estado puede parecer redundante,pero hay que tener en cuenta que entre este paso y el anterior hay bloques deretardo y lectura del puerto serie, y se hace ası para que la separacion entre 2lıneas de ejecucion sea mınima, facilitando ası la programacion.

Estado 3

15. cpi estadoSonar, $0316. brne estadoSonar3elseA



17. out udr, distSonar18. estadoSonar3elseA:19.

Si esta enestado 3pasa aestado 4, para comenzar el descanso de al menos10000µs.

Pasa a Estado 4

20. cpi estadoSonar, $0321. brne estadoSonar3elseB22. ldi estadoSonar, $0423. estadoSonar3elseB:24.

Porultimo, completa con retardos y recepciones los900µs.

Retardo Final

25. retardo05exterior:26.27. ...28.29. retardo05:30. inc count31. nop32. nop33. nop34. nop35. cpi count, $6136. brne retardo0537. ldi count, $0038.39. inc count2 ; * Contador del bucle exterior

40. cpi count2, $0541. brne retardo05exterior42. ldi count2, $0043.44. finRetardoInicial:45.



11.2.3.1. Lectura del Puerto Serie

Se realiza porpolling, aproximadamente cada100µs, para garantizar la ausen-cia de perdida de datos (a la velocidad a la que se ha configurado el puerto, lallegada de datos, con envıo continuo, ocurre aproximadamente cada200µs). Elalgoritmo se basa en comprobar si se ha recibido unbytepor el puerto serie, sies ası se lee, y si no, no se hace nada. Si elbyterecibido es la bandera de inicio,de valor 255, se hace que el puntero de la pila de recepcion apunte a la posicioninicial de la misma, y si no lo es, se copia el valor a la pila de recepcion, y seincrementa el puntero que la maneja.

posición e incel puntero depila

Guarda laReinicia elpuntero depila

Bandera deinicio?

Lee Dato

Hay dato?

SÍ

SÍ

NO

NO

Figura 11.3: Recepcion de datos por el puerto serie.



La implementacion realizada es la siguiente:

Lectura del Puerto Serie

1. in regusr, USR ; * Comprueba q hay

2. sbrs regusr, 7 ; * un nuevo dato

3. rjmp noDatoRx4.5. in rxchar, udr ; * Si hay dato lo lee

6.7. cpi rxchar, $FF ; * Si es la bandera de

8. brne datoRx ; * inicio pone el

9. ldi r30, $80 ; * puntero de la pila

10. ldi r31, $00 ; * de recepcion al ppo

11. rjmp finRx12.13. noDatoRx:14. nop ; * Retardo de

15. nop ; * sincronizacion

16. nop ; * cuando no hay

17. nop ; * dato

18. rjmp finRx19.20. datoRx:21. st Z+, rxchar ; * Guarda la nueva

22. nop ; * posicion recibida

23.24. finRx:25. nop ; * Retardo para que

26. nop ; * la lectura dure

27. nop ; * 2us

28. nop29. nop



11.2.4. Generacion de Senales PWM

Para la generacion de senales PWM se ha utilizado un algoritmo basado encontador. Como la precision que da el protocolo de control es de 255 niveles, seusa un contador hasta ese valor, y un bucle, que a cada vuelta comprueba si elcontador ha alcanzado el valor de cada servomotor. Si es ası pone el pin corres-pondiente a 0.

El problema de diseno surgido es el del numero de instrucciones que el micro-controlador es capaz de ejecutar, por servomotor y vuelta del bucle. Utilizando uncuarzo a8MHz, y sabiendo que el sistema da1MIPS/MHz[16], en este caso setendran8MIPS, es decir,0,125µs/ciclo. Ası, el numero de ciclos de instruccionque es capaz de ejecutar por servomotor y vuelta sera:

⌊1500[µs]

255[vueltas] 16[servos] 0,125[µs/ciclo]

⌋= 2 [ciclos/vuelta servro]

Esto es demasiado crıtico, ası que no se puede utilizar. Elunico parametro quese puede modificar es el de numero de servomotores controlados. Dividiendolosen 2 grupos, teniendo 8 en cada grupo, se obtiene:

⌊1500[µs]

255[vueltas] 8[servos] 0,125[µs/ciclo]

⌋= 5 [ciclos/vuelta servro]

Tambien hay que tener en cuenta que hay que realizar varias comprobacionesdel puerto serie durante el tiempo en que se ejecuta el bucle. Los ciclos que seutilizan para esto son los que sobran de controlar los servomotores.

Ademas, puesto que se han tenido que dividir los servomotores en 2 grupos,las senales de control del segundo tienen que ponerse a 1 en algun momento, a lolargo de la ejecucion del bucle de control del primer subbloque, por lo que tambienhay que realizar una comprobacion de esto.

El diagrama de flujo sera, por tanto:



Se repite elproceso conlos 7 servosrestantes

Carga posicionescontador = 0

contador>=posServo1

Refresca lassalidas

Actualiza conla máscara deservo1

nop

Recepciónde datos

Incrementa elcontador

contador==255

Calibra el 2ºbloque deservomotores

NO

SÍ

SÍ

NO

21

12

Figura 11.4: Control de los servomotores.



Ası, primero se cargan las posiciones en registros internos, para mejorar lavelicidad de proceso:

Carga de Posiciones

1. lds servoIzq1Pos, $00802. ...3. lds servoAux22Pos, $008D

Seguidamente, comienzan a compararse con el valor del contador, actualizan-dose el registro que refrescara al puerto al final del bucle. Para que cualquierlınea de ejecucion dure siempre lo mismo, se aprovecha que el salto condicionalnecesita 2 ciclos si salta, y 1 si no lo hace.

Control de Servos

4. ldi count, $005.6. patasIzqAux2PWM:7.8. cp count, servoIzq1Pos ; * Actualiza el valor del

9. brlo servoIzq1Else ; * ctrl respecto del

10. andi servoIzqAux2, servoIzq1Mask ; * valor del contador

11. servoIzq1Else:12.13. cp count, servoIzq2Pos ; * Igual q el anterior

14. brlo servoIzq2Else15. andi servoIzqAux2, servoIzq2Mask16. servoIzq2Else:17. ...18.19. ; *

20. ; * Refresca las salidas

21. ; *

22. out porta, servoIzqAux223.24. ; *

25. ; * Recepcion de datos

26. ; *

27. ...28.29. finRxIzqAux2:30.

Para que la base de tiempos utilizada con el segundo grupo de servomotoressea la misma que con el primer grupo, es necesario activar sus senales de control



durante la ejecucion del primer subbloque. Para ello, de nuevo se hace uso delcontador de bucle.

Calibracion del Segundo Bloque

31. inc count ; * Pone a 1 los controles

32. cpi count, $55 ; * de la segunda mitad de

33. brne patasIzqAux2PWMelse ; * servos cuando llega

34. out portc, servoDerAux3 ; * el momento

35.36. patasIzqAux2PWMelse:37.

Porultimo, estan las instrucciones de control de flujo, que vuelven al principiodel bucle en cada iteracion.

Fin del Bucle

38. cpi count, $FF39. brne patasIzqAux2PWM40. ldi count, $00

Para el segundo bloque la estructura es la misma, menos en la parte de acti-vacion del otro subbloque, en la que no se hace nada, manteniendose solo porsimetrıa.



11.2.5. Control del Sonar

En el ultimo bloque (16000µs), se realiza el control del sonar. Para ello, hayque tener en cuenta su cronograma:

8 ciclos de ráfagaultrasónica a 40kHz

10ms mínimopara generarla siguienteráfaga

10µs mínimo 10µs mínimo

sonarInit

sonarEco de 100µs a 18ms

Figura 11.5: Temporizacion del sonar.

En el mismo se aprecia que, para que comienze a realizar la medida, hay quegenerar un pulso de, al menos,10µs, a la entrada de la lınea de control del mismo.Tras este pulso, el sonar envıa un tren de pulsos ultrasonicos, y tras un intervalode tiempo no especificado, se pone a 1 su lınea de salida. La duracion temporal deesta senal es directamente proporcional a la distancia medida, ası que habra querealizar dicha medicion.

Lo expuesto anteriormente es lo que, basicamente, se ha implementado en elultimo bloque de codigo, ademas de intercalar la recepcion de datos por el puertoserie, y el envıo del estado de apoyo de las patas.

Seguidamente, se va a explicar, algo mas detalladamente, este proceso. Paraello, se presenta, en primer lugar, el diagrama de flujo correspondiente, pero conciertas simplificaciones, como puede ser no incluir los retardos explıcitamente, nila recepcion de datos por el puerto serie. Estas dos tareas ya se han explicado enapartados anteriores, tanto su motivacion como su implementacion, por tanto, nose van a volver a comentar aquı.



1

nop

SÍ

NOestadoSonar

== 1

initSonar = 1

1

Envía elestado deapoyo delas patas

nop

SÍ

NOestadoSonar

== 1

initSonar = 0

nop

SÍ

NOestadoSonar

== 1

estadoSonar = 2

flotanteRetardo

inicial

Mide el ancho depulso. Si está enestadoSonar 2,pasa a 3.

Retardo flotantefinal. Complementaal inicial, para queel total sea cte.

Retardo de 15µs

Figura 11.6: Bloque final.



En primer lugar, se realiza el envıo del estado de las patas al servidor:

Envıo del Estado de las Patas

1. in estadoPatas, pinb ; * Carga el estado

2. lsr estadoPatas ; * y lo coloca en la

3. lsr estadoPatas ; * posicion adecuada

4. andi estadoPatas, patasApoyMask ; * Pone a 0 los MSB

5. out udr, estadoPatas ; * Envıa por puerto serie

6.

Si esta en elestado 1, activa la lınea de control del sonar:

Activa sonarInit

7. cpi estadoSonar, $01 ; * Si esadoSonar == 1

8. brne estadoSonar00elseA ; *

9. sbi portb, 0 ; * Activa sonarInit

10.11. estadoSonar00elseA:12.

Mantiene activa la senal de control durante15µs:

Retardo de 15µs

13. ldi count, $00 ; * Contador para el

14. ; * retardo

15. retardoFinal01:16. inc count17. nop18. nop19. nop20. nop21. cpi count, $0F ; * 15 vueltas

22. brne retardoFinal0123. ldi count, $0024.

Si esta en elestado 1, desactiva la lınea de control del sonar:

Desactiva sonarInit

25. cpi estadoSonar, $01 ; * Si esadoSonar == 1

26. brne estadoSonar00elseB ; *



27. cbi portb, 0 ; * Desactiva sonarInit

28.29. estadoSonar00elseB:30. cpi estadoSonar, $01 ; * Inicializa la

31. brne estadoSonar00elseC ; * distancia

32. ldi distSonar, $0033.34. estadoSonar00elseC:35.

Si esta enestado 1, pasa aestado 2:

Pasa a estado 2

36. cpi estadoSonar, $01 ; * Pasa a estado 2

37. brne estadoSonar00elseC38. ldi estadoSonar, $0239.40. estadoSonar00elseD:41.

Hasta este punto, todo lo realizado en el control del sonar es relativamente sen-cillo, utilizando el metodo de no separar mas que lo indispensable las diferenteslıneas de ejecucion. El problema aparece a partir de aquı, puesto que, como se hapodido comprobar en el cronograma, desde el instante en que se genera el pulsode senal de comienzo, hasta que el sonar genera el flanco de subida de su salidade eco, hay un intervalo no especificado por el fabricante y, lo que es aun peorpara el sistema sıncrono, que no se garantiza que tenga una duracion igual paracada vez que se use el sonar. Puesto que la duracion variable en la ejecucion delcodigo afecta directamente al posicionamiento correcto de los servomotores, seha utilizado un sistema basado en retardos flotantes. Esta es la tecnica que se va apresentar a continuacion:

1. Se comienza un bucle de espera, que es el retardo flotante inicial, mostradoen el diagrama de flujo. En el momento en que se detecte el flanco de subidade la senal de eco del sonar, o se llegue al valor maximo del contador quecontrola el bucle, se sale del mismo.

2. El siguiente bloque, contiene otro bucle de espera, que se realizara siempredesde 0 hasta 255 (haciendo uso de otra variable contador distinta a la delbucle anterior). A cada vuelta del ciclo se comprueba si ha llegado un flancode bajada por la lınea de eco del sonar. Si no es ası, y si se esta en elestado



2, y el registro que almacena la distancia no ha llegado a 254, se incrementael mismo.

3. Por ultimo, y tras haber pasado alestado 3si se estaba en elestado 2, yademas se ha recibido el flanco de bajada de la senal de eco del sonar, secompletan los ciclos del retardo flotante inicial, para que el total de ciclossea el mismo a cada vuelta de ejecucion del codigo.

Esta es, por tanto, la forma en que se consigue que el uso del sonar dure siemprelo mismo, independientemente de la respuesta del mismo.

A continuacion se va a mostrar la forma en que se ha implementado lo expli-cado anteriormente.

El retardo flotante, basicamente es:

Retardo Flotante Inicial

42. ldi countFlotante, $00 ; * Inicializa contador

43.44. retardoFlotante:45. inc countFlotante ; * Lo incrementa

46. in temp, pinb ; * Comprueba si

47. andi temp, ecoSonarMask ; * hay un flanco

48. cpi temp, ecoSonarMask ; * de subida en

49. breq ecoDetectado ; * la se~nal de

50. cpi countFlotante, $FF ; * eco del

51. brne retardoFlotante ; * sonar

52. nop53.54. rjmp retardo100usInit55.56. retardo100usInit:57.58. ldi count, $0059.60. ecoDetectado:61. nop62. nop63. rjmp retardo100usInit64.65. retardo100us:66. inc count ; * Retardo que

67. nop ; * se incluye

68. nop ; * para cumplir

69. nop ; * las specs

70. nop ; * del sonar

71. cpi count, $6472. brne retardo100us



73. ldi count, $0074.

Ahora se pasa a medir el ancho de pulso:

Mide el Ancho de Pulso

75. medidaSonar:76. in temp, pinb ; * Si sigue activa

77. andi temp, ecoSonarMask ; * la se~nal de eco

78. cpi temp, ecoSonarMask79. brne estadoSonar01elseA80. cpi estadoSonar, $02 ; * y esta en estado 2

81. brne estadoSonar01elseB82. cpi distSonar, $EF ; * y la distancia es

83. breq estadoSonar01elseC ; * menor que el max

84. inc distSonar ; * Incrementa distSonar

85. nop86. ...87. nop88. rjmp rxDatosFinal0389.90. estadoSonar01elseA:91. nop92. nop93.94. estadoSonar01elseB:95. nop96. nop97.98. estadoSonar01elseC:99. nop100. nop101.102. rxDatosFinal03: ; * Recepcion de datos

103.104. ...105.106. inc count ; * Bucle exterior

107. cpi count, $FF ; * de duracion

108. brne medidaSonar ; * constante

109. ldi count, $00110.111. in temp, pinb ; * Si detecta el

112. andi temp, ecoSonarMask ; * flanco de

113. cpi temp, ecoSonarMask ; * bajada del

114. breq estadoSonar02elseA ; * eco

115. cpi estadoSonar, $02 ; * y esta en estado 2



116. brne estadoSonar02elseB117. ldi estadoSonar, $03 ; * Pasa a estado 3

118. rjmp estadoSonar02A119.120. estadoSonar02elseA:121. nop122. nop123.124. estadoSonar02elseB:125. nop126. nop127.128. estadoSonar02A:129.

Porultimo, queda completar el retardo flotante incial, con los ciclos que no seejecutaron:

Retardo Flotante Final

130. cpi countFlotante, $FF ; * Si no ha llegado

131. breq finRetardoFlotanteCont ; * al final

132. nop133.134. retardoFlotanteCont:135. inc countFlotante ; * Completa el bucle

136. nop137. nop138. nop139. nop140. cpi countFlotante, $FF141. brne retardoFlotanteCont142. ldi countFlotante, $00143.144. finRetardoFlotanteCont:145.146. rjmp mainloop ; * Vuelve al principio del bucle de programa

147.

Como se puede observar, todas las lıneas de ejecucion duran lo mismo, y elretardo flotante consigue adaptarse al comportamiento no determinista del sonar.Ademas, si el sonar no detecta un obstaculo, seguira a 1 su salida de eco, por loque el sistema seguira enestado 2durante la siguiente vuelta de ejecucion, y unavez bajado a 0 pasara a estado 3. Ası se consigue cubrir toda la casuıstica delsonar.



11.3. Herramientas de Desarrollo

E n este caso se han utilizado dos herramientas: un compilador con editor inte-grado (Wavrasm) y un programa paraflashearel microcontrolador con una

tarjeta programadoraApollo, por puerto paralelo.

11.3.1. Wavrasm

La version utilizada ha sido la 1.0.0. Sobre su uso cabe poco que decir, sim-plemente se escribe el fichero en ensamblador con el editor integrado, se guardaen disco y se compila, generando el fichero HEX, que es el que posteriormente seenvıa al microcontrolador para programarlo.

11.3.2. FunProm

La version utilizada ha sido la 2.51, con un parche para Windows NT y XP parala comunicacion por puerto paralelo. El proceso es simple: se carga el fichero, seindica al programa que borre laflash, y seguidamente se le indica que la programe.

Eso sı, se ha encontrado un problema en esta version, y es que si se modificael fichero a enviar, es necesario salir del programa y volverlo a iniciar, cargandode nuevo el fichero de disco, porque si no, no lo actualiza, y sigueflasheandocon la version antigua del mismo, presumiblemente mantenida en memoria porparte del programa. Hasta que el fallo se detecto provoco bastantes dolores decabeza, por lo que se detalla aquı, para que pueda evitarse el problema a proximosprogramadores que usen estesoftware.



11.4. Pruebas y Calibracion

P rimero fue necesario calibrar el instante en que se activaba el segundo grupode servomotores (eloffset). Esto se hizo midiendo con un osciloscopio el

ancho de pulso generado para dos servomotores, uno de cada grupo, con la mismareferencia de control.

En segundo lugar, hubo que calibrar tanto el retardo flotante como el de espa-ciamiento fijo en el bloque de control del sonar. Esto tambien se hizo con ayudade un osciloscopio.

Para calibrar las posiciones de los diversos servomotores, en la fase de mon-taje, antes de ajustar a cada uno en su posicion, se alimentaron y posicionaron ensu posicion neutral, es decir, 128, y se encajaron las patas de tal forma que es-tuvieran en sus posiciones intermedias, tanto hombro como codo. Ası mismo, serealizo esta labor con la garra (2 servomotores) y el soporte para el sonar.

Porultimo, se probo la comunicacion por puerto serie, tanto la recepcion comola transmision. Esto se realizo con una version temprana delsoftwaredel servidor.


Bloque IV

Cliente y Servidor

12

Servidor

P ara implementar el sistema completo de control del robot se ha desarro-llado el servidor. Esta aplicacion se encarga, en sus capas mas bajas, dela comunicacion, por puerto serie, con el microcontrolador montado so-bre el robot, para posicionar los servomotores, y recibir, tanto el estado

de los sensores montados en los terminales de las patas, como las medidas que varealizando el sonar.

Las capas siguientes se encargan de la generacion de trayectorias articulares,respuestas ante la realimentacion recibida por los sensores en cuanto a velocidadde avance y giro, y porultimo, la comunicacion, sobre TCP, con el cliente quese quiera conectar, tanto para dar informacion de estado, como para permitir lateleoperacion a traves de la red, implementando un protocolo de control.

Todo ello ha sido implementado haciendo uso de la RTSJ (Real-Time Specifica-tion for Java[27]), ejecutandose sobre la primera maquina virtual que implementadicha especificacion[17].

En el presente capıtulo se van a desarrollar las ideas mas importantes que hanguiado el desarrollo de la aplicacion, pero no se pretende, en ningun caso, realizaruna descripcion detallada de la codificacion del servidor, puesto que para ello yase ha documentado conJAVADOC[52] todas las clases, metodos y variables queaparecen en el mismo. Toda esta documentacion, en formato HTML, se incluyeen el CD adjunto, como manual del programador. Lounico que se va a realizar,a lo largo de las proximas paginas, es recalcar las ideas principales que subyacentras el diseno, para que se pueda pasar a utilizar la documentacion en HTML conmas soltura.

142 Cliente y Servidor

12.1. Modelo en Capas

S e ha desarrollado un modelo basado en 6 capas bien diferenciadas, que semuestran en la figura 12.4. La idea es desacoplar, en la medida de lo posible,

las diferentes partes implicadas en el sistema, para ası conseguir un sistema masflexible a la hora de introducir modificaciones posteriores, ası como facilitar eldiseno y la implementacion del mismo.

La division se ha realizado siguiendo los siguientes criterios:

1. La comunicacion por puerto serie, tanto en recepcion como en transmision,debe ocultarse a las capas superiores.

2. Por otra parte, la comunicacion con el cliente, ası como el protocolo utiliza-do, debe ocultarse a las capas inferiores.

3. El calculo de las posiciones articulares, en cada instante de muestreo, sedebe realizar de forma independiente a la forma en que se obtienen las fun-ciones a seguir.

4. Las decisiones a tomar, respecto al rumbo y la velocidad de avance, se debengestionar de forma independiente al control articular directo, basandose soloen los parametros obtenidos a partir de la realimentacion sensorial, con-seguida a partir del sonar y los terminales de las patas.

A partir de estas premisas surge, de forma natural, el modelo de 6 capas im-plementado. A continuacion, se pasa a presentar las funcionalidades concretas decada capa, ası como los conceptos que rigen su implementacion haciendo uso dela RTSJ[27].

12.1.1. Capa 1: Enlace Puerto Serie

La comunicacion por puerto serie es dependiente de la plataforma, y al tenerque configurar la tasa de transferencia, bit de paridad,. . . ha sido necesario eluso de un metodo nativo en C, para acceder a los registros de la UART (esto seencapsula en el paquetenativo).

Una vez reconfigurado el puerto serie, se abren, ya conJAVA , un flujo entrante yotro saliente, para mantener la comunicacion (paquetemicroctrl). En este puntose ha detectado unbug del kernel utilizado, que produce perdidas de datos entransmision. Puesto que la maquina virtual que se tiene que utilizar solo funciona,a pleno rendimiento, con estekernel, ha sido necesario introducir retardos entrebytey byteenviado.


Servidor 143

Con todo lo anterior se consigue presentar a la capa superior una interfaz paraenviar y recibir datos, sin importar ni el medio ni el protocolo utilizados.

12.1.2. Capa 2: Eventos Periodicos de Recepcion y Transmision

Una vez conseguida una comunicacion transparente con el microcontrolador,aparece la necesidad de temporizacion precisa, especialmente en transmision, paraque las posiciones articulares sean enviadas en cada instante de muestreo, sin re-tardos excesivos para el control directo. Para conseguirlo se ha optado por el usode eventos periodicos, haciendo uso de temporizadores periodicos configurables,capaces de manejar periodos del orden deµsegundos. El periodo de muestreoutilizado es de 10ms.

En la implementacion se ha hecho uso de clases especıficas de la RTSJ[27],tanto en el caso de eventos periodicos, como en los gestores de eventos en sı,ası como de un hilo de ejecucion de tiempo real fuera del alcance del recolectorde basura. El paquete que contiene estas funcionalidades estrayartic.

12.1.3. Capa 3: Contenedor de Trayectorias Articulares

Para tener en cada instante de muestreo las posiciones listas para enviar, seimplementa esta capa que, a partir de funciones polinomicas de segundo grado,recibidas de la capa superior, recalcula las nuevas posiciones. Ademas, recibe di-rectamente los valores medidos por los sensores del robot, y a partir de los mis-mos, y combinados con las indicaciones recibidas de la capa superior, generaeventos relacionados con nuevas medidas del sonar, nuevos estados de apoyo ono de las patas, finalizacion de la ejecucion de una trayectoria,. . .

Todos estos eventos, lanzados hacia la capa inmediatamente superior, son con-figurables, es decir, que la capa superior indica, junto con las funciones pasadas,que eventos desea recibir, y cuales no. Esto consigue un considerable ahorro en eltiempo de gestion de eventos necesarios, puesto que no son reenviados a la capasiguiente.

La versatilidad de esta capa es enorme, puesto que permite concatenar trayec-torias y asociarles eventos diversos, todo ello de forma asıncrona, a la vez quepermite, que la capa inferior reciba, dentro de los lımites temporales establecidos,las posiciones articulares a enviar.

Puesto que el calculo de una muestra de posiciones articulares puede tardarun tiempo variable, la posicion futura es calculada inmediatamente despues derecibir la peticion, por parte de la capa inferior, de la posicion actual, y haberle



respondido con dicha posicion. Esto se realiza en un hilo independiente de tiemporeal, que tras dar su servicio se duerme, hasta la proxima vez que se solicite. Trasla ejecucion de este hilo, se realiza la gestion de eventos, en otro hilo de tiemporeal, que tambien se duerme tras prestar su servicio.

Esta forma de operar impide el bloqueo de las capas inferiores, siendo esto unacuestion crıtica, puesto que se perderıa la temporizacion requerida en las senalesde control. Ademas, se impide la entrada en estados incongruentes, a causa decondiciones de carrera mal resueltas en la etapa de diseno.

La implementacion de esta capa se encuentra en el paquetetrayartic.

12.1.4. Capa 4: Generador de Trayectorias Articulares

Esta capa se encarga de coordinar las patas entre sı, calculando las trayectoriasque tienen que seguir los servomotores, adaptando su velocidad y amplitud a par-tir de las directivas de velocidad y giro de la capa de navegacion, reaccionandoante los eventos ocurridos, asociados a cada trayectoria de cada pata, adaptan-do el movimiento a los desniveles del terreno, y enviando a la capa superior loseventos asociados a nuevas medidas del sonar, y si alguna pata no ha conseguidoapoyo (desnivel insalvable). Ademas, se encarga de gestionar el posicionamientoy medida del sonar.

Para ello, en funcionamiento normal, es decir,andando sin incidencias, se haimplementado una Red de Petri, que se muestra en la figura 12.3. Esta Red de Petrise encarga de coordinar entre sı las seis patas, basandose en los eventos asociadosa la capa inferior, y a los cambios en las directivas de navegacion (velocidad ygiro) impuestas por la capa superior. Para entender el funcionamiento de la RdP,es necesario exponer el modelo que se ha utilizado, a nivel articular, de las patas.Esto se va a realizar en el apartado siguiente.

12.1.4.1. Modelado de las Trayectorias Articulares de las Patas

Un ciclo completo de una pata se puede dividir en 3 tramos:

1. Elevacion.

2. Busqueda de apoyo.

3. Desplazamiento del cuerpo.

✵ Elevacion

En la etapa deelevacion, se realiza un movimiento ascendente, que tienevarios objetivos:


Servidor 145

✯ Separarse lo mas rapidamente posible del suelo.

✯ Llegar al punto mas alto con velocidad vertical nula.

✯ Situarse en la vertical para la ejecucion del siguiente tramo.

Por tanto, para el servomotor del hombro (movimiento vertical), se tienenlos siguientes datos:

✯ Posicion inicial:c0.

✯ Posicion final:cf in.

✯ Tiempo en que se quiere ejecutar la trayectoria:nmax.

Puesto que la capa inferior soporta trayectorias polinomicas de segundo gra-do, la expresion generica de la misma, junto a dos restricciones adicionales,es:

c(n) = a0 +a1 n+a2 n2 (12.1a)

a1 > 0 (12.1b)

a2 < 0 (12.1c)

La restriccion 12.1b implica que la velocidad vertical inicial es positiva,puesto que el movimiento tiene que ser ascendente. Por otra parte, la restric-cion 12.1c fuerza una aceleracion en sentido negativo, para ası conseguiruna velocidad nula al final de la trayectoria.

Particularizando paran = 0 en la expresion general 12.1a, y sabiendo quela posicion inicial esc0, se obtiene

c(0) = c0 = a0 (12.2)

Particularizando ahora paran = nmax en la expresion general 12.1a, y sabi-endo que la posicion final esc0, se obtiene

c(nmax) = cf in = a0 +a1 nmax+a2 n2max con cf in > c0 (12.3)

Sustituyendo el resultado de 12.2 y reescribiendo la ecuacion 12.3, se ob-tiene

cf in−c0 = a1 nmax+a2 n2max (12.4)



Por otra parte, puesto que la velocidad final tiene que ser nula, se utiliza lamisma

dc(n)dn

∣∣∣∣n=nmax

= a1 +2 a2 n∣∣n=nmax

= 0 (12.5)

Por tanto, a partir de los dos resultados parciales 12.4 y 12.5, se tiene elsiguiente sistema de ecuaciones:

cf in−c0 = a1 nmax+a2 n2max (12.6a)

0 = a1 +2 a2 nmax (12.6b)

Resolviendo el sistema anterior, y teniendo en cuenta el resultado 12.2, lostres coeficientes de la funcion de trayectoria quedan determinados por lassiguientes expresiones:

a0 = c0 (12.7a)

a1 = 2cf in−c0

nmax(12.7b)

a2 = −cf in−c0

nmax(12.7c)

En la horizontal, se realiza un movimiento con velocidad uniforme, del quese tienen los siguientes datos:

✯ Posicion inicial:h0.

✯ Posicion final:hf in.

✯ Tiempo en que se quiere ejecutar la trayectoria:nmax.

En este caso la expresion generica de la trayectoria es:

h(n) = a0 +a1 n+a2 n2 (12.8)


Servidor 147

Puesto que la velocidad es constante, la segunda derivada de la trayectoriadebera ser nula. Por tanto:

d2h(n)d2n

= 2 a2 = 0 =⇒ a2 = 0 (12.9)

Por otra parte, sustituyendo en 12.8, el punto inicialh0 y final hf in paran= 0y n = nmax respectivamente, se tiene el siguiente sistema de ecuaciones:

h0 = a0 (12.10a)

hf in = a0 +a1 nmax (12.10b)

Resolviendo el sistema anterior, y teniendo en cuenta el resultado 12.9, lostres coeficientes de la funcion de trayectoria quedan determinados por lassiguientes expresiones:

a0 = h0 (12.11a)

a1 =hf in−h0

nmax(12.11b)

a2 = 0 (12.11c)

✵ Busqueda de apoyo

Durante la busqueda de apoyo se mantiene el hombro quieto, por lo que solohay movimiento vertical. Por simplicidad,este se ha modelado con veloci-dad uniforme, por lo que, realizando un desarrollo similar al realizado parael movimiento del hombro durante la etapa de elevacion, los coeficientesson:

a0 = h0 (12.12a)

a1 =hf in−h0

nmax(12.12b)

a2 = 0 (12.12c)



✵ Desplazamiento del cuerpo

El tercer tramo se refiere a la etapa en que la pata esta apoyada, y producedesplazamiento del cuerpo del robot. Puesto que solo se tienen 2 grados delibertad, se ha considerado como velocidad de avance a la producida por elhombro, modelandose como de velocidad constante.

Por otra parte, puesto que los desniveles del terreno pueden ocasionar que elcuerpo se acerque o aleje del suelo, se utiliza ademas una velocidad vertical,que se recalcula tras cada ciclo, para realizar lacompensacion de altura.Ambas trayectorias se modelan con expresiones similares a 12.12.

12.1.4.2. Funcionamiento de la Red de Petri

La idea que subyace tras la RdP es forzar a que haya siempre al menos trespatas apoyadas, a la vez que se consigue que las otras tres busquen un nuevoapoyo. Ası, se puede dividir un ciclo completo de la RdP en dos subciclos simetri-cos, que usando la numeracion de las patas actual, serıa el de las patas pares apo-yadas y el de las patas impares apoyadas.

Para interpretar los nombres y lugares de la RdP, hay que tener en cuenta queuna t seguida de un numero indica el numero de tramo, y unap seguida de unnumero indica un numero de pata. Ası, t2p0 quiere decirtramo 2 pata 0.

Comenzando en el lugarinicio, se activa directamente la transicion fininicio,puesto que no tiene condicion asociada, y se generan las trayectorias del tramo1 (subida) de las patas impares. Una vez finalizadas estas 3 trayectorias se dis-para la transicion fint1impar, generandose a la vez las 3 trayectorias del tramo 2(busqueda de apoyo) de las patas impares.Este es un punto de sincronismo.

Conforme van encontrando apoyo las patas impares, se van disparando las tran-sicionesfint2p1, fint2p3 y fint2p5, y generandose las correspondientes trayecto-rias del tramo 3.

Una vez que todas las patas impares se han apoyado (estan en el tramo 3), sedispara la transicion t3impar, generandose las correspondientes trayectorias deltramo 1 para las patas impares.

Una vez que las 3 patas pares han finalizado sus respectivas trayectorias deltramo 1, se activa la transicion fint1par, siendoeste otro punto de sincronis-mo, comenzando a ejecutarse los tramos 2 de las patas pares (buscando apoyo).Mientras lo van consiguiendo, se van activando las transicionesfint2p0, fint2p2 yfint2p4, pasando a los lugarest3p0, t3p2 y t3p4 respectivamente, ejecutando sustramos 3.


Servidor 149

Una vez que todas las patas pares han apoyado, se activa la transicion t3par,cerrandose el ciclo.

Lo anteriormente expuesto es lo que ocurre cuando no se producen incidenciasextraordinarias. Por ejemplo, en el caso de cambios en las directivas de velocidado giro, se producen adaptaciones de las respectivas trayectorias, ejecutandose elcodigo correspondiente de cada lugar marcado. Ademas, si alguna pata llega alfinal de su tramo 3, todas las patas apoyadas se paran, pero las que estan en el airecontinuan, hasta que consiguen apoyarse, para proseguir con el avance.

Solo hay una situacion en la que la RdP se para, y es el caso en que no seconsiga apoyar alguna pata. Bajo esta circunstancia, la capa de generacion detrayectorias notifica a la capa superior (navegacion) que pata no se ha podidoapoyar, y se queda a la espera de nuevas directivas de velocidad y giro. Una vezrecibidasestas, se reinicializa la RdP, es decir, que se vuelve al marcado inicial,en inicio o inicioimpar, en el caso en que se encontrara la ejecucion en la parteinferior de la RdP.

Gracias a esta sencilla implementacion se consigue desacoplar el problema dela coordinacion entre patas y las eventualidades que puedan surgir a causa delterreno, dejando a la capa superior la responsabilidad de corregir la ruta en casode no conseguirse apoyar alguna pata, pero descargandola de la labor de decidirsobre la coordinacion entre las mismas.

La implementacion de esta capa se encuentra en el paquetetrayartic.

12.1.5. Capa 5: Generador de Trayectoria Espacial

Funcionando de forma teleoperada, esta capa simplemente funciona como unenlaceentre la capa de comunicaciones y la de control articular. Es en el casodel funcionamiento autonomo cuando se realiza un verdadero proceso de decisionsobre el desplazamiento del robot.

Para conseguir esta capacidad de navegacion, se ha optado por un diseno basa-do en reglas borrosas, puesto que se considera una forma simple y elegante deconseguir una capacidad aceptable de interaccion con el entorno.

Las variables linguısticas implicadas en el modelado son las siguientes:

✵ Delante.

✵ Detras.

✵ Izquierda.

✵ Derecha.



✵ Demasiado Cerca.

✵ Cerca.

✵ Lejos.

Las distribuciones de pertenencia de las variablesdelante, izquierda y derechase muestran en la figura 12.1. Como se puede observar, estos conceptos son clara-mente borrosos, puesto que no se puede definir unaunica recta que contenga todoslos puntos pertenencientes al conceptodelante, pero sı en cambio, se puede decirque un punto esta masdelanteque otro.

y

x

0 0

1

(a) Izquierda

0 01

y

x

(b) Delante

y

x

0 0

1

(c) Derecha

Figura 12.1: Distribuciones, en el espacio cartesiano, de las diferentes variableslinguısticas que se utilizan para especificar direcciones en el espacio.

Por otra parte, a la hora de considerar distancias, se han utilizado las funcionesde pertenencia mostradas en la figura 12.2. Ası, combinando estas variables enreglas borrosas se consigue un comportamiento autonomo sencillo del robot.

Como se puede observar, las variables linguısticas no asimilan directamenteque el robot puede encontrarse sin apoyo bajo ciertas circunstancias. Para poderincluir esto dentro del modelo, sin anadirle complejidad, cada vez que ocurre unaeventualidad de este tipo, dependiendo del estado de avance y giro del robot, seasignan valores congruentes a las variables borrosas correspondientes. Ademas,se aplica unfactor de olvidoa los valores generados por la falta de apoyo de laspatas, puesto que al desplazarse el robot, deja de tener sentido mantener dichovalor.

El procesado de las reglas se realiza cada vez que se produce un nuevo evento,ya sea por una nueva medida del sonar, o porque una pata no ha conseguido apoyo.Para aumentar la capacidad de respuesta temporal, se almacena, en tablas unidi-mensionales, los valores borrosos de cada muestra del sonar, ası como del estadode las patas. Ası, cada vez que se produce un nuevo evento solo se recalculan losvalores correspondientes a dicho evento.


Servidor 151

0

1

distancia

Demasiado Cerca

(a)

0

1

distancia

Cerca

(b)

0

1

distancia

Lejos

(c)

Figura 12.2: Funciones de pertenencia de las variables linguısticas que se utilizanpara especificar distancias respecto del robot.

Despues, una vez que el hilo de navegacion pasa a ejecutarse, reevalua lasreglas borrosas, y decide en funcion de las mismas.

Basicamente, la funcionalidad de la que se ha dotado al navegador, es la deevitar obstaculos (elevaciones excesivas del terreno) ası como de agujeros por losque el robot se podrıa caer. Esta capa se ha dejado abierta, dando la posibilidad depoder integrar sistemas de navegacion mucho mas complejos, dando un entornode programacion para ello.

Toda la funcionalidad de navegacion se ha encapsuldo en el paquetetrayespa.

12.1.6. Capa 6: Comunicaciones

Para implementar la capa de comunicaciones del lado del servidor, se ha desa-rrollado el paquetecomInetServidor, con un conjunto de clases que encapsulanel protocolo desde el punto de vista del servidor.

El funcionamiento se basa en dos hilos de ejecucion independientes, uno parael flujo entrante, y el otro para gestionar el flujo saliente. Para hacer uso de laclase principal de comunicacion, puesto que esabstract, es necesario extenderlacon una subclase, implementando los metodos abstractos que, basicamente, sonllamados por el hilo de recepcion cada vez que decodifica una PDU (ProtocolData Unit) procedente del servidor.

Del lado de la comunicacion saliente, y para evitar el bloqueo a causa del retar-do en el envıo de datos sobre TCP, se ha implementado una cola de transmision,en la que se van colocando los datos de forma temporal, hasta que pueden serenviados.



inicioimpar

t2p0 t2p2 t2p4

t3p0 t3p2 t3p4inicio

t1impar

t2p1 t2p5t2p3

t3p1 t3p3 t3p5

t1par

fint1par

fint2p0 fint2p4fint2p2

fininicio t3par

fint1impar

fint2p1 fint2p3 fint2p5

fininicioimpar t3impar

Figura 12.3: Red de Petri que coordina las patas entre sı.


Servidor 153

EstadoRobotAvisable

DesplazamientoControlableModoAvisable GarraControlable

EstadoRobotAvisable

DesplazamientoControlable GarraControlable

EstadoArticularAvisable

EstadoArticularLeible TrayArticModificable

PosicionArticularLeible PataApoyadaAvisable MedidaSonarAvisable

RecepEstadoRobotAvisable

ComunicacionesServidor

GeneradorTrayEspacial

GeneradorTrayArtic

ContenedorTrayArtic

LanzadorEventosEstadoRobot

ManejadorEnvioPosServos ManejadorEnvioPosServos

Figura 12.4: Modelo de capas del servidor.


13

Cliente

E l cliente desarrollado tiene dos objetivos fundamentales: implementarla capacidad de comunicarse satisfactoriamente con el servidor, paraası poder enviarle lasordenes pertientes al robot, y presentarle al usuariouna interfaz grafica lo mas amigable posible. Para ello se ha utilizado

J2SE v1.4.2 (Java 2 Standard Edition version 1.4.2) y algunas caracterısticas detemporizicion de la extension Java3D.

Con el presente capıtulo no se pretende, en ningun momento, realizar una des-cripcion exhaustiva de la codificacion del cliente, puesto que para ello ya se hadocumentado conJAVADOC[52] todas las clases, metodos y variables que apare-cen en el mismo. Toda esta documentacion, en formato HTML, se incluye en elCD adjunto, como manual del programador. Lounico que se va a realizar, a lolargo de las proximas paginas, es recalcar las ideas principales que subyacen trasel diseno, para que se pueda pasar a utilizar la documentacion en HTML con massoltura.

13.1. Interfaz Gr afica

L a forma habitual de implementar interfaces graficas enJAVA es conSWING[31], un conjunto de paquetes para poder hacer uso de todo tipo de

elementos graficos en un entorno de ventanas, completamente independiente dela plataforma. Esta aproximacion al problema es muy sencilla, y haciendo usode un IDE comoNETBEANS o JBUILDER se puede tener la parte grafica de la


aplicacion terminada en comparativamente poco tiempo.

Aun siendo esto ası, y sabiendo queSWING es la opcion mas economica, enlo que a tiempo de desarrollo se refiere, se ha preferido otro planteamiento: laimplementacion de una interfaz a pantalla completa, haciendo uso de una nuevacaracterıstica deJAVA , el FSEM (Full Screen Exclusive Mode), implementando,ademas, tanto el repintado de la pantalla por codigo, usandopage flippingcon2 buffers[22], como todos los elementos graficos que aparecen, conXFIG[5] yGIMP[42].

Para ello, se han dibujado primero todos los componentes graficos que sequerıan utilizar en la aplicacion, desde botones y ventanas, hasta indicadores ymandos.

Por otro lado, se ha desarrollado el paqueteGUI, que contiene todas las clasesque implementan los elementos de la interfaz grafica, ası como los gestores deeventos asociados.

El funcionamiento global de la parte grafica se divide en varias partes:

1. Inicializacion de la pantalla en modo FSEM.

2. Carga e inicializacion de todas las imagenes que se van a utilizar en la in-terfaz.

3. Configuracion de la gestion de eventos de teclado y raton.

4. Inicio del bucle de refresco, y ejecucion periodica del mismo hasta la fina-lizacion de la aplicacion.

5. Finalizacion correcta.

Ahora se pasa a comentar los diferentes puntos enumerados.

13.1.1. Inicializaci on de la Pantalla

En esta primera etapa se comprueba que el sistema soporta FSEM, y si es ası,se desactiva el repintado automatico, puesto que se va a utilizar lo que se conocecomoactive rendering, es decir, que el repintado se hace por codigo.

Ademas, se configura laestrategia de buffer, que es depage flippingcon 2buffers[22, 52]. Esto quiere decir que se van a utilizar 2 bloques de memoria paraalmacenar lo que se muestra en pantalla, uno con la imagen actual, y otro con laque se esta generando para el siguiente refresco. Una vez que la nueva imagenesta lista, se conmutan las dos zonas de memoria, mostrandose la nueva imagen, yusandose la otra zona de memoria para generar la que se mostrara en la siguientevuelta.


Cliente 157

De esta forma se consigue aprovechar al maximo el hardwarede la tarjetagrafica. De hecho,esta es una tecnica comun a la hora de programar los juegosgraficos actuales.

13.1.2. Carga de Imagenes

Puesto que todos los elementos que se van a utilizar son imagenes en disco,y es un conjunto considerable, se ha implementado una clase que, a partir de lasinstrucciones que aparecen en un fichero de texto, carga las imagenes y secuenciasde imagenes especificadas. Para ello se ha desarrollado una sencilla sintaxis deespecificacion de ficheros[22].

Una vez cargadas, monta una tablahash[30], para acelerar el acceso a lasimagenes, presentando un conjunto de metodos para un acceso transparente a lasmismas por parte del programador.

Una vez terminado esto, la aplicacion comienza a crear los diferentes gestoresque necesitara a lo largo de la aplicacion.

13.1.3. Gestion de Eventos de Teclado y Raton

Para facilitar la programacion del hilo principal, se ha desarrollado una claseabstractque todos los dialogos deben extender, para el manejo de las imagenes,y una interfacecon un conjunto de metodos para uniformizar las llamadas a losmetodos de gestion de eventos de teclado y raton de cada clase[30, 31].

De esta forma, se consigue que el hilo principal no tenga que lidiar con que dia-logo concreto esta activo en cada momento, sino que directamente accede a ellospor medio de metodos iguales para todos, pero con funcionalidades concretas ydistintas, dependiendo todas ellas del tipo de dialogo.

13.1.4. Bucle de Refresco

Una vez que se ha conseguido inicializar correctamente al cliente, se comienzaa ejecutar un hilo independiente[34], que se activa de forma periodica (periodode refresco de la pantalla), para actualizar la pantalla. Para conseguir una tempo-rizacion lo suficientemente precisa, se ha utilizado un temporizador de precisiondeJAVA 3D[22, 51].

La idea es simple, se ejecuta, de forma cıclica, el codigo necesario para ac-



tualizar y refrescar la pantalla, y con el temporizador se consigue la precisionnecesaria.

Para no bloquear a otros hilos en ejecucion de forma indefinida[22, 34], si sedetecta, varias veces consecutivas, que el hilo no duerme, se le obliga a hacerlo,permitiendo a los demas hilos ejecutarse.

13.1.5. Finalizacion

Puesto que la JVM (Java Virtual Machine) se encarga, por medio del GC(Garbage Collector), de liberar toda la memoria no utilizada, lounico que seha tenido que programar es el cierre de los flujos de datos utilizados, ası comopermitir que los hilos de ejecucion finalicen correctamente sus metodosrun()respectivos.

13.2. Comunicaciones

P ara implementar la capa de comunicaciones del lado del cliente, se ha desa-rrollado el paquetecomInetCliente, con un conjunto de clases que encap-

sulan el protocolo desde el punto de vista del cliente.

El funcionamiento se basa en dos hilos de ejecucion independientes, uno parael flujo entrante, y el otro para gestionar el flujo saliente. Para hacer uso de laclase principal de comunicacion, puesto que esabstract, es necesario extenderlacon una subclase, implementando los metodos abstractos que, basicamente, sonllamados por el hilo de recepcion cada vez que decodifica una PDU (ProtocolData Unit) procedente del servidor.

Del lado de la comunicacion saliente, y para evitar el bloqueo a causa del retar-do en el envıo de datos sobre TCP, se ha implementado una cola de transmision,en la que se van colocando los datos de forma temporal, hasta que pueden ser envi-ados. Ası, el hilo que realiza llamadas a metodos para enviarordenes al robot (eneste caso el hilo de la interfaz grafica) no se bloquea a causa de la comuniacion.Esto es indispensable realizarlo ası, puesto que si no, la interfaz grafica podrıa norefrescarse en los tiempos adecuados, a causa de problemas con la comunicacion.

Para conseguir, de forma sencilla, que las PDUs entrantes tuvieran su reflejoinmediato en la interfaz grafica, se ha extendido la clase principal de comunica-ciones como clase interna de la clase principal de la interfaz grafica. Ası, al im-


Cliente 159

plementar la funcionalidad de los metodosabstractde la superclase,estos tienenacceso directamente a los metodos y variables privados de la clase principal de lainterfaz grafica, simplificando enormemente la implementacion.

13.3. Manejo

L o primero que se muestra al arrancar el cliente es un dialogo que solicita laIP del servidor del robot. Una vez introducidaesta y pulsandoACEPTAR, el

cliente intentara conectarse. Si no lo consigue mostrara una ventana advirtiendode la incidencia y volvera al primer dialogo. Si ha conseguido conectarse comen-zara a ejecutarse en modo teleoperacion.

En la parte superior izquierda hay siempre tres botones disponibles, el primeropara conmutar de modo (TELEOPERACION y AUTONOMO), el segundo para mos-trar una ventana de ayuda, dependiente del modo y, el tercero, para salir del pro-grama.

En las partes media y superior de la pantalla se muestra, sobre elfondo lunar,una animacion con lasultimas medidas realizadas por el sonar, al estilo de unapantalla de radar.

En la parte inferior estan los indicadores animados que, de izquierda a derecha,muestran:

✵ Apertura de la garra del robot.

✵ Grado de giro de la muneca de la garra del robot.

✵ Curvatura en la trayectoria de avance o retroceso del robot.

✵ Velocidad de avance o retroceso del robot.

13.3.1. Modo Teleoperacion

Este es el modo de operacion por defecto, en el cual el usuario puede indicaral robot que hacer, indicandole los valores para los parametros mostrados por losindicadores de la parte inferior de la pantalla.

Lasordenes aceptadas son:

1. Desplazamiento:



(a) Aumenta avance con el botonarriba.

(b) Disminuye avance con el botonabajo.

(c) Aumenta el giro hacia la izquierda con el boton izquierda.

(d) Aumenta el giro hacia la derecha con el botonderecha.

2. Garra:

(a) Aumenta la apertura de la garra con el boton control y arriba, si-multaneamente pulsados.

(b) Disminuye la apertura de la garra con el boton control y abajo, si-multaneamente pulsados.

(c) Aumenta el giro de la muneca de la garra, hacia la izquierda, con elbotoncontrol e izquierda, simultaneamente pulsados.

(d) Aumenta el giro de la muneca de la garra, hacia la derecha, con elbotoncontrol y dercha, simultaneamente pulsados.

3. Parada de emergencia:barra espaciadora.

4. Ayuda:F1.

5. Cambio de modo:F2.

6. Salir: F3.

13.3.2. Modo Aut onomo

En este modo el robot se comporta de forma autonoma, no respondiendo a masorden que la de parada de emergencia. Lasordenes aceptadas por teclado son:

1. Parada de emergencia:barra espaciadora.

2. Ayuda:F1.

3. Cambio de modo:F2.

4. Salir: F3.

Por ultimo, en la figura 13.1 se muestra una captura de pantalla del cliente enpleno funcionamiento.


Cliente 161

Figura 13.1: Cliente ejecutandose en modo autonomo.


Bloque V

Ampliaciones

14

Diseno Mecanico

14.1. De Hexapodo a Octopodo

A partir de los buenos resultados estructurales obtenidos con el diseno ac-tual en PVC, se propone ampliar el numero de patas del robot a 8, para

ası poder experimentar con estrategias de control basadas en el comportamien-to de los aracnidos. Esto aumentarıa su capacidad para moverse por terrenos conmayores desniveles, pudiendo experimentar con situaciones en las que pueda con-tinuar avanzando aun cuando no sea posible apoyar alguna de las patas.

14.2. De 2 a 4 Grados de Libertad

E l diseno actual de las patas se basa en una estructura de 2 grados de libertad,pero consiguiendo siempre el apoyo en vertical. Este sistema es muy efi-

ciente en lo que a numero de motores se refiere. Por otra parte, hay otros prototi-pos, como por ejemplo elCentollodel laboratorio, que tiene 3 grados de libertad.Aun ası, no es posible reproducir satisfactoriamente los movimientos propios deun insecto, puesto queestos tienen 4 grados de libertad en sus patas. Por tanto,se propone el estudio de la posibilidad de un desarrollo basado en 4 grados delibertad, imitando la estructura de una pata de insecto.

166 Ampliaciones

14.3. Realimentacion de Esfuerzos

A ctualmente, gracias a los sensores ubicados en los terminales de las patas,es posible detectar cuando el robot hace contacto con alguna de sus patas

sobre el suelo. Con este sistema se consiguen buenos resultados sobre superfiecesduras, no siendo ası sobre terrenos mas blandos, como tierra o grama. Por ellopuede resultar interesante estudiar otras posibilidades, como por ejemplo, la re-alimentacion de esfuerzos, basados en otro tipo de sensores, o midiendo directa-mente el consumo de los servomotores (esto habrıa que realizarlo con circuiterıaadicional).

14.4. Soporte Completo para Webcam

A ctualmente, hay un servomotor montado sobre la estructura del robot paradar soporte a una camara, pero el soporte para la misma no ha sido disenado

aun. Se pueden estudiar las distintas posibilidades que hay para este montaje, oincluso plantear la posibilidad de montar directamente una camara conpan andtilt incorporado, como por ejemplo laSONY EVI100.


15

Electronica y Software de Bajo Nivel

15.1. Microcontrolador

P ara las especificaciones actuales el microcontrolador utilizado da las presta-ciones necesarias. En el caso en que se quieran anadir mas sensores, o mayor

numero de servomotores, serıa necesario utilizar uno con mas puertos de propositogeneral, y posiblemente con mas capacidad de proceso.

Si se desea utilizar un puerto de comunicaciones diferente al actual, como porejemplo USB, tambien serıa necesario reemplazarlo, puesto que el modelo utiliza-do no tiene tales prestaciones.

15.2. Placa de Circuito Impreso

E l diseno se desarrollo pensando mas en la comodidad a la hora de realizarpruebas de conexionado, mas que en la optimizacion en espacio. Por tanto,

es susceptible de optimizarse en este aspecto, por ejemplo, utilizando un diseno ados caras, y minimizando la superficie ocupada por la misma.

Por otra parte, se podrıa separar el soporte de alimentacion de potencia para losservomotores de dicha placa, utilizando conectores normalizdos de modelismo.

168 Ampliaciones

15.3. Alimentacion

A ctualmente, se utiliza una fuente de alimentacion de laboratorio para elec-tronica y servomotores. Esto se podrıa sustituir porpilas de metal-hidruro,

convenientemente dimensionadas, y ası solo tener que haber conexion por puertoserie con el robot.

15.4. Servidor Integrado sobre el Robot

P uede resultar interesante montar sobre el robot directamente un sistemaem-bedded, o de bajo coste, como unaEPIA, anadiendo soporte para WLAN,

y un disco duroFLASH. Esto, junto al uso de alimentacion a bordo, permitirıa lacompleta autonomıa del robot.

Como el incremento de peso, a causa de las baterıas necesarias, puede afectarnegativamente al correcto funcionamiento del robot, puede ser necesario cambiarlos servomotores, al menos los de los codos, a los que generan 5kg.

15.5. Software de Bajo Nivel

C on el diseno actual se ha llevado al lımite sus prestaciones, y posiblementesea launica parte del diseno que no es susceptible de ampliaciones, a no

ser claro que se cambie de microcontrolador. La optimizacion del codigo es muygrande, al gestionar tanto la comunicacion por el puerto serie, la generacion delas 16 senales de control para los servomotores, la deteccion del estado de lossensores de las patas, y el control y temporizacion del sonar utilizado.

Por tanto, solo se puede hablar de cambios a nivel de ensamblador si se produceun cambio en el diseno electronico del robot, en cuyo caso habrıa que ver que eslo que hay que modificar o ampliar.


16

Software de Alto Nivel

16.1. Interfaz Gr afica del Cliente

P uesto que el equipo en que se ha desarrollado el software, tiene una tarjetagrafica con poca memoria, para la necesaria en aplicaciones 3D, se ha de-

jado esta faceta de lado. Por tanto, si se dispone de un equipo lo suficientementepotente, se podrıa desarrollar una interfaz grafica con FSEM, al igual que la ac-tual, pero esta vez haciendo uso de toda la potencia de la extension JAVA 3D[22].De esta forma se podrıa incluso desarrollar un simulador 3D de nuevas estrategiasen el movimiento de las patas, pudiendo simularlas antes de ejecutarlas sobre elservidor.

Ademas, puesto que no se ha montado finalmente unawebcamsobre el servo-motor instalado para tal efecto, no se tiene soporte por parte del cliente para lapresentacion de las imagenes obtenidas.

16.2. Comunicaciones

A nivel de comunicaciones se puede incrementar la funcionalidad del protocolosobre TCP, aumentando el numero y funcionalidad de las PDUs actualmente

implementadas, facilitando tareas de calibracion remotas, configuracion de la la-tencia del sonar, modificacion del tipo de trayectorias a utilizar con las patas,. . .

Por otra parte, se podrıa hacer uso de RT-CORBA, en vez de trabajar direc-

170 Ampliaciones

tamente sobre TCP. Esto incrementarıa enormemente la versatilidad, pudiendoseincluso desarrollar un sistema para dirigir un grupo de robots, pudiendo experi-mentar con la interaccion entre ellos.

Una forma posiblemente mas sencilla, es el uso de RMI (Remote MethodsInvocation). Actualmente no esta implementado para apliciaciones de tiempo re-al, pero esta en proceso de desarrollo la especificacion, dentro del grupo DRT-SJ[46] (Distributed Real-Time Specification for Java). De hecho, se ha realizadouna propuesta, por parte de Andrew Borg y Andy Wellings[11] para la imple-mentacion.

16.3. Navegacion

E l comportamiento autonomo implementado se puede ampliar hasta el infini-to, probando estrategias complejas de interaccion con el entorno. En el caso

de montar unawebcamse puede utilizar la informacion visual para interactuar conmas precision con el medio.

Otra opcion interesante puede ser la interaccion social con otros robots simi-lares, facilitando esta tarea con, por ejemplo, dispositivosBluetoothde bajo costey corto alcance, para la identificacion entre diferentes individuos.

16.4. Generacion de Trayectorias Articulares

L a estrategia escogida para la generacion de trayectorias articulares es unade las muchas que se podrıan utilizar, de hecho, se escogio por su simpli-

cidad y buenos resultados practicos. Pude resultar muy interesante, a la par queinstructivo, la implementacion de otras estrategias, tanto de coordinacion entre lasdistintas patas, como en el uso de otras funciones, por ejemplo, polinomios deorden superior.

Ademas, teniendo en cuenta que en las ampliaciones mecanicas propuestas seincluye el desarrollo de patas con 4 grados de libertad, mas similares a las delos insectos y aracnidos, aumentan enormemente las posibilidades en cuanto ageneracion de trayectorias se refiere.


Software de Alto Nivel 171

En este caso puede resultar interesante simular las estrategias conMATLAB ,haciendo uso de HEMERO.

16.5. Comunicacion con el Microcontrolador

S i se incrementan el numero de sensores montados sobre el robot, o se mo-difica la forma en que se controlan los motores, puede ser necesario el uso

de otras formas de comunicarse con el microcontrolador, pasando incluso al usode USB en vez de puerto serie. Puede ser interesante la implementacion y experi-mentacion, tanto a nivel de metodos nativos, como de cambios en la capa baja delservidor, de nuevas interfaces de comunicacion.


172 Ampliaciones


17

Conclusiones

L a idea original que motivo el presente Proyecto Fin de Carrera, que eraaplicar la RTSJ al control de un robot, ha desembocado en una com-pleta implementacion, no solo de un robot hexapodo, con la mecanicay electronica asociada, sino ademas desoftwarede alto nivel capaz de

controlarlo y operarlo. Ademas de haberse implementado un modelo en capasde control, se ha ido un paso mas alla, desarrollando una arquitectura cliente–servidor, pudiendose operar el robot a traves de Internet.

Y no solo eso, sino que tambien se ha desarrollado un sistema de navegacionautonomo, basado en reglas borrosas, para que el robot sea capaz de evitar obsta-culos, y moverse por un entorno desconocido, con desniveles del terreno.

La arquitectura de control empleada, al ser completamente modular, permitesu uso para experimentar con otras opciones de control, pudiendose modificar oampliar alguna capa, sin que esto afecte a ninguna de las demas.

Por tanto, los objetivos inicialmente planteados, han sido cubiertos, y en algu-nas partes superados con creces, en el transcurso de la elaboracion del presenteProyecto.

A nivel de software, la implementacion utilizada de la RTSJ, da resultadossatisfactorios en su uso para el control, permitiendo combinar la simplicidad y el-egancia de la programacion enJAVA , con capacidades apropiadas para entornos detiempo real. Lo que sı se ha echado en falta, a la hora de programar el servidor, esun entorno de desarrollo para, entre otras cosas, poder depurar, de forma comoda,el codigo.TimeSyslo comercializa, pero no comosoftware libre, por lo que no seha tenido acceso al mismo.

Tambien ha sido interesante el poder experimentar con las capacidades FSEMdeJAVA , ası como de la temporizacion conJAVA 3D, comprobando que se pueden

174 Conclusiones

conseguir altos rendimientos graficos sin necesidad de tener que programar concodigo dependiente de la plataforma. Aun ası, obviamente no se llega al mismonivel al que se obtendrıa con C++ o ensamblador, pero la comodidad que ofreceal programador bien merece la pena.

Por otra parte, se ha podido comprobar lo sencillo que puede resultar imple-mentar protocolos sobre TCP conJAVA , siendo muchısimo mas sencillo que conlas implementaciones clasicas en C o C++. Esto es debido a queSUN ha intentado,desde los inicios del lenguaje, que sea propicio su uso en el mundo Internet.

La programacion en ensamblador realizada ha sido realmente complicada, pues-to que el cumplimiento de las especificaciones temporales ha sido crıtico. Laarquitectura que se ha utilizado es de tipoejecucion cıclica, combinada con lametodologıa demaquina de estados. Ambas formas de plantear el problema seencuadran en lo expuesto en el capıtulo 3.

El desarrollo electronico ha permitido, por su parte, que se puedan aplicar al-gunos de los conocimientos teoricos sobre la materia, adquiridos a lo largo de lacarrera, permitiendo asentar conocimientos.

Por su parte, el uso de herramientas de modelado 3D, ha permitido entrar encontacto con una faceta de la ingenierıa practicamente desconocida para los estu-diantes deIngenierıa de Telecomunicacion, que es el diseno grafico. Esta facetaresulta muy interesante para quien tenga interes en profundizar en el campo de larobotica, puesto que, en algun punto del desarrollo del artefacto, sera necesario sumodelado mecanico.

Ası mismo, se ha podido comprobar que el proceso de mecanizacion de piezaspuede resultar muy complicado, sirviendo de leccion, y posibilitando el valorar deforma mucho mas consciente, lo que implica la fabricacion en sı. Ademas, puestoque las piezas se han tenido que fabricar manualmente, tambien se ha tomado enconsideracion lo complicado de llevar a cabo tareas artesanales.


Bloque VI

Apendices

Apendice A

Ejemplo de Codigo en ISO

S e presenta a continuacion el codigo que se utilizo para mecanizar, so-bre un taco de metacrilato, una pieza de tipohombro-codo superior. Seincluye aquı simplemente como ejemplo practico. Si se quisiera utilizarcon una plancha de aluminio, harıan falta fresas para aluminio, y unas

agarraderas que impidan que se doble al ir eliminando material por los bordes.

Mecanizacion del hombro-codo superior

1. N0006 F100 S3000 T5.5 ;(TALADRO DE 2MM)

2. N0007 M6 ;(CAMBIO DE HERRAMIENTA)

3. N0010 G00 G90 G43 X0 Y0 Z100 M34. N0020 G00 X31 Y3.75 Z105. N0030 G81 X31 Y3.75 Z0 I50 K2 ;(TALADRADO DE LOS 6 AGUJEROS)

6. N0040 G00 X31 Y30.25 Z107. N0050 G00 X19.525 Y23.625 Z108. N0060 G00 X42.475 Y23.625 Z109. N0070 G00 X19.525 Y10.375 Z10

10. N0080 G00 X42.475 Y10.375 Z1011. N0090 G80 (FIN TALADRADO)12. N0100 F100 S3000 T2.2 ;(TALADRO DE 8MM)


14. N0120 G00 X31 Y17 Z1015. N0130 G81 X31 Y17 Z0 I50 K2 ;(TALADRA CENTRO GRANDE)

16. N0140 G80 (FIN TALADRADO)17. N0150 F100 S3000 T5.5 ;(TALADRO PARA EJES)


19. N0170 G00 X31 Y62 Z1020. N0180 G81 X31 Y62 Z0 I50 K221. N0190 G80 ;(FIN TALADRADO)

22. N0200 F100 S3000 T1.1 ;(FRESA DE 8MM)

178 Apendices


24. N0220 G41 ;(COMPENSACION DE RADIO IZQUIERDA)

25. N0230 G00 X48 Y70 Z10 ;(PERFIL CON OREJERAS...)

26. N0240 G01 X38 Y62 Z027. N0250 G01 X38 Y55 Z028. N0260 G01 X38 Y55 Z1.529. N0270 G01 X38 Y40 Z1.530. N0280 G01 X38 Y40 Z031. N0290 G01 X38 Y32.492 Z032. N0300 G09 X24 Y32.492 I31 J033. N0310 G01 X24 Y40 Z034. N0320 G01 X24 Y40 Z1.535. N0330 G01 X24 Y55 Z1.536. N0340 G01 X24 Y55 Z037. N0350 G01 X24 Y62 Z038. N0360 G09 X38 Y62 I31 J6939. N0230 G01 X38 Y62 Z-1.5 ;(PERFIL CON OREJERAS, SEGUNDA PASADA...)

40. N0240 G01 X38 Y62 Z-1.541. N0250 G01 X38 Y55 Z-1.542. N0260 G01 X38 Y55 Z043. N0270 G01 X38 Y40 Z044. N0280 G01 X38 Y40 Z-1.545. N0290 G01 X38 Y32.492 Z-1.546. N0300 G09 X24 Y32.492 I31 J047. N0310 G01 X24 Y40 Z-1.548. N0320 G01 X24 Y40 Z049. N0330 G01 X24 Y55 Z050. N0340 G01 X24 Y55 Z-1.551. N0350 G01 X24 Y62 Z-1.552. N0360 G09 X38 Y62 I31 J6953. N0900 G01 X38 Y50 Z1054. N1400 M30


Apendice B

Instalacion de Debian Woody

D ebian es una de las mejores distribuciones de Linux que existen hasta elmomento. Su polıtica de conseguir un sistema con un alto grado de es-tabilidad, lo ha llevado a ser utilizado en entornos de servidores de red,y otros equipos que requieren de un alto grado de fiabilidad. Ademas, es

una distribucion no comercial, por lo que sus objetivos de estabilidad no entran enconflicto con objetivos comerciales. La version que se va a instalar, es laDebianWoody, que esta realizada en torno a unkernel 2.4, que es el entorno sobre el cualhabra que instalar elTimeSys Linux.

B.1. Hardware que se va a utilizar

L os pasos a seguir en el proceso de instalacion dependen, en gran medida, delhardwaresobre el cual se va a instalar[45]. Por este motivo, se incluyen a

continuacion, las caracterısticas principales del equipo sobre el que se ha realizadola misma:

✵ ProcesadorAMD@950MHz.

✵ Placa baseSoltek 750KV, con sonido integrado conVIA chipset.

✵ 512MB de RAM.

✵ Tarjeta graficaATI Rage 128Xpert.

✵ Pantalla TFT.

180 Apendices

✵ Discos duros de 12GB en los buses IDE0 maestro y esclavo.

✵ Grabadora de CD en el bus IDE1 maestro.

✵ Lector de CD en el bus IDE1 esclavo.

✵ SO Windows instalado en el disco duro conectado al IDE0 maestro.

B.2. Proceso de Instalacion

B.2.1. Preparacion del Sistema

1. Se arranca el PC y se entra en la BIOS, deshabilitando elVirus Warning(para que se pueda sobreescribir correctamente el sector de arranque —MBR—),y se habilita el arranque desde CD-ROM. Se graba la configuracion y se salede la BIOS.

2. Se inserta el CD etiquetado comoBinary 1, y se reinicia el equipo.

B.2.2. Eleccion de la Version e Inicio del Proceso

1. Una vez que aparece elboot promptse introduce la version que se quiereinstalar, en este caso la que usa unkernel 2.4:

boot: bf24

y se pulsaintro, para comenzar la instalacion.

2. Se elige el idioma:es

3. Aparece el menu principal de instalacion. Se eligeConfigurar teclado:

(a) Se selecciona:qwerty/es: Espanol

B.2.3. Particionando el Disco Duro

1. Vuelve al menu principal. Se eligeParticionar un disco duro:

(a) Se elige la unidad, en este caso/dev/hdb.


In�alacion de Debian Woody 181

(b) Arranca elcfdisk, que es una utilidad para particionar discos duros. Elesquema de particiones utilizado es el siguiente:

Name Flags Part Type FS Type Size(MB)

hdb1 Boot Primary Linux ext2 501.7

hdb2 Primary Linux ext2 501.7

hdb3 Primary Linux ext2 3002.2

hdb5 Logical Linux ext2 3002.2




hdb9 Logical Linux swap 509.9

hdb10 Logical Win95 FAT32 509.9

Se escribe en la tabla de particiones y se sale delcfdisk.

B.2.4. Particiones, Sistemas de Ficheros y Puntos de Mon-taje

2. Vuelve al menu principal. Se eligeDar formato y activar una particion deintercambio.

(a) ¿Buscar bloques defectuosos?: No. Es la opcion por defecto, puestoque la busqueda de bloques defectuosos tarda mucho en realizarse.

(b) Pide confirmacion para/dev/hdb9, y se le dice que sı.

3. Iniciar una particion de Linux. Este paso se repite hasta tener el siguienteesquema (usando sistema de ficherosext2):


182 Apendices

Partici on Punto de Montaje

/dev/hdb1 /

/dev/hdb2 /boot

/dev/hdb3 /usr

/dev/hdb5 /home

/dev/hdb6 /var

/dev/hdb7 /tmp

/dev/hdb8 /local

B.2.5. El Nucleo del Sistema Operativo

1. Vuelve al menu principal. Se eligeInstalar el nucleo y los modulos.

2. Vuelve al menu principal. Se eligeConfigurar los controladores de disposi-tivos:

(a) Se entra enkernel/drivers/scsi, y se seleccionaide-scsi. Esto permi-tira utilizar la grabadora de CDs1. Se dice quesı cuando se preguntapor si se quiere instalar el modulo en elkernel, y no se le pasa ningunparametro al mismo.

(b) Se entra enkernel/drivers/sound, y se seleccionavia82xccc audio, con-testando igual que en el caso anterior.

B.2.6. El Sistema Base

1. Vuelve al menu principal. Se eligeConfigurar el nombre de la maquina, yse introducemerlin, por ejemplo.

2. Vuelve al menu principal. Se eligeInstalar el sistema base:

(a) Medio de instalacion: CD-ROM

(b) Unidad de CD-ROM: /dev/hdd (IDE1 esclavo).

1Las grabadoras de CDs, aunque esten conectadas albus IDE, se utilizan como si fueran dis-positivos SCSI.



B.2.6.1. Configuracion del LILO

1. Vuelve al menu principal. Se eligeHacer el sistema arrancable:

(a) ¿Donde se instalara el gestor de arranque LILO?: en/dev/hda (MBR).Se confirma.

(b) Incluir: Poner todo en el menu

2. Vuelve al menu principal. Se eligeCrear un disquete de arranquey sesiguen los pasos indicados en pantalla.

3. Vuelve al menu principal. Se eligeReiniciar el sistema(Hay que sacar elCD Binary 1del lector).

B.2.7. Instalacion de los Paquetes de software

1. En el menu deLILO se elige la opcionLinux.

2. Configuracion de la zona horaria:

(a) Is the hardware clock set to GMT?: No2

(b) Se escogeEuropa-Madrid

3. Shall I enable md5 passwords?: Sı

4. Shall I enable shadow passwords?: Sı

(a) Se introduce elpasswordderoot, que es . . .

5. Shall I create a normal user account now?: Sı

(a) Enter a user name: alberto

(b) Enter a full name: Alberto D. Prieto Lofkrantz

(c) Enter a password: . . .

6. Shall I remove the pcmcia packages?: Sı

2Linux es capaz de tener el reloj del sistema puesto en GMT (Greenwich Mean Time) y, a partirde la zona horaria en que se encuentre, obtener la hora del lugar. Esto tiene como ventaja queequipos conectados en red, desde diferentes zonas horarias, compartan la misma base de tiempo,facilitando la sincronizacion entre ellos, al realizar comunicaciones. Windows en cambio, no escapaz de hacer esto, y como el equipo en que se esta realizando la instalacion tiene ambos SO, seha elegido no tener el sistema puesto en GMT.


184 Apendices

7. Do you want to use a PPP connection to install the system?: No

8. Choose the method apt should use: cdrom

9. Se introduce el CDBinary 1y se pulsaintro.

10. Scan another CD?: Sı. Este paso se repite hasta que se hayan introducidolos CDs de la distribucion que se quieran usar,3 en este caso dos.

11. Add another apt source?: No

12. Use security updates fromsecuriy.debian.org?: No

13. Run tasksel?: Sı, y se selecciona:

(a) X Window system

(b) Desktop environment

(c) C and C++

(d) Spanish environment

(e) TeX/LaTeX environment

14. Run dselect?: No

B.2.8. Configuracion del Software Seleccionado

B.2.8.1. less

1. Add a mime handler for “application/*”?: No

B.2.8.2. locales

1. Se selecciona:

(a) es ES ISO-8859-1 (por defecto)

(b) es ES@euro ISO-8859-15

3Si posteriormente se quieren anadir mas fuentes de instalacion, se usan las herramientas apt,por ejemplo, desde unashell, se teclea (comoroot) apt-cdrom add, para anadir un nuevo CD.



B.2.8.3. ssh

1. Allow SSH protocol 2 only?: Sı

2. Do you want/usr/lib/ssh-keysign to be installed SUID root?: Sı

3. Do you want to run thesshd server?: Sı

B.2.8.4. Impresora PostScript

1. Do you have a PostScript printer?: No

2. Paper size:A4

B.2.8.5. CVS

1. Se deja todo por defecto.

B.2.8.6. gdm

1. Select the desired default display manager:kdm

B.2.8.7. mozilla-browser

1. Do you want to useFreeType 2 support on Mozilla?: Sı

B.2.8.8. Sonido

1. Choose your sound daemon’s dsp wrapper:auto

B.2.8.9. Xserver-common

1. Manage Xserver wrapper configuration file with debconf?: Sı


186 Apendices

B.2.8.10. Xserver-xfree86

1. Manage Xfree4.x server configuration file with debconf?: Sı

(a) Select the desired Xserver driver: ati4

(b) Use kernel framebuffer device interface?: No5

(c) Please select de XKB6 rule set to use?: xfree86

(d) Please select your keyboard model:pc104

(e) Please select your keyboard layout:es

(f) Please select your keyboard variant:ES

(g) Please select your keyboard options:en blanco

(h) Please choose your mouse port:/dev/psaux

(i) Please choose the entry that best describes your mouse:PS/2

(j) Is your monitor a LCD device?:Sı

(k) Please choose a method for selecting your monitor characteristics:Medium

(l) Please select your monitor’s best video mode:1024x768@75Hz

(m) Select the video modes you would like the X server to use:1024x768,800x600, 640x480

(n) Please select your desired default color depth in bits:24

B.2.8.11. dictionary

1. Default dictionary: spanish

B.2.8.12. exim

1. Escoge:(4) local delivery only

2. Mail for “root” redirected to: alberto

4La tarjeta grafica utilizda es una ATI Rage 128Xpert.5Esta opcion suele ponerse como sı, pero con la pantallaTFT con la que se trabaja da proble-

mas, no pudiendose utilizar el entorno grafico.6X KeyBoard.


Apendice C

Instalacion de TimeSys Linux yJavaVM

U na vez que ya se tiene instalada la distribucionDebian, ya se puede pasaral kernelde tiempo real, y los componentes deJava, tanto elSDK, co-mo la maquina virtual de tiempo real y un entorno de desarrollo (IDE),como elNetBeans IDE. A continuacion se exponen los pasos seguidos

sobre una maquina concreta, pero realmente, a partir de aquı, los pasos son muysimilares, de forma casi independiente de la plataforma.

C.1. TimeSys Linux

A partir de esta seccion y de las siguientes, se supone que el usuario con el quese ha entrado al sistema es el superusuario1 (root), y que se esta utilizando

el entorno grafico.

Una vez descargado dewww.timesys.com el fichero con la distribucion 3.1 deTimeSys(tslinux-3-1-x86-bsp214c.tar.bz2), se procede a su descompre-sion. Para ello, se abre el mismo con elArchiver2, y se extrae todo en el directorio/home/alberto.

1ADVERTENCIA: Como superusuario se tiene acceso sin restricciones a todo el sistema. Portanto, si no se esta completamente seguro de lo que se esta haciendo no se debe proseguir, puestoque se corre el riesgo de dejar el sistema inservible, o la perdida de datos.

2Es una aplicacion grafica para manejar ficheros comprimidos en multiples formatos, y empa-quetados contar.

188 Apendices

Figura C.1: Ventana del Archiver.

Una vez hecho esto, se cierra elArchiver, y se abre una consola, se coloca enel directorio/home/alberto/tslinux-3.1, y se ejecuta elscript de instalacion.

Figura C.2: Konsole.

El listado de pantalla completo del proceso de instalacion se muestra a conti-nuacion:

merlin:~# cd /home/alberto/tslinux-3.1/


In�alacion de TimeSys Linux y JavaVM 189

merlin:/home/alberto/tslinux-3.1# ./install

TimeSys provides uniprocessor (UP) and symmetric

multiprocessor (SMP) versions of its software. You must have

an SMP system in order to run the SMP version.

Do you want to install the SMP version of TimeSys Linux? [n]

Installing the UP version of TimeSys Linux.

TimeSys Distributions:

1. TimeSys Linux...............GPL license.

2. TimeSys Linux/RT............TimeSys RT License required.

3. TimeSys Linux/CPU...........TimeSys CPU License required.

4. TimeSys Linux/NET...........TimeSys NET License required.

5. Exit

Select the TimeSys distribution you wish to install or update: 1

Installing TimeSys Linux

No previous installations found.

You may use the default paths or specify new ones.

Default paths:

Source directory................../usr/src/timesys

Binary directory................../usr/local/bin

Library directory................./usr/local/lib

Boot directory..................../boot

Installation paths:

1. Use Defaults

2. Use New

3. Exit

Select installation path: 1

TimeSys Linux 3.1 for ix86 Compatible Host

This CD contains several separate and independent software programs.

TimeSys Linux/Real-Time, TimeSys Linux/CPU and TimeSys Linux/NET are

owned and licensed by TimeSys Corporation under the terms of the TimeSys

Corporation End User License Agreement contained in the file LICENSE on

this CD. TimeSys Linux is owned and licensed by TimeSys Corporation under

the terms of the Free Software Foundation, Inc. GNU General Public

License contained in the file GPL on this CD. Other software programs are


190 Apendices

licensed under the terms of their respective owners’ license agreements

as contained on this CD. All rights not expressly granted are reserved by

the respective Licensors.

Hit <Enter> to continue:

TimeSys Linux 3.1 is based on Linux kernel version 2.4.7. It is

recommended that it be installed on a distribution based on the same

or a similar kernel revision. Installing it on a distribution based

on the 2.2 kernel, e.g. Red Hat 6.2, may cause certain kernel

dependent applications to malfunction. Please see the Release Notes

for more information.

Enter "y" to continue the installation: [n] y

Installing sources to /usr/src/timesys......done

Installing binaries in /usr/local/bin......done

Installing man pages in /usr/local/man......done

Installing kernel image in /boot

Adding LILO entry timesys...

You have multiple or no root= entries in your lilo.conf.

What is your root partition? /dev/hdb1

Warning: Int 0x13 function 8 and function 0x48 return different

head/sector geometries for BIOS drive 0x80

Warning: Int 0x13 function 8 and function 0x48 return different

head/sector geometries for BIOS drive 0x81

Added Debian Linux

Skipping /vmlinuz.old

Added Windows XP *

Added timesys

Installing loadable kernel modules......done

merlin:/home/alberto/tslinux-3.1#

C.2. Java 2 SDK y NetBeans IDE

S e ha optado por la instalacion conjunta, tanto delJava 2 SDK 1.4.2, comodel NetBeans IDE 3.5.1. El entorno de desarrolloNetBeans, no es necesario

para escribir codigo en Java, se podrıa utilizar simplementeEmacs, tal y como seesta haciendo al escribir estas lıneas, antes de compilarlas con LATEX. No obstante,


In�alacion de TimeSys Linux y JavaVM 191

resulta muyutil para el desarrollo de aplicaciones, y como es de libre distribucion,se puede usar sin problemas.

Para la instalacion, tras haber descargado el binario de instalacion correspon-diente (j2sdk-1 4 2-nb-3 5 1-bin-linux.bin) dewww.sun.com, se ejecuta.

Figura C.3: Instalacion de J2SE y NetBeans.

El unico parametro que hay que pasarle es el directorio en que se quiere in-stalar, en este caso/usr/local/j2sdk nb.Y ya estan listos para utilizarse, tanto elNetBeanscomo elSDK.

Figura C.4: NetBeans IDE.


192 Apendices

C.3. Java Real-Time Implementation

F inalmente, hay que instalar la maquina virtual para hacer uso de laEspecificacion de Java para Tiempo Real. Para ello, se descarga de

www.timesys.com el fichero comprimidortsj ri-1.0.tar.gz. Acto seguido,se desempaqueta con elArchiver, en/usr/local.

Figura C.5: Archiver con la Real-Time Java Implementation.

Porultimo, desde una consola, se va al directorio/usr/local/refimp-1.0/pthreadrt,y se ejecuta la herramientamake, para que se copie la librerıalibthreadrt.so.2.0a/usr/lib. Una vez hecho esto, ya esta lista la maquina virtual para ser utilizda.


Apendice D

Planos del diseno paraMecanizacion en Aluminio

A continuacion se incluyen los planos del primer diseno mecanico reali-zado, pensado para su mecanizacion con CN, utilizando como materialbaseduraluminio. Se incluyen, en el CD adjunto, tanto los planos, comolos modelos 3D realizados conSolid Edge v12.

Alberto D. Prieto Löfkrantz Dibujado Comprobado Aprobado

Cotas en milímetros yángulos en grados

Nombre Fecha

HEXÁPODOModelo Aluminio

Título

Archivo: planosAluminio.dft

Escala Hoja 1 de 12

16/12/03Alberto D. Prieto Löfkrantz 16/12/03Alberto D. Prieto Löfkrantz 16/12/03

Número de repeticiones Número de pieza

45

O 3,1 H11

R 7

O11

R 17

O 26,5

O 2

e = 2mm

Hombro-codo superior 16

1:1



Nombre Fecha


Título


Escala Hoja 2 de 12



45

R 7O

3,1H11

e = 2mm

Hombro-codo inferior 26

1:1



Nombre Fecha


Título


Escala Hoja 3 de 12



4248

2

1020

28

2

R0,5

R4

R 4

R 4

R 2

10°

14

2,5

R 1,25

22

10

70°

30

4 R 4

3O

2,5O 3,1 H11

120

e = 2mm

7

Brazo

1:1

36



Nombre Fecha


Título


Escala Hoja 4 de 12


Número de repeticiones Número de piezaHombro izquierdo

AA

CORTE A-A

BB

CORTE B-B

5648

42

204

31

1322

28

R2

7

40

R1

R7 O

3,1H11

15

27

17

10

O 3,1 H11

R 4

4.13

1:1

5R 1

R 4

R 7

R1

O 2,5

R 0,5

22

R2

R 2

27

31

2

R4

O 3,1 H11

10° 10°

20

10 7

3 7

21,87



Nombre Fecha


Título


Escala Hoja 5 de 12



CC

DD

CORTE C-C

CORTE D-D

R 2

R2

R 2 22 13

28

2

27

31R7

40

10°

20

7

15

10°

R 1

O3,1

H11

R7

O3,1

H11

424856

204

5 7 10R 1

R 1

R 4

O 2,5

R 0,5

2

31

34

17

27

1021,87

2

R 4

Hombro derecho 4.23

1:1

O 3,1 H11



Nombre Fecha


Título


Escala Hoja 6 de 12



14

7

6,5

105

37

56

R 4

O 2,5

O 2,5

O 2

O 2

2

22

10

R 1R 1

R 1

22

5

7

2

O 3

Fijación del sensor 56

2:1



Nombre Fecha


Título


Escala Hoja 7 de 12



114

114

42

30°

80

130

10 1321

e = 2mm

40

1010

R5

R 5

E

DETALLE E

42 20

10

3

3

2110

R1

R1

R 0,5

57

F DETALLE F

O 2,5

R 17

O 9

O2

26,5

G DETALLE G

5

1010

O 2,5

O 5

30°

O2,5

Carcasa superior 61

1:2



Nombre Fecha


Título


Escala Hoja 8 de 12



80

130

4211

411

4

R5

R5

20R 0,5

R 1R 1

2

28

70

O2,5

H

DETALLE H

O 3

R 17

I

DETALLE I

105 10

O 2,5

1:2

71

Carcasa inferior

e = 2mm

O2,5 10

10

10



Nombre Fecha


Título


Escala Hoja 9 de 12



20

1022

55

15

2

R 2

R 2

10

10

R 5

O 2,5

15

20

Soporte lateral 86

1:1



Nombre Fecha


Título


Escala Hoja 10 de 12



28

3 7

42

25

10 10

R 0,5

J

DETALLE J

R 5

R 4 3

75

R 5

20

O2,5

20

55 R 4

50

10 10

10R

5

O2,5

7

802

251

17

2531

55

Soporte para la garra 91

1:2



Nombre Fecha


Título





38,1

14,8

44

9,6

30

R 4

O 2,52

2

R 2

38

26,5

R 17O 9R 5

2

101

1:1

Soporte para el sónar

20

44

O 2



Nombre Fecha


Título





1:2

Montaje

Apendice E

Planos del diseno para fabricacionen PVC

A continuacion se incluyen los planos del segundo diseno mecanico reali-zado, pensado para su implementacion exlusivamente a partir de plan-chas dePVC. Se incluyen, en el CD adjunto, tanto los planos, como losmodelos 3D realizados conSolid Edge v12.



Nombre Fecha

HEXÁPODOModelo PVC

Título

Archivo: planosPVC.dft

Escala Hoja 1 de 12


Número de repeticiones Número de piezaHombro-codo superior 1

6

1:1

45

O 1,4O 21

R 17

O11

R 7

O 3

e = 3mm



Nombre Fecha

HEXÁPODOModelo PVC

Título


Escala Hoja 2 de 12


Número de repeticiones Número de piezaHombro-codo inferior 2

6

1:1

45

R 7 O3

e = 3mm



Nombre Fecha

HEXÁPODOModelo PVC

Título


Escala Hoja 3 de 12


Número de repeticiones Número de piezaBrazo

1:1

36

10

33

R 6 O2,5

O 2,5

R 6

R 6

15

3

7

42

R1

21

3

2519,5

R 3

100

e = 3mm

O3

R1,2

5

21



Nombre Fecha

HEXÁPODOModelo PVC

Título


Escala Hoja 4 de 12


Número de repeticiones Número de piezaHombro 4

6

1:1

e = 3mm

35 4813

5O

3

O 3

O 2,5 O 2,5

R7

R7



Nombre Fecha

HEXÁPODOModelo PVC

Título


Escala Hoja 5 de 12


Número de repeticiones Número de piezaFijación del sensor 5

6

2:1

3315

22

6,5

10 O2,5

O1,4

10,5

120°

7

26

e = 3mm



Nombre Fecha

HEXÁPODOModelo PVC

Título


Escala Hoja 6 de 12


Número de repeticiones Número de piezaCarcasa superior 6

1

1:2

80

80

2316

4211

411

417

15

R 5

30°

6

3

A

DETALLE A

6

15

O6

R 17

O 9

O1,4

O21

R5

6

10

B

DETALLE B

10

21

10

3

O 2,542 21

6

O6

O 5

130

R 5

e = 3mm



Nombre Fecha

HEXÁPODOModelo PVC

Título


Escala Hoja 7 de 12



1:2

71

Carcasa inferior

4211

411

417

80 15

6

3

R 5

80

30°

21334557

3 930

6 10

130

R 5

R 5O 3

R 17

e = 3mm



Nombre Fecha

HEXÁPODOModelo PVC

Título


Escala Hoja 8 de 12


Número de repeticiones Número de piezaSoporte lateral 8

4

1:1

e = 3mm

10

40

5078

C

DETALLE C

65

3R 4

D

DETALLE D

135°

R 0,75

6,25



Nombre Fecha

HEXÁPODOModelo PVC

Título


Escala Hoja 9 de 12


Número de repeticiones Número de piezaSoporte para la garra 9

1

1:1

6R 2

R 6

6

99

21

3

15

27

61114

2213

2041

R 3

942

1010

3O

2,5

R 6

R 6

R 6

e = 3mm



Nombre Fecha

HEXÁPODOModelo PVC

Título




Número de repeticiones Número de pieza 10

1

1:1

Refuerzo trasero

R 21,75

R 4

3

611

80 15

R 4

78 50

e = 3mm



Nombre Fecha

HEXÁPODOModelo PVC

Título




Número de repeticiones Número de piezaCuña 11

21

5:1

6

11

6 5 45R

1,5

R 1

e = 3mm



Nombre Fecha

HEXÁPODOModelo PVC

Título





1:2

Montaje

Referencias

[1] AVR Assembler Help.

[2] Free Software Foundation, www.fsf.org.

[3] Linux Documentation Project (LDP), www.ldp.org.

[4] Proyecto GNU, www.gnu.org.

[5] Xfig User Manual version 3.2.3d, May 29 2001.

[6] 3D-MV, 3D-MV: 3 Dimensional Moving Vehicle, http://www.walking-machine.com, 1999-. . . .

[7] Amos Albert, Jens Hofschulte, Olaf Schermeier, Friedhelm Schewe, andRoger Strasser,BARt-UH, http://www.biped.irt.uni-hannover.de, 1999.

[8] Prof. Dr. Karsten Berns, The Walking Machine Catalogue,http://www.walking-machines.org, http://agrosy.informatik.uni-kl.de/wmc/,2004.

[9] G. Bessonnet, B. Espiau, P. Sardain, R. Pissard-Gibollet, H. Math-ieu, P. Digiacomo, C. Canudas, and P. Junqua,BIPOP Project,http://www.inrialpes.fr/bip/, 1995-1999.

[10] Greg Bollella and James Goslin,The Real-Time Specification for Java, IEEEComputer (2000), 47–54.

[11] Andrew Borg and Andy Wellings,A Real-Time RMI Framework for theRTSJ, http://www.it.uc3m.es/drequiem/Docs/RTRMI/R-Borg-2003.pdf, De-partment of Computer Science, The University Of York, UK, 2003.

[12] Professor Martin Buehler, Mojtaba Ahmadi, Pedro Gregorio, Hamid Rad,and Joey Mennitto,ARL Monopod II, http://www.cim.mcgill.ca/ arlweb/,1993-1997.

198 Apendices

[13] Alan Burns and Andy Wellings,Real-Time Systems and Programming Lan-guages, Third Edition.

[14] James M. Conrad,Stiquito Home Page, http://www.stiquito.com/, 1994-2004.

[15] Atmel Corporation, AVR Assembler User Guide, 1998,http://www.atmel.com.

[16] , ATMEL AVR AT90S8515 Microcontroler Datasheet, 2001,http://www.atmel.com.

[17] TimeSys Corporation,The Concise Handbook Of Linux for Embedded Real-Time Systems v1.1, Pittsburg, PA, 2002, www.timesys.com.

[18] , The Concise Handbook Of Real-Time Systems v1.3, Pittsburg, PA,2002, www.timesys.com.

[19] , Getting Started with TimeSys Linux on an X86 or Compatible, Pitts-burg, PA, 2002, www.timesys.com.

[20] , TimeSys Linux User’s Manual, Pittsburg, PA, 2002,www.timesys.com.

[21] George Coulouris, Jean Dollimore, and Tim Kindberg,Sistemas Distribui-dos: Conceptos y Diseno, 3rd ed., Addison Wesley, 2001.

[22] Ph. D. Andrew Davidson, Java Graphics and Gaming,http://fivedots.coe.psu.ac.th/ ad/jg/index.html, Asian Institute of Tech-nology, 2004.

[23] Juan Antonio de la Puente Alfaro,Transparencias sobre Sistemas de TiempoReal, http://polaris.dit.upm.es/ jpuente/strl/transparencias/.

[24] Manuel Jesus Bellido Dıaz, Jorge Juan Chico, and Paulino Ruiz de Clavi-jo Vazquez,Curso Linux Avanzado: Administracion y Servidores, 2002, De-partamento de Tecnologıa Electronica, Universidad de Sevilla.

[25] EDS,Solid Edge v12 html help, 2002.

[26] Manalapan High School Electronics, Ambassador project,http://cjrobotics.org/, 1999.


Planos del diseno para para fabricacion en PVC 199

[27] The Real-Time for Java Expert Group: Greg Bollella, Ben Brosgol, PeterDibble, Steve Furr, James Gosling, David Hardin, Mark Turnbull, The Ref-erence Implementation Team: Doug Locke Rudy Belliardi, Scott Robbins,Pratik Solanki, and Dionisio de Niz,The Real-Time Specification for Java,Addison-Wesley, http://www.rtj.org, 2000.

[28] J. C. Habumuremyi and I. Doroftei, Amru Project,http://mecatron.rma.ac.be/legged.html, 1988-. . . .

[29] Jaap Havinga,BiPed, http://www.havingasoftware.nl/robots/BiPed/BiPed.htm,2000-. . . .

[30] Cay S. Horstman and Gary Cornell,Java 2. Caracterısticas avanzadas,vol. 2, Pearson Prentice Hall, 2003.

[31] , Java 2. Fundamentos, vol. 1, Pearson Prentice Hall, 2003.

[32] FZI Forschungszentrum Informatik, Projekt AirBug,http://www.fzi.de/ids/projekte.php?id=19, 2000-. . . .

[33] Donald Lewine,POSIX Programmer’s Guide: Writing Portable UNIX Pro-grams, 1st ed., O’Reilly, 1991.

[34] Bill Lewis and Daniel J. Berg,Programacion Multithread en Java, PearsonPrentice Hall, 2003.

[35] Lynxmotion,Polypod, http://www.lynxmotion.com/, 2004.

[36] EMCO MAIER, Descripcion del software EMCO WinNC SINUMERIK810/820 M version de software 3.20, 1996.

[37] , Descripcion de la maquina EMCO PC MILL 125 Maquina fresado-ra, 1998.

[38] Maxim, MAX220-MAX249 Datasheet, 2000, http://www.maxim-ic.com.

[39] Thomas Nau,PCB: an interactive printed circuit board layout systemforX11, 1997.

[40] , PCB-1.7.1.ALPHA command reference, 1998.

[41] Frank Nickols,Baby beetle, http://www.ntu.edu.sg/home/mfnickols/home.htm,2000-. . . .

[42] Members of the GIMP Documentation Project,GIMP User Manual.


200 Apendices

[43] Carmen Baena Oliva, Manuel Jesus Bellido Dıaz, Jorge Juan Chico, andMarıa del Pilar Parra Fernandez,Curso Debian GNU/Linux, 2001, Departa-mento de Tecnologıa Electronica, Universidad de Sevilla.

[44] Parallax, Devantech SRF04 Ultrasonic Range Finder, september 2002,http://www.parallaxinc.com.

[45] Bruce Perens, Sven Rudolph, Igor Grobman, James Treacy, andAdam Di Carlo, Instalacion de Debian GNU/Linux 3.0 para Intel x86,http://www.debian.org/releases/stable/i386/install, december 2002.

[46] Java Community Process,JSR 50: Distributed Real-Time Specification,http://jcp.org/en/jsr/detail?id=050, 2004.

[47] BEAM Robotics,AVRIL Project, http://gene.solarbotics.net, 2003.

[48] Alessandro Rubini and Jonathan Corbet,Linux Device Drivers, 2nd ed.,O’Reilly, 2001.

[49] Syed M. Sarwar, Robert Koretsky, and Syed A. Sarwar,El libro de UNIX,Addison Wesley, 2002.

[50] National Semiconductor,LM340/LM78XX Series 3-Terminal Positive Regu-lators, april 2003, http://www.national.com.

[51] Sun Microsystems,Java 3D API Specification version 1.1.2, 2001.

[52] , Java 2 SDK Documentation version 1.4.2, 2003.

[53] Tacket and Gunter,Utilizando Linux, Prentice Hall, 1997.

[54] Matt Welsh and Lar Kaufman,Running LINUX, 1st ed., O’Reilly, february1995.

[55] Dr. W. Whittaker, Dr. R. Simmons, and Dr. E. Krotkov,Ambler, http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/epk/www/home.html, 1988-1992.

[56] WinUniSoft,WinUniSoft html help, 2002.

[57] Kan Yoneda, AQUAROBO 1, http://www-robot.mes.titech.ac.jp/staff/yoneda/yoneda.html.


Java y Tiempo Real RTSJ Aplicada a un Robot...

Documents

Transcript of Java y Tiempo Real RTSJ Aplicada a un Robot...