Diferencia entre revisiones de «Monitor»

Revisión actual del 00:42 19 sep 2015

Integrantes

• Gonzalo Crovetto crovetto.gonzalo@gmail.com
• Federico Mujica federicomujica1@gmail.com
• Nicolás Vázquez nicovazquez90@gmail.com

Tutor

• Gonzalo Tejera gtejera@fing.edu.uy

Introducción

La plataforma Butiá se caracteriza por su amigabilidad y ayuda al usuario. Este proyecto plantea estudiar las posibilidades de ampliar la ayuda al usuario mediante la incorporación de un elemento monitor, que permita diagnosticar y apoyar el desarrollo de comportamientos .

Objetivos

Nos planteamos los siguientes objetivos:

• Brindar nuevas funcionalidades a Turtlebots para poder reconocer más intuitivamente los posibles problemas que puedan estar sucediendo.

• Lograr que los nuevos usuarios puedan reconocer fácilmente dichos problemas, haciendo que su período de aprendizaje sea más ameno y menos frustrante.

• Dejar el camino abierto a la implementación de nuevas funcionalidades que permitan el monitoreo no solo de errores, sino de determinados comportamientos que puedan ser de interés para el usuario

¿Cómo lograrlo?

• Encontrando los errores que se manifiestan con normalidad.
• Identificando cada uno de dichos errores y agrupándolos para darles un significado distinto que el usuario pueda comprender.
• Modificando la visualización de los componentes de acuerdo al error identificado.

Motivación

Al finalizar este proyecto debemos poder brindar una forma intuitiva para usuarios sin conocimientos de electrónica ni programación de saber cual es el estado de los sensores butia. De esta forma, el usuario puede darse cuenta cuando cambiar un cable o un sensor defectuoso que este afectando su programa.

Investigación

Previo a poder implementar algunas de las ideas que nos surgían, pasamos por un largo proceso de investigación del funcionamiento de la plataforma Butiá. Identificamos módulos clave en la arquitectura del sistema, que se comunican de la siguiente manera:

En el centro de la imagen pueden verse las componentes centrales del sistema: pybot_client y pybot_server. Al iniciar TurtleBots, se inicializan ambos, y toda la interacción que podemos hacer desde la interfaz gráfica se va a traducir en comandos que se envían desde pybot_client hacia pybot_server, donde son atendidos estos pedidos.

Desarrollo

Mantenemos el código en el siguiente repositorio Git: https://github.com/nvazquez/Turtlebots

Como puede verse en el directorio /plugins/butia hemos creado dos nuevas clases:

• MonitorButia (definido en el archivo monitor.py)
• MonitorElem (definido en el archivo monitor_elem.py)

MonitorButia

Definición

Nuestra clase MonitorButia está compuesta por un hash llamado sensors, en el cual la clave de cada elemento es el String que identifica a cada uno de los sensores o actuadores, y el valor es un arreglo de 6 elementos MonitorElem (ya que es el número máximo de puertos que contiene la placa USB4Butia). Ademas contamos con las claves por separado en el atributo sensors_name. Para clarificar veamos la inicialización de la clase MonitorButia:

def __init__(self):
    self.sensors = {
        'grey': [MonitorElem() for i in range(6)],
        'light':[MonitorElem() for i in range(6)],
        'distanc': [MonitorElem() for i in range(6)],
        'button': [MonitorElem() for i in range(6)],
        'motors': [MonitorElem() for i in range(8)]
    }
    self.sensors_name = ['grey', 'light', 'button', 'distanc','motors']

MonitorElem

Cada instancia de MonitorElem contiene los contadores de errores y las operaciones de monitoreo, las cuales son invocadas desde MonitorButia según el sensor que esté conectado

Identificación de errores

A partir de la investigación del sistema previa al desarrollo, fuimos observando que podemos detectar ciertos tipos de errores, de forma de tener una idea más precisa de que tipo de falla es la que se obtiene, ya que cuando había algún fallo de cualquier tipo siempre se devolvía la constante -1. Por lo tanto incluímos:

• ERROR_BOARD_DISCONECTED = -100 (este error se genera cuando la placa no esta conectada)
• ERROR_MODULE_NOT_PRESENT = -101 (este error se genera cuando el modulo al que se quiere acceder no esta disponible)
• ERROR_EXCEPTION = -102 (este tipo de error lo incluimos para aquellos casos donde puede darse un fallo impredecible)

Para poder hacer uso de estos tipos de errores, tuvimos que modificar la funcion call_module de usb4butia.py

from plugins.butia.monitor import ERROR_BOARD_DISCONECTED
from plugins.butia.monitor import ERROR_MODULE_NOT_PRESENT
from plugins.butia.monitor import ERROR_EXCEPTION

