robot automóvil autónomo - telematica.utfsm.cl · luego, en el ámbito mecánico del robot se...

Robot automóvil

autónomo

//Integrantes

Lilian Rosales

201330006-5

Katrina Stamulis

201330003-0

Matko Milovic

201330007-3

Felipe Hurtado

201330010-3

Juan Carlos Céspedes

201330004-9

//Asignatura

Introducción a la Ingeniería

//Fecha

11 de septiembre de 2013

Tiguer.bot

v.Alpha


1. Introducción

En el siguiente trabajo mostraremos el proyecto realizado en el ramo de Introducción a la

Ingeniería, por cierto primer desafío de ingeniería para nosotros, en el cual se nos pedía

realizar un proyecto con la Raspberry Pi.

En este contexto, nos juntamos a discutir la lluvia de ideas acerca de que podría ser nuestro

proyecto. Así llegamos a la conclusión de que lo mejor sería hacer un robot que se moviera

y que si es que detectaba un objeto debía girar para de esta manera esquivarlo,

nombrándolo oficialmente en ese momento como “Tiguer.bot”. Esta idea se nos ocurre

también gracias a la experiencia anterior de tres de los integrantes del grupo al realizar un

proyecto similar pero solo con Arduino.

Aquí viene el desafío del proyecto el cual es que la Raspberry Pi sea quien posea la

“inteligencia” para que el robot sepa si continuar su movimiento recto o girar, esto

incluyendo también el uso de un Arduino, pero solo cumpliendo la función de ejecutar las

ordenes de Raspberry Pi, y debido a esto fue que se debió cambiar mucho el proyecto

durante el proceso de construcción con respecto a lo pensado en un inicio para obtener el

resultado planteado.

Todo lo anterior se explicará a modo de tutorial con mayores detalles en las próximas

páginas, además de mostrar una breve descripción de los materiales utilizados y la

metodología del trabajo.

2. Objetivos

2.1. Objetivo General

Presentar un proyecto libre, relacionado al área Telemática, sobre la plataforma Raspberry

Pi, escrito en el lenguaje de programación C.

2.2. Objetivos Específicos

-Idear un proyecto que desafíe nuestras capacidades.

-Utilizar una plataforma de hardware levemente limitada, en este caso, Raspberry Pi

-Escribir el código principal en C

-Generar comunicación bidireccional entre una tarjeta Arduino y Raspberry Pi

-Compactar el hardware utilizado al menor tamaño posible y que sea funcional

-Adquirir nuevos conocimientos, tanto en el área del software, como en la electrónica de la que haremos uso.

Tiguer.bot

v.Alpha


3. Metodología

3.1. Hardware utilizado:

Raspberry Pi

Arduino UNO

Sensor de ultrasonido SRF04

Servomotor HS-322

Motor DC

LED

Transistor NP2222

El desafío de este trabajo fue utilizar Raspberry Pi como controlador principal, por lo que

toda la “inteligencia” del robot, el código principal, se encuentra en la RasPi, y la Arduino

queda relegada a una ejecutora de lo que RasPi ordene. Estas tarjetas estarán conectadas

vía puerto serial con un cable micro-USB – USB-A. Desde la Arduino se controla el

servomotor y el sensor de ultrasonido, mientras que el RasPi controlará el motor DC y un

par de LEDs.

3.2. Software utilizado:

El software utilizado para este proyecto es el lenguaje de programación C, junto al lenguaje

propio de Arduino, que resulta casi idéntico a C. Estos lenguajes son utilizados a bajo nivel,

especialmente el de Arduino. La Raspberry Pi fue cargada con librerías externas a las de

estándar ANSI-C. Además de lo mencionado, no se hizo uso de otro software.

3.3. Proceso

-Planteamiento de un objetivo

-Abstracción de su funcionamiento

-Trabajo teórico de procesos y relación con el medio

-Contrastación de lo ideal con lo posible

-Ajustes a la teoría, para poder llevarla a la realidad

-Realización de un prototipo funcional

-Perfeccionar el prototipo para acércalo al ideal inicial

