Category: Invitados

Integración Continua en GitHub con AppVeyor (parte 2)

posted by under Invitados, Programación ,

En esta segunda parte, Jorge nos amplía y completa un poco más la anterior entrada sobre la Integración Continua con AppVeyor, para mostrarnos cómo generar y publicar una release automáticamente.

 

Generación del artefacto

Lo primero que será necesario es configurar un "artifact", que sera lo que se haga "push" hacia GitHub, para ello, en la pestaña "SETTINGS" en el menú "Build", haremos que los resultados que nos interesen se añadan a un .zip, creando un "After build script", en el cual meteremos los binarios que nos interese. Previamente a eso, vamos a indicarle en la parte superior, que queremos que la compilación utilice "debug" y "release".

El script:

7z a PostAppVeyor_%configuration%.zip %APPVEYOR_BUILD_FOLDER%\%APPVEYOR_PROJECT_NAME%\bin\%configuration%\*.exe

Añadirá todos los .exe que haya en la carpeta al fichero que indicamos, en caso de necesitar añadir otros ficheros o librerías, se podría indicar cambiando el patrón de búsqueda o poniendo rutas absolutas.

Con esto, AppVeyor va a generar el .zip, ahora sólo queda hacer que sea público como resultado de la compilación. Para eso, en la pestaña "SETTINGS", en el menú "Artifacts", lo creamos mediante el botón "Add artifact".

Seleccionando el .zip que se ha generado mediante el script, se le pone un nombre con el cual publicarlo en AppVeyor (hay que tener en cuenta que AppVeyor borra todos estos archivos a los 6 meses).

 

Publicación del artefacto

Después de todo lo anterior, sólo nos queda publicar los binarios en el apartado de "Release" de GitHub cuando nos interese. Para ello, lo primero de todo, necesitamos generar un token en GitHub para AppVeyor. Esto se hace desde el perfil , en el apartado "Settings/Developer Settings/Personal Access Tokens" pulsando en "Generate new token".

Tras darle un nombre, los permisos que necesitamos asignarles son simplemente "public_repo" y pulsar en "Generate token".

Esto nos genera un código alfanumérico, que debemos copiar, ya que lo necesitaremos en AppVeyor para configurarlo.

Una vez tenemos el token, nos vamos a AppVeyor y en la pestaña "SETTINGS" en el menú "Deployment", seleccionamos "Add deployment".

En el desplegable, hay que seleccionar "GitHub Releases". Cabe destacar que vamos a configurarlo para que sólo se publiquen como release los "Tags" del repositorio en la rama master. Para eso, vamos a configurar los parámetros de publicación que se ofrecen, teniendo especial cuidado en añadir una condición que sera "APPVEYOR_REPO_TAG" = true, para que sólo las etiquetas se suban a GitHub Release. Un ejemplo de como configurarlo seria el siguiente:

Una vez todo listo, solo nos queda crear un tag en nuestro proyecto, y pushear el tag a Github, esto iniciará el proceso, y cuando acabe, se podrá ver el resultado en el apartado "releases" del repositorio de GitHub.

 

Con esto queda cerrado el ciclo de despligue que junto a la entrada anterior sobre integración y testeo continuo, nos permite llevar nuestro código a cotas de calidad de desarrollo muy altas, preparando a su vez el proyecto sofware para poder gestionarlo cómodamente y de manera segura ante eventuales contribuyentes.

 

Integración Continua en GitHub con AppVeyor (parte 1)

posted by under Invitados, Programación ,

En esta ocasión tengo el gusto de presentar a Jorge, un excelente compañero de trabajo y un grandísimo profesional. En su día a día siempre anda buscando la mejor forma de hacer las cosas y en esta ocasión nos trae un detallado tutorial de Integración Continua, ámbito en el que recientemente se ha sumergido, y del que hoy nos presenta unas pildoritas de sabiduría y buen hacer.

GitHub, con todo el revuelo que ha provocado la compra por parte de Microsoft, es uno de los mayores repositorios de código que existen, y el mayor de código libre. Dispone de múltiples herramientas que ayudan al desarrollo de aplicaciones y testeo de aplicaciones que en muchos casos no son explotadas, lo cual es una lástima ya que son gratuitas (siempre que tu repositorio sea público) y aportan una gran ayuda.

