Mostrando entradas con la etiqueta Linux. Mostrar todas las entradas
Mostrando entradas con la etiqueta Linux. Mostrar todas las entradas

martes, 1 de mayo de 2018

¡Mira por dónde pisas! (con MATLAB/OCTAVE)

Qué encontrarás en esta entrada?
  • Análisis en OCTAVE de un ".gpx".

Algunos de vosotros quizás conozcáis mi oscura obsesión por hacer grafiquitas de todo en MATLAB (u OCTAVE). Tras la entrada del otro día, no he podido resistirme a intentar pasar los datos al ordenador y analizarlos por mi cuenta. En esta entrada os doy unas pinceladas de cómo lo he hecho y os muestro algunos resultados.


El primer paso, es hacer que un archivo ".gpx" sea inteligible para MATLAB/OCTAVE. Después de ver algún módulo para OCTAVE (que es lo que tengo ahora mismo instalado en el ordenador), no conseguí cargarlo por problemas de dependencias... así que "no me compliqué", y me hice mi propio script en Shell de Linux que leyese el ".gpx" como un archivo de texto, extrajese los datos de latitud, longitud y elevación, y crease con ellos un archivo ".m" que pudiese ejecutar en MATLAB/OCTAVE.

Izquierda: datos originales de un ".gpx". Derecha: archivo ".m".

Una vez con los datos en un ".m" estamos listos para jugar. En la primera imagen vemos una especie de cuadro de mandos. Arriba a la izquierda tenemos el mapa de la ruta sobre una maya de líneas que representan la superficie terrestre. A su derecha, tenemos un globo terráqueo en el que se representa el punto donde se localiza la ruta. Bajo estas, se encuentra el clásico perfil de altitud, y más abajo, el perfil de velocidades.

Para esta prueba he utilizado los datos de GPSies de mi última ruta.



Podemos utilizar, por tanto, estos datos para comparar los resultados. Vemos que la forma de la ruta es similar (si bien, en mi versión la estética es un poco más minimalista, puesto que no muestra un mapa debajo). Sin embargo, lo que sí incluye es la altitud, de manera que representa la ruta en 3D, y calcula las distancias teniendo en cuenta las subidas.


Arriba se muestra el perfil de la ruta. A la derecha, los dos cerros más elevados que el resto. La línea gris del suelo representa la superficie plana a la altura del mar. Se observa también que la curvatura de la tierra a estas escalas es demasiado pequeña como para suponer una corrección significante en la medida de las distancias.

Y hablando de curvaturas, se ha tenido en cuenta la corrección del elipsoide. La tierra es más achatada por los polos que por el ecuador, por lo que no es una esfera, sino un "elipsoide oblato". Las distancias de la ruta se calculan basándose en la posición que tienen sobre la superficie terrestre dada su latitud, longitud y elevación, por lo que es importante conocer con exactitud el radio terrestre en cada punto. Para ello me ha sido muy útil esta respuesta en Xataka Ciencia, sin embargo, a la hora de implementarlo punto a punto, suponía un esfuerzo de computación considerable, por lo que se ha tomado un valor escalar constante del radio de La Tierra para toda la ruta basada en la latitud inicial.


Con todo, esto el resultado es... un poco pobre.


Y es que aún dista un poco de los datos de GPSies, que sin lugar a dudas son más aproximados a los reales:

  • Distancia plana: 29,77 Km frente a 32,31 Km de GPSies.
  • Distancia con elevación: 29,98 Km (+220m) frente a 32,51 Km (+200m) de GPSies.
  • Tiempo: Respecto al tiempo, he de decir que los datos que exporta GPSies después de transformarlos desde OruxMaps (como hablábamos el otro día) son un poco raros, con lo cual falla cualquier medida derivada, como las velocidades. Esto sale algo mejor si utilizamos el archivo original de OruxMaps.
  • Elevación: Los datos de elevación máxima, mínima y su diferencia son correctos. Se discrepa en la subida acumulada, que sale mayor que en GPSies, pero que parece que en este caso su cálculo tampoco está muy claro, porque ofrecen dos formas de hacerlo, una de ellas experimental.


Por último, he analizado el intervalo de muestreo. Mientras que en el archivo original de OruxMaps el intervalo de muestreo es de 2 segundos salvo errores en la precisión del GPS (según mi configuración actual), en el caso de GPSies (que no es más que una adaptación del archivo original de OruxMaps) es una auténtica orgía de valores:


Hay que tener en cuenta esto ya que es habitual hacer estimaciones pensando que el intervalo de muestreo es contante. En este caso, esas aproximaciones se alejarán notablemente de la realidad.

Y hasta aquí mi primer contacto con el análisis de datos ".gpx" en MATLAB/OCTAVE. No sé vosotros, pero yo he echado la mañana con esta tontería :p...

domingo, 22 de octubre de 2017

Ubuntu 17.10: Primeros pasos (y problemas)

