Sistemas operativos de tiempo real para PCs - Busco recomendaciones

Hola.
Como dice el título, quería saber si alguien puede comentar sus experiencias con sistemas operativos de tiempo real para PC's. Que proyectos implementaron, diferencias en la programación entre un lenguaje visual para PC y un RTOS, limitaciones, etc.
Es un tema que creo puede ser de interes para toda la comunidad, dado que al trabajar con sistemas embebidos siempre hay restricciones temporales a cumplir, tal vez procesar datos adquiridos por microcontroladores, procesarlos en la PC, y comunicar las salidas de control de vuelta al microcontrolador...
Buscando por la web hay bastante variedad, pero no conozco a nadie que haya trabajado con eso.
Cualquier comentario será más que bienvenido.
 
Hola, bueno, el sistema operativo que más se acerca es el MS-DOS instalado como sistema dentro de un PC, y no el MS-DOS en una ventana de windows.

No sé qué hay de Linux instalado en forma básica...

saludos
 
algunos comentarios.....

MS-DOS como tal no es un sistema multitarea, asi que necesitarias un kernel que soporte multitarea ejecutandose encima.

el Kernel de Linux no es de tiempo real, asi que depende de tu aplicación si te llega a servir. Afortunamente a Linux se le puede cambiar el kernel y ponerle uno de Tiempo real.

No me late mucho la idea de tener una PC ejecutando un RTOS y aparte otro sistema para adquirir datos. Soy mas de la idea de Jonathan, aunque tal vez un PIC pudiera quedarse corto, yo veria por un procesador ARM... (de hecho me encuentro realizando un RTOS para un ARM..)
 
El unico sistema operativo de tiempo real para PCs que está probado y funcionando hace años en instalaciones industriales alrededor del mundo es un UNIX que se llama QNX. Se puede descargar una versión educativa (por así decirlo) desde su web, que es muy reducida de tamaño y tiene un entorno gráfico impresionante mas los compiladores C/C++ y toda la bola de drivers de red, etc.

Es un sistema operativo de tiempo real con un scheduler específicamente diseñado para esta tarea y no un kernel multitarea común y silvestre. Provee retardos determinísticos a las interrupciones y a la ejecución de procesos, y puede usar toda la potencia de un procesador de PC en aplicaciones de todo tipo, pero que básicamente son de control industrial.

También hay unos parches para el Kernel Linux que lo trasforman en RT y dicen que andan muy bien, pero yo no he trabajado con ellos.

Saludos!
 
Lo de hacerlo con un PIC me pareció una buena idea ya que el proyecto que yo digo está terminado , solo hay que mejorarlo y hacerlo más útil. Lo bueno es que a partir del código funcional se puede utilizar por ejemplo un pic24f o un dspic. Mi idea con esto del kernel multitarea era implementarlo en un robot y que este ejecute acciones mientras lee el estado de los sensores
 
Me parece que no tenes muy claro el concepto de Tiempo Real...

El problema con un PIC y un kernel multitarea, mas allá de las facilidades de programación y desarrollo que hay en la PC, es que el kernel sea multitarea NO IMPLICA QUE SEA DE TIEMPO REAL. Si el kernel no es de tiempo real, no tenes garantías de cuando se ejecutan los procesos y la respuesta a las interrupciones. Hay aplicaciones donde esto es clave...y hay otras en las que puede no importar.

No conozco el caso de tu robot y los sensores que debe leer, pero lo que seguramente es clave es que cuando llegue el instante de muestreo, el proceso que se ejecuta en ese instante comience y termine dentro de los plazos estipulados, o al menos con el mínimo retardo posible y de valor conocido. Nuevamente, depende de la tarea que deba hacer el robot: si es un control de movimiento (posición y/o velocidad) de las articulaciones puede ser medianamente importante este comportamiento, pero si es un control de impedancia de una garra robótica que tiene que tomar y transportar huevos, el tema del control en tiempo y forma se vuelve particularmente crítico, a riesgo de terminar con una tortilla alrededor del brazo...

