ROS: un sistema de robot operativo de código abierto

I. INTRODUCCIÓN

Crear software para robots es algo difícil, debido a que la escala y el alcance de la robótica
continúa creciendo. Los diferentes tipos de robots pueden tener hardware que varía enormemente,
lo que hace que la reutilización de código no sea trivial. Además, el gran tamaño del código
requerido puede ser desalentador.

Para estos retos, los investigadores de la robótica han creado una amplia variedad de marcos para
manejar la complejidad y facilitar la creación rápida de prototipos de software para experimentos,
dando lugar a los muchos sistemas de software robótico actualmente utilizados en el mundo
académico y la industria.

El énfasis en la investigación robótica integradora a gran escala será útil en una amplia variedad
de situaciones a medida que los sistemas robóticos se vuelven cada vez más complejos. En este
documento, se tratará los objetivos de diseño de ROS, cómo nuestra implementación funciona
para ellos y cómo ROS maneja varios casos de uso común de desarrollo de software robótico.

II. Los objetivos de diseño

No afirmamos que ROS es el mejor marco para todos los softwares de robótica. ROS fue creado
para cumplir un conjunto específico de desafíos encontrados al desarrollar robots de servicio a
gran escala como parte del proyecto STAIR en la Universidad Stanford y el Programa Personal
Robots en Willow Garage.

Los objetivos filosóficos de ROS se pueden resumir como:

• Punto a punto
• Basado en herramientas
• Multilingüe
• Delgado
• Libre y de código abierto

A. Punto a punto

Un sistema creado utilizando ROS consiste en una cantidad de procesos, potencialmente en una
cantidad de hosts diferentes, conectados en tiempo de ejecución en una topología punto a punto.
Aunque los marcos basados en un servidor central también pueden darse cuenta de los beneficios
del diseño multiproceso y multi-hospitalario, un servidor de datos central es problemático si las
computadoras están conectadas en una red heterogénea.
La topología punto a punto requiere algún tipo de mecanismo de búsqueda para permitir que los
procesos se encuentren entre sí en tiempo de ejecución.

B. Multilingüe

Al escribir código, las personas muestran preferencias para lenguajes de programación, estas
preferencias son el resultado del tiempo de programación, facilidad de depuración, sintaxis,
eficiencia del tiempo de ejecución y una serie de otras razones, tanto técnicas como culturales.
Por ello, se ha diseñado ROS para que sea neutral en cuanto al idioma, actualmente, ROS admite
cuatro lenguajes muy diferentes: C ++, Python, Octave y LISP, con otros puertos de idiomas en
varios estados de finalización.

Para respaldar el desarrollo de idiomas cruzados, ROS utiliza un lenguaje de definición de interfaz
(IDL) de idioma neutro y simple para describir los mensajes enviados entre los módulos. El IDL
usa archivos de texto muy cortos para describir los campos de cada mensaje y permite la
composición de los mensajes.

Como los mensajes se generan automáticamente a partir de archivos de texto simples, es fácil
enumerar nuevos tipos de mensajes que transportan datos que van desde las transmisiones de
sensores a las detecciones de objetos y mapas. El resultado final es un esquema de procesamiento
de mensajes independiente del idioma en el que diferentes idiomas se pueden mezclar y combinar
según se desee.

C. Basado en herramientas

El diseño de microkernel, que utiliza un gran número de pequeñas herramientas para construir y
ejecutar los diversos componentes de ROS, además de construir un entorno monolítico de
desarrollo y tiempo de ejecución.

Las tareas que realizan estas herramientas son por eje.: navegar por el árbol de códigos fuente,
obtener y establecer parámetros de configuración, visualizar la topología de conexión punto a
punto, medir la utilización del ancho de banda, graficar gráficamente los datos del mensaje,
generar automáticamente la documentación.

D. Delgado

La mayoría de los proyectos de software de robótica contienen controladores o algoritmos que

podrían ser reutilizados fuera del proyecto. El sistema de compilación ROS realiza construcciones
modulares dentro del árbol de códigos fuente, y su uso de CMake hace que sea relativamente fácil
seguir esta ideología "delgada". Situar virtualmente toda la complejidad en las bibliotecas, y solo
crear pequeños ejecutables que expongan la funcionalidad de la biblioteca a ROS, permite una
extracción y reutilización de código más sencilla más allá de su intención original.
E. Libre y de código abierto