Qué encontrarás en esta entrada?
  • Algunas malas experiencias en mi primer día de uso de Ubuntu 17.10.

Erdferkel-drawing.jpg
Public Domain, Link

Acabo de cambiar a Ubuntu 17.10 (desde las 15.10). Cada vez que se cambia de sistema operativo, nos damos cuenta de las costumbres, o tal vez manías, que hemos ido cogiendo con todos los anteriores, y esto hace que el cambio siempre lleve asociado sorpresas: algunas positivas, y otras no tanto. En esta entrada no os voy a decir que Ubuntu 17.10 sea un mal sistema operativo (es muy pronto para hacer una valoración así: se lanzó el 19 de octubre, y yo lo he estado probando sólo desde ayer, día 21). Simplemente os voy a mostrar una lista de cosas que, ya sea por no haberme adaptado aún a ellas, o por que sean temas que deberían pulir más, me han incomodado en mi actualización a la versión del cerdo hormiguero.

Estética con la que he dejado el equipo tras la instalación de Ubuntu 17.10. Se basa en el tema "Gnome-OSX IV Space Grey" con iconos "Ubo".

Aquí va mi lista de "problemas" o "incomodidades" que me ha dado Ubuntu 17.10:

  • gtkdialog me ha dado muchos problemas. Lo utilizaba para el entorno gráfico de varios scripts propios, por lo que me he visto obligado a adaptar la programación para que funcionen con zenity (que sí funciona sin problemas y que cada día me gusta más por su simpleza) o a abandonarlos.
  • El gestor de software synaptic falla al arrancar. No viene instalado por defecto, y al instalarlo y ejecutarlo, me da un error de display. De momento he renunciado a él, pero para mi es infinitamente más útil que la aplicación Software que viene por defecto, como comentaré en algunos de los puntos de más abajo.
  • Terminator era un terminal que utilizaba en la versión 15.10 por su capacidad de poderse dividir en subconsolas, lo que permitía crear cuadros de mando. Puede instalarse por la aplicación Software (alternativa oficial al synaptic elegida por Ubuntu), pero luego no se encuentra  en la misma aplicación para borrarlo. Ni si quiera se encuentra pulsando la opción "Mostrar detalles", que debería llevarte directamente a la pantalla de gestión de la aplicación. He tenido que borrarlo con apt-get desde consola.

Cuadro de mando realizado con Terminator

  • Luminance HDR es una aplicación bastante extendida para edición HDR de fotografía. Fue una sorpresa comprobar que entre la mucha morralla que mete la aplicación Software, no se puede encontrar la aplicación Luminance HDR allí. La solución fue descargarla desde Ubuntu Updates.

Pantallazo de la conocida aplicación para edición de imágenes HDR

  • Se me ha bloqueado el equipo varias veces, siendo necesario el reinicio a capón. La primera vez fue intentando actualizar la biblioteca de música (de gran tamaño), pero me ha pasado dos o tres veces más en menos de 12 horas de uso con tareas normales. Nada que ver con mi experiencia con 15.10, que si bien se me bloqueó alguna vez, a lo mejor fue con frecuencia de una al cuatrimestre o menor.
  • La búsqueda en las aplicación Software es lenta y a veces parece que se atasca (nada que ver con cómo funcionaba synaptic). Además, ofrece muchos resultados de aplicaciones de baja calidad y poco testadas, que terminan dando muchos problemas, mientras que aplicaciones ya consolidadas, como he comentado antes, no aparecen en sus búsquedas.
  • Por alguna extraña razón, me ha hecho una mala asignación de algunos botones especiales del teclado. En la configuración viene correctamente, y al intentar cambiarlos allí, te confirma que están bien asignados, pero no funcionan al usarlos como deben (por ejemplo, me confunde el botón "Stop" con el "Eject"). En 15.10, que yo recuerde, nunca tuve que tocar nada para que funcionase bien.

Configuración del teclado. Sección sobre los botones de sonido y medios.

  • Hace un uso extraño de las contraseñas. En ocasiones en las que debería solicitármelas, me hace uso automático de ellas sin saber muy bien de dónde las saca. Me parece que podría ser un problema importante de seguridad.
  • No hay una aplicación oficial para gestionar los temas de GNOME 3. Esto hace que si quieres personalizar un poco tu experiencia desde el punto de vista estético, tengas que bajarte una aplicación para ello. Como he comentado, la aplicación Software mete mucha morralla en sus búsquedas, así que hasta que encuentres una que te valga, puedes dar con varias aplicaciones que no funcionan correctamente y que dan muchos problemas. A mi la que mejor me ha funcionado es la que llaman "Retoques de GNOME", que si no me equivoco, era la que venía por defecto en anteriores versiones de Ubuntu GNOME.

