Preparando ficheros stage... ya tenemos robot!!!

¿Para que tanto hablar de robots si después no ponemos los conocimientos en funcionamiento? Eso se preguntará mucha gente y para ellos es esta entrada.

Dado que no tenemos robots, lo lógico es que los simulemos. Para simular podemos usar tanto gazebo que realiza una simulación en 3D, como Stage que esta íntimamente ligado al middleware Player que es el que tomamos la decisión de utilizar. Por lo tanto explicar Stage es lo lógico además de que aunque no queramos usar Player también se puede usar con ROS (el RSF más potente y recomendable para grandes proyectos en la actualidad).

Lo primero de todo es tener en cuenta que vamos a trabajar en GNU/Linux como siempre hemos asumido hasta ahora, aunque Player existe también para Windows.

Pasemos a los ficheros. Para que Player sepa que proxies debe activar en el servidor del robot, para que nuestro software se pueda conectar como cliente, se requieren de un fichero de configuración con la extensión .cfg pero si ese robot no existe y va a ser simulado y mostrado con Stage, se requerirán los ficheros del mapa (una imagen con extensión la que se desee) el .world y algunos .inc

Los .inc son ficheros que describen fisicamente al robot, los componentes adicionales que se van a incluir (en el caso del turtlebot la Kinect) y el entorno donde se moverá. Solo son útiles para Stage por lo que cuando usemos Player en el robot real, no los necesitaremos. Es habitual usar los .inc que ya existen y no crear unos, por el engorro que supone crearlos.

Los .world son ficheros que describen también físicamente al robot. Normalmente solo se usa un .world en una simulación y dentro de este es donde se incluyen los .inc anteriormente mencionados. Un ejemplo de .world puede ser este:

# ejemplo.world
# Authors: Gabriel Núñez Guerrero
# $Id$

include "map.inc"
include "irobot.inc"
include "kinect.inc"

# time to pause (in GUI mode) or quit (in headless mode (-g)) the simulation
quit_time 3600 # 1 hour of simulated time
paused 0

resolution 0.02

# configure the GUI window
window
(
  size [ 851.000 721.000 ] # in pixels
  scale 0.02857   # pixels per meter
  center [ 0  0 ]
  rotate [ 0  0 ]           
  show_data 1              # 1=on 0=off
)

# load an environment bitmap
floorplan
(
  name "Mapa"
  size [23.9 20.3 1]
  pose [0 0 0 0]
  bitmap "mapa.png"
)

roomba
(         
  # can refer to the robot by this name
  name "roomba"
  pose [-2 -5 0 90.00 ]

  kinect( pose [ 0.1 0 0 0 ] )
  blobfinder( colors_count 6 colors [ "red" "blue" "green" "cyan" "yellow" "magenta" ] )
  fiducial( range_max 8 range_max_id 5 )
  fiducial_return 1 
           
  localization_origin [0 0 0 0 ]

#  Odometria con errores simples inyectados para simular perdida
  odom_error [ 0.2 0.2 0.1 ]       # Error  x y z
                               
)

Dado que desde el principio estamos describiendo la creación de un turtlebot, en este fichero .world hemos incluido los .inc correspondientes al irobot, a una kinect y al mapa donde se moverá. Dentro estamos generando un robot que llamaremos roomba (osea el turtlebot) con el accesorio de Microsoft.

También estamos describiendo como sera la planta del mapa donde se moverá nuestro aparatito. Dentro del floorplant se indica el nombre del mapa, de donde se sacara la imagen, las dimensiones en metros y la posición  donde se pondrá.

Por último se define la ventana de visualización que usara Stage para mostrarnos el escenario con nuestro robot. Esta ventana debe guardar unas proporciones con respecto a la imagen y al tamaño que se ha indicado que tiene el mapa en medida real.

Los .cfg son los ficheros donde se especifican que proxies debe lanzar el servidor de player. Es el fichero más importante, es el alma de nuestro robot y es el que con pequeñas modificaciones se usará para ser ejecutado en el robot real, no solo en la simulación de Stage.

Fichero ejemplo de .cfg:

driver
(       
  name "stage"
  provides [ "simulation:0" ]
  plugin "stageplugin"
  worldfile "prueba.world"   
)

# Create a Stage driver and attach position2d and laser interfaces
driver
(
  name "stage"
  provides [ "6665:position2d:0" ]
  model "roomba"
)

driver
(
  name "mapfile"
  provides ["6016:map:0"]
  resolution 0.02857
  filename "mapa.png"
)

#driver
#(
#  name "wavefront"
#  provides ["planner:0"]
#  requires ["output:::position2d:1" "input:::position2d:0" "map:0"]
#  safety_dist 0.15
#  distance_epsilon 0.4
#  angle_epsilon 10
#  replan_dist_thresh -1
#  replan_min_time -1
#  alwayson 1
#)

#driver
#(
#  name "kinect"
#  provides ["color:::camera:0" "depth:::camera:1" "ptz:0" "imu:0"]
#  heatmap 0
#  downsample 1
#  color_resolution 2
#  depth_resolution 1#)

Las líneas que comienzan con el caracter # se interpretan como comentarios. Bien, dicha esta obviedad debeis tener en cuenta que lo comentado puede ser descomentado y el robot simulado debería funcionar igual, pero la kinect debería existir de forma real conectada a algún USB de vuestro equipo. Recomiendo dejarlo tal como esta de momento.

Para que podais hacer experimentos y pruebas, dejo los ficheros en el siguiente enlace, para que puedan ser descargados.

https://docs.google.com/file/d/0B0kz7LhqitgreS13RnFqT2JLVWc/edit?usp=sharing

Uso de Player/Stage

Una vez preparado todo, hay que saber como echar a andar a un robot (simulado o físico) . Esto se hace con un simple comando: player robot.cfg

Pero Player también viene acompañado de multitud de aplicaciones que sirven de apoyo para la experimentación. Por ello es interesante mencionar algunos que pueden tener un interés especial:

playernav

Muestra en una pantalla con el mapa del que esta provisto el fichero de configuración del que proveeremos a nuestro robot. De todas formas, no tiene porque existir un mapa, pero ayuda a la localización. Con este programa, podemos ver en 2D el robot en su posición actual en el mapa, y dar una serie de waypoints que el robot seguirá.  

Uso playernav localhost:6665

localhost puede ser cualquier IP donde se este ejecutando un servidor de player. El puerto por defecto es el 6665 pero puede ser cualquier otro, según la configuración del fichero del robot.

El control es algo extraño, porque debe pinchaser con el ratón sobre el robot que se representa con el circulo rojo, y arrastrar al punto donde quiere que sea el destino del movimiento, dejándole marcado este como goal.

playerv

Permite subscribirse a los dispositivos configurados en el robot relacionados con el posicionamiento aunque también al laser, y mapa pero apenas son útiles en este programa. Además es posible comandar el robot, usando un vector de velocidad y ángulo.

Uso  playerv -h localhost -p 6016 

-h para indicar la IP del servidor player que se esta ejecutando (simulación o real) -p puerto del servicio position2d (6665 habitualmente y por defecto si no se indica)

El vector de movimiento se obtiene al pinchar sobre la caja roja y moverla sin soltar.

playercam

Muestra en una ventana la imagen que devuelve la cámara que pudiera haber instalada en el robot. 

Uso  playercam localhost:6665

playerjoy

Únicamente permite mover el robot sin interfaz gráfica, usando el teclado actuando directamente sobre la odometría. Es muy similar a como funcionaría controlándose como un videojuego.

Uso playerjoy localhost:6665

Instalando Player/Stage

Trás mucho hablar de middleware de robots, lo primero a parte de tener un ordenador con GNU/Linux preparado, es realizar una instalación del software necesario para comenzar con las simulaciones que nos permitán hacer nuestros experimentos. Posteriormente este mismo software desarrollado puede ser llevado a nuestro hardware y ejecutado de la misma forma que en simulación.

