Problem Solving: Peeling Back the Layers
One of the things I enjoy about working on a project like my dog door logging project is that problems crop up that challenge me. This is something I find fun, but my students sometimes find frustrating, so I’ve been thinking about how to present the issues of problem solving in a way that will be more appealing to my students and will encourage them to dig as deep as they need to to solve the problem and not give up.
I tend to approach problems in a step by step fashion. As I’ve built this dog door project, I’ve done it one step at a time rather than trying everything at once. First, I tested the tilt sensor itself to see if it would work, printing it’s state to the monitor. The wiring and programming for the tilt sensor have been well documented (thanks, Adafruit!), making this step fairly straightforward. Understanding the programming language and how circuits work allow you to change things up if needed, but the basic tutorial gets things off the ground quite nicely. Early success is important!
The next step was to figure out how to save the data from the tilt sensor. This involves thinking about a couple of things. First, what does the data coming out of the sensor look like? Is it a string? A number? Here’s where tutorials sometimes break down. The tutorial I used lit a light when its state changed. I needed to print text somewhere, preferably in a format I could use elsewhere to create a graph. I had in step one, printed to the serial monitor, adding a single line to the tutorial code. I actually ended up making my own string, so that “Up” printed to the screen when the “door” was “Up”. Basically the tilt sensor registers a high or low value of electricity, similar to an LED receiving a high or low value of electricity, so I just converted the high or low value to the string “Up” or “Down”.
There’s a lot to unpack in just that one solution. I think we underestimate that when teaching students. Understanding what’s coming out of a function is challenging for most. Knowing that printing to a file requires a string or a number and that other data types might not work is a pretty big step. And then you have to figure out how to convert your data to the right type if necessary. Also, you have to know that some sensors might actually give you numbers and then you don’t need to convert! Crazy.
So I’m printing to the screen, but not saving the data anywhere. How do I do that? How do I do that with what I have on hand? To the Google machine! As I mentioned yesterday, I discovered that the Arduino can store a small amount of data (512 bytes). This was a test of two things: 1) that the data can be saved and 2) that I could read the data later and see that it was useful data. Again, the documentation on this was good, but I had to know how to search for that. I searched “how to save data on an Arduino” by the way. And I got this, which led me to this. And just this step is a challenge for many students. There are different kinds of memory. The amount is tiny, so one has to think about how many characters to use. It’s a good lesson, but could be frustrating. And there’s a whole other process for reading the stored memory out, which requires writing another program. Phew!
In search of a more robust solution for saving and retrieving data, I went to the SD shield, a shield I’ve used before with some frustration. Most of the time, I couldn’t even get the Arduino to recognize the SD card, which has to be formatted exactly correctly for anything to work. I got past this step at least. In theory, I’m writing to the SD card now instead of local memory (a one-line change plus some imported libraries and pin attributions, maybe 5 lines total). But, the file is empty every time I look at it. No errors, just not doing what I think I’m telling it to do. And these are the issues faced by most of my students. Things are “correct” but something isn’t right. My card could be too big. The documentation does say that SD cards that are bigger than 16GB are not supported. Whatever that means. My filename could be wrong, but I think I’d get an error. Could be any number of things, programmatically or electrical or hardware.
And then I have to solve the problem of how to get the device onto the dog door itself. This is going to pose an issue. The best way to do it would be to solder everything together, and I think that’s the direction I’m headed. We shall see.
But you can see how many layers of things one must dig through to begin to solve what seems like really simple problems. To me, this is the crux of what we teach in CS. We help students methodically step through solving a problem (often a problem they designed) and then recognize the smaller problems they need to solve one at a time in order to achieve the larger solution. It’s breaking down problems into smaller parts, algorithmic thinking, and a touch of creativity, all things we’re trying to convey in CS. But it’s not always easy and I think we need to recognize the frustration that might come with discovering another mystery with each solution, the feeling that maybe there’s no bottom to this. Thinking through my own strategies for solving this particular problem reveals all the things I know that help me, things I might need to help my students learn as they bump up against these kinds of problems: different data formats, how data is read by a computer, memory types and sizes, formats for disks and files, not to mention electrical circuits and programming which are the main things we think we’re working with. I find it fun to peel back the layers, and I hope to make it fun for students, with a little bit of coaching.