Debugging physical computing

I find debugging physical computing particularly hard because you’re dealing with so many things. You’re dealing with the hardware and software. So let’s look at some of the things that can go wrong. So with the software, we’ve got your code that you’ve written, and even the most experienced programmers will accidentally create bugs in their code. A bug is an unintended consequence of coding, something we don’t mean to happen, but they happen. Here are some examples of bugs that I’ve created in my code. A common problem in programming is loops and variables. I’m going to show you this in Blocks, but this can happen in any language.

So I’ve got a loop here that’s going to repeat four times, and I wanted to display the number 1, 2, 3, 4. Let’s see what happens.

So here, the problem is that the counter wasn’t declared before we started. So MakeCode made the counter 0 by default, and that’s quite common. So when we show the counter it is 0, to fix this, we would either set it to 1 before we start, or much easier is show the number after you’ve changed it. So now, we get 1, 2, 3, 4. Another the really common problem,

especially with the micro:bit, is the radio group,

so setting micro:bit A to group one, but then not setting the group at all or setting it to a different number.

So these two micro:bits will never talk to each other. Then, there is sending the wrong number. So I send 4.

Then, the second micro:bit, I’m expecting five, so I’m never going to get that. So this heart is never going to show up. To help with radio problems and problems of naming objects, I tend to put stickers on my devices. So raspberry pis work off IP addresses, so I’ll put the IP address of that Pi on a Post-it and stick it onto the Pi itself so I know which raspberry pi I’m talking to.

Same here with the micro:bits– I’ll have the group number written on a Post-it so I know which group I’m supposed to be on. Some other common logic problems is getting all these symbols mixed up. So we say greater than 5, and the number 5 will not work here. It has to be 6, 7, 8. If you want 5 to work, it would have to be greater than or equal to 5. This is a very short sample of bugs that I’ve seen and I’ve done myself. Different programming languages have tools to help you debug. So I use a lot of test code.

So if I don’t know what a variable is at any point during the program, I print that variable to the screen so I can check it as the code is being run. You’ll see here in MakeCode that it actually has tools to tell you what the variable is at certain points during the program. So we can see the counter is increasing every time we go through the loop. And by the end of the loop, the counter is 4, but we didn’t show it before we exited the loop.

Another debug method which is quite common is to actually just talk to someone about your code to explain to them the problem and talk through each function, each part of the code, to say this is what it’s doing and this is what it should be doing. A lot of the time, even without the other person talking, you’ll figure out the problem because you’re looking at your code from a different point of view. If you can explain your code to someone else, that really helps you debug it. You also need to consider libraries. So this is code that you’ve imported into your project that someone else has written. Do you trust this code? Could that code have bugs in it?

Is this the correct library that you’ve actually imported? Onto hardware, then, so one of the big problems I have with projects is power. So overpowering a project or underpowering it or completely not switching it on whatsoever is a common problem that I have. We also have connections, so crocodile clips can come loose very easily. Things can fall off. Motors, then– having the wrong type of motor– too powerful, not powerful enough. You get servos that go 180, not 360, so having the completely wrong motor can be a problem. With motors as well, we have the power problem of underpowering them or overpowering them. I have blown up motors from overpowering them. Sensors– they can be the wrong type of sensor.

They can be oversensitive, undersensitive. Again, they could not be turned on and not sensing whatsoever. We saw that with challenge one when the temperature sensor was wrong. But it was consistently wrong, so we could fix that in the software. Lights, again, kind of comes back to power with lights. You’re underpowering them so the light is turning on, but it hasn’t got enough power, so you can’t see it. The wrong type of lights– we have red, green, blue lights, but you can also have green, red, blue. So you get green instead of red, which can be very confusing. These are just some of the examples of things that I’ve seen that can go wrong with physical computing.

Here’s some examples of big and expensive things that have gone wrong in physical computing in the real world.