Para instalar Player/Stage recomiendo seguir la siguiente guia, ya que es algo problemático, y es la web mas completa que conozco sobre este tema.

http://www.cnblogs.com/kevinGuo/archive/2012/05/03/2480077.html

Como advertencia, recomiendo hacer uso de una versión de Linux de 32bits, para evitar problemas con localicación de las librerías a la hora de las compilaciones.

Otra recomendación es referente a Stage. En el proceso de compilación no es dificil que aparezca algo como esto:

Stage-3.2.2-Source/libstage/region.cc:10: error:  
reference to ?Region? is
ambiguous
/usr/include/X11/Xutil.h:267: error: candidates are: typedef struct  
_XRegion* Region 

 Si se da este caso, editar los ficheros region.hh y region.cc Del segundo debemos cortar (no copiar) el código correspondiente al constructor y el destructor de la clase Region, y en el primer archivo pegar dicho código dentro de la clase. Es algo muy sencillo que resuelve el problema.

¿Amor por Pentax o datos objetivos?

¿Por qué Pentax es la mejor marca de reflex de la historia? Este modelo solo cuesta 644€ y es gama proconsumer. Se trata de la vieja K-5 y no de ninguna de sus revisiones (es un modelo de mas de 2 años y sus datos le mojan la oreja a cualquier Canon o Nikon actuales de precios similares)

-16MPx
-Cuerpo sellado
-Estabilizador de imagen integrado en el cuerpo
-HDR integrado en la camara
-ISO 80-51200 en manual
-FullHD a 25fps
-7fps
-1/8000 tiempo de obturación

Y lo mejor de todo..




Para los que quieran cámaras de gama intermedia, están las K-30 y K-50 de la misma calidad y especificaciones casi calcadas. Para principiantes tenemos ñas k-r y nuevas k-500 (esta prima hermana de las K-50 pero sin cuerpo sellado ni de magnesio pero solo 499 euros en kit con 18-50)

 

     Hace poco se acaba de inaugurar la página web de una aplicación que seguro será de interés para los usuarios de móviles con SO Android y que sean unos apasionados del deporte al aire libre. Se trata de un programa que ayuda a los jugadores de golf a mejorar su juego, mediante una serie de ayudas sobre el propio campo gracias al uso del GPS. La aplicación no se encuentra aún publicada en el google play, pero promete hacerlo en poco tiempo. Se encuentran registrados todos los campos de golf de España, y pinta sublime. Es un concepto nuevo que los buenos aficionados al golf agradecerán. 

 ---- 

     A few days ago was launched the website about an app that will be very interesting for android movile device users and outdoor sports enthusiasts. It's a software that will help golf players to improve their skills thanks to their device's GPS and other interesting features. The app is not published in Google Play yet, but it will be very soon. All spanish golf courses are included and looks great. It's a new concept that amateur golfers will appreciate very much.

www.scaddie.com

Panorámica en alta resolución de Marte

Esta imagen de 360º que bien podría haber sido sacada por un Nexus 4 o un LG Optimus G, pertenece a la Curiosity Rover en Marte.

Esperemos que la próxima foto obtenida por un engendro mecánico de forma remota, la hayamos obtenido con alguno de nuestros proyectos.

Mars Gigapixel Panorama - Curiosity rover: Martian solar days 136-149 in Out of this World

El nuevo iPod touch para el 23 de Octubre

Ya se que el 23 de Octubre no se sabe que va a presentar Apple en su evento especial, pero todos aseguran que saldrá el nuevo iPad mini. 

Sea lo que sea que se presente no dejará de ser un iPod touch tuneado. Hace tiempo que Apple no innova, que clona el mismo dispositivo con pequeños retoques (algunos copiados de la competencia y mejorados, otros propios pero sin llegar a ser radicales), pero el mercado con su borreguismo habitual no hace mas que bailarle el agua. Ayer mismo escuche en la radio a un "guru" hablando de como la empresa de la manzana había vuelvo a deslumbrar al mundo con el mejor móvil de la historia y dispositivo más avanzado del momento, el iphone 5, cuando precisamente cualquier hijo de vecino sabe que el iphone 5 ha sido la decepción más grande en tiempo (los hay que prefieren incluso el 4S al 5 porque el salto técnologico es mínimo y el precio es más ajustado).

Esta sequía de ideas no viene desde la muerte de Steve Jobs, es algo que viene desde la época del primer iphone. El primer iphone fue un producto impresionante y revolucionario pero a estas alturas esta más que superado y solo saben estirar el chicle, lo mejor del asunto es que el chicle no se les rompe.

Retina display, pantalla más alargada, microsim, nanosim, siri... ¿alguna de estas cosas son trascendentales? El retina display parece el más revolucionario de esta lista, y realmente nadie puede decir que es radical porque con esas dimensiones de pantalla y la concentración de pixeles por pulgadas dificilmente a simple vista es apreciable una mejora en la calidad de imagen. Es más, el retina display se ha demostrado no ser para nada una tecnología interesante, al ser aplicada en los MacBook ha recibido mas criticas que otra cosa, porque toda la vida de la informática ha estado orientada al pixel y en eso se basan muchas técnicas de mejora de imagen (tanto hardware como software)