Retoques de GNOME desde la aplicación Software.

  • El funcionamiento del ratón en el explorador Nautilus es una locura. Se comporta como si fuera el uso del dedo en una tablet, perdiendo usabilidad en el ordenador. He intentado modificarlo pero no he sido capaz de ello. En su lugar Nemo me funciona mucho mejor. El que venga con dos gestores de ficheros en paralelo, con estética similar y que además se lanzan de manera indistinta dependiendo desde dónde lo hagan, ambos con el nombre genérico "Archivos", hace que sea un poco confuso distinguir cuándo estás usando cada uno de ellos. Al principio pensé que me daba fallos aleatorios hasta que caí en la cuenta de que eran aplicaciones distintas con un manejo distinto.

Nautilus a la izquierda. Nemo a la derecha.

  • También me ha dado error en el reconocimiento de las pantallas principal y secundaria. De las varias veces que he reiniciado, en una de ellas olvidó la configuración de pantallas reseteándola.
  • Por último, en alguna aplicación se han producido molestos parpadeos la pantalla, si bien es verdad que esto me ocurrió antes de cambiar a los drivers oficiales para la gráfica (que por defecto no venían por ser drivers propietarios).

Como veis, la lista no es corta, y llevo menos de un día de uso. Sé que en la lista figurarán cosas que serán problemas de que aún no me haya adaptado al nuevo sistema operativo, o cosas que podrían solucionarse trasteando en la configuración con un mayor conocimiento, pero el caso es que el cambio me ha traído este sabor agridulce. Espero que con el tiempo pueda decir que sólo quedó lo bueno y que la experiencia global fue positiva. De momento, como comentaba, es pronto para emitir juicios al respecto.

viernes, 4 de noviembre de 2016

¡Por fin encontré la cura!

Qué encontrarás en esta entrada?
  • Presentamos Cura: un software libre para el laminado en la impresión 3D.
  • Ventajas sobre otros softwares y primeras impresiones.

El Sr. Altair·Mikoto y yo estábamos preocupados por la resolución de nuestra BQ Hephestos Prusa i3, y es que según las especificaciones, debería tener una precisión mucho mayor que la que estábamos consiguiendo hasta el momento. Una hipótesis bastante plausible era que el problema estuviera relacionado con el software de laminado utilizado y es que, desde el inicio, elegimos Slic3r y nunca consideramos ninguna otra opción. Hoy, hemos abierto nuestros horizontes y hemos descubierto Cura.

Antes de entrar a alabar las bondades de Cura, me gustaría indicar que posiblemente los malos resultados obtenidos con Slic3r fueran debidos al desconocimiento por mi parte a la hora de configurarlo, y que Repsnapper nunca lo usé para laminar, sino sólo para previsualizar. Aún así, creo que hay puntos en los que Cura es claramente superior.

Lo primero que llama la atención de este software multiplataforma gratuito (sólo requiere registro mediante correo electrónico) es su ligereza y sencillez. Tanto a Slic3r como a Repsnapper les cuesta bastante mover ciertos archivos de geometrías complicadas, con demasiadas caras: los tiempos de respuesta de estas aplicaciones llegan a ser desproporcionados y consumen gran cantidad de recursos del ordenador. Cura trabaja en un tiempo muy razonable con archivos de este tipo sin problemas.

Opciones básicas de Cura

Tiene una serie de controles básicos que, sin ánimo de ofender a nadie, podrían considerarse "for dummies". Si la impresora viene entre las preconfiguradas (hay varias opciones populares disponibles), la primera vez que abres el programa la eliges con un click y ya te viene cargada en el combo correspondiente. Eliges el material, la calidad entre varios estándares, el relleno y en 4 clicks (click arriba, click abajo) tienes listo el archivo G-Code para guardarlo (se va generando en paralelo y, como he comentado, no tarda demasiado incluso con geometrías complicadas). En resumen: su uso es trivial (en el sentido más realista y menos pedante del término).

Ahora bien, si esto se nos queda corto, tenemos, como en otros programas, la posibilidad de meter las manos en la masa con las opciones avanzadas.

Opciones avanzadas de Cura

Es aquí donde Slic3r tiene algún punto a su favor, y es que cuenta con más opciones de configuración avanzada. Sin embargo, sorprende lo bien que funcionan las opciones preconfiguradas en Cura.

La sección (de las ocho que hay) referente a las velocidades de una de las tres pestañas de configuración (configuración de la impresión) de Slic3r.

Sin embargo, Cura no es sólo fácil de usar, a la vez que aceptablemente completo, sino que también es "bonito".


Al detectar la impresora entre las preconfiguradas, la dibuja, dando una idea precisa del tamaño que ocupará el modelo en relación con la máquina y con los márgenes de impresión.

Por último, que es lo que verdaderamente importa, Cura permite aprovechar al máximo las capacidades de la impresora en cuanto a resolución. En este punto aplica el comentario que he hecho al principio: quizás no haya sabido configurar bien Slic3r, pero no han sido pocas las pruebas que he realizado para intentar mejorar los resultados con muy poco éxito en lo que respecta a los pequeños detalles.

