LABORATORIO REMOTO DE CONTROL EN TIEMPO
REAL CON VISUALIZACIÓN 3D
A. Llosá, S. Garcı́a-Nieto, M. Martı́nez y J. Sanchis
Departamento de Ingenierı́a de Sistemas y Automática
Universidad Politécnica de Valencia, Camino de Vera 14, 46022 - Valencia, España
e-mail: anllogui@upvnet.upv.es, [sergarro, mmiranzo, jsanchi]@isa.upv.es
Resumen
El presente articulo describe la implementación de
un laboratorio remoto para el ámbito de control.
Esta herramienta permite tanto la simulación de
procesos como el control en tiempo real de siste-
mas dinámicos. La base de este trabajo fue presen-
tada en el año 2005 en los trabajos de [11] y [10].
A partir de estos trabajos se han realizado me-
joras sucesivas, las cuales se presentaron en 2006
[15]. Ası́ mismo, este artı́culo describe la imple-
mentación definitiva, que dota a esta herramienta
de un framework completo y versátil y portable,
en el cual se ha ampliado la visualización de los
procesos a controlar a tres dimensiones.
Palabras clave: Laboratorio remoto, tiempo
real, visualización 3D
1. INTRODUCCIÓN
Los conceptos teóricos asociados al campo de con-
trol resultan, normalmente, complejos y difı́ciles
de asimilar por parte de los estudiantes. En cam-
bio, la aplicación práctica de la teorı́a es una for-
ma muy eficaz de asimilar conocimientos [9]. Por
tanto, resulta imprescindible el desarrollo de pla-
taformas Software/Hardware destinadas a la im-
plementación práctica de las técnicas de control
planteadas de forma teórica [19].
El presente artı́culo introduce una nueva estrate-
gia educacional, para el estudio de sistemas de
tiempo real y control no lineal vı́a Internet [4].
Esta nueva estrategia se basa en la inclusión de
elementos reales dentro de los modelos de simula-
ción (componentes de comunicación, actuadores y
sensores reales, etc.). Esta propuesta pone de ma-
nifiesto las diferencias existentes entre los procesos
reales y las clásicas simulaciones. Los estudiantes
pueden comprobar el comportamiento real de un
sistema de control complejo y además profundi-
zar y afianzar sus conocimientos en la teorı́a de
control no lineal. Por otra parte, el desarrollo de
prototipos donde comprobar las diferentes meto-
dologı́as de control resulta complejo y costoso a
nivel económico. Por tanto, con el objeto de ha-
cer frente a las cuestiones ya mencionadas, este
trabajo propone sustituir los procesos reales por
modelos virtuales, compuestos por un simulador
que se ejecuta en un sistema de tiempo real.
El modelo virtual cuenta con un conjunto de tar-
jetas de adquisición que permiten la interacción
con el entorno. El sistema de control interactúa
con el modelo virtual como si éste fuese el proce-
so real. Adicionalmente, se plantea el uso de un
bus de campo como sistema de comunicación cu-
yo uso está generalizado en la industria actual, con
el objetivo de ilustrar la influencia de este tipo de
componentes dentro del sistema de control. Con-
secuentemente, uno de los elementos del bus de
campo es un controlador basado en una arquitec-
tura PC. Este controlador emplea los sensores y
actuadores distribuidos para interaccionar con el
modelo virtual. Por último, se ha desarrollado una
aplicación que actúa como interfaz entre el usua-
rio y la plataforma, lo cual permite gestionar todo
el sistema vı́a Internet [20]. En resumen, la plata-
forma desarrollada consta de los cuatro elementos
principales:
xPC modelo virtual.
I/O distribuidas basadas en CAN bus.
Controlador PC basado en RTLinux.
SCADA multiplataforma desarrollado en JA-
VA.
El xPC es una potente herramienta incluida en
el conocido software de computación cientı́fica
Matlab. Esta herramienta permite la ejecución de
diagramas Simulink en tiempo real. Gracias al
xPC, el proceso real se sustituye por un modelo
virtual descrito por un modelo Simulink. En es-
te caso particular, se ha implementado un modelo
no lineal basado en las ecuaciones fundamentales
del péndulo invertido [2]. Por otro lado, las I/O
distribuidas se encuentra dispuestas en un bus de
campo basado en CAN bus con protocolo de comu-
nicaciones CANOpen. Donde uno de los nodos es
un PC estándar que hace las funciones de con-
trolador. El cual, interactúa con el modelo virtual
mediante las I/O distribuidas en el CAN bus. Gra-
cias al empleo de RTLinux como SO en el contro-
lador, se asegura la ejecución de distintas tareas
en tiempo real.
Finalmente, el SCADA desarrollado es un interfaz
de usuario desarrollado mediante el lenguaje de
programación JAVA. Esta aplicación puede ges-
tionar todas las opciones de configuración del con-
trolador PC, ası́ como visualizar la actividad del
sistema (variables manipuladas, acciones de con-
trol, etc.). El SCADA ha sido diseñado para esta-
blecer una conexión remota con la plataforma vı́a
TCP/IP a través de Internet [20]. El diagrama que
se muestra en la figura 1 describe la interconexión
entre los diferentes componentes de la plataforma
[11].
Figura 1: Diagrama de Funcional del Sistema.
El artı́culo se encuentra dividido en VI secciones.
En primer lugar, la presente introducción. A con-
tinuación, la sección II, III y IV describen los dis-
tintos componentes que integran la plataforma. La
sección V describe a forma de Manual de Usuario,
el manejo de la aplicación SCADA por parte del
usuario. Por último la sección VI muestra las prin-
cipales conclusiones obtenidas en el desarrollo del
trabajo.
2. BUS DE CAMPO CAN
CAN (Controller Area Network) es un bus
de campo [6], desarrollado originalmente para
aplicaciones en la industria de automoción. El
protocolo CAN fue estandarizado en 1993 como
ISO 11898-1. Este hecho a contribuido de manera
determinante en el amplio desarrollo de este en
distintos ámbitos industriales.
La principales caracterı́sticas que proporciona este
robusto y versátil bus de campo son las siguientes:
Comunicación broadcast. Un emisor de infor-
mación transmite a todos los nodos a través
del bus. Todos los nodos reciben el mensa-
je y deciden si es relevante o no para ellos.
Este mecanismo garantiza la integridad de la
información de todos los nodos.
Priorización de mensajes. El protocolo pro-
porciona mecanismos hardware que garanti-
zan que no se produzcan colisiones entre men-
sajes cuando varios nodos desean emitir men-
sajes.
Mecanismo sofisticado de detección de errores
y retransmisión de mensajes fallidos.
Estructura multi-maestro, que permite cons-
truir redes con tolerancia a fallo (redundan-
tes).
Para más información, en [10] fueron planteadas
las ventajas de la utilización de este bus para el
desarrollo de plataformas de control de sensores
distribuidos.
3. SISTEMA DE TIEMPO REAL
Existen en el mercado todo tipo de sistemas ope-
rativos de tiempo real. En este caso se ha decidi-
do utilizar RT-Linux-GPL [22], desarrollado en el
proyecto europeo Ocera [17] a partir de RTLinux
de Fsmlabs [22], y Linux. Para la implementación
de los módulos se ha utilizado como referencia un
tutorial de dominio público [18].
3.1. ELECCIÓN DEL S.O. DE TIEMPO
REAL
La razón para esta elección es que RTLinux-GPL
y Linux poseen una licencia de tipo GPL. Esto im-
plica, entre otras cosas, la posibilidad de obtención
del código fuente para su modificación o amplia-
ción. En el caso de investigación pública, este pun-
to es muy importante, debido a la necesidad del
investigador a saber, en caso de necesidad, como
funcionan las herramientas en las que está basan-
do sus investigaciones, o modificarlas para poder
ampliar el uso de éstas y adaptarlas a los objeti-
vos propios de la investigación, y a devolver a la
sociedad la inversión que se ha efectuado en ella,
dejando el fruto de su trabajo libre.
En el caso de que se realice algún tipo de cambio
en el código, éste pasa al conocimiento del licen-
ciatario principal, de manera que, en caso de que
sea útil para el proyecto general, es incluido en
éste, y el resto de usuarios pueden ser beneficia-
rios. En caso de la comunidad investigadora, esto
es necesario, ya que de esta manera los esfuerzos
de muchas personas se pueden ir sumando para un
beneficio común.
Otro factor de la elección ha sido el económico, ya
que el coste el software utilizado para desarrollar e
implementar la plataforma ha sido nulo, habiéndo-
se utilizado herramientas de código abierto.
Todo el trabajo realizado ha sido licenciado como
GPL para su libre modificación y distribución, si-
guiendo la filosofı́a [12] de las herramientas y uti-
lidades en las cuales se ha basado.
El ejecutable corrı́a bajo Linux, siendo un proceso
más del sistema operativo, y las tareas de con-
trol eran controladas por el planificador interno
de Ada. esto no aseguraba nunca que la tarea de
control se ejecutase en el momento requerido.
3.2. ESTRUCTURA DEL MÓDULO DE
CONTROL