Saludos!
 
Gracias ezvalla, hiciste algo con el QNX?.

Esto es más bien un ejercicio de imaginación, no voy a implementar nada de esto, pero si me piden una propuesta de como creo que debería hacerse.

Es un control de un brazo robótico. Yo hago el control de una articulación y otra gente de las demás articulaciones. El tema es que ni conozco esa gente, ni se como habra hecho cada uno para controlar su articulación, y algun control se hizo hace años y otro tal vez se hara el año que viene....

Pero sí se que todos tienen acceso desde una PC.
En la PC tendría que correr un programa que transformadorrme coordenadas del brazo (posición/orientación) a coordenadas articulares (que las articulaciones muevan x grados para un lado o para el otro).

Además pensando en un brazo que tiene que interactuar con su entorno con cosas en movimiento, también precisará recibir información del mismo, ver de no chocar nada....
También la PC serviría para guardar históricos, datos del proceso en el que esté el robot, daría interfaz de usuario y proveería conectividad a través de una tarjeta de red (monitoreo/control remoto) para interactuar con su celda de trabajo.

Entonces bueno, si uno le quiere exprimir precisión y velocidad al brazo un entorno como Windows no es la mejor opción. Esta muy lejos del hard de la PC, hay retardos importantes en los puertos (uno envía un dato desde su programa, se hace una petición al sistema, cuando el sistema operativo tiene tiempo toma esa petición y la atiende con su respectivo driver, luego recibe la respuesta, otra vez cuando al SO se le canta atiende esa entrada y devuelve la respuesta al programa. A su vez el programa puede tener varios hilos de ejecución en paralelo, asi que ahora dependera del programador de tareas de windows, etc...), si uno quiere seguir una trayectoria precisa con el brazo lo veo complicado. No sería problema posicionarlo (se tardaría un poco más en todo caso).
Bueno, voy a leer un poco sobre QNX y ver que posibilidades tiene.

Gracias a todos por participar
 
En realidad, estuve chusmeando el trabajo de un grupo de personas en el Instituto de Automatica de la UNSJ, que es donde trabajo. Ellos reemplazaron el control de un brazo Bosch SR-800 (creo que ese es el codigo del modelo) que estaba hecho en dos PCs bajo DOS y Novell (esto lo hice con unos alumnos) en 1994, por otra version basada en QNX, por que necesitaban controlar el robot vía red desde Matlab y hacer no se que otros engendros leyendo sensores remotos y conectandolo a un dispositivo de ayuda a personas con discapacidades tales como la falta de un brazo. Entonces, con el dispositivo este leían la información miográfica de una persona y movían el brazo robotico "como si fuera el brazo" que la persona había perdido.

Muy buen laburo, pero el control del robot corre bajo QNX con tiempos de muestreo del orden del milisegundo, si mal no recuerdo, por que le estaban poniendo sensores de fuerza que requerían muestreo de alta velocidad.

De todas formas, yo había usado antes QNX cuando hicimos algunos trabajos para SIDERAR en San Nicolás y ahí conocí la potencia de ese sistema operativo. En esa empresa hacían uso masivo de QNX para el control de los procesos...

Saludos!
 
Gracias ezavalla, muy interesante lo del trabajo del brazo robótico. No se me ocurre nada más potente que combinar Matlab (por la enorme cantidad de cosas que se pueden hacer con él, y porque es un programa que se usa en casi cualquier carrera de ing.) con un RTOS que asegure los tiempos del sistema.
De hecho el Matlab tiene un módulo RTW (Real Time Workshop), que no lo he visto todavía.
Ja, a lo mejor utilicé algun producto tuyo en Siderar cuando hice una pasantía en Florencio Varela. Me acuerdo que había un programa Photon-QNX para ver datos de las líneas de producción (de corte de chapa). Ni me acordaba que lo había usado.

Bueno, tengo para investigar un buen rato, gracias de vuelta ya tengo un hilo conductor para empezar.

Saludos
 
Atrás
Arriba