Mis herramientas de desarrollo

Estaba yo pensando… ¿Por donde empiezo?

Bueno, trataré de empezar por el principio.

La idea es que voy a reflejar en una serie de posts la experiencia que he ido adquiriendo a lo largo de estos años que llevo trabajando.

He ocupado distintos puestos en distintas empresas, prácticamente todos alrededor de la ingeniería de telecontrol en el área de la energía eléctrica.

He trabajado unas veces en el entorno del transporte de energía, otras veces en el entorno de la distribución, pero casi siempre en la ingeniería de desarrollo software y hardware de los equipos de telecontrol.

Estos son los equipos que hacen posible que una instalación de una compañía eléctrica, desde una subestación de 400 Kv hasta un centro de transformación de distribución, funcionen desatendidos de manera segura y telecontrolados desde un despacho de la compañía correspondiente.

Además, soy aficionado a esto. Me gusta que las cosas funcionen solas. Así que, en mi tiempo libre, en mi casa, sigo dedicándole tiempo a esto. A ver, esto no quiere decir que en mi casa vaya a hacerme el porting de una librería 61850 a una Raspberry Pi, esto ya lo hago en la oficina con nuestros equipos. Lo que quiero decir es que en casa aprovecho estos conocimientos que he adquirido para desarrollar otras soluciones aplicables en el ámbito doméstico o en algún otro sector. Seguramente acabaré escribiendo sobre alguno de estos ejemplos.

En fin, que voy a tratar de darle un poco de visibilidad a mis aptitudes en este entorno por si a algún lector le parecen interesantes y pudiéramos llegar a colaborar de alguna manera…

Y como la mayor parte del contenido va a estar dedicado a la ingeniería software creo que lo mejor es dedicarle este primer post a las herramientas de desarrollo software que uso habitualmente.

Con el tiempo he aprendido que el uso de estas herramientas es fundamental para limitar o reducir el riesgo del desarrollo software. Además, en un segundo nivel, alrededor de estas herramientas debería haber una colección de procedimientos que nos aclaren como debemos usarlas. Y después, debería haber un compromiso de los integrantes del equipo de desarrollo para seguir estos procedimientos.

Son las siguientes:

  • GitLab
  • Youtrack
  • Artifactory
  • MediaWiki

GitLab.

Plataforma web para la gestión de todo el ciclo de vida del desarrollo software de un equipo.

Integra en una única herramienta funciones que antes solían hacerse con varias como Git (repositorio de código fuente), Gerrit (revisión de código), TeamCity o Jenkins (integración continua).

  • Git: Integra un servidor git para el control de código fuente: trazabilidad de cambios, ramas, tags…
  • Revisión de código: Permite la revisión de código por otro programador, incluir comentarios, rechazar la subida al repositorio, revisión iterativa, etc.
  • Integración continua Permite la configuración de “runners” en los que se compila el commit subido a las ramas de git. También se permite la ejecución de tests unitarios y test de integración, funcionales, etc. Se pueden configurar distintos runners en Linux y Windows.

GitLab es muy flexible y no impone una manera de hacer las cosas. Para homogeneizar el desarrollo de distintos proyectos se deben elaborar distintos procedimientos comunes para hacer, al menos:

  • Estructura de directorios del repositorio.
  • Gestión de ramas del repositorio.
  • Versionado de artefactos.
  • Proceso de construcción de artefactos.
  • Generación de versiones liberadas. Repositorio de artefactos.

Distintas opciones de uso, se puede instalar en una Raspberry Pi (mi opción domestica) o en un servidor “on premises” o en la nube. Libre de gastos, si uno se mantiene su propia instalación.

Youtrack

Es una herramienta de gestión de issues. Permite hacer la gestión de un proyecto de desarrollo software según distintas metodologías. Una de ellas scrum.

Entre otras cosas:

  • Facilita el desarrollo colaborativo entre los distintos miembros del equipo.
  • Gestión de issues (bugs, task, etc)
  • Permite la gestión de un backlog, agile boards asociadas a sprints.
  • Planificación, gestión de tiempos …
  • Comentarios en md, con enlaces, documentos adjuntos, etc.
  • Métricas.

Al igual que con GitLab es muy conveniente que en algún sitio esté descrito cómo se va a usar.

También tiene distintas opciones de instalación y es de libre distribución hasta 10 usuarios.

Artifactory

Básicamente, es un repositorio de artefactos. Es decir, el servidor donde se guardan, de manera ordenada, los paquetes de ficheros que constituyen una distribución de la aplicación.

Esta herramienta, a poco que la aplicación software tenga un mínimo de complejidad, cobra mucha importancia. Se trata de mantener las distintas versiones de los ejecutables bien gestionadas para garantizar la integridad y la trazabilidad del software.

Artifactory, incluso en su versión gratuita, ofrece un api REST para bajar y subir ficheros. Este interface se puede usar desde los scripts de integración continua de los distintos repositorios de GitLab.

De esta manera, la compilación de las versiones liberadas y su registro en el repositorio de artefactos se hace de manera automática y libre de los errores de la intervención humana…

