Diferencia entre revisiones de «Monitor»
(→TurtleBots) |
|||
(No se muestran 3 ediciones intermedias de otro usuario) | |||
Línea 39: | Línea 39: | ||
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. | 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''' == | == '''Desarrollo''' == | ||
Línea 168: | Línea 168: | ||
Funcionamiento | Funcionamiento | ||
* Para cada sensor en set_old_devices: | * Para cada sensor en set_old_devices: | ||
− | ** Se | + | ** Se pone el atributo inuse en False para la instancia de MonitorElem correspondiente al sensor. Los contadores permanecen iguales. |
===== '''reset''' ===== | ===== '''reset''' ===== | ||
Línea 181: | Línea 181: | ||
* Para todos los sensores que están en uso: | * Para todos los sensores que están en uso: | ||
** Resetea todos los contadores | ** 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''' === | === '''TurtleBots''' === | ||
Línea 192: | Línea 196: | ||
− | + | ||
[https://www.youtube.com/watch?v=ZSBlnh0YeEs]:Butia Monitor | [https://www.youtube.com/watch?v=ZSBlnh0YeEs]:Butia 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