El esquema general con RTLinux-GPL en la ejecu-

3.1.1. Caracterı́sticas del sistema de ción de los procesos del sistema está representado
tiempo real en la figura 2.
El modelo utilizado para implementar el sistema
de tiempo real ha sido el de tarea periódica. Los
parámetros principales que definen esta tarea son
los siguientes:

Periodo: Es el intervalo de tiempo P en el que

se ha de ejecutar la tarea T. Por lo tanto,
una tarea Ti con un periodo Pi genera una
secuencia de activaciones (a1 , a2 , a3 , · · · , an ),
donde ak deberá de ejecutarse en el intervalo
definido por [(k − 1).Pi , k.Pi ]. En este caso, Figura 2: Esquema de los procesos plataforma de
es de 2 ms para la tarea de control, y 10 ms control.
para la tarea de visualización.
RTLinux-GPL toma como proceso de máxima
Plazo de entrega: El plazo de entrega Di de
prioridad el Módulo de control y mantiene a Li-
una tarea Ti es el intervalo de tiempo máxi-
nux como otro proceso más del sistema de menor
mo entre el que la tarea se ha de activar y su
prioridad. Esto significa, que mientras tenga algo
finalización. En el caso de estudio, Di = Pi .
que ejecutar el módulo de control, Linux pasará a
Dependiendo de las restricciones del sistema,
la espera. Por lo tanto, en caso de que el tiempo
Di puede ser mayor o menor que Pi .
necesario de ejecución del control fuese superior
al tiempo asignado previamente, Linux no se eje-
Desfase inicial: El desfase inicial de una tarea
cutarı́a, por lo que el sistema darı́a la impresión
Ti denota el desfase que tiene el inicio de
de estar colgado, ya que el módulo de control se
la primera activación de la tarea respecto al
apoderarı́a completamente de la CPU.
tiempo de inicio y se denota como φi . En éste
caso es 0 para las dos tareas definidas. Cuando el modulo de control no se está ejecutan-
do, entra en funcionamiento Linux, y se ejecutan
En el caso de la plataforma descrita en este tra- el resto de procesos del sistema.
bajo, se ha implementado un sistema tiempo real A continuación se describen con más detalle las
“duro” (“hard real time”), ya que es la opción con tareas.
más dificultades en su implementación, y la mejor
opción a la hora de implantar cualquier tipo de
control. 3.2.1. Tarea de control
Para las pruebas, en un primer momento se desa-
Esta tarea se encarga de realizar el control del sis-
rrolló un sistema de control en tiempo real “blan-
tema y tiene las tı́picas acciones de una tarea de
do” con Ada, pero solamente se consiguió un pe-
control (leer sensores, calcular acción de control,
riodo mı́nimo de muestreo de 20 ms, y no se ase-
escribir acción de control). Tiene la máxima prio-
guraba el tiempo real. Estas pruebas fueron rea-
ridad.
lizadas con un kernel de Linux compilado para la
distribución Debian, sin los parches de tiempo real En los ordenadores actuales, no es posible calcular
disponibles actualmente [14]. Esto era debido a la el tiempo que se tarda en ejecutar lı́neas de código,
granularidad del sistema, que en ese tipo de kernel debido a la incertidumbre causada por las nuevas
está adaptada al trabajo de ordenadores de escri- estructuras de microprocesadores, ya que varı́a de
torio normales, para no tener pérdidas de tiempo un ciclo de ejecución a otro. Esto lleva a que no
de cómputo. se es posible asegurar que el tiempo que tarda la
tarea en calcular la acción de control en un periodo
sea el mismo que en el periodo anterior.
Existen otros mecanismos mas sofisticados para
evitar este problema como es el particionamiento
en tres tareas propuesto por [8] y [3] o en dos ta-
reas, propuesto en [7], pero se ha optado por una
solución que simplifica el proceso y a la vez ase-
gura que la acción de control se ejecutará siempre
en el mismo instante.
La solución es la siguiente:
3.2.2. Tarea de visualización
Debido a que la visualización de los datos no es
prioritaria, ésta se hace con un periodo de mues-
treo menor a la acción de control y con una priori-
dad más baja. En estos momentos la visualización
se realiza en modo texto en la pantalla del PC, y
a su vez se graban en una pila del sistema para
que otro proceso de linux los pueda leer y enviar
a la aplicación SCADA desarrollada a tal efecto y
detallada en el punto 5.