El 23 de Octubre veremos el ipod touch en una pantalla de 7", tendencia que desde hace unos años esta ganando adeptos, porque se esta demostrando que es el tamaño perfecto para un tablet. Las 7" permite usar el aparato sujetandolo con una mano sin tener que apoyarlo, escribir con los pulgares en la pantalla virtual mientras lo sujetas sin que las teclas del centro de la pantalla queden lejanas, y el tamaño de la pantalla es ideal para guardarlo en cualquier bolsillo, permitir resoluciones muy respetables (mas sabiendo que en 5" ya se meten 1080p) ver con claridad una pelicula o pagina web sin dejarse la vista...

El precio, por fin Apple se ha dado cuenta que hay que vender tecnologia "barata" para extenderse en todos los sectores. Los 250 euros que se han visto en algunos listados de tiendas importantes, lo ponen a la altura del Nexus 7 de google (mejor aparato a mi ver que el iPad mini y lo digo sin que se sepa aun ni como sera el nuevo dispositivo que se presenta dentro de unos dias), aunque auguro que su interior no tendra ningun quadcore, ni tendra 2GB de RAM... 

Apple llega tarde, con un SO que debe tener un lavado de cara porque su interfaz esta quedando obsoleta frente a Windows Phone o el giro que esta dando Google a Android, pero triunfara. Si venderan tantos iPad mini, que para navidad NADIE podra comprar uno por la falta de existencias. 

Larga vida al ipod touch ya sea convertido en móvil, tablet,  formato nano o en, estado natural,  mientras algunos esperamos a que Apple vuelva a ser lo que fue llevando las riendas de la innovación.

Elección de un RSF (Middleware para robots) adecuado.

Voy a tratar de enlazar lo antes posible el asunto de los middleware de robots, porque mi intención es comenzar un pequeño tutorial para todo aquel que desee hacer sus experimentos.

Lo primero que hay que tener claro es el tipo de entorno en el que vamos a desarrollar los experimentos, los requisitos de nuestro experimento (osea lo que vienen siendo requisitos no funcionales en ingeniería del software), y el hardware del que disponemos (requisitos no funcionales). De estos factores se desprenderá la dificultad del conjunto y las características a las que deberá cumplir el RSF. 

Existen muchos artículos de investigación que hacen una recopilación de los middleware mas extendidos y sus características, con lo que consultándolos se podría hacer una aproximación a la elección.

Ref: 

• PabloIñigo-Blasco, Fernando Diaz-del-Rio, Mª Carmen Romero-Ternero, Daniel Cagigas-Muñiz, Saturnino Vicente-Diaz, "Robotics software frameworks for multi-agent robotic systems development", Robotics and Autonomous Systems 60(2012).

• Ayssam Elkady y Tarek Sobh, "Robotics Middleware: A Comprehensive Literature Survey and Attribute-Based Bibliography", Journal of Robotics Volume 2012, Article ID 959013, Enero 2012.

• Nader Mohamed, Jameela Al-Jaroodi y Imad Jawhar, "Middleware for Robotics: A Survey", (RAM 2008), Septiembre 2008.

Bien, pondré un supuesto con el cual se hará la elección.

En principio plantearemos un entorno controlado como el interior de una casa o un patio, donde cualquiera puede hacer sus pinitos en robótica avanzada. Además asumiré que el experimento será un éxito con tan solo mover el robot y obtener una posición. Y por último, el hardware que se usará es un turtlebot.

Dados estos requisitos, parece obvio que lo mejor es usar ROS, ya que Willow Garage es el desarrollador de este robot y a estas alturas se trata del RSF más extendido y con más futuro. El problema es la gran capacidad de disco que requiere, la falta de versión para programar en otros leguajes de programación que no sean C++, y la total imposibilidad de instalarlo en otros sistemas que no sean Unix like.

Para un experimento de pocas pretensiones, muy versátil, accesible a todo el mundo (no necesario saber de GNU/Linux) y con posibilidad de hacer todo tipo de simulaciones antes de llevar el software al robot, mi elección es la de Player/Stage. El uso de Player/Stage nos permite abaratar más el robot, y podríamos ahorrarnos el poner una Kinect e incluso usar el ipaq como equipo de computo (bueno esto es por frikismo de mi parte)

Bien, Player/Stage es un robotics software framework cuya comunicación se realiza entre el cliente y el servidor de los datos por TCP. Este es uno de los aspectos más débiles del middleware, pero dado que el software cliente estará funcionando en una red local o incluso dentro del mismo turtlebot, y no habrá un flujo de datos abrumador, no tiene mucho sentido preocuparse por este aspecto. Lo mas interesante, además de la multiplataforma, es su plena integración con el simulador Stage. 

Stage simula las lecturas de datos de los sensores y componentes con los que se conforme el robot, por lo que el algoritmo que queramos probar en el software cliente de nuestro turtlebot podrá ser probado en simulación. Esto ayuda a la depuración y mejora antes de pasar a la acción real, la detección de fallos es esencial, pero también podremos inducir a ellos introduciendo ruido aleatorio en las lecturas para ver que tal se comporta.

Player provee de los datos al clientes mediante unos proxies, que a su vez están conectados a los drivers del hardware de forma que hacen de capa de abstracción para facilitar la vida al desarrollador. Estos drivers a su vez están conectados a Stage que sustituirá al hardware cuando se simule.

Esquemas del funcionamiento.

Esquema de Player-Hardware

Esquema Player/Stage

Recopilamos el porque he dedidido usar Player/Stage:

-Muy extendido, por lo que tiene una comunidad de usuarios amplia que puede ayudar.
-Ocupa poco en disco.
-Programación en varios lenguajes.
-Portado a distintos SO.
-Simulador integrado de serie.
-Soporte para Kinect, y para el Roomba de iRobot.
-Facil configuración.

En contra se puede decir que la instalación no es muy simple, ya que ofrece problemas de compatibilidad con librerías, y el tipo de comunicaciones.

Turtlebot, o robots basados en Roomba

En este artículo quiero hablar de robots diseñados en base los modernos robots aspiradora (en realidad de 3 modelos concretos). Estoy agrupando todos bajo el nombre de turtlebots, pero es un error que voy a permitirme porque quiero que todo el mundo sepa a que me refiero.

El turtlebot es el robot de investigación y experimentación más sencillo y económico disponible en el mercado. Se trata de OpenHardware desarrollado por Willow Garage (desarrolladores del middleware para robots ROS) por lo que no necesariamente hay que comprar el aparato sino que se  lo puede construir cada uno en su casa. Frente a opciones como las plataformas robóticas de MobileRobotics, se desmarca como la opción más recomendable para macroproyectos de cientos de agentes o para microproyectos de un único agente pese a que su autonomía, versatilidad y capacidad de carga son mínimas en comparación con un Pioneer.

http://turtlebot.eu/

http://turtlebot.com/

Este robot puede simplificarse más debido a que en realidad se esta haciendo la customización del robot comercial Roomba de iRobot. Esta aspiradora dispone de un puerto serie accesible por donde provee de bastante información útil (con la ayuda de un pequeño circuito) como nivel de batería u odometría (muy importante).

Evidentemente, la plataforma requiere de hardware adicional como es una unidad de procesamiento donde  ejecutar un middleware y ejecutar los algoritmos que queramos probar. La elección de Willow Garage fue la de usar un netbook, pero no necesariamente tiene porque ser este equipo, podemos usar tanto una rasberry pi, como un PC 104, una PDA antigua... cualquier cosa que al menos pueda ejecutar Linux. Hay otras opciones por internet paralelas y muy válidas usando la aspiradora.

La versión que más me gusta es la que usa una viejisima iPaq. 

http://roomba.pbworks.com/w/page/11867510/iPaq%20Roomba%201

Si queremos seguir los pasos del turtlebot original es necesario instalar una Microsoft Kinect, accesorio de videoconsola que se ha convertido en la investigación como un elemento esencial por ser el sustituto perfecto de tres sensores habituales como son cámara, IMU y laser. Para que os hagáis una idea, el laser más barato del mercado no baja de los 2000 euros (aunque evidentemente no es comparable con el Kinect en precisión y alcance). 

Existe una última versión (que yo conozca) de estos turtlebot, y se trata del llamado bilibot que es el último en aparecer y el más caro al estar equipado con un brazo.

http://www.bilibot.com/

El cálculo es que con poco más de 400 euros tendréis vuestro turtlebot construido (reutilizando un poco de hardware y comprando algunos componentes de segunda mano)

LG, los moviles y Optimus 2x P990

Bien, quería hacer una pequeña visión sobre el mundo de los móviles y el problema de la marca LG. Esta empresa, lleva mucho tiempo haciendo móviles con poco éxito a excepción del "LG chocolate" mítico. El problema que tienen los coreanos es poco comprensible, ya que desde siempre han sido punteros en tecnología y van por delante de todos sus competidores.

Fueron los primeros en sacar un móvil de doble núcleo, con lo que consiguieron el smartphone más rápido de la historia y a un coste bastante ajustado; los primeros en sacar un terminal con tecnología 3D, los primeros en usar el dual channel para memoría RAM... ahora con el Optimus G tendrán el mejor móvil del mercado pero... ¿Por qué incorporando la mejor tecnología a un precio super competente, no consiguen el beneplácito del mercado? La respuesta es sencilla, mala experiencia de usuario.

LG se ha caracterizado en la época de la explosión de los smartphone, por no optimizar las ROMs de forma que muchos sufren cuelgues, reinicios o perdidas de cobertura intermitentes. Esto unido a su falta de soporte por parte de LG que no da ninguna continuidad actualizando los Androids (referente a nuevas versiones del SO), hacen que el usuario final tenga una sensación de mala calidad en sus productos. Si unimos esto al boca a boca de los foros, la sangría de posibles clientes es muy importante. LG podría ocupar el puesto que ocupa Samsung sin ningún tipo de problemas, pero una mala planificación la llevan al fracaso tras fracaso (no absoluto pero si conforme a espectativas que levantaban).

Es significativo ver que cuando tienes un móvil LG, si le cambias la ROMs de serie por una cocinada, obtienes una mejora importante y se eliminan casi el 100% de los problemas (obviando los propios de la ROM no oficial que siempre los hay).

Ahora pasaré a hacer una review de un LG Optimus 2X P990 para que entendáis lo que quiero decir:

Características:

-Tegra 2 1GHz

-512MB de RAM

-Salida HDMI

-cornning gorilla glass

-Pantalla Super LCD IPS 

-Resolucion 800x480 en pantalla de 4"

-Lector de tarjetas micro SD

-Almacenamiento interno de 8 GB

-Wifi, GPS y A-GPS, bluetooth

-Cámara de 8Mpx

-Grabación de video HD 720 y 1080p

-Conector de sonido standar jack 3,5mm

-Bateria de 1500mAh

Todo esto en un movil de principios del 2011!!! cuando cualquiera diria que es propio de hoy en dia.

En mi opinión los acabados son perfectos (metálicos en algunas zonas como el borde del terminal y tapa trasera), muestran gran calidad y robustez, cosa que no pasa con muchas marcas. Pero siempre recomiendo, tener el móvil en las manos. NO HAY QUE FIARSE NUNCA, DE LAS APRECIACIONES DE LA GENTE!!! Casi todos las review que se pueden leer están sesgadas hacia un modelo concreto, y las comparativas serias nunca hablan de aspectos subjetivos, por lo que siempre es mejor tener el móvil en mano y evaluar por ti mismo. Lo que a uno le parece grande y pesado, a otro le parece justo para el tamaño de su bolsillo.

Para que sepáis mis predilecciones, y entendáis mis apreciaciones informo:

-Me gustan los teclados físicos.

-Si no existe teclado físico veo esencial tener una pantalla de al menos 4,3" en adelante, sin llegar a las 5" o a lo sumo rozándolo.

-Es importante tener una cámara no de muchos MPx sino de alta calidad y buena optica, si ambas cosas se juntan mejor.
-Duración de la batería es vital.
-La calidad de los materiales y acabados es algo primordial.

Partiendo de esto, tras un tiempo usando el movil he comprobado que tiene una de las mejores cámaras de móvil que conozco, la batería no dura como una blackberry o un nokia symbian, pero frente a otros Androids es aceptable teniendo el 3G activo (osea 32 horas no más, sin uso intensivo evidentemente). El GPS es MAGNIFICO, no había usado un móvil cuyo GPS cogiera antes señal de satélites que este. Las pegas, el software como ya he mencionado (aunque la ROM de serie esta super preparada y equipada con software útil, con una capa de personalización que me encanta bien organizada, donde las aplicaciones instaladas se distinguen de las que vienen de serie y las nunca abiertas se marcan con una N sobre el icono), la pantalla es pequeña aunque ya os imaginareis que esta próximo a los iphone por las 4".

¿Porque hablar de todo esto ahora?

Parece ser, que por una vez no soy el único que piensa en contra corriente de la amplia comunidad de usuarios de tecnología. Google también ha creido en LG, y se ha dado cuenta de los equipazos que preparan lo Koreanos, por lo que se esta especulando que el próximo "teléfono google" oficial, osea el nuevo NEXUS será un LG basado en el nuevo Optimus G. Esto quiere decir que el problema de software se desvanecerá, y se convertirá en el móvil de referencia SIN DUDA ALGUNA.

Recomendación, ponga un móvil LG en su vida, uno de segunda mano de algún usuario de algún foro que este cansado de tantos fallos, y metale una ROM cocinada. El acierto esta garantizado, precio regalado y hardware perfecto. (Antes de la compra, comprobar las ROMs cocinadas disponibles, para evitar sorpresas)

RSF o Middleware para Robots

Una vez más creo oportuno hacer un break en mis entrada de opinión para ponerme un poco técnico y tratar de ayudar a los que sean curiosos o tengan problemas en sus proyectos. Esta vez voy a hacer una pequeña introducción a la robótica.

La robótica a gran escala, me refiero a sistemas con hardware de gran envergadura y no a los robots BEAM u otro tipo de robots simples (que no por ello son menos importantes), requiere de dispositivos cuyo manejo necesita de un software complejo. Por ejemplo, cuando se quiere usar un laser como es comprensible el acceso a los datos que provee este aparato, no es lo mismo que usar un sensor de proximidad de infrarojos o un sensor de ultrasonidos que pueden ser manejados por un simple PIC. De estas necesidades software se derivan muchas otras necesidades como: un sistema de computo potente (ordenador, pc104, placas con procesadores ARM potentes...), un conocimiento mucho más en profundidad del hardware, etc.

De esta problemática surgieron programas gigantes y nada reutilizables, para el control de un robot y de todos los dispositivos que lo componían. Por lo que si se construía un nuevo robot con componentes similares al anterior, no era posible reutilizar ni tan solo el software de esos componentes (salvo un buen diseño software). Gracias a Dios, entre los miembros de esta comunidad de investigadores habían muchos licenciados en computer science engineering (aka ingenierios informáticos)  y se dio con una solución bastante potente para el problema. Esta solución es el middleware para robots o RSF de las siglas Robotics Software Framework.

¿Cual es la utilidad de un RSF? Bien, se trata de una capa de abstracción software que sirve para que el programador se despreocupe de la implementación específica de un hardware y de todos sus detalles como drivers o APIs del fabricante. De esta forma se normaliza la programación para robots, y permite por ejemplo usar un laser dando igual la marca o modelo que sea, siempre que este tenga soporte dentro del middleware para robots.

Ahora viene lo mejor, esos componentes hardware concretos tienen sus correspondientes módulos/componentes software genéricos que homogeinizan el hardware, pero tienen que estar corriendo en un servidor al cual se conecta el software desarrollado por el usuario del robot. Bien, esto quiere decir que debe existir alguna forma de comunicarse con esos módulos para poder obtener información y controlarlo. Lo habitual, contra todo pronóstico, es que esa comunicación se realice mediante la pila de protocolos de red, haciendo uso de TCP/UDP.  ¿Por qué esto? para dar más flexibilidad de la que da el propio diseño modular, distribuir los componentes de un robot, permite la construcción de un sistema robótico mas complejo aún y por tanto más potente aunque a costa de problemas derivados de la comunicación.

Para que se entienda mejor el funcionamiento, pongo una imagen de un middleware comercial.

Los middleware más extendidos son Open source y por eso mismo son los más recomendables (si se encuentra un bug, se puede modificar, son los más extendidos por lo tanto son los que tienen mayor número de componentes..). Pero también a la hora de hacer la elección del RSF que se quiere usar en el robot, debería ser un factor muy importante la existencia de un software de simulación.

El software de simulación con normalidad se integra perfectamente con el RSF, consiguiendo que el desarrollador no necesite tener el hardware real para programar la aplicación que maneja el robot. Además, no solo simula el hardware sino también un entorno, pudiendo representar casi de forma fidedigna la respuesta del aparato en un entorno real.

Una pequeña recopilación de los RSF:

-ROS
-Player/Stage
-Miro
-UPnP
-ORCA
-Urbi
-OpenRDK
-OROCOS

Retro review SONY VAIO P11Z

Hace poco que me he hecho con este subnotebook y a petición de un compañero de foro voy a hacer esta pequeña review.

El Sony VAIO P11Z es un netbook interesante por la cantidad de hardware extra que equipa y por su tamaño, más que por otra cosa. Su rendimiento es bastante escaso si lo comparamos con un netbook actual, ya que si se tiene en cuenta que tiene un procesador Atom 520z o 540z en las versiones más potentes (1,8GHz) ya podeis imaginaros que puede tener problemas para mover incluso algunos juegos web hechos en flash (por ejemplo el settlers online del que ya hice una review). No quiere decir que sea pésimo, sino que su procesador es la primera generación de Atom y además en la gama de bajo consumo, sin contar el chip gráfico que aunque es "moderno" es una intel GMA500 (que viene siendo la GPU prima hermana que la de algunos móviles actuales, osea un derivado de PowerVR)

Como ventajas, ese procesador y GPU hacen que tenga un consumo reducido, pero se da el caso de tener una batería de muy escasa capacidad para también ahorrar en espacio, por lo que solo tiene 2 horas de autonomía. Yo tengo la batería de alta capacidad y me dura 4 horas aproximadamente con la wifi activa, pero hace que el portátil pese mucho mas (lo digo en relación al peso del portatil). 

También se trata de un netbook muy pequeño (no tanto como los viliv pero por el estilo) con una pantalla de resolución brutal 1600 x 768 y un peso de unos 600 gramos. El teclado es muy cómodo para el tamaño que tiene, algo que no se cumple en equipos como el Jornada 720 (se que no es un netbook pero tiene teclado completo que supuestamente se puede usar con las dos manos), los viliv o Kohjinsha (que son mi debilidad pero la cordura no me deja comprarlos).

El hardware adicional que lo convierten en un must have, es el GPS,el modem 3G y la pantalla de excelente resolución. Es cierto que hace que la duración de la bateria baje, pero te dan una flexibilidad brutal para alguien que este continuamente viajando. El otro punto débil es la pésima cámara, pero es suficiente para lo poco que se suelen usar (personalmente no la uso nunca así que paso)

¿Que ocurre con el software? Todos los drivers están disponibles para windows vista, pero no me extrañaría para nada que en windows 7 sean compatibles (normalmente los drivers para Vista funcionan sin problemas en 7 al igual que lo hacian en XP los del 2000). Un SO que no he probado y que a priori parece que sera compatible, es con Android X86 que actualmente ya esta en la version ICS. También existe un software de downgrade ofertado por la propia SONY que descarga todo lo necesario para que el Vaio P11Z funcione al 100% en XP.

En cuanto a Windows 8, lo he usado con bastante satisfacción (en la entrada que hago la comparativa con Windows XP podreis leer mas al respecto). Me ha asombrado ver como se mueve mejor con la nueva versión del SO de Microsoft que con las anteriores, pero he recibido quejas sobre el mal funcionamiento del GPS. Dudo mucho que sea tan malo como lo era el del Toshiba Libretto W105 (que carecía de antena conectada al modulo). Lo recomiendo totalmente, si tienes la intención de usar uno de estos para trabajo. Piensa que cuesta cerca de 300 euros (completo y perfectas condiciones) de segunda mano un equipo que es del 2009 y con hardware  que podemos asumir que esta desfasado en comparación con otros equipos del mismo precio. Osea, es un equipo muy valorado.

En resumen, comparándolo con mi último subnotebook, el Toshiba Libretto W105, tiene un rendimiento ridículo pero su grosor es menor aunque es mas largo. Dándole una puntuación en dimensiones tiene un 7/10 pero en hardware un 4/10 frente al Libretto al que le daría un 9/10. Estamos hablando de equipos de fechas  de salida muy próximas. El consumo, el calor disipado, y el teclado físico me hacen afirmar que el VAIO es más apropiado para el trabajo y me durara más tiempo que mi añorado W105 pero solo haciendo uso de la batería de capacidad extendida que se puede adquirir en ebay por 56 euros.

Los PowerPC vuelven a estar de moda

Los procesadores de Motorola e IBM de arquitectura RISC, están volviendo a estar en la cúspide de la tecnología. ¿Cómo es esto? Yo digo: ¿acaso alguna vez no lo estuvieron?

Apple abandono estos maravillosos procesadores en favor de los raquíticos intel, esgrimiendo motivos comerciales de abaratamiento de costes y mejoras de rendimiento sobretodo en el apartado de portátiles. Personalmente nunca me he creído esta versión, mas aun sabiendo los planes de IBM con procesadores de varios nucleos y bajo consumo antes de que intel pensara tener alguno en el mercado.

¿Por qué afirmo que ahora los PowerPC están de moda? Pues bien, se han dado las casualidades de que actualmente todo los aparatos que simbolizan el TOP de tecnología (y digo TOP REAL) tiene como protagonista un procesador de este tipo.

El Curiosity rover, esa sonda que acaba de aterrizar en Marte y que tiene como misión buscar vida, esta planeado que tenga 2 años de vida útil, pero puede alargarse hasta los 14!!! ¿Pero que pinta aquí la NASA? Pues pinta y mucho, el procesador encargado de llevar estas tareas a cabo es un RAD750, procesador basado en el PowerPC 750 a 200MHz (osea un G3 de toda la vida modificado para bajo consumo y soportar radiaciones) Se podría decir que el procesador es el de la Game Cube o la Wii. Aquí lo que cuenta es consumo potencia, y FLOPS que se pueden desarrollar, por lo que se ve evidente que si la NASA toma esta elección es porque se ha probado que son en estos ratios la mejor poción posible. PowerPC 1 - Apple 0

Siguiendo con esto, podría centrarme en que todas las consolas contemporáneas (Wii, Xbox 360, PS3) poseen un PowerPC en su corazón, de mas o menos núcleos, y a mayor o menor frecuencia. Queda claro el motivo de la elección en unos sistemas que su duración siempre se planea para al menos 5 años sin llegar a la plena obsolescencia. PowerPC 2 - Apple 0

Lo mejor, todos sabemos que el TOP500 es el ranking de los superordenadores mas potentes actuales, y que muchas veces han estado encabezados por equipos con procesadores vectoriales (los cuales requieren de una adaptación en el software a ejecutar) pero habitualmente, y concretamente ahora, esta encabezado por Sequoia http://i.top500.org/system/177556 que usa procesadores IBM Power BQC (variantes una vez mas de la familia de los PowerPC A2 multinucleos de reducido consumo) PowerPC 3 - Apple 0

Para finalizar, esta noticia: http://es.engadget.com/2012/08/04/ibm-alcanza-los-5-5-ghz-con-los-chips-system-z-y-anuncia-power7/ Power 7+  la nueva familia de la que nacerán los próximo PowerPC. Actualmente los Power7 son los procesadores de mayor velocidad del mundo con 4,4GHz SIN FORZAR EL CHIP CON TECNICAS DE OVERCLOCK (muchos podrían decir que AMD lo consiguió hace poco, pero no era así, no hablamos del mismo planteamiento) PowerPC 4 - Apple 0

Por mi parte, creo que poco hay que añadir. Aunque es cierto que Apple mejoro en difusión, no ha sido el caso de la mejora en rendimiento, ni el caso del abaratamiento de costes (siguen siendo equipos mas caros que la competencia solo justificados por el diseño). PowerPC son la crema de los procesadores de propósito general, y por ello no pienso renunciar a mis 2 PowerMac G5 Dual cores.

Review de Windows 8 Consumer Review

Todos sabemos que la interfaz de Windows 8 es totalmente distinta a la tradicional de los sistemas de escritorios, aun así mantiene esa posibilidad como retrocompatibilidad con el software no adaptado a Metro. En este escritorio, no encontramos botón de inicio, lo cual es chocante para un usuario tradicional, y no permite acceder directamente a las aplicaciones desde allí salvo accesos directos en pantalla. Si quieres encontrar tu software instalado, tendrás que usar la búsqueda del sistema similar a lo que ocurre con Ubuntu desde la version 11.04 usando Unity. Yo lo entiendo como un error total, que ademas, en ambos casos , quieren copiar al spotlight de Apple sin la opción que si da MacOS X de usar la barra del Finder para acceder a las aplicaciones.

Una novedad más para los nuevos usuarios de Windows 8, sera el encontrarse que no existe la mítica X para cerrar los programas. Si sales de estos volviendo a Metro, se quedan en background corriendo de forma oculta.

Los gestos más habituales se resumen en: Para volver a Metro puedes mover el ratón hacia la esquina inferior izquierda y hacer clic. Para cerrar las aplicaciones se consigue moviendo el ratón hasta el tope de la pantalla, pinchando y arrastrando hasta el borde inferior (el opuesto) de la pantalla. Si en lugar de llevarlo al borde inferior lo llevas al centro de la pantalla lo que consigues es minimizar. La opciones de Metro se hacen  visibles haciendo el movimiento de ratón hacia esquina inferior derecha y haciendo clic. Cerrar el equipo se realiza pulsado sobre el abatar del usuario del PC y seleccionando la opción pertinente.

Otras características que he observado en el nuevo SO de Microsoft, es que a la hora de la instalación se configura el perfil del usuario con el perfil de hotmail. Esto es importante, ya que la contraseña para el inicio de sesión sera la misma que tu cuenta de hotmail. ¿Por qué? Pues bien, algunas de las novedades de Windows 8 es la total integración con la famosa nube (con la cual no estoy en absoluto de acuerdo pero habrá que aceptarla hasta que se vean los problemas que suponen, y no solo hablo del caso de Microsoft, con esta opinión quiero generalizar). 

Dado que era usuario de Windows Phone, mis contactos, mis fotos, mis correos y skydrive estaban sincronizados con mi terminal móvil. Con Windows 8, nada mas conectarte a la wifi de tu casa te encuentras con que TODA esa información, por arte de magia, esta en tu PC. Si, todo lo que estaba en mi DELL Venue Pro esta en mi SONY VAIO P11Z. La sincronización es total y transparente, es muy agradable e impresiona, es muy útil tener la nube disponible y de forma que ni te enteras que la usas, pero me reitero en que lo veo peligroso.

Pero las maravillas de Windows 8 no acaban aquí. El sistema de lectura de correos electrónicos, ha mejorado substancialmente, haciéndolo fácil de usar y gestionar. Ahora bien, el sistema es tan parecido al que usa BlackBerry en su Playbook, que no me extrañaría para nada que se estuviera violando algún tipo de patente. Pero la cosa no queda solo en eso. El uso del sistema recuerda bastante a que sera necesaria una interfaz táctil para poder usarlo con facilidad, es evidente que el ratón esta obsoleto para Metro. Esto me crea otra inquietud, los gestos que requerirá Windows 8 para usar el Metro también recuerdan en exceso a las del tablet de RIM (aunque es cierto que son ligeramente distintos) 

Un cambio que también se encuentra en el nuevo SO, es el cambio de los colores del menú de inicio precarga del sistema. ¿A cual me refiero? cuando tienes mas de un SO instalado en el mismo equipo, el menú de inicio que se muestra para seleccionar en que arrancamos, el que se modificaba antaño en el boot.ini se muestra de color azul claro y blanco mostrando incluso un icono.

Por ultimo, una reflexión personal. Dado que el uso de Metro es tan peculiar, kinect sera soportado por el SO, y las fechas de salida son tan próxima, no me extrañaría que fuera practicamente necesaria la compra del accesorio de Microsoft para poder manejar Windows en PC sin interfaz táctil.

¿Por qué hago la review ahora? El motivo es porque se acaba de saber que ha habido una filtración y la versión definitiva de Windows 8 ya corre por ahi.

Vuelven los colonos!!

 El settlers online es una nueva secuela de ese maravilloso juego de estrategia que hizo sus primeros pinitos en ms-dos. Esta vez no hace falta gastarse el dinero en un soporte de almacenamiento para un instalable, ya que podemos jugar usando un navegador y registrándose en su página Web, lo cual no quita que a los menos pacientes les permita ahorrar unos euros.

Es un juego lento, pausado, que te da tiempo para pensar y dedicarte a otras tareas en el resto del día a parte del vicio (la lentitud en general puede desesperar a veces pero todo tiene su porque). Te mete el veneno en el cuerpo de los buenos juegos, e incluso los más frikis podrán estar 24 horas al día sin parar de hacer cosas como potenciar tus edificios para asegurarse una mejor producción o entrar en el comercio. Lo normal es que con 3 horas al día sea suficiente para tener tu isla al día, pero ese tempo para ser un juego de estrategia en tiempo real, es el que hábilmente los de ubisoft han visto ideal como filón para hacer caja y apropiado para los juegos Web.

El juego se desarrolla en sus primeras fases de forma ágil, permitiéndote subir de nivel con tareas sencillas. Esto es agradable para el jugador y creo que es un acierto y es el primer cebó para crear un fenómeno de masas en cuanto salga de la fase beta. Posteriormente se vé que el tiempo se ralentiza, las cosas no suceden tan rápido como se quisiera, lo cual en parte es bueno para no generar una dependencia total que absorba al jugador el 100% de su tiempo y eso es aconsejable para no obligar a una ruptura radical . Poco a poco se crea un ambiente en el que ves que todo se centra en la economía y que debes ser un buen gestor, comienzan las conjeturas con hojas de cálculo. Amigo mio, si llegas a este punto ya no hay marcha atrás. 

El juego cada vez complica más la evolución del jugador, y este sabe que en los tiempos de producción son importantes, pero ya no puedes hacer nada para optimizar o conseguir algunos elementos importantes del juego como son los generales veteranos, las licencias de construcción, los exploradores joviales, los batidores salvajes.. ¿que hacer? Desembolsar, comprar vía SMS gemas, el elemento que facilita la vida y con el que ubisoft pretende hacer caja.

El sistema de batalla es pasivo, solo puedes rellenar a tu generales con las tropas que mejor creas puedan hacer frente al enemigo, y enviarlos al combate. Tras este planteamiento, lo único que queda es esperar al resultado del enfrentamiento.

Existen varias páginas que se han creado para gestión económica, y también simulación de batalla, pero ya blue byte esta en proceso de integrar estas opciones en el propio juego. Hay que tener en cuenta que esta en fase beta, pero lleva una gran evolución.

Valoracion, juego sesudo y para pacientes (enfermos o no), o gente con mucho cash. 7/10

Pro: El apartado gráfico, el ser online sin instalación y tratarse del settlers

Contras: el juego es flash por lo que es pesado para equipos como atoms antiguos, el componente social no es muy evidente al margen de gremios que aportan poco nuevo al juego individual (chats y poco mas). Por último los precios en gemas de algunos elementos del juego son excesivos. Parece que en poco tiempo se mejoraran estas cosas, al menos una de ellas cuando entren en acción los PvP (player versus player) que se desarrollarán en terrenos de batalla neutrales.

¿ Windows 8 por fin desbancará a Windows XP ?

Desde que Microsoft tuvo la feliz idea de sustituir Windows XP, ninguno de los SO sacados hasta la fecha me han convencido, y creo que siempre he tenido razón al afirmar que ni de lejos estaban a la altura en rendimiento del sucesor de Windows 2000. Es por esto que he hecho algunas pruebas con Windows 8 en un equipo de especificaciones pobres y he comparado los resultados con la mismas configuración hardware y el XP.

Para empezar, tengo que recordar que para poder hacer una comparativa lo mas fiel posible a rendimiento y servicios entre los dos sistemas operativos, en Windows XP debería haber instalado Origami Experience 2, pero no lo he hecho. El motivo, es porque la interfaz METRO de Windows 8, no es ni mas ni menos que una evolución de lo que Microsoft quiso crear en el 2006 con el Origami Project y que dio lugar a los dispositivos UMPC (que posteriormente han evolucionado a los tablets actuales y que ahora estaba sufriendo una retroevolución a sus orígenes integrando teclados físicos).

Tenemos Windows 8 Release Preview 32bits para asegurarnos un entorno de escritorio, y Windows XP Profesional 32bits con service pack 3. El equipo donde se han puesto a funcionar ha sido un SONY VAIO P11Z/G con 2GB de RAM, procesador Atom 520z 1,33GHz y grafica intel GMA 500.

Con estas características, he observado un rendimiento superior en aplicaciones bajo Windows 8. Concretamente para ser más exactos, corriendo chrome y jugando al juego Settlers Online (que me gustaría analizar mas adelante). Este juego funciona con flash, y la respuesta del juego es peor al usarse en Windows XP. Esto da idea de una mejora en la gestión de procesos, y del rendimiento de los gráficos. Hace poco salieron unas estadísticas que respaldaban la mejora notable que sufrian las tarjetas gráficas bajo Windows 8 frente a Windows 7, y no descartaría que fuera extensible para XP.

http://blogs.msdn.com/b/b8/archive/2012/07/23/hardware-accelerating-everything-windows-8-graphics.aspx

Otro dato que ya era conocido es la velocidad de arranque del sistema, que se ve reducida, pero tampoco sorprende al hacer uso de UEFIs y particiones con precargas de drivers. Era uno de los objetivos de Microsoft y a fe que lo han conseguido.

En general, parece que el nuevo Kernel híbrido de Windows 8, sabe que tiene que hacer para dar una buena respuesta al usuario. Pese a que Metro gracias a sus tiles actualizables pudiera parecer que consumirían mas recursos no es así. 

En Windows XP, nos encontramos con un entorno que a priori parece con una respuesta más fluida, pero no se hasta que punto esto es real o solo una impresión infundada por la familiaridad del entorno. La sensación de mayor control sobre la máquina al tener todo a mano, y ver como funcionan aplicaciones antiguas, hacen dudar.

Bajo mi punto de vista, y por lo que he podido comprobar, Windows 8 será un digno sucesor de Windows XP en cuanto a rendimiento. Es importante el cambio para los usuarios que tengan equipos antiguos y quieran seguir dándole vida a sus equipos, aunque el cambio costará trabajo de asimilar por el cambio de filosofía que supone. Ahora ya no hay escusas para mantenerse en XP salvo que seas incapaz de adaptarte. Mejor rendimiento, la posibilidad de acceder a la nube de Microsoft por defecto, y muchos nuevos servicios gracias a METRO. Rejuvenecer el equipo, o solo hacer que rinda mejor con algunas aplicaciones, hacen que piense que al fin, han dado con la tecla para desbancar al otro producto de la misma factoría.

Taller C/C++. CMake (Olvidando el Makefile manual) Parte 2

Bueno, para completar el asunto de CMake he de terminar diciendo como se usa. Saber hacer un CMakeLists.txt no vale para nada si no se sabe como ha de usarse.

En el terminal, dentro de la carpeta del proyecto, en el caso de un CMakeLists.txt que contenga instrucciones de instalación, habría que hacer:

~$ mkdir build
~$ cd build
~$ cmake ..
~$ make
~$ make install

Hay que considerar que a cmake se le puede llamar con opciones, así que la sintaxis exacta sería:

cmake [opciones] ruta

En el caso de que nuestro CMakeLists.txt sea simple, podemos hacer directamente una llamada de la siguiente forma:

~$ cmake .
~$ make all

 Yo suelo hacer uso de esta última, ya que no es habitual que en un proyecto personal se quiera hacer una instalación. Espero que os sirva de ayuda.

Taller C/C++. CMake (Olvidando el Makefile manual)

Poco a poco hemos ido desde lo más sencillo a lo más complejo en lo que a programación en C/C++ respecta dentro de GNU/Linux. Ahora llega el momento de hablar de herramientas potentes que valen para generar ficheros de configuración, paquetes y lo que nos interesa ahora mismo, ficheros Makefile de forma "automática". Realmente seguirás necesitando especificar de una manera u otra algunos de los contenidos del fichero. Por ello yo soy más partidario de crear mi propio Makefile a mano, con el que tener un control total de lo que pasa, pero para proyectos de gran tamaño en los que hay varias versiones (una release y otra debug) puede ayudar.

Existen varías opciones para llevar a cabo estas tareas, me centraré en Autotools (automake), Cmake, y qmake (para proyectos que usen QT). Los IDE de desarrollo más avanzados ya integran estas herramientas, e incluso existen algunas interfaces gráficas que ayudan a la generación del Makefile como son la GUI de Cmake o el imake, pero que no trataré en el taller pero es bueno que sepais de su existencia.

CMake

Lo primero de todo instalar CMake: ~$ sudo apt-get install cmake

Al igual que el fichero Makefile que generamos a mano anteriormente (y del cual ahora hay que olvidarse), debemos crear un fichero llamado CMakeLists.txt dentro del directorio donde se encuentra nuestro software.

El CMakeLists.txt no sirve para generar únicamente un Makefile, así que me ceñire a una sintaxis simple y más que suficiente:

#Nombra al proyecto con el nombre bloguero, gracias a esto se definen 2 variables que pueden usarse dentro del CMakeList.txt mas adelante, ${BLOGUERO_SOURCE_DIR} directorio del codigo fuente, y ${BLOGUERO_BINARY_DIR} directorio donde se encuentran los compilados.
PROJECT(bloguero)

#Indica que vesión mínima de cmake se necesita. Si no se indica puede dar warnings.
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)

