Bugs en la centralita de mi coche

Cuando hablamos de un bug en una aplicación para dibujar hablamos de una pequeña putada, llega grafista, dibuja un logotipo de muerte y tras 3 horas intenta grabar y la aplicación casca. No pasa nada, el grafista pierde 3 horas de su vida, se cabrea y listo. Si hablamos de un software que se ejecuta en un hardware que controla un vehículo, un avión o un sistema donde se hacen transacciones bancarias la cosa cambia. Un error puede matar a una persona que circula en su vehículo y pierde los frenos.

Dada el impacto que puede producir un error en un software de estas características cabe pensar que los desarrolladores de estas aplicaciones estén muy formados y que las pruebas de calidad que pasen sean muy minuciosas.

Hace unos días me llegó una carta certificada de Renault, indicándome que tenía que llevar mi coche a un concesionario oficial para hacerme una reprogramación por peligro de "bloqueo del motor durante su utilización". No creo que después de 50mil kilómetros me vaya a petar el motor, aunque quien sabe. En resumen, me ha cambiado el software que controla la inyección de carburante, que suena importante.

Me imagino que el software de inyección irá en un hardware aparte que el ordenador de a bordo, el cual me estima mi consumo instantáneo, medio, etc. Bien, después de este reinicio ahora el coche no calcula bien el consumo medio, lo que me hace pensar que el software de mi ordenador de a bordo no se ha enterado de la reprogramación del software de inyección y por tanto sigue teniendo "algunos" datos antiguos y algunos otros nuevos. En resumen, mi consumo medio es 0.1 litros/100km (al precio del gasoil es una ganga).

Pero bueno, es un caso muy raro, se puede tolerar, sin embargo hay otro problema que me da más que pensar: 2000 kilómetros antes de cambiar el aceite me avisa y justo cuando llega ese aviso el ordenador curiosamente corrige otro bug, este es de la máquina de estados que controla lo que se muestra en pantalla. Cuando me ha avisado siempre vuelve a la pantalla a la que estaba después de usar el regulador. Cuando pongo el regulador en la pantalla me muestra la velocidad y en su funcionamiento normal se queda fijo, sin embargo, como digo, después del aviso vuelve a mostrarme lo que tenía. Esto me dice dos cosas:

1.- Los que prueban y programan no saben el comportamiento que debe tener, de otra forma se hubiesen dado cuenta de lo que tenía que pasar.

2.- No usan ningún tipo de test y si lo hacen no tienen un informe de cobertura de test. En caso de que lo usaran podría haber detectado rápidamente que el caso de funcionamiento con aviso de ir al taller estaba testeado. Un artículo referente a esto en el blog de testing de google.

No quiero ni decir nada acerca de algún que otro código que he visto que controla ciertas transacciones con tarjetas de crédito, ahora me da miedo real pagar con tarjeta de crédito.

Para cuando un coche donde dejen el código fuente abierto y cada uno podamos programarnos nuestro software a medida ? :D Hay gente que hace hacks (con arduino por cierto), pero no lo veo muy claro

pd: la imagen está tomada de la wikipedia en inglés

Manual rápido de programación con GPS

Hace tiempo que tenía ganas de poner un post de este tipo, así que vamos allá. Pongamos que no sabes lo que es GPS y quieres hacer una aplicación que necesite saber donde estás, estás en el sitio correcto, voy a tratar de enumerar lo que necesitas saber de forma clara y concisa:

- Qué es GPS: es un sistema que permite saber en qué posición del globo estás situado
- En qué se basa: Hay una serie de satélites orbitando que emiten señales, el receptor las interpreta y gracias a triangulación determina tu posición
- Necesito saber triangular: no, el receptor hace todo por tí, olvida a doppler, trigonometría, etc :)
- qué información da el GPS: te da la posición gracias a la latitud y longitud, esto es, lo hace en coordenadas polares. Además el GPS da mucho más información...
- Cómo me da la información el GPS: usa NMEA, un protocolo de texto separado por comas donde viene la información bien clarita.
- Cómo recojo la información del GPS: pues normalmente a través de puerto serie... "pero mi receptor GPS es bluetooth", no te preocupes, tu bluetooth se comportará como un puerto serie.
- Cómo uso la información desde mi aplicación: abres el puerto y vas leyendo linea a linea los datos NMEA, extraes la información y la usas, por ejemplo, para poner un punto en un mapa.
- Las coordenadas polares no son útiles para mi: lógico, estamos acostumbrados a trabajar en coordenadas cartesianas (el plano XY de toda la vida). Alguien ya pensó en eso e inventó UTM, que no es más que un sistema para proyectar latitud y longitud a nuestro querido plano castesiano. En resumen, al final tendremos X e Y y con eso es muy fácil empezar a trabajar

