Descripción del Problema

• ¿Qué es USM Zero?

USMZero es una iniciativa estudiantil multidisciplinaria nacida en la UTFSM, formada por alumnos y ex alumnos de Casa Central, Sede Viña del Mar, Campus Vitacura y Campus San Joaquin. Su principal objetivo es el desarrollo de un vehículo bio-híbrido (solar/tracción humana) para competir en la Carrera Solar de Atacama a desarrollarse en Octubre de este año.

• ¿Qué problemas presentan?

En este contexto y en base a competencias pasadas, se presentan fallas de difícil hallazgo en el vehículo, tal que un sistema centralizado que se comunique en tiempo real con las diferentes señales del mismo es necesario para una detección rápida de problemas, con tal de minorizar tiempos y permitir un desarrollo óptimo a lo largo de la competición. Además, habrán instancias de exposición en ciertas ciudades del norte de Chile, por lo que es necesaria una interfaz que presente de forma más amigable y sencilla al público general el funcionamiento del vehículo.

Figura 1: Logo USM Zero. Figura 2: Prototipo del Vehículo.

Análisis del Problema

• Solución Propuesta

Se propone abordar la solución utilizando el lenguaje "QML", el cual está basado en JavaScript para la creación de aplicaciones enfocadas a la interfaz gráfica de usuario. Note que en un inicio se pensó desarrollar nuestra solución mediante el framework "Qt", pero las opciones gráficas que este presentaba eran básicas y con diseños un tanto rústicos considerando la interacción con usuarios de todas las edades (necesidad de diseño vanguardista).

• Sistema Utilizado

Se desarrolla el presente proyecto en un sistema con distro Unix (trabajos realizados en Linux y Ubuntu) debido a los requerimientos técnicos propios del SBC (del inglés, Single Board Computer), siendo este el elemento físico en donde se utilizará esta aplicación. Un Computador de Placa Reducida es un pequeño ordenador completo en un sólo circuito enfocado a aplicaciones del entorno industrial o sistemas embebidos dentro de otros que funcionan como interfaces o controladores (para ver las especificaciones del SBC a utilizar, haga click aquí).

• Métodos de Interacción

                Para llevar a cabo el desarrollo de la interfaz, se debió aprender sobre tópicos que no fueron abordados en el curso, tales como:

                        • QML: este lenguaje se usa principalmente para aplicaciones móviles, donde la entrada táctil, las animaciones fluidas y una buena experiencia                         de usuario son cruciales. Los elementos de QML que vienen por defecto con Qt son un sofisticado conjunto de bloques, elementos gráficos                         como rectángulos o imágenes y comportamientos como animaciones, transiciones, entre otros (para leer la documentación de QML acorde a                         la versión Qt 5.11 utilizada en este proyecto, haga click aquí).

                        • Protocolo CAN: Controller Area Network (Red de Controladores de Área) es un protocolo de comunicaciones basado en una topología bus para                         la transmisión de mensajes en entornos distribuidos. Además, ofrece una solución a la gestión de la comunicación entre múltiples CPU's (para                         leer una documentación de apoyo con una breve Introducción a CAN, haga click aquí).

Figura 3: "Hola Mundo" en QML. Figura 4: Bus CAN.

Interfaz Gráfica

En base a todo lo descrito previamente, se inició el desarrollo de la interfaz gráfica, separando su construcción en dos partes: BackEnd (capa de acceso de datos, es decir, la interpretación de datos recibidos en protocolo CAN y posterior paso a lenguaje QML para producir cambios en los íconos presentes en pantalla) y FrontEnd (capa de presentación, es decir, los diferentes íconos, imágenes y animaciones visibles al usuario).
Dada esta separación, se hicieron una serie de requerimientos por parte de USM Zero, identificando como variables críticas los velocímetros, niveles de batería, presión, humedad, altura, voltaje y corriente, enfocándonos como grupo en generar las imágenes necesarias para cumplir con ello, siguiendo un diseño modelado por Ingenieros en Diseño de Productos pertenecientes al equipo multidisciplinario.

• Interfaz Solicitada

Figura 5: Interfaz Gráfica Base.

• Resultado Logrado

Figura 6: Interfaz Gráfica Lograda.

• Casos de Uso

• Velocímetros: se planea desarrollar un bus virtual CAN con tal de enviar datos vía software que sean leídos e interpretados por el BackEnd, tal que
se muestren una animación en el FrontEnd que sea reconocible como un velocímetro (muestra velocidad en [km/h]).

• Nivel de Batería: se planea desarrollar un bus virtual CAN con tal de enviar datos vía software que sean leídos e interpretados por el BackEnd, tal que
se muestren una animación en el FrontEnd que sea reconocible como un indicador de batería (muestra porcentaje del nivel de batería).

• Nivel de Presión: se planea desarrollar un bus virtual CAN con tal de enviar datos vía software que sean leídos e interpretados por el BackEnd, tal que
se muestre la información concreta en el FrontEnd (sección "Details") que sea reconocible como nivel de presión en [atm].

Diagramas UML

• Diagrama de Clases

Es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos. Para este caso, el diagrama de clases correspondiente es el siguiente:

Figura 7: Diagrama de Clases.

Este diagrama consta de las clases presentes en el proyecto desarrollado, tal que se explican las herencias y dependencias de cada una de ellas. De esta forma, las clases QCanBus, QCanBusFrame, QCanBusDevice y CanBus heredan de QObject (línea no segmentada), CanBus depende de QCanBus, QCanBusFrame y QCanBusDevice (línea segmentada); mientras que BackEnd hereda de CanBus (línea no segmentada).

• Diagrama de Secuecia

Es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML, es decir, muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Se adjunta en la siguiente imagen el diagrama de secuencia correspondiente a cada uno de los casos indicados, incluyendo todos los disponibles en la aplicación desarrollada.

Figura 8: Diagrama de Secuencia.

Este diagrama explica la secuencia lógica al iniciar la lectura de información, tal que QCanBusDevice avisa que llega un frame de datos en protocolo CAN, llamando al método readData() presente en BackEnd. Este usa el método de CanBus readFrame() para actualizar los datos disponibles y reportar al FrontEnd (interfaz gráfica), cambiando todas las animaciones e imágenes (de ser necesario) presentes en pantalla, tal que, para los casos descritos, modifica las agujas junto con el valor de velocidad, el porcentaje junto con el valor de batería y el valor de presión detectada.

Implementación

Considerando la plataforma y lenguaje utilizado, esta sección consta del detalle de algunas secciones de código que resultan más relevantes dada su importancia en el óptimo funcionamiento de la interfaz gráfica. De igual forma, se adjunta la totalidad del código desarrollado para quien esté interesado en continuar su estudio en el siguiente enlace (notar que se requiere cierto conocimiento básico sobre Protocolo CAN y QML).

• BackEnd

• Método readData(): método que se encarga de enviar las señales a la interfaz gráfica para lograr el cambio de datos en tiempo real.
• BackEnd(QObject *parent): constructor que se encarga de conectar las señales de recepción de frames (CAN) a la función readData().

• FrontEnd

• Speedometer.qml: clase que genera un cuadrado con atributos modificados para adquirir una forma circular con bordes variables. Esta configuración
permite que pueda correr un pequeño triángulo sobre él que marca la velocidad en tiempo real.