Dise
˜
no de un autopiloto para peque
˜
nos veh
´
ıculos
no tripulados
Design of an Autopilot for Small Unmanned Vehicles
Leonardo Garberoglio
∗1
, Claudio Pose
†2
, Ignacio Mas
†‡§3
and Juan Giribet
†‡4
∗
Grupo de Estudio de Sistemas de Control, Facultad Regional San Nicol
´
as, Universidad Tecnol
´
ogica Nacional
Buenos Aires, Argentina
1
lgarberoglio@frsn.utn.edu.ar
†
Grupo de Procesamiento de Se
˜
nales, Identificaci
´
on y Control, Facultad de Ingenier
´
ıa, Universidad de Buenos Aires
Paseo Col
´
on 850, Ciudad Aut
´
onoma de Buenos Aires, Argentina
2
cldpose@fi.uba.ar
3
imas@fi.uba.ar
‡
Consejo Nacional de Investigaciones Cient
´
ıficas y T
´
ecnicas
Godoy Cruz 2290, Ciudad Aut
´
onoma de Buenos Aires, Argentina
4
jgiribet@conicet.gov.ar
§
Centro de Sistemas y Control - Instituto Tecnol
´
ogico de Buenos Aires
Madero 351, Ciudad Aut
´
onoma de Buenos Aires, Argentina
Resumen—En este trabajo se presenta el dise
˜
no de un
autopiloto para peque
˜
nos veh
´
ıculos aut
´
onomos. El trabajo est
´
a
enfocado principalmente en la arquitectura del sistema, pero se
presentan tambi
´
en algunos detalles del firmware desarrollado
para el autopiloto. En particular, el firmware incluye el
paquete rosserial, que permite una conexi
´
on simple con ROS
(Robot Operating System), resultando beneficioso para diversas
aplicaciones.
El desarrollo se valida experimentalmente en un veh
´
ıculo
a
´
ereo no tripulado (UAV
1
) del tipo multi-rotor y en un
veh
´
ıculo acu
´
atico de superficie (ASV
2
). Estos veh
´
ıculos han
sido desarrollados por nuestro grupo, y en este trabajo puede
encontrarse informaci
´
on sobre estos proyectos, lo cual puede
ser de utilidad para los interesados en el desarrollo de UAV o
ASV.
Palabras clave: Autopiloto; Veh
´
ıculos no tripulados;
Navegaci
´
on Guiado & Control.
Abstract— In this work, the design of an autopilot
for small unmanned vehicles is presented. It is focused
mainly on the system’s architecture, while presenting some
important remarks of the developed firmware. In particular,
the firmware uses rosserial, a package that allows a simple
connection with ROS (Robot Operating System), which is
useful for a number of applications.
The work is validated experimentally on an multirotor-type
unmanned aerial vehicle (UAV), and on an autonomous
surface vehicle (ASV). These vehicles have been developed by
our group, and this work provides information about such
projects, which may be useful for those interested in the
development of this kind of vehicles.
Keywords: Autopilot; Unmanned vehicles; Navigation
Guidance & Control.
I. INTRODUCCI
´
ON
En los
´
ultimos a
˜
nos ha ido creciendo el inter
´
es en el
dise
˜
no, construcci
´
on y despliegue de peque
˜
nos veh
´
ıculos no
1
Unmanned Aerial Vehicles.
2
Autonomous Surface Vehicles.
tripulados. Los veh
´
ıculos aut
´
onomos acu
´
aticos (tanto los de
de superficie (ASV) como los submarinos), los terrestres y
los veh
´
ıculos a
´
ereos no tripulados (UAV), han demostrado
ser de utilidad para diversas aplicaciones, logrando reducir
costos operativos e incluso realizando tareas riesgosas, sin la
necesidad de exponer a los pilotos a situaciones peligrosas.
Los avances en la ingenier
´
ıa electr
´
onica han permitido
reducir los costos de fabricaci
´
on y el desarrollo de veh
´
ıculos
cada vez m
´
as peque
˜
nos y econ
´
omicos. En este sentido, es
notable la potencia computacional de nuevas arquitecturas
de microcontroladores (como la de los ARM Cortex M
de 32bits), la miniaturizaci
´
on y mejora en el desempe
˜
no
de los sensores inerciales (gir
´
oscopos y aceler
´
ometros) de
tipo MEMS
3
, adem
´
as de la estabilidad y sensibilidad de los
nuevos bar
´
ometros MEMS (utilizados como alt
´
ımetros) y
magnet
´
ometros. Por otro lado, con las nuevas constelaciones
de sat
´
elites para GNSS
4
, la mejora en la precisi
´
on y la
reducci
´
on de los costos de los receptores satelitales, es
cada vez m
´
as f
´
acil obtener un sistema de posicionamiento
global; incluso existen en el mercado soluciones econ
´
omicas
que permiten lograr precisi
´
on centim
´
etrica para aquellas
tareas que requieran tal precisi
´
on. Finalmente, las nuevas
tecnolog
´
ıas y materiales utilizados para la fabricaci
´
on de
bater
´
ıas recargables con gran densidad de energ
´
ıa, junto al
desarrollo de actuadores cada vez m
´
as eficientes, en parti-
cular los motores brushless, permiten dotar a los veh
´
ıculos
de una autonom
´
ıa cada vez mayor. Sin embargo, a
´
un es
la autonom
´
ıa un factor limitante para ciertos escenarios en
donde se deben efectuar misiones prolongadas. En estos
escenarios la propulsi
´
on el
´
ectrica no es una alternativa viable
y se hace necesario recurrir a veh
´
ıculos propulsados por
combustible, los cuales suelen ser de mayor tama
˜
no y costo,
con una mec
´
anica m
´
as compleja y la necesidad de un
3
Microelectromechanical systems.
4
Global Navigation Satellite Systems.
Recibido: 07/12/18; Aceptado: 18/02/19
Revista elektron, Vol. 3, No. 1, pp. 29-38 (2019)
ISSN 2525-0159
29
mantenimiento peri
´
odico.
Existen diversas empresas que comercializan peque
˜
nos
veh
´
ıculos no tripulados. Sin embargo, asociado a estas
tecnolog
´
ıas a
´
un quedan muchos problemas por resolver. Esto
hace que hoy d
´
ıa diversos grupos de investigaci
´
on alrededor
del mundo est
´
en trabajando con este tipo de veh
´
ıculos.
Por ejemplo, en [1]–[4] se han desarrollado peque
˜
nos ASV
con fines de investigaci
´
on. Estos veh
´
ıculos han demostrado
ser de gran utilidad en tareas tales como el monitoreo
medioambiental, la toma de muestras, la confecci
´
on de
mapas batim
´
etricos entre otros, todos ellos sin el costo de
desplegar grandes veh
´
ıculos y personal. De igual modo,
se han desarrollado UAVs para gran variedad de tareas
espec
´
ıficas, como en [5]–[8], donde se observan aplicaciones
en seguridad, agrimensura, tareas de monitoreo en zonas de
dif
´
ıcil acceso, como bosques, volcanes, zonas de incendio
o de desastres naturales. Cada vez son m
´
as las aplicaciones
que se ven beneficiadas con el uso de los ASV o UAV y de
peque
˜
nos veh
´
ıculos terrestres.
Una de las limitaciones que se presenta al trabajar con
peque
˜
nos veh
´
ıculos es su capacidad de carga reducida, lo
que no permite instalar un gran n
´
umero de sensores de
observaci
´
on de peso apreciable. Para aquellas misiones que
necesitan un gran conjunto de estos sensores de observaci
´
on,
se pueden utilizar varios veh
´
ıculos, distribuyendo entre
´
estos
los sensores. Estas arquitecturas segmentadas han despertado
el inter
´
es de la comunidad, y en particular el estudio de la
coordinaci
´
on y control de la flota de veh
´
ıculos es objeto de
investigaci
´
on en la actualidad [9].
Mayor inter
´
es a
´
un despierta el desarrollo de t
´
ecnicas de
control para la coordinaci
´
on de veh
´
ıculos que funcionen
cada uno en un dominio diferente (veh
´
ıculos acu
´
aticos,
junto con a
´
ereos o terrestres). Dado que cada veh
´
ıculo est
´
a
dotado con un reducido n
´
umero de sensores, y teniendo
en cuenta que la percepci
´
on del entorno de cada uno de
ellos es diferente y limitada, combinar datos provenientes
de los distintos veh
´
ıculos es de particular inter
´
es. En base
a estos desarrollos, es posible contar con una arquitectura
distribuida de robots, cada uno dise
˜
nado para cumplir una
tarea simple. Finalmente, en funci
´
on a la tarea m
´
as compleja
que se requiera, es posible seleccionar y desplegar los robots
m
´
as adecuados [9].
Todo veh
´
ıculo aut
´
onomo cuenta con un hardware de bajo
nivel, denominado Piloto Autom
´
atico (AP por sus siglas
en ingl
´
es), el cual se encarga de adquirir, sincronizar y
acondicionar la informaci
´
on de los instrumentos de nave-
gaci
´
on, para luego estimar la orientaci
´
on y la posici
´
on del
veh
´
ıculo, decidir su trayectoria y ejecutar los comandos
correspondientes (es decir realizar la navegaci
´
on, el guiado
y el control del veh
´
ıculo). A su vez, muchas veces esta
electr
´
onica es capaz de recibir instrucciones de un opera-
dor o de una computadora de alto nivel y comandar los
actuadores del veh
´
ıculo. Los AP est
´
an presentes en todos
los veh
´
ıculos aut
´
onomos, y muchas veces incluyen varios
subsistemas interconectados, pero para peque
˜
nos veh
´
ıculos
aut
´
onomos, el AP debe tener un tama
˜
no reducido y por lo
general incluir los sensores de navegaci
´
on. De estos senso-
res, uno de los m
´
as importantes, es la unidad de mediciones
inerciales (IMU, por su siglas en ingl
´
es), compuesta por tres
aceler
´
ometros y tres gir
´
oscopos (situados en cada uno de los
ejes). Otros sensores que suelen estar presentes, en la misma
placa o como m
´
odulos externos, son los magnet
´
ometros
(para estimaci
´
on de orientaci
´
on), bar
´
ometros (utilizados para
estimar altitud), receptores de GPS y diferentes tipos de
sensores de velocidad y proximidad.
Cada clase de veh
´
ıculo aut
´
onomo (ASV, UAV o terrestres)
posee necesidades de control de bajo nivel particulares.
Un UAV del tipo multi-rotor posee 6 grados de libertad
(6 DOF
5
) mientras que un ASV posee solo 3 DOF. Los
multi-rotores pueden ser actuados por medio de 4, 6 y
m
´
as motores, mientras que los ASV suelen tener 1
´
o 2,
por su parte veh
´
ıculos de ala fija suelen tener un motor
para propulsi
´
on y servos para controlar la trayectoria. No
obstante, muchas caracter
´
ısticas son comunes a ambas clases
de veh
´
ıculos. Por ejemplo, para la estimaci
´
on de la posici
´
on
y la orientaci
´
on del veh
´
ıculo, suelen utilizarse algoritmos
similares para fusionar los datos de los sensores de navega-
ci
´
on. Los actuadores suelen comandarse mediante el mismo
tipo de se
˜
nales (PWM
6
), los comandos suelen provenir
de radio-controles (RC) que utilizan protocolos similares.
Teniendo en cuenta todas estas similitudes y diferencias,
es de particular inter
´
es poder contar con un AP vers
´
atil,
esto simplifica el desarrollo cuando se trabaja con varios
veh
´
ıculos de diferentes clases.
Existe una variedad de AP comerciales disponibles en
el mercado, cuyos dise
˜
nos buscan optimizar el peso, ta-
ma
˜
no, costo, potencia computacional y perif
´
ericos, as
´
ı como
tambi
´
en diferentes tipos sensores. Dentro de los AP m
´
as
populares, proyectos como Pixhawk [10] y APM [11] son
open-hardware y open-software, con una enorme comuni-
dad de usuarios y desarrolladores. El proyecto Pixhawk se
presenta en diferentes versiones de su AP y el software
es constantemente actualizado teniendo en cuenta los re-
querimientos de sus usuarios, ya que el mismo es muy
utilizado en el
´
ambito acad
´
emico y por usuarios aficionados.
Con caracter
´
ısticas similares se encuentra la l
´
ınea de AP
desarrolladas por DJI [12], los cuales se enfocan en UAV del
tipo multi-rotor y que, comparado con otros proyectos como
el Pixhawk, tienen un mayor costo y suelen ser instaladas
en veh
´
ıculos listos para volar. La principal desventaja es
que, tanto su hardware como su software, son propietarios,
por lo que la flexibilidad para proyectos acad
´
emicos es m
´
as
limitada. Cuando se requiere mayor capacidad de c
´
omputo
o el uso de sensores m
´
as avanzados se pueden utilizar AP
como los desarrollados por Acutronic Robotic (ex Erle-
Robotic), basados en una Raspberry Pi Zero. Otra opci
´
on es
la controladora de vuelo Aereo, basada un microprocesador
Intel Atom. Para realizar proyectos con mayor capacidad de
c
´
omputo, pueden utilizarse mini computadoras como la Intel
NUC, pero estas alternativas suelen ser m
´
as costosas, con un
considerable incremento en el peso y consumo respecto al
Pixhawk o APM. La aplicaci
´
on en la que se est
´
e trabajando
definir
´
a cu
´
al es el veh
´
ıculo, as
´
ı como el AP adecuado. En
[13] se presenta una comparaci
´
on entre distintos autopilotos
que suelen encontrarse, principalmente en UAV de tipo
multi-rotor.
5
Degree Of Freedom.
6
Pulse Width Modulation.
Revista elektron, Vol. 3, No. 1, pp. 29-38 (2019)
ISSN 2525-0159
30
http://elektron.fi.uba.ar
II. DESARROLLO DE HARDWARE DEL AUTOPILOTO
En el a
˜
no 2018, los laboratorios GPSIC
7
y GESIC
8
desa-
rrollaron un AP de bajo costo y vers
´
atil, para ser utilizado en
peque
˜
nos veh
´
ıculos aut
´
onomos de diversos tipos. El dise
˜
no
se bas
´
o en un AP fabricado previamente en el GPSIC en
2013 y 2015, denominado Choriboard. La primera (a
˜
no
2013) y segunda versi
´
on (a
˜
no 2015) de la Choriboard [16],
[17] utilizaban un procesador ARM Cortex-M3, sin unidad
de punto flotante, con un clock de hasta 120MHz y 150
DMPIS (Drystone Millions of Instructions per Second), en
un encapsulado LQFP de 100 pines de 14x14mm. En la
Facultad de Ingenier
´
ıa de la UBA se hab
´
ıan construido
proyectos similares de autopilotos [18].
Las primeras versiones de la Choriboard utilizaban una
IMU con un chip MPU6000 de Invensense. Este chipset,
actualmente discontinuado, ofrec
´
ıa la posibilidad de utilizar
un firmware propietario llamado Digital Motion Processor
(DMP), que permit
´
ıa realizar la fusi
´
on y filtrado de datos
dentro del mismo chip para obtener una estimaci
´
on de la
orientaci
´
on del veh
´
ıculo mediante un cuaterni
´
on. Si bien
la versi
´
on MPU6050 del mismo dispositivo era mucho m
´
as
popular, el MPU6000 presentaba la opci
´
on de comunicaci
´
on
por SPI hasta 20MHz, que presenta ventajas cuando se
necesita procesar una gran cantidad de datos. El dispositivo
se presentaba en un encapsulado QFN de 24 pines de
4x4mm.
Para completar la estimaci
´
on de orientaci
´
on, se agreg
´
o
un magnet
´
ometro HMC5883L de Honeywell. En la primera
versi
´
on, este sensor se encontraba sobre la misma placa,
pero su medici
´
on se ve
´
ıa fuertemente afectada por el campo
magn
´
etico producido por los motores de los veh
´
ıculos, lo
cual hac
´
ıa dif
´
ıcil la instalaci
´
on de la placa en veh
´
ıculos
del tipo multi-rotor. Para solucionar este inconveniente, se
utilizaba un magnet
´
ometro adicional, ubicado entre 10cm y
15cm por encima del plano de los motores.
La primera versi
´
on de la Choriboard fue dise
˜
nada sobre
una placa de 93x93mm, con suficiente espacio entre los
diversos componentes para permitir la verificaci
´
on de errores
de dise
˜
no. Para la segunda versi
´
on, el factor de forma fue
tomado en cuenta, y se redujeron las dimensiones de la placa
a 100x60mm, como puede observarse en la figura 1.
Ambas versiones de la placa incluyen una fuente swit-
ching con un amplio rango de voltaje de entrada (7-40V),
para permitir el uso de bater
´
ıas LiPo de entre 2 y 6 celdas
(7.4-22.2V), y con una salida de 5V-3A. Esta fuente permite
alimentar todos los componentes de la placa (mediante un
regulador lineal de bajo dropout de 3.3V), a la vez que ha-
bilita el uso de una computadora externa para tareas de alto
nivel. De hecho, para la segunda versi
´
on de la Choriboard
se dise
˜
n
´
o una placa que permite adosarle una Intel Edison
y as
´
ı poder implementar algoritmos de navegaci
´
on y control
m
´
as complejos, por ejemplo aquellos basados en im
´
agenes
[19]–[21]. En ambas versiones, todos los conectores para
las entradas y salidas de PWM, as
´
ı como tambi
´
en para
los sensores externos, puertos de comunicaci
´
on y programa-
7
Grupo de Procesamiento de Se
˜
nales, Identificaci
´
on y Control, Facultad
de Ingenier
´
ıa de la UBA [14].
8
Grupo de Estudio de Sistemas de Control, Facultad Regional San
Nicol
´
as, Universidad Tecnol
´
ogica Nacional [15].
Figura 1. Versi
´
on I de la Choriboard (izq) y versi
´
on 2 (der)
ci
´
on/debugging, se implementaron utilizando tiras de pines
con un pitch de 2.54mm (0.1”).
II-A. Nueva propuesta de dise
˜
no del autopiloto
La tercera versi
´
on de la Choriboard (a
˜
no 2018) se dise
˜
n
´
o
con dos objetivos principales:
1. Reducir el tama
˜
no y peso de la placa, para poder ser
utilizada en veh
´
ıculos a
´
ereos muy peque
˜
nos.
2. Actualizar el modelo de microcontrolador y sensores,
para mejorar el rendimiento, y para remplazar dispo-
sitivos obsoletos y/o discontinuados.
El microcontrolador utilizado es un STM32F722, en un
encapsulado LQFP de 64 pines de 10x10mm. Es un disposi-
tivo ARM Cortex-M7 de alto desempe
˜
no, que puede operar
hasta 216MHz y posee unidad de punto flotante integrada,
logrando hasta 462 DMIPS, el triple que la versi
´
on previa.
Cuenta con 512KB de memoria flash y 256KB de memoria
RAM; 64KB de esta
´
ultima son usados para almacenar datos
de tareas tiempo real cr
´
ıticas y otros 16KB para ejecutar
dichas tareas. Este chip fue elegido para obtener el mejor
balance entre el tipo y tama
˜
no de encapsulado (maximizar
el n
´
umero de pines utilizados, facilidad para soldadura
manual), poder computacional (es uno de los mejores de la
serie Cortex-M), documentaci
´
on de firmware, disponibilidad
de librer
´
ıas de bajo nivel, y las comunidades de soporte.
Para remplazar el ya discontinuado MPU6000, se eligi
´
o
otro dispositivo de Invensense, el ICM20602, similar a su
antecesor. Una desventaja es que no soporta el uso del
firmware DMP, raz
´
on por la cual la fusi
´
on y filtrado de los
datos debe realizarse directamente en el microcontrolador.
Sin embargo esto no es un inconveniente dado que, el
firmware desarrollado para las primeras versiones del AP
inclu
´
ıa rutinas para la estimaci
´
on de orientaci
´
on, las cuales
han sido validadas con el DMP.
En el Cuadro I se muestra una comparaci
´
on general entre
los dos sensores, donde puede observarse que los gir
´
oscopos
presentan 20 veces menos offset en ausencia de movimiento
rotacional (ZRO), 20 % menos de ruido y tres veces mejor
sensibilidad, mientras que los aceler
´
ometros presentan la
mitad de offset y cuatro veces menos ruido.
Para reducir el peso y el tama
˜
no de la placa, todos los
conectores fueron reemplazados por modelos de montaje
superficial de Hirose, de la l
´
ınea DF13, los mismos que se
Revista elektron, Vol. 3, No. 1, pp. 29-38 (2019)
ISSN 2525-0159
31
http://elektron.fi.uba.ar
Cuadro I
COMPARACI
´
ON ENTRE IMUS
PRODUCTO ICM 20602 MPU6000
Encapsulado 2x2x0,75mm LGA 16
leads
4x4x0,9mm QFN 24
Leads
GIR
´
OSCOPOS
FSR (dps) ±250/500/1000/2000 ±250/500/1000/2000
ZRO @25
◦
C ±1dps ±20dps
ZRO over Temp ±0,02dps/
◦
C ±0,16dps/
◦
C
Sens. Tol. @25
◦
C ±1 % ±3 %
Sens. Over Temp ±2 % ±2 %
Gyro Noise 0.004dps/
√
Hz 0.005dps/
√
Hz
ACELER
´
OMETROS
FSR ±2/4/8/16g ±2/4/8/16g
Offset @25
◦
C ±25mg X,Y : ±50mg Z:
±80mg
Offset Over Temp X,Y: ±0.5mg/
◦
C Z:
±1mg/
◦
C
X,Y: ±0.5mg/
◦
C Z:
±85mg/
◦
C
Sens. Tolerance ±1 % ±3 %
Sens. Over Temp ±1,5 % ±2,5 %
Accel Noise 100µg/
√
Hz 400µg/
√
Hz
usan en el autopiloto Pixhawk. Al momento del dise
˜
no, los
pines se han asignado de forma tal que todos los m
´
odulos
utilizados en el Pixhawk pueden ser conectados directamente
en la Choriboard.
Adem
´
as, la fuente switching fue removida de la placa
principal, dejando un conector de alimentaci
´
on, tambi
´
en
compatible con los que se utilizan en el Pixhawk. Estos
m
´
odulos permiten el sensado de los niveles de tensi
´
on y
consumo de corriente de la bater
´
ıa.
El bar
´
ometro BMP180, tambi
´
en discontinuado, fue re-
emplazado por el modelo MS5611 de TE Conectivity, que
cuenta con un conversor ADC de 24 bits en lugar del de 19
bits de su antecesor, esto permite medir la altura con una
sensibilidad de hasta 10cm. El bar
´
ometro se comunica con
el microcontrolador mediante una interfaz I2C.
Para habilitar la conexi
´
on de diversos sensores externos,
otro conector de bus I2C se encuentra disponible. Como
dicha interfaz suele ser utilizada por un magnet
´
ometro, se
agrega un pin extra para ser asignado a la se
˜
nal de fin
de conversi
´
on de la medici
´
on. Si es necesario conectar
m
´
ultiples sensores, se utiliza un extensor externo a la placa.
En el mismo bus I2C, pero montado sobre la placa
principal, se encuentra una memoria EEPROM para alma-
cenar informaci
´
on no vol
´
atil, como datos de calibraci
´
on de
sensores, o configuraci
´
on del sistema.
El dise
˜
no cuenta con un conector adicional con un bus SPI
diferente a aquel usado para la IMU, para ser utilizado con
otra IMU de mayor calidad en pos de realizar calibraciones
o comparaciones, o para comandar un On-Screen Display
(OSD), que agrega los datos de vuelo a un transmisor de
video.
Adem
´
as, se provee un conector de un puerto UART para
utilizarse con un m
´
odulo GPS, el cual cuenta no s
´
olo con
las l
´
ıneas de transmisi
´
on y recepci
´
on, sino tambi
´
en con una
entrada de PPS (Pulse Per Second - Pulso Por Segundo), que
suele utilizarse para una precisa sincronizaci
´
on de tiempos
con el sistema satelital.
Para la recepci
´
on de comandos se provee de una entrada
para se
˜
nales tipo PPM. Dado que se desea la reducci
´
on del
tama
˜
no, el encoder PWM a PPM no se incluye en la placa
pero puede agregarse de forma externa de ser necesario.
Adem
´
as, se agrega una entrada para se
˜
nales DSM de la
l
´
ınea de radiocontroles Spektrum (UART), para conectar
directamente los micro-receptores Satellite de la marca. Por
otro lado, seis salidas PWM est
´
an disponibles para controlar
los actuadores del veh
´
ıculo, los cuales en general son
controladores electr
´
onicos de velocidad (ESC) para motores
trif
´
asicos sin escobillas, o servomotores. Todas las se
˜
nales
de este tipo se encuentran en un
´
unico conector de 10 pines
(6 salidas PWM con una masa com
´
un, y la entrada de PPM
con +5V y masa).
Para almacenar una cantidad de datos masiva en tiempo
real (por ejemplo, los datos sin procesar de los sensores), se
utiliza una memoria microSD. Como indicadores visuales
se agregan tres leds (rojo, verde, azul) para diversos usos.
El microcontrolador permite la conexi
´
on directa a un
puerto mini USB para la actualizaci
´
on del firmware, o como
una interfaz UART para la comunicaci
´
on con una placa de
alto nivel. Tambi
´
en se provee un conector de 4 pines Serial
Wire Debug (SWD), como otra opci
´
on para actualizar el
firmware, y, adem
´
as, para realizar debugging del mismo.
En la figura 2 se puede observar la comparaci
´
on f
´
ısica
entre la segunda y tercera versi
´
on de la Choriboard.
Figura 2.
´
Ultimo dise
˜
no, versi
´
on III (izq), y versi
´
on II (der).
Con respecto al hardware, las caracter
´
ısticas de la placa
dise
˜
nada son considerablemente similares a las del Pixhawk.
La
´
ultima versi
´
on del Pixhawk recientemente se actualiz
´
o e
incluye un Cortex-M7. Tambi
´
en es cierto que la compatibi-
lidad entre el hardware de ambos autopilotos fue un factor
importante al momento del dise
˜
no. Una de la razones detr
´
as
de dichas elecciones es la capacidad de desarrollar tareas de
investigaci
´
on de grado, master y doctorado, a la vez que se
pueden crear trabajos conjuntos entre diferentes universida-
des, aprovechando la gran disponibilidad de los productos
comerciales. Otra raz
´
on es la capacidad de utilizar sensores
comerciales, que han sido probados minuciosamente, para
comprobar la calidad del dise
˜
no realizado, mientras se desa-
rrollan versiones propias de cada uno de ellos. Por otro lado,
existen diversas prestaciones en los autopilotos comerciales
que no son
´
optimas o incluso no tienen uso en diversas
tareas de investigaci
´
on, sin embargo consumen recursos del
microcontrolador. La capacidad de poder eliminar las partes
innecesarias puede liberar recursos
´
utiles para asignar a otras
tareas, o para aliviar la carga del microcontrolador. Por
´
ultimo, la selecci
´
on de los componentes utilizados en base a
Revista elektron, Vol. 3, No. 1, pp. 29-38 (2019)
ISSN 2525-0159
32
http://elektron.fi.uba.ar
su disponibilidad y precio, y el dise
˜
no de un PCB simple con
posibilidad de ser soldado a mano, otorga un mayor control
sobre el costo de la placa finalizada. En la figura 3 puede
verse un diagrama en bloques del hardware del autopiloto.
Figura 3. Diagrama en bloques del hardware desarrollado
III. DESARROLLO DEL FIRMWARE
El firmware, el cual est
´
a basado en las versiones desa-
rrolladas para las versiones anteriores del AP, fue dividi-
do en dos partes. La primera es una abstracci
´
on de los
perif
´
ericos de bajo nivel, mientras que la segunda es la
aplicaci
´
on del usuario. Los drivers de bajo nivel tienen
por objetivo inicializar el microcontrolador y sus perif
´
ericos
(temporizadores, buses SPI-I2C, UARTS, etc.), mientras que
la aplicaci
´
on de usuario provee las funciones de alto nivel
para realizar la configuraci
´
on y lectura de los sensores, y
ejecutar los algoritmos de navegaci
´
on y control. En general,
la adquisici
´
on de datos de los diferentes sensores se realiza a
intervalos regulares, pero los sensores tienen distintas tasas
de muestreo en el cual entregan informaci
´
on. Por ejemplo, la
IMU puede realizar mediciones a una frecuencia entre 1KHz
y 8KHz, el bar
´
ometro y magnet
´
ometro a 10Hz, el receptor
de radio control a 50Hz y el GPS a 1Hz (5Hz o 10Hz),
entre otros. Los actuadores suelen funcionar a frecuencias
de hasta 400Hz. Por lo tanto, se necesita de un sistema que
pueda administrar la lectura de sensores y la fusi
´
on de datos
teniendo en cuenta las caracter
´
ısticas del sistema.
Para realizar la implementaci
´
on del software, se prefiri
´
o
utilizar un sistema bare-metal en lugar de basarse en un
RTOS (sistema operativo de tiempo real). Aunque existen
en la comunidad distintas visiones sobre cu
´
al de estas
opciones es m
´
as conveniente, hay un claro consenso sobre
las ventajas que cada una presenta. Las ventajas que ofrece
el desarrollo de un RTOS son diversas, en particular, el uso
de un scheduler o un middleware facilita considerablemente
el desarrollo. Si bien es cierto que se sacrifica memoria
del microcontrolador, no parece una limitaci
´
on para esta
aplicaci
´
on. Sin embargo, usar un RTOS significa, de alguna
manera, perder cierto determinismo en la ejecuci
´
on de las
tareas, o al menos que se haga m
´
as complejo el an
´
alisis
de tiempos.
´
Esta es la raz
´
on para la elecci
´
on tomada,
obtener un mayor control sobre los tiempos de respuesta
ante diferentes eventos, normalmente dados por los sensores,
como puede ser la llegada de un pulso de PPS, o el fin de la
conversi
´
on del ADC en la IMU o el magnet
´
ometro. Cuando
se desea dar pruebas formales sobre la estabilidad de un
lazo de control, teniendo en cuenta la implementaci
´
on en
el hardware, resulta conveniente poder describir con cierto
determinismo el comportamiento del sistema puesto que
facilita el an
´
alisis de los algoritmos. Por ejemplo, el uso del
PPS para sincronizaci
´
on de tiempos, el cual es una se
˜
nal
con precisi
´
on del orden de los nanosegundos, requiere su
atenci
´
on con la mayor prioridad posible, relegando otras
posibles tareas en ejecuci
´
on.
Para este fin, en los microcontroladores utilizados se
encuentra disponible un controlador dedicado a la organiza-
ci
´
on y atenci
´
on de interrupciones, llamado Nested Vectored
Interrupt Controller (NVIC). El mismo permite agrupar a las
diferentes fuentes de interrupci
´
on, tales como interrupciones
por timers internos, canales de comunicaci
´
on o cambio
de flancos o nivel en determinados pines, en diferentes
niveles de prioridades y sub-prioridades. De esta manera,
interrupciones con un alto nivel de prioridad pueden pausar
temporalmente la ejecuci
´
on de interrupciones de menor
prioridad, y retomarlas una vez hayan sido finalizadas. Por
otro lado, interrupciones con el mismo nivel de sub-prioridad
son puestas en una cola y atendidas secuencialmente.
Adem
´
as, se hace uso de otra prestaci
´
on de esta l
´
ınea de
microcontroladores, el acceso directo a memoria (DMA -
Direct Memory Access). Dicha prestaci
´
on permite habili-
tar, entre otras cosas, el acceso directo de los puertos de
comunicaci
´
on a la memoria donde son almacenadas las
variables, ejecut
´
andose dicho proceso en paralelo al pro-
grama principal. Dado que se hace uso de varios canales de
comunicaci
´
on para los diferentes sensores, y para transmitir
datos de forma masiva, dicho recurso permite alivianar la
carga del procesador.
Para el desarrollo del firmware se ha utilizado el paquete
STM32CubeMX. Esta aplicaci
´
on gr
´
afica permite configurar
cada pin del microcontrolador para asignarle la funci
´
on
espec
´
ıfica requerida. Tambi
´
en provee una forma simple
de configurar el complejo sistema del reloj interno del
microcontrolador, permitiendo elegir la frecuencia de trabajo
deseada y configurando autom
´
aticamente los PLLs. Esta
herramienta tambi
´
en genera el c
´
odigo para la inicializaci
´
on
de los perif
´
ericos configurados y crea un proyecto para
diferentes IDEs. El IDE utilizado es el provisto por el
fabricante del microcontrolador, el cual est
´
a basado en
Eclipse.
III-A. ROS y ROS Serial
ROS (Robot Operating System) es un entorno de trabajo
(framework) para el desarrollo de software orientado a
robots, que provee la funcionalidad de un sistema operativo.
ROS provee los servicios est
´
andar de un sistema operativo
(m
´
as precisamente funciona como middleware) tales como
abstracci
´
on del hardware, control de dispositivos de bajo
nivel, implementaci
´
on de funcionalidad de uso com
´
un, paso
de mensajes entre procesos y mantenimiento de paquetes.
En los
´
ultimos a
˜
nos, ROS se ha convertido en uno de los
est
´
andares m
´
as usados en grupos de investigaci
´
on dedicados
a la rob
´
otica. El funcionamiento es por medio de nodos,
programados generalmente en C++ o Python, los cuales
Revista elektron, Vol. 3, No. 1, pp. 29-38 (2019)
ISSN 2525-0159
33
http://elektron.fi.uba.ar
se comunican entre s
´
ı compartiendo mensajes a trav
´
es de
t
´
opicos. Cada nodo suele tener una funci
´
on espec
´
ıfica y
b
´
asica en el entorno. Es posible ejecutar nodos en distintos
dispositivos, formando una red entre ellos. Por ejemplo,
una computadora puede correr el nodo maestro de ROS
(roscore) y alg
´
un nodo que procese datos mientras que en
otra computadora se pueden correr los nodos encargados
de la adquisici
´
on de los datos. Esta segunda computadora
puede estar, incluso, a bordo de un veh
´
ıculo aut
´
onomo.
ROS necesita un sistema operativo, generalmente Linux,
para poder ejecutarse. En el caso en donde la adquisici
´
on de
datos se realiza en alguna computadora de bajo nivel, en la
que no se puede instalar un sistema operativo, es necesario
hacer uso de alg
´
un paquete que permita la comunicaci
´
on
entre el sistema embebido de bajo nivel y la computadora de
alto nivel. En este trabajo se hace uso del paquete rosserial
[22].
Rosserial es una interfaz de comunicaci
´
on que permite
intercambiar mensajes del tipo ROS (los mismos que se
utilizan en la comunicaci
´
on interna de los nodos) a trav
´
es
del protocolo serial. Para que esta comunicaci
´
on se lleve
a cabo es necesario ejecutar el paquete rosserial python
en la computadora principal y desarrollar un cliente en
el sistema embebido de bajo nivel. Actualmente existen
clientes para Arduino, Mbed, Tivac y otros. En este trabajo
se ha desarrollado un cliente de dicha librer
´
ıa para el
microcontrolador de la Choriboard.
La integraci
´
on de un AP en ROS permite dividir el
sistema de control de un veh
´
ıculo m
´
as complejo en peque
˜
nos
sistemas embebidos capaces de crear nodos, publicar y
suscribirse a t
´
opicos del sistema as
´
ı como hacer uso de los
servicios y par
´
ametro del entorno. Como se ha comentado
anteriormente, el esqueleto del firmware de la Choriboard
se crea con la herramienta CubeMX. ROS Serial necesita
una comunicaci
´
on serie con la PC de alto nivel. Es por ello
que se dedica la UART3 para este fin.
En este proyecto se han utilizado los mensajes IMU y Bat-
teryState. Dichos mensajes forman parte de los std sensor
message. Para utilizarlos se crea un node handler y dos obje-
tos publisher, uno para cada mensaje. Luego, peri
´
odicamente
se actualizan los valores de los datos de dichos mensajes y
se publican en el nodo maestro de ROS a trav
´
es de rosserial.
En la secci
´
on de validaci
´
on experimental se ver
´
a la
utilidad de haber implementado rosserial, y c
´
omo permiti
´
o
utilizar de manera simple informaci
´
on del AP para procesar
la informaci
´
on adquirida por un LIDAR instalado en un
ASV.
IV. BANCOS DE PRUEBA PARA LA VALIDACI
´
ON
EXPERIMENTAL
Para validar experimentalmente el desempe
˜
no del AP se
realizaron varias pruebas. En particular se presentan aqu
´
ı
los resultados obtenidos con un veh
´
ıculo a
´
ereo no tripulado
del tipo multi-rotor (m
´
as precisamente un quadrotor) y con
un veh
´
ıculo acu
´
atico de superficie. Ambos veh
´
ıculos fueron
desarrollados por el grupo de investigaci
´
on y usualmente son
utilizados como banco de pruebas para validar los algoritmos
de navegaci
´
on, guiado y control. A continuaci
´
on se presenta
una introducci
´
on de estos veh
´
ıculos.
IV-A. Dise
˜
no y construcci
´
on de los veh
´
ıculos
En la actualidad, no s
´
olo la electr
´
onica de los veh
´
ıcu-
los aut
´
onomos se encuentra disponible de forma masiva
y a un bajo costo. Con la aparici
´
on y proliferaci
´
on de
la tecnolog
´
ıa de impresi
´
on 3D en una gran variedad de
materiales, tambi
´
en las estructuras de este tipo de veh
´
ıculos
se han vuelto accesibles para el p
´
ublico general. Es posible
encontrar en sitios dedicados al almacenamiento de modelos
3D (Thingiverse, GrabCAD, etc.) no s
´
olo piezas de repuesto
y accesorios personalizados para modelos comerciales de
estructuras, sino tambi
´
en modelos propios dise
˜
nados para
facilitar la producci
´
on y armado por usuarios particulares
que no disponen de complejas maquinarias industriales (en
particular para UAV del tipo multi-rotor).
Por ejemplo, para algunas pruebas de control con m
´
ulti-
ples veh
´
ıculos a
´
ereos en el GPSIC, se dise
˜
n
´
o un veh
´
ıcu-
lo quadrotor con caracter
´
ısticas similares a los veh
´
ıculos
comerciales, con una distancia diagonal entre motores de
500mm. Este dise
˜
no es el mismo que se utiliza para realizar
los vuelos de validaci
´
on en este trabajo, y el mismo puede
descargarse del repositorio utilizado por el grupo
9
. Los
actuadores est
´
an compuestos por cuatro motores RCTimer
2212/920Kv y h
´
elices pl
´
asticas 9443. Se utilizaron un trans-
misor Spektrum DX7 y un receptor AR6100, de la misma
marca, para controlar de manera remota el veh
´
ıculo. Para
la alimentaci
´
on del veh
´
ıculo se utiliz
´
o una bater
´
ıa LiPo de
cuatro celdas. La figura 4 muestra la Choriboard instalada
en el UAV.
Figura 4. UAV utilizado para la validaci
´
on experimental del autopiloto.
En 2017 comenz
´
o una colaboraci
´
on entre los laboratorios
GPSIC y GESIC con el prop
´
osito de desarrollar un ASV de
bajo costo capaz de funcionar en aguas calmas, como las de
un arroyo o un lago. Como resultado de esta colaboraci
´
on
se obtuvo el ASV Yaguar
´
on [23]. En la figura 5 se puede
ver una foto de este veh
´
ıculo navegando en un arroyo de la
zona de Ramallo, provincia de Buenos Aires.
La configuraci
´
on elegida fue tipo catamar
´
an con 2 ponto-
nes. Esta configuraci
´
on otorga una gran estabilidad y permite
una considerable capacidad de carga
´
util aceptable para un
veh
´
ıculo de este porte. Los pontones fueron desarrollados
a partir de tubos de PVC y las punteras, as
´
ı como las
tapas traseras de los pontones fueron construidas con piezas
moldeadas en fibra de vidrio y resina epoxi. La estruc-
tura central, que une ambos pontones, fue construida en
9
https://gitlab.com/gpsic/modelos-3d/quad
Revista elektron, Vol. 3, No. 1, pp. 29-38 (2019)
ISSN 2525-0159
34
http://elektron.fi.uba.ar
aluminio. Para soportar la electr
´
onica y algunos sensores
se construy
´
o un segundo marco desmontable, tambi
´
en de
aluminio, ubicado en la parte posterior del ASV y montado
en forma vertical.
La propulsi
´
on del ASV est
´
a dada por dos impulsores de
la firma BlueRobotics, modelo T100, instalados uno en cada
pont
´
on. La configuraci
´
on de propulsi
´
on en modo diferencial
permite el control de heading sin la necesidad de timones
m
´
oviles, facilitando la mec
´
anica. Cada motor es manejado
por un Controlador Electr
´
onico de Velocidad (ESC por sus
siglas en ingl
´
es) del mismo fabricante. Estos ESC permiten
la operaci
´
on del veh
´
ıculo hacia adelante y en reversa. La
fuente de energ
´
ıa utilizada son tres bater
´
ıas de 12V y 7Ah, lo
que le da una autonom
´
ıa de 2 horas.
´
Estas fueron montadas
en la parte delantera del ASV para balancear el peso del
mismo.
Todos los componentes electr
´
onicos del Yaguar
´
on ASV
fueron montados en un gabinete pl
´
astico, estanco, en el
marco vertical del veh
´
ıculo. En la figura 6 puede verse el
montaje de la Choriboard III utilizando una pieza pl
´
astica
fabricada con impresora 3D, el receptor de Radio Control,
los ESCs y el m
´
odulo de alimentaci
´
on. En esta figura
tambi
´
en puede verse una Raspberry Pi 3, que se utiliz
´
o en las
pruebas para adquirir informaci
´
on de un sensor de distancia
l
´
aser y de los sensores de navegaci
´
on del AP.
Figura 5. Yaguaron ASV.
IV-B. Control de los veh
´
ıculos
En esta secci
´
on se presentan los algoritmos de control que
se implementan en el firmware del AP. El prop
´
osito no es
presentar en detalle el algoritmo, sino dar una explicaci
´
on
general, para que pueden comprenderse los resultados que
se presentan m
´
as adelante.
IV-B1. Estabilizaci
´
on del UAV: La distribuci
´
on de los
motores con la direcci
´
on de giro y la convenci
´
on de los ejes
son representados en la figura 7.
Los
´
angulos de navegaci
´
on utilizados se definen como la
rotaci
´
on sobre cada uno de los ejes: roll, para la rotaci
´
on
sobre el eje x, pitch, para la rotaci
´
on sobre el eje y, y yaw,
para la rotaci
´
on sobre el eje z.
Por otro lado, el veh
´
ıculo posee s
´
olo 4 DOF, ya que
puede actuar independientemente sobre los tres
´
angulos de
navegaci
´
on, adem
´
as de la aceleraci
´
on vertical (respecto a la
terna del veh
´
ıculo). Cualquier movimiento en el plano xy
Figura 6. Interconexi
´
on de los componentes del sistema electr
´
onico.
(respecto de una terna inercial fija a la tierra), estar
´
a ligado
a variaciones de los
´
angulos de pitch y roll.
Figura 7. Distribuci
´
on de los motores y ejes del UAV.
Para poder volar un veh
´
ıculo del tipo multi-rotor, el
AP debe ejecutar varias tareas. Primero, para estabilizar la
orientaci
´
on del veh
´
ıculo, los datos de los tres aceler
´
ometros
y gir
´
oscopos son adquiridos y procesados para obtener una
estimaci
´
on filtrada de los
´
angulos de pitch y roll. Los
aceler
´
ometros est
´
an afectados por ruido de alta frecuencia,
pero (en una situaci
´
on de vuelo est
´
atico - hovering) entregan
una buena medici
´
on de la direcci
´
on del vector de gravedad.
Por otro lado, los gir
´
oscopos tienen una buena respuesta en
alta frecuencia, pero suelen estar afectados por un sesgo.
Para extraer las mejores caracter
´
ısticas de cada uno de los
sensores, se realiza una calibraci
´
on inicial para eliminar
el sesgo de los gir
´
oscopos y los
´
angulos de pitch y roll
son obtenidos usando un filtro complementario [24]. El
magnet
´
ometro, previamente calibrado, es usado para obtener
el
´
angulo de yaw respecto del norte magn
´
etico.
Para guiar el veh
´
ıculo y enviar los comandos de referencia
de los
´
angulos, se utiliza un radio control de 7 canales marca
Spektrum operando en la frecuencia de 2.4GHz. Cada canal
del control env
´
ıa una se
˜
nal PWM a 50Hz, con un tiempo
en alto de entre 1 y 2mS. El receptor saca una se
˜
nal PPM
compuesta por todas las se
˜
nales PWM una detr
´
as de la otra
Revista elektron, Vol. 3, No. 1, pp. 29-38 (2019)
ISSN 2525-0159
35
http://elektron.fi.uba.ar
e ingresa a un pin dedicado para tal fin en la FC. Cinco
canales son usados, uno para el empuje vertical y tres para
las referencias de pitch, roll y yaw y un switch del tipo
on/off para habilitar/deshabilitar el control y los motores.
Para estabilizar el veh
´
ıculo, se utilizan tres controladores
PID independientes para cada uno de sus
´
angulos. Cuando
se implementan los controladores PID se debe notar que
actuando sobre el error en los
´
angulos de pitch, roll y
yaw, la salida ser
´
a el torque necesario en cada eje para
realizar la acci
´
on deseada. Para convertir los torques en
fuerzas individuales para cada motor se deben establecer
las relaciones entre dichas magnitudes. El conjunto de los
torques de cada motor m
´
as el empuje vertical se relaciona
con las fuerzas individuales de cada motor de la siguiente
forma:
M
x
M
y
M
z
F
z
= A ·
f
1
f
2
f
3
f
4
(1)
donde, para el multi-rotor descripto en la figura 7:
A =
−
√
2
2
l
√
2
2
l
√
2
2
l −
√
2
2
l
√
2
2
l
√
2
2
l −
√
2
2
l −
√
2
2
l
˜
k
t
−
˜
k
t
˜
k
t
−
˜
k
t
−1 −1 −1 −1
La constante
˜
k
t
representa la relaci
´
on entre el torque
producido en el eje Z del veh
´
ıculo por el giro de los motores
a una distancia l del centro, y la fuerza es ejercida en el
mismo eje.
Para obtener las fuerzas individuales de los motores dados
los torques, es suficiente con usar la pseudoinversa de A (ver
por ejemplo [25]), ya que produce soluci
´
on con la m
´
ınima
energ
´
ıa y por ende el m
´
ınimo uso de potencia.
En [26] puede encontrarse m
´
as informaci
´
on acerca del
an
´
alisis de la din
´
amica y el control de un quad-rotor.
IV-B2. Guiado del Yaguaron ASV: Como se mencion
´
o
anteriormente, gran parte de los perif
´
ericos utilizados para
estabilizar un UAV son los mismos que se utilizan para
navegar con el ASV. La lectura de los comandos del Radio
Control, el manejo de los motores (por medio de los ESC),
la telemetr
´
ıa con una PC en tierra utilizando radio enlace
y la estimaci
´
on de la actitud del veh
´
ıculo son ejemplos de
estas semejanzas. Es por ello que se reutiliz
´
o gran parte del
firmware del UAV, siendo necesario reescribir las funciones
que vinculan los comandos del Radio Control con las se
˜
nales
enviadas a los motores para la navegaci
´
on en modo manual.
V. RESULTADOS
En esta secci
´
on se presentan los resultados obtenidos
utilizando la Choriboard en el UAV y el ASV. En [27] puede
verse un video de las pruebas realizadas con los veh
´
ıculos.
Primero se presentan los resultados de los experimentos en
un vuelo realizado con el multi-rotor, en donde se realiza
un an
´
alisis del control interno (de hovering) y el desempe
˜
no
del control ante perturbaciones. El prop
´
osito de la segunda
prueba es mostrar el correcto funcionamiento del AP para
controlar el ASV y adem
´
as mostrar la utilidad de haber
incluido el rosserial en el firmware.
V-A. Desempe
˜
no del AP en un multi-rotor
Se realizaron varios vuelos con el multi-rotor para evaluar
el desempe
˜
no de la Choriboard. Todos los vuelos fueron
realizados en exteriores, con vientos moderados.
En las figuras 8, 9 y 10, se muestran los valores medidos
y de referencia para los
´
angulos de pitch, roll y yaw durante
uno de los vuelos. Puede observarse que el desempe
˜
no
es aceptable, manteniendo los
´
angulos de pitch y roll con
0.5 grados respecto de la referencia en estado de vuelo
estacionario; mientras que las maniobras las sigue apropia-
damente. Por otro lado, para el
´
angulo de yaw tambi
´
en se
observa un buen comportamiento, siguiendo la referencia
correctamente.
10 15 20 25 30
Time [s]
-7
-6
-5
-4
-3
-2
-1
0
1
2
Orientation [°]
Pitch References and measured angle
pitch - measured
pitch - reference
Figura 8.
´
Angulo de pitch: Medido y Referencia.
15 20 25 30 35
Time [s]
-8
-6
-4
-2
0
2
4
6
Orientation [°]
Roll References and measured angle
roll - measured
roll - reference
Figura 9.
´
Angulo de roll: Medido y Referencia.
En cuando a la robustez del control, en la figura 11
se muestra el rechazo a una perturbaci
´
on que se introdujo
golpeando uno de los brazos del veh
´
ıculo durante un vuelo.
Puede apreciarse que el veh
´
ıculo se recupera bien, sin
oscilaciones y en un tiempo adecuado.
Revista elektron, Vol. 3, No. 1, pp. 29-38 (2019)
ISSN 2525-0159
36
http://elektron.fi.uba.ar
50 60 70 80 90 100 110
Time [s]
0
1
2
3
4
5
6
7
Orientación [°]
Vuelo típico
Yaw: Referencia - Mediddo
Yaw - Medido
Yaw - Referencia
Figura 10.
´
Angulo de yaw: Medido y Referencia.
50 55 60 65 70 75 80 85 90
Time [s]
-6
-4
-2
0
2
4
6
8
Orientation [°]
Pitch disturbance rejection
pitch - measured
pitch - reference
Figura 11. Rechazo a perturbaciones en pitch.
V-B. Desempe
˜
no del AP en un veh
´
ıculo acu
´
atico
El segundo experimento fue realizado utilizando un
veh
´
ıculo acu
´
atico de superficie. Como validaci
´
on del sistema
desarrollado se propone realizar el relevamiento topogr
´
afico
de la costa del arroyo ”Las Hermanas”, ubicado en la ciudad
de Ramallo, provincia de Buenos Aires, Argentina. Para esta
tarea se utiliza un sensor l
´
aser para medir distancia (LIDAR),
los datos de una IMU, provenientes del AP desarrollado, y
un sistema basado en ROS. El LIDAR utilizado es de la
firma Hokuyo, posee un rango de funcionamiento m
´
aximo
de 5 metros. Este sensor es montado en el marco vertical del
veh
´
ıculo y se lo ubica apuntando hacia el costado derecho
del ASV. De este modo el SLAM se produce utilizando solo
una costa del arroyo. En la figura 12 se observa el montaje
del LIDAR en el veh
´
ıculo.
En estas pruebas el veh
´
ıculo es controlado por un ope-
rador en la costa, en modo manual, a baja velocidad y
cerca de la costa, de modo que el LIDAR obtenga datos
v
´
alidos. Todos los datos son grabados para un posterior
procesamiento en modo off-line.
A bordo del veh
´
ıculo se instal
´
o una Raspberry Pi 3B+, que
corre un sistema operativo Linux con el sistema ROS. Esta
placa se utiliza para recolectar la informaci
´
on del LIDAR
Figura 12. Montaje del sensor principal del ASV.
y almacenarla en un archivo bag-file de ROS. Adem
´
as se
adquiere informaci
´
on proveniente de la IMU de la Cho-
riboard, que se utiliza para compensar el movimiento del
sistema y mejorar el c
´
alculo de la trayectoria del veh
´
ıculo
en el procesamiento de la informaci
´
on del LIDAR. El
rosserial simplifica el trabajo, dado que permite adquirir la
informaci
´
on de la IMU directamente en un nodo de ROS
en la Raspberry y guardar esta informaci
´
on junto con la del
LIDAR para su post-procesamiento. Los datos almacenados
en la Raspberry son post-procesados en una PC usando el
paquete Google Cartographer [28].
En la figura 13 se muestra la superposici
´
on del mapa
obtenido utilizando el Google Cartographer, sobre un mapa
de un servicio satelital, en este caso Google Maps.
Figura 13. Mapa obtenido por Google Cartographer e imagen satelital.
VI. CONCLUSIONES
En este trabajo se present
´
o una actualizaci
´
on del auto-
piloto Choriboard, el cual es m
´
as liviano y posee mayor
potencia de c
´
omputo que las versiones previas.
El tama
˜
no compacto y la compatibilidad de sus conectores
con dispositivos y sensores comerciales le dan una gran
versatilidad, permitiendo su uso en peque
˜
nos veh
´
ıculos
a
´
ereos no tripulados y otros robots m
´
oviles. Como valida-
ci
´
on experimental, se instal
´
o el autopiloto en un veh
´
ıculo
Revista elektron, Vol. 3, No. 1, pp. 29-38 (2019)
ISSN 2525-0159
37
http://elektron.fi.uba.ar
a
´
ereo no tripulado y un veh
´
ıculo acu
´
atico de superficie,
mostrando su correcto funcionamiento. El firmware utilizado
para controlar los veh
´
ıculos tambi
´
en ha sido desarrollado por
nuestro grupo.
El uso de un dise
˜
no propio de hardware y software,
permite un mayor control sobre el funcionamiento del au-
topiloto. Esta flexibilidad permite tener un control a bajo
nivel de los tiempos de ejecuci
´
on de cada una de las tareas,
o poder introducir herramientas de validaci
´
on de software,
que permiten evaluar el desempe
˜
no de algoritmos y t
´
ecnicas
de dise
˜
no, principalmente con un prop
´
osito acad
´
emico.
Teniendo en cuenta las similitudes con otros autopilo-
tos como el Pixhawk, es pertinente preguntarse sobre la
necesidad de desarrollar una nueva versi
´
on del autopilo-
to Choriboard. La primera versi
´
on de la Choriboard fue
desarrollada en 2013, en el marco de un Proyecto de
Desarrollo Tecnol
´
ogico y Social, financiado por la Uni-
versidad de Buenos Aires. El prop
´
osito de este proyecto
era demostrar la factibilidad de desarrollar en el pa
´
ıs esta
tecnolog
´
ıa. Pero adem
´
as, este desarrollo gener
´
o varias tesis
de grado y posgrado, diversas investigaciones relacionadas
con algoritmos de navegaci
´
on, guiado y control, estudio
de sistemas tolerantes a fallas, y m
´
etodos de detecci
´
on y
correcci
´
on de errores, entre otros proyectos. Esto demuestra
la importancia de incentivar este tipo de desarrollos en el
pa
´
ıs, y el impacto positivo que han tenido para el desarrollo
de estas tecnolog
´
ıas. M
´
as a
´
un, esta nueva actualizaci
´
on
del autopiloto gener
´
o una fruct
´
ıfera colaboraci
´
on entre dos
grupos de investigaci
´
on, que se espera que crezca y que se
sumen en el futuro otros grupos de investigaci
´
on.
REFERENCIAS
[1] S. Bertram, C. Kitts, D. Azevedo, G. D. Vecchio, B. Hopner,
G. Wheat, and W. Kirkwood, “A portable asv prototype for shallow-
water science operations,” in OCEANS 2016 MTS/IEEE Monterey,
Sept 2016, pp. 1–6.
[2] G. G. Acosta, B. Menna, R. de La Vega, L. Arrien, H. Curti, S. Villar,
R. Leegstra, M. D. Paula, I. Carlucho, F. Solari, and A. Rozenfeld,
“Macabot: prototipo de veh
´
ıculo autonomo de superficie,” in XI
Jornadas Argentinas de Rob
´
otica, Nov. 2017.
[3] S. Manjanna, A. Q. Li, R. N. Smith, I. Rekleitis, and G. Dudek,
“Heterogeneous multi-robot system for exploration and strategic
water sampling,” in IEEE International Conference on Robotics and
Automation (ICRA), 2018.
[4] J. Moulton, N. Karapetyan, A. Q. Li, and I. Rekleitis, “External force
field modeling for autonomous surface vehicles,” in International
Symposium on Experimental Robotics, Nov. 2018.
[5] G. Jiang, R. M. Voyles, and J. J. Choi, “Precision fully-actuated
uav for visual and physical inspection of structures for nuclear
decommissioning and search and rescue,” in 2018 IEEE International
Symposium on Safety, Security, and Rescue Robotics (SSRR), Aug
2018, pp. 1–7.
[6] J. Rojas, C. Devia, E. Petro, C. Martinez, I. Mondragon, D. Patino,
M. C. Rebolledo, and J. Colorado, “Aerial mapping of rice crops
using mosaicing techniques for vegetative index monitoring,” in 2018
International Conference on Unmanned Aircraft Systems (ICUAS),
June 2018, pp. 846–855.
[7] D. C. Guastella, L. Cantelli, C. D. Melita, and G. Muscato, “A
global path planning strategy for a ugv from aerial elevation maps
for disaster response,” in ICAART, 2017.
[8] P. Addabbo, A. Angrisano, M. L. Bernardi, G. Gagliarde, A. Menne-
lla, M. Nisi, and S. Ullo, “A uav infrared measurement approach for
defect detection in photovoltaic plants,” in 2017 IEEE International
Workshop on Metrology for AeroSpace (MetroAeroSpace), June 2017,
pp. 345–350.
[9] T. Fossen, K. Pettersen, and H. Nijmeijer, Sensing and Control for
Autonomous Vehicles. Springer, 2017.
[10] “Pixhawk, an open source autopilot.” [Online]. Available:
https://pixhawk.org/
[11] “ArduPilot, an open source autopilot.” [Online]. Available:
http://ardupilot.org/
[12] “DJI Naze v M-2.” [Online]. Available: https://www.dji.com/naza-
m-v2
[13] Z. Yang, F. Lin, and B. Chen, “Survey of autopilot for multi-rotor
unmanned aerial vehicles,” in 42nd Annual Conference of the IEEE
Industrial Electronics Society, 10 2016, pp. 6122–6127.
[14] “Grupo de Procesamiento de Se
˜
nales, Identificaci
´
on y Control.”
[Online]. Available: http://psic.fi.uba.ar
[15] “Grupo de Estudio de Sistemas de Control.” [Online]. Available:
https://www.facebook.com/gesic.frsn/
[16] F. Roasio, Dise
˜
no de un sistema de navegaci
´
on integrada para un
UAV. Tesis de Grado, Facultad de Ingenier
´
ıa de la Universidad de
Buenos Aires, 2013.
[17] C. Pose, Desarrollo de algoritmos de navegaci
´
on y control para un
veh
´
ıculo a
´
ereo aut
´
onomo. Tesis de Grado, Facultad de Ingenier
´
ıa
de la Universidad de Buenos Aires, 2014.
[18] A. Kharsansky, Dise
˜
no e implementaci
´
on de un sistema embebido de
control de actitud para aeronaves no tripuladas. Tesis de Grado,
Facultad de Ingenier
´
ıa de la Universidad de Buenos Aires, 2013.
[19] J. Luiso, Desarrollo de un sensor de flujo
´
optico. Tesis de Grado,
Facultad de Ingenier
´
ıa de la Universidad de Buenos Aires, 2016.
[20] J. E. Luiso and J. I. Giribet, “Sensor de flujo
´
optico,” in Reuni
´
on de
Procesamiento de la Informaci
´
on y Control (RPIC), 2017.
[21] A. Tournour, Control de un veh
´
ıculo a
´
ereo no tripulado utilizando
informaci
´
on de flujo
´
optico. Tesis de Grado, Facultad de Ingenier
´
ıa
de la Universidad de Buenos Aires, 2018.
[22] “ROS serial: a protocol for wrapping standard ROS serialized
messages.” [Online]. Available: http://wiki.ros.org/rosserial
[23] L. Garberoglio, P. Moreno, J. I. Giribet, and I. Mas, “Autonomous
vehicles for outdoor multidomain mapping,” in IEEE Biennial Con-
gress of Argentina (ARGENCON), 2018.
[24] J.-M. P. R. Mahony, T. Hamel, “Nonlinear complementary filters
on the special orthogonal group,” IEEE Transaction on Automatic
Control, vol. 53, no. 5, pp. 1203–1218, 2008.
[25] G. Strang, Introduction to Linear Algebra. Wellesley-Cambridge
Press., 2016.
[26] J. Li and Y. Li, “Dynamic analysis and pid control for a quadrotor,”
in Mechatronics and Automation (ICMA), 2011 International Confe-
rence on. IEEE, 2011, pp. 573–578.
[27] “Choriboard V3 - Autopilot.” [Online]. Available:
https://www.youtube.com/watch?v=MgewmB 4lAg
[28] W. Hess, D. Kohler, H. Rapp, and D. Andor, “Real-time loop closure
in 2d lidar slam,” in 2016 IEEE International Conference on Robotics
and Automation (ICRA), May 2016, pp. 1271–1278.
Revista elektron, Vol. 3, No. 1, pp. 29-38 (2019)
ISSN 2525-0159
38
http://elektron.fi.uba.ar
Enlaces de Referencia
- Por el momento, no existen enlaces de referencia
Copyright (c) 2019 Leonardo Garberoglio, Claudio Pose, Ignacio Mas, Juan Ignacio Giribet
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Revista elektron, ISSN-L 2525-0159
Facultad de Ingeniería. Universidad de Buenos Aires
Paseo Colón 850, 3er piso
C1063ACV - Buenos Aires - Argentina
revista.elektron@fi.uba.ar
+54 (11) 528-50889