El código fuente completo de ROS está a disposición del público que es fundamental para facilitar
la depuración en todos los niveles de la pila de software.

ROS se distribuye bajo los términos de la licencia BSD, que permite el desarrollo de proyectos
tanto comerciales como no comerciales. ROS pasa datos entre módulos utilizando
comunicaciones entre procesos, y no requiere que los módulos se vinculen en el mismo ejecutable.
Los sistemas construidos alrededor de ROS pueden usar la licencia de grano fino de sus diversos
componentes: los módulos individuales pueden incorporar software protegido por varias licencias
que van desde GPL a BSD a propietario, pero la "contaminación" de licencia termina en el límite
del módulo.

II. NOMENCLATURA

Los conceptos fundamentales de la implementación de ROS son nodos, mensajes, temas y

servicios. Los nodos son procesos que realizan cálculos, ROS está diseñado para ser modular un
sistema compuesto por muchos nodos. El término "nodo" es intercambiable con "módulo de
software". Y para nosotros "nodo" surge de visualizaciones de sistemas basados en ROS en
tiempo de ejecución.

Los nodos se comunican entre sí al pasar mensajes. Un mensaje es una estructura de datos
estrictamente tipada. Los mensajes pueden estar compuestos de otros mensajes y matrices de otros
mensajes, anidados de forma profunda. Un nodo envía un mensaje publicándolo en un tema
determinado, puede haber varios editores y suscriptores simultáneos para un único tema, y un solo
nodo puede publicar y/o suscribirse a múltiples temas. En general, los editores y los suscriptores
no conocen la existencia de los demás.

En ROS, llamamos a esto un servicio, definido por un nombre de cadena y un par de mensajes
estrictamente tipeados: uno para la solicitud y el otro para la respuesta.

IV. CASOS DE USO

La arquitectura abierta de ROS permite la creación de una amplia variedad de herramientas; al

describir el enfoque ROS para estos casos de uso, también presentaremos una serie de
herramientas diseñadas para ser usadas con ROS.

A. Depuración de un solo nodo

El alcance de una investigación se limita a un área bien definida del sistema, como un nodo que
realiza algún tipo de planificación, razonamiento, percepción o control. Sin embargo, en un
sistema robótico para experimentos, debe existir un ecosistema de software mucho más grande lo
que agrega una cantidad significativa de dificultad a la investigación integradora de robótica.
ROS está diseñado para minimizar la dificultad de depuración, su estructura modular permite que
los nodos en desarrollo activo se ejecuten junto con los nodos preexistentes y bien depurados.
Debido a que los nodos se conectan entre sí en el tiempo de ejecución, el gráfico se puede
modificar dinámicamente. Lo que puede generar un aumento masivo de la productividad,
especialmente a medida que el sistema robótico se vuelve más complejo e interconectado. La
facilidad de insertar y eliminar nodos de un sistema basado en ROS es una de sus características
más potentes y fundamentales.

B. Registro y reproducción

ROS apoya el enfoque de proporcionar una funcionalidad genérica de registro y reproducción. Es

decir, cualquier flujo de mensajes ROS puede descargarse en el disco y luego volver a
reproducirse. Es importante destacar que todo esto se puede hacer en la línea de comando; no
requiere modificación del código fuente de ninguna pieza de software en el gráfico.

C. Subsistemas empaquetados

Para permitir la funcionalidad "empaquetada", como un sistema de navegación, ROS proporciona

una herramienta llamada roslaunch, que lee una descripción XML de un gráfico y crea una
instancia del gráfico en el clúster, opcionalmente en hosts específicos. La experiencia del usuario
final al iniciar el sistema de navegación se reduce a una sola Ctrl-C y cierra con gracia los cinco
procesos.

Esta funcionalidad también puede ayudar significativamente a compartir y reutilizar grandes

demostraciones de investigación robótica integrativa, ya que la configuración y el desmontaje de
grandes sistemas distribuidos se pueden replicar fácilmente.

D. Desarrollo colaborativo

Debido al gran alcance de la robótica y la inteligencia artificial, la colaboración entre

investigadores es necesaria para construir sistemas grandes. Para esto el sistema de software ROS
está organizado en “paquetes” deliberadamente abiertos: un paquete ROS es simplemente un
directorio que contiene un archivo XML que describe el paquete y establece las dependencias.