En esta entrada vamos a hablar sobre una de esas herramientas llamada AppVeyor, ¿y que es AppVeyor? Es una herramienta de integración continua que permite realizar compilaciones, ejecutar teses, y publicar binarios, todo ello con unos pocos clicks gracias a su alta integración en GitHub (y encima gratuito si tu repositorio es público).

Llegados a este punto, se puede pensar, ¿qué me puede aportar a mi todo eso? La respuesta es sencilla, si tienes algún repositorio en el que colaboras con más gente, siempre sabréis que los cambios van a compilar, y en el caso de que tengáis test unitarios, que los ha pasado, y además de todo eso, publicar las "release" si así lo queréis. Vale, ahora pensarás, yo soy un desarrollador independiente, que no comparte repositorios, y tampoco me preocupo en sacar ninguna "release", ¿en qué puede ayudarme a mi? Fácil, puedes configurar diferentes "build" para diferentes entornos, y probar que tu código es perfectamente funcional en varias plataformas y versiones sin necesitar disponer de esas máquinas para compilar en ellas.

 

Compilación

¿Te he convencido? Pues vamos a ver como podemos configurar esta herramienta para nuestro repositorio. Lo primero es registrarnos en su web (algo muy fácil usando nuestra cuenta de GitHub).

Con sólo eso, ya estamos registrados, y llegamos a nuestro "dashboard", que por el momento estará vacío, pero vamos a solucionarlo pulsando en "NEW PROJECT" .

Para este ejemplo, he creado un repositorio en mi perfil llamado PostAppVeyor, el cual aparece automáticamente, y simplemente hay que pulsar en "ADD".

Ya tenemos nuestra integración lista, aunque de momento no haya hecho nada, veamos qué pasa si pulsamos en "NEW BUILD".

Pulsando esto, se lanzará una compilación que se puede seguir desde "LATEST BUILD".

Un detalle importante, es que al haber añadido AppVeyor al repositorio, se establecen automáticamente los WebHooks para notificar a GitHub los resultados, y si miramos el historial de commits del repositorio, se puede ver el resultado.

Esto también se aplica automáticamente para los "Pull Request", de modo que siempre se comprobarán las modificaciones que haya sobre el repositorio.

 

Test unitarios

Vale, el repositorio compila, ¿cómo añado los teses? Otra respuesta fácil, AppVeyor es capaz de detectarlos automáticamente. Añadamos un test al proyecto y veamos que pasa al "pushearlo" a GitHub. Automáticamente se inicia una compilación pero... ha fallado, ¿por qué?, si en Visual Studio pasaba el test sin problemas...

Vale, esto es debido a que los teses unitarios de Visual Studio, necesitan descargar paquetes NuGet. Vamos a solucionar esto yendo a la pestaña "SETTINGS" y al menu "Build". Hay que buscar "Before build script" para añadir un evento previo a la compilación, que haga un "nuget restore", tras esto, basta con pulsar en "Save" y ya estaría listo.

Ahora que tenemos todo lo necesario, vamos a volver a probar (Mediante el botón "RE-BUILD" del resultado que ha fallado) y ¡sopresa!, ya funciona correctamente.

Pero espera... a mi no me dice eso. Mis teses no se ejecutan, ¿qué pasa? Bueno, es posible que tu proyecto este hecho en un Visual Studio superior al que usa por defecto (2015), y el descubrimiento de teses unitarios no haya funcionado del todo bien, esto podemos solucionarlo rápidamente seleccionando la versión de Visual Studio que vamos a utilizar (en mi caso 2017). Volviendo a la pestaña "SETTINGS", pero esta vez en el menú "Environment", seleccionando Visual Studio 2017 y damos a "Save".

Veamos el resultado ahora pulsando en "RE-BUILD".... ¡¡¡Premio, nuestros teses ya se ejecutan!!!

Con todo lo que hemos hecho hasta ahora, tenemos un repositorio que comprueba automáticamente si el código compila correctamente, y ademas ejecuta los teses unitarios para comprobar que sigue cumpliendo con el funcionamiento esperado.

En la próxima entrada veremos cómo generar y publicar las "releases" a partir de nuestro código compilado y testeado.

 

Neurtura – O cómo sobrevivir en el mundo de la Monitorización Industrial

posted by under Invitados , ,