Arriba: impresión con G-Code generado por Cura. Abajo-izquierda: modelo 3D. Abajo derecha: impresión basada en Slic3r.

Como ejemplo, sobre estas líneas hay tres imágenes de la misma pieza. En la parte de abajo a la izquierda está el modelo utilizado en los otros dos casos. El caso de abajo a la derecha es mi mejor resultado con Slic3r, mientras que el de arriba es el resultado con los parámetros preconfigurados de buena calidad en Cura. Como se puede apreciar, queda lejos de ser perfecto en ningún caso, pero estamos hablando de detalles relativamente pequeños y se aprecia una clara mejora en el resultado obtenido mediante Cura con respecto al obtenido con Slic3r. Comentar también que este aumento de la calidad no ha implicado un aumento en el tiempo de impresión. Ambas impresiones se realizaron aproximadamente en un tiempo de 10 minutos.

Para finalizar, tras quedar tan sorprendido por Cura me ha entrado curiosidad por ver qué impresoras construye la gente de Ultimaker (la empresa que ha realizado el programa). Os dejo el siguiente vídeo, que me ha dejado tan boquiabierto como impotente al comprobar que la calidad se paga (entre 3.000 y 4.000 €).

domingo, 28 de agosto de 2016

A donde me lleve la fotografía

Qué encontrarás en esta entrada?
  • Tutorial para añadir una etiqueta GPS con la localización de forma automática a tus fotos.

Llevo años pensando en comprarme un GPS para la cámara. Un trasto grande, incómodo y caro con el objetivo de que mis fotos de paisaje queden localizadas de forma automática. Por otro lado, llevo años grabando en GPS mis salidas fotográficas, para ver por donde he ido caminando. Que tonto me siento ahora al descubrir que no era en absoluto necesario comprar más cacharros.

Captura de Panoramio, al subir una imagen geolocalizada por el método que contamos en este post

Os voy a enseñar desde Linux, por línea de comandos, cómo podéis añadir una etiqueta de localización a todas vuestras fotos de golpe. Para ello, sólo es necesario:

i) Una cámara puesta en hora.
ii) Un GPX con el recorrido que hemos hecho.

El primer punto es sencillo: comprobar que la cámara está puesta en hora antes de salir a hacer las fotos, porque esta marca de tiempo quedará insertada en cada imagen y será el dato por el que se cruce la información.

El segundo punto trata de grabar vuestro recorrido en formato "GPX". Esto se puede hacer de muchas formas, por ejemplo, con una de las múltiples aplicaciones para el móvil, como OruxMaps (que siempre recomiendo por su gran completitud), u otras de uso más sencillo. El caso es que una vez realizada la ruta la exportamos a formato "GPX" y con él vamos a trabajar.

Será necesario tener instalado exiftool. Con esta utilísima herramienta, sólo tendremos que escribir:

exiftool -geotag=DATA.gpx *.jpg

Donde "DATA.gpx" es el archivo con la ruta y supongo que está en la misma carpeta que las fotos, en formato "*.jpg". De esta manera, de golpe, se cruzan los datos de las horas de las tomas de las fotos con el recorrido GPX y se añade una marca de lugar en las etiquetas EXIF de las imágenes. Todas nuestras fotos localizadas de golpe. Ya las podemos subir, por ejemplo, a Panoramio sin preocuparnos de localizarlas a mano (¡la de tiempo que he perdido con eso!).

Datos EXIF GPS antes de la operación

Datos EXIF GPS después de ejecutar el comando

¡Espero que os haya sido útil!

jueves, 17 de diciembre de 2015

Un día en la vida de @AstarothsBot

Qué encontrarás en esta entrada?

Como comentábamos el otro día, El Diablo Fumado se ha lanzado a las redes sociales, y ahora publica "por su cuenta" en Twitter bajo el alias @AstarothsBot. En la última entrada vimos que esto era posible gracias a Node-RED. Hoy veremos cómo es un día en la vida de este peculiar "community manager" recorriendo una sesión de sus twits, en concreto, la del 16 de diciembre de 2015.


Recordemos que @AstarothsBot es un bot que recoge variables, como el pronóstico del tiempo, la temperatura de la CPU, el uso de los procesadores, de la memoria, de la red, etc. y devuelve mensajes teñidos de su... peculiar carácter. El esquema actual de su programación en Node-RED sería el siguiente:


sábado, 5 de diciembre de 2015

El Diablo Fumado y el Nodo

Qué encontrarás en esta entrada?
  • Breve presentación de Node-RED.
  • Presentación en sociedad de @AstarothsBot.

El otro día, mi enlace con las tecnologías experimentales, Altair·Mikoto, me habló de Node-RED. Se trata de una forma de programar gráfica bastante interesante. La aplicación ofrece varios módulos que se conectan de forma gráfica mediante "cables", que enganchan las salidas y entradas de cada uno de los ellos.


Dentro de cada módulo hay funciones complejas pre-programadas, o incluso la capacidad de escribir tus propias funciones en JavaScript. También hay módulos que desde Linux ejecutan comandos en shell.