Tiguer.bot

v.Alpha


3.4. Evolución del proyecto

Como fue mencionado, el proyecto nace de un desafío, al ser un proyecto libre, pero de

temática referida a la carrera, como grupo tuvimos que elegir un proyecto en el cual

invertir el tiempo otorgado, y que nos reportará la mayor “rentabilidad”, tanto en ámbito

intelectual, como académico. Y con tal condicionante, de entre las múltiples ideas que

barajamos, trabajamos con un proyecto en el que ya habíamos tenido experiencia, un

robot automóvil que detecta distancias y se aleja al detectar un objeto cercano. En esa

ocasión, trabajamos sólo con Arduino, a diferencia del presente, en el que debíamos utilizar

RPi.

Ya teniendo nuestro objetivo en mente y sus funciones, correspondía crear el algoritmo

bajo el cual se moviera el código del robot, y que fuese la inteligencia con la que contaría el

robot. Al tener ya pensado que el robot sólo reconocería distancias frente a él en el mundo

real, nos encontrábamos en un sistema que procesa un universo tridimensional, con una

mirada de una dimensión. Ese particular punto aligeraba la potencia de procesamiento

requerido, y a la vez, los datos almacenables posibles disminuían, junto a la limitada

capacidad de movimientos posibles, cuatro. Lo anterior contribuyó a un Algoritmo más

avanzado que con el que se presenta Tiguer.bot v.2, así nace v.1, el cual es el objetivo a

conseguir en un eventual v.3.

El algoritmo por sí solo no funciona, por lo que nos tocaba respaldarlo con hardware

compatible, capaz de ejecutar acciones o entregar información correspondiente. Este

punto no ha cambiado mucho a lo largo del proyecto, el motor DC de v.2, en v.1

correspondía a otro servomotor. Se recomienda ver la sección de hardware.

Establecidos el algoritmo y el hardware que utilizaríamos, faltaba saber con qué software

tendríamos que trabajar. Para el código teníamos la opción de trabajar con python o con

lenguaje C, ambos tenían librerías para los pines GPIO, con funcionalidades similares,

python se distinguía por ser más simple en algunas reglas de sintaxis, y ser más familiar a

nuestros ojos, además de que ya sabemos cómo ejecutar ciertos procesos sobre archivos

de texto plano. C, por otra parte, tiene la ventaja que, al ser compilado antes de su

ejecución, es más rápido.

Teniendo pensado como queríamos que operara el robot, y el hardware que utilizaríamos,

se debía administrar los componentes, eficazmente, para que las acciones se ejecutaran lo

más rápido posible y la información se trasladara sin retrasos, y eficientemente, evitando

sobrecargar el robot con baterías, pesos y conexiones innecesarias.

Tiguer.bot

v.Alpha


La búsqueda de información para el primer prototipo consistió en las mencionadas librerías

para los pines GPIO. Y con toda la información obtenida, planes generados y sketches del

robot, se forma el prototipo Tiguer.bot v.1

El problema surge luego de esto, cuando al tener que llevar la idea al mundo real, no todos

los componentes pueden ser conseguidos y algunos puntos no son tan simples como

parecían. Es en ese momento en el que v.1 debió ser reestructurado para adaptarse a la

realidad en la que se desenvuelve, y en aquella en que tratamos de crear. El principal

problema fue la comunicación entre ambas tarjetas, ya que la comunicación vía GPIO era

bastante complicada, ya que la emisión de información requería, en momentos, de más de

un pin, que ambas tarjetas estuvieran en lectura y escritura de manera coordinada, y

resolver los problemas de voltaje entre ambos tipos de pines (RPi trabaja a 3v, Arduino a

5v). Luego, en el ámbito mecánico del robot se presentó la dificultad de no conseguir

servomotores de 360°, sino que contábamos sólo con aquellos de 180° y finalmente, el

modelo del sensor, no era un Ping, sino que otro modelo. Nuestra respuesta es estos

problemas fue modificar la mecánica del robot, conservando un servo 180, que manejase la