Ha costado que llegue el segundo invitado a Mascando Bits, pero nunca es tarde si la dicha es buena, y en este caso lo es. Hoy Xabier, compañero de fatigas en el trabajo, nos trae una retrospectiva con aplicación práctica de ingeniería de hardware y software al estilo open source que tanto ha marcado los inicios de Ingran Engineering, empresa de la que me siento orgulloso de pertenecer. Xabier ha sido y será siempre un MacGyver de la electrónica y la mecánica. Esperemos que esta sea la primera de otras muchas entradas.

Actualmente vivimos en un mundo complicado, luchando entre el software y hardware abierto y sistemas propietarios. En la confrontación entre la solución basada en Arduino-ESP8266 de 5€ y el Siemens S7 de 500€. En el dilema de dar servicio a un precio adecuado y cumplir las directivas y el marcaje CE. Puede que aquí encontréis algo intermedio, o no. Pero por lo menos, fue nuestra solución durante un tiempo.

 

Introducción

La verdad que empecé a escribir esta entrada hace bastante tiempo, puede que hace más de uno año. Pero por fin lo he completado. A falta de que todavía monte un blog, quisiera agradecer a Rubén que me deje espacio en su blog para publicar.

Este va a ser la primera de varias entradas, comentando la funcionalidad de un sistema que en su día desarrollamos en Ingran Engineering, que actualmente ha quedado en desuso, al migrar a sistemas de adquisición de datos basados en Modbus-TCP, y también porque el módulo central del sistema, el Industruino que usamos en sus primeras versiones, nos dio bastantes problemas para los niveles de calidad y servicio que buscábamos. No obstante el fabricante ha sacado una revisión del Industruino que soluciona los problemas del primero y que además añade nuevas capacidades al dispositivo.

El las siguientes fotos os muestro la versión básica del Neurtura (nombre comercial del dispositivo de monitorización), en la primera podéis ver el aspecto exterior con los conectores:

 

En esta podéis ver los componentes internos:

Podéis observar de izquierda a derecha: Un magnetotérmico, un analizador de energía eléctrica, el Industruino D21G IND I/O (la versión más reciente) con su módulo ethernet al lado, una fuente de alimentación de 24 Voltios y un router Teltonika RUT230.

El la parte exterior tenemos conectores Harting, para la alimentación, para la conexión de las pinzas amperimétricas, para el analizador de energía, y para las conexiones de los sensores, actuadores y Modbus-485.

Si alguien no tiene demasiadas ganas de leer, que vaya al final, al apartado "Compilando".

 

Contexto

¿Cómo narices se puede monitorizar un proceso industrial, en este caso concreto, una bomba de agua para regadío, de manera efectiva, eficaz y barata? Esa pregunta nos la hicimos en Ingran Engineering hace bastante tiempo, con la certeza de que tenía que haber una solución que tuviese las tres Bs (Bueno, Bonito y Barato). Esto era lo que necesitábamos:

  • Medida de parámetros eléctricos de una bomba: Potencia, Voltaje, Factor de Potencia...
  • Medidas de parámetros del acuífero: Conductividad eléctrica (salinidad), Nivel del agua bajo tierra...
  • Medida de parámetros del agua extraída: Caudal, Presión...
  • Registro de datos cada 10 segundos, y mostrarlos vía Web y en el móvil

Además, por si no fuera poco, teníamos las siguientes restricciones:

  • Necesidad de utilizar GSM/GPRS/3G para la comunicación.
  • Necesitaba tener marcaje CE y cumplirlo.
  • Tenía que ser compatible con lo que había ya montado: diversos tipos de caudalímtros/contadores, medidores de nivel de acuífero...

Aqualogy tenía una solución llamada IdroSmartWell que hacía todo eso, y más, a un precio que casi nos dio un infarto al escucharlo. La solución de software vino de la mano del proyecto EmonCMS de Open Energy Monitor y la de hardware tuvimos que apañárnosla.

 

Especificaciones técnicas

Las especificaciones técnicas de Neurtura que habéis visto en las fotos anteriores son las siguientes:

  • Analizador de energía eléctrica trifásica: Conexión a pinzas amperimétricas externas de 5A o 1A. Medida de V, I, P, PF, THD y más cosas...
  • 4 Entradas analógicas de 0-20mA o 0-10 Voltios: Resolución máxima de 18 bits.
  • 2 Salidas analógicas de 0-20mA o 0-10 Voltios: Resolución máxima de 12 bits.
  • 8 Entradas/Salidas digitales: Opción de usarlas como contadores de pulsos.
  • Conexión de Modbus-485 para conectar mas dispositivos.
  • Opción de postear (enviar) a EmonCMS directamente.
  • Guardado de datos en la SD local.
  • Guardado de parámetros de configuración en la EEPROM.
  • Guardado de datos de contadores y demás datos cambiantes en la FRAM propia.
  • RTC local.
  • Actualización del firmware remota: Utilizando el RUT230.

 