ROS proporciona una utilidad llamada rospack para consultar e inspeccionar el árbol de códigos,
buscar dependencias, buscar paquetes por nombre, etc. Se proporciona un conjunto de
expansiones de shell llamado rosbash para mayor comodidad, acelerando la navegación de la
línea de comandos del sistema.

La utilidad rospack está diseñada para admitir el desarrollo simultáneo en múltiples repositorios
de paquetes ROS, y rospack rastrea los árboles de paquetes según sea necesario. Las
compilaciones recursivas, respaldadas por la utilidad rosmake, permiten dependencias de
bibliotecas de paquetes cruzados.

E. Visualización y Monitoreo

ROS puede explotar la naturaleza dinámica del gráfico de conectividad para "aprovechar"
cualquier flujo de mensajes en el sistema; el desacoplamiento entre editores y suscriptores permite
la creación de visualizadores de propósito general. Se pueden escribir programas simples que se
suscriben a un nombre de tema en particular y trazan un tipo particular de datos, como escaneos
láser o imágenes. Sin embargo, un concepto más poderoso es un programa de visualización que
utiliza una arquitectura de complemento: esto se hace en el programa rviz, que se distribuye con
ROS.

F. Composición de la funcionalidad

En ROS, una "pila" de software es un grupo de nodos que hace algo útil, ROS puede crear
instancias de un clúster de nodos con un solo comando; pero, a veces se desean múltiples
instancias de un clúster. ROS admite esto al permitir que los nodos y los archivos de descripción
de clúster roslaunch completos se inserten en un espacio de nombres secundario, que garantiza
que no haya colisiones de nombres. Esto antepone una cadena a todos los nombres de nodo, tema
y servicio, sin requerir ninguna modificación al código del nodo o clúster.

G. Transformaciones

Los sistemas robóticos necesitan rastrear las relaciones espaciales por una variedad de razones:
entre un robot móvil y un marco de referencia fijo para localización. Para simplificar y unificar
el tratamiento de marcos espaciales, se ha escrito un sistema de transformación para ROS, llamado
tf que construye un árbol de transformación dinámica que relaciona todos los marcos de referencia
en el sistema. A medida que la información fluye desde los diversos subsistemas del robot
(codificadores de unión, algoritmos de localización, etc.), el sistema tf puede producir flujos de
transformaciones entre nodos en el árbol al construir una ruta entre los nodos deseados y realizar
los cálculos necesarios.

CONCLUSIONES:

• Este sistema operativo de código abierto, se visualiza como una herramienta para el
avance profundo en los proyectos de investigación académica e industrial.
• ROS permite realizar desde las aplicaciones más básicas, por lo que es muy utilizado ya
que se trata de una estructura muy flexible y adaptable a diversas necesidades.
 • Por su variedad de plataformas, lenguajes, compiladores, y paquetes de aplicaciones
desarrolladas por investigadores y empresas de la robótica permiten que otros las puedan
usar y lo mejor, modificar y crear nuevas y mejoradas opciones.

1.1 Introducción

El concepto de sistemas de computación digital en tiempo real es un concepto emergente en

comparación con la mayoría de la teoría y práctica de la ingeniería. La plataforma informática
debe procesar la entrada relacionada con la solicitud de servicio y producir una respuesta de salida
antes de una fecha límite medida con respecto a un evento detectado anteriormente. El sistema de
computación digital en tiempo real debe producir una respuesta a petición mientras el usuario y /
o sistema espera. Después de la fecha límite establecida para la respuesta, en relación con el
tiempo de solicitud, el usuario se da por vencido o el sistema no cumple con los requisitos si no
se ha producido ninguna respuesta.

El tiempo real se refiere a aplicaciones o procesos informáticos que pueden responder con una
latencia baja a las solicitudes de los usuarios. Un sistema correcto en tiempo real debe producir
una respuesta de salida funcionalmente (algorítmicamente y matemáticamente) correcta antes de
una fecha límite bien definida en relación con la solicitud de un servicio.