#Añade el directorio ./src a la lista de directorios que compone el proyecto. Se pueden añadir tantos directorios como se necesiten, repitiendo esta línea y poniendo el nombre. Dentro del directorio, en este caso src debe existir otro fichero CMakeLists.txt
ADD_SUBDIRECTORY(src)

#Define una variable NOMBRE_EJECUTABLE dentro de la cuál se almacena el nombre de nuestro programa, bloguero
SET(NOMBRE_EJECUTABLE bloguero)

#Define para el compilador, en este caso opciones de compilación
ADD_DEFINITIONS( "-Wall -O2 -ansi -pedantic" )

#Para buscar una librería que pueda necesitarse en la compilación o en el CMakeLists.txt . En NAMES se indica el nombre la librería,y en PATHS las rutas donde debe buscar. LIB_SERIAL será una variable que se creará con el resultado de la búsqueda.Al igual que existe un FIND_LIBRARY también existe un FIND_PROGRAM para buscar librerías, que sigue la misma sintaxis
FIND_LIBRARY(LIB_SERIAL
             NAMES libserial
             PATHS /usr/lib
           /usr/local/lib)
                 
#Si no se encontró la librería se muestra un mensaje de error. Hay varios tipos de mensajes, como STATUS y varios tipos de condiciones para el IF, NO
IF(LIB_SERIAL)
    #Añade la librería para el enlazado
    TARGET_LINK_LIBRARIES(bloguero LIB_SERIAL)