dirección, y un motor DC que entregara movimiento al sistema completo. El caso del sensor

fue más sencillo, luego de determinar el modelo en cuestión, bastó con modificar el código

del sensor ping para adaptarlo a este modelo.

El punto principal que diferencia v.1 de v.2, es la comunicación entre tarjetas, en v.1

habíamos pensado en comunicar vía GPIO, pero tras la evidenciación de los problemas ya

mencionados, optamos por buscar un medio diferente por el cual enviar y recibir datos,

resultando en la utilización del puerto serial USB. Buscando documentación, encontramos

el trabajo del Dr. Juan González Gómez, que contenía librerías escritas en C para la

comunicación entre una máquina GNU/Linux con un dispositivo capaz de comunicar de ese

modo. Tal sistema de comunicación cambiaba repentinamente el panorama al que nos

enfrentábamos, por las características de esta comunicación. Fue necesario hacer ciertas

modificaciones al código, lo que se explica dentro de la sección tutorial. Ante tales cambios,

con el sentido de llegar a nuestro objetivo, un robot automóvil autónomo, y en función del

tiempo, decidimos modificar el algoritmo, aligerando los procesos requeridos, acotando la

inteligencia del robot a sólo dos situaciones.

Teniendo el nuevo algoritmo y establecida la posibilidad de comunicación serial, más lo

aprendido en el proceso, de genera el Prototipo Tiguer.bot v.2. Es tras estolo que el

Tutorial del siguiente punto explica. Luego, modificamos el código de comunicación,

adaptándolo a nuestras necesidades y agregando el código requerido para que el robot

funciones como determinamos. Una vez mezclado todo, comienza el diseño industrial-

Tiguer.bot

v.Alpha


mecánico del robot para lograr incluir todo en el menor espacio posible. Una vez

ensamblado todo, podemos decir que estamos en presencia de Tiguer.bot Alpha

4. Componentes

Raspberry Pi modelo B

Es un minicomputador de bajo costo con

multiples utilidades, que posee una RAM de

512 MB y CPU de 700 Mhz (se le puede hacer

overclocking). Las ventajas de utilizar

Raspberry pi residen en su conectividad,

pudiendo transmitir información via internet,

usb, etc.

Arduino Uno R3 Atmega328

El Arduino es una plataforma computacional

física open-source basada en una simple

tarjeta de I/O y un entorno de desarrollo que

implementa el lenguaje Processing/Wiring. El

Arduino Uno R3 puede ser utilizado para

desarrollar objetos interactivos o puede ser

conectado a software de tu computadora

(por ejemplo, Flash, Processing, MaxMSP).

Sensor ultrasonido SRF-04

Tiguer.bot

v.Alpha


Es un sensor de distancias por ultrasonidos

capaz de detectar objetos y calcular la

distancia a la que se encuentra en un rango

de 3 a 300 cm. Su funcionalidad, envía un

pulso de arranque y mide la anchura del

pulso de retorno. Muy útil por su gran

precisión, pequeño tamaño y bajo costo

Servo Motor Hitec Hs-5745MG

Servo Motor programable de 3 polos que

requiere pulsos entre 3 y 5 volts. Posee

entrada y salida digital y es capaz de girar en

180°

Motor DC 5V

Motor de corriente continua de 5V que

utilizamos para dar potencia al robot.

Tiguer.bot

v.Alpha


5. Tutorial

5.1. En busca de la inteligencia

El primer paso es conocer el algoritmo que se quiere utilizar, el cual será la

¨inteligencia¨ que tendrá el robot:

La imagen superior plasma la forma en que debe funcionar el programa. El

algoritmo es un tanto básico, pero se le pueden anexar funcionalidades, aprovechando las

ventajas de conectividad y de cómputo de Raspberry Pi. De esta manera, se crea un sistema

en que arduino solo se preocupa de ejecutar las órdenes emitidas por la Raspberry Pi. De

esta manera, la Raspberry es quien se encarga de procesar las información recibida desde

Arduino o datos ingresados manualmente por el usuario, por tanto, el algoritmo presenta