- Ya, dicho así es fácil, pero cómo lo hago en la realidad?. Lo primero es tener un GPS, por ejemplo , como mi pc no tiene puerto serie uso un conversor USB->serie. De esta forma ya puedo acceder al GPS... cómo? pues con python y los siguientes pasos:

- instalo python
- instalo Python for Windows extensions si estoy en windows
- instalo pyserial que nos da acceso al pueto serie.
- instalo pygps: este hará el trabajo de interpretar NMEA y proyectar a UTM por nosotros

- abro el editor y programo:


import serial;
from threading import Thread;
from NMEA import NMEA;
from LatLongUTMconversion import LLtoUTM;

class GPSPosition(Thread):
    def __init__(self, callback):
        Thread.__init__(self);
        #serial conf
        s = serial.Serial()
        s.baudrate = 4800
        s.port = "COM1" 
        s.open();
        self.serial = s
        self.nmea = NMEA();
        self.callback = callback
        self._run = 1;
        self.start();

    def end(self):
        self._run = 0;
    def run(self):        
        while self._run:
            nmea_data = self.serial.readline();
            self.nmea.handle_line(nmea_data);
            zone, easting, northing = LLtoUTM(23, self.nmea.lat, self.nmea.lon)
            self.pos = (easting, northing);
            self.callback(self.nmea.lat,  self.nmea.lon, self.pos, self.nmea.mode > 0);

if __name__ == '__main__':
    def position(lat, lon, pos, valid_pos):
        if(valid_pos):
            print "current position", pos, "lat: ", lat, " lon:", lon;
        else:
            print "invalid position
  
    gps = GPSPosition(position);
    


ejecuto:

C:\temp>c:\Python25\python gps.py
invalid position
invalid position
current position: 314418.53, 4575413.58 lat: 41.31 lon: -5.22
current position: 314418.53, 4575413.58 lat: 41.31 lon: -5.22
current position: 314418.80, 4575413.20 lat: 41.31 lon: -5.22

- qué es posición inválida? Pues resulta que un GPS no sabe su posición nada más conectarse, necesita un tiempo (que depende de muchas cosas) para tener una posición válida.
- Lo hago y no me funciona: sal a la calle porque en casa el GPS no es capaz de coger señal de satélite dentro de casa!!
- No me da bien la posición: Lo habitual son 10 metros de error como mucho, normalmente está entre los 2 o 3 metros.
- Lo hago pero me oscilan las posiciones: en GPS es bueno pero milagros no hace.

Fin, espero no haberme dejado nada.

falta de profesionalidad

Todos los días empresas nos prestan una serie de servicios a cambio de un dinero, sea de forma directa, voy a un bar, pido un café y pago al camarero, o de forma indirecta, voy por una autovía que se financia con los impuestos que pago. Detrás de esas empresas y servicios hay gente, personas y el trabajo de esas personas es lo que al final te llega: el camarero me sirve el café, el ingeniero diseña la carretera y el operario la cubre con asfalto, etc.

El problema es que en una empresa hay gente profesional y gente que no lo es y es es la diferencia entre que no te enteres de que te están prestando un servicio a estar quemado e indefenso.

Para mi un profesional _no_ es una persona que tenga mucha experiencia o conocimientos en un área o que haga muy bien tal o cual cosa, para mi ser un profesional es ser serio en el trabajo, cumplir con los plazos, tratar de mejorar cada día, hacer frente a los problemas y, sobretodo, hacerse responsable cuando las cosas no se hacen bien.

