Infraestructura para el desarrollo de laboratorios
remotos
Remote Laboratories Development Framework
Marco Miretti
†1
, Emanuel Bernardi
†2
†
AC&ES - Research Group, Universidad Tecnol
´
ogica Nacional Facultad Regional San Francisco
San Francisco, C
´
ordoba, Argentina
1
mmiretti@sanfrancisco.utn.edu.ar
2
ebernardi@sanfrancisco.utn.edu.ar
Resumen—El presente trabajo se fundamenta en la ense
˜
nanza
a trav
´
es de experiencias remotas. El mismo plantea el desar-
rollo de una infraestructura de aprendizaje a distancia medi-
ante la construcci
´
on de laboratorios remotos de forma vers
´
atil,
escalable y asequible, al apoyarse en la democratizaci
´
on de la
tecnolog
´
ıa.
Si bien la propuesta es aplicable a un sinn
´
umero de ramas
de la ciencia, con el fin de proveer un prototipo funcional,
´
este se implement
´
o para la ense
˜
nanza de sistemas de control.
En consecuencia,
´
este consiste en la construcci
´
on de un
sistema din
´
amico, t
´
ıpico del
´
area. Adem
´
as, cuenta con una
interfaz de programaci
´
on de aplicaci
´
on (API) que permite a
los estudiantes desarrollar sus propios algoritmos de control,
utilizando lenguajes de alto nivel, como son Python y GNU
Octave, prescindiendo de competencias afines a los sistemas
embebidos y a las redes de comunicaci
´
on.
Palabras clave: educaci
´
on; experimentaci
´
on remota; sistemas
de control.
Abstract—The present work is based on teaching through
remote experiences. It proposes the development of a
distance learning infrastructure by the construction of remote
laboratories in a versatile, scalable and affordable way, by
relying on the technology democratization.
Although the proposal is applicable to countless areas of
science, in order to provide a functional prototype, it was
implemented for teaching control systems. Consequently, this
consists of the construction of a dynamic system, typical of
the area. In addition, it has an application programming
interface (API) that allows students to develop their own
control algorithms, using high-level languages, such as Python
and GNU Octave, regardless of related skills to embedded
systems and communication networks.
Keywords: education; remote experimentation; control
systems.
I. INTRODUCCI
´
ON
La experimentaci
´
on como herramienta de aprendizaje, es
en s
´
ı un m
´
etodo sumamente enriquecedor, que al ser com-
plementada con conceptos te
´
oricos posibilita la generaci
´
on
de resultados sobresalientes. Este aspecto es particularmente
relevante en
´
areas de formaci
´
on ingenieril, donde realizar
ensayos pr
´
acticos constituye una parte
´
ıntegra del estudio
[1]. Entonces, a la hora de percibir un fen
´
omeno, u ob-
servar el comportamiento de un sistema, la pr
´
actica resulta
mandatoria. Adicionalmente, el acceso remoto al material
educativo ha demostrado ser de gran utilidad durante el brote
de COVID-19.
En base a los fundamentos mencionados, a trav
´
es de este
trabajo se plantea el desarrollo de una infraestructura de
laboratorios remotos para la ense
˜
nanza en la ingenier
´
ıa, con
la aplicaci
´
on particular a los sistemas de control. A modo
de justificar el desarrollo, se construy
´
o un sistema din
´
amico
prototipo que permite el ensayo y evaluaci
´
on de las t
´
ecnicas
de control instruidas (tales como PID
1
, MPC
2
, entre otras).
As
´
ı, el prop
´
osito de esta metodolog
´
ıa de ense
˜
nanza es
permitir que el estudiante se instruya de forma aut
´
onoma y
descentralizada, posibilitando el acceso a los experimentos
de forma remota e ininterrumpida. Particularmente, con
la implementaci
´
on de este sistema el estudiante tiene a
su alcance la capacidad de aplicar m
´
ultiples t
´
ecnicas de
control [2]–[4], siendo prescindible la experiencia en la
programaci
´
on de bajo nivel, i.e. programaci
´
on de sistemas
embebidos, configuraci
´
on de las comunicaciones, etc. Para
ello, el desarrollo contempla el dise
˜
no de librer
´
ıas intuitivas
y simples de utilizar, implementadas en los lenguajes GNU
Octave y Python, de modo que para su utilizaci
´
on solo
ser
´
an necesarios conocimientos m
´
ınimos de programaci
´
on.
Se eligieron estos lenguajes debido a que los mismos poseen
extensos paquetes dedicados al control de procesos. Esto
es, mientras que GNU Octave resulta ampliamente popular
entre los investigadores de las
´
areas afines, Python posee una
gran tracci
´
on por parte de la comunidad desarrolladora de
software libre. Adem
´
as, para el caso de GNU Octave existen
proyectos para llevar la accesibilidad un paso adelante, como
por ejemplo el desarrollo de una interfaz gr
´
afica de usuario
GUI
3
para la ense
˜
nanza de control de procesos [5].
En la Figura 1 se plasma la infraestructura b
´
asica
planteada, como as
´
ı tambi
´
en su alcance. La misma demues-
tra como los estudiantes acceden a experimentos de forma
remota a trav
´
es de internet, utilizando como intermediario
un servidor remoto, en este caso implementado sobre una
Raspberry Pi (aunque puede funcionar en cualquier com-
putador que ofrezca una interfaz WiFi y un sistema operativo
basado en GNU Linux). Los experimentos remotos se comu-
nican con dicho servidor mediante plataformas embebidas
1
Del ingl
´
es, Proportional-Integral-Derivative
2
Del ingl
´
es, Model Predictive Control.
3
Del ingl
´
es, Graphical User Interface
Recibido: 27/02/22; Aceptado: 14/05/22
Creative Commons License - Attribution-NonCommercial-
NoDerivatives 4.0 International (CC BY-NC-ND 4.0)
https://doi.org/10.37537/rev.elektron.6.1.143.2022
Original Article
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
8
e
s
p
8
2
6
6
e
s
p
8
2
6
6
e
s
p
8
2
6
6
Fig. 1. Mapa del sistema completo
ESP8266, permitiendo el comando de actuadores y la lectura
de sensores.
De esta forma sus usuarios, los estudiantes, tienen acceso
continuo a la experimentaci
´
on, sobre fen
´
omenos f
´
ısicos
aut
´
enticos. Permiti
´
endoles aplicar sus conocimientos sobre
infinidad de sistemas.
II. ESTADO DEL ARTE
Los laboratorios remotos no son nuevos, desde la in-
venci
´
on de internet en los 70’ se han propuesto y desar-
rollado incontables soluciones con una gran variedad de
enfoques. As
´
ı tambi
´
en trabajos como [6] y [7] han relevado
el estado del arte de dichas tecnolog
´
ıas, adem
´
as de analizar
sus puntos comunes, y diferencias m
´
as notables. Dicho
estudio sirve como un punto de referencia para este an
´
alisis.
Es de destacar, que los laboratorios encontrados con
mayor frecuencia se corresponden a competencias relevantes
a la Ingenier
´
ıa Electr
´
onica (microelectr
´
onica, rob
´
otica, con-
trol, sistemas embebidos) [8]. La arquitectura hallada en
´
estos trabajos se basa en el paradigma cliente-servidor,
con un laboratorio actuando como servidor en el extremo
remoto, y una aplicaci
´
on cliente en el extremo del usuario.
Dentro de dicho paradigma existen gran variedad de ar-
quitecturas, incluyendo una basada en servicios web REST
4
,
obteniendo buenos resultados [9]. Otra, como la que propone
[10] se encuentra orientada a servicios, favoreciendo la
abstracci
´
on y, por lo tanto, la modularizaci
´
on de los mismos.
En tanto, [11] plantea la compatibilidad de los laboratorios
remotos con los dispositivos inteligentes, con el fin obtener
un mayor alcance.
A. Construcci
´
on y topolog
´
ıas
Seg
´
un analiza [12], los experimentos a realizar en labo-
ratorios remotos se dividen en dos grupos:
• Experimentos “
´
unicos en su clase” o dif
´
ıciles de
replicar debido a su costo y complejidad.
• Experimentos de bajo costo, f
´
acilmente replicables.
Luego, [13] caracteriza los laboratorios remotos dividi-
endo su topolog
´
ıa en dos tipos principales:
• Aplicaciones web.
• Aplicaciones dedicadas de control remoto.
Las aplicaciones web, suelen ser est
´
andares y requerir
menos dependencias del lado del cliente. Una aplicaci
´
on
4
Del ingl
´
es, Representational State Transfer.
dedicada, si bien a veces provee una mejor interfaz de
usuario, viene aparejada de dependencias de software e
incompatibilidades.
Del lado del cliente, propone dos enfoques:
• Aplicaciones intrusivas, con permisos de acceso. (ac-
cesos por SSH
5
)
• Aplicaciones no-intrusivas, tales como accesos a trav
´
es
del navegador.
Las primeras permiten una interacci
´
on mas fluida y mejor
experiencia de usuario, teniendo en muchos casos acceso
total a la informaci
´
on de sensores y actuadores, aunque
acompa
˜
nados de riesgos de seguridad. Las aplicaciones
no-intrusivas solucionan muchos de estos riesgos, con la
desventaja de ser menos interactivas.
Por
´
ultimo, analizando la comunicaci
´
on servidor-
experimento se hallan dos soluciones:
• Software propietario, tal como LabView o MAT-
LAB/Simulink.
• Software libre, com
´
unmente de prop
´
osito general como
C, C++ o Python.
B. Ejemplos de aplicaci
´
on
El campo de aplicaci
´
on de los laboratorios remotos es
muy extenso, y tal como se mencion
´
o previamente, su
uso es frecuente en las competencias afines a la Ingenier
´
ıa
Electr
´
onica. De esta forma, existen muchos tipos de labora-
torios:
• Para el
´
area de la microelectr
´
onica y el dise
˜
no de
microcontroladores, basados en FPGAs
6
[14].
• Para experiencias afines a la f
´
ısica y
´
optica [15].
• En el
´
area de la electr
´
onica de potencia, bancos de
prueba remotos en donde el usuario puede elegir la
estructura de control y obtener resultados gr
´
aficos en
tiempo real [16].
• En el campo de los sistemas embebidos, produciendo
laboratorios sencillos y f
´
aciles de replicar como por
ejemplo el “lab-in-a-box” (laboratorio en una caja)
presentado por [17].
• En la ense
˜
nanza de los sistemas de control, cuyos
conceptos te
´
oricos requieren de la pr
´
actica para que
el estudiante logre asimilarlos [6], existe una gran var-
iedad de soluciones y estudios dedicados a los mismos
[18]. La gran mayor
´
ıa de estos experimentos remotos
solo permiten al estudiante elegir, a partir un grupo
preestablecido, una estrategia de control y regular sus
par
´
ametros [19], [20], sin embargo hay unos pocos
enfoques como el ACT
7
que no solo permiten esto,
sino tambi
´
en dan la posibilidad al alumno de dise
˜
nar
sus propios algoritmos y probarlos en una gran variedad
de sistemas din
´
amicos (levitador magn
´
etico, sistema de
tanques de agua, motores y simulador de helic
´
optero)
[21].
III. PROPUESTA
Para comprender este desarrollo es fundamental entender
que el mismo no busca crear un experimento espec
´
ıfico,
5
Del ingl
´
es, Secure Shell.
6
Del ingl
´
es, Field-Programmable Gate Array
7
Del ingl
´
es, Automatic Control Telelab
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
9
http://elektron.fi.uba.ar
del
´
area de control o explicar como dicho experimento es
utilizado por los docentes y estudiantes para enriquecer
el aprendizaje. El proyecto se desarroll
´
o para presentar
una soluci
´
on a preguntas de mayor envergadura: ¿C
´
omo
puede cualquier desarrollador
8
construir una plataforma de
experimentaci
´
on remota? ¿Qu
´
e gu
´
ıa y cuales herramientas
debe tener a su alcance?
El resultado, como el t
´
ıtulo indica es una infraestructura
para la creaci
´
on de laboratorios remotos.
Con el fin de refinar dicha infraestructura, se construy
´
o un
experimento remoto de ejemplo, que sirvi
´
o como base para
detectar las necesidades de un laboratorio remoto, ayudando
a formar una metodolog
´
ıa de desarrollo replicable. Este
experimento sirve tambi
´
en de prueba de concepto, poniendo
en pr
´
actica las bondades de la infraestructura propuesta.
IV. DESCRIPCI
´
ON DE LOS COMPONENTES
En la Figura 2 se aprecian los diferentes componentes
involucrados. Se hace
´
enfasis en el vasto contenido de
software y firmware en los mismos, uno de los pilares m
´
as
importantes en este trabajo.
e
s
p
8
2
6
6
drivers
interfaces de red
RTOS
telemetría
configuración
logging
comunicación
interfaz de usuario
empaquetado
alto nivel
portabilidad
Fig. 2. Mapa de componentes.
A la izquierda est
´
a representado el experimento, que a
trav
´
es de una conexi
´
on local se comunica con el servidor
intermedio. Este
´
ultimo se comunica mediante una red de
´
area amplia (internet) con el usuario final, representado
como la burbuja de la derecha.
El laboratorio remoto no es
´
unicamente el experimento,
sino tambi
´
en el servidor intermedio, la conexi
´
on con el
usuario final y el software que se ejecuta en cada uno de
los dispositivos.
A. Experimento
Detalladamente, el experimento consiste en un sistema
embebido basado en la plataforma ESP8266, el cual es el
encargado de comandar sensores y actuadores. Luego, la
naturaleza del sistema din
´
amico variar
´
a seg
´
un con que se
quiera experimentar, algunos ejemplos son:
• Resistencias y capacitores formado configuraciones de
filtros, con entradas comandadas por se
˜
nales PWM y
medidos con puertos anal
´
ogicos, para pr
´
acticas en el
´
area de Se
˜
nales y Sistemas.
8
Para estos fines se considera desarrollador a un docente, estudiante,
programador o grupo multidisciplinario, con nociones b
´
asicas de progra-
maci
´
on.
• Otro sistema embebido de inter
´
es, para una experiencia
en el
´
area de T
´
ecnicas Digitales.
• Un sistema termodin
´
amico, como una resistencia cale-
factora y un sensor de temperatura LM-35, utilizando
las interfaces PWM y 1-Wire, para la experimentaci
´
on
en Sistemas de Control.
• Un p
´
endulo aeropropulsado, conectado mediante la
interfaz PWM para su comando, y midiendo su
´
angulo
a trav
´
es de un encoder, utilizando la interfaz GPIO con
interrupciones.
Tanto para estos ejemplos, como para muchos otros posi-
bles, es necesario que la infraestructura cumpla con ciertas
condiciones, respecto al sistema embebido y su firmware.
Esto es:
• Debe tener la capacidad de interactuar sus interfaces
para comandar las entradas y leer las salidas de los
elementos conectados.
• Debe posibilitar la exposici
´
on de la informaci
´
on
recibida desde los dispositivos conectados, para que la
misma llegue al usuario final. Como as
´
ı tambi
´
en utilizar
la informaci
´
on indicada por el usuario para comandar
los actuadores indicados.
• La comunicaci
´
on con el cliente debe ser lo suficiente-
mente
´
agil para satisfacer las necesidades del sistema
din
´
amico.
• Debe soportar un sistema operativo de tiempo real, con
capacidad de crear y ejecutar tareas.
• Debe tener una interfaz clara de comando y configu-
raci
´
on.
• Debe generar logs, a ser consultados por el usuario,
para entender su funcionamiento, como tambi
´
en por el
programador del experimento en la etapa de desarrollo.
Para cumplir con estos requisitos se program
´
o un
Firmware basado en FreeRTOS, permitiendo la creaci
´
on de
m
´
ultiples tareas. Para ello, posee una librer
´
ıa de drivers
para comunicar el dispositivo embebido con sus sensores
y actuadores a trav
´
es de interfaces GPIO, SPI, I2C, PWM,
1-Wire y con libertad suficiente para otras espec
´
ıficas como;
interfaz de encoder angular incremental, interfaz de coman-
dos y PWM para controladores de motores sin escobillas.
Adem
´
as, tiene la capacidad de comunicaci
´
on HTTP y
Websockets para configuraciones y telemetr
´
ıa respectiva-
mente, pudiendo as
´
ı ser comandado y le
´
ıdo por el usuario
final con la confianza y velocidad necesarias.
Finalmente, el embebido tiene la capacidad de logging a
trav
´
es de la interfaz UART.
B. Cliente-servidor intermedio
En esta infraestructura es necesario un dispositivo in-
termedio que se encargue de recolectar informaci
´
on de
los experimentos presentes en su red y transmitirla a los
usuarios correspondientes. Para este prop
´
osito se utiliz
´
o
una plataforma Raspberry PI 4B, aunque el software nece-
sario para que cumpla su prop
´
osito puede ser instalado en
cualquier computador con un sistema operativo basado en
linux y una interfaz de red WiFi.
Sus requisitos m
´
ınimos para cualquier laboratorio remoto
son:
• Capacidad de comunicarse con el dispositivo embebido.
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
10
http://elektron.fi.uba.ar
• Memoria y capacidad de procesamiento suficiente para
almacenar, preprocesar y retransmitir la informaci
´
on.
• Posibilidad de comunicarse con el usuario final.
El software que se cre
´
o a partir de estos requerimientos
permite que un programa escrito en los lenguajes Python
u Octave, provisto por el usuario final, se ejecute en el
servidor intermedio y se comunique con el embebido a
trav
´
es de HTTP y Websockets. Los paquetes de software
multiplataforma que se generaron con este objetivo son
Nyquist y Octave Websockets, publicados en el gestor de
paquetes pip para Python y en el
´
ındice oficial de paquetes
de Octave, respectivamente.
Adem
´
as, para este computador se desarroll
´
o un software
que permite abrir una conexi
´
on SSH o de Jupyter Notebook
con el usuario final, permitiendo ser invocado por este
´
ultimo
a trav
´
es de una plataforma de mensajer
´
ıa como Discord.
De esta forma, el usuario final podr
´
a comandar el sistema
embebido como si fuese el servidor intermedio.
V. ELECCI
´
ON DE hardware
Debido a que en cada experimento se requiere implemen-
tar un sistema de bajo costo, con recursos computacionales
entre bajos y moderados, y conexi
´
on WLAN, se opt
´
o por
utilizar un sistema embebido basado en el microprocesador
ESP8266. Dicha plataforma cuenta con soporte f
´
ısico Wi-Fi
y stack TCP/IP, a un costo m
´
ınimo.
As
´
ı, desde el punto de vista de los elementos de hardware,
´
estos se componen en una gran variedad de breakouts.
Particularmente, se opt
´
o por el dispositivo WeMos-D1 mini,
ya que su tama
˜
no resulta ventajoso al momento de dise
˜
nar
experimentos modulares, y la cantidad de pines disponibles
se considera suficiente para estas aplicaciones.
VI. FIRMWARE
Por otro lado, en lo que concierne al firmware existen
numerosos y amplios kits de desarrollo, que proporcionan
drivers y librer
´
ıas que resuelven los aspectos de m
´
as bajo
nivel.
A. Entorno de desarrollo y RTOS
Con entorno de desarrollo nos referimos a aquellos drivers
y bibliotecas de software que resuelven las secciones de bajo
nivel. El framework elegido es el esp-open-rtos, un entorno
basado en el sistema operativo de tiempo real FreeRTOS,
escrito en lenguaje C y acompa
˜
nado por complementos
extras, los que contemplan desde el manejo de la interfaz
PWM hasta servidores HTTP.
Es de destacar la existencia de numerosos frame-
works para este microprocesador. Siendo otras alternativas
disponibles:
• ESP866 RTOS SDK: tambi
´
en basado en FreeRTOS,
con soporte oficial de espressif y documentaci
´
on sobre-
saliente. Se descart
´
o por parecer poco versatil, en caso
de incorporar funcionalidades no contempladas. Un
ejemplo claro de esto es el requisito de comunicaci
´
on
por Websockets.
• esp-idf : soportado oficialmente por espressif, ex-
tremadamente amplio y vers
´
atil. Documentado minu-
ciosamente. Se descart
´
o ya que fue deprecado para el
chip ESP8266 en etapas tempranas de su desarrollo,
soportando
´
unicamente microprocesadores de la gama
ESP32.
Por
´
ultimo, para favorecer la replicabilidad, y facilitar
la creaci
´
on de experimentos por parte de nuevos desarrol-
ladores, se generaron im
´
agenes de Docker, una de ellas con
las herramientas de compilaci
´
on necesarias y las bibliotecas
de software ya incluidas, otra con la capacidad de grabar me-
diante UART binarios ya compilados en un microprocesador
ESP8266. Todo esto, junto con las instrucciones de uso se
encuentran en la documentaci
´
on del proyecto, almacenado
en GitLab [22].
B. Redes y comunicaci
´
on
En esta secci
´
on se describe fundamentalmente la comuni-
caci
´
on entre el experimento y la computadora de alto nivel
que act
´
ua como servidor remoto. En tanto, la conexi
´
on entre
el usuario y dicho servidor ser
´
a omitida ya que no resulta
relevante en este contexto.
Con el objetivo de comunicar tanto comandos, config-
uraciones, como se
˜
nales de control y medici
´
on, entre el
experimento y el servidor se utilizaron dos protocolos.
• HTTP: para comunicar todo tipo de se
˜
nales de config-
uraci
´
on, cuya latencia no es necesariamente un factor
determinante, pero si lo son los c
´
odigos de error
reportados luego de aplicar las mismas.
• Websockets: para enviar se
˜
nales de comando a los
actuadores y recibir informaci
´
on de los sensores. Este
tipo de se
˜
nales requieren una latencia reducida.
As
´
ı, para la gesti
´
on de configuraciones se opt
´
o por un
patr
´
on de mensajer
´
ıa request-response y se cre
´
o una API-
REST
9
[23], con el objetivo de mejorar la escalabilidad,
simplicidad, versatilidad y portabilidad. Adem
´
as, se gener
´
o
una especificaci
´
on OpenAPI [24].
Por el contrario, en el caso de las se
˜
nales transmitidas
a trav
´
es de Websockets, se eligi
´
o un patr
´
on del estilo
publish-subscribe, donde cada dispositivo env
´
ıa paquetes
de telemetr
´
ıa encapsulados con formato JSON. La latencia
observada entre fuente y destino para un paquete con la
informaci
´
on de un par de sensores o actuadores es de 10 ms
aproximadamente, lo que se considera satisfactorio para el
com
´
un de los experimentos contemplados por la propuesta.
El patr
´
on de comunicaci
´
on y su secuencia de inicializaci
´
on
se observan en la Figura 3.
Tal como se aprecia en el diagrama de secuencia de la
Figura 3, la comunicaci
´
on es iniciada por el cliente (Nodo
Central), abriendo un Websocket. Al hacer esto, el lazo
principal del firmware presente en el m
´
odulo ESP crea un
nuevo hilo de ejecuci
´
on para la rutina seleccionada seg
´
un la
direcci
´
on del socket abierto. As
´
ı, dicha rutina o task, queda
ligada a las comunicaciones correspondientes.
La secuencia que se muestra se corresponde con el caso
t
´
ıpico de un sistema de control comandado por el sistema
embebido. En este, el algoritmo de control se comunica con
el sistema para asignar valores a sus actuadores y recibe
informaci
´
on de los sensores, esto
´
ultimo solo en caso de
tratarse de un control a lazo cerrado.
Es de destacar que con este patr
´
on la comunicaci
´
on
no se bloquea la lectura de sensores o el comando de
9
Del ingl
´
es, Representational State Transfer
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
11
http://elektron.fi.uba.ar
Nodo Central M´odulo ESP Websocket Callback
Posiciones de memoria compartida
Rutina “X”
ws://exp/rutina-X
activar rutina “X”
Valores de sensores
Valores de actuadores
Valores de sensores
Valores de actuadores
Valores de sensoresComunicaci´on de control
Valores de actuadores
Valores de sensores
Valores de actuadores
Valores de sensores
Lazo de controlLazo de control
Fig. 3. Diagrama de secuencia para la comunicaci
´
on del experimento.
actuadores, y viceversa. Esto se debe al uso de una memoria
compartida. La tarea denominada “X” se encarga de leer los
sensores y almacenar la informaci
´
on adquirida de
´
estos en la
memoria compartida. De la misma forma, tomar
´
a los valores
correspondientes a los actuadores desde dicha fuente de
almacenamiento y accionar
´
a los elementos correspondientes
a trav
´
es de sus respectivos drivers (ver secci
´
on VI-H)
es importante remarcar que es posible que existan varias
tareas similares a “X”, que utilizar
´
an la informaci
´
on de
esta memoria compartida para diferentes prop
´
ositos, como
controlar los valores m
´
aximos comandados, detectar cuando
el experimento est
´
a fuera de rango, proporcionar un logging
constante (ver secci
´
on VI-G y secci
´
on VI-F).
Mientras la tarea “X” se est
´
a ejecutando, las llamadas de
Websockets entre el nodo central y el dispositivo embebido
se ejecutan en pseudo-paralelo
10
ESP8266
WS callbackWS callback
HTTP callbackHTTP callback
OrchestratorOrchestrator
Control taskControl task
Telemetry writerTelemetry writer
Central nodeCentral node
ActuatorsActuators
SensorsSensors
Command
Configs
Actuator data
Sensor data
Telemetry
Configs
Telemetry
Values
Commands
1
Fig. 4. Diagrama UML de componentes.
10
No pueden ejecutarse realmente en paralelo debido a que el dispositivo
embebido tiene un solo n
´
ucleo, sin embargo el RTOS orquesta los tiempos
de ejecuci
´
on de cada tarea, para que desde el punto de vista pr
´
actico se
pueda asumir que
´
estas se ejecutan de forma paralela.
En la Figura 4 se aprecian los componentes del sistema
embebido y sus interfaces. Como se explic
´
o, el embebido
se comunica con el nodo central de dos formas; mediante
preguntas y respuestas para configuraciones y comandos
one-shot, por otro lado, de forma publicar-subscribir para
transmitir informaci
´
on a alta velocidad para el control en
l
´
ınea. En tanto, con los sensores y actuadores, se comunica
mediante las interfaces disponibles (GPIO, SPI, I2C), seg
´
un
cada especificaci
´
on de los dispositivos que se conecten.
Internamente el dispositivo embebido comunica sus tareas
de tres formas, ya sea mediante una memoria compartida,
a trav
´
es de task-messages (provistos por el framework
FreeRTOS) o bien utilizando rutinas de interrupci
´
on.
C. Estructura de la telemetr
´
ıa
En casi cualquier dispositivo, es importante que la
telemetr
´
ıa tenga las siguientes caracter
´
ısticas:
• Parseabilidad.
• Escalabilidad.
• Observabilidad.
La parseabilidad se refiere a la capacidad de la telemetr
´
ıa
para ser procesada y almacenada en variables dentro de la
memoria de programa. Por otro lado, una comunicaci
´
on
escalable es vers
´
atil si es posible agregar, modificar o
eliminar variables en el futuro, sin romper la compatibilidad
del protocolo. Finalmente, la observabilidad consiste en
la capacidad de “espiar” cualquier canal de comunicaci
´
on
y leer lo que se est
´
a transmitiendo. En caso de nuevos
experimentos este
´
ultimo punto resulta muy
´
util durante la
etapa de desarrollo y reparaci
´
on de “bugs”.
Con el fin de cumplir estas condiciones, se eligi
´
o el
formato de intercambio de datos JSON
11
. A continuaci
´
on
se muestra la composici
´
on de la misma, proveniente del
experimento:
{"encoder": {"angle_deg": 30.255, "ts_ms": 1633306309135,
"code": 0}}
11
Del ingl
´
es, JavaScript Object Notation
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
12
http://elektron.fi.uba.ar
De la misma forma, se muestra la telemetr
´
ıa emitida desde
el nodo central:
{"propeller": {"pwm_duty": 10.3, "ts_ms": 1633306309147,
"code": 0}}
En este ejemplo, el dispositivo embebido decodifica el
JSON extrayendo los valores necesarios para comandar
el actuador (un propulsor cuyo driver recibe instrucciones
seg
´
un el duty de PWM). Luego utiliza los datos le
´
ıdos en
el sensor para generar la l
´
ınea de “encoder” que es emitida
por Websockets.
Con el objetivo de parsear los JSONs se gener
´
o una
librer
´
ıa a partir de un detokenizador primitivo llamado jsmn
[25]. El mismo es extremadamente limitado, pero posee un
gran potencial; ya que no tiene dependencias, es simple,
portable, y no requiere colocaci
´
on de memoria din
´
amica.
Extendiendo esta utilidad se logr
´
o una robusta y veloz
librer
´
ıa, apta para el caso de uso planteado.
D. Interfaz RESTful
En el experimento, las transiciones de estado se disparan
a trav
´
es de comandos HTTP, utilizando el estilo de ar-
quitectura REST. De esta forma, cada uno de los estados
o elementos de la configuraci
´
on presentes en el sistema
embebido est
´
an emparejados a un recurso HTTP, cuyas
transiciones se encuentran bien definidas, produciendo as
´
ı
una API.
Fig. 5. Documentaci
´
on OpenAPI del verbo POST para el recurso
propeller/pwm/status.
En la Figura 5 se aprecia la especificaci
´
on OpenAPI en
forma de documentaci
´
on HTML para los verbos POST de
un recurso.
A continuaci
´
on, se observa una interacci
´
on entre un
usuario y el experimento, en donde
´
este solicita que el
propulsor se inicialice y el experimento responde que su
requisito fue aceptado.
> curl "http://192.168.100.41/propeller/pwm/status?verb=
POST&value=initialized"
202 Accepted
De forma similar, el usuario puede no solo modificar el
estado de los recursos sino tambi
´
en consultarlo, t
´
ıpicamente
con el recurso GET. Esto se muestra a continuaci
´
on.
> curl "http://192.168.100.41/propeller/pwm/status?verb=
GET"
initialized
En dicho caso, el experimento responde con ”initialized”
para indicar que el recurso ya se encuentra inicializado.
Por supuesto, dicho estado era conocido, ya que el
´
ultimo
comando enviado hab
´
ıa confirmado la correcta inicializaci
´
on
en su respuesta.
De esta forma, el proyecto aprovecha las bondades del
protocolo HTTP. El cual permite realizar pedidos, ejecutar
porciones de c
´
odigo en el servidor embebido y dar una
respuesta adecuada en el c
´
odigo de error, por lo cual se lo
consider
´
o una opci
´
on sumamente robusta y apropiada para
realizar configuraciones o enviar comandos singulares, tal
como la inicializaci
´
on de un actuador. Mientras que para
la informaci
´
on de control, que no requiere una respuesta o
c
´
odigo de error, la informaci
´
on se env
´
ıa por Websockets,
una alternativa mucho mas veloz, aunque menos robusta en
cuanto a confirmaciones.
E. Performance de las comunicaciones
Como ya se ha mencionado, la soluci
´
on elegida para las
comunicaciones se trata de un sistema h
´
ıbrido, utilizando
los protocolos HTTP y Websockets. El primero, es utilizado
para la configuraci
´
on y comandos, mientras que el protocolo
Websockets se utiliza para la emisi
´
on de telemetr
´
ıa en forma
peri
´
odica, en cada uno de los hosts.
A continuaci
´
on se observa un paquete HTTP de configu-
raci
´
on luego de ser adquirido, utilizando el software tshark:
1.722 COMPUTADORA -> EXPERIMENTO TCP 54588 -> 80 [SYN]
1.741 EXPERIMENTO -> COMPUTADORA TCP 74 80 -> 54588 [SYN,
ACK]
3 1.741 COMPUTADORA -> EXPERIMENTO TCP 66 54588 -> 80 [ACK]
1.742 COMPUTADORA -> EXPERIMENTO HTTP 170 GET /logger/
level?value=LOG_INFO&verb=POST
1.761 EXPERIMENTO -> COMPUTADORA HTTP 185 202 Accepted (
text/plain)
1.762 COMPUTADORA -> EXPERIMENTO TCP 66 54588 -> 80 [FIN,
ACK]
1.765 EXPERIMENTO -> COMPUTADORA TCP 66 80 -> 54588 [ACK]
La primer columna indica el tiempo transcurrido en
segundos desde que se inici
´
o la adquisici
´
on. De inicio
a fin transcurren unos 43 milisegundos. All
´
ı se aprecia
como la comunicaci
´
on es orquestada utilizando el protocolo
HTTP, en donde numerosas verificaciones suceden entre
host y cliente, aumentando as
´
ı la confianza. De esta forma,
el tiempo transcurrido resulta m
´
as que satisfactorio para
prop
´
ositos de configuraci
´
on o comandos aislados.
Por otro lado, si consideramos que el computador interme-
diario tiene que consultar el valor de un sensor, procesar la
informaci
´
on y enviar el valor para que el embebido accione
los actuadores. El per
´
ıodo m
´
ınimo para el sistema de control
es:
T
min
= 2t
HT T P
+ t
proc
,
siendo t
HT T P
la latencia ocasionada por la comunicaci
´
on,
y t
proc
el tiempo de procesamiento. Es decir:
T
min
> 2t
HT T P
En un promedio realizado con 100 muestras, de endpoints
distintos t
proc
= 39 ms, lo que significa una frecuencia de
muestreo m
´
axima de 12.8 Hz. Demasiado lenta para algunos
sistemas de din
´
amicas muy veloces.
La alternativa que se eligi
´
o para solucionar este inconve-
niente, fue la de emitir los datos de sensores y actuadores
de forma constante y no solicitada, en forma de telemetr
´
ıa.
Es decir, se opt
´
o por un patr
´
on publish-subscribe en lugar
de request-response
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
13
http://elektron.fi.uba.ar
Dicha telemetr
´
ıa se env
´
ıa utilizando el protocolo Websock-
ets, que a diferencia de HTTP solo abre el puerto TCP al
inicio de cada comunicaci
´
on, evitando una gran cantidad de
mensajes de sincron
´
ıa y acknowledgement luego del primer
paquete.
El per
´
ıodo con el cual dicha telemetr
´
ıa es emitida es con-
figurable, en la adquisici
´
on que se muestra a continuaci
´
on,
se visualiza al experimento emitiendo la informaci
´
on de
sus sensores a aproximadamente 20 Hz, mientras que el
computador intermediario toma esta informaci
´
on, la procesa
y env
´
ıa los comandos para los actuadores antes que llegue
el paquete siguiente, cerrando as
´
ı un lazo de control a 20
Hz. El patr
´
on de las comunicaciones de telemtr
´
ıa se ven a
continuaci
´
on:
3.172 COMPUTADORA -> EXPERIMENTO WebSocket 90 WebSocket
Text [FIN] [MASKED]
3.196 EXPERIMENTO -> COMPUTADORA WebSocket 226 WebSocket
Text [FIN]
3 3.223 COMPUTADORA -> EXPERIMENTO WebSocket 90 WebSocket
Text [FIN] [MASKED]
3.240 EXPERIMENTO -> COMPUTADORA WebSocket 186 WebSocket
Text [FIN]
3.275 COMPUTADORA -> EXPERIMENTO WebSocket 90 WebSocket
Text [FIN] [MASKED]
3.301 EXPERIMENTO -> COMPUTADORA WebSocket 146 WebSocket
Text [FIN]
Es de destacar, que esta frecuencia ya incluye al tiempo
de procesamiento. Esto se debe a que el mismo se realiza
de manera no-bloqueante respecto de la comunicaci
´
on de
naturaleza asincr
´
onica.
Luego de las respectivas pruebas se concluy
´
o que esta
estrategia funciona sin problema alguno para lazos de hasta
100 Hz, lo que permite cubrir la gran mayor
´
ıa de los
sistemas f
´
ısicos de inter
´
es para un laboratorio remoto.
F. Logging y debug
El logging es una parte importante durante el proceso
de desarrollo, es por esto que el proyecto cuenta con una
librer
´
ıa para direccionar mensajes de depuraci
´
on por la
interfaz UART, o Bluetooth utilizando el m
´
odulo HC-08.
Esta biblioteca emite mensajes con contexto de hora, nivel
de alerta y l
´
ınea de c
´
odigo en la que fue generado. A
continuaci
´
on se muestra un ejemplo de los logs generados
por el experimento:
22:25:15 DEBUG lib/driver/src/encoder.c:72 GPIOs de
econder seteados como entrada
22:25:15 DEBUG tasks/src/send_telemetry.c:48 encoder
inicializado
22:25:17 WARNING callbacks/src/propeller_cgi.c:86
inicializando propulsor ...
4 22:25:17 INFO callbacks/src/propeller_cgi.c:93 propulsor
inicializado
Naturalmente, direccionar estos mensajes a trav
´
es de la
interfaz UART consume recursos del procesador. Es por esto
que es posible configurarse mediante variables de precompi-
lador, permitiendo as
´
ı imprimir
´
unicamente los mensajes con
nivel mayor o igual al seleccionado. Los niveles posibles, de
menor a mayor gravedad son; trace, debug, info, warning,
error y fatal.
G. Datos y memoria embebida
Las tareas relacionadas con la lectura de sensores y
publicaci
´
on de los mismos por telemetr
´
ıa comparten un
mismo recurso, encargado de almacenar el valor le
´
ıdo de
los sensores, algo similar sucede con los valores destinados
a los actuadores. Para compartir esta informaci
´
on entre
los distintos hilos de ejecuci
´
on se utiliza el m
´
etodo de
comunicaci
´
on entre procesos denominado shared memory
12
.
En la Figura 6, se visualiza un mapa de memoria RAM,
donde se designa una posici
´
on fija de la memoria correspon-
diente a variables inicializadas para este prop
´
osito.
fixed position
structures
initialized data
text
uninitialized data
heap
stack
Fig. 6. Mapa de la memoria RAM.
Con el fin de garantizar atomicidad de lectura y escritura
los hilos utilizan mutexes
13
. Los mismos evitan que m
´
as
de un proceso modifique el recurso simult
´
aneamente. Esto
es, solo pueden utilizarlo una vez que los dem
´
as procesos
lo hayan liberado. Esto resulta fundamental para evitar
corrupciones de memoria.
En las versiones mas recientes de FreeRTOS se encuentra
disponible la biblioteca atomic.h, la cual promete realizar
esta tarea utilizando menor cantidad de recursos.
H. Drivers
Para el sistema piloto que se describe en la secci
´
on IX
fue necesario escribir bibliotecas que permitan comandar
los sensores y actuadores del mismo.
´
Estas, agregan un
importante valor a la infraestructura de laboratorios remo-
tos, estableciendo una base para generar comunicaciones a
sensores y actuadores de nuevos experimentos.
De esta forma, se plantea a nuevos desarrolladores una
programaci
´
on objetiva de la comunicaci
´
on, utilizando es-
tructuras que emulen objetos y atributos en lenguajes de
alto nivel, proveyendo funciones para interactuar con los
mismos.
A continuaci
´
on se bosqueja un ejemplo que involucra un
objeto con sus atributos y m
´
etodos, en este caso para un
encoder angular incremental.
1 /
**
*
\brief A quadrature encoder structure.
*
/
typedef struct EncoderObjectType {
uint8_t pin_a; /
**
< \brief The "a" pin of the
encoder.
*
/
6 uint8_t pin_b; /
**
< \brief The "b" pin of the
encoder.
*
/
size_t last_state; /
**
< \brief A latch of the last
encoder state.
*
/
uint16_t value; /
**
< \brief The output value.
*
/
} EncoderObjectType;
11 uint16_t get_encoder_value() {
12
Del ingl
´
es, memoria compartida
13
Del ingl
´
es exclusi
´
on mutua
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
14
http://elektron.fi.uba.ar
return encoder.value;
}
void set_encoder_value(uint16_t value) {
16 encoder.value = value;
}
void quadrature_encoder_init(uint8_t pin_a, uint8_t pin_b
) {
/
*
initialization routine
*
/
21 }
void encoder_intr_handler(uint8_t gpio_num) {
/
*
interrupt handler
*
/
}
VII. SOFTWARE DE ALTO NIVEL
El software considerado de alto nivel, comprende a las
aplicaciones y bibliotecas que son ejecutadas en sistemas
complejos, para este proyecto consideramos de alto nivel a
todo software destinado a los computadores no embebidos.
A. Nyquist
1) Prop
´
osito: Los comandos para interactuar con el ex-
perimento, expuestos hasta el momento, resultan a simple
vista cr
´
ıpticos, dif
´
ıciles de recordar, y poco amigables para
un usuario con conocimientos limitados sobre los protocolos
HTTP y Websockets. Como ya se mencion
´
o, el objetivo
principal de esta infraestructura es romper con la barrera que
representan los conocimientos sobre programaci
´
on y redes,
para que los experimentos sean utilizados por estudiantes o
investigadores con m
´
ınimos conocimientos de scripting, ya
sea en Octave o bien Python.
Para tal fin se program
´
o el paquete Nyquist [26], un
modesto traductor multiplataforma que permite enviar o
recibir comandos y telemetr
´
ıa de laboratorios remotos que
se adapten a la infraestructura de comunicaci
´
on propuesta,
abstray
´
endose de las dificultades que presentan los diversos
protocolos, handshakes, asincron
´
ısimos, etc.
2) Instalaci
´
on: El paquete Nyquist se encuentra publi-
cado en el repositorio oficial de Python pip, y su instalaci
´
on
es tan simple como ejecutar el siguiente comando:
pip install nyquist
3) Utilizaci
´
on: Con el fin de demostrar lo simple e
intuitiva que resulta la programaci
´
on de un experimento,
se adjunta el c
´
odigo necesario para comandar una prueba
sobre el prototipo desarrollado, el p
´
endulo aero-propulsado
de la secci
´
on IX. Si bien este programa resulta intuitivo
para un programador familiarizado con Python, se escribi
´
o
la documentaci
´
on de la biblioteca Nyquist [26], la cual
documenta de forma exhaustiva cada uno de los puntos
necesarios para experimentar con los laboratorios.
from nyquist.lab import System
from nyquist.control import Experiment
4
# we create an inherited class from Experiment
class MyExperiment(Experiment):
# the three fundamental functions should be defined
9 def before_the_loop(self):
# we will use aero to comunicate with the system
self.aero = System("aeropendulum")
self.aero.propeller.pwm.status.post("initialized"
)
self.aero.logger.level.post("LOG_INFO")
14 self.aero.propeller.pwm.duty.post(self.duty_low)
def in_the_loop(self):
angle = self.aero.sensors.encoder.angle.get()
if angle < self.setpoint_deg:
19 self.aero.propeller.pwm.duty.post(self.
duty_high)
else:
self.aero.propeller.pwm.duty.post(self.
duty_low)
# the after script will be executed even on failure
24 def after_the_loop(self):
self.aero.propeller.pwm.duty.post(0)
self.aero.propeller.pwm.status.post("disabled")
29 # instance experiment
exp = MyExperiment()
# set constants
exp.setpoint_deg = 90
34 exp.duty_high = 10
exp.duty_low = 5
# and run!
exp.run()
4) Extensi
´
on: Si se desea agregar un nuevo experimento,
es suficiente con generar una lista de los recursos HTTP
y Websockets que dicho experimento tiene disponible. Al
hacerlo, la biblioteca Nyquist utilizar
´
a esta informaci
´
on para
crear los atajos necesarios que faciliten la comunicaci
´
on
con el nuevo laboratorio. Este punto resulta vital, ya que
el desarrollador de un nuevo sistema din
´
amico no necesita
conocimientos de Python, paqueter
´
ıa, o comunicaciones en
absoluto.
B. El paquete Websockets para GNU Octave
Dado que el principal objetivo de este proyecto es que
los usuarios, ya sea estudiantes o investigadores, experi-
menten libremente sin requerir amplios conocimientos de
programaci
´
on, la infraestructura no solo es soportada en el
lenguaje Python, sino tambi
´
en en GNU Octave. Este
´
ultimo
se ha convertido en uno de los lenguajes m
´
as utilizados en
el
´
area de sistemas de control, y es id
´
oneo para muchos
estudiantes e investigadores.
Si bien GNU Octave tiene la capacidad de realizar co-
municaciones HTTP, y posee una biblioteca para establecer
comunicaciones por Sockets, carec
´
ıa de soporte para el
protocolo Websockets, elegido como uno de los medios
principales de comunicaci
´
on para la infraestructura.
Por este motivo se cre
´
o el paquete Octave websockets
[27], resolviendo la caracter
´
ıstica faltante para la imple-
mentaci
´
on de la infraestructura. Es de destacar que dicho
paquete no solamente sirve al proyecto, sino a todos los
usuarios de GNU Octave que deseen establecer comuni-
caciones Websockets dentro de sus algoritmos. Dicha bib-
lioteca se public
´
o en el
´
ındice oficial de paquetes de GNU
Octave y forma parte de los 86 paquetes de Octave al d
´
ıa
de la fecha.
1) Utilizaci
´
on: Para instalar Octave Websockets, es nece-
sario ejecutar el siguiente comando dentro de GNU Octave:
pkg install "https://github.com/gnu-octave/octave-
websockets/archive/v0.1.0.tar.gz"
Un ejemplo de uso muy sencillo se puede ver a contin-
uaci
´
on:
host = "192.168.0.10"
uri = "ws://propeller/pwm/duty"
port = 80
4
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
15
http://elektron.fi.uba.ar
% conectarse
ws = ws_connect (host, uri, port)
mode = "text"
9 % enviar datos
ws_send (ws, data, mode)
% recibir respuesta
resp = ws_receive (ws)
C. Conexi
´
on entre el usuario y el servidor intermedio
En las secciones anteriores, si bien se resuelven los
problemas de conectividad entre el experimento remoto y el
servidor intermedio, a
´
un queda pendiente demostrar como
un usuario se conecta a dicho servidor intermedio. Para
esto se desarrollaron varias soluciones con posibilidades
de aplicaci
´
on muy diferentes entre s
´
ı, basadas en las her-
ramientas Gitlab Runners y Remote Mole (esta
´
ultima creada
espec
´
ıficamente para este proyecto).
Como se explic
´
o en la secci
´
on II, dentro de los laborato-
rios remotos existen diferentes enfoques en cuanto a la forma
de conexi
´
on que establece el cliente (usuario) con el servidor
(experimento); intrusivos y no-intrusivos. Cada uno de estos,
posee ventajas y desventajas marcadas, que depender
´
an del
caso de uso. Un investigador que est
´
a probando sus nuevos
algoritmos en un laboratorio remoto, requerir
´
a un acceso
intrusivo al mismo, que le permita observar cuantas variables
quiera, instalar paquetes, modificar entornos, entre otros. Por
otra parte, para un grupo de estudiantes ser
´
a mas apropiado
el acceso no-intrusivo que los a
´
ısle de forma segura de la
plataforma, proveyendo tambi
´
en una adecuada orquestaci
´
on
para administrar el acceso.
1) Remote Mole: Esta herramienta [28] permite a un
usuario acceder de forma “intrusiva” al experimento. La
aplicaci
´
on posibilita la creaci
´
on remota de t
´
uneles SSH,
Jupyter Notebooks y manejo de instrumentos remotos, tales
como un osciloscopio, todo a trav
´
es de una interfaz de
mensajer
´
ıa, utilizando la plataforma Discord.
Los t
´
uneles SSH facilitan el acceso al dispositivo, como si
se tratase de una red local. Adem
´
as, por tratarse de un pro-
tocolo abierto y sumamente popular existe un sinn
´
umero de
programas, sobre cualquier plataforma, para que el usuario
acceda de manera remota, proporcionando usuario y con-
trase
˜
na. Si el usuario se encuentra en la misma red de
´
area
local, o si posee una IP p
´
ublica, crear un tunnel utilizando
la herramienta podr
´
ıa no ser necesario, sin embargo esas no
son condiciones que podamos garantizar. En la Figura 7 se
ve como el usuario pide al Bot que cree un t
´
unel.
Fig. 7. Interacci
´
on de creaci
´
on de t
´
unel SSH.
Luego, para acceder, simplemente se utiliza el comando
provisto, seguido de la contrase
˜
na del usuario:
marco ˜ > ssh marco@0.tcp.sa.ngrok.io -p 15256
2 marco@0.tcp.sa.ngrok.io’s password:
Linux raspberrypi 5.10.63-v7l+ #1459 SMP Wed Oct 6
16:41:57 BST 2021 armv7l
The programs included with the Debian GNU/Linux system
are free software;
the exact distribution terms for each program are
described in the
7 individual files in /usr/share/doc/
*
/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to
the extent
permitted by applicable law.
Last login: Sun Jul 4 15:58:24 2021 from ::1
12 marco@raspberrypi:˜ $
Un usuario podr
´
a tambi
´
en valerse de una interfaz mas
amigable e intuitiva, como son los Jupyter Notebooks. Con
la misma herramienta, Remote Mole, podr
´
a direccionar el
puerto dedicado para estos Notebooks hacia una direcci
´
on
p
´
ublica. Esto es muy
´
util, incluso dentro de la misma red
local. En la Figura 8 se observa el comando de invocaci
´
on
del t
´
unel.
Fig. 8. Interacci
´
on de creaci
´
on de t
´
unel Jupyter.
Al ingresar en el enlace indicado, es necesario ingresar las
credenciales del usuario, luego se debe seleccionar el archivo
sobre el cual trabajar (Figura 9) y finalmente desarrollar
c
´
odigo sobre el mismo (Figura 10).
Fig. 9. Visualizador de archivos.
Fig. 10. Desarrollo con acceso a un experimento.
2) Herramientas LXI: Por
´
ultimo, Remote Mole tambi
´
en
permite acceder a instrumentaci
´
on remota a trav
´
es del pro-
tocolo LXI. De este modo, el usuario est
´
a en condiciones
de conectarse a un instrumento, ya sea una fuente de
alimentaci
´
on, un osciloscopio o un generador de funciones,
modificar sus configuraciones, pedir datos o realizar capturas
de pantalla. En las Figuras 11, 12 y 13 se aprecia como
usuarios se conectan a un osciloscopio, env
´
ıan comandos
de configuraci
´
on y piden informaci
´
on de su pantalla.
En consecuencia, dicha herramienta resulta una carac-
ter
´
ıstica prometedora, ya que no solamente permite acceder
a los experimentos sino tambi
´
en a instrumentos de medici
´
on,
a partir de est
´
andares conocidos. Utilizando esto como
base, la cantidad de experiencias pr
´
acticas, relacionadas a
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
16
http://elektron.fi.uba.ar
Fig. 11. Establecimiento de conexi
´
on con osciloscopio Siglent.
Fig. 12. Comando de auto-set enviado al a osciloscopio.
Fig. 13. Pedido de captura de pantalla al osciloscopio.
la electr
´
onica, que se pueden llevar a cabo son incontables.
Esto es, electr
´
onica anal
´
ogica, se
˜
nales y sistemas, disposi-
tivos electr
´
onicos, electr
´
onica digital, programaci
´
on, etc.
3) Gitlab Runners: La tecnolog
´
ıa de Gitlab Runners, o
simplemente runners utilizada ampliamente en la industria
del software para resolver los problemas de integraci
´
on y
despliegue continuo resulta una soluci
´
on propicia para el uso
no supervisado de los experimentos, ya que dichos runners
permiten ejecutar rutinas de c
´
odigo previamente escritas por
un estudiante y subidas a un repositorio git hosteado en
Gitlab. Adem
´
as, de ser necesario es posible compilar el
c
´
odigo fuente, revisar y simular el mismo para verificar que
no existan peligros para el experimento, antes de ejecutarlo
en la plataforma, todo de forma autom
´
atica.
El proceso es muy sencillo,
´
unicamente se debe:
• Escribir el c
´
odigo del experimento en uno de los
proyectos generados para estos experimentos.
• Subirlo al repositorio remoto de git.
VIII. ENTORNO DE TRABAJO
A. Contenerizaci
´
on
En algunas ocasiones durante este trabajo se mencion
´
o la
replicabilidad. Esta caracter
´
ıstica indica que tan posible es
reproducir lo que se hizo en este proceso, mientras menos
esfuerzo requiera, m
´
as replicable es.
Con el objetivo de reducir este esfuerzo, todas las her-
ramientas de desarrollo se encuentran contenerizadas. Lo
que permite ejecutar algo similar a una maquina virtual,
aunque ligero y
´
agil, para compilar, testear y ejecutar
c
´
odigo. As
´
ı, con este esfuerzo ya no es necesario instalar
programas en la computadora personal,
´
unicamente se debe
descargar una imagen que genere un contenedor para dichas
dependencias, y trabajar en el mismo.
Todos los problemas de dependencias se resuelven con
tres comandos:
docker pull marcotti/esp-open-rtos
docker pull marcotti/esptool-minimal
3 docker pull marcotti/remote-mole-dev
B. Integraci
´
on continua
Todas las herramientas generadas poseen pipelines de
integraci
´
on continua. Esto es, grupos de pasos automatizados
que compilan, testean y despliegan el c
´
odigo cada vez que
se sube, y peri
´
odicamente, para asegurar que el desarrollo
est
´
e siempre funcionando y listo para utilizarse. En la Figura
14 se aprecian los pasos ejecutados con cada actualizaci
´
on
de remote-control-lab.
Fig. 14. Pipeline de remote-control-lab.
C. Documentaci
´
on del proyecto
Dentro de la integraci
´
on continua que se coment
´
o en el
punto anterior existe un paso para la generaci
´
on autom
´
atica
de documentaci
´
on, en donde se compilan y publican las
p
´
aginas web que describen la utilizaci
´
on de esta infraestruc-
tura, de forma autom
´
atica [22], [24], [26], [28].
IX. SISTEMA PILOTO: P
´
ENDULO AERO-PROPULSADO
Fig. 15. Fotograf
´
ıa del sistema construido.
Como ya se detall
´
o en reiteradas ocasiones a lo largo del
proyecto, se construy
´
o un sistema piloto para demostrar el
potencial y versatilidad del framework creado. El mismo,
que se muestra en la Figura 15, trata de un p
´
endulo
propulsado a trav
´
es de una h
´
elice de drone, con un motor
sin escobillas.
El principio de operaci
´
on de este sistema se basa en
establecer un
´
angulo respecto al vector de gravedad (set-
point), para que en base a la manipulaci
´
on del empuje de
la h
´
elice se compense la desviaci
´
on entre el
´
angulo actual y
el de set-point. Es de destacar que este sistema es no lineal
SISO
14
.
Entre sus posibilidades, este sistema permite realizar
pruebas con filtros de Kalman aplicando fusi
´
on de sensores,
14
Del ingl
´
es, Simple-Input Simple-Output
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
17
http://elektron.fi.uba.ar
ya que posee un aceler
´
ometro/gir
´
oscopo, junto a un encoder
incremental, acoplados en el eje de rotaci
´
on. Esto, se ha
realizado previamente en otros trabajos [29] y su aplicaci
´
on
en este contexto resulta relevante.
Espec
´
ıficamente, el p
´
endulo aero-propulsado es un sis-
tema de din
´
amica r
´
apida, por lo que pone a prueba los
l
´
ımites establecidos por la latencia en las comunicaciones. A
modo de ejemplo, el experimento de observar la respuesta a
un cambio de set-point del tipo escal
´
on fue programado con
unas pocas l
´
ıneas de c
´
odigo, utilizando la biblioteca nyquist.
En la Figura 16 se muestra el resultado de la ejecuci
´
on de
dicho algoritmo.
0 1 2 3 4
tiempo [s]
0.40
0.45
0.50
0.55
0.60
sen( )
Fig. 16. Respuesta al escal
´
on.
La respuesta temporal obtenida deja en evidencia que
la tasa de actualizaci
´
on de datos alcanzada es suficiente
para este tipo de aplicaciones. Esto es, un lazo de control
puede ejecutarse a una frecuencia menor a 100 Hz sin
problema alguno, utilizando los sensores y actuadores del
experimento.
Si bien es un experimento
´
unico en su clase, se prioriz
´
o
una construcci
´
on de bajo costo, modular y f
´
acilmente repli-
cable. Para este fin se aprovech
´
o la existencia de m
´
odulos de
desarrollo provistos en masa, posibles gracias a la corriente
de democratizaci
´
on del hardware [30]. Adem
´
as, se evit
´
o,
en la medida de lo posible, construir hardware ad-hoc,
debido a que esto afecta negativamente a la replicabilidad
del experimento. Finalmente, tambi
´
en se confeccionaron y
detallaron planos mec
´
anicos.
En la Figura 17 se ve la respuesta del experimento a
diferentes tipos de algoritmos de control, entre ellos P, PI,
PD y m
´
ultiples sintonizaciones de controladores PID, todos
estos posicionando al p
´
endulo para el mismo set-point.
El c
´
odigo necesario para realizar esta tarea resulta in-
cre
´
ıblemente sencillo, gracias a la abstracci
´
on que provee
el proyecto, permitiendo concentrarse realmente en el algo-
ritmo de control, sin prestar atenci
´
on a la construcci
´
on y
comunicaci
´
on con el experimento.
La programaci
´
on del mismo consta de las siguientes
elementales l
´
ıneas:
class MyExperiment(Experiment):
2
def before_the_loop(self):
self.aero = System("aeropendulum")
self.aero.propeller.pwm.status.post("initialized"
)
self.aero.telemetry.period.post(20)
7 self.aero.logger.level.post("LOG_INFO")
self.data = [] # {’time’: %f, ’angle’: %f, ’
setpoint’: %f}
0 2 4 6 8 10 12 14 16
tiempo [s]
0.4
0.5
0.6
0.7
0.8
0.9
1.0
sen
( )
setpoint
p
pi
pd
classic
some_overshoot
no_overshoot
Fig. 17. Comparaci
´
on de controladores en el experimento.
pid_coeffs = ziegler_nichols(Ku=40, Tu=1.45,
control_type=’no overshoot’)
12 self.pid = PIDController(
pid_coeffs[’Kp’],
pid_coeffs[’Ki’],
pid_coeffs[’Kd’],
20,
17 0.05
)
self.linerizer = PendulumLinearizer(
41.67880775502065,
4.570736581055918,
22 )
self.aero.sensors.encoder.angle.get()
self.start_ts = time.monotonic()
def in_the_loop(self):
27 angle_deg = self.aero.sensors.encoder.angle.get()
if angle_deg is None:
return
angle_deg = avoid_negative_angles(angle_deg)
32 angle_rad = np.deg2rad(angle_deg)
spent = time.monotonic() - self.start_ts
37 pid_duty = self.pid.update(self.setpoint_rad -
angle_rad)
compensator_duty = self.linerizer.compensate(
angle_rad)
duty = pid_duty + compensator_duty
duty = safety_check(duty, self.max_duty,
SAFE_DUTY)
self.aero.propeller.pwm.duty.post(duty)
42
self.data.append(
{
’time’: spent,
’sin_angle’: np.sin(angle_rad),
47 ’duty’: duty,
’sin_setpoint’: np.sin(self.setpoint_rad)
,
}
)
52 def after_the_loop(self):
self.aero.propeller.pwm.duty.post(0)
self.aero.propeller.pwm.status.post("disabled")
self.aero.propeller.pwm.status.post("initialized"
)
Naturalmente, fue necesario crear unas peque
˜
nas bibliote-
cas para un controlador PID, y para linealizar el sistema
(de naturaleza no-lineal). Si bien estas pueden ser tambi
´
en
utilizadas por el usuario, la construcci
´
on de las mismas
proveer
´
a al mismo un mejor entendimiento en la imple-
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
18
http://elektron.fi.uba.ar
mentaci
´
on de la teor
´
ıa de control.
X. CONCLUSI
´
ON
A trav
´
es de este trabajo se ha desarrollado un sistema
escalable y replicable, que permite a docentes, estudiantes,
profesionales y aficionados construir sus propios laborato-
rios remotos. Aportando as
´
ı a una educaci
´
on descentralizada
y cada vez m
´
as colaborativa.
Esto es, mediante la construcci
´
on del sistema piloto,
el framework desarrollado mostr
´
o ser vers
´
atil y a su vez
intuitivo. Por lo que adaptarlo a las necesidades que impon
´
ıa
este experimento no represent
´
o un problema. Adem
´
as, la
plataforma propuesta logr
´
o suplir las necesidades de perfor-
mance requeridas por un sistema de r
´
apida din
´
amica. Es
por ello, que al satisfacer tales necesidades, la gama de
experiencias que pueden generarse utilizando esta interfaz
es realmente amplia.
Por otro lado, luego de meses de pruebas internas y
experimentaci
´
on constante, las herramientas de educaci
´
on
remota resultaron ser extremadamente
´
utiles. Las interfaces
y el software generado fue puesto a prueba en el dictado de
clases y en grupos de investigaci
´
on, permitiendo a los usuar-
ios manipular herramientas a distancia para comprender
sistemas complejos o acceder a instrumentos de medici
´
on.
La API generada demostr
´
o ser transparente y eficaz,
permitiendo con pocas l
´
ıneas de c
´
odigo generar algoritmos
de control como los ya mencionados, implementando capas
de comunicaci
´
on complejas en una sola l
´
ınea.
Por
´
ultimo, la documentaci
´
on web desarrollada resulta
suficiente para que cualquier usuario, a trav
´
es de la ex-
perimentaci
´
on y manipulaci
´
on de los ejemplos provistos,
disfrute y democratice el aprendizaje.
REFERENCIAS
[1] P. C. Wankat and F. S. Oreovicz, Teaching engineering. Purdue
University Press, 2015.
[2] K. Ogata, Modern Control Engineering, 5th ed. Pearson Education,
2010.
[3] F. Golnaraghi and B. C. Kuo, Automatic Control Systems, 9th ed.
Wiley, 2009.
[4] E. J. Adam, Instrumentaci
´
on y Control de Procesos. Notas de Clase,
3rd ed. Santa Fe: Ediciones UNL, 2018.
[5] E. S. Burgos and E. J. Adam, “Graphical user interface editor for
octave applications,” Engineering Reports, p. e12269, 2020.
[6] L. Gomes and S. Bogosyan, “Current trends in remote laboratories,”
IEEE Transactions on industrial electronics, vol. 56, no. 12, pp. 4744–
4756, 2009.
[7] J. S
´
aenz, L. de la Torre, J. Chac
´
on, and S. Dormido, “A study of
strategies for developing online laboratories,” IEEE Transactions on
Learning Technologies, vol. 14, no. 6, pp. 777–787, 2021.
[8] C. Gravier, J. Fayolle, B. Bayard, M. Ates, and J. Lardon, “State of
the art about remote laboratories paradigms-foundations of ongoing
mutations,” International Journal of Online Engineering, 2008.
[9] M. Ngolo, L. B. Palma, F. Coito, L. Gomes, and A. Costa, “Ar-
chitecture for remote laboratories based on rest web services,” in
2009 3rd IEEE International Conference on E-Learning in Industrial
Electronics (ICELIE). IEEE, 2009, pp. 30–35.
[10] M. Tawfik, C. Salzmann, D. Gillet, D. Lowe, H. Saliah-Hassane,
E. Sancristobal, and M. Castro, “Laboratory as a service (laas): a
novel paradigm for developing and implementing modular remote
laboratories,” International Journal of Online and Biomedical Engi-
neering (iJOE), vol. 10, no. 4, pp. 13–21, 2014.
[11] C. Salzmann, S. Govaerts, W. Halimi, and D. Gillet, “The smart
device specification for remote labs,” in Proceedings of 2015 12th
International Conference on Remote Engineering and Virtual Instru-
mentation (REV). IEEE, 2015, pp. 199–208.
[12] L. Gomes, F. Coito, A. Costa, and L. B. Palma, “Teaching, learning,
and remote laboratories,” Advances on remote laboratories and e-
learning experiences, p. 189, 2007.
[13] J. Garc
´
ıa-Zub
´
ıa, D. L
´
opez-de Ipi
˜
na, and P. Ordu
˜
na, “Evolving to-
wards better architectures for remote laboratories: a practical case,”
International Journal of Online and Biomedical Engineering (iJOE),
vol. 1, no. 2, 2005.
[14] L. S. Indrusiak, M. Glesner, and R. Reis, “On the evolution of
remote laboratories for prototyping digital electronic systems,” IEEE
Transactions on Industrial Electronics, vol. 54, no. 6, pp. 3069–3077,
2007.
[15] L. De La Torre, L. T. Neustock, G. K. Herring, J. Chacon, F. J. G.
Clemente, and L. Hesselink, “Automatic generation and easy de-
ployment of digitized laboratories,” IEEE Transactions on Industrial
Informatics, vol. 16, no. 12, pp. 7328–7337, 2020.
[16] F. J. Rodriguez, C. Giron, E. J. Bueno, A. Hernandez, S. Cobreces,
and P. Martin, “Remote laboratory for experimentation with multi-
level power converters,” IEEE Transactions on Industrial Electronics,
vol. 56, no. 7, pp. 2450–2463, 2009.
[17] H. B
¨
ahring, J. Keller, and W. Schiffmann, “Remote operation and
control of computer engineering laboratory experiments,” in Proceed-
ings of the 2006 workshop on Computer architecture education: held
in conjunction with the 33rd International Symposium on Computer
Architecture, 2006, pp. 6–es.
[18] A. Leva and F. Donida, “Multifunctional remote laboratory for
education in automatic control: The crautolab experience,” IEEE
Transactions on Industrial Electronics, vol. 55, no. 6, pp. 2376–2385,
2008.
[19] D. Hargreaves, “Student learning and assessment are inextricably
linked,” European Journal of Engineering Education, vol. 22, no. 4,
pp. 401–409, 1997.
[20] M. Wu, J.-H. She, G.-X. Zeng, and Y. Ohyama, “Internet-based
teaching and experiment system for control engineering course,” IEEE
Transactions on Industrial Electronics, vol. 55, no. 6, pp. 2386–2396,
2008.
[21] M. Casini, D. Prattichizzo, and A. Vicino, “The automatic control
telelab,” IEEE Control Systems Magazine, vol. 24, no. 3, pp. 36–44,
2004.
[22] M. Miretti, “Remote Control Lab documentation,”
https://marcomiretti.gitlab.io/remote-control-lab, 2021, accessed:
2021-07-11.
[23] R. T. Fielding, Architectural styles and the design of network-based
software architectures. University of California, Irvine, 2000.
[24] M. Miretti, “Remote Labs - Control openapi specification,”
https://marcomiretti.gitlab.io/remote-control-lab/openapi.html, 2021,
accessed: 2021-07-11.
[25] Zaitsev, Serge, “Jsmn: The most simple json parser for c in small
systems,” https://zserge.com/jsmn/, 2019, accessed: 2021-10-03.
[26] M. Miretti, “Nyquist rtd documentation,”
https://nyquist.readthedocs.io/en/latest, 2021, accessed: 2021-07-
11.
[27] ——, “Octave websockets,” https://gnu-
octave.github.io/packages/websockets, 2020, accessed: 2021-10-31.
[28] ——, “Remote Mole rtd documentation,” https://remote-
mole.readthedocs.io/en/latest/, 2021, accessed: 2021-07-11.
[29] M. Miretti, F. Busano, E. Bernardi, H. Pipino, and G. Peretti,
“Estimaci
´
on h
´
ıbrida de posici
´
on angular en dispositivos de captura
de im
´
agenes a
´
ereas,” VIII Jornadas de Ciencia y Tecnolog
´
ıa para
Alumnos (CyTAL), 08 2018.
[30] L. Buechley, “Lilypad arduino: How an open source hardware kit is
sparking new engineering and design communities,” 2009.
Revista elektron, Vol. 6, No. 1, pp. 8-19 (2022)
ISSN 2525-0159
19
http://elektron.fi.uba.ar
Enlaces de Referencia
- Por el momento, no existen enlaces de referencia
Copyright (c) 2022 Marco Luis Miretti, Emanuel Bernardi
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