la posibilidad de ejecutar un modo automático, manual y los dos modos en paralelo; esto

sería el modo semi-automático, en el cual, el robot se protege a una distancia corta

evadiendo la ejecución de la orden ingresada y alejándose del potencial peligro, en caso de

estar lejos es capaz de ejecutar las acciones indicadas.

5.2. El viaje al mundo físico

Teniendo ya el algoritmo pensado y por tanto orientados a lo que queremos que el robot

haga, podemos proceder a intentar llevarlo al mundo real, para tal labor debemos listar los

dispositivos y sensores que nuestro proyecto requiere, como se pudo ver en el punto 4.

Una vez conseguidos se debe determinar la manera más eficaz y eficiente de conectarlos y

administrarlos. Para lo cual determinamos lo siguiente:

Tiguer.bot

v.Alpha


La razon tras estas conexiones es la facilidad con la que Arduino controla el

servomotor y el sensor SRF04. La batería se conecta con Raspberry Pi para alimentarla, y

dado que la conexión entre Arduino y Raspberry es por USB, esa misma alimetación se

suministra a Arduino. En el caso del motor DC determinamos que era mejor suministrarlo a

través de una bateria externa y controlar su flujo a través de un transistor.

Este diagrama puede ser expandido a medida que se expande el algoritmo.

5.3. Programando

Ha llegado el momento de hacer que estas conexiones tengan un sentido y cumplan su

objetivo, es decir traducir nuestro algoritmo a un código ejecutable por una máquina

digital. El lenguaje elegido para escribir este código fue el lenguaje de programacion C, ya

que se encontraba dentro de nuestros fines académicos utilizar dicho lenguaje.

El principal problema a la hora de escribir este código, no fue programar las acciones

ejecutables, sino, la comunicación serial entre ambas tarjetas. Al principio habiamos

pensado en comunicar vía pines del GPIO de Raspberry Pi a Arduino, sin embargo, tal

solución presenta más inconvenientes al tener que ser una comunicación sincrona. La

solución a la que llegamos y que resulta mucho más simple y efectiva fue utilizar el canal

USB que permite una comunicación bi-direccional asincrona, además de alimentar

electricamente el Arduino. Aquí es cuando aparece una de las ventajas, el hecho de que el

sistema operativo sea una distribución GNU/Linux (Raspbian), nos permite obtener

numerosas documentaciones de funcionalidades trasnersales a esta familia de sistemas, en

particular la que nos intereso y que juega un papel central en la ejecución de nuestro

proyecto fue un código de comunicación serial1.

1 - Linux and the serial port. Dr. Juan González Gómez. Enero 2009

3,7 v

Tiguer.bot

v.Alpha


El trabajo liberado bajo GPL incluye todas las librerias necesarias para activar o desactivar el

puerto serial y para enviar y recibir información. Nosotros modificamos parte del código,

específicamente el ejemplo de una mini-terminal.

Por otro lado en Arduino utilizams tres códigos ejemplo del IDE, blink, knob y Ping. En el

caso de Ping tuvimos que adaptarlo al modelo de sensor que teniamos. Luego de unir todo

dentro de un mismo código y cambiar el tipo de la variable respuesta del sensor, de un

“long” a un “byte”. Ese tipo permite 256 niveles de proximidad, siendo representables

como los caracteres de la tabla ASCII.

La comunicación serial efectuada esta pensada para ir byte a byte, es decir, esta pensada

en “char”, es por tal razón que modificamos la salida serial con la que se entregaba la

distancia, puesto que es mucho más fácil analizarlo por byte que juntar todos los bytes

requeridos para una variable “long” y luego procesarlas para tener su significado. El margen

de distancia con el que trabajamos era suficientemente amplio como para permitir un

pequeño margen de error en la entrega de distancia, el sensor mide hasta 300 cm.,

mientras que el byte nos otorga los 256 niveles en los cuales se repartirá la distancia

máxima.

El espectro de acción del robot es de infinito hasta “00011111”, que es la representación