ELSE(LIB_SERIAL)
    MESSAGE("imposible encontrar la libreria libserial")
ENDIF(LIB_SERIAL)

#Incluye directorios para los ficheros de cabecera en el proyecto
INCLUDE_DIRECTORIES(./cabeceras)
#Incluye directorios para buscar librerías en el proyecto
LINK_DIRECTORIES(./librerias)

#Indica el nombre del ejecutable contenido en NOMBRE_EJECUTABLE y los ficheros fuente que se usaran (fichero1.cpp,fichero2.cpp...) para la compilación. Si quisiéramos que en lugar de un ejecutable, compilará en forma de librería, se haría con la siguiente instrucción ADD_LIBRARY(bloguerolib SHARED fichero1.cpp fichero2.cpp) donde SHARED se puede sustituir por STATIC en función de si queremos una librería dinámica .a o estática .so
ADD_EXECUTABLE(${NOMBRE_EJECUTABLE} fichero1.cpp fichero2.cpp fichero3.cpp)

#Indica que el ejecutable cuyo nombre esta almacenado en la variable NOMBRE_EJECUTABLE requiere para enlazar la librería pthread (lpthread)
TARGET_LINK_LIBRARIES(${NOMBRE_EJECUTABLE} pthread)

#Instala el ejecutable bloguero que se encuentra en la carpeta raíz del proyecto en el directorio /usr/local/bin si quisieramos instalar una libreria, en destination sustituiríamos bin por lib y se instalaría en /usr/local/lib Como se puede observar, se indican también los permisos que tendra trás la instalación
INSTALL(FILES ./bloguero
        DESTINATION bin
        PERMISSIONS OWNER_READ OWNER_EXECUTE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE)

