Ejercicios resueltos de programación en simatic S7 (bomba de agua)

Hola de nuevo a todos.
Después de una larga temporada sin escribir, me he decidido volver a la carga con unos ejercicios resueltos de programación de autómatas programables Siemens. La razón es que tenía de realizar unas modificaciones en un programa de un autómata y para ello tuve que recordar viejos conocimientos. El material principal del que he dispuesto para el estudio ha sido un tutorial de programación que encontré en la red bastante interesante. Lo podéis encontrar aquí. En dicho tutorial aparecen una serie de ejemplos resueltos, sin embargo, al final del tutorial se pueden encontrar ejercicios interesantes que no incluyen la solución. Pero no os preocupéis porque vamos a incluirla aquí.
El primer ejercicio se puede encontrar en la página 119 y aunque es bastante sencillo, me ha parecido bien empezar por él. Se trata de una bomba de agua. El enunciado y la solución, a continuación.
BOMBA DE AGUA
Las entradas del autómata  y los símbolos asignados son:

• Servicio ON/OFF: E0.0 (ON)
• Sensor de máximo: E0.1 (sensorMax)
• Sensor de mínimo: E0.2 (sensorMin)
• Una entrada adicional para simular el térmico: E0.3 (entradaTermico)

Las salidas del autómata son:

• Electrobomba: E4.0 (electrobomba)
• Servicio dispuesto: E5.0 (pilotoDispuesto)
• Saltó térmico: E5.1 (termico)

Centrándonos en las salidas, vamos a determinar las condiciones de activación y desactivación de cada una de ellas:
1.- Electrobomba: 

Condiciones de activación son:

• Que esté encendido el sensor de mínimo.
• Que el servicio esté en ON.
• Que esté apagado el sensor de máximo.
• Que no haya saltado el térmico.

Se deben cumplir todas estas condiciones (Y lógica) para que se produzca la activación.

Las condiciones de desactivación son: 

• Térmico encendido
• Que el servicio esté en OFF.
• Que esté encendido el sensor de máximo.

Cualquiera de estas condiciones (O lógica) produce la desactivación.

Así que el código asociado en step 7 sería:

//CONDICIONES DE SET

      U     sensorMin

      U     ON

      UN    sensorMax

      UN    termico

      S     electrobomba

//CONDICIONES DE RESET

      O     entradaTermico

      ON    ON

      O     sensorMax

      R     electrobomba

2.- Piloto servicio dispuesto:
Según el enunciado, este piloto debe estar encendido siempre que la electrobomba esté en funcionamiento, así que el código es:
U electrobomba
=pilotoDispuesto

3.- Piloto saltó térmico:
Este piloto estará encendido cuando el térmico (que es la entrada añadida E0.3) lo esté, así que:
U entradaTermico
=termico

Y esto es todo por hoy. Más adelante continuaremos resolviendo el resto de ejercicios.

Caja registradora en Java con base de datos Access utilizando el IDE Netbeans

Después de prácticamente 2 meses sin publicar absolutamente nada os quiero hacer llegar este trabajo de un curso de programación Java que he estado realizando (de ahí mi baja frecuencia de publicación). Se basa en un programa que hace las veces de caja registradora moderna y que permite guardar datos de información de clientes y de pedidos en una base de datos Access. A continuación se muestra una memoria explicativa.

1.     Diseño de la base de datos

El objetivo es crear una aplicación que permita de información relacionada con los pedidos que en una compañía de comida rápida se hacen. Debe permitir la opción de registrar clientes y que estos tengan descuentos. Para el diseño de la base de datos hay que determinar primero cuáles serán las entidades y los atributos asociados a dichas entidades. Se han considerado como entidades los Clientes, los Pedidos y los Productos. Cada uno de ellos debe tener unos atributos, que representan la información sobre dichas entidades. Los atributos que se almacenan de cada entidad son:

·         Entidad Cliente: NIF, Nombre, PrimerApellido y SegundoApellido.

·         Entidad Pedidos: NúmeroPedido, Fecha e Importe.