binaria con la cual se procesa las distancias en RPi.

5.4. Descargando el código

Para proceder, se debe descargar el IDE de Arduino para programarlo y las librerías del

trabajo del Dr. Juan González Gómez.

Comenzaremos explicando cómo escribir el código para Arduino, se deben declarar donde

estarán los pines, esto es si son salidas o entradas e iniciar la comunicación serial.

Activar el sensor y obtener la respuesta de la distancia, esta enviarla por el puerto serial y

leer el puerto en busca de comunicación de entrada, llámese orden a ejecutar. Luego de

eso viene la ejecución.

Mientras que en RPi deberemos descargar el código ejecutando sudo wget

www.iearobotics.com/wiki/images/4/4b/Serial-1.0-bin.tar.gz y la libreria Wiring Pi

ejecutando git clone git://git.drogon.net/WiringPi

Luego de eso lo que haremos es descomprimir y desempaquetar el primer archivo

descargado, con tar –xvf Serial-1.0-tar.gz ; ingresar al directorio creado y dentro al sub-

directorio term_ex aquí debemos modificar el archivo term.c para adaptarlo al algoritmo

http://www.iearobotics.com/wiki/images/4/4b/Serial-1.0-bin.tar.gz

Tiguer.bot

v.Alpha


que hemos generado. En nuestro caso, modificamos el código para que al ejecutarlo

pregunte al usuario si desea un control manual, semi-automático o automático.

Como se podrá ver más adelante en la documentación lo que hacemos dentro del código

es adaptar los procesos de lectura, que en el caso manual se omiten y en el semi-

automático solo tienen relevancia en la eventualidad de estar en una distancia corta. En el

caso automático, la distancia que se lea, implica una orden asociada a la categoría en que

se encuentra, es decir, si es distancia larga, el vehículo se autoriza a continuar su trayecto.

En caso contrario RPi ordena el cambio de ruta. En el caso semi-automático solo se toma en

cuenta la distancia cuando es corta y es la única orden autónoma que se emite. En el

directorio padre ejecutar make.

5.5. Montaje

Para proceder a crear el auto es necesario darle una estructura que lo soporte y que

idealmente sea ligera, resistente y optimizar al mínimo el espacio requerido. Se puede

utilizar una tabla de poco espesor y resistencia óptima, como sugerencia.

Se debe realizar un esquema de montaje con el fin de acotar el espacio de uso y así tener

presente los pasos para realizar el armado en sí.

Figura 1: Este es un modelo de la base para el auto, donde los rectángulos grises

representan espacios vacíos donde se debe recortar para alivianar el peso de la tabla y

pasar cables, entre otros usos.

Tiguer.bot

v.Alpha


Figura 2: vista horizontal.

Esto es lo que denominamos la versión v.alpha de Tiguer.bot.

Tiguer.bot

v.Alpha


6. Anexo (Galería de imágenes)

Tiguer.bot

v.Alpha


Tiguer.bot

v.Alpha


7. Otros

7.1 Ventajas/Desventajas

Ventajas

Responde al entorno:

1. Si encuentra un obstáculo a cierta distancia es capaz de esquivarlo.

2. Si no encuentra obstáculo alguno, sigue su ruta en línea recta.

Podrían implementarse un número de Tiguer.bots; esto con el fin de crear una

“manada”, la cual sea capaz de no chocar entre sí, imitando el comportamiento

básico de un tigre cachorro.

Teniendo en cuenta un motor DC con la fuerza de torque suficiente para mover

el cuerpo del robot, puede llegar a ser bastante veloz y cumplir con su función

eficazmente.

Desventajas

El proyecto actualmente tiene un retraso de 5 a 8 segundos entre el instante de

recibir la señal del sensor y en responder ante éste, lo cual entorpece bastante

el comportamiento adecuado de Tiguer.bot.

Al desarrollar el proyecto no se habilitan las múltiples funcionalidades de RPi;

por lo cual se pierde bastante potencial de ésta.

El costo de construir un Tiguer.bot es bastante alto, cerca de unos 88 USD