En este CMakeLists.txt me he explayado un poco, y he puesto cosas que no son necesarias en absoluto. He faltado un poco a la palabra de simple, pero ha sido para moestrar un poco la potencia. Un ejemplo super simple sería:

PROJECT( bloguero )
ADD_EXECUTABLE( bloguero main.cpp)

Un Ejemplo intermedio en complejidad:

PROJECT( bloguero )
SET(LIBSRC bloguerolib )
SET(SRC bloguero )
ADD_LIBRARY( bloguerolib SHARED ${LIBSRC} )
ADD_EXECUTABLE( bloguero ${SRC} )
TARGET_LINK_LIBRARIES( bloguero bloguerolib )

 En este se genera una librería dinámica .so y después se incluye para el enlazado para la generación del ejecutable.

Taller C/C++. Makefile

Bueno, creo que lo más simple ya queda claro, además de que es algo que se ha tratado en miles de páginas web con mayor o menor acierto.

Ahora vamos a pasar a algo más complejo que puede llegar a ser un infierno si  no se hace uso de un IDE de desarrollo.

Los ficheros Makefile:

Los ficheros Makefile son ficheros de texto que funcionan como scripts, a los que se llama cuando queremos compilar una aplicación sin tener que escribir toda la linea de texto que llama al compilador con todas sus opciones. Son muy útiles cuando nuestros programas van cogiendo cierta envergadura. Es facil olvidar la opción que mejor nos iba con gcc, o uno de los muchisimos ficheros que componen el proyecto.