Últimamente veo como la profesionalidad cada vez es menor: los servicios técnicos pasan de ti cuando hay un problema, el fontanero tarda 4 días en venir a repararte el agua caliente, acuerdas un plazo y luego no se cumple, etc, etc... y lo peor, cobran con un verdadero profesional. Estoy harto de ver gente que está en su trabajo viendo pasar el tiempo para que lleguen las 3 de la tarde y saliendo del paso como pueden y con el menor esfuerzo posible, lo veo cada día.

Da gusto ver a una persona que es profesional, que le gusta su trabajo y que se preocupa, y aunque me cobre más, lo pago con gusto, solo por el hecho de que sé que ese dinero va para alguien que lo merece y por otro lado porque así estoy participando en una "selección natural".

No me extraña que las empresas cada vez busquen gente con "perfiles horizontales", ser serio es algo básico y la carencia de esa característa es mucho más problemática que la de conocimientos técnicos. Sabes que una persona profesional que tiene una responsabilidad va a esforzarse (o apechugar) para sacarlo, independientemente de si sus conocimientos sean bajos en esa materia. Saber J2EE, hibernate, structs, blablabla tiene un precio, poder confiar en que alguien va a tener algo en la fecha, sea lo que sea, no.

intento de augmented reality

"Para quien tiene un martillo todo son clavos".

Esta mañana me he levantado pronto y como no tenía sueño y nada que hacer productivo en todo el día, he pensado en hacer algo con mi webcam (tranquilos, no salgo en ningún momento :). Hace unos días vi como con un gps, una webcam y una brújula gracias a google earth conseguían poner una capa por encima de la realidad con información la ubicación de diferentes cosas. El proyecto estaba hecho sobre android, en el enlace hay un video muy interesante. Tambien hace relativamente poco vi como un navegador proyectaba información sobre el parabrisas que indicaba qué calle debías coger (no encuentro el link). Con lo cual me planteé por qué no podría hacer lo mismo para agroguía, que el agricultor mirase la cámara y viese por donde había ya pasado superpuesto con la realidad.

En esta mañana he hecho un prototipo de augmented reality de forma que en la pantalla del PC se mostrase información de por donde ya había pasado mostrando la visión en ese momento del conductor unido a un capa generada que se lo indicase.

He cogido la webcam, un GPS, python y opengl y he preparado un prototipo. He colocado la webcam arriba en el coche (ver foto) junto al GPS de forma que a medida que el GPS me da información de posición con OpenGL renderizo las zonas por las que ya se ha pasado justo con la cámara en ese lugar.




La prueba no ha quedado demasiado mal teniendo en cuenta que es un prototipo rápido, un video:



Problemas:
- La resolución de la cámara es malísima.
- El GPS lleva retardo, de ahí que no estén sincronizados
- No he calibrado la cámara adecuadamente, la he puesto a ojo, un fov e inclinación más o menos parecida a la de la webcam

Mañana voy a probar con un GPS de 5hz y con menos retardo, además intentaré ajustar mejor la cámara.

Cube modeling challenge

Este fin de semana están haciendo un concurso de modelado solo con cubos. A priori parece que con pocos cubos no se puede hacer demasiado, sin embargo merece la pena entrar y ver las imágenes.

Por mi parte me he animado y he hecho una (lo primero que "modelo" en mi vida)



si, es triste y oscura.

cosas que pasan: MGS mobile

Me bajo metal gear acid mobile, la versión 3D para probarla en mi móvil y así saber si los shots que había visto hace ya meses eran verdad y el juego prometía tanto, lo paso al móvil y después de defraudarme miserablemente (por ahora, no me gustan los juegos por turnos) me dispongo a decompilarlo para ver un poco qué hacían.

ejecuto:
"""
C:\temp\metal_gear_acid_mobile_3d_n70\src>java -cp jode.jar;C:\WTK22\lib\cldcapi10.jar;C:\WTK22\lib\midpapi20.jar;C:\SonyEricsson\JavaME_SDK_CLDC\PC_Emulation\WTK2\lib\mobile3d.jar;C:\WTK22\lib\mmapi.jar jode.decompiler.Main --dest src meta l_gear_acid_mobile_3d_n70.jar
"""

