Micro:Bit Week 4A Sensor & Serial Communication

Compete a python or a Block Based code that will collect quantitative data from student solutions from a design challenge of your choice.

Challenge

Students make a small racer out of paper or cardstock. Students can modify the basic chassis to have a flat base, to add rails, or to add wheels and axels using available supplies, such as popsicle sticks, bamboo skewers, drinking straws, plastic bottle caps, etc. Then they code the micro:bit and add it (with a battery pack) to the car, placing it wherever they believe is best and using tape, glue dots, or foam squares to keep items in place.

Students race their creations on a straight track made of a piece of wood, a rain gutter, or other appropriate material. The only forces that can work on the racer are gravity and friction -- the students may not "push" the car or add other items that can generate thrust. The micro:bit records the speed of the racer as it goes down the track. It does this by tracking the change z-axis using the accelerometer (distance) as a well as the time it takes for the car to travel before crashing (time). The code automatically calculates the speed (distance/time). Students record the speed of their racer on the track at least three times and take the mean.

Then the height of the top of the track is changed either higher or lower. Students repeat the experiment, recording the speed at each height at least three times. The class compares the data and the designs used to draw conclusions on how the height of the track (and therefore the vector angle) affects the speed of the racers and how various designs affected the speed.

The Flowchart

The Code

In Action

Reflective Paragraph

This code was based on the idea of a timing gate. Usually the micro:bit would be connected to the track with two conductive lines or pads that would record when the racer, which also had conductive material on it, crossed those lines. This method is easier to code, as you can measure the distance between the lines on the track. You really just need to determine the time to takes to travel that distance.

I wanted code that was more flexible and could be used on any track. I also wanted the micro:bit to travel on the racer, serving not only as a data collection device but also as standard ballast for every racer, making the mass between racers relatively similar. This way the focus would be on the creation of the car itself and some variables would be controlled.

The biggest challenge I faced was figuring out how to stop collecting data and calculate the speed. I needed an adequate trigger. Eventually I realized that I could use the accelerometer for that, simply stopping data collection when the racer experiences a jolt at the bottom of the ramp. Of course after playing with several versions of racers, I found that cars with wheels may continue to roll rather than crash. So for version 2, I'll need to address that concern. I think I'll try the capacitive touch feature of the v2 micro:bit and place a line of foil at the bottom of the ramp to trigger the end of data collection.

The other downside to my code is that my distance unit is not at all standard in the way the timing gate example is -- using inches or centimeters. You can compare the speed calculations between racers, because they are using the same measurements, but I'm concerned it may make it hard for students to conceptualize the speed as distance over time. On one hand, for informal programs, this makes it easy for kids to focus on the results of their iterative engineering activities, because they're just looking to see if the speed increases or decreases. But for a classroom exercise, I think an activity where students calibrate the measurements of the accelerometer and translate those measurements into a standard distance would be necessary. For older students, it would be interesting to get into how we can use Pythagoras' rule to more accurately determine acceleration using multiple vectors.