Un ejemplo sencillo de Makefile puede ser simplemente escribir dentro de un fichero la linea con la que compilamos un proyecto. gcc -o ejecutable main.cpp
pero se puede llegar a compliar la cosa hasta puntos insospechados, con Makefiles que comprueban la existencia de las librerías que se usan dentro de nuestro código, la ruta de acceso, borrar el compilado anterior de tu programa, instalar el programa...

Para ayudar en la realización de un Makefile, explicaré uno creado por mí, y que cubre bastante bien las necesidades de un desarrollador medio:

#    @author Gabriel

#Definicion de constantes
NOMBRE = bloguero
VERSION = 0.1.5
AUTOR = Gabriel

FECHA = 10/11/2011
COMPILADOR = g++
OPCIONES = -g -Wall -O2
LIBRERIAS = -lm -lpthread
OBJETOS = utm.o poli.o bloguer.o
MAIN = main.cpp

#Genera todo el programa
all: escribe principal
   
escribe:
    @echo ;
    @echo VERSION: $(VERSION);
    @echo AUTHOR: $(AUTOR);
    @echo NAME:  $(NOMBRE);
    @echo ;

#Enlazado con las clases y generacion del ejecutable
principal: $(OBJETOS)
    $(COMPILADOR) -o $(NOMBRE) $(OPCIONES) $(MAIN) $(OBJETOS) $(LIBRERIAS)

