Failing to Learn: Why mistakes matter
We don’t really question learning very much. As a result, it’s quite easy for us to Fail to Learn. As a reflection point for you, when was the last time you remember learning something? Can you describe what mental process was altered and changed because of this learning?
Without meta-thinking about learning, Failing to Learn can be quite common.
In running Learning Days for the past year, many people have said “I have nothing to teach.” “I don’t know anything.” It’s interesting that despite having lived for so many years, so many of us find it hard to think of something to teach.
Almost like, we’ve spent years Failing to Learn.
No fault of theirs though. The formal education we’ve received, the structure of learning I’ve illustrated above and the thought that we must be certified experts to be able to teach, all make it hard to find something to teach.
A bigger point I’d like to make though, is that learning need not follow the format above.
Let me lead you through a recent lesson I ran with Lih Wei that highlights a very different experience of learning. We will be highlighting ‘mistakes’. Do try and spot any, and see if you can figure things out before I explain it.
It can seem to get a bit technical, but do bear with it. The pay-off is worth it.
Robotics & Programming
We teach a robotics/programming class on Sunday mornings at NUS, and the current project is around building a remote-controlled car, with customizable attachments.
We’ve reached a point where we have remote-control over radio frequency, multi-directional movement, line-following modules, buzzers, multi-colored LED lights, and now integrating an ultrasonic sensor for proximity detection.
Objective: Simply put, we now want to detect distance using a sensor.
We want to try making the buzzer on the car go “BEEP” by remote control, when we wave our hand in front of the ultrasonic sensor on the joystick.
We started with a basic example, where the sensor would say ‘Ping: 10cm’ or whatever distance when it detects something in front of it.
When we ran the code, we found something strange. The Green and Yellow lights for the car started to light up, even when we didn’t press the Green and Yellow buttons.
That wasn’t supposed to happen.
All it should do was to tell us what was the distance of the object in front of the sensor but it was also making the yellow and green lights show up.
Problem: Green and yellow lights turned on, even though the only thing that should happen is that the program reads the distance of the object in front of the sensor.
Any ideas on what’s wrong?
Well…we thought back about the lights, and the situations that make them light up. The Yellow and Green lights on the car were only supposed to turn on when a ‘y’ or a ‘g’ was sent from the remote control.
We noticed that the program was sending out yPing: 13/14cm as part of the example code, when it detected our hand at 13/14cm in front of the sensor.
Any ideas on what’s wrong yet?
Well, yPing: 13/14cm, contains the letter ‘y’ and ‘g’, causing the lights to activate.
So we tried to adjust the code so that it only showed 13/14cm.
Only the distance.
It kind of worked. We ended up seeing y13/14cm being sent out.
We solved the mystery of why the lights turned on, but haven’t solved the mystery of why the ‘y’ gets sent.
The remote control was set up according to the images above.
As you can see on the left, TRIGGER_PIN & ECHO_PIN (for the ultrasonic sensor) was assigned to pin 8 as per the example code we referred to.
On electronics like this, pins are basically connections. You can see on the right that the purple wire was plugged into pin (Digital)8 on the board (it’s kind of small).
From the code on the left, you can see on line 36–39 that the Buttons were assigned to Pins 12, 8, A1, and 9 respectively. On the right, you can see those pin numbers under the colored buttons.
Any ideas why y13/14cm is being sent?
If you were paying attention, you would notice that the sensor was attached to Pin 8 but so was PIN_BUTTON_UP, the yellow button.
This was making the yellow light activate, even if we didn’t press the yellow button.
The yellow button would have sent a signal if it was pressed. Right now, concurrently, the sensor sends a signal every 50 milliseconds to Pin 8. It was as if the sensor was ‘pressing the yellow button’ every 50 milliseconds.
We changed the settings for the code and hardware, so that the sensor was attached to pin 10 instead, so it didn’t interfere with other Pins and signals.
And it worked!
We only needed to do a few small tweaks so that the sensor can trigger the buzzer sound as we intended.
tl;dr: We encountered some problems in programming our remote control, found the mistakes and made our code work as intended.
Our lessons are generally unstructured. We keep a very clear vision of what outcomes we want to achieve, but we don’t plan our lessons to the minute, as many teachers do.
As such, we encountered a few errors in our code. ‘Bugs in the code’. We then spent significant time with our students ‘debugging’ and troubleshooting, to discover what went wrong.
Essentially, we were exhibiting what problem-solving in the real world was like. The questions we asked our students, the trains of thought we put them on, helped them struggle towards a solution.
At this point, I’d like you to re-think about the title of this post.
Failing to Learn
Have we failed to reach our learning objective?
Or have we failed in order to reach our learning objective?
Just like this artwork, ‘Failing to Learn’ can have two very different meanings, and a slight flip of our perception can create drastically different interpretations and outcomes.
In taking this robotics/programming lesson forward, we have a few options.
(1) Anticipate this problem, and give clearer instructions so students won’t encounter this problem, and can achieve their project outcome more smoothly and quickly.
(2) Leave things as it is, so students can encounter this problem, and take the time to learn how it can be overcome.
Most educators would choose (1), choosing efficiency and achieving the project outcome. It’s easy to see that these problems and the troubleshooting are not part of the plan, and distract students from completing their project.
We choose instead to go with (2). Such unforeseen problems and challenges are part and parcel to life. We prefer to let our students struggle with challenges, rather than cruise towards a destination with no obstacles.
This mindset has been hard to adopt for many parents, as they resist the taboo word of failure. We will nonetheless choose to stick to our philosophy as we believe this is how we truly prepare our kids for the future.
Our robotics/programming class happens weekly, on weekday nights and weekends. Each lesson lasts about 3 hours, and we try to do 3–6 month modules where students build a real world product.
We’re also starting up another class on Game Design for the same timeframe above. This was a game a group of our students made in about 3 months, despite 0 programming experience.
Drop us a message/query at louis@praxium.co, or in a comment below if you’re interested to have a teen you know (aged 12–18) join in one of these classes!
