martes, 14 de junio de 2011

Skype llega a la TV por cable

Skype llega a la TV por cable: "La compañía de televisión por cable estadounidense Comcast, anunció que en breve permitirá realizar videoconferencias en los televisores vía Skype.



Los televisores inteligentes con Wi-Fi y aplicaciones ya se ofrecen en el mercado, en las gamas más altas de marcas como Samsung, permitiendo interactuar con la red para ver videos, navegar e inclusive realizar videollamadas a través de Skype, adquiriendo una cámara opcional que las mismas compañías venden.



Pero Comcast, una de las compañías de televisión por cable e Internet más grandes de Estados Unidos acaba de anunciar que muy pronto ofrecerá el servicio de videollamada de Skype a todos sus clientes, para que a través de sus televisores puedan realizar videollamadas en alta definición.






Con esta unión, los clientes de esta compañía no necesitarán un Smart TV, sino que con el dispositivo que ofrece la operadora y una cámara web podrán acceder a este servicio, que facilita cada día más las videollamadas sin necesitar una computadora.



El servicio entraría en pruebas en los próximos meses con el objetivo de ofrecerlo a sus clientes antes de fin de año. De ser exitoso, otras compañías seguirán sus pasos.



Skype es el sistema de VOIP y videollamadas más exitoso del mundo, con más de 600 millones de usuarios registrados, que fuera adquirido por Microsoft a inicios de 2011.




"

C# y Tiny 6410

Hola a todos, en esta ocasión les mostrare como realizar una comunicación serial, entre un Pc Portátil, y un sistema embebido, primero que todo lo que se ha realizado es cambiar el sistema operativo de el dispositivo.
el sistema embebido (Tiny 6410), el cual posee un procesador ARM11 de la empresa samsung, el cual tiene como referencia S3C6410, donde a continuación les dejo las especificaciones técnicas:










Specification 

  • Dimension: 110 x 110 mm
  • CPU: 533 MHz S3C6410A ARM1176JZF-S (max freq. 667 MHz)
  • RAM: 256 MB DDR RAM, 32 bit Bus
  • Flash: 2GB MLC Flash
  • EEPROM: 1024 Byte (I2C)
  • Ext. Memory: SD-Card socket
  • Serial Ports: 3x DB9 connector (RS232), total: 4x serial port connectors
  • IR: Infrared Receiver
  • USB: 3x USB-A Host, 1x miniUSB Slave-OTG 2.0
  • Audio Output: 3.5 mm stereo jack
  • Audio Input: Condenser microphone
  • Ethernet: RJ-45 10/100M (DM9000)
  • RTC: Real Time Clock with battery
  • Beeper: PWM buzzer
  • TV Output: CVBS
  • LCD Interface
    • STN Displays:
      • Monochrome, 4 gray levels, 16 gray levels, 256 colors, 4096 colors
      • Max: 1024x768
    • TFT Displays:
      • Monochrome, 4 gray levels, 16 gray levels, 256 colors, 64k colors, true color
      • Max: 1024x768
    • 40 pin (2.0 mm) and 41 pin connector for FriendlyARM Displays (4.3" and 7")
  • Touch Panel: 4 wire resistive
  • User Inputs: 8x push buttons and 1x A/D pot
  • User Outputs: 4x LEDs
  • Expansion: 40 pin System Bus, 30 pin GPIO, 20 pin SDIO (SD, SPI, I2C), 10 pin Buttons (2.0 mm)
  • Debug: 10 pin JTAG (2.0 mm)
  • Power: 5V connector, power switch and LED
  • Power Supply: regulated 5V (Mini6410: 0.25 A, Mini6410 + 4.3" LCD: 0.5 A)
  • OS Support
    • Windows CE 6
    • Linux 2.6
    • Android
    • Ubuntu

este dispositivo viene de fabrica, con el sistema operativo Qtopia, ahora lo que se realizo es cambiar ese sistema operativo por windows CE 6.

con este sistema operativo instalado, ahora solo nos queda es realizar las aplicaciones para poder controlar los diferentes componentes que se encuentra en dicha tarjeta, como son:

  • Leds
  • Puerto Serie
  • Memoria I2C
  • Sensor de Temperatura
  • ADC
  • Comunicacion por infrarrojo
  • Camra Cmos
  • Pulsadores


el control de estos componentes presentes en el sistema embebido, lo haremos con lenguajes de alto nivel, que tenga la opción de poder crear aplicaciones para dispositivos móviles, pues como sabemos los procesadores ARM, son los cerebros de la mayoría de los dispositivos portátiles  como teléfonos móviles, mp3, mp4 etc.

para esto contamos con diferente programas para realizar esta aplicaciones, en tre los que tenemos, Visual estudio 2005 y labviw, en este caso en particular utilizaremos visual estudio 2005 y dentro de este paquete de programación cogeremos a C#, con el diseñaremos una aplicación para la realización de una comunicación serial entre el ARM y mi computador portátil.

Primero que todo realizaremos una interfaz en Visual C#, en mi caso ha quedado así:



la interfaz es simple, tiene un boton de abrir, el cual no abre el puerto serie, un boton de cerrar que cierra el puerto serie, una casilla de estado, en donde nos dice si el puerto esta cerrado o abiertos, un combobox, en el mostramos que puertos tiene disponible la tarjeta, para mi caso mi tarjeta tiene 5 puertos serie de los cuales utilizaremos el COM2 para esta aplicación, la interfaz también cuenta con una casilla de datos, en ella mostramos los datos que estamos recibiendo de nuestro transmisor y por ultimo un pucturebox en la cual muy pronto se hará una gráfica que provenga de algún dispositivo que envié datos por comunicación serial provenientes de algún sensor, como puede ser  un arduino, como un ejemplo.

no obstante visual estudio 2005 no es la unica forma de poder realizar interfaz gráficas para este tipo de dispositivos, por ejemplo labview tiene una sección de aplicaciones móviles que nos permite realizar interfaz muy interesantes, que próximamente estar mostrando.



Continuara...





lunes, 6 de junio de 2011

Por fin mi ARM

Estas son las fotos y u video de mi nuevo sistema EMBEBIDO, es como les mostré anterior mente, un ARM11, pronto esperen proyectos con el.





sábado, 4 de junio de 2011

Labview y google earth

Actualmente trabaja en este proyecto es un interfaz con labview, la cual puede ser enlazarda con google earth, esta aplicación se basa en una biblioteca "Google_Earth.llb" que se descargó de la Fuente siguientes:


Esta es la imagen de la interfaz:


La interfaz me muestra la latitud, longitud, velocidad, rumbo, y el gráfico de los ángulos, estos ángulos proviene de un acelerometro de 2 eje que se encuentra en la misma placa de circuito junto a una brújula electrónica, estos datos son enviados por xbee con una distancia de 1000 Mts a linea de vista, los datos que provienen de los sensores son adquiridos por  un arduino mega 1280, que se encarga de comunicarse con el Gps y la Brújula, este encapsula los datos en una trama  de bist que depues sera adquirida por labview y visualizando los datos.

El GPS de 50 canales D2523T receptor GPS helicoidales


la brújula es CMPS09



Todo esto va conectado a una plataforma robótica, que puede navegar con la ayuda de el Gps y el usuario podrá observar en google earth por donde esta el robot.

Esperar el articulo completo, con los vídeos de la plataforma.









Labview and google earth

Currently working on the next project is a labview interface with which you can enlazarce with google earth, this application is based on a library "Google_Earth.llb" which was downloaded from the following Source:


https://decibel.ni.com/content/docs/DOC-2117

This is the image of the interface:


The interface displays me the latitude, longitude, speed, course,and I graph the angles from accelerated uns meters and degreesfrom an electronic compass, they are sent by RS232 from a megaarduino, which is responsible for capturing data from the GPS andcompass.

The GPS 50 Channel GPS Receiver Helical D2523T


the compass is CMPS09



All this is hooked to a robotics platform, which you can browse forwireless communication with the help of the GPS and the user will see on google earth the location of the robot, is now working withXBee of 1500 Mts to line of sight, but future this will be replaced bymore powerful radio modem.










NASA

Mi nombre en un chip rumbo a marte, jejejejeje, eso dice el siguiente certificado de la nasa.

Según el laboratorio de propulsión a chorro, de la NASA, puedes llenar tus datos y tu nombre sera incluido en un chip, rumbo a MARTE.

Fill in your information below and your name will be included with others on a microchip on the Mars Science Laboratory rover heading to Mars in 2011!



Les dejo un enlace en vivo de la nasa al que creo yo que es la plataforma robotica mas versátil del universo fue creada para sortear terrenos irregulares.






miércoles, 1 de junio de 2011

Optimizing a mobile robot’s navigation performance

Optimizing a mobile robot’s navigation performance


Accuracy in managing position and motion is key to useful, reliable autonomous operation of mobile robots
Ground-based robots are typically used for missions where direct human involvement is too expensive, too dangerous, or just ineffective. Often, the robots must be able to operate autonomously, using navigation systems to monitor and control their motion when moving from one location to the next, and when accuracy in managing position and motion is key to useful, reliable autonomous operation.
MEMS (micro-electromechanical system) gyroscopes provide a feedback sensing mechanism that can be very useful in optimizing navigation system performance. The Seekur robot system (see Fig. 1) is an example of an autonomous system that employs advanced MEMS devices to improve navigation performance.

Fig. 1: The Seekur system developed by Adept MobileRobots (www.mobilerobots.com) is an autonomous systems employing advanced MEMS sensors.
A robot navigation overview
A robot’s movement typically starts with a position change request from the central processor managing the progress of the robot’s overall mission. The navigation system begins executing a position change request by developing a trip plan or trajectory.
The trip plan considers available paths, known obstacle locations, robot capability, and any relevant mission objectives. (For example, delivery time can be critical for a specimen delivery robot in a hospital.) The trip plan is fed into a controller, which produces drive and direction profiles for navigational control. These profiles result in motion and progress with respect to the plan. The motion is typically monitored by a number of sensing systems, each of which produces feedback signals; the feedback controller combines and translates them into updated trip plans and conditions.
The key steps in developing a navigation system start with a good understanding of each function, with particular emphasis on its operational goals and limitations. Each function typically has some clearly defined and easily executed aspects, but also offers challenging limitations that need to be managed. In some cases, this process can be iterative, where identifying and dealing with limitations enables new opportunities for optimization.
As an example, the Adept MobileRobots Seekur is an autonomous robot that has a four-wheel drive system, with independent steering and speed control for each wheel, to provide the flexibility to move the platform in any horizontal direction. It’s inertial navigation system (INS) is similar to the one shown in Fig. 2.

Fig. 2: The Seekur’s navigation system uses GPS, laser sensing, and MEMS gyros to independently control each of the system’s four wheels.
Forward control
As seen in Fig. 2, forward control is achieved by issuing robot-body commands These commands are essentially error signals derived from the difference between the trip plan provided by the trajectory planner and trip progress updates produced by the feedback sensing system.
The commands are fed into the inverse kinematics system, which translates the robot body commands into steering and velocity profiles for each individual wheel. These profiles are calculated using Ackermann steering relationships, which incorporate tire diameter, surface contact area, spacing, and other important geometrical features.
Ackermann steering principles and relationships enable these robot platforms to create electronically linked steering angle profiles similar to those of the mechanical rack-and-pinion systems used in many automotive steering systems. Incorporating these relationships remotely, without requiring the axles to be mechanically linked, helps minimize friction and tire slip, provides the benefits of reduced tire wear and energy loss, and allows motion not possible with simple mechanical linkages.
Feedback sensing and control
Each wheel has a drive shaft that is mechanically coupled to its drive motor through a gear box and—through another gear box — to an optical encoder, which is an input to the odometry feedback system. The steering shaft couples the axle to another servo motor, which establishes the wheel’s steering angle. The steering shaft also couples to a second optical encoder through a gear box — which provides another input to the odometry feedback system.
The navigation system uses an extended Kalman filter to estimate the pose of the robot on the map by combining data from multiple sensors. The odometry data on the Seekur is derived from the wheel traction and steering encoders — which provide the translation — and a MEMS gyro, which provides the rotation.
Odometry
The odometry feedback system estimates robot position, heading, and speed using optical-encoder measurements of drive- and steering shaft rotation. Figure 3 provides a graphical reference and relationship for translating the rotation count of the drive shaft’s optical encoder into linear displacement (position) changes.

Fig. 3: The odometry system determines linear displacement using encoder readings in accordance with the relationship shown above.
The drive-axle and steering-shaft encoder measurements for each wheel are combined in the forward-kinematics processor, using the Ackermann steering formulas, which produce heading, turn rate, position, and linear velocity measurements.
The advantage of this measurement system is that its sensing function is directly coupled to the drive and steering control systems, so their state is accurately known. However, its accuracy in terms of the actual speed and direction of the vehicle is limited unless reference to a set of real-world coordinates is available. The primary limitations, or error sources, are in the tire-geometry consistency (the accuracy and variation of diameter in Fig. 3) and breaks in the contact between the tire and the ground surface. Tire geometry is dependent on tread consistency, air pressure, temperature, and weight — all conditions that can change during normal robot use. Tire slip depends on turn radii, velocity, and surface consistency.
Position sensing
The Seekur system uses various range sensors. For indoor applications, it employs a 270° laser scanner to build a map of its environment. The laser system measures object shapes, sizes, and distance from the laser source using returned-energy patterns and signal-return times.
When in its mapping mode, it characterizes its workspace by combining scan results from many different positions in the workspace (see Fig. 4). This produces a map of object locations, sizes, and shapes, which is used as a reference for run-time scans.
When used in conjunction with the mapping information, the laser scanner function provides accurate position information. If used by itself, it would bear limitations that include the stop time for scans and an inability to manage a changing environment. In a warehouse environment, people, lift trucks, pallet jacks, and many other objects change position often, which could potentially impact speed to a destination and, indeed, accuracy of achieving the correct destination.

Fig. 4: Laser sensing permits mapping of a surrounding environment such as the hall-door-room-cabinet arrangement shown here.
For outdoor applications, the Seekur uses global positioning systems (GPS) for position measurements. These systems use flight times of radio signals from at least four satellites to triangulate a position on the earth’s surface.
When available, such systems can provide accuracy to within 1 m. However, they are limited by the line of sight requirements, which can be impeded by buildings, trees, bridges, tunnels, and many other types of objects. In some cases, where outdoor object locations and features are known (such as urban canyons), radar and sonar can also be used to supplement the position estimates during GPS outages. Even so, effectiveness is often limited when dynamic conditions exist, such as cars passing by or construction.
MEMS angular rate sensing
The MEMS gyroscope used in the Seekur system provides a direct measurement of the Seekur’s rate of rotation about the vertical, or yaw, axis, which is normal to the earth’s surface in the Seekur navigational reference frame. The mathematical relationship for calculating a relative heading (Eq. 1) is a simple integration of the angular rate measurement over a fixed period (t1 to t2):

One of the key advantages of this approach is that the gyroscope, being attached to the robot frame, measures the vehicle’s actual motion without relying on gear ratios, backlash, tire geometry, or surface contact integrity. However, the heading estimate does rely on sensor accuracy, which is a function of the following key parameters: bias error, noise, stability, and sensitivity.
Fixed bias error, ωBE, translates into a heading drift rate, as shown in Eq. 2:

Bias error can be broken down into two categories: current and condition-dependent. The Seekur system estimates current bias errors when it is not in motion. This requires the navigation computer to recognize when no position change commands are being executed and facilitate data-collection bias estimate and correction-factor updates. The accuracy of this process depends on sensor noise and the amount of time available to collect data and formulate an error estimate. The Allan variance curve (see Fig. 5) provides a convenient relationship between bias accuracy and averaging time. In this case, the Seekur can reduce the bias error to less than 0.01°/s, averaged over 20 s, and can optimize the estimate by averaging over about 100 s.

Fig. 5: The Allan variance curve (shown for an ADIS16265 — an iSensor MEMS device similar to the gyroscope currently used in the Seekur system) can also help determine the optimal integration time for gyro sensing.
The Allan variance relationship also offers insights into the optimal integration time (τ = t2 − t1). The minimum point on this curve is typically identified as the in-run bias stability. The heading estimates are optimized by setting the integration time, τ, equal to the integration time associated with the minimum point on the Allan variance curve for the gyroscope in use.
Because they influence performance, condition-dependent errors, such as bias temperature coefficient, can determine how often the robot must stop to update its bias correction. Using precalibrated sensors can help address the most common error sources, such as temperature- and power-supply changes.
For example, a change from the ADIS16060 to the precalibrated ADIS16265 may incrementally increase size, price, and power, but offers 18 times better stability with respect to temperature. For a 2°C change in temperature, the maximum bias of 0.22°/s with the ADIS16060 is reduced to 0.012°/s with the ADIS16265.
The sensitivity error source is proportional to the actual change in heading, as shown in Eq. 3:

Commercial MEMS sensors often provide sensitivity error specifications that range from ±5% to above ±20%, so they will need calibration to minimize these errors. Precalibrated MEMS gyroscopes, such as the ADIS16265 and ADIS16135, provide specifications of less than ±1% — with even better performance in controlled environments.
Application examples
Warehouse automation currently uses lift trucks and belt systems to move materials for organizing inventory and fulfilling demands. The lift trucks require direct human control, and the belt system requires regular maintenance attention.
In order to achieve maximum warehouse value, many warehouses are being reconfigured, a process that opens the door for autonomous robot platforms. Instead of a substantial construction effort to revise lift trucks and belt systems, a fleet of robots requires only software changes and retraining the robot’s navigation system for its new mission.
The key performance requirement in a warehouse delivery system is the robot’s ability to maintain a consistent pattern of travel and maneuver safely in a dynamic environment, where obstacles move and human safety cannot be compromised. In order to demonstrate the value of MEMS gyroscope feedback on the Seekur in this type of application, Adept MobileRobots conducted an experiment to find out how well the Seekur would maintain a repetitive path, without and with MEMS gyroscopic feedback (Fig. 6). It is important to note that this experiment was run without GPS or laser-scanning correction—for the purpose of studying the impact of MEMS gyroscopic feedback.


Fig. 6: A MEMS gyroscope can make a significant difference in robotic performance, as can be seen in the plot of Seekur path accuracy without MEMS gyroscope feedback (a) and with feedback enabled (b).
The difference in maintaining the path accuracy is easy to see when comparing the path traces in Fig. 6. It is important to note that these experiments were run on early generation MEMS technology that supported ~0.02°/s stability. Current gyroscopes enable two to four times performance improvement at the same cost, size, and power levels. As this trend continues, the ability to maintain accurate navigation on repetitive paths will keep improving, opening up additional markets and applications, such as specimen and supply delivery in hospitals.
Robot supply convoys
Current DARPA initiatives continue to call for more robot technology to help in force multiplication. Supply convoys are an example of this type of application, where military convoys are exposed to opposing threats while forced to move in slow, predictable patterns. Accurate navigation enables robots, like the Seekur, to take on more responsibility in supply convoys, reducing human exposure to threats along their paths.
One key performance metric, where the MEMS gyroscope heading feedback is particularly helpful, is in managing GPS outage conditions. The latest Seekur navigation effort, geared towards this environment, employs MEMS inertial measurement units (IMUs) for better accuracy and for their ability to incorporate future integration advances—for terrain management and other functional areas.
To test how well this system localizes — with and without the IMU — the error of an outdoor path was recorded and analyzed. Comparing the errors with respect to the true path (from the GPS) of the odometry only and those of the odometry and the IMU combined in the Kalman filter (Fig. 7) shows that positional accuracy is nearly 15 times better in the latter case.

Fig. 7: Comparing Seekur position error using odometry only (blue) and using odometry/IMU (green) show the significant performance impact of the latter combination.
Future developments
Next-generation development for systems such as the Seekur could move from gyroscopes to fully integrated, 6-degrees-of-freedom (6DoF) MEMS sensors. While the yaw-oriented approach is useful, the world isn’t flat; many other applications, existing and future, can use integrated MEMS units for terrain management and for additional accuracy refinement. ■

Learn more about Analog Devices, Inc.


Fuente: http://www2.electronicproducts.com/Optimizing_a_mobile_robot_s_navigation_performance-article-farc_adi_jun2011-html.aspx

Nueva técnica reduce a la mitad el consumo de los dispositivos informáticos

Nueva técnica reduce a la mitad el consumo de los dispositivos informáticos
Un equipo de investigadores de la Universidad de Washington ha desarrollado un sistema de programación que disminuye el consumo de energía de los ordenadores y teléfonos móviles entre un 50 y un 90%. La técnica se basa en el aprovechamiento de operaciones que pueden sobrevivir a pequeños errores producidos durante reducciones de voltaje o en comprobaciones de precisión menos exhaustivas, entre otros recursos. Por Elena Higueras.
Nueva técnica reduce a la mitad el consumo de los dispositivos informáticos
El uso de ordenadores, centros de datos y dispositivos móviles cada vez más potentes lleva aparejado un aumento del consumo de energía. Muchos expertos están trabajando para reducir este gasto. La mayoría de estos proyectos se centran en buscar sistemas más eficientes de refrigeración o en modos de ahorro de energía.

Ahora, investigadores de la Universidad de Washington (UW) proponen una forma distinta de control de consumo energético, que permitirá que los programadores reduzcan el gastos de energía de los unos y los ceros en el propio código.

El grupo de especialistas de dicha universidad ha creado un sistema, llamado EnerJ, que reduce el consumo de energía hasta un 50%, y que tiene el potencial de llegar a reducirlo incluso hasta en un 90%, señala un comunicado emitido por la Universidad de Washington. Este sistema se presentará la próxima semana en el encuentro anual de Diseño e Implementación de Lenguajes de Programación que se celebrará en San José (California).

"Todos sabemos que el consumo de energía es un gran problema. Con nuestro sistema, los usuarios de telefonía móvil notarían sus beneficios en terminales más pequeños, en una mayor duración de la batería o en ambos casos, y los centros informáticos lo verían reflejado en la factura de la luz", afirma Luis Ceze, uno de los autores de la investigación y profesor asistente de Informática e Ingeniería de la UW, en la mencionada nota.

Pequeños errores sin importancia

El sistema se basa en la idea de aprovechar los procesos informáticos que pueden sobrevivir a pequeños errores que ocurren cuando, por ejemplo, el voltaje se reduce o se aminoran las comprobaciones de exactitud. Algunos ejemplos de aplicaciones posibles son el streaming de audio y video, los juegos y el reconocimiento de imágenes en tiempo real, para aplicaciones de realidad aumentada en dispositivos móviles.

Nueva técnica reduce a la mitad el consumo de los dispositivos informáticos
En palabras de otro de los autores del estudio, el estudiante de doctorado de la UW en Informática e Ingeniería Adrian Sampson: "el reconocimiento de imagen tiene que ser tolerante con los pequeños problemas, como una mota de polvo en la pantalla. Si introducimos unos manchas más en la imagen debido a los errores, el algoritmo debería seguir funcionando correctamente y esto nos podría hacer ahorrar energía".

El sistema crea dos piezas entrelazadas de código: una de ellas es la parte exacta - por ejemplo, el cifrado de la contraseña de una cuenta bancaria- y la otra parte está destinada a todos los procesos que podrían sobrevivir a fallos ocasionales. El software crea una barrera impenetrable entre las dos piezas: "Hacemos que sea imposible la fuga de datos de la parte aproximada a la parte precisa. Usted está completamente seguro de que esto no puede suceder”, garantiza Sampson.

Menos voltaje

Mientras el uso eficiente de la energía en los ordenadores resulta frustrante y costoso, todavía queda otra cuestión fundamental en juego. Algunos expertos creen que nos estamos acercando al límite en el número de transistores que se pueden ejecutar en un único microchip.

Se trata del llamado "problema del silicio negro", que hace referencia a la infrautilización de los transistores que hay en cada chip al no disponer de la suficiente potencia para utilizar todos los transistores al mismo tiempo.

El sistema de la Universidad de Washington funcionaría como un regulador de intensidad que permitiría que algunos transistores trabajasen a un voltaje más bajo. Las tareas aproximadas podrían funcionar en las regiones más oscuras del chip.

Los investigadores podrían utilizar el programa con un nuevo tipo de hardware, en el que algunos transistores tengan un voltaje más bajo. Esto aumentaría ligeramente el riesgo de errores al azar, por lo que EnerJ trasladaría sólo la resolución de las tareas aproximadas a estos transistores. "Si usted puede permitirse un error cada 100.000 operaciones más o menos, ya se puede ahorrar mucha energía", asegura Ceze.

Otras formas de usar el hardware para ahorrar energía consisten en reducir la frecuencia de actualización y la tensión del chip de memoria.

Del 50 al 90% de ahorro energético

Las simulaciones realizadas por el equipo de investigación estadounidense demostraron que EnerJ reduce el consumo de energía alrededor del 20 a 25% como media, dependiendo de la agresividad del enfoque. En uno de los casos se llegó hasta casi el 50%. Los investigadores ya están diseñando un hardware para probar sus resultados en el laboratorio.

Los ordenadores de hoy en día también podrían utilizar EnerJ con un enfoque puramente basado en el software. Por ejemplo, el equipo podría redondear números o saltarse algunas comprobaciones de precisión extra en la parte aproximada del código para ahorrar energía. Según las estimaciones de los investigadores, esto supondría un ahorro energético de entre un 30 y un 50%, basado únicamente en el software. Por tanto, los científicos de la UW consideran que la combinación de los métodos de software y hardware podrían reducir el consumo de energía en un 90%.

"Nuestro objetivo a largo plazo sería mejorar en 10 veces la vida de la batería", apunta Ceze en el comunicado. El equipo espera lanzar el sistema como una herramienta de código abierto este verano.


(Tendencias21)