·         Entidad Productos: NúmeroProducto, Precio y NombreProducto.

Decididas las entidades y atributos asociados, es necesario determinar los atributos claves, aquellos que no se repiten y no pueden estar vacíos. Se han elegido los siguientes:

·         Entidad Cliente: NIF.

·         Entidad Pedidos: NúmeroPedido.

·         EntidadProductos: NúmeroProducto. En este atributo clave hay que aclarar que aunque se vayan a servir productos iguales, no se estarán sirviendo los mismos productos. Es decir, si un cliente pide un capuccino, eso será un producto, y si justo después otro cliente pide de nuevo capuccino, está pidiendo otro capuccino nuevo, no el mismo que se entregó al cliente anterior, por lo que nunca habrá dos capuccinos con el mismo NúmeroProducto.

Llegados a este punto es hora de determinar las relaciones entre entidades. Se han considerado las siguientes:

·         Un Cliente realiza Pedidos, de forma que las entidades Cliente y Pedidos se relacionan y tienen una relación uno a muchos, ya que un cliente puede realizar muchos pedidos, pero un determinado pedido es realizado por un solo cliente.

·         Un Pedido estará formado por uno o varios Productos, teniéndose así una relación uno a muchos, ya que un Pedido puede tener varios Productos, pero cada Producto (NúmeroProducto) pertenece a un solo pedido.

Por último queda por determinar las claves foráneas, traspasando así el atributo clave de una entidad a otra, existiendo así elementos de unión entre entidades relacionadas. Las claves foráneas que se han determinado son:

·         Entidad Cliente: Ninguna.

·         Entidad Pedidos: NIF (procedente de la entidad Cliente).

·         Entidad Productos: NúmeroPedido (procedente de la entidad Pedidos).

Con toda esta información recabada, ya es posible generar el modelo E-R de forma gráfica, que se muestra en la imagen a continuación:

Modelo ER de la base de datos

2.     Diseño de la interfaz

Para el diseño de la interfaz se ha optado por buscar la simplicidad y facilidad de uso, tratando de crear un sistema Poka-Yoke que evite errores en la lectura-introducción de datos por parte del usuario de la aplicación.

Toda la aplicación parte de una ventana principal sobre la que aparecen-desaparecen paneles según se vaya indicando. Al arrancar el programa principal aparecerá esta ventana principal, que tiene el siguiente aspecto:

Aspecto de la ventana principal

En ella se puede observar lo que podría ser el logotipo de la compañía (evidentemente se ha escogido uno cualquiera), un título y un menú en la parte superior que permite acceder a todas las funcionalidades del programa.

Clicando en la opción Cliente podemos acceder al alta, baja y modificación de clientes. Las ventanas se muestran a continuación respectivamente:

Aspecto de la ventana AltaCliente

Aspecto de la ventana BajaCliente

Aspecto de la ventana ModificarCliente

Todas ellas están formadas por etiquetas, cajas de texto sobre las que introducir la información y botones que captarán eventos para ejecutar acciones.

Desde el menú Pedidos se puede acceder a las opciones Nuevo pedido, Fecha pedidos, Pedidos de clientes, cuyos nombres resultan autoexplicativos. Los aspectos de dichas ventanas son:

Apecto de la ventana AltaPedido

Esta es la parte de la interfaz más recargada. En la parte superior izquierda aparecen las etiquetas y cajas de texto que permiten introducir la fecha actual (en un programa real debiera captarlo automáticamente) e introducir el NIF de un cliente si está registrado, o bien realizar el pedido como un cliente no registrado. Debajo de estas opciones se encuentran los diferentes productos que componen el menú, cada uno de ellos con un botón que permite añadir al pedido el producto. En la parte derecha se muestra una tabla sobre la que irán apareciendo los productos que un cliente solicita, una opción de eliminar algún tipo de producto en caso de introducción por error y por último una caja de texto que muestra el importe total y el botón para imprimir o realizar el pago del pedido.

Aspecto de la ventana FechaPedidos

Esta es una ventana simple sobre la que introducir la fecha sobre la cuál queremos ver los pedidos realizados.

