In a previous post, I played with code and created a Particle function that made LEDs flicker like a candle whenever the function was called. While experimenting, I had the idea of creating a flickering paper circuit fireplace, or a candle, that might be triggered by data connected to a light sensor. Ultimately, I wanted to figure out a way to do this as a step toward creating a wifi-connected book containing artwork brought to life with real-time data.
1. ThingSpeak channel documenting light sensor 2. Photon connected to a paper circuit
Unlike the Goofy Photon Servo Notifierwhich used the Particle.subscribe feature (linked to data in my Google Calendar) the function illustrated below is triggered via a web hook that I set up in ThingSpeak, which only calls the function if a sensor on another Photon reports a low light level.
PROOF OF CONCEPT (Video demo)
I'm making progress toward my goal of creating a wifi-connected book that uses data to help tell a story. As a test of concept, I created a Thing HTTP app and a "React" app in ThingSpeak to trigger a Particle function (on one Photon) based upon readings from a Photocell (attached to a second Photon). To get started, I created a ThingSpeak channel and a Particle web hook by following this tutorial.
Once I created the web hook, my Photon started logging the photocell data on ThingSpeak. In order to make the data more useful, I modified the Photon code in the tutorial by adding the following lines to the loop, just above the line containing the Write API key for the ThingSpeak Channel.)
value = map(value, 0, 4096, 0, 255); //maps values value = constrain(value, 0, 255); //constrains values between 0 and 255.
Next, I uploaded this code to a second Photon, connecting the Photon to a paper circuit using alligator clips. Lastly, I created the ThingHTTP and React apps.
The React app allowed me to set up a trigger related to the data. I set it up so that a reaction happens any time the sensor picks up a value of 150 or greater (when it's cloudy or dark and the resistance increases). The ThingHTTP app allowed me to post an HTTP request to Particle, triggering the Particle function that illuminates the owl's eyes and the candle flame.
As my previous posts have explained, I'm in the process of learning about the Photon in hopes of creating a wifi-connected book that will use paper circuitry triggered by data to help tell a story. This won't be completed until the spring. Since we were required to create some sort of project and video for this class, I took a detour from the work I'm most interested in to focus on another application of the Photon.
Rather than creating a formal lesson plan, I created an instructional video and a functioning model of a project that might be adapted for use in a classroom or other venue.
Before I launch into my final project, here's a teaser of what the circuit in my wifi-connected book might look like. This is only a prototype to help me think about where the leads need to go, as I begin to plan my book's layout.
I'll need to overlay the copper tape with conductive fabric in areas where the circuit will continue between the pages of the book. I'll also need to determine precisely where I'll be poking the holes that I'll be sewing through, to bind the signatures between the covers. My first book model will most likely be constructed from binder's board. Once I've received some feedback and determined that everything works the way I want it to, my hope is to create wooden covers with recesses engraved with a laser cutter or CNC router.
FINAL PROJECT:
While thinking about how I might be able to use a servo in my book, I hunkered down and created a gadget that I'm calling the Goofy Photon Servo Notifier. I've designed a basic paper pop-up book structure that folds flat once the servo is removed.
The pop-up structure folds flat.
In theory, I could add something similar to the inside of the pages of the wifi-connected book I'll eventually make and a reader could pop the servo in.
VIDEO DEMO
QUICK OVERVIEW:
Taking inspiration from this "Study Budy" project, I started experimenting with the Particle.subscribe feature. The basic premise of the project is to have a new event on a Google Calendar trigger a servo connected to a Photon, in order to alert a student that there is something they should be working on.
Basically, Particle.subscribe is a piece of code that tells a Photon to listen for an specific event that you can give a very specific name to; a unique name will reduce the likelihood of other people subscribing to your event (and triggering your device). When the Photon receives word that the event is taking place (a new task added to your Google Calendar, for example), the Photon carries out a unique function referred to as an "event handler" that basically uses data to trigger an action on a physical object. (Note: In my earlier servo exploration, I used a different method to trigger a servo.)
To start, I logged into my If Then Than That account. I created a new Applet, selecting Google Calendar as my If THIS. I selected the first box depicted below, which reads "Any event starts".
I selected "Particle" for my Then THAT.
The trickiest part was figuring out what to put into the configuration boxes. I named my event something rather unoriginal: New_Event. I will be changing this name in my Applet and in my code to make it more unique.
I left the box below this (for optional data) empty. After saving the Applet, I uploaded my code and added a new event to my Google calendar to test it out.
CODE
While the "Study Budy" project got me going in the right direction, helping me to explore a new way to trigger events on my Photon, the code I wrote for my project was completely different.
For starters, my code requires only one Photon. My code also periodically detaches the servo to reduce jitter, and resets the servo to a zero position after 45 seconds. If a user didn't want the servo to reset automatically, they could comment out the code and manually press the reset button. Here is a screenshot of the code I wrote. Here's the link to my code.
RESOURCES TO LEARN MORE:
One juicy resource that I found this week was Daragh Burn's IoT course outline. a plan for an Internet of Things class that will be offered by Carnegie Mellon starting in January 2017. It was there that I got a useful explanation of the differences between Particle.publish and Particle.subscribe that I'd only just begun to understand.
My next step is to log in to the Particle-Raspberry Pi beta in order to see whether I can get my Photon to interact with data pulled from a Raspberry Pi I'm not certain that learning how to do this will actually help me create my physical book, but it will help me continue my investigation into the Internet of Things.
Here is a link to the standards I've selected for my experimental bookbinding project. My ultimate goal is to create a wifi-connected book, using a Photon microcontroller, that I'll begin constructing in January.
This week, I continued to experiment with code by adding a function that makes an LED flicker like a candle or fireplace. This function will only be called when a light sensor registers that it's cloudy or dark outside.
Here are a couple screenshots of the Arduino code that I adapted for use on my Photon. The thing I'm most proud of is that I figured out how to apply a For Loop in the Particle function I created that allows an LED to flicker for a reasonable amount of time--enough to get a point across--without flickering non-stop. I've since merged the code written below into the larger program that I've been working on.
I've also been experimenting with conductive fabrics and tapes this week, to find a material that might be useful for a book hinge. Although I had some mixed results, I'm not entirely certain that I'll be able to solder copper tape to the fabric without it scorching.
Lastly, I've begun experimenting with Inkscape, in an attempt to start brainstorming what my wooden covers might end up looking like.
The following image was my first attempt, but I've already discovered some problems with the design.
This week, I've continued my exploration of the Photon, as I prepare to implement my Capstone project next trimester. I am happy to report that I have a working prototype that merges all of the functions that I've been working on and writing about in prior posts. I'm not finished by any stretch of the imagination, but I have proven to myself that the concept in my mind can work!
Merging all of the functions into one program took considerable time, experimentation, and trouble-shooting. After several failures, and many hours of work, I took a paper copy of my code to a cafe and attempted to debug it. Surprisingly, this worked, even though I wasn't sitting anywhere near a computer. Not being near the computer helped me to be more clear about what I was trying to do and helped me hone in on potential problem areas.
Debugging in a Cafe
My next step is to work on finding a smaller servo that will work with my Photon.
This week I spent time experimenting with code and playing around with If Then Than That (IFTTT), which recently changed its set-up. My goal was to start merging programs on my Photon. So far, I've got a servo and NeoPixels running in one program, but I'd still like to add in code for a buzzer and LEDs that will be triggered by a light sensor. (This is a cross-post from my personal blog.)
My most exciting breakthrough was figuring out how to use IFTTT's "New Tweet From Search" feature, which makes it possible to trigger a web request by filtering a search in Twitter. In the case of my experiment, I created Applets, formerly referred to by IFTTT to as recipes, that can control the colors of NeoPixels connected to my Photon, in much the same way that CheerLights work!
This could provide an interesting way to interact with a wifi-connected book. A reader could send a tweet to change the color of LEDs in the book or scan a QR code to achieve the same effect, by triggering a Maker Event (also set up in IFTTT). While I'd already figured out how to do this with my own Tweets, I now know how to allow other peoples' tweets to interact with my Photon. My next step is to add code to the program so that a musical function is called in response to data received on a light sensor.
My next step is to add music to this program and trigger an event from data, such as readings from a light sensor or motion detector.
This week, another open exploration week, I unboxed my BBC Microbit and played around with some of the coding exercises for Python. I really like the way that I can practice different coding languages, such as JavaScript and Python with one device! My favorite lesson so far was this one, where I was able to connect a speaker to my Microbit with alligator clips and play music. I attempted to complete the Dalek Poetry activity, but I couldn't get it work.
Paper Circuit Triggered Microbit
I also couldn't get the Bluetooth feature to work on my device (I just learned that it's not compatible with Python yet), so the process of uploading the code was a bit cumbersome.
Instead of using the Microsoft iPad app as I'd planned, I ended up having to drag and drop the code from the downloads folder on my PC onto the device, as if it were a flash drive. Aside from that minor annoyance, it was a fun way to get instant gratification while playing with code.
I found an animated book making project that allowed me to tweak some code to create different animations on my Microbit that were triggered by copper traces in a book touching different pin configurations. It works in principle, as you can see in the video below.
Here are a couple of screenshots.
I'm running a little short on time this week, so this is where my exploration needs to stop for now. Next time I play with this, I'm going to check out a few of these lessons. I think that everyone learning the basics of coding should have a Microbit, because you can immediately practice physical coding.
This was "Open Project Week," where we were invited to work on a project of our choice, as long as it relates to the course syllabus. I continued my exploration of the Photon, which is something that I started prior to this class. Continuing my independent inquiry supports this course's learning objective of setting "personal and professional goals for increasing [my] coding confidence."
Since last week, when I got a servo up and running on my Photon, I've had a couple of major breakthroughs. In particular, I've figured out how to trigger a web request via a QR code. What that means is that I can now use a QR code to trigger a specific function in my code to "control physical objects," which is another learning objective of this course. In this case, I can control a servo and a buzzer. I'm continuing to build upon my understanding of Particle functions.
I've embedded a couple of videos here, but if you are interested in learning more, please visit my personal blog (linked below).
This week, I dug deeper into how switches work and continued playing with my Photon, a tiny wireless board that is programmed with an Arduino-based language.
This is a headerless Photon, but the one I use to prototype with has header pins soldered to it.
The following is a simple sketch for a LilyPad Arduino. It has two blinking functions; one blinks faster if a switch is toggled from off to on (high to low). Although I have experience with switches in my work, the concept of a pull-up resistor was something new to ponder. According to the baldengineer, "When using any kind of 'open' inputs with an Arduino such as switches, push buttons, reed relays, and some sensors, a pull-up resistor is needed for reliable operation. These resistors hold the I/O pin at a known value until the switch forces the I/O pin to a different known value. On each board there are Arduino Internal Pull-Up resistors built-in, they just need to be turned on in the sketch, usually in setup()." My original code didn't specify that I wanted the switch to be an INPUT_PULLUP, rather than just an INPUT, and it didn't work. When I changed the code, it did!
I also continued working on a personal passion project, which is trying to learn more about the Photon and the Internet of Things. Like the LilyPad Arduino, the Photon also has built in pull-up resistors. I haven't used them yet, but I thought I'd mention it.
My goal for the week was to get a servo up and running and connected to Twitter, which I was eventually able to do. Here is the blog post that I wrote about this. I've been documenting my work with the Photon on my personal blog for about a month, because I'm hoping to use one in a project I'm building.
This week, those in my class who are new to coding were challenged to set up the Arduino IDE on their computers and make LEDs blink, using an LilyPad Arduino. While I'm not an expert coder by any stretch of the imagination, I am not new to the LilyPad. As a result, I was invited to challenge myself. With the leeway to do something that would benefit my learning, I decided to play around with some Adafruit code written for the Gemma, pairing music with individually addressable (color changing) NeoPixels. My first experience playing with tones on a LilyPad took place two years ago, while following the tutorials in Sew Electric. Since I hadn't yet attempted to pair music with NeoPixels (or NeoPixels with the LilyPad) this seemed like an appropriate and interesting challenge.
The original code that I started with played a simple five tone tune, the theme from Close Encounters, and lit up the brim of a hat when exposed to light. My goal was to deconstruct the code (and look for patterns) to see if I could play a different tune and change the LED configurations. My tune is nothing but a scale played forwards and backwards; but, after an afternoon of puttering, I was able to get it to work on a couple of different microcontrollers, including the LilyPad.
One thing that I found really interesting about the original code was the way that the loop calls a function embedded within a function (a music function embedded within the light function). I tinkered around with the numerator and denominator in the code for the delayAmount and loopTime, to see how it changed things, but I still don't understand how the original values were derived.
Rather than taking screen shots of code from my computer, I've embedded the code using Codebender, a cloud-based Arduino plugin that makes it easy to share code.
This week in class, we continued reading Seymour Papert's book, Mindstorms: Children, Computers, and Powerful Ideas. In chapter three, addressing how math is best learned and understood by children, Papert (1980) highlights the importance of learners having a "relationship to it" (p. 65), as well as a "personal need to do something one could not do before" (p. 74). Learning driven by personal need, rather than the requirement to memorize and regurgitate, is learning that is more "powerful...general...intelligible" (p. 76). Computers, then, with their ability to help children internalize math concepts by applying theorems for the purpose of creating something they want to create, may help students learn how to learn, by allowing them to break larger problems into smaller chunks that might be applicable in their daily lives. While this book is a seminal work, providing a historical context for Papert's philosophy of constructionism (a philosophy that has notably influenced the way I approach teaching and learning), I've found my mind wandering while wading through it in its entirety.
Wishing for a fresher take on how Papert's ideas play out in our media saturated world, I turned my attention to Connected Code: Why Children Need to Learn Programming, which was published in paperback this past September. While Kafai, Y. B. & Burke, Q. (2016) actively build upon Papert, reinforcing key ideas that he advocates in a variety of publications, it goes further by making the case that coding and programming should be valued less as a form of "thinking and engaging in the individual mind" and more "as a form of participation and expression" (p. 127). This assertion really jumped out, because it is supported by prior research I've done related to media literacy and the benefits of remixing. Code is a building block of media that has the potential to influence people's thinking through their exposure to media messages, but it can also enable a citizen to construct and deconstruct their own media messages. Code is also a building block of physical objects, the design of which are also human constructions, that may also reflect certain social and political values. Not only does this book do an admirable job of articulating Papert's influences in education, using contemporary examples that are relevant in my life, it extends the conversation to some of the physical tools and materials that I find personally intriguing.
Works Cited
Kafai, Y. B. & Burke, Q. (2016). Connected code: Why children need to learn programming.
Cambridge, MA: MIT Press.
Papert, S. (1980). Mindstorms: Children, computers, and powerful ideas. New York, NY: Basic Books.
This week, we were asked to continue our exploration of visual coding by reviewing the concepts we practiced in Scratch (and a couple new ones). We reviewed the broadcast command, creating variables, and using if/else statements. Then, we were given the chance to compare Scratch with a more complex graphical platform, Snap, that allows the integration of more complex loops and functions. One thing that I learned about Scratch, that I didn't know before, is that you can create lists that may be used to substitute out different variables, such as a random interjection or greeting, to make a game seem more interesting. While I saw the immediate value in creating variables for keeping score, for example, or using broadcast to have sprites communicate with one another, I had to watch more than one video to understand why I'd want to use a list. In this game (also embedded below), I've used if statements, broadcast, and a couple of lists to vary dialogue between my sprites depending upon what was happening. The object is to use the up, down, left, and right keys to move the puppy to the fire hydrant, without touching one of the crazy squirrels. There is currently only one round to this game, but I applied a lot of new learning here (and had fun in the process).
I also continued to work through the CS First Game Design challenges, eventually completing them all.
I thoroughly enjoyed Snap's Hour of Code activity, because the scaffolding was just right. By the time I was finished, I'd learned how to program a game with a little critter that moved randomly, and kept getting faster and faster, while I tried to click him with my mouse. The game kept score, kept track of the maximum score, and would even erase the annoying drawing marks as a gift to any player who reached the maximum score. I even dreamed about this game, trying hard to remember how certain outcomes had been achieved.
We were also asked to complete some of the free tutorials offered by Vidcode, in order to compare graphical coding with text-based coding. I'd heard of Vidcode before, but I hadn't spent much time exploring it prior to our assignment. I completed all six of the free tutorials, because they were engaging and intuitive, and only took a couple of hours. I don't have a formal education in Computer Science or coding, but JavaScript seems pretty easy to learn compared with the limited bits of Python I've been trying to better understand. Text-based coding isn't a new concept for me, but I am in a place where I'm ready to dig deeper and learn more, in order to really do more with it. I like the way that Vidcode mixes coding with photo and video editing; it's a great way to teach coding concepts in manageable chunks with the possibility of creating something with a pretty funky outcome. The links to my creations are below, as well as a couple of screenshots.
This week, we were asked to pair a Makey Makey with Scratch in order to code a physical object. The link to my project, directions, and code are here. All of the characters are programmed to move and make a sound when they are triggered with the arrow keys; the space bar resets the program. I opted to use my own code, rather than remixing something. In the spirit of fall, I programmed each haunted character to move when triggered, change its costume, make a noise, and then disappear.
I created a simple controller using felt, conductive fabric, and a bit of conductive thread. It had occurred to me that I could create an interactive jack-o-lantern, but I opted for something a little more traditional to help me remember which way was up, down, left, and right.
I tacked the patches of conductive fabric to the felt with conductive thread and attached alligator clips. I put tape on the tails of the thread to keep them from flopping around and causing a short circuit.
The video below documents how the controller works.
This is the first time that I've ever connected a physical object to my own Scratch program, although I've seen it done. The most challenging part was the programming, especially getting the characters to return to exactly where they started when the space bar was triggered. I got the job done, but I need to spend more time learning about the more complex intricacies of Scratch.
Experiment with the following coding types and reply to the following prompt for each method: What do you see as the benefits of this method for various types of learners? Which type of learner are you and which worked best for you? 1.Puzzle challenges (screenshots from CODE.org dashboard that keep track of which puzzles completed).
Puzzle challenges are good for students who enjoy a hands-on way to practice a lesson while getting immediate feedback. For visual and auditory learners, the colorful puzzles and audio effects are an additional enticement. Because a student can make mistakes and keep trying, in order to learn a concept, it's a great way to practice discrete skills that build upon one another. For those who are more interested in what's "under the hood," the option to compare and contrast the block code to the actual code is available. Being able to view the actual code, and practice challenges in small, manageable chunks, is something that I enjoy about Code.org. I am particularly grateful for the hints, and the ability to keep trying new things to use the fewest number of blocks.
2. UnPlugged Activities:
Unplugged Activity 4
Unplugged activities are good for students who might benefit from more focused attention on concepts related to code. While I personally find many of the unplugged activities tedious, such as this one using graph paper, algorithms, and symbols, I'll admit that it was a good way to confirm the value of knowing how to use functions more efficiently! Many of the unplugged activities had the added benefit of being collaborative and offering students the opportunity to move around. One unplugged activity that I thought looked really fun (although I have not actually tried myself), is Create a Face, which teaches programming by having a small group use physical props and programs on cards to create an interactive face.
3. Creating Digital Games, Animations and Stories using Scratch. Add a link to your Scratch Creation (or embed it if you prefer).
Scratch is a good for people who like to make things, those who have time to debug and experiment, and those who might struggle to tell stories using print alone. The learning curve is a bit steep, and the program takes time to learn, but there is the added benefit of being able to publish, remix, and share Scratch creations with others. While my Scratch skills aren't stellar, I enjoy playing with it. I found myself aware of the time on multiple occasions, however, as it took a long time to make this simple video. One thing I wish Scratch did better was show the actual code that the blocks translate into. I recognize that I need to invest more time to understand the complexities, as I've only scratched the surface of what Scratch can do.
Of the three methods we tried this week, I think that I found the puzzles to be the most useful for my own goals of wanting to understand the concept of code and to be able to start thinking about what the actual code looks like. My second choice would be to play around with Scratch, but it seems to take much more time. The unplugged activities are my last resort.
I'm starting this blog to document my learning in the Marlboro course MAT621: Innovations in Education: Create with Code. I've embedded an Enhanced Diigo Linkroll, tagged MAT621, to keep track of items curated during this course.