3.3. PRUEBAS PREVIAS

1. Aplicar acción de control.
Nada más activarse el módulo , se aplica la Antes de realizar la implementación del control
acción de control calculada en el instante an- del proceso, se procedió a realizar unas pruebas
terior, de manera que se elimina este tipo de para comprobar el cumplimiento de las restriccio-
incertidumbre, teniendo ası́ un retardo fijo en nes de tiempo requeridas. Para comprobar esto, se
la aplicación de la acción de control. grabó el instante del reloj de tiempo real del PC
donde en el experimento se enviarı́a la acción de
2. Lectura de los sensores. control a los actuadores.
El siguiente paso después de aplicar la acción
de control es leer los sensores para poder rea-
lizar el cálculo de ésta.
Para ello utilizamos los drivers desarrollados
que funcionan de la siguiente manera:
Se manda una señal para que todos los nodos
Can que funcionan como sensores adquieran
al mismo tiempo señales del proceso, y a
continuación manden la información al nodo
principal las señales leı́das. Esto último se rea-
liza de forma secuencial.

3. Cálculo de la acción de control.

Figura 4: Tarea de Control - Media de periodo:
En este paso se calcula la acción de control, 2ms
con el algoritmo de control implementado,
que se va a aplicar en el siguiente periodo.

En la figura 3 es posible ver el cronograma de una