Compilando y cargando el firmware

El Industruino se programa utilizando el IDE de Arduino por USB, aunque también se puede programar por Ethernet utilizando TFTP, cosa que ya comentaré explicaré mas adelante en otra entrada.

En la Organización de Ingran Engineering de Github podéis encontrar el firmware y las librerías necesarias:

Para compilarlo y subirlo al Industruino, seguid estos pasos:

  1. Decargar el IDE portable de Arduino, versión 1.8.5
  2. Extraer arduino-1.8.5-windows.zip
  3. Dentro de la carpeta de arduino-1.8.5 crear una carpeta llamada "portable"
  4. Abrir el programa arduino.exe
  5. Instalar la placa del industruino -> clicando Tools -> Boards Manager y buscando "industruino" -> Insalar "Industruino SAMD Boards 1.01"
  6. Cerrar el entorno de programación de Arduino
  7. Descargar el proyecto Ikusi-Makusi de GitHub y extraerlo en donde se quiera
  8. Descargar el proyecto Ikusi-Makusi-libraries de GitHub y copiar las librerías en la carpeta arduino-1.8.5\libraries
  9. Abrir el programa arduino.exe de nuevo, en Herramienta->Placa seleccionar Industruino D21G y en Herramientas->Puerto el puerto de series correspondiente.
  10. Abrir el archivo Industruino_ethernet.ino del proyecto Ikusi-Makusi con el IDE de Arduino.
  11. Compilarlo y subirlo al Industruino.
  12. Conectad el Industruino a una red con DHCP y encenderlo.
  13. Con los botones navegar hasta la pantalla RED y mirad la IP asignada.
  14. Meter la IP en cualquier navegador web y empezar a experimentar.

Continuará...

 

¿Qué es un dron? – Conceptos básicos

posted by under Invitados

Me complace presentar como primer invitado en el blog a mi compañero Javier, con el que tuve el gusto de compartir experiencias de trabajo durante un par de años en la misma empresa, en el mismo departamento e incluso hasta en los mismos proyectos, trabajando en ocasiones codo con codo. Ahora Javier, desde hace un tiempo, ha seguido su trayectoria profesional en el campo de los drones, tan en auge en estos últimos años.

Hace poco mantuve una conversación sobre drones con Rubén y me pidió que escribiera una entrada en su blog (Mascando Bits) explicando mis experiencias como desarrollador de software para drones robots. Me pareció una buena idea ya que se trata de una tecnología que está creciendo muy rápidamente y la gente de a pie todavía no tiene claro como funcionan, que componentes necesitan y que son capaces de hacer.

Hasta hace unos meses mis conocimientos sobre drones se reducían que me sonaba un poco el Phantom de DJI y el Parrot. De robots se puede decir que me sonaba un poco la librería ROS. Las circunstancias hicieron que empezase a trabajar en un proyecto con drones robots cuya misión es realizar vuelos autónomos para detectar y clasificar objetos u eventos. Las circunstancias hicieron también que el proyecto fuera mega urgente y tuviéramos que trabajar mano a mano un experto en drones y aviones, un experto en robots y un (experto? jaja) en visión por ordenador que soy yo. Así pues, 7 meses después parece que todos sabemos cómo funcionan los drones. ¡Los nuestros al menos!

 

img_7389-1

 

Para centrar el tema voy a empezar por definir que es un dron robot. Un dron robot es un vehículo aéreo no tripulado (Unmanned Aerial Vehicle) que funciona de manera autónoma. El término dron vulgarmente se suele asociar a los vehículos aéreos de varios motores con hélices, pero el término preciso es UAV. Para que sea robot solo necesita realizar tareas de forma autónoma, es decir, sin el control directo de un ser humano.