El concepto de sistemas integrados tiene un historial similar y relacionado con los sistemas en
tiempo real y es principalmente un enfoque que limita el alcance para evitar plataformas de
computadora de escritorio generales que podrían incluirse en un sistema en tiempo real. Por
ejemplo, el centro de control de la misión Johnson Space Center de la NASA incluye una gran
cantidad de estaciones de trabajo de escritorio comerciales para el procesamiento de datos de
telemetría casi en tiempo real.

Una vez más, una definición de incrustación de sentido común es útil para entender qué se piensa
por un sistema integrado en tiempo real. Incrustación significa encerrar o implantar como esencial
o característica. Un sistema integrado es una computadora de propósito especial contenida dentro
del dispositivo que controla y que no puede ser observada directamente por el usuario del sistema.
Un sistema integrado realiza servicios predefinidos en lugar de funciones y servicios
especificados por el usuario como lo hace una computadora de propósito general. La industria de
sistemas incorporados en tiempo real está llena de terminología especializada que se ha
desarrollado como un subconjunto de la terminología general de sistemas informáticos.

1.2 Breve Historia de Sistemas en Tiempo Real

El origen del tiempo real proviene de la historia reciente del control de procesos usando
plataformas informáticas digitales. El concepto de tiempo real también está arraigado en la
simulación por computadora, que se ejecuta al menos tan rápido como el proceso físico del mundo
real que modela se ejecuta en tiempo real.

La ampliación de la cobertura de los conceptos de tiempo real suave y el uso de sistemas

operativos de mejor esfuerzo ha sido añadida a la segunda edición de este libro en el capítulo 11
porque los lectores que trabajan con Linux embebido y con requisitos no tan estrictos como en
tiempo real duro, que los plazos no deben pasarse por alto ya que, por definición, esto significa
fallo total del sistema.

El concepto de sistemas duros en tiempo real llegó a comprenderse mejor sobre la base de la
experiencia y los problemas detectados con los sistemas desplegados. Un ejemplo muy claro fue
cuando el sistema Apollo 11 sufrió una sobrecarga de recursos de la CPU que amenazaba con
hacer que los servicios de orientación de descenso incumplieran los plazos y casi provocó la
interrupción del primer aterrizaje en la luna. Durante la bajada del módulo lunar y con el uso del
sistema de radar, el astronauta Buzz Aldrin observó una alarma del sistema de guía por
computadora. En base a su experiencia, la decisión fue seguir adelante y pasar por alto la alarma.

Cuando el hardware, firmware y software se combinan en un sistema embebido en tiempo real,

el tiempo de respuesta debe ser diseñado y probado para asegurar que el sistema integrado cumple
con los requisitos de los plazos. Esto requiere un diseño a nivel de sistema y prueba que van más
allá de los métodos de hardware o software utilizado normalmente, la mayoría de los ingenieros
de hardware están familiarizados con los métodos para diseñar la sincronización lógica digital y
verificar la corrección.

1.3 Breve Historia de los Sistemas Integrados

Incrustar es un concepto más antiguo que el tiempo real. Los sistemas informáticos digitales
integrados a menudo son una parte esencial de cualquier sistema integral en tiempo real y de
entrada detectada para producir respuestas como salida a los actuadores. Los sensores y
actuadores son componentes que proporcionan E/S y definen la interfaz entre un sistema integrado
y el resto del sistema o aplicación.

Una estación de trabajo de propósito general proporciona una plataforma para que grupos de
servicios no especificados sean determinados, mientras que un sistema integrado proporciona un
servicio bien definido o un conjunto de servicios tales como control anti bloqueo. Finalmente, el
objetivo de un sistema integrado es la rentabilidad, un conjunto más limitado de servicios en un
sistema más grande, como un automóvil, una aeronave o un centro de conmutación de
telecomunicaciones.

1.4 Servicios en tiempo real

El concepto de un servicio en tiempo real es fundamental en sistemas integrados en tiempo real.

Conceptualmente, un servicio en tiempo real proporciona una transformación de entradas a salidas

en A y un sistema integrado para proporcionar una función. Por ejemplo, un servicio puede
proporcionar control térmico para un subsistema detectando la temperatura con termistor para
enfriar el subsistema con un ventilador o para calentarlo con bobinas eléctricas. El servicio
provisto en este ejemplo es la gestión térmica de modo que la temperatura del subsistema se
mantenga dentro de un rango establecido. Dentro de los servicios integrados en tiempo real están
las funciones de control digitales y son de naturaleza periódica. En el caso del control digital, los
servicios deben proporcionar la función dentro de las limitaciones de tiempo requeridos para
mantener la estabilidad. En el caso de los servicios de voz, la función debe ocurrir dentro de las
limitaciones de tiempo para que el oído humano es razonablemente con audio claro.