debido a los diversos dispositivos que se utilizan para su correcto

funcionamiento, además del trabajo de programación, diseño del robot y

materiales de montaje.

La rentabilidad como negocio es nula, ya que el proyecto fue ideado

enfocándose en los ámbitos académicos.

Al tener fines académicos, el fondo de inversión para un futuro mejoramiento

del proyecto se ve bastante limitado; solo si se cambia el enfoque a un modelo

más “comerciable” podría darse el propósito de mantener el proyecto de una

manera un poco más estable.

La poca funcionalidad de Tiguer.bot, ya que fue pensado solo con el fin de no

colisionar con objetos, manteniendo una distancia mínima predefinida.

7.2. Rentabilidad

El costo unitario de cada bot, fue estimado en 88 USD, un precio bastante elevado para un

dispositivo de características tan simples. Si bien se puede reducir el precio gracias a la

fabricación en masa y en serie, tal procedimiento sólo conllevaría a un descenso de los

costos de manufactura, llámese el recurso humano. La compra en masa de materiales y

Tiguer.bot

v.Alpha


componentes, aunque es posible, no genera una caída significativa, los primeros, porque su

aporte en el costo final es menor, mientras que el segundo no permite un mayor descenso

en su costo. Finalmente, el valor del producto no justifica el potencial precio con el que

saldría al mercado. Es esta la razón por la cual el proyecto no es comercialmente viable y

sus objetivos son netamente académicos.

8. Documentación 8.1. Código principal en RPi

#include <termios.h>

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include "serial.h"

#include "console_io.h"

//------------------

//-- CONSTANTS

//------------------

//--TIMEOUT in micro-sec

#define TIMEOUT 10000

//--------------------

//-- Global variables

//--------------------

//-- Serial port descriptor

int serial_fd;

/**************************************************************************/

/* Main loop. When the user press a key, it is sent to the serial port. */

/* When a character is received from the serial port, it is printed on */

/* the screen */

/**************************************************************************/

void term(void)

{

char c[1];

char rec[1];

int n;

//-- Main loop

do {

//-- Poll the serial port. A character has been received?

n=serial_read(serial_fd,rec,1,TIMEOUT);

//-- If so, print it on the screen!!

Tiguer.bot

v.Alpha


if (n==1) {

if(rec[0]<'1')

serial_send(serial_fd,"G",1);

else

serial_send(serial_fd,"F",1);

fflush(stdout);

}

//-- Repeat until the user press the ESC key

} while (c[0]!=ESC);

};

void termm(void)