Si nos centramos en el concepto de dron más extendido, típicamente quadrotors, un dron se compone de:

  • Chasis: la estructura que aloja el resto de componentes
  • Motores: tantos como patas tenga el chasis
  • Variadores: uno para cada motor (Electronic Speed Controler, ESC)
  • Hélices: una por cada motor
  • Controladora de vuelo: también llamada "autopiloto"
  • Batería
  • Receptor de radio (en realidad no es esencial, salvo que quedamos manejar el dron con un mando)

Un dron vuela básicamente porque la batería proporciona energía a los motores que hacen girar las hélices que a su vez propulsan aire hacia abajo elevando el dron. La fuerza de sustentación deberá ser mayor al peso del dron para conseguir elevarlo.  Este concepto juega un papel fundamental a la hora de elegir el tamaño de las hélices, baterías, peso del dron, etc.

La controladora de vuelo es la parte más importante de un UAV. Es la encargada de regular la potencia de cada motor y de estabilizar el dron en función de la información que recogen sus sensores. Si todos los motores reciben la misma potencia, el dron se mantendrá estable en el eje vertical. Si los motores traseros reciben más potencia, el dron se desplazará hacia delante, y viceversa.

Los componentes comunes de una controladora de vuelo son:

  • Acelerómetro: mide la aceleración de los movimientos del UAV
  • GPS: proporciona las coordenadas del UAV (no todos tienen este sensor)
  • Giróscopo: mide la velocidad angular del UAV
  • Barómetro: mide la altura a partir de la presión atmosférica
  • Magnetómetro: la brújula del UAV proporciona su orientación
  • Procesador: Es la inteligencia que realiza las lecturas de los sensores y las convierte en operaciones destinadas a mantener el UAV estable y llevarlo a la posición deseada.

pic-prod-pixhawk1

Las controladoras de vuelo pueden ser muy simples y solamente intentar mantener el dron estable mientras realiza maniobras, o bien complejas y utilizar sensores como el GPS para mantener la posición de dron. Las controladoras de vuelo son la “chicha” de los drones y las que marcan la diferencia de calidad entre unos modelos y otros. Cuanto más avanzada sea la controladora mejor estabilizará el dron, sean cuales sean las circunstancias. Una controladora ideal mantendrá al dron clavado en el punto deseado pase lo que pase, aunque el viento empuje el dron la controladora detectará el desplazamiento no deseado y lo corregirá para mantener esa posición. Obviamente la calidad de los sensores (GPS, brújula, acelerómetro) influyen en los cálculos (PIDs) que realiza la controladora para conseguir su objetivo de mantener o llevar al dron a la posición objetivo, con la velocidad deseada.

Y así es como funciona un dron de la manera más simple que se me ocurre explicarlo. Si analizamos el funcionamiento desde el punto de vista del piloto que utiliza una emisora de radio para controlarlo se podría interpretar de la siguiente manera. El piloto maneja los controles y como consecuencia está enviando comandos de velocidad al piloto automático, que los traduce en señales eléctricas a los variadores o ESC. Estos convierten la corriente continua de la batería en la intensidad que se desea enviar a los motores. Si “armamos” el dron y le damos gas a los motores, el piloto automático recibe comandos de velocidad en la dirección vertical ascendente, y suministrará potencia a los 4 motores por igual hasta que sus ecuaciones detecten que se ha alcanzado la velocidad deseada de ascenso.

Muchas controladoras de vuelo vienen con un software que permite "calibrar" el dron de forma precisa, configurar la sensibilidad de los controles de la emisora de radio, la configuración de los botones, la velocidad máxima del dron, vuelta a casa automática, etc. La calibración y configuración de la controladora de vuelo es una parte esencial para que el dron vuele correctamente y evitar accidentes y sorpresas. Otras controladoras de vuelo permiten además la configuración de misiones basadas en waypoints (puntos GPS). Estas misiones no envían comandos de velocidad al autopiloto, si no que envían puntos GPS de destino o comandos de posición y el autopiloto se encarga de alcanzarlos.

Como introducción al funcionamiento de los drones puede resultar un poco densa, pero los conceptos de comandos de velocidad y de posición que se envían a las controladoras son la clave para diseñar software para drones robots. Si en lugar de ser el mando del piloto el que envía esos comandos es un software programado por nosotros que toma decisiones en función de ciertos eventos o mensajes, estaremos convirtiendo el UAV en un robot. ¿Y de qué forma se pueden tomar estas decisiones? De eso hablaré en la próxima entrada...

Enlaces de interés: