Posts Tagged ‘sensor’

Critical technological components for demonstrating the value of the Frontline gloves concept were 1. the proximity sensor for sensing distances in smoky/darr/low visibility environments, and 2. basic communication between firefighters made possible by gesture recognition, using bend sensing technology. Putting together quick and dirty prototypes of these two components helped us test their viability early. Here are a couple of videos of the tests.

In our initials ideas, the Frontline gloves product concept consisted of two distinct parts connected by wires: 1. the upper hand area of the glove with proximity sensing and signalling capabilities and 2. the brain and software nestled into a pouch further up the arm (maybe integrated into the end of the long arm of the glove). The latter would consist essentially of an Arduino, a Xbee shied for wireless communication with the paired glove, and a battery pack for powering the whole setup.

But before long we found ourselves exploring ideas around miniaturizing the product (encouraged by teacher Vinay.V) by combining both parts in one – within the box on the hand of the glove itself (photo above). This, we learnt, would be possible if we got rid of the Arduino board by detaching its chip, clock and a few other components and mounting them on to a much smaller custom made board.

The integrated single-piece set up of components.

The Tradeoff

Going further, we decided to go with using the complete Xbee shield setup as is, including its board, for this prototype. As a result, we traded off using two seperate components connected by wires for a larger but single component fully integrated into the hand of the glove, including the battery pack.

The increasing size of the housing for components as prototyping progressed.

Rapidly created scenarios helped us better understand how technology-enhanced gloves could answer critical needs of firefighters in real fire situations.

Because we were working with a set of four or five critical user needs (finalized from researching papers and ongoing projects in wearables for firefighting), the first concept of our product became loaded with features – a classic case of ‘featuritis’.

Dan’s enlightening presentation highlighted the various subtleties of the domain as well as some of the first thumb rules for gestural interface design. Issues highlighted included limitations of current interaction modes, the (under-explored) importance of ergonomics, types of interactive gestures, the preponderance of sensors, an overview of notation, prototyping for … phew! immersive stuff, literally. But I will let you find the real thing for yourself in his soon-to-be-released book. There’s also Dan’s exclusive wiki on the subject.

We had our own shot at tinkering around with the delightful Ardunio micro-controller some days later, and took the opportunity to develop our own gestural interfaces. My favorite was this one – RubberBots – for its degree of sensitivity and emotional subtlety in response to interaction.

This mini-project was executed as part of the Computational Design course at CIID some weeks back. My objective was to use the Nintendo Wii to record simple wind data by suspending the Wii in an open location, and using the recorded data to create visualizations drawn by programming in Processing. More details follow.

The Concept:
This intent is to show a concept for visualization of simulated wind data as would be available from a sensor located on a windmill.
A real stakeholder – wind data analyst – from a leading Danish consultancy was interviewed to understand key challenges in wind turbine design.
It is common in the Danish wind industry (and elsewhere) to record wind data for very small intervals of time. By understanding wind patterns in terms of its properties such as acceleration and constancy, engineers are able to go beyond physical limitations of turbine design to evolve increasingly efficient and productive systems.
With over 20 sensors recording different parameters on a single windmill, analysts often face a veritable mountain of data (down to individual seconds). In this context, visualization of such data in a manner that facilitates comparison, causality and multivariant evidence becomes key. The poster describes briefly how some of these goals were met.

The delightful ‘Wiimote’ was used in this experiment to mimic the sensor.

Design Context: A real world scenario Location: a wind farm out in the North Seao72 turbineso20 sensors on each turbineoEach sec of wind data recordedoData from 8 years archived for analysis

·The peak production of windmills of all capacities is 60% of full capacity due to physical limitations·Measuring constancy of wind is of most interest to wind analysts and windmills designers·Acceleration of wind is most deterrent to wind production as it wears out the material most, and least load on the material comes from constancy of wind·The main difficulty in real-world wind turbine design isn’t generating the most electricity at a given speed – it is making blades which will work across a range of wind speeds·The design challenge is to be able to measure and visualize wind data in a way that can help engineers interpret the ‘acceleration’, ‘lift’ and ‘orientation’ of wind.

Using the Wii Remote as principle sensorWii remote sensors simulate the acceleration of wind by it’s x, y, z acceleration coordinates·In order to holistically render the acceleration of wind in a visual manner, we have focused on gathering data in coordinate directions x and y, and rendered the z axis insignificant – by suspending the sensor (in this case, the Wiimote) with a cord of fixed length.·Due to the position of the Wii remote when recording the raw wind data, the x and y coordinates are principle axis in this experiment. This has two benefitsoThe z sensor is rendered insignificant in terms of contributing to measuring acceleration, thus rendering it simpler by reducing the number of variables required in its calculatingoThe z axis becomes dedicated to measuring ‘lift’ and denoted here by the small series of arcs at the bottom.