Aspecto de la ventana PedidosCliente

Muy similar a la anterior, esta ventana permite introducir el NIF del cliente sobre el que queremos ver los pedidos que ha solicitado.

3.     Diseño de la arquitectura de programación

Para la realización del programa se han generado los siguientes paquetes:

·         fastfoodcompany.principal: Contiene Aplicación y FastFoodCompany. Aplicación simplemente se encarga de cargar y visualizar la ventana principal, que está diseñada en FastFoodCompany.

·         fastfoodcompany.principal.acciones: Contiene la clase AccionesFastFoodCompany que se encarga de atender a los eventos que ocurran en la ventana FastFoodCompany y realizar las acciones necesarias.

·         fastfood.clientes: Contiene AltaCliente, BajaCliente y ModificarCliente que son las clases con los JPanel (paneles) vistos en las figuras 3, 4 y 5.

·         fastfood.clientes.acciones: Contiene las clases AccionesAltaCliente, AccionesBajaCliente y AccionesModificarCliente que, al igual que hace AccionesFastFoodCompany, se encarga de atender a los eventos que ocurran en las ventanas (que serán originados por el usuario) y ejecutar las respuestas.

·         fastfood.pedidos:Contiene AltaPedido, FechaPedidos y PedidosCliente.

·         fastfood.pedidos.acciones: Con AccionesAltaPedido, AccionesFechaPedidos y AccionesPedidosCliente.

·         fastfood.gestionBD: Contiene ServiceCliente, GestionSQLClientes, ServicePedidos y GestionSQLPedidos. Las clases GestionSQLXXX se encargan de gestionar la conexión con la base de datos, mientras que las clases ServiceXXX se encarga de generar las consultas SQL correspondientes que luego serán solicitadas desde GestionSQLXXX. Las clases XXXCliente se encargan de todo lo relacionado con el alta, baja y modificación de clientes, mientras que XXXPedidos gestionan lo relacionado con los pedidos.

Se ha desarrollado por tanto una arquitectura Model-View-Controller, donde:

• View: FastFoodCompany, AltaCliente, BajaCliente, ModificarCliente, AltaPedido, FechaPedidos y PedidosCliente.
• Model: AccionesFastFoodCompany, AccionesAltaCliente, AccionesBajaCliente, AccionesModificarCliente, AccionesAltaPedido, AccionesFechaPedidos, AccionesPedidosCliente, ServiceClientes y ServicePedidos.
• Controller: GestionSQLClientes, GestionSQLPedidos.

4.     Manual de usuario interactivo

Véase:

Manual usuario interactivo

5.     Código fuente de la aplicación

Lo podéis descargar aquí

Impresiones con un móvil chino (BEDOVE X21)

Para los que hayáis leído mi blog, sabréis de sobra que me gusta bastante realizar compras en dealextreme. Son ya muchas las veces que he realizado compras en dicha tienda, aunque bien es cierto que habían sido cosas de poco valor. Alguna vez había mirado productos tales como tablets o móviles, pero, o bien no los había necesitado, o bien no me había atrevido a comprar ninguno. Sin embargo, el deterioro de un samsung galaxy europa me hizo replantearme la posibilidad de adquirir un móvil "chino". En mi caso, quería que cumpliera una serie de requisitos:

- Que fuera completamente libre. Desde hace un tiempo he dado un salto a una OMV (de esto hablaré en otra ocasión) y no estoy sujeto a ningún compromiso de permanencia, así que si algún día me apetece cambiar de operadora, necesito un móvil libre que no lleve asociado ningún contrato de permanencia.

- Pantalla grande: La pantalla del samsung galaxy europa era de 2.8", y lo cierto es que mis gordos dedos se desenvolvían bastante mal en ella.

- Android: El más extendido, quería una versión no más antigua que la 4.0.

Después de una búsqueda de móviles en España, comprobé como los precios de un smartphone que cumpliera con mis deseos se dispararía en precio, así que empecé a buscar proveedores más baratos, tales como ebay, focalprice... aunque finalmente me decanté por dealextreme y su Bedove X21 que podéis encontrar en negro y en blanco.