iteración de la tarea de control, con datos tomados
a partir de sucesivos experimentos.

Figura 5: Tarea de Control - Media de duración:

0.5227 ms

Figura 3: Cronograma de una iteración de control.
Se puede apreciar el comportamiento del contro-
lador en cada iteración, ası́ como sus tiempos es-
timados.
En las figuras 4 y 5 se pueden ver los resultados en
forma de histograma de los tiempos de duración y
activación respectivamente de la tarea de control,
y en las figuras 6 y 7 los de la tarea de visualiza-
ción. En estos resultados se puede apreciar como el

Figura 6: Tarea de Visualización - Media de pe-
riodo: 200ms
Figura 7: Tarea de Visualización - Media de dura-
ción: 199.99 ms
sistema alcanza perfectamente los requerimientos
de tiempo real del sistema.
4. PLATAFORMA DE
SIMULACIÓN
El presente punto aborda la utilización de la plata-
forma de simulación, para las pruebas del sistema
de tiempo real, denominada xPC de MathWorks
[1]. El xPC target es un toolbox de la compañı́a
The MathWorks para la construcción de prototi-
pos, testado y desarrollo de sistemas de tiempo
real. En particular, es adecuado para la simula-
ción o el control en tiempo real de procesos, ya que
permite al PC comunicarse con el exterior usando
tarjetas de adquisición de datos. Para más infor-
mación, éste tipo de sistema ya fue presentado y
detallado en [10].
En el experimento se ha utilizado un modelo del
proceso del péndulo invertido, desarrollado en [11].
El modelo de simulink completo se puede apreciar
en la figura 8, incluyendo la adquisición de señales.
Figura 8: Diagrama Simulink
5. SCADA
En [15] se presentó la primera versión de este sof-
tware, en la que se podı́a visualizar en lı́nea el
control de la aplicación en dos dimensiones y sin
opción de reproducir los experimentos realizados.
En ésta nueva versión ya es posible esto, además
de poder visualizar en 3D el comportamiento del
proceso a controlar.
En la figura 9 se puede ver una imagen del software
descrito a continuación. La aplicación ha sido de-
sarrollada en Java, utilizando la máquina virtual
de SUN liberada actualmente para su libre distri-
bución y Netbeans [13], un entorno de desarrollo
para Java, con licencia GPL.