Entre sus varias formas de salida, me llamó desde el principio la capacidad de que publique directamente en Twitter. Es esta la forma en la que nació @AstarothsBot, el "community manager" de Astaroth's Bot System (ABSys).


Como algunos ya sabréis, ABSys es un sistema que he creado, cada vez más complejo, por el que me comunico con mi ordenador y al final éste realiza tareas para mi sin la necesidad de estar físicamente presente. Este simpático bot toma distintas variables (monitorización del sistema, clima, etc.) y, tras analizarlas, publica distintos mensajes divertidos en su cuenta de Twitter.

Para empezar a usar Node-RED en Ubuntu, deberéis seguir los siguientes pasos:

sudo apt-get install nodered
sudo apt-get install npm
sudo ln -s /usr/bin/nodejs /usr/bin/node

Podréis acceder entonces a la aplicación tecleando primero en una consola:

node-red

Y luego accediendo desde un navegador de Internet a la dirección:

http://127.0.0.1:1880/

Lo suyo sería ejecutar "node-red &" como aplicación al inicio, y así siempre que se encendiese el ordenador, se activarían automáticamente las acciones que hayamos configurado.

Os invito a seguir los delirantes comentarios sarcásticos del Diablo Fumado en su canal de Twitter.

domingo, 1 de noviembre de 2015

CenterIM y Ubuntu 15.10

Qué encontrarás en esta entrada?
  • Instalar CenterIM en Ubuntu 15.10.

ADVERTENCIA:

No me responsabilizo de los posibles riesgos de seguridad que impliquen seguir los pasos detallados en esta entrada.


Acabo de abordar recientemente la siempre estimulante tarea de un formateo. Aunque es recomendable realizarlo de vez en cuando para limpiar basura y actualizar los sistemas operativos, con cada actualización siempre hay algunos problemillas que hay que solventar. Y es que somos animales de costumbres que, una vez acostumbrados a utilizar algo, nos cuesta mucho utilizar otra cosa a no ser que tenga claras y rápidas ventajas con respecto a lo anterior.

Es el caso de CenterIM en Ubuntu 15.10. Por un momento pensé en que iba a tener que renunciar a este ligero cliente de mensajería instantánea que, por otra parte, hace la función de cimientos para el sistema ABSys (el sistema por el cual puedo dar órdenes a mi ordenador desde el móvil, pudiendo acceder a tiempo real a mi equipo y ejecutar distintas tareas, como he documentado alguna vez en este blog).

Según podíamos leer en RSPPI en su día, de donde tomé las bases para ABSys, para instalar CenterIM bastaba con ejecutar en un terminal el siguiente comando:

apt-get install centerim

Sin embargo, esto sólo funciona limpiamente para versiones antiguas de Ubuntu. En la versión 15.10, hay que ir algunos pasos más allá. Al intentar instalar CenterIM de la página oficial, nos encontramos varias alternativas: la versión 5, que hay que configurarla ("./configure"), y la versión 4, que está para configurar también, o en forma de paquete ".deb".

Personalmente, y debido a mi falta de conocimiento, estoy un poco "peleado" con las versiones en "tar.gz" para configurar, porque antes o después llego a un problema irresoluble de dependencias. Éste es también mi caso para las versiones 4 y 5 de CenterIM. Pruebo por tanto los paquetes, pero éstos también tienen problemas de dependencias: fundamentalmente, el paquete "libgnutls26" parece haber sido descatalogado para las nuevas versiones de Ubuntu.

Tras luchar con Synaptic y sus repositorios, encuentro una interesante página en la que se pueden descargar paquetes antiguos de Ubuntu: Ubuntu Updates. Allí no es difícil descargar la librería libgnutls26.

Una vez hecho esto, el problema lo da libgcrypt11, pero resulta que éste también está en Ubuntu Updates.

Después de estos pasos, estamos listos para instalar los paquetes ".deb" de la página de CenterIM. En antiguos repositorios de Ubuntu, accesibles desde la web, también tenemos estos paquetes. Primero hay que instalar la versión "commons" ("centerim-common_4.22.10-2ubuntu1_all.deb"), y después, por ejemplo, la versión "centerim_4.22.10-2ubuntu1_amd64.deb".

Con esto tenemos instalado de nuevo CenterIM en un Ubuntu 15.10.

Resumiendo los pasos:
  1. Instalar libgcrypt11.
  2. Instalar libgnutls26.
  3. Instalar centerim-common_4.22.10-2ubuntu1_all.deb.
  4. Instalar centerim_4.22.10-2ubuntu1_amd64.deb.

jueves, 1 de octubre de 2015

¿Llevan todos los caminos a Roma?

Qué encontrarás en esta entrada?
  • Script Linux para unir GPX.
  • Ver en un mapa la superposición de de todos los caminos.

Como sabéis, en Astaroth's World somos muy fans de los GPS y de Linux. Una cosa que siempre he tenido curiosidad por ver es la superposición de todos los caminos que he seguido en mi vida. No recuerdo exactamente cómo era aquello que leí una vez, pero venía a decir algo así como que nuestros pies eran como bolígrafos que iban escribiendo nuestra historia según nos íbamos moviendo.

Los puntos que forman una línea más gruesa representan mis pasos por Los Cerros de Alcalá

Evidentemente, no registro mi vida continuamente con el GPS (si bien es verdad Google sí que lo hace por nosotros...). Al menos no por ahora. Lo que sí registro son muchas de mis excursiones, en archivos con formato ".gpx".

Un archivo ".gpx", como podemos ver en Wikipedia, es un archivo XML que contiene las coordenadas de una ruta, los puntos de interés ("waypoints"), la altitud y otros datos. Mi objetivo es partir de varios archivos ".gpx", extraer sólo la latitud y longitud de los puntos que construyen la ruta, y crear un nuevo archivo con todos ellos.

Para ello, he realizado un script en shell de Linux. Seguro que hay millones por Internet más eficientes que éste, pero éste es el mio, y es lo que se me ha ocurrido a mi en el momento.

#!/bin/bash
#
# Este script recopila datos sobre la longitud y latitud de varios archivos ".gpx" ó
#".GPX" y los une un un sólo archivo.
#
# Es necesario para su correcto funcionamiento que los archivos de entrada estén en la
#carpeta "GPX", un nivel por debajo del script.
#
# Creado por Astaroth (O.R.G.).
# 30/09/2015

clear

#************************************************************************************
# RENOMBRAR: se intenta evitar problemas con los espacios en los nombres de archivos.
#************************************************************************************
echo "Renombrando archivos para evitar problemas al procesarlos..."
mkdir .renombrado

# Se hace un primer indexado de los archivos de entrada:
ls GPX/*.gpx > .lista.txt
ls GPX/*.GPX >> .lista.txt

# Primero se renombran las extensiones para homogenizar:
cat .lista.txt | sed 's/.GPX/.gpx/g' > .Lista2.txt

maxl=`wc .lista.txt | awk '{print $1}'`

# Después se renombran los archivos, copiándolos a una carpeta con nombres no problemáticos:
for i in $(seq $maxl) ; do
    nomorg=`cat .lista.txt | sed -n ''$i'p' | sed 's/\ /\\ /g'`
    renom=`cat .Lista2.txt | sed -n ''$i'p' | sed 's/GPX\///g' | sed 's/\ /_/g'`
    cp "$nomorg" .renombrado/$renom
done

# Por último, se indexan los archivos con el nombre que no dará problemas:
echo "Indexando archivos"
lista=`ls .renombrado/*.gpx`

#************************************************************************************
# UNIÓN: es el script propiamente dicho, se extraen los datos de cada archivo y se
#unen en uno solo.
#************************************************************************************

echo "Escribiendo GPX de la unión..."

# CABECERA: se escribe parte fija inicial.
#------------------------------------------------------------------------------------
echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" > Union.gpx
echo "<gpx>" >> Union.gpx
echo "<trk>" >> Union.gpx
echo "<trkseg>" >> Union.gpx

echo "Extrayendo coordenadas..."

# CUERPO: la parte en la que van los datos.
#------------------------------------------------------------------------------------

# Extracción de las latitudes y longitudes:
for archivo in $lista; do
    cat $archivo | grep -o "lat=\"[0-9]*.[0-9]*\" lon=\"[,-][0-9]*.[0-9]*\"" >> .latlong.txt
done

# Escribiendo los datos en el archivo de la unión:
cat .latlong.txt | sed 's/lat/<trkpt lat/g' | tr '\n' '*' | sed 's/*/>\n<\/trkpt>\n/g' >> Union.gpx

# COLA: Parte fija al final del documento (cierre de etiquetas XML)
#------------------------------------------------------------------------------------
echo "Cerrando archivo GPX de la unión..."
echo "</trkseg>" >> Union.gpx
echo "</trk>" >> Union.gpx
echo "</gpx>" >> Union.gpx

#************************************************************************************
# BORRADO DE ARCHIVOS TEMPORALES: se limpian los archivos que ya no son necesarios.
#************************************************************************************
echo "Borrando archivos temporales..."
rm .lista.txt
rm .Lista2.txt
rm -R .renombrado
rm .latlong.txt

echo ""
echo "¡¡EJECUCIÓN FINALIZADA!!"

Uno de los puntos delicados era que tomara correctamente el nombre de los archivos (muy heterogéneo entre mis documentos), por lo que parte importante del script es indexar los elementos involucrados y renombrarlos para que no den problemas (prestando especial cuidado a los espacios, que podrían ocasionar errores).

Una vez hecho esto, se escribe la cabecera (una parte genérica fija). Luego se extraen las coordenadas (longitud y latitud, obviando otros datos, como pudieran ser los de elevación) y se insertan en el cuerpo del archivo final. Por último, se cierra el archivo con una parte fija final (el cierre de las etiquetas del XML que se abrieron en la cabecera).