Las razones para decantarme por él fueron las características, el precio y, sobre todo, los comentarios (reviews). Las características son:

• Pantalla táctil capacitiva (5 puntos) IPS de 4.5 pulgadas y una resolución de 854 x 480 píxeles.
• Sistema operativo: Android 4.0.9.
• CPU: Media Tek MTK6577 doble núcleo a 1 GHz.
• GPU PowerVR SGX531.
• Memoria interna (ROM): 4 GB.
• Memoria RAM: 512 MB.
• Batería: 2 baterías de 2200 mAh Li-ion
• y: 2200mAh Li-ion 
• Frecuencias de red: GSM 850/900/1800/1900MHz WCDMA 850/2100MHz
• Doble SIM, dual standby.
• Cámara frontal 1.3 MP, cámara trasera 8.0 MP.
• WIFI, GPS, MP3, MP4, Bluetooth, Radio FM...

El precio actual ronda los 115 euros, si bien y lo compré por algo menos de 110.

Lo más destacado en los comentarios son:

• Positivos: El tamaño de la pantalla, la calidad de ésta y el rendimiento general del teléfono.
• Negativos: La recepción WIFI, la calidad de la cámara y el GPS.

Con esta información me decidí a comprarlo y, tras casi un mes probándolo, os quiero hacer saber cuáles son mis impresiones.

• Unpacking (desempaquetado): Mi primera impresión fue realmente buena, nada más abrir la caja puedes observar detalles que no encuentras en un móvil "no chino", como son el traer dos baterías, dos protectores de pantalla, una funda y, por supuesto, unos auriculares con micrófono. 
• Calidad de los materiales: Por un lado nos encontramos con unos auiculares, cargador y cable de conexión USB aparentemente de baja calidad. No ocurre así con el teléfono en sí, que si bien es algo plasticoso, es bastante resistente (ha sufrido ya bastantes caídas y no he tenido ningún tipo de problema hasta ahora).
• Funcionamiento del software/rendimiento: El arranque del sistema operativo es bastante rápido. Una vez arrancado el funcionamiento es fluido, sin lag (retardos), aunque ciertamente yo no soy un jugón y no le he exigido mucho. Sí que he notado una gran velocidad instalando aplicaciones o ejecutando varias aplicaciones al mismo tiempo. La multitarea es bastante buena. El android no trae ningún tipo de modificación o capa como pueda ocurrir con los Samsung o los HTC y trae soporte para muchos lenguajes, entre ellos el español (nada de letras chinas ni cosas por el estilo).
• Pantalla: Sin duda el punto fuerte del teléfono. Con 4.5 pulgadas, mucha luminosidad y gran ángulo de visión (recuerdo que es una pantalla IPS). Aunque la resolución no es excesivamente alta (854 x 480) no se aprecia el pixelado ni nada por el estilo (puede que yo no sea muy exigente en tal sentido).
• Cámara: En este punto mi opinión puede no ser una buena referencia, ya que nunca he sido muy exigente con las fotografías. Mi impresión es que las fotografías que se consiguen son buenas, aunque un flash bastante poco potente provoca que en condiciones de poca luz sólo objetos que se encuentran cercanos se vean bien. Olvida fotografiar algún objeto lejano en condiciones de poca luz. 
• Duración de la batería: Éste era uno de los puntos que más me preocupaba, ya que había oído hablar de smartphones chinos que tenían una duración muy escasa, que la batería drenaba y hay algún otro comentario como "si trae dos baterías por algo será". Mi opinión es que es una batería más que aceptable, teniendo en cuenta que hablamos de smartphones. Suelo hacer un uso medio-intenso y me aguanta el día sin problemas. Además, al disponer de dos baterías, puedes cargar una mientras la otra se encuentra en funcionamiento y así eliminas el engorro de tener que conectar el teléfono. Un punto negativo que sí quiero resaltar es el tiempo de carga de la batería, que puede incluso alcanzar más de 8 horas para una carga completa, un valor que creo que está muy por encima de la media.
• Conectividad: Con respecto a la recepción WIFI difiero bastante de los comentarios que indican que la recepción es pobre. Consigo el mismo alcance que pueda tener con un ordenador y además la velocidad de la conexión es bastante buena. El funcionamiento del bluetooth es correcto, aunque sólo lo utilizo para el manos libres del coche, no he realizado ninguna otra prueba. Y donde sí que estoy totalmente de acuerdo con algunos comentarios es que el GPS es bastante malo, puede tardar varios minutos en conectar y cuando lo hace hay veces que tiene error de muchos metros que para realizar navegación puede dar problemas. La conexión WCDMA (datos móviles) funciona a la perfección. 

