Skip to content

Week 9

Assignments

  • [ ] Task 1: I used an Arduino Uno to simulate a low fidelity thermostat, using a photoresistor and the assumption that the brighter the sun shines, the more a fan is needed.
  • [ ] Task 2: short demonstration of the reaction of the system.

Process

  • The setup uses the photoresistor to measure relative brightness, and start a motor when the brightness is greater than about half.
  • First, I prototype the circuit with just the photoresistor, a 10K ohm resistor to ground, and measure the value received by the Arduino when the sensor is covered, receiving minimal light, then uncovered, at maximum exposure. This gave me a range between 320 and 650.
  • Then I wire in a motor with an L298N motor control board. It’s true that this board is not the most efficient, but for such a small experiment, it will do.
  • I experiment running the setup on the USB supplied power, and with a battery pack. As I move my finger over the photoresistor, blocking the light, the fan stops.
  • When I move away, it spins up as the sensor value passes the threshold I set, “500.”

Reflection

  • I will confess I don’t have a conventional teaching background, which seems to prevent me from having preconceived notions about what my “discipline” is. I will recognize that I teach from perspectives that embrace arts, Science and Computer science, as part of what no doubt touches multiple areas of STEM, but also will approach things from language arts perspective as well, in considering how tech jargon comes to gain meaning, and sifting through abstractions that might be second nature to a pro, but need some demystification for first time learners. I even try to acknowledge history and the humanities in lessons where I can, and all this is intended to define the subjects taught in the Lab as not just being distinct areas of specific technical learning, but tied fundamentally to the learning that students are doing in every other area of their academic journeys. Where my own experience is often limited in other areas of academics, I relish opportunities to collaborate with other instructors and have been blessed by collaborations that can span the gamut of subjects, including a team-up with the football coach to teach some of the players to animate their own scoreboard graphics to illuminate their successes on the field. Opportunities at times have seemed endless, but the lab is at an extreme end of campus, and for many other faculty, planning periods are sparse and much sought after by demanding to-do list items.

  • I think when I arrived here, I saw this makerspace as a pinnacle of what I imagined such a space needed. Plenty of modular space, distinct zones for specific maker activities, multiple academic spaces so multiple classes could meet simultaneously…

  • And yet, there remains more to hope for, even still. Our scholastic culture teaches that the makerspace is like a library of craft, and multiple events are held each academic term, inviting classes to visit.

  • I recognize that there are relatively few periods of the year which offer substantial time to do much needed cleanup, not just sweeping floors and the like, but resetting project kits, building up supplies, and performing maintenance. Some of this is surely within my own realm of time management, but historically I have struggled to define good boundaries when it comes to the attempt to meet one more community need. - - This has definitely been catching up with me, as deferred maintenance becomes its own barrier soon enough, leading to a desire of better organizational systems to help keep things in line. This is where computational thinking becomes attractive, as some of the more pressing needs in the lab are its own organizational structures. The artefacts of course take literal form, in the countless electrical and hardware components, each being sortable into one of a myriad relatable categories, to occupy predictable space and find ways back to such space after use, and the workflow needed to ensure that. I have begun building small lessons around taking the computational thinking approach to a concrete problem with specific observable constraints, such as the need for a tool to reside in discrete space. The path from the wandering tool to a bespoke home on the wall is easily trackable through the CT process, and the documentation that results makes for replicable results that are not only repeatable, but improvable through the successive iterations.

Tools

  • Arduino, Adobe Illustrator, and TinkerCad