Summer intern’s reflection and thoughts on teacher and student STEM computational making during our summer workshop. Learn more about the Phase 2 Summer Workshop on our About page.
by Hakeem Adeyemi
My name is Hakeem Adeyemi. I am currently a rising junior at Tufts University pursuing a double major in Engineering Psychology and American Studies. This summer I am working as a Research Intern on the Re-Making STEM research project.
At the beginning of this week’s professional development workshop at Malden High School, I was placed into a room of dreamers, inventors, and designers and I was dubbed as a Micro:Bit expert tasked with leading anyone who wished to explore the relatively new technology. I was nervous, I felt like I had enough basic knowledge to feel comfortable teaching all of the aspects of the Micro:Bit that I already knew, but I was also deeply aware that the Micro:Bit still held many secrets that I had yet to come close to discovering. I was barely confident in my ability to get a basic servo-motor moving, nevermind the almost endless amount of add-ons available to the Micro:Bit through shields and sensors, which expand the potential uses of the device to nearly limitless heights.
Two months prior to the beginning of the Malden PD workshop, I was first presented a Micro:Bit for the first time. Using the built-in accelerometer, my mentor Susan Klimczak, who works as the Program Co-ordinator at the nearby South End Technology Center, created a mini-game in which the user controls a frog as it aims to eat as many frogs as possible. I was mildly impressed at the time but if I had been shown the game again now, I would be dazzled and would be showering her with praise. Having completed a Micro:Bit project myself, I am distinctly aware of how amazing a tool is it but I can also fathom how difficult it must’ve been for my mentor to design and execute a working game.
Two weeks ago, I was first introduced to the Micro:Bit as a design tool. Amon Milner is the Assistant Professor of Computing and Innovation at Olin College of Engineering, an expert in the emerging maker field, and a member of our research team. He was tasked with teaching us research interns how to use the microcontroller. With Susan and her game, the Micro:Bit was simply a controller, a steering wheel to drive with, but at this learning session we popped the hood in an attempt to understand more of what was going on behind the scenes. At Amon’s office at Olin College, I was given a Micro:Bit to learn with. I was walked through the basics of the device, learning to transmute messages and connect a small motor.
It was nice to learn the basics of a new tool and I also missed coding because I hadn’t done any since the end of my computer science class in the spring. However, I knew that we had only begun to scratch the surface of what was possible with the Micro:Bit.
On the first day, I co-hosted a mini-Micro:Bit workshop for the participants in the room that were interested. It went relatively well up until the point when I was asked to showcase the servo-motor. As diligently as I tried, the motor would not work and left me extremely frustrated because I couldn’t understand why and I was left with no answers for the people I was trying to teach. The Micro:Bit had won the first battle and in all honesty I was left a bit dejected but I was determined to not lose the war.
As it turned out, my week brought up several other battles with the Micro:Bit. The group I was tasked with observing intended on creating community lockers that would store park equipment and would be accessible by a phone app. To do this, not only did they decided they wanted to use the Micro:Bit to control a servo-motor operated lock mechanism but also, they wanted to use the radio function heavily to have multiple Micro:Bits communicate with each other and I had never even explored that feature.
Navigating the radio aspect of the project was surprisingly straightforward. Within 30 minutes, we had two Micro:Bits sending complex messages back and forth. It was good to have a win after I had previously felt beaten by the technology but there was so still so much left to do.
Developing the code for the lock mechanism was not as straightforward. It was a multi-step undertaking that was a lot more complicated than my team originally thought. First, the Micro:Bit controlling the lock has to be engaged via radio by the Micro:Bit in the user’s hand. Then the Micro:Bit that controls the lock sends 3 randomized number to the users Micro:Bit which act as a code. Depending on which numbers are sent, the user inputs a password by using the Micro:Bit 3 input options of pressing A, pressing B, or pressing A and B at the same time. If the password is deemed correct the user’s Micro:Bit then sends a signal to the lock Micro:Bit and then at that point the servo-motor turns thus opening the box.
I remember the day. I realized it would be necessary to hard code each and every password combination into the Micro:Bit. Instead of the microcontroller being able to smoothly evaluate the password based on the users input, the code I had to write was a complex series of logicals, with a specific scenario matched with each password statements. The logical arguments were not immensely difficult but allotting for 27 unique combinations required exact precision to avoid errors but was a mind-numbing task to exact. I put on my headphones and stared down my computer screen for nearly two hours as I copied and pasted, and dragged and dropped snippets of code until I was finally finished.
Sadly, due to some technical aspects of the Micro:Bit that are still beyond my scope of expertise, the 27 different password combinations that I had painstakingly hard-coded had to decrease down to a manageable 3 combinations. The Micro:Bit required the inputs for the password faster and with more precision that we could ask our users to display, so it was very difficult to insert the password if we could open it at all. It was disappointing after spending hours of my time specifically working to code the Micro:Bit to accept 27 combinations to realize it was not feasible but to have a prototype that worked consistently made up for my disappointment.
At the end of the week I was extremely satisfied with what I had accomplished. Although we didn’t accomplish everything we set out to do because of the password setback, we still came out with a successful prototype of a remote-activated box and learned alot about the Micro:Bit. I gained a lot of confidence as a coder, teammate, and teacher. It was my first time coding as a team as I worked on the user end of the program, meaning curating the user’s interaction with the box and the code and my coding partner Cara worked on the system end of the program, meaning how the user’s actions interact with the system or in this case the locked box. Cara was a great partner and one of the most satisfying moments of the project for me was when Cara said that what she most appreciated from working with me was that I taught her coding techniques that weren’t difficult or complex but just required using extremely simple strategies to solve complex problems. I think that’s a lesson that can be applied in all aspects of life.
My biggest takeaway from my work on the Micro:Bit is that I have much more confidence using microcontrollers, block coding and even physical computational tools in general. Teaching ourselves taught us ingenuity as well as confidence in our abilities to use new technologies to solve whatever problems might arise.