finding stories in Sensors
The “Cyber” in cyberphysical systems
The Physical element of Cyber-Physical Systems is focused on the execution of code and analysis of data through sensors. How can sensors shape what we measure? How can we ensure that we act on the metrics we intended to measure?
My coursework at 3Ai included a critical exploration of programming languages, specifically Python, which was applied to coding for sensors. I was able to create functioning loops in Python that eventually controlled sensors such as thermostats, air quality measurements, light meters and oscilloscopes. As a result, I have developed a useful understanding of how code can shape and limit how these systems are built.
Case Study: The Circuit Playground Express
A Circuit Playground Express (CPX) sensor laid on a diagram mapping its components.
For an assignment exploring sensors, we were asked to code a temperature sensor that could export readings to a .csv file from a Circuit Playground Express (CPX) device, which is not shipped with document writing functionality. Our task began with finding some way to add this functionality to the CPX, which relied on scant coding samples generated by the device’s enthusiasts. Much of the code was poorly commented, the tutorials were unclear, and we were left to solve this problem on our own.
I approached the problem through a series of experiments on the device. For example, as a method for understanding some of the ambiguous language from how-to guides, I made a chart of all possible meanings. Then I methodically tested each of those possibilities. When this still proved inaccurate, I went to the source of each “guide” to analyze when those guides were written and which version of the CPX software they used. I then downgraded the drivers to those versions of the software in an attempt to align the device to each guide.
In the end, the solution was found in a book, and I was able to re-write the boot file of the CPX to allow for data export.
Key Learning
“There is a big danger in working in a single medium. The logjam you don’t even know you’re stuck in will be broken by a shift in representation.”
1. Documentation must explain everything. Don’t assume the next person who looks at your code knows everything you do. Especially in emergency and crisis situations where time is critical, coders may be tempted to assume a base level of shared knowledge between experts for the sake of expediency. You have time before a crisis emerges to make sure code is clear and easy to understand. Make sure it is, before feedback loops amplify misunderstandings in a crisis. I was able to apply this to my “Tourist’s Guide to Datasets,” below.
2. Step back. Stepping back from a problem isn’t just important for mental health. Walking away and returning, or bringing in outside perspectives, is a way of challenging internal stories about what “works” and “doesn’t work.” It’s a way of becoming trapped within the metaphors and shorthand you’ve created to explain a problem to yourself. Setting stop-gaps in a system where you are forced to articulate the problem to another person can be clarifying.
3. Make metaphors concrete. Too often we rely on metaphors and shorthand to understand different parts of a system. Even if two people with different understandings of a system communicate exclusively through metaphors, they stop talking about the system and start talking about their own abstractions. Clarifying concretes reduces ambiguity. This can be done by drawing models out as steps or illustrations, forcing you to clarify your own thoughts and understandings of the model. I found that misunderstanding the metaphors of the system we were using created considerable struggles in navigating my way through problems that would emerge. Systems or network maps — discussed in greater detail on the “Systems” page — are extremely helpful ways to reach this understanding.
4. Context is essential. Do not attempt to bring knowledge from a limited application to problems outside of that application. Understand the context of new environments where systems could be deployed. Do not assume that what works in one system will work in another, or that what worked for one group of people will work with everyone. Especially in creating new systems, we have to take note of interaction points where the data from one sensor can be misread or incomprehensible to another. When we adapt that data, we have to keep in mind what it originally represented, not merely what makes it “compatible!”
5. Talk to people. Because I had focused so much of my time on just getting started with the code, it felt like I was always “just about” to figure it out. I could have put the assignment away earlier and asked better questions later with people who got me outside of my own head.
What’s Next? A Tourist’s Guide For Datasets
“Most data arrives on our computational doorstep context-free and ripe for misinterpretation. And context becomes extra-complicated [with] poor data documentation.”
As a result of my experiences, I have become more vigilant about documentation the context of our actions in coding and in data collection. Here, a photograph of an experiment in taking air quality readings shows more information than simple Air Quality measures. By including detailed contextual stories within a “user guide” to data we collect, we can make sure people don’t misapply datasets, or use them in ways that don’t make sense.
After my experiences with the CPX, I went into data collection activities with a greater emphasis on clarity in my documentation. My mind went to tourist guides that I would use to make sense of cities in my travels. I decided to develop a “Tourist’s Guide” for data, as an example of how we might introduce “tourists” to our datasets: people who are looking to make sense of what our data is and how to get the most out of it.
For example, in a subsequent activity gathering data on air quality, I made sure that to create a clear, human-readable version of the data. This is meant as a key or guide to the .csv file, not a replacement. See the document here.
As a result of my experiences, the document included a thoughtful assessment of what information would be useful to include and how to read and understand how it was collected. For example:
Images of locations where air quality measures were taken, along with times and identifiable smells in the air.
A description of what each Air Quality measurement meant in layman’s English. Because our data was being collected for a wide variety of purposes, it was important to define our understanding of the terms we were using, to avoid misunderstandings or international/interdisciplinary changes in meaning.
Clearly marked concerns about the data we collected. Because the goal is to produce useful data, rather than position ourselves as immaculate researchers, it was important to clarify readings that seemed anomalous or beyond our level of expertise.
This approach is a prototype, and could be expanded to more of a tourist’s guidebook format. Given a thirty minute time constraint on collecting the data, I wanted to show that this approach could be implemented without significant delays in gathering the data.
As we create more complex systems at scale, it’s critical for us to make sure that humans can understand each piece of these systems. We do this by telling stories about what our code and data mean, so that we can understand how to diagnose and fix them — and to build them right in the first place. Moving forward as a practitioner of the New Branch of Engineering, I’ll keep this idea of the “tourist’s guide to data” in mind, scoping out ways to systematize the gathering of metadata that can make data accessible and clear, even to those who may struggle with numerical analysis. Data tells a story, and so does the way we collect it. My hope is to use both types of stories to tell a richer, deeper narrative with more points of entry.
Skills Mastered
Breaking down large, difficult problems into identifiable steps to solve them, documenting and retracing steps when necessary.
A commitment to new standards of practice around data collection and sharing, focused on broadening accessibility through context
Awareness of how information moves between multiple sensors, and what questions we can ask to test that the data’s meaning is preserved as it moves.