{

char c[1];

char rec[1];

int n;

//-- Main loop

do {

//-- if there is a key pressed by the user

if (console_io_kbhit()) {

//-- Read the character

c[0]=console_io_getch();

//-- Send the character to the serial port, if different from ESC

if (c[0]!=ESC)

serial_send(serial_fd,c,1);

}



}

void terms(void)

{

char c[1];

char rec[1];

int n;

//-- Main loop

do {

//-- Poll the serial port. A character has been received?

n=serial_read(serial_fd,rec,1,TIMEOUT);

//-- If so, print it on the screen!!

if (n==1) {

if(rec[0]<'1')

serial_send(serial_fd,"G",1);

else{

Tiguer.bot

v.Alpha


//-- if there is a key pressed by the user

if (console_io_kbhit()) {

//-- Read the character

c[0]=console_io_getch();

//-- Send the character to the serial port, if different from ESC

if (c[0]!=ESC)

serial_send(serial_fd,c,1);

}

fflush(stdout);



}

/**********************/

/* MAIN PROGRAM */

/**********************/

int main (int argc, char* argv[])

{

char mode,

//-- Check if the serial device name is given

if (argc<2) {

printf ("No serial device name is given\n");

exit(0);

}

//-- Open the serial port

serial_fd=serial_open(argv[1],B9600);

//-- Error checking

if (serial_fd==-1) {

printf ("Error opening the serial device: %s\n",argv[1]);

perror("OPEN");

exit(0);

}

//-- Configure the console for using the keyboard

console_io_open();

//--Ask the mode

printf("What is the mode you want to use?(M,S,A)\n");

scanf("%c",&mode);

//-- Execute the main loop

printf ("Press the ESC key to quit\n");

if(mode == "A")

term();

if(mode == "M")

termm();

Tiguer.bot

v.Alpha


if(mode == "S")

terms();

//-- Restore the previous console configuration

console_io_close();

//-- Close the serial port

serial_close(serial_fd);

return 0;

}

8.2. Código en Arduino

#include <Servo.h> //Incluir la libreria se servomotores

const int Trig = 7; //Declaración e inicialización de los pines con un nombre representativo

const int Echo = 5;

const int LED = 4;

Servo servo; //declaración del servomotor

void setup(){

pinMode(Trig, OUTPUT);//estado de los pines (envío o recepción)

pinMode(Echo, INPUT);

pinMode(LED, OUTPUT);

Serial.begin(9600); //inicialización de la comunicación serial

servo.attach(9); //inicialización del pin del servomotor

}

void loop(){

long duration, cm; //declaración de variables que utilizaremos luego

digitalWrite(Trig,LOW); //envío de una señal de ultrasonido

delayMicroseconds(2);

digitalWrite(Trig,HIGH);

delayMicroseconds(5);

digitalWrite(Trig,LOW);

duration = pulseIn(Echo, HIGH); //medición de la duración de entrada en High,

cm = microsecondsToCentimeters(duration); //conversion de tiempo a distancia

Serial.write(cm); //envío de la distancia

delay(100); // espacio de muestreo

if(Serial.available()){ //busqueda de una órden en el puerto serial

char c = Serial.read();

if(c == 'G'){ //orden girar

digitalWrite(LED,HIGH);

servo.write(45);

}

Tiguer.bot

v.Alpha


else if(c == 'F'){ //orden seguir adelante

digitalWrite(LED,LOW);

servo.write(90);

}

}

}

byte microsecondsToCentimeters(long microseconds){

return microseconds / 29 / 2;

}

9. Conclusión

En el transcurso de este trabajo además de todo lo aplicado a la Raspberry Pi y al hecho de

que nos sirvió para poner en practica nuestro aprendizaje en programación en C, tuvimos la

posibilidad de aplicar y/o aprender más acerca de la electrónica relacionada con todas las

conexiones necesarias para lograr tener un Arduino y una Raspberry Pi funcionando juntas

con la energía suficiente y también para colocar los respectivos motores conectados para

coordinar su funcionamiento. Además este trabajo nos trajo un inconveniente inesperado a

la hora de diseñar a “Tiguer.bot” porque a la hora de tener el algoritmo y el código listo

llego la hora de unir todo el aparataje y esto requirió un diseño previo el cual se nos

complicó más de la cuenta en su momento.

El proyecto mostrado, al utilizar Raspberry Pi como plataforma principal puede tener una

infinidad de usos adicionales al que le dimos nosotros en este caso, esto gracias a la gran

conectividad de Raspberry Pi por su puerto Ethernet y por sus puertos USB, los que

permitirían hipotéticamente controlar el “Tiguer.bot” remotamente mediante conexión

USB a Bluetooth o Wi-Fi, además de poder conectar algunos otros sensores a la Raspberry

Pi para que esta detecte cambios de otro tipo en el ambiente como un sensor de

temperatura por ejemplo y en ese escenario hacer un código para dicho contexto.

Con todo lo anterior nos quedó más que claro lo útil que es este aparato inventado hace

pocos años y la multifuncionalidad que se puede llegar a obtener de forma compacta.

Tiguer.bot

v.Alpha


10. Bibliografía http://www.iearobotics.com/wiki/index.php?title=Tutorial:Puerto_serie_en_Linux

Linux and the serial port. Dr. Juan González Gómez. Enero 2009.

http://www.iearobotics.com/wiki/index.php?title=Tutorial:Puerto_serie_en_Linux

robot automóvil autónomo - telematica.utfsm.cl · luego, en el ámbito mecánico del robot se...

Documents