Making sense of sensors
I recently attended a talk on the topic of sensor miniaturisation. Specifically, it covered the challenges of directly integrating electronics into the constituent materials of everyday objects and structures. The aim of this research is to be able to extract data about chemical and mechanical properties of objects during their production via additive manufacture, through their lifetimes out in the world, to their eventual disposal and reprocessing. It’s a hugely ambitious goal that will require advances in electronics fabrication, materials science and energy storage. However, one of the biggest challenges is the matter of how to move the vast quantities of data that thousands of sensors tend to produce – and, perhaps more pertinently for the end user, how to make sense of it all once you have it.
Taking a step back from the brave new world of 3D-printed spoons that can analyse their own stress distributions, it is clear that new products – and iterations on previous ones – are becoming increasingly instrumented. Much of the work of an engineer at any technically oriented organisation concerns the integration or development of sensors, often in conjunction with colleagues who do not have a background in electronics and sensor design.
This last point presents a problem. Any engineer who has used the software supplied with many pieces of technical hardware – from cheap evaluation boards to high-end test equipment – will know that user experience is very much secondary to displaying as much data as possible. To a technical user, a program window full of numbers, graphs and strangely anachronistic dials is just about workable, if an eyesore. To a non-technical user, it is gibberish.
A common way to deal with this issue is to supplement software with presentations, documents or hands-on demos. Thus, an engineer can explain with either speech or text what the mess of data on screen is trying to convey. This is acceptable for one-off demos (although still one step away from a true ‘hands-on’ experience). However, in many cases, a colleague – maybe from another office – may wish to take away a test rig to show to other members of their department. To do so, they will require a not insignificant amount of training at someone’s expense, and there is still every likelihood of technical failure they cannot fix or outputs they cannot explain.
So how to solve this issue? Firstly, we must define what the intended recipient needs from their demonstrator. This will differ from case to case, but a good starting point would be to assume that they want to see data on the performance of the new sensor. A readout displaying the sub-degree position error your sensor is capable of shows progress. Five boxes with various file paths in them shows nothing. Live-updating graphs with clear labels, brand-aware colours and low latency instantly highlight important information as a user interacts with a device. Static images, streams of text, and multiple windows and programs obscure the point of focus and remove the clear link between the device and the data.
Secondly, what’s the main stumbling point when a colleague takes a demonstrator to show to others in your organisation? If your program requires 23 steps and an incantation to open correctly, it is not going to impress in a boardroom. Much better to have one device to plug in, and one shortcut to click on an otherwise blank laptop. The blank laptop is key here – provide all the software and hardware needed for a portable demonstrator and lock it down to prevent any tampering.
So, to conclude, sensors are being integrated into everything. As a result, it has never been more important – or more complex – for engineers to clearly and concisely communicate large quantities of data to colleagues. By taking a step back and analysing what data really needs to be presented to tell others the correct story, the process can be dramatically simplified. Furthermore, by building clear graphical user interfaces to display data, the live output of sensors can be easily understood by all members of a project team, technical or otherwise. Thus, the inevitable misunderstandings and miscommunications that come with large teams and different knowledge bases are avoided. Integration into a final product becomes simpler, and technically ambitious projects incorporating the latest sensing technology are delivered working, on time and on budget.
Consultant Electronics Engineer