Como conclusión decir que estoy muy contento en general ya que lo primero que busco en un smartphone es que tenga un buen rendimiento (y el de éste lo es). Un mejor receptor GPS sería ideal. Veré qué tal resulta cuando pase más tiempo, pero sin duda mi impresión hasta ahora es bastante buena.

¿Cursando Fundamentos de programación en la UNED? Tengo un regalo para tí. Parte 3 y última

Pues después de mucho batallar y gracias a la inestimable ayuda de compañeros que me han resuelto dudas en el foro y de otra persona que sabrá perfectamente quién es cuando lo lea, he conseguido terminar esta última práctica. Como buen español, dejándolo para el final. Espero que, aunque sea bastante tarde os sirva. Estoy bastante cansado, así que, sin más, cuelgo el enlace
Práctica 4

Borrador práctica 4 de fundamentos de programación

Hola a tod@s. Como muchos de los que habéis seguido este blog sabréis, he ido incluyendo aquí los resultados de las prácticas de fundamentos de programación. Antes de incluirlas, siempre me había cerciorado bien de que estuviesen correctas (aunque no optimizadas). Sin embargo, debido al gran retraso que llevo con esta 4º y última, y tras dedicarle bastante tiempo sin obtener ningún resultado satisfactorio, he decidido colocar un borrador de mi estado actual. Lo comento aquí y luego añado el código.

La idea es tener un programa principal que se ejecuta continuamente hasta que se pulsa la opción salir. Para la gestión de las reservas utilizo tipos de datos definidos. Un tipo de datos denominado "TipoReserva" que contiene la "sala" (tipo int), la "fecha" (otro tipo definido formado por 3 tipos int) y el nombre de la "persona" que la realiza. Como podemos realizar hasta 100 reservas, pues creo he creado un tipo de datos llamado "TipoVectorReservas" que simplemente consta de 100 "TipoReserva". Cuando quiero introducir una reserva, hago que la información (previamente comprobada) se almacene en ese vector. Si quiero eliminar una reserva, leo los datos de la reserva a eliminar y la elimino de ese "vectorReservas". Por último, si quiero listar las reservas de un determinado mes, leo los datos necesarios y los paso como argumento a una función llamada ImprimirCalendario. Hubo momentos en los que he conseguido compilar el código y comprobé que obtenía resultados, no los esperados, pero resultados. Sin embargo debí hacer alguna modificación y desde entonces soy incapaz. 

Siento no haber podido colgarla ya funcionando correctamente. De cualquier forma espero que os pueda servir.
Borrador de la práctica
Actualización: He estado modificando y tratando de limpiar el código y creo que el nuevo borrador que tengo parece mejor, aunque sigo obteniendo errores de compilación que no consigo resolver. Podéis encontrarlo aquí
Borrador 1 de la práctica

El coche con control remoto usando Arduino ya está aquí