Figura 9: Pantallazo del programa
5.1. CONEXIÓN CON EL MÓDULO
DE CONTROL
Como se representa en la figura 1, el software de vi-
sualización se conecta por TCP/IP vı́a ssh (Figura
10) y lanza cualquiera de los procesos predefinidos
a petición del usuario desde la interfaz.
Figura 10: Botones de control
Las posibles opciones de control implementadas se
basan en los algoritmos de control de inyección de
energı́a introducidos en [2], los cuales se resumen
a continuación.
Controlador 1 (con a=2):
u = 2a tan x1
Controlador 2 (con a=2):
u = 2a sin x1
Controlador 3 (con a=2 y k=5):
u = 2a tan x1 + kx2
Controlador 4 (con a=2 y k=5):
u = 2a sin x1 + ϕx2 cos x1
1 1

−k Si (Hd ≤ 4a ) (cos x1 ) <
ϕ=
k otors casos
1 Existen dos modos de ejecución: en linea y simu-
Hd (x1 , x2 ) = cos x1 − a cos2 x1 + x22
2 lación. A continuación se detallan los dos modos:
5.2. CREACIÓN DE MODELOS
VISUALES
Para continuar con la filosofı́a de utilizar herra-
mientas libres, se ha utilizado una de éstas para
la generación de los modelos visuales en 3D de los
procesos a controlar.
En la representación se utiliza un importador de
ficheros con formato 3ds a Java3D. Al ser formato
antiguo liberado por Autodesk, es posible diseñar
objetos en 3D con herramientas libres y gratuitas,
para más tarde exportarlos éste formato.
En este caso se ha utilizado la herramienta Blender
(Figura 11) [5]. lı́der en el diseño 3D profesional
con software libre. El proceso que se ha seguido es
desarrollar con los formatos de Blender para lue-
go exportarlo al formato de 3DStudio comentado
anteriormente.
Figura 11: Creación de modelos con Blender
Para el desarrollo de un modelo, en primer lugar
se ha de hacer un análisis de los objetos que se van
a representar. Éstos se dividirán en dos tipos: los
(1) dinámicos y los estáticos.
Los estáticos se pueden desarrollar todos juntos
e importarlos a la aplicación de la misma mane-
(2) ra. Los dinámicos son un poco más complejos de
desarrollar, ya que hay que separar las partes mo-
vibles de éstos, tomando como criterio la dinámica
(3) del objeto. Para explicarlo con más claridad se va
a utilizar como ejemplo el de la aplicación del ca-
so de estudio: el carro con el péndulo invertido. El
(4) vehı́culo se puede dividir en dos componentes: el
péndulo en sı́, que serı́a la barra, y el carro.
2a
5.3. EJECUCIÓN DE SCADA
(5)
(6)
5.3.1. Ejecución en lı́nea
Si se tiene conexión al sistema de control descrito
en el punto 3 se puede proceder a ejecutar el modo
de ejecución en lı́nea, con el cual la aplicación de
visualización se conectará vı́a TCP/IP al sistema
de control.
Una vez arrancado RTLinux ya es momento de
insertar el módulo de control. Para ello primero se
elige el módulo de control en el combo al efecto y
luego se inserta pulsando el botón Ejecuta, el cual
ha sido habilitado al arrancar RTLinux, como se
muestra en la figura 10.
Al pinchar sobre el botón, el módulo del contro-
lador elegido será cargado y pasará a ejecutarse
como proceso de máxima prioridad del sistema.
En la figura 12 se muestra el SCADA en pleno
funcionamiento.
Figura 12: SCADA en ejecución
Se puede observar que al usuario se le da la op-
ción de guardar los datos adquiridos en un fichero
gracias a la selección del checkbox Guardar Datos.
Esto guarda los datos obtenidos en el control en
un fichero .dat, el cual se escribe en el mismo di-
rectorio donde se ejecuta el programa SCADA con
el siguiente nombre:
TipoControlador Fecha+Hora.dat
Y los datos aparecen en el siguiente orden:
1. Instante
2. Fuerza
3. Ángulo
4. Velocidad angular
5. Velocidad del carro
6. Duración del periodo de muestreo
Gracias a esto es posible tratar los datos obteni-
dos con la plataforma para compararlos con los
obtenidos en simulación, como se va a detallar en
el punto 5.3.2.
Es aconsejable, que, en caso de no querer guardar
estos datos, se deseleccione la casilla correspon-
diente, ya que de esta manera el programa fun-
cionará de forma más ligera, ya que no tiene que
escribir en un fichero todos los datos obtenidos.
Otro aspecto a tener en cuenta, es el compromiso
de la realidad con respecto a las prestaciones del
software. El dibujo en cada periodo de muestreo
de las gráficas de los valores obtenidos del con-
trolador, hacen que el el rendimiento del sistema
de visualización se resiente a nivel de rendimiento,
y se observan saltos en la representación gráfica.
Debido a esto, se ha optado por representar uno
de cada 20, lo que impone un periodo de represen-
tación de 40 ms.
Esto solo sucede con la parte de que concierne a
las gráficas. El resto del sistema que depende de
los datos, como el que se dedica a almacenarlos en
un fichero o la parte de representación del proceso,
utilizan todos los datos que son transmitidos desde
el controlador.
5.3.2. Ejecución de simulación
Éste modo de ejecución se ejecuta solamente cuan-
do el proceso no tiene conexión al PC de control.
En este caso, el programa avisa al usuario con una
ventana de error que se puede ver en la figura 13.
Posteriormente, al intentar ejecutar el programa,
aparecerá otra ventana indicando la necesidad de
introducir un fichero de datos (14).
Figura 13: Aviso de modo simulación
Figura 14: Aviso de introducción de datos
El fichero requerido ha de haber sido creado pre-
viamente por ésta aplicación en una ejecución nor-
mal, como se explica en la Ejecución en lı́nea. De
esta manera, es posible reproducir en cualquier la-
do controles realizados anteriormente, sin necesi-
dad del PC de control ni del simulador del proceso.
6. CONCLUSIONES
El presente artı́culo describe el desarrollo de una
herramienta Software/Hardware, destinada a que
los alumnos pueden estudiar sistemas de control
distribuidos en tiempo real. Esto proporciona una
herramienta útil a la hora del prototipado rápido
y primera fase de evaluación de algoritmos de
control. La plataforma proporciona un método
rápido y seguro de experimentación, con la ven-
taja de incorporar comportamientos más reales a
nivel de comunicaciones y sensorización. Cuestión
fundamental en el control de procesos.
Por último, las vı́as propuestas para trabajos fu-
turos es el reemplazo de la herramienta xPC por
una implementación basada en Open Source como
Octave[16] o Scilab[21], u otro sistema basado en
Linux ejecutándose en tiempo real. Por otro la-
do, el interface de usuario puede ser modificado
con el objetivo de incluir mayor funcionalidad y
versatilidad.
Agradecimientos
Parcialmente financiado por los proyectos de in-
vestigación DPI 2005-07835, DPI 2004-08383-C03-
02 del MEC-FEDER y GVA-026.
Referencias
[1] xPC Target User’s Guide. The Mathworks,
Inc., Natick, MA., 2 edition, 2002.
[2] J. Aracil and F. Gordillo. The inverted pen-
dulum: a benchmark in nonlinear control. In
Proceedings of the World Automation Con-
gress. Seville, 2004.
[3] P. Balbastre, I. Ripoll, J. Vidal, and A. Cres-
po. A task model to reduce control delays.
The Journal of Realtime Systems, 27(3):215–
236, 2004.
[4] H. Benmohamed, A. Leleve, and P. Prevot.
Generic framework for remote laboratory in-
tegration. International Conference on Infor-
mation Technology Based Higher Education
and Training, 2005.
[5] Blender. Available: http://www.blender.org.
[6] H. Boterenbrood. Canopen: high-
level protocol for can-bus. Available:
http://www.nikhef.nl/, 2000.
[7] A. Cervin and J. Ecker. Feedback schedu-
ling of controls task. Proceedings of the 39th
IEEE conference on Decision and Control.,
2000.
[8] A. Crespo, I. Ripoll, and P. Albertos. Redu-
cing delays in rt control: The control action
interval., 1999.
[9] B. Duan, K. Ling, H. Mir, M. Hosseini,
and R.K.L. Gay. An online laboratory fra-
mework for control engineering courses. In-
ternational Journal of Educational Enginee-
ring, 6(21):1068, 2005.
[10] S. Garcı́a-Nieto, A. Llosá, F. Llaneras, and
F. Sanchı́s. Simulation platform and distribu-
ted control in real time (in spanish). Jornadas
automática. Alicante, pages 195–202, 2005.
[11] S. Garcı́a-Nieto, A. Llosá, M. Martı́nez, and
X. Blasco. Implementation of energy shaping
algorithms in real time (in spanish). Jorna-
das de Automática. Alicante, pages 389–396,
2005.
[12] GNU. Available: http://www.gnu.org/.
[13] Netbeans Development IDE. Available:
http://www.netbeans.org.
[14] Real Time Linux. Available:
http://rt.wiki.kernel.org.
[15] A. Llosá, S. Garcı́a-Nieto, M. Martı́nez, and
J. Sanchis. Nonattendance educational stra-
tegies for nonlinear control using the inverted
pendulum. 7th IFAC Symposium on Advan-
ces in Control Education, June 2006.
[16] GNU Octave. Available:
http://www.octave.org/, 2006.
[17] Ocera Project. Availa-
ble:http://www.ocera.org.
[18] I. Ripoll. Tutorial rtlinux. available:
http://www.gii.upv.es/personal/iripoll/rtlinux.
[19] R. Sanchez-Peña and M. Sznaier. Robust sys-
tems theory and applications. John Wiley &
Sons, 1998.
[20] K. Schilling, T.M. Adami, and R.D. Irwin. A
virtual laboratory for space systems enginee-
ring experiments. Proc. 5 thIFAC Symp. on
Automatic Control in Aerospace.
[21] The open source platform for nume-
rical computation Scilab. Available:
http://www.scilab.org/, 2006.
[22] V. Yodaiken. The rtlinux manifesto. Availa-
ble: http://www.rtlinux.org, 2006.