Pantalla de la salida del script

Con esto tenemos un único archivo ".gpx" con la información de todos, pudiéndolo visualizar con casi cualquier herramienta cartográfica como, por ejemplo, GpsPrune.

Unión de varias rutas que he registrado con el GPS. Se ve mi recorrido por La Alcarria de Alcalá (Los Santos de la Humosa, Santorcaz, Anchuelo, Villalbilla, Valverde de Alcalá, Torres de la Alameda, Loeches...).

Visión global de la unión de todas las rutas que he registrado con el GPS. Se incluyen algunas rutas no hechas a pie.

Algún día espero cubrir gran parte del mapa con estas líneas, y dejar una historia llena de recorridos, pueblos, monumentos y curiosidades que poder contar.

ACTUALIZACIÓN 


Una sencilla modificación en el script nos permite, de una manera más limpia, recuperar además los puntos de interés, las altitudes, las fotos, etc. En lugar de quedarnos sólo con la longitud y la latitud, el scrpt ahora selecciona todo lo que esté entre las etiquetas "<gpx ...>" y "</gpx>", y lo incluye en bloque en el archivo final. El resultado, el que podéis ver bajo estas líneas.

Caminos que he seguido por Los Cerros. Con esta actualización se incluyen puntos de interés que fui marcando, así como fotos y elevaciones, y desaparecen las líneas que unían una ruta con la siguiente, emborronando el resultado final.

El script definitivo sería el siguiente:

#!/bin/bash
#
# Este script recopila datos sobre la longitud y latitud de varios archivos ".gpx" ó
#".GPX" y los une un un sólo archivo.
#
# Es necesario para su correcto funcionamiento que los archivos de entrada estén en la
#carpeta "GPX", un nivel por debajo del script.
#
# Creado por Astaroth (O.R.G.).
# 01/10/2015

clear

#************************************************************************************
# RENOMBRAR: se intenta evitar problemas con los espacios en los nombres de archivos.
#************************************************************************************
echo "Renombrando archivos para evitar problemas al procesarlos..."
mkdir .renombrado

