April 23, 2017

Toy Piano

Some time ago Kaisla started to get interested in learning to play music. We have a xylophone with colored "keys" so I printed out a few songs with notes colored with the same colors so she could learn to play them. She learned those few simple songs quite quickly and seemed interested to learn more. I asked if she would be interested in making a piano app so she could play on the iPad, and she said that would be great.

Obviously there are a lot of piano apps already in the app store, but it's not the same as making your own. We couldn't use Scratch for this project since we wanted to run it on the iPad, so I  decided that it would be interesting to see how easy it would be to implement it with web technologies (which I'm already familiar with) and let Kaisla see what "real" code is like. This meant that I did most of the actual coding, but it was still a fun project we did together and I learned some new things along the way and Kaisla seemed to enjoy working on the app also.

We made a few different color schemes for the keys, one with the same colors as the xylophone, so she could play the songs she had learned right away. It's actually almost a year already since we made the first version of the app, but Kaisla and her little sister have enjoyed playing it so we have added more songs to it every now and then. Kaisla has even composed one song of her own, and of course wanted that we add it to the app.

Toy Piano app


You can try it out at: http://cvuorinen.github.io/react-toy-piano
Works best on a touch screen device with a large screen, such as iPad or other tablet. Also works on phones, but has less keys (only one octave) so it's not possible to play all the songs. Add to homescreen for a better experience. Works also on computer, but it's not really fun to play with the mouse.

For anyone interested in the technical side, here is a summary of the technologies used in this project: The user interface is built with React and sounds are produced with Tone.js. The notes are regular UTF-8 characters, the font is FreeSerif and the layout is constructed using CSS flexbox.
Source code available at https://github.com/cvuorinen/react-toy-piano

October 11, 2015

Stop Motion Animation with Raspberry Pi

Today we tried out a little stop motion animation with Legos using our Raspberry Pi camera and the button we connected to it.

We built a mount for the Raspberry Pi camera module, from Legos naturally. It came out quite nice and it holds the camera firmly in place. Then we set up some Lego roads, a car and some characters and planned a little how we are going to move them. Taking the pictures was quite easy with our setup since we had the separate button and the camera was attached to the Lego base plates, so we didn't have to worry about moving the camera when taking a picture.

Here is a gif of our first try (created using the awesome Imanee PHP library):


It came out OK, but there were a few issues with it so we weren't entirely happy with the result. The background is a bit messy, my hand was in the picture in some of the frames and the biggest issue was that the characters were a little out of focus which made them appear blurry.

Our camera rig, with the extra lens
(attached with blu-tack)
So I Googled around a bit about how to change the focus of the Raspberry Pi camera. And turns out it has a fixed focal length, which is nice most of the time, but for this kind of thing where you want to take pictures where the objects are closer than 50cm from the lens, they will be out of focus. But I found an easy enough solution, which was to buy a pair of cheap reading glasses with lens strength +2, take out a lens and position it in front of the camera. That way the focal length is somewhere around 20-30cm, which is much better for our purposes. And the images did come out better after that, so it was quite easy and cheap hack.

This time we also made the car come from the other direction so it doesn't block so much of the view while it's waiting. Otherwise we did it pretty much the same way. I had to try and keep Kaisla's little sister preoccupied with other things as she really wanted to help also. She did get to push the button a few times to take a couple of frames, but I had to delete some of them as she was a little bit too trigger happy with the button.

Action!


After all the pictures were taken, we moved them to my laptop with rsync and created a video using a command-line utility called ffmpeg. If you are interested in the actual commands, you can check out this great post from Raspberry Pi Learning Resources, which describes each step with a little bit more detail.

Here is the final video:



This time it came out better and we were both happy with the result. Of course there's still room for improvement, for example the lighting is a bit bad since it was evening and there wasn't a lot of natural light. Maybe we'll do some more later on, if Kaisla keeps interested in it. Or maybe we'll try creating a time-lapse video next.

October 10, 2015

Taking photos with the Raspberry Pi camera module

A few days ago I told Kaisla that I have a camera for the Raspberry Pi that can be programmed with code to take pictures, and asked if she would be interested in trying it out. She got very excited and wanted to try it right away and take some pictures.

I hooked up the camera module I had lying around (I had bought it at the same time I bought all the parts for our traffic lights project) into the Raspberry Pi and then we first tried it out by taking a few pics with a command line utility called raspistill. Kaisla typed the command as I instructed, and she wanted to name the file "perhonen" (butterfly in Finnish). First picture was funny since it was upside down, so we had to add some parameters to the command to flip the image.

It worked nicely but of course it gets quite tedious to have to type some commands every time you want to take a photo. So we decided to hook up a button so we can take pictures just by pushing it. I also had some buttons (or actually, tactile switches as they are called) and an extra breadboard (most of these parts are so cheap, it pays off to get some extra while at the electronics shop or if you order online).

Then we had to Google a bit info about how those switches should be wired, since we hadn't used them before. The switch has four legs, but turns out you only need to wire two of them to make it work.

Then we wrote a quick Python script that takes a picture when the button is pressed and saves it to a file named by date and time. After that it was fun to take pictures just by pressing the button.

We have some plans to try to do a little stop motion animation, which this thing is now perfectly suited for. Just need to build some kind of camera mount to hold it in place. I will write a new post about that in a few days. Update: here is a post about our first stop motion animation.

You can find a lot of info about these things online, but here's a good guide from the  Raspberry Pi Learning Resources.

July 12, 2015

Traffic Lights - Part 2: Coding & Building

In Part 1 we planned and did the wiring for our Lego traffic lights and tested that the wiring worked. With the wiring done, it was time to code the traffic lights sequence and build a casing that will hold the breadboard and our Raspberry Pi that will control the LEDs.

Programming the traffic lights


We already had a little experience with ScratchGPIO after our Robot Antenna project, so it was a natural choice to also program the traffic lights with. The actual logic is quite simple, and we were already familiar with it since we have been observing real traffic lights lately while driving. We had to discuss the timing a little bit, but mostly Kaisla had pretty good initial suggestions for the timings. We also had to do some trial and error with turning off the lights at correct times.

It was an exciting moment when we finally nailed it and had working traffic lights that change exactly like real traffic lights. We just looked at it for a while, and then of course showed it to little sister and mommy too.

Afterwards we also ported the logic to python so that it will be easier to run remotely on the command line, without the need need to start an X session. I did most of the typing of the python code, but we went through each line side by side with the Scratch version so we could see that it does exactly the same thing.

Building the Lego case


We had already done a kind of front panel in front of the bread board, you can see it in the image above (don't mind the bunny head, it's a speaker and not related to this project). The plan was to make the whole thing portable so that the case holds everything that's needed for it to run, including the Raspberry Pi and a power supply so there are no wires coming out and limiting the range where it can be played with. For a power supply we are using a regular cellphone USB "power bank" (that can be used to charge cellphones on the go) that I already had lying around. We also have a WiFi dongle in the Raspberry Pi so we can connect to it remotely through SSH without the need for it to be plugged in to a display or a keyboard. We also have a Lego compatible base plate in the PiBow case that we have for the RPi, so it was easy to attach it with Legos.

It was still quite hard to get everything to fit nicely so that the power cable and GPIO cable have enough free space. Also the power bank was a little tricky to get to stay in place nicely. The final thing came out quite massive in relation to just the LEDs, but that's ok. It's also quite sturdy and now it's very portable so we can easily move it around without having to plug in anything.

I already had an SSH client app in my phone that I can use to connect to it, but typing CLI commands without a proper keyboard is a little annoying so I found a better app. It's called RasPi Check and it allows you to save the connection details of the RPi and also a list of commands that can then be executed easily later.

So now we can take the whole thing and place it anywhere and then start and stop the python script from my phone with a press of a button. How cool is that!

There was a sample python script that came with the Raspbian installation called blink11.py that toggles GPIO pin 11 on and off with a one second timeout. We also copied that script and changed the pin to 13, which is the pin that our yellow LED is connected to. So now we also have a script to run when the traffic lights are "out of order".



Conclusion


We have played with the traffic lights a few times already, and even though it's just "one sided", it has worked nicely and we've had a good time. But the final product is not the most important thing, it's the project where we have again learned a lot and most importantly spent time together and had fun.

Kaisla has already asked what are we going to do next now that this project is ready, and we have a few ideas. In the parts that I got before starting our exploration with hardware, there were also some buttons (tactile switches to be exact) that Kaisla would like to use for something. So maybe we will do a button that pedestrian Legos can press to get the traffic light to change, or maybe something totally different. We'll see, but I got the feeling that she definitely wants to keep on making "things that work".





July 8, 2015

Traffic Lights - Part 1: Wiring

When we started our Raspberry Pi traffic lights for Lego cars project, we already had little experience with wiring LEDs and we started by planning the wiring. Instead of drawing the plans by hand, we used a free program called Fritzing. Fritzing is easy to use and has most common components that can be dragged and connected together to create circuits. It then automatically creates a circuit diagram, which is nice. 

Fritzing Breadboard view
Fritzing Schematic view
It was our first time using a breadboard so we had to learn how to use it. It's pretty simple, you just have to know which way the rows are connected. Most of the rows are connected horizontally, but larger boards have two vertically connected, so called power rails, on both sides. Then there are smaller ones that only have horizontally connected rows. We have one of both, but we are using the larger one for this project because it's the one that's Lego compatible, so we can build stuff around it.

After all the planning done, it was time to start actually wiring. We did a quick test to just light up one LED on the breadboard first and it worked fine. Then we just followed our plan and wired all the resistors and LEDs. We had to cut some of the jumper leads with scissors to modify their length so we got the colors just right according to our plan. Other than that it was pretty smooth sailing and Kaisla did most of the wiring, I just needed to help a little here and there.


With wiring done, it was time to test it. We obviously hadn't programmed the traffic lights yet, so we needed some other way to test that the wiring works correctly. I found an awesome Android app called GPIO Tool For Raspberry Pi that connects to RPi using SSH (which I had already set up previously) and allows to set GPIO pins on and off by just pressing buttons on the phone.

Everything worked correctly and it was fun to control the traffic lights manually with the app. If only there was a way to control real traffic lights with an app the same way!


We have already come a long way, but there's still lot of work to do. We must build a "casing" or structure of some kind (using Legos) to hold the breadboard and the Raspberry Pi and of course we must do the actual programming of the traffic lights. We have been observing the traffic light patterns while driving so we know how to do it correctly. But this is enough for now, to be continued in Part 2: Coding & Buiding.

June 28, 2015

Robot Antenna - Getting Started with Hardware Hacking

After our latest Scratch game project we haven't done much coding, just played few games like Lightbot on iPad. But since I have a Raspberry Pi, I started thinking she might like to do some coding with physical things rather than just something that's on the screen. And I would like to learn more about hacking with hardware myself, since I'm not that familiar with electronics. I talked about it with her and she got really exited and had an idea for a first project almost instantly. She wanted to build traffic lights for lego cars! That sounded like a great project, so I started looking what kind of stuff would be required for a project like that.

After Googling around a bit and brushing up my knowledge of basic electronics (that had gotten a bit rusty since I haven't done any electrical work after high-school), I had an idea how we would do it. I ordered various electronics bits and bobs from the net, such as LEDs, jumper wires, resistors, few breadboards, switches, a GPIO cable etc. You can get this stuff from pretty much any electronics shop, either online or if you have a brick and mortar one nearby. I ordered a shipment from Pimoroni since they have all kinds of nice accessories, for example a lego compatible breadboard, a lego compatible base plate for the Pibow case I already had, some colourful USB and HDMI cables and SD cards etc.

While waiting for the shipment to arrive, I talked to Kaisla about electronics and tried to teach her some basic concepts. Like what is an electric circuit, how current flows in the circuit and how we need to adjust the current to our needs with resistors and how switches work by breaking the circuit. She seemed to understand most of that pretty well and even came up with some examples from real life, like the light switches in our house. I also talked to her about how dangerous electricity can be and that we must be cautious whenever we're working with electronics. We also learned that it's important to plan the electric circuits and how it's usually done by drawing a circuit diagram and she drew a simple one with one LED and a resistor.


Robot Antenna

Before going ahead with the traffic lights project, I decided that we should try something a little more simple first. I found this nice beginner project called Robot Antenna in the official Raspberry Pi site that has lots of good learning resources. It involves a very simple circuit with one LED and one resistor and then it can be programmed using a modified version of Scratch, called ScratchGPIO, with the same familiar user interface that we are already used to with Scratch.

When we received the shipment, we were both excited and Kaisla was very happy about the things I had gotten her, like a pink SD card and a purple USB power cable. She was very pleased that she had her own memory card and wanted to decorate it with a butterfly sticker.

Before starting with the robot antenna project, we first tried if we could just light up a LED without any programming involved. The GPIO pins on the Rasberry Pi have different purposes, some need to be programmatically turned on but some have constant power output (you can read more about them here if interested). So we put together the circuit of one red LED and one resistor (we used 330 Ohm like in the instructions for the robot antenna) with some jumper wires and connected to the 3.3 volt power output pin and a ground pin on the RPi. It was an exiting moment when I plugged in the USB power cable for the first time, but the LED did light up! We then tried all the other different coloured LEDs I had bought, green, yellow and blue, and they all light up nicely (even the blue did light up without changing the resistor, even though it requires more voltage).



Next Kaisla started working on her robot. The only requirement was that it should have an antenna, otherwise it was all left to her imagination. She was sceptical at first whether she could draw a good enough robot, but after some encouragement she did it and it came out really nice and she was really pleased with it. We then cut it out and glued it to an empty kitchen paper roll and I made hole for the LED at the top of the antenna.

Then it was time to combine all of this. We needed to use one of the programmable output pins now instead of the one with constant power and we also put the RPi back into it's case so we needed to connect through the GPIO cable now. So we changed from female-to-female jumper wires to male-to-female wires for the ones that connect to the RPi. We put the wires and LED inside the robot and pushed the LED through the hole and it fit just nicely. We then booted up the Raspberry Pi (we are using the "default" Raspbian OS on it), but ran into some troubles since the ScratchGPIO doesn't come preinstalled on it and I hadn't configured the WiFi on it yet so we couldn't install it right away. I had to Google a little bit for instructions on setting up WiFi on Raspbian and Kaisla got bored. She went on to do a puzzle (one with Elsa from Frozen) while I got the WiFi set up and installed ScratchGPIO. After that we could finally do the actual coding, a very simple program at first with just a loop of 10 iterations that sets the pin on, waits one second, sets the pin off and waits another second and executes by pressing the spacebar key. With that, we had our very first program that interacts with hardware we had wired ourself. It worked as expected and Kaisla was very proud of it and wanted to show it to her mom and little sister.



All in all, it has been a very interesting first hardware project for both of us and we have both learned a lot. Next we will start planning the traffic lights project, and I'll write more about that later.

April 6, 2015

Owl flies - coding our second Scratch game

After all the graphics done and a pretty good idea how the game is going to work, it was time to start coding.

Scrolling background


I knew we were going to need a scrolling background and had some ideas how to implement it, but decided to do some research beforehand. I found this nice wiki page that explains few different scrolling concepts and we ended up using a variation of one of the solutions presented in that article. Just had to modify it a little so that it scrolls all the way from outside of the view to the other side.

Owl flies


Next it was time to add the owl. As I said in the previous post, we had two owls, one that sits on a tree branch and the one that flies. Adding the sitting owl was simple, just drag it to the correct position and scale it to appropriate size. We decided that pressing space bar starts the game, so we hide it when that happens. Because lots of other stuff also needs to happen as the game starts, I thought it would be good to implement the game start as an event that is broadcast from one place. We discussed few different analogies for the broadcasting of an event, she seemed to like the idea of sending a message by mail the most. So, when the game starts we broadcast an event "lennä" which is Finnish for "fly" (in imperative form).

The flying owl required some more coding. It needed to appear when the sitting owl disappears and then start moving. Because we have a scrolling background, our owl can remain static horizontally and only move vertically. We decided to use the space bar key for flying as well, so that the owl descends if the space key is not pressed and ascends if it is pressed. This logic required a simple loop that runs as long as the game is playing and inside it a simple if condition; if space key pressed, then move owl up, else move owl down. Also needed a small wait inside the loop so it doesn't run too fast. After that it took us some experimentation to get the right "speed" for the owl's ascend and descend and smoothness of the movement by adjusting the wait time and the amount of pixels for the movements. But it was fun to do and we had a few laughs while making the owl or the background move too fast.

Code for our flying owl.


Sound effects


Sound effects are always a fun part of creating a game. This time Kaisla wanted that I do the owl sounds and she does mosquito buzzing. We recorded the sounds in Scratch, edited them a little bit and added some to the game right away.

The owl is hungry


Now that we have a flying owl, we can finally get to the actual objective of the game: catching mosquitoes. Kaisla hadn't drawn an image of a mosquito, so we looked for one in the Scratch sprite library and found one that was good enough for our use. Maybe we will add a custom image later.

We needed multiple mosquitoes on the screen and they needed to scroll with the background (to appear staying static) so we took the scrolling logic from the background and modified it a little bit so we can set a custom starting point for the image to appear. Kaisla decided that the owl needs to catch 10 mosquitoes, but that sounded like too much to be on the screen at the same time so I thought that maybe we could have only a few sprites that we can reuse, by positioning them again after being eaten.

For this we needed to explore a new concept, randomization. After being eaten, we move the mosquito to a new position that is outside of the screen horizontally and then assign it a random position vertically. We encountered a few bugs while coding this that caused for some funny side effects, like the mosquito getting "stuck" to the owl's beak. But we finally got it working well and now the game could actually be played.

Because Kaisla is so careful about the details, she soon pointed out that there are too many mosquitoes because she had decided there should only be ten. So we needed a way to count the number of mosquitoes the owl has eaten. We had explored the concept of variables a few times before and she didn't have much trouble grasping the idea when I explained it as something like writing down a note on a piece of paper so it can be looked up later. We also discussed variable naming and I said that it's always good to name them after the values stored in them so that it's easier to understand later. She seemed to grasp this concept well and named the variable "hyttysiä syöty" (Finnish for "mosquitoes eaten").

Scratch has a nice feature where you can choose that it shows the contents of a variable on screen while playing so we didn't have to implement that by ourselves to see the value increase as intended.

Kaisla explaining the game to her little sister.


Finishing touches


We still had a few items left on our TODO list, like making the owl flap it's wings and making the owl go back to sitting on the tree branch after it has eaten 10 mosquitoes. We have since added the wing flapping effect by creating a second "costume" for the flying owl that we change in the loop. I just cut out the wings in an image editor and rotated them to create another one with the wings in a more upright position. It took a little tweaking until I got it to look good enough for her but I think it came out quite nice in the end.

We haven't done any coding for a while now and the owl returning to the branch is still not done. But we'll get to it sometime in the near future. Here is the game in it's current state, so you can check out all of the code, or just try it out. And why not leave a comment if you like it.

Update: And as I just discovered that Scratch games have embed codes, here is the game inline so you can try it out right here (if you're on a browser that supports Flash).