Además, si se desarrolla un herramienta de fabricación de equipos, esta puede obtener los ejecutables de artifactory y desplegarlos en el equipo. De nuevo, sin intervención humana…

MediaWiki

Y esta sería opcional, pero muy conveniente. Es la herramienta que soporta la Wikipedia.

Se puede instalar en un servidor local sin coste.

Sirve para compartir información de manera informal, de una manera más ágil que un sistema de gestión documental.

Esto no sustituye a la gestión documental de la empresa, que debe soportar manuales de ingeniería, de instalación, de configuración, de uso, pero si sirve para compartir detalles de implementación, notas de aplicación o información informal que pueden intercambiar los distintos actores involucrados en el desarrollo de un producto.

Posted in Broadcasting | Leave a comment

Ponencias en UC3M curso 2023/2024

Este curso escolar, como en los diez últimos años, he vuelto a la Universidad Carlos III de Madrid para impartir tres sesiones.

Dos de ellas en la asignatura Redes Inteligentes del Master Universitario en Energías Renovables en Sistemas Eléctricos y la otra en la asignatura Internet de la Energía del Master en Internet of Things (IoT).

En los dos casos he tratado de trasladar a los alumnos mi experiencia práctica en la ingeniería de redes de transporte y distribución de energía eléctrica y, también, en el desarrollo de equipos de telecontol. Por esto, mis sesiones han girado alrededor de los equipos que se pueden encontrar en dos subsistemas de las redes:

  • La medida automática de consumos de energía eléctrica de los abonados
  • La gestión de la topología de la red de trasporte de energía eléctrica.

En cuanto a la medida automática, vimos cómo en España se ha impuesto la solución promovida inicialmente por Iberdrola basada en la tecnología PRIME desarrollada en España. También hablamos de las particularidades de los contadores inteligentes que tenemos instalados en casa y sobre el Concentrador de datos, que es el equipo instalado en los centros de transformación que recibe la información histórica registrada por los contadores.

En cuanto a la gestión de la topología de la red, hablamos de los distintos equipos que se pueden encontrar en las subestaciones de transporte y en los centros de transformación. Estuvimos viendo algún detalle del sistema de telecontrol de Red Eléctrica y de los equipos que instalan en sus subestaciones. Vimos qué protocolos se usan para la comunicación con otros equipos de la subestación como protecciones y multimedidores, y también con el Despacho de Telecontrol. También vimos algún detalle del HMI y de la funcionalidad asociada a estos equipos.

Me gusta participar en estas sesiones, aunque sea de manera puntual, creo que es bueno que los estudiantes tengan alguna sesión más práctica que teórica, que les enseñe, a los que se van a dedicar a esto, lo que se van a encontrar en la calle.

Además, la UC3M tiene un centro de masters en la Plaza de Toledo de Madrid con unas instalaciones fantásticas.

Posted in Broadcasting | Leave a comment

Sensor de profundidad. Composición del escenario

Estaba yo pensando… ¿Cómo se compone el escenario completo?

Nuestro problema, ahora, es componer la imagen de un escenario completo de 180º contenida en un único fichero .pcd

Como ya vimos en su momento, los puntos de una nube de puntos representada por un fichero en formato pcd no necesitan mantener un orden establecido ni están sujetos a muchas restricciones. Yo diría que sólo a una: todos están referenciados al mismo sistema de coordenadas. Bueno, pues a esto se reduce nuestro problema: debemos cambiar el sistema de coordenadas referencia de los puntos de un fichero por el del otro. Es decir, los puntos del fichero source, que tienen como referencia sus propias coordenadas, debemos referenciarlos a las coordenadas del fichero target. Una vez hecho esto ya podremos añadir los puntos al fichero target.

Continue reading

Posted in Broadcasting, Depth sensors, Sensors | Tagged , , , | Leave a comment

Sensor de profundidad. Pan&Tilt 2

Estaba yo pensando… ¿Cómo controlamos esto?

Para generar el tren de pulsos descrito en el post anterior se puede usar el PWM (Pulse Width Modulation) que suele incorporar como periférico prácticamente cualquier microcontrolador orientado al entorno industrial.

Conozco bien la familia de procesadores ColdFire de Freescale, ahora incorporada a NXP, por haberla usado muchas veces en mi trabajo. Tenía por casa una Tower del MCF54418 y esto me permitió poner en marcha el invento rápidamente. Es una lástima que estos procesadores, herederos de la arquitectura del 68000 de Motorola se hayan visto desplazados por los ARM.

Continue reading

Posted in Broadcasting, Depth sensors, Sensors | Tagged , , , , | Leave a comment

Sensor de profundidad. Pan&Tilt 1

Estaba yo pensando… ¿Cómo movemos esto?

El sensor de profundidad que incorpora el ASUS Xtion tiene un campo de visión de 58º en horizontal y 45º en vertical. Esto quiere decir que el sensor observa el espacio que ocuparía una pirámide de base rectangular cuyo vértice estuviera en la lente y que tuviera una amplitud de 58º en horizontal y de 45º en vertical, coincidiendo el lado largo de la base de la pirámide con la horizontal.