#Realiza el compilado de las clases
$(OBJETOS) : %.o : %.cpp %.h
    $(COMPILADOR) -c $(BANDERAS) $< -o $@ 

Aquí se imprimen los datos del programador y del programa, además de realizar la compilación en 2 partes. Dado que esta escrito en castellano, creo que no será dificil de entender que es lo que hace, pero explicaré una parte concreta que puede ser la más liosa.

Al final del fichero se observa como se hace referencia a unos %.o %.cpp %.h En realidad, esto hace que se compilen los ficheros cuyos nombres correspondan a los que están en la lista OBJETOS, y cuyas extensiones sean .cpp .h

Este Makefile es para un proyecto de C++. La sección LIBRERIAS se indica para especificar que librerías se usan dentro de nuestro código fuente, en este caso las de matemáticas -lmath y las de posix -lpthread (necesarias para programar con hilos y que espero poder explicar en un futuro). Pero si en tu proyecto no se hace uso de ninguna librería, no es necesario indicar nada.

Si tu proyecto tiene algunos ficheros que solo tienen .cpp y no su correspondiente .h, tendría que añadirse a mano en la seccion principal, escrito trás $(MAIN). Si se observa detenidamente, con unas simples sustituciones se obtienen sentencias similares a:  

g++ -o -O2 bloguero main.cpp utm.o poli.o bloguer.o -lm -lpthread

Es posible insertar otras opciones, que hacen referencia a la localización de ficheros de cabecera .h que no se encuentran en el habitual /usr/local/include ¿Cómo lo hacemos? indicando lo siguiente: -I ruta_include Ejem. -I /opt/include

Por último mencionar la opción que ayuda al compilador (si somos estrictos al enlazador) a encontrar librerías que no se encuentran instaladas en el lugar por defecto: -L ruta_librería Ejem. -L /opt/lib

Para finalizar, decir que el fichro Makefile debe encontrarse en el mismo directorio donde están los fuentes de tu programa, y para ejecutarlo solo hay que escribir en el terminal: ~$ make  ó ~$make all

Taller C/C++. Compilación

No es mi intención la de enseñar C, pero si ayudar a realizar las tareas más dificultosas de la programación cuando no eres experto.

Para compilar una aplicación que tengamos escrita en varios ficheros .c (de lenguaje C ) .cpp o .cc (de lenguaje C++) si tenemos un IDE de desarrollo es sencillo, pero pongamonos en lo peor y supongamos que nos encontramos con un entorno solo texto o usamos un editor tipo nano, vi...

Los procesos de la compilación son varios, y entre ellos se encuentra la de enlazado que inserta el código de librerías ya compiladas en nuestro código fuente. Este paso se realiza usando ld, pero en nuestro caso iremos por la vía facil para no liar al personal ya que gcc también lo hace.

Para obtener un ejecutable, en el terminal escribir:

~$ gcc -o nombre_ejecutable fichero_main.c fichero1.c fichero2.c ...

Esta linea realiza el compilado y el enlazado, dando como resultado un ejecutable llamado nombre_ejecutable. Ahora explicaré un poco las opciones que suelo usar para indicarle al compilador como debe generar el binario.

Opciones generales:

-o indica que se genere un fichero ejecutable.

-c indica que se genere solo el objeto compilado pero no enlazado.

-Wall indica que avise de todos los warning que puedan existir en el código, ya que estos warnings podrían dar errores en tiempo de ejecución.

-g indica al compilador que introduzca en el ejecutable todo lo necesario para poder ser depurado a posteriori con herramientas como gdb.

-pedantic -ansi indica al compilador que sea estricto en la compatibilidad con ANSI C

-petantic-errors indica al compilador que convierta los warnings que pueden causar error en ejecución en errores estrictos de código.

Opciones de optimización:

-Ox siendo x=0,1,2,3 Ejem sintaxis: ~$ g++ -o -O2 ejecutame main.cpp

Indican con que grado se quiere que este optimizado el código en cuanto a velocidad de ejecución y espacio en memoria que debe ocupar. Mientras mayor sea el número mayor es la optimización y más se tarda en compilar (personalmente creo que merece la pena esperar a que termine de generar el compilado).

También existe otra opción para el gcc que mejora los tiempos de ejecución. 

-march=[core2 | corei7 | prescott | ... ] 

No recomiendo el uso de march, porque requiere un conocimiento exahustivo del procesador donde correra el ejecutable, amen de que recorta la portabilidad. En este caso soy mas partidario de hacer una buena programación sabiendo como se alojan los datos en memoría, uso de algoritmos del menor orden de complejidad posible, algoritmos adecuados...

Para saber mas opciones, siempre podeis acudir a man gcc o g++