Raspberry Pi for Kids: Building Virtual Robots with Code

By Richard Wentk

Part of Raspberry Pi For Kids For Dummies Cheat Sheet

Your Raspberry Pi can do lots of neat things. When you write code – it doesn’t matter what kind of code – you’re really building yourself a virtual robot to do a job you want done. The robot is virtual. It lives behind the screen instead of rolling and clanking around in front of it, bumping into things. It takes information from your keyboard, and it does what your code tells it to do, like a, well, robot.

It’s handy to understand what this robot is good at and also what it’s bad at. Here are a few things to remember:

  • The robot can only do one thing at a time. When you give it instructions, it follows them one by one. It doesn’t do them all at once.

  • Unless you tell it to remember something, the robot forgets everything. It can’t even remember what the last thing it did was. If you want it to remember something, you have to tell it to make a special memory cell. (Technically, this process is called defining or creating a variable.)

  • If you tell the robot to remember something, it won’t forget it. Not unless your code stops running when it finishes a job, or you turn the power off. Otherwise, the robot can literally remember things for years.

  • The robot is very good at math. 124 x 56791 / 3.14159? No problem! The robot has the answer almost before you’ve finished asking the question.

  • The robot can do simple things to text. This includes finding words or phrases and replacing them with other words or phrases, splitting text into sections, and counting words.

  • The robot does not understand English. Even though it can do things to text, it does them in a mechanical way. It has no idea what words mean. You can make it find and replace words in random gibberish, and it won’t notice that the words don’t make sense.

  • The robot is very precise and never makes mistakes. If you ask it to do math, it always gets the answer as right as it can. There’s no “more or less” or “near enough” or “kind of.”

  • The robot is very literal. If you ask it do something that makes no sense, it will do it – or at least try to.

  • The robot can make very simple decisions. Is one number bigger than another? Are they the same? Is this bit of text the same as that bit of text? Is it Monday today? These are simple questions with yes/no answers.

  • The robot is a machine, not a person or an animal. Think of a car engine. Now think of a car engine that does math instead of driving a car. The robot is more like that than a friendly pet.

  • The robot can’t do lots of things you find easy. You have no problem reading a book, recognizing your friends, or having a conversation about school. Code robots can’t do these things. (Really complicated robots in research labs can do them a bit, but they’re still some way behind humans.)

  • The robot has no feelings. It’s a machine, so it doesn’t have a body, it doesn’t get hungry or tired, and it doesn’t have moods. It doesn’t like you or dislike you.

  • The robot is a machine for processing information. If you can convert something – music, photos, web pages, Tweets, animations, video clips, anything – into numbers and letters, you can make a computer do something useful with it.

  • When you put all that together, programming really means two and a half things.

    • The first is defining what information you want to work with, and how it’s put together. Sometimes this is done for you. For example, music and video files all follow standards. Sometimes you have to do it for yourself. (Do you want to make art? How can you get a computer to remember a pencil stroke?)

    • The second is making instruction lists – long, detailed, precise instruction lists – that do something useful to the information.

    • What about the half thing? In some ways it’s the most important of all. When you have information and you have instruction lists, you can reuse them whenever you need to.

You’ve built a robot tool to solve a problem, and now you can use the tool over and over. For example, if you build a robot tool to draw a car on a screen in a game, you can reuse the tool to draw lots of cars. And then you can move them around without worrying about redrawing them on every move – because that problem is solved.

This is cooler than it sounds. It means you can keep building more and more complicated robots out of bits of code you write once and clip together whenever you need it.

It’s like using plastic blocks to build houses and castles, and then using castles and houses to build cities, and then building cities on all the planets in a solar system.