Ya he hablado de diferentes elementos y cómo utilizarlos con nuestro Arduino. Experimentos con un sensor de distancias, con un receptor de infrarrojos para la comunicación, arranque, parada e inversión de giro en motores... Todo ello destinado a utilizarlos en el coche que hoy os muestro. Ha sido una larga espera hasta tener a disposición todos los elementos necesarios (ya que la gran mayoría proceden de China), sin embargo, el montaje y programación han resultado sencillos. Ahora que tengo un mejor conocimiento de Arduino, puedo decir que me ha impresionado su sencillez, gracias en buena parte al gran trabajo de la gran comunidad que tiene detrás y que proporciona librerías, documenta proyectos... Y hubiese sido más sencillo y rápido la construcción de éste coche de haberme percatado antes de los problemas que provocaban un funcionamiento incorrecto, ésto es, el ruido generado por los motores y la utilización de una sola fuente de alimentación para el circuito.

El aspecto final del coche se muestra a continuación

Aspecto final del coche con control remoto

En la siguiente imagen podéis apreciar también el mando que utilizo para controlarlo

Conjunto de mando a distancia y coche

Por último mostraros una vista más detallada del frontal del vehículo, en el que se puede apreciar el servo sobre el cuál reside el sensor de distancia

Parte frontal del coche en la que se encuentra el servo y el sensor de distancias

Y una última que muestra las conexiones de la placa de prototipos

Placa de prototipos con las conexiones realizadas

El funcionamiento es el siguiente:

Con el mando a distancia podemos enviar diferentes señales en función del botón pulsado. Estas señales son leídas utilizando el receptor de infrarrojos e interpretadas por Arduino, para realizar la acción oportuna. Las diferentes acciones son (por ahora), avance recto, avance recto lento, giro a derechas y giro a izquierdas. Esto se consigue controlando individualmente la velocidad de cada uno de los motores (mediante PWM). Al mismo tiempo, cuando el vehículo se encuentra en movimiento, el sensor de distancia chequea si hay algún objeto cercano, en cuyo caso, para evitar la colisión, se procede a tomar la decisión de modificar el sentido de avance del coche. Como el sensor de distancias "ve" a los objetos que tiene justamente enfrente (tiene un ángulo de visión pequeño), se ha optado por colocarlo encima de un servo que permita girarlo, haciendo un barrido en función del sentido del movimiento del coche. Todas estas acciones se pueden ver en el vídeo a continuación

El código utilizado para lograr todo esto es:

/*Proyecto ArduinoCar utiliza un mando a distancia convencional para 

controlar remotamente un coche a escala con Arduino. Para el movimiento

del coche se utilizan motores independientes en la rueda izquierda (control

de la rueda conectado al pin 5) y la rueda derecha (control conectado al 6)

*/

//Libreria para comunicacion por infrarrojos

#include <NECIRrcv.h>

//Libreria para el sensor de distancias

#include <Ultrasonic.h>

//Libreria para el servo

#include <Servo.h>

//Pin al que se conecta el receptor infrarrojos

#define IRPIN 7

//Codigos del mando a distancia

#define OFF 3877142272

#define ON 4278222592

#define UNO 3893853952

#define DOS 3910565632

#define TRES 3927277312

//Inicializacion del sensor de ultrasonidos (trigger, echo)

Ultrasonic ultrasonic (8,9);

//Inicializacion del receptor infrarrojos

NECIRrcv ir(IRPIN);

//Inicializacion del servo

Servo servo;

//Variables globales a utilizar

unsigned long ircode;

unsigned long codigo;

//Setup inicial

void setup() {

  ir.begin() ;

  pinMode(5,OUTPUT);

  pinMode(6,OUTPUT);

  //Control del servo conectado al pin 13

  servo.attach(13);

  servo.write(90);

}

//Bucle que se ejecutara continuamente