y cual es mi sorpresa que no está ofuscado!. Ahí está, el código del juego completito, salvo métodos que están, parece ofuscados, todo el resto de cosas se pueden ver perfectamente. Ahi está, todo el código de 3D, su A* (ver AStarSearchpor ejemplo), la animación a la antigua usanza (quake2 style pero sin interpolar) de Snake (ver JSR184_LoadSnake).

Soy fan de decompilar juegos para móvil, es divertidísimo intentar saber qué están haciendo sin ver ni una sola variable (normalmente todo se llama 'a') o ver los formatos de fichero que usan o como cargan las imágenes. Por ahora lo que más he visto ha sido lo de empaquetar recursos y "xorear" parte de los datos, "swapear" el comienzo y fin del fichero (ves cosas como "GNP" de la cabecera de los png)... aunque luego tienes casos como gameloft del cual aún no he conseguido ver como lo hacen, es demasiado difícil de descifrar para un rato.

Si algo bueno tiene java (de lo poco) es que se puede decompilar y mirar dentro.

KML y la privacidad

Este post pretender ser dos cosas: primero un pequeño manual de como hacer un servidor de KML con python y cherrypy y segundo demostrar qué se puede hacer para recibir feedback indiscriminado usando lo anterior.

Conocimientos previos:
- cherrypy es un API que permite implementar una aplicación web en dos patadas
- KML es un formato usando principalmente por Google Earth que sirve como contenedor de información geográfica, puntos de interés, etc, etc

KML no deja de ser un xml (*sic*) en el cual cabe de todo puntos, líneas, elementos 3D, animaciones y lo que nos interesa, conexiones a un servidor para obtener datos enumrados anteriormente. De esta forma es posible indicarle en un enlace que vaya a un servidor a buscar datos. Hay un pequeño pero efectivo tutorial en la página del api de google earth.

Tomando ese ejemplo creamos el servidor con cherrypy:

import cherrypy

class Root:
def get_kml(self, latitude, longitude):
kml = (
'<?xml version="1.0" encoding="UTF-8"?>\n'
'<kml xmlns="http://earth.google.com/kml/2.2">\n'
'<Placemark>\n'
'<name>Random Placemark</name>\n'
'<Point>\n'
'<coordinates>%f,%f</coordinates>\n'
'</Point>\n'
'</Placemark>\n'
'</kml>'
) %(longitude, latitude)
return kml

def index(self, directory="."):
cherrypy.response.headers["Content-Type"] = "application/vnd.google-earth.kml+xml"
return self.get_kml(-3.332565,42.600353);

index.exposed = True

if __name__ == '__main__':
root = Root()
cherrypy.quickstart(root);


El tema web no me va, pero estaba interesado en saber como va este tema en python. Me da la impresión que aún está por detrás de Ruby. He estado mirando turbogears y la verdad me ha gustado.

En el tutorial ponen un ejemplo de KML que se conecta a un servidor, podríamos cambiar la sentencia Link por lo siguiente:

<link>
<href>http://localhost:8080/</href>
</link>

De esta forma al cargar ese fichero en google earth se conectaría al servidor y bajaría kml.

Ahora la segunda parte: qué pasa si ese kml es generado por una aplicación y el usuario lo carga en su google earth. Pongamos, por ejemplo, un software de guiado para maquinaria agrícola, en el cual después de haber trabajado se puede guardar ese trabajo a KML para poder verlo más tarde en el PC. Pongamos que ese software escribe algo así dentro del fichero kml:

<link>
<href>http://servidor.com/?license_no=1234&lat=-3.332565&lon=42.600353</href>
</link>

Gracias al número de licencia conoces al usuario y con latitud y longitud conoces la localización de sus parcelas. Eso por no hablar que con unos pocos bytes se puede enviar _de todo_. Tiene su parte mala, pero también su parte buena, se le pueden dar bastantes usos.

Por cierto, y no digo que tenga algo que ver, ya he implementado el writer para kml de agroguía :):