#....

def callModule(self, modulename, board_number, number, function, params = [], ret_type = int):
        """
        Call one function: function for module: modulename in board: board_name
        with handler: number (only if the module is pnp, else, the parameter is
        None) with parameteres: params
        """
        try:
            number = int(number)
            board_number = int(board_number)
            if len(self._bb) < (board_number + 1):
                return ERROR_BOARD_DISCONECTED
            board = self._bb[board_number]
            if board.devices.has_key(number) and (board.devices[number].name == modulename):
                return board.devices[number].call_function(function, params) #Aca puede venir un -1 y lo dejamos asi
            else:
                number = self._open_or_validate(modulename, board) #Trata de obtener el modulo
                if number == ERROR:
                    return ERROR_MODULE_NOT_PRESENT
                return board.devices[number].call_function(function, params) #Aca puede venir un -1 y lo dejamos asi
        except Exception, err:
            if hasattr(err, 'errno'):
                if (err.errno == 5) or (err.errno == 19):
                    self.closeB(board)
            self._debug('ERROR:usb4butia:callModule', err)
            return ERROR_EXCEPTION #Aca exploto

Funciones

En forma gráfica podemos ver sus atributos y métodos:

evaluateResult

Entrada:

• sensor_name : string -> El nombre del sensor o actuador que se está evaluando
• sensor_port : int -> El número de puerto en el que se encuentra conectado el sensor o actuador
• sensor_result : int -> El resultado numérico obtenido al llamar a una función específica del sensor o actuador

Salida:

• Ninguna

Funcionamiento:

• Para el sensor o actuador identificado:
  • Se incrementa el contador de operaciones totales en 1
  • Se evalua sensor_result para detectar si el mismo es un error o no, y en caso de ser un error identificar el tipo de error e incrementar el contador del error correspondiente

getMonitorEvaluation

Entrada:

• Ninguna

Salida:

• Una lista indicando el sensor, puerto donde se encuentra conectado y el tipo de evaluación de errores, el cual puede ser:
  • MONITOR_RETURN_TYPE_NO_OP (indica que no se ha utilizado)
  • MONITOR_RETURN_TYPE_LOW (indica que el promedio de errores para el sensor en ese puerto es menor al 25%)
  • MONITOR_RETURN_TYPE_MEDIUM (indica que el promedio de errores para el sensor en ese puerto es mayor al 25% y menor al 50%)
  • MONITOR_RETURN_TYPE_HIGH (indica que el promedio de errores para el sensor en ese puerto es mayor al 50%)

Funcionamiento:

• Para cada sensor:
  • Si está en uso, se calcula el promedio de errores sobre la cantidad de operaciones totales. Se devuelve la salida correspondiente segun el porcentaje calculado

activateMonitor

Entradas:

• set_new_devices : lista de sensores conectados

Salidas:

• Ninguna

Funcionamiento

• Para cada sensor en set_new_devices:
  • Se pone el pone el atributo inuse en True y se inicializan todos los contadores en 0 para la instancia de MonitorElem correspondiente al sensor

desactivateMonitor

Entradas:

• set_old_devices : lista de sensores que estaban conectados antes del llamado

Salidas:

• Ninguna

Funcionamiento

• Para cada sensor en set_old_devices:
  • Se pone el atributo inuse en False para la instancia de MonitorElem correspondiente al sensor. Los contadores permanecen iguales.

reset

Entradas:

• Ninguna

Salidas:

• Ninguna

Funcionamiento:

• Para todos los sensores que están en uso:
  • Resetea todos los contadores

Testing

Para poder realizar pruebas sobre los monitores implementados, se utilizo la estructura del TutleBot "Por Siempre" y se le pedía el valor a todos los tipos de sensores, mientras los desconectábamos y conectábamos rápidamente. Comprobando que los monitores detecten correctamente los errores generados.

TurtleBots

A nivel de TurtleBots agregamos una nueva paleta para poder utilizar bloques de monitoreo

Actualmente, el bloque resetMonitorButia está en funcionamiento y llama a la función reset de MonitorButia.

También se puede observar el funcionamiento en el siguiente video:

[1]:Butia Monitor

Trabajo a futuro

Como trabajo a futuro nos plantemos los siguientes desafíos:

• Agregar un bloque que reciba como entrada un sensor y devuelva el porcentaje de errores que tuvo el sensor con respecto al total de operaciones, estos deberían ser: FALLO BAJO, FALLO MEDIO, FALLO ALTO (que ya se encuentran disponibles en la paleta con un color correspondiente según el grado de error)
• Con el punto anterior se busca permitir que el usuario pueda diseñar su programa de forma que se pueda detectar cómo actuar según el comportamiento de los sensores