Cuando se utiliza una aplicación de software para múltiples servicios en una sola CPU, el sondeo
de software a menudo se sustituye con hardware de la detección de eventos y codificación de
entrada. Esta máquina de estado de hardware entonces afirma una entrada de interrupción en la
CPU, que a su vez establece un indicador utilizado por una máquina de estado de programación
para indicar que un servicio de procesamiento de datos de software debe ser enviado para su
ejecución.

Los tiempos de espera se implementan utilizando hardware temporizadores de intervalo, que

también afirman interrupciones a la CPU multiservicio. Si expira un temporizador de intervalos,
las condiciones de tiempo de espera son manejados por una función de error porque se espera que
el servicio normalmente sea lanzado antes del tiempo de espera. Independientemente de si el
servicio está activado por un tiempo de espera o un acontecimiento en el mundo real, el servicio
siempre se comprueba con el servicio de salud y el sistema de supervisión del estado mediante la
publicación de una indicación vitalidad.

En última instancia, el estado del mundo real se sondea por una máquina de estados de hardware,
mediante una máquina de estados de software, o por una combinación de ambos. Una
combinación de ambos es a menudo es la mejor solución y es uno de los métodos más populares.
La implementación de servicios de datos en el software proporciona flexibilidad para que las
modificaciones y mejoras se pueden hacer mucho más fácilmente en la comparación con la
modificación de hardware.

En general, la mayoría de los servicios requieren una integración de componentes, incluyendo al

menos hardware y software. Los eventos del mundo real se detectan utilizando sensores, a
menudo transductores y convertidores de analógico a digital, y están atados a una interrupción de
microprocesador con datos, control, y memorias intermedias de estados. Esta interfaz sensor
proporciona la entrada necesaria para el procesamiento de servicios. El procesamiento transforma
la entrada de datos asociados con el evento en una salida de respuesta. La salida de respuesta es
más a menudo implementada como una interfaz de convertidor de digital a analógico a un
accionador electromecánico. La respuesta es computada a continuación, transferidos a la interfase
digital a analógico para controlar algún dispositivo situado en el mundo real.

Control digital tiene una clara ventaja sobre analógico, ya que puede ser programado sin
modificaciones de hardware. Un sistema de control analógico, o un ordenador analógico, requiere
reverenciar y modificación de los inductores, condensadores y resistencias utilizadas en los
circuitos de control. Los servicios de periódicos en los sistemas de control digitales aplicar la ley
de control de un sistema de control digital. Cuando un microprocesador está dedicado a un solo
servicio, el diseño y la implementación de los servicios son bastante simples.

En última instancia, todos los servicios en tiempo real pueden ser sólo de hardware o una
combinación de hardware y software de procesamiento con el fin de UNK eventos a actuaciones
para monitorear y controlar algún aspecto de un sistema general. Finalmente, después de un
servicio produce una salida digital, habrá algo de latencia en la transferencia de la memoria de
trabajo a la memoria del dispositivo y el potencial de conversión DAC para la salida de
accionamiento.

Hasta el momento, todas las aplicaciones y tipos de servicios considerados han sido periódica.
Uno de los ejemplos más comunes de un servicio en tiempo real que no es periódica, por
naturaleza, es el servicio de control de errores. Normalmente, un sistema no tiene fallas, si
periódica o regularmente lo hace, probable el sistema necesita ser reemplazado. Por lo tanto, el
manejo de errores es a menudo asíncrona. La línea de tiempo y características de un servicio en
tiempo real asincrónica son, sin embargo, no es diferente de las ya estudiadas.

1.5 Los estándares de tiempo real

Las normas en tiempo real POSIX (Portable Interfaz de Sistemas Operativos) se han consolidado
en una única actualización 1003.1 estándar a partir de 2013 [POSIX 1003.l]. Originalmente, las
normas en tiempo real reconocidos por el IEEE (Instituto de Ingenieros Eléctricos y Electrónicos),
así como el Open Group fueron escritos como extensiones específicas a las normas básicas de
POSIX, incluyendo:

1. IEEE Std 2003.lb-2000: Pruebas para la especificación POSIX parte 1includ ing
extensiones de tiempo real.
2. IEEE Std 1.003,13 a 1.998: aplicaciones en tiempo real perfil estándar para abordar en
tiempo real y dispositivos huella más pequeña.
3. IEEE Std 1003.lb-1993: Extensión en tiempo real.
4. IEEE Std 1003.lc-1995: Hilos
 5. IEEE Std 1003.ld-1999: Extensiones adicionales en tiempo real.
6. IEEE Std 1003.lj-2000: Extensiones de tiempo real avanzada.
7. IEEE Std 1003.lq-2000: Rastreo.

La primera y uno de los cambios más significativos realizados en la norma base original para
sistemas de tiempo real fue designado 1003.lb, que especifica la API (Application Programmer
Interface) que la mayoría de los sistemas operativos RTOS (Real-Time Operating System) y
Linux ponen en práctica en su mayoría. Las extensiones POSIX 1003.lb incluyen la definición de
los mecanismos del sistema operativo en tiempo real:

1. Programación de prioridad
2. Señales en tiempo real
3. Relojes y temporizadores
4. Semáforos
5. Paso de mensajes
6. Memoria compartida
7. Asíncronos y síncronos VO
8. Bloqueo de memoria

Algunas normas adicionales interesantes en tiempo real que van más allá de los RTOS o soporte
del sistema operativo de propósito general incluyen:

1. DO-l78B y actualizada DO-l78C, Consideraciones sobre el software en sistemas de vuelo

y certificación de equipos.
2. JSR-1, Especificación de tiempo real para Java, recientemente actualizada por el NIST
(Instituto Nacional de Estándares y Tecnología).
3. La aplicación TAO en tiempo real CORBA (Arquitectura de Solicitud de Objeto Común)
4. El IETF (Equipo de Trabajo de Ingeniería de Internet) RTP (Protocolo de Transporte en
Tiempo Real) y RTCP (Protocolo de Control en Tiempo Real) RFC 3550.
5. IETF RTSP (Protocolo de Transmisión en Tiempo Real) RFC 2326.

Conclusiones:

 Como vimos los sistemas de tiempo real desempeñan un papel muy importante ya que
debe tener la capacidad de llevar a cabo tareas en un tiempo de respuesta mínimo y con
gran éxito.
 Estos sistemas de tiempo real se encuentran en constante desarrollo ya que con los
avances tecnológicos se fabrican nuevas máquinas que funcionan en tiempo real y que
 por consiguiente necesitan tener sistemas controlados por computadores que posean la
capacidad de interactuar con los demás.
 La utilidad de los sistemas de tiempo real es muy grande ya que actualmente se aplican
en una gran variedad de áreas como: telecomunicaciones, sistemas multimedia, robóticos,
aviación, automovilismo, electrodomésticos, sistemas médicos, etc.

Aplicación:

Un problema en un banco en el cual se producen pérdidas, una deuda incontrolable o la pérdida

de un cliente importante. Se podría aplicar los sistemas de tiempo real para que así el personal de
la empresa estuviera conectado a un sistema informático en tiempo real que controle todas sus
operaciones autorizando que se cumplan las normas preestablecidas y reteniendo las que no sean
autorizadas o rechazadas por la persona o personas con atribución para ello quien recibe
inmediatamente un aviso por correo electrónico en el que se le indica que tiene una operación
pendiente de autorizar u los parámetros que han provocado la irregularidad.

Preguntas

1. ¿Qué normas cumplen el sistema de tiempo Real?

a) POSIX

b) ISO

c) ASO

d) ASCII

La normas utilizadas es el sistema POSIX y sustentada por la IEEE.

2. ¿En qué lenguaje trabaja el ROS?

a) C ++

b) Python

c) Octave

d) LISP

e) Todos los anteriores

No tiene un lenguaje de programación estricto se puede trabajar con C ++, Python, Octave y LISP
entre otros.
3. Defina lo que es RTOS

a) Es una aplicación de internet en tiempo real

b) Es una interfaz usada en el hardaware para interpretar el tiempo real

c) Es una interfaz en tiempo real de programación

d) Es una aplicación de Unix

Es una interfaz en tiempo real de programación en si RealTime Operating System muy

implementado en Linux.