Continue reading

Posted in Broadcasting, Depth sensors, Sensors | Tagged , , , , | Leave a comment

Sensor de profundidad. Visualización.

Estaba yo pensando… ¿Y qué aspecto tiene una nube de puntos?

Vamos a tratar de averiguarlo.

Ya hemos visto cómo se representa una nube de puntos en un fichero. Ésta es una representación muy conveniente para procesar estos datos con la librería PCL. También hemos visto algún ejemplo de procesado, y veremos más. Esta representación facilita la implementación de estos algoritmos pero, aunque el fichero está codificado en ASCII, leerlo así en plan Matrix, pues no es fácil; y tratar de construir una imagen de la escena en tu cabeza, yo diría que es imposible.

Continue reading

Posted in Broadcasting, Depth sensors, Sensors | Tagged , , , , | Leave a comment

Sensor de profundidad. Procesamiento.

Estaba yo pensando… ¿Cuál será la mejor manera de representar esta información?

Una vez que hemos adquirido la información de la escena que ve el sensor será necesario procesarla para extraer la parte que nos interesa o nos resulta útil. Se podría, por ejemplo, obtener medidas de las paredes que envuelven la escena; se podría extraer de la imagen todo lo que no fueran paredes, suelo o techo; se podrían extraer objetos de la escena para tratarlos de manera separada y otras muchas cosas. En fin, ésta es la parte más imaginativa.

Yo me he propuesto, simplemente, obtener una imagen de 360º de la escena. Para esto habrá que contar con varias “instantáneas” tomadas desde distintas posiciones del sensor alrededor de un eje. Cómo integrar estas distintas imágenes en una única representación de la escena lo dejo para otro post más adelante. Ahora contaré algo sobre la herramienta que he usado para procesar la información.

Continue reading

Posted in Broadcasting, Depth sensors, Sensors | Tagged , , , | Leave a comment

Sensor de profundidad. Adquisición.

Estaba yo pensando… ¿Será un juguete o será realmente útil?

Cuando compré el ASUS Xtion Pro Live en Amazon por 143,71€ ya imaginaba que no sería lo mismo que los sensores de Prometheus, que escaneaban la cueva con una agilidad y precisión propias de una película de ciencia ficción, pero no sabía hasta qué punto el sensor iba a ser realmente útil o sería simplemente un juguete de dudosa utilidad asociado a una consola de videojuegos. La verdad era que los videojuegos con interface “natural” no habían tenido el éxito que se esperaba de ellos.

Éste era el primer paso: averiguar si el sensor es suficientemente estable y tiene suficiente precisión como para que los resultados tengan cierto valor. También me preocupaba si el software asociado al sensor tendría la suficiente calidad como para usar el sensor con tranquilidad y poder construir sobre él alguna aplicación básica que me permitiera hacer lo que estaba buscando.

Continue reading

Posted in Broadcasting, Depth sensors, Sensors | Tagged , , , , , , , | Leave a comment

Sensor de profundidad. Descubrimiento.

Estaba yo pensando… ¿será posible hacer algo parecido?

El otro día estuve volviendo a ver Prometheus, una película de la saga de Alien que describe el origen del protagonista. Quería recordar las escenas en las que unos pequeños dispositivos voladores trazan un mapa en tres dimensiones de las cuevas que dan acceso a la nave escondida en una construcción piramidal.

Cuando vi la película por primera vez, debió ser en 2012, pensé: “Esto sería fantástico, seguro que hay gente y dinero detrás pero, al fin y al cabo, esto es una peli de ciencia ficción”

Continue reading

Posted in Broadcasting, Depth sensors | Tagged , , , , , , , | Leave a comment

¿Por qué el nombre de rtBasics?

Estaba yo pensando, ¿por qué le he puesto este nombre? ¿Qué es eso de Back to Real Time Basics?

Bueno, quería reivindicar un poquito los tiempos en los que estas cosas del software embebido eran sencillas por necesidad.

Digo por necesidad porque la ROM era EPROM (con una E) y porque toda la RAM era estática. Claro, así contar con más 128KB de cada una era un lujo. Eso si tenías la suerte de que tu procesador pudiera direccionar más de 64KB. Yo tuve la suerte: Motorola 68008, que recuerdos!

Continue reading

Posted in Broadcasting | 1 Comment

Automatización en Redes Eléctricas Inteligentes

Os adjunto la documentación de la presentación que hice el día 24/04/2014 en la Universidad Carlos III de Madrid sobre Automatización en Redes Eléctricas Inteligentes para la asignatura Redes Inteligentes del Master Universitario en Energías Renovables en Sistemas Eléctricos del curso 2013/2014.

Desde 1995, que dejé de dar las clases en la Escuela de Ingenieros Industriales del ICAI, no había vuelto a subirme a un estrado. La cosa me gustó…

He tomado prestadas algunas imágenes de documentación de Arteche, Iberdrola, Gas Natural Fenosa, Endesa, ZIV, Ingeteam y RITZ. Mi agradecimiento por ello.

Continue reading

Posted in Broadcasting | Tagged , | Leave a comment