This was originally posted to our makerspace forum (https://forum.makeit.zone/t/micro-bit-creatures-creating-a-kinetic-scene-with-micro-bits/818 ); any updates are most likely to arrive there first.
This project was inspired and enabled by the Element 14 Great micro:bit Education Giveaway.
I was fortunate to have our proposal selected to receive a club pack of 10 micro:bits.
My thanks to Element14 and their staff for this opportunity!
Synopsis
"We will use micro:bits- amazing small computers that fit in the palm of your hand- to create an interactive story that sense, moves, and makes sound!
Students will discover how computers can sense the real world and communicate with each other, and then how they can make motors move, lights flash, and speakers buzz. Each student will build a part of the scene, develop a program to bring it to life, and then have it coordinate its actions with the other creations."
Target Age Group
8 - adult.
As the focus will be on using the micro:bit as a tool, the same basic skills and application ideas can be applied to any student’s desired creation. As the creation is envisioned by the student, it will naturally scale to their interests and skills.
Goals
- To have fun!
- Give a peak of underlying technologies (eg communication networks, automation.)
- Use computing and electronics as a tool.
- Interaction with the physical world.
- Demonstrable creation at the end.
- Collaboration
- Of participants
- And of underlying modules/components
- Scalable
- Time goals: Adjustable from a couple of hours -> 6+ hours (after school program)
- Age goals: 8+ to adult; have most of the content be student generated
Course Outline
The initial version is targeting a three hour, half day camp:
Full outline, including hardware notes (PDF)
Using These Ideas with Students
I’ll present the results first, and some notes from using the above outline.
I presented the material to a group of ten 8-12 year olds as a half day camp. Some had used block programming environments like Scratch before, a few had heard of Arduino and Raspberry Pi (but not used them), but none had heard of the micro:bit.At the end, success!
https://forum.makeit.zone/uploads/default/original/1X/ce1c8541f37c5389a03bddada8513f1ac976fd50.jpeg
https://forum.makeit.zone/uploads/default/original/1X/ce1c8541f37c5389a03bddada8513f1ac976fd50.jpeg
However, we had some issues with the custom carrier boards I developed. I ran out of time to use M4 bolts to attach the micro:bits and instead soldered them with tinned wire. The kids noticed they were ‘bendable’ so squished them into their cardboard creation… breaking some of the solder joints. So we couldn’t continue and have the different components communicate with each other by bluetooth. But they could see how the earlier “pager” example they had developed could be easily extended to send control messages between the micro:bits.
Most importantly they had fun, understood the concepts, and wanted me to fix the boards and come back to continue.
Teaching Notes
This material really requires a micro:bit per student, especially for the first 45 minutes. I found that students who tried to pair up ended up with a more passive participant, and they often struggled to understand the concept at hand. There were “oh, aha!” moments when they tried it independently.
Movement is key to kids in this age group to keep focus and attention high.
Fortunately the room I was using had a projector just far enough away from the computers, and it was a small enough group, that we could move from the computers and make a “huddle” around the screen, illustrate and discuss the new concept, and break back to trying the next idea. I would recommend this setup, and will be looking at how I can rearrange our Makerspace to be more like this.
I start with “what is a program?” (a list of instructions; a recipe…) and then do my “very stupid robot” act, and get them to give me a program for a square- one student, one instruction. I play a very dumb robot… walking into walls, not stopping if a length isn’t given, etc.
Then, “what is a computer?”
This is enough to get them through the basic while…forever loop.
Then events/“triggers”, and having each button display a different icon on the screen.
We worked through most of this with the simulator; it’s such an immediate feedback loop that it makes initial mistakes quick and easy to find, and encourages exploration. However, it quickly starts to feel like a “dumb” game. Time to switch to the real hardware…
Then I introduced the accelerometer, and uploading the code to the microbit. Using Chrome + WebUSB made this extremely easy… once the devices were paired.
The “free fall” event, once discovered, proved very popular. The micro:bit really is quite a survivor!
At this point everyone got the basics.The first challenge was then introduced: time to work in small groups and use the radio commands to send secret text messages to each other. A quick drawing on the whiteboard to explain the radio “group” concept and showing them the colour and label of the blocks was enough to get them going. One of the students realized it’s similar concept to the “security” of FRS radio channels. Once this was understood, they all wanted to figure out each others group id and secretly listen in on each others messages.
At each 45 minute mark we took a 15 minute break for snacks, etc. During this time I introduced them to a different, but logic-problem activity. This time- Ricochet Robots. It’s a little hard to explain, but after a couple of rounds everyone starts to understand it. A nice bonus is that it’s not too competitive. The puzzle usually absorbs so much attention that no one is really keeping score.
At the start of the next 45 minute block I introduced the carrier/interface PCBs, and explained what each did.
This was the only time I provided some example code- as URLs to pre-made examples in MakeCode. The idea was to start with known-working code and debug any last minute hardware issues, like flat batteries or switches set to “off”.
Next mini-break was to introduce the building supplies- tape, popsicle sticks, paperclips, straws, cardboard, foam board, etc, etc.
And then the real challenge: use what you’ve learnt to make a scene that moves, lights up, and makes sound based on the sensors built into the micro:bit plus the ultrasonic distance sensor.
There was some confusion about how it would work, but after a little while, the idea of sending “text messages” from “spy” sensors clicked.
This particular group decided to make a waving storm-trooper that would play a different song, and different coloured LEDs, based on how far away an observer is. If you get too close the motor, with attached fan, will start and “blow you away”.
Time for another 15 minute break, some more Ricochet Robots, and then build time!
Towards the end we hit three barriers:
- a lack of time
- hardware failures
- focus starting to wander
But at the end everyone had a good time, learnt some new skills, and I was asked by more than one student where they could get their own micro:bits.
I’m really looking forward to expanding this a little and doing it again as a series of weekly events.
Addendum
Since this class, I was invited to do an event at our local art gallery. I took along some of the components developed for this course as part of our display and setup two laptops with MakeCode ready to use. Unfortunately I couldn’t convince any of the adult patrons to try MakeCode, but given the questions asked, I’m more convinced that the same approach will be appealing to adults as well. But just not in public, and with different building materials. I suspect combining this with an introduction to laser cutting might be a winning duo.
Hardware
Note: I’ve just spotted that all schematics have the Vcc voltage from the additional 4 x AA battery pack as 5V. It is of course 6V!
I quickly realized that to support the theme of using the micro:bit as a tool, or embeddable component, I was going to need some dedicated hardware. Building circuits with breadboards and alligator clips would lead to both information overload and be to fragile to include in potentially moving creations.
I decided to build 5 basic micro:bit “creatures” (hardware modules):
- Blinky (NeoPixel/WS2812 RGB LEDs)
- Wavy (servo)
- Noisy (amplifier + speaker)
- Spiny (H-bridge DC motor driver)
- Pinger (ultrasound distance sensor)
Links are to their KiCad schematics in GitHub.
This also gave the opportunity to include a secondary battery pack to supply 5V and higher current.
I opted for a simple 4xAA battery pack and to incorporate a current protection diode. The diode is not only for protecting against reversed batteries, but also to drop the 6V to a safe level for all the components I planned to use.
Unfortunately I was short of time so had to build these in-house with what was at hand; I’m sure there are pre-existing boards available that offer more features and improved reliability. On the other hand, some students were amazed that it is possible to make circuit boards yourself!
My goal was to create circuit boards that would have the required electronics, be easy to attach to a 6V battery pack, and provide a mechanically should connection to the micro:bit. I decided to limit the interface pins to P0, P1, and P2. This means code for these carrier boards will be easily compatible with bread-boarded versions. And these pins provide simple mechanical and electrical connections: M4 bolts and nuts!
I followed Chris Gammel’s advice (from the AmpHour Podcast and installed KiCad, and proceeded to re-learn schematic capture and PCB layout. Chris’s training website (Contextual Electronics and YouTube channel gave me enough clues to get going.
It was an interesting experience; easier than I expected, impressive, and also disappointing!
I was grateful that the underlying process (enter schematic, create net-list, layout PCB, generate Gerber files) hasn’t changed in 20ish years; but also disappointed that it’s not been made simpler/more obvious. But I was very impressed at KiCads ease of use, speed, and ability to do things like 3D previews.
The KitTronic BBC micro:bit CAD resources were very helpful to work out the dimensions and spacing of the micro:bit, making it a lot easier to layout circuit boards that can also carry the micro:bits.
Details for each “creature” are below.
Blinky
This is based on the wonderful WS2812 RGB LED with integrated controller. This magic little combination allows independent control of each LED wired one-to-the-other in a chain.
They’ve been well documented and supported by Adafruit, although they call them NeoPixels.
I found their reference for reliably powering and connecting NeoPixels to be essential reading.
Also, Adafruit has created an add-on for the micro:bit block programming environment! it’s super easy to add; just follow Adafruit’s instructions.
As noted in Adafruit’s documentation, the micro:bit can’t supply enough power to light many NeoPixels.
And although NeoPixels will light up with 3.3V, they’re a lot brighter when given 5V. But there’s a catch: if they’re powered by 5V, they may not reliably receive data sent at 3.3V, which is the voltage the micro:bit uses.
I didn’t have any voltage level shifters on hand, but did find some ingenious 3.3V to 5V conversion circuits- this Hack A Day page, Arduino forum posts, a StackExchange question, and this one, and a microchip ap note.
Unfortunately I couldn’t get any of these ideas to work reliably with the parts I had at hand.
But then I discovered this great trick on Hack-a-Day using a WS2812 with a reduced power supply voltage as a level shifter! The only catch is the this first “voltage shifter” NeoPixel will be a little dimmer than the others.
In the end I opted to use a second power diode to reduce the supply voltage to all of the NeoPixels to a level where the 3.3V data line from the micro:bit worked reliably. All the NeoPixels are a little dimmer, but they all have similar brightness.
The KiCad schematic files in github.
BOM
- 2 x IN4004 or similar diode
- 1 x 100 Ohm resistor
- 1 x 220 uF capacitor
- 1x 4 AA (6V) battery box, preferably with a built in switch
Schematic
PCB Layout
Example MakeCode Program
https://makecode.microbit.org/_HCqUU24HC95j
Wavy
Adding a servo was very simple. Most hobby servos will work with a 5V supply voltage and 3.3V control signal.
Pololu has a great page describing the required voltages and connections for servos.
The KiCad schematic files in github.
BOM
- 1 x IN4004 or similar diode
- 1x 4 AA (6V) battery box, preferably with a built in switch
Schematic
PCB Layout
Example MakeCode Program
https://makecode.microbit.org/_HjTcAahymCM9
Noisy
I think there is a good chance that most introductory electronics courses include the venerable LM386 audio amplifier.
I choose to implement the basic 20x gain circuit listed in the datasheet, and expanded on in this StackExchange question.
The KiCad schematic files in github.
BOM
- 1 x IN4004 or similar diode
- 1 x 5 kOhm potentiometer
- 1 x 0.022uF capacitor
- 1 x 220uF capacitor
- 1 x 10Ohm resistor
- 1 x 4-32Ohm small speaker
- 1 x LM386 Audio Amplifier IC
- 1x 4 AA (6V) battery box, preferably with a built in switch
Schematic
PCB Layout
Example MakeCode Program
https://makecode.microbit.org/_HHJhbMJPmgpb
Spiny
The goal for this “creature” is to provide continuous rotation via a simple DC motor.
As I had several LM293 drivers on hand, that’s what I used.
Given the limited number of easily accessible pins on the micro:bit, I limited my design goal to using only one of the H-bridges and control the speed and direction of only a single motor.
I also didn’t have any luck finding a pre-made add-on for the Javascript block editor, but how it’s controlled is fairly simply to explain: one pin pulses the overall power, the other two pins control if the motor wires are connected to positive voltage or ground.
This Instructable for using the LM293 with an Arduino was a great sanity check reference.
This was the most complex of the circuits to layout, but quickly proved much more reliable than a bread-boarded version.
The KiCad schematic files in github.
BOM
- 5 x IN4004 or similar diode
- 1 x small, 5V DC motor
- 1 x LM293 Quadruple Half-H Drivers IC
- 1x 4 AA (6V) battery box, preferably with a built in switch
Schematic
PCB Layout
Example MakeCode Program
https://makecode.microbit.org/_5gA97ccyHYFA
Pinger
This creature utilizes the HC-SR04 ultrasonic sensor to provide distance measurements. This sensor is sometimes called a “ping” sensor.
It can be used to detect the presence or absence of an “intruder” into the scene.
The catch with using this sensor is interfacing between 5V and 3.3V logic. Especially in this case, as the sensor’s output (5V) has to be interfaced to the micro:bit’s input; a mistake will result in too much voltage for the micro:bit, most likely damaging it.
Luckily I found a guide specifically for interfacing the HC-SR04 to a micro:bit. It also includes instructions for adding the sonar addon to the block programming environment.
Unfortunately this proved to be the most difficult board to get working. The initial sensor I used was either damaged when I built the board, or defective. A second board and sensor did work, but proved unreliable; the distance measured would often start “bouncing” between a reasonable distance value and 0. I will be coming back to this board and testing it with an oscilloscope; I suspect the 3.3V voltage from the micro:bit is not always triggering the sensor. I plan to try and catch this with an oscilloscope, or just use a level shifter IC and see if it improves.
The KiCad schematic files in github.
BOM
- 1 x IN4004 or similar diode
- 1 x 1.1 kOhm resistor
- 1 x 2.2 kOhm resistor
- 1 x HC-SR04 Ultrasonic sensor
- 1x 4 AA (6V) battery box, preferably with a built in switch
Schematic
PCB Layout
Example MakeCode Program
https://makecode.microbit.org/_aTvbgvhpJWyr
PCB Milling
We have a small ShapeOko CNC. It’s been great for carving items out of various materials, but we’ve never used it for PCB milling… until now.
It did need one last minute upgrade: a Z touch probe. For successful isolation PCB routing you really do need to map the height variation across the surface of the PCB to be milled. Luckily Chillipeppr, the software typically used with our 'Oko, has an easy to use extension that does Z-probing magic.
The next step was to figure out how to generate isolation routing g-code from the Gerber files that KiCad generates.
I found a great guide from The bald engineer’s blog. For the final conversion he uses pcb2gcode. This looks to be an amazing tool. But I opted to use FlatCam, due to the promise of a more visual environment, and being able to see and generate several steps at the same time, eg both the isolation routing and board cutout.
Unfortunately I hit some issues with FlatCAM on OS X. I ended up building from source using tomoyanonymous’s HomeBrew Tap. However there were some (more) issues that I had to quickly work-around/sort-of-fix.
But once compiled, it was easy to use, and got the job done quickly.
I’m looking forward to designing and building my next set of PCBs!