void loop() {

  //Si hay datos recibidos desde el control remoto, los capturamos

  while (ir.available()) {

    ircode = ir.read();

    //Dependiendo del boton pulsado realizamos una determinada accion

    switch (ircode){

    case OFF:

    //Paramos el coche

    codigo=OFF;

    digitalWrite(5,LOW);

    digitalWrite(6,LOW);

    //El servo apunta al frente

    servo.write(90);

    break;

    case ON:

    codigo=ON;

    //El coche avanza recto

    digitalWrite(5,HIGH);

    digitalWrite(6,HIGH);

    servo.write(90);

    break;

    case UNO:

    //El coche tuerce a la izquierda

    codigo=UNO;

    analogWrite(5,160);

    digitalWrite(6,HIGH);

    //El servo apunta a la izquierda

    servo.write(150);

    break;

    case DOS:

    //El coche avanza recto a menor velocidad

    codigo=DOS;

    analogWrite(5,200);

    analogWrite(6,200);

    servo.write(90);

    break;

    case TRES:

    //El coche tuerce hacia la derecha

    codigo=TRES;

    analogWrite(6,160);

    digitalWrite(5,HIGH);

    //El servo apunta a la derecha

    servo.write(30);

    break;

    }

  }

  //Si detecta algun obstaculo a menos de 20 centimetros

  if (((ultrasonic.Ranging(CM))<=20) && (codigo!=OFF)){

    if (codigo==UNO){

      //Si el coche estaba torciendo hacia la izquierda, comienza a girar a la derecha

      digitalWrite(5,HIGH);

      digitalWrite(6,LOW);

      delay(200);

      //Devuelve el estado que tuviese

      analogWrite(5,160);

      digitalWrite(6,HIGH);

    }else if (codigo==TRES){

      //Si el coche estaba torciendo hacia la derecha, comienza a girar a la izquierda

      digitalWrite(5,LOW);

      digitalWrite(6,HIGH);

      delay(200);

      analogWrite(6,160);

      digitalWrite(5,HIGH);

    }else if (ircode==ON || ircode==DOS){

      //Si el coche avanzaba recto, realiza un giro mayor

      digitalWrite(5,LOW);

      digitalWrite(6,HIGH);

      delay(400);

      if (ircode==ON){

        digitalWrite(5,HIGH);

        digitalWrite(6,HIGH);

      }else {

        analogWrite(5,200);

        analogWrite(6,200);

      }

    }

  }

}

Por último comentar que tengo previsto introducir varias mejoras, alguna de ellas creo que bastante interesantes. La primera de ellas pasa por incluir la posibilidad de inversión de giro (aún no disponible debido a falta de componentes), la segunda consiste en añadir otro tipo de comunicación remota, bien por bluetooth o bien por radiofrecuencia, ya que la comunicación infrarroja tiene bastantes limitaciones y un último proyecto en el que Arduino utiliza sistema GPS para realizar un trazado de forma autónoma. Os mantendré informados...

Ubuntu para smartphones próximamente

Con algo de retraso os hago llegar (si es que no lo sabíais) ésta noticia que tan interesante me ha resultado. Ubuntu está trabajando en llevar su sistema operativo a los teléfonos inteligentes (smartphones). 

Aspecto visual de Ubuntu phone OS

Ya habíamos visto a Ubuntu for Android, que utilizaba un dock para correr la versión de escritorio de Ubuntu en nuestro Android. Ahora van un paso más allá y crean un sistema operativo dedicado a smartphone, en el que los gestos son la clave para acceder a todo lo que deseemos. 

En el siguiente vídeo podéis ver una demo de Ubuntu phone OS

Y en éste podéis ver la presentación de Mark Shuttleworth (inglés)

La noticia de Ubuntu for phones me parece sorprendente, ya que supondría poder tener una misma plataforma para televisión, ordenador, servidor, tablet y smartphone, algo hasta ahora nunca visto.

Mi opinión personal sobre Ubuntu es que está evolucionando a un ritmo muy bueno, aunque las últimas versiones resultaban pesadas para mi pequeño netbook, por lo que decidí pasar a Lubuntu. Sin embargo, leyendo en la wiki de ubuntu respecto a Nexus 7, parece que tienen previsto revisar el núcleo para hacer Ubuntu más rápido, ligero y con un menor consumo de recursos. BRAVO. Creo que esto podría ser un punto clave para hacer un buen sistema operativo para smartphones, aunque también necesitarán desarrolladores y fabricantes que cooperen. La tarea se antoja difícil, pero yo ya me estoy imaginando lo que puede suponer tener un smartphone con Ubuntu, sería tener un ordenador en la palma de mi mano.