# Se hace un primer indexado de los archivos de entrada:
ls GPX/*.gpx > .lista.txt
ls GPX/*.GPX >> .lista.txt

# Primero se renombran las extensiones para homogenizar:
cat .lista.txt | sed 's/.GPX/.gpx/g' > .Lista2.txt

maxl=`wc .lista.txt | awk '{print $1}'`

# Después se renombran los archivos, copiándolos a una carpeta con nombres no problemáticos:
for i in $(seq $maxl) ; do
    nomorg=`cat .lista.txt | sed -n ''$i'p' | sed 's/\ /\\ /g'`
    renom=`cat .Lista2.txt | sed -n ''$i'p' | sed 's/GPX\///g' | sed 's/\ /_/g'`
    cp "$nomorg" .renombrado/$renom
done

# Por último, se indexan los archivos con el nombre que no dará problemas:
echo "Indexando archivos"
lista=`ls .renombrado/*.gpx`

#************************************************************************************
# UNIÓN: es el script propiamente dicho, se extraen los datos de cada archivo y se
#unen en uno solo.
#************************************************************************************

echo "Escribiendo GPX de la unión..."

# CABECERA: se escribe parte fija inicial.
#------------------------------------------------------------------------------------
echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" > Union.gpx
echo "<gpx>" >> Union.gpx
echo "<trk>" >> Union.gpx
echo "<trkseg>" >> Union.gpx


# CUERPO: la parte en la que van los datos.
#------------------------------------------------------------------------------------

# Extracción de las latitudes y longitudes:
echo "Escribiendo datos..."
for archivo in $lista; do
    inic=`cat $archivo | grep -n "<gpx" | awk -F\: '{print $1}' | sed -n '1p'`
    fini=`cat $archivo | grep -n "</gpx" | awk -F\: '{print $1}'| sed -n '$p'`
    inic=`echo "$inic + 1" | bc`
    fini=`echo "$fini - 1" | bc`
    cat $archivo | sed -n ''$inic','$fini'p' >> Union.gpx

done

# COLA: Parte fija al final del documento (cierre de etiquetas XML)
#------------------------------------------------------------------------------------
echo "Cerrando archivo GPX de la unión..."
echo "</trkseg>" >> Union.gpx
echo "</trk>" >> Union.gpx
echo "</gpx>" >> Union.gpx

#************************************************************************************
# BORRADO DE ARCHIVOS TEMPORALES: se limpian los archivos que ya no son necesarios.
#************************************************************************************
echo "Borrando archivos temporales..."
rm .lista.txt
rm .Lista2.txt
rm -R .renombrado

echo ""
echo "¡¡EJECUCIÓN FINALIZADA!!"

Espero que os sea de utilidad.

viernes, 14 de agosto de 2015

Hasta la vista, Dashboard!

Qué encontrarás en esta entrada?
  • ¿Cómo subdividir un terminal Shell Linux?
  • ¿Cómo hacerse un dashboard con la monitorización del sistema?

Mi reciente cumpleaños ha venido acompañado de un monitor de 27 pulgadas que ridiculiza enormemente mi antigua pantalla de formato cuadrado. Sin embargo, no he querido relegarla a un rincón del olvido, y la he conectado igualmente, aunque no sé muy bien qué uso darle.


Una de las posibles aplicaciones que pensé fue la de monitorización del sistema. Me pregunté: "¿y si me hago una especie de cuadro de mando con los parámetros del equipo actualizados cada cierto intervalo?" Tras considerar varias alternativas, llegué a la conclusión de que lo más fácil sería utilizar una consola que pudiese subdividirse a mi antojo, mostrando en cada una de las partes la información que yo quisiera.

Existen varias opciones para cumplir con lo dicho anteriormente, pero la primera con la que me topé fue con... TERMINATOR. Terminator es una consola para gnome que nos permite ejecutar nuestros comandos como cualquier otra, pero que tiene un sistema de perfiles y diseños que permite la personalización del aspecto. De una manera intuitiva y gráfica (mediante el ratón) se puede subdividir la ventana en horizontal y en vertical como queramos, guardando la configuración en un diseño o "layout" cuando lo hayamos dejado a nuestro gusto. Después, en la configuración de diseños (layouts), tenemos la opción de meter un "custom command", es decir, una línea de comandos personalizada con el conjunto de órdenes que queramos que se ejecuten en cada ventana subdividida.


Una vez hecho esto, la información se guarda en un archivo de configuración llamado:

$HOME/.config/terminator/config

También podríamos optar por modificar directamente este archivo si conocemos su sintaxis.

Con esto, hacemos que al abrir Terminator con uno de sus diseños precargados nos aparezca una pantalla subdividida en la cual se ejecuten los comandos que hayamos dispuesto en cada subdivisión.

Un comando de ejemplo podría ser "top", y mostraría a tiempo real los procesos ejecutándose. Si nos vamos a una estructura un poco más compleja, yo había pensado en algo como esto:

k=1; while [ $k = 1 ] ; do clear; echo "TEMPERATURAS (actualizado a las $(date +%H:%M)):"; echo "---------------------------------------" ; echo "" ; sensors | grep ".*Temperature:" ; sleep 30 ; done

La línea realiza un bucle infinito en el que, cada 30 segundos, mira las temperaturas de la CPU y la placa base utilizando el programa "sensors" que ha de estar instalado previamente. Combinando varias líneas de este estilo, obtenemos un cuadro de mandos (o dashboard) con la estructura e información que deseemos. Ideal para mantener siempre en una pantalla auxiliar de pequeño tamaño.


Una vez guardad toda esta información en la configuración del diseño ("layout"), podemos ejecutar Terminator simplemente con un comando del tipo:

terminator -f -l Dash

El apéndice "-f" es de fullscreen (pantalla completa) y "-l Nombre_de_tu_diseño" es para cargar el "layout" que hayas configurado con anterioridad (en mi caso se llama "Dash").

domingo, 12 de julio de 2015

Quc Qucs - Tras

Qué encontrarás en esta entrada?
  • Revisión de Qucs (simulación de circuitos).

En la carrera tuve mis traumáticas prácticas con PSpice, un programa que - al menos de la forma en que nos lo dieron - no se presentaba como demasiado intuitivo, aunque a cambio prometía ser tremendamente completo.

Ahora no trabajo a menudo con proyectos de electrónica, pero tenía interés en buscar algo "sencillito", que funcionase en Linux, y que resolviese pequeños problemas de simulación electrónica sin invertir demasiado tiempo en su aprendizaje. Bajo estos requisitos encontré varias alternativas, algunas más complejas que otras. La aplicación que más me gustó por su facilidad de manejo en relación con sus prestaciones fue Qucs.

Uno de los ejemplos que trae cargado el programa

Qucs permite dibujar circuitos de manera sencilla pinchando en los componentes que queramos añadir. Tiene gran variedad de componentes y todos son ampliamente configurables. Además, permite añadir textos y gráficas a los esquemas de manera que podamos tenerlo todo integrado en una misma pantalla.

Captura de pantalla: se ven los componentes básicos a la izquierda, y cómo integrar circuitos y gráficas.

Parámetros de un diodo

Realizar simulaciones es relativamente simple: se elige la simulación, se configuran los parámetros con lo que se va a simular, y se le da al botón del engranaje. Esto genera una variables de la simulación, que se pueden representar en los variados diagramas que ofrece la aplicación.



En resumen, me parece un programa no demasiado complicado de utilizar y que puede dar unos resultados muy vistosos y útiles para el usuario poco familiarizado con este tipo de software.

Quizás uno de mis próximos proyectos