Coding while ill

/

Not well today. Let's just say that there's a particular room in the house that I can't be too far away from just at the moment. And I've got a horrible sore throat. What better time to write code? After all, the day can't get any worse, can it?

For some time I've been meaning to write a web programming interface for the Hull Pixelbots. I want to use MVC Active Server Pages and host the project on Azure. And today I got started on the project. I've not done this kind of thing for a while, and it was a journey of discovery in many ways. There's a very good tutorial on how to do it here. 

By the end of the day I've got the basics working, and I'm feeling a lot better. I think coding while ill works well for me.

Fibbage is Fun

/

We spent some time last night playing Fibbage. I first played it earlier in the year at David's. It's so good I actually bought a copy. It's a great party game. You need a PC, preferably with a big screen, and each player needs a device with web access. Then the game invites players to invent answers to silly questions and search for the correct one. 

And  no, I'm not saying it's good just because I won. Although I did. Perhaps those years of being a lecturer have turned me into someone good at inventing plausible lies....

Show your work to people

/

I've spent a chunk of today improving the Hull Pixelbot software. The improvements were identified when I was showing off the software at the hardware group last week. There's nothing like showing off your stuff to flag up faults and issues in it. Things that seemed like carefully thought out design decisions turn out the be horrible ways of doing things. And if you're lucky the person you're trying to impress will come up with ideas and suggestions that will make what you've building even better.

Perhaps you might be a bit afraid of doing this, but in my experience it makes a huge difference to the quality of a product to have someone take a look who hasn't spent ages living with it. 

An MP3 player for 88 pence

/

I remember when mp3 players first came out. They weren't cheap. Now they are 88 pence. Brian showed me one at the Hardware Group on Thursday.

Going to the group is always a calculated risk for me, in that people frequently show me things that I want to buy one of. Mind you, at 88 pence each I can afford to go mad and order a number, so I've bought 5. 

They can be controlled by an Arduino (or any other device with digital I/O) or directly. You'll need a micro-sd card to hold the music and a speaker of some kind of course, but I'm thinking of using them to make an orchestra of Hull Pixelbots.....

Hull Pixelbot and Meltdown and Spectre

/

There's been a lot of talk in the press about the Meltdown and Spectre vulnerabilities inherent in modern computer systems. For anyone out there who is concerned, I can confirm that there is no danger of any Hull Pixelbots being compromised by either of these issues.  

Actually, to be serious for a moment, the important thing about these two clever pieces of nastiness is that they let a naughty program read another part of your computer memory. They don't directly allow a program to attack your system.

If you happen to be running a missile control password management database at the same time as browsing the murkier corners of the internet and running a cracked copy of Photoshop then you might have cause to worry, but most people don't do this. At least, I really hope they don't.

One of "Robert's Rules" is "A system complicated to be useful will have bugs in it". A corollary (posh word) is  "A system complicated enough to be useful will be vulnerable to attack". 

That's why we wash our hands before eating, have locks on our houses and make sure that our computer has the most up to date security patches. 

Closing rings - a New Year Resolution

/

In the great spirit of "Fail early, fail often" I actually managed to break my New Year's Resolution on January the first. This was almost intentional, having crashed and burned so early in the process kind of takes the pressure off any future attempts. 

Anyhoo, the resolution was to at least complete my "activity ring" on the Apple fitness app each day. Like you can see I did last year at the end of December.

Closing this particular ring (there are three as you can see on the left) calls for a mere 30 minutes of moving about a bit. Spending an entire day on the sofa watching telly doesn't seem to fit well with this, hence the failure. 

But since then I've been a lot more busy. The latest version of the Apple watch software has a "fitness coach" mode which passes comment on your efforts and tries to exhort you to achieve more. I know that actually what is happening is something along the lines of:

if (exerciseTime < 30)
{
    print("Get off the sofa and do something you lazy person");
}

..but it does seem to be working. I've become quite fastidious about filling in the fitness ring and even hopping onto the rowing machine to top up any missing minutes towards the end of the day. Maybe I'll manage to fill in the others (energy consumption and standing up during the day) over time. 

I'm not sure that this will enable me to live longer, but I do find that with a bit of exercise my razor sharp mind is just a bit razor sharper. 

"In-band" error signalling is dangerous

/

I've been working on the Hull Pixelbot for what seems like ages (You probably think I've been blogging about it for roughly as long. Don't care. My blog.)

Anyhoo, today I learned the perils of "in band error signalling". The phrase "In-band" is a radio term. It means that control information is sent in the came channel as the data. My "in-band" errors worked like this:

int findVariablePos (char * name)
{
    int result;
     /* Stuff happens in here to find the variable  */
    return result; // return the offset of the variable */
}

The function findVariablePos returns the offset into the variable name table of the variable with the given name. In a program a variable is a named location that you can use to store data that is used as the program runs. If my program does this:

i = 99

- this is an attempt to store 99 in a variable called 'i' for no readily apparent reason. The thing running the program needs to have a way of finding out where in the computer the variable i is actually stored. That's the job of findVariablePos. Deep inside the program that actually runs the Hull Pixelbot script there is a statement like this:

int iPos = findVariablePos ("i")

The statement above (we're writing C by the way) would get me the position in the variable table of the variable with the name 'i'. "Aha", you say. "What if the program doesn't contain a variable called 'i'. ". Well, in that case the findVariablePos function returns the value -1 to indicate that the name was not found. This is kind of sensible, because you can't have anything at the position -1 in a table, negative numbers are meaningless in this context. All good. To make things clearer I even did this:

#define VARIABLE_NOT_FOUND -1

This gives meaning to the value, so that I can write tests that make sense:

if (iPOS==VARIABLE_NOT_FOUND)
{
    Serial.println("Variable not found");
}

All good. Works fine. Then I re-factor the code and add a bunch of new error codes. I then decide it would be nice to have a set of numbers that the user (and other programs) can use to make sense of error messages. And I make the following change:

#define VARIABLE_NOT_FOUND 2

This makes sense in the context of fiddling with my error numbers, but it means that if the program ever puts a variable in location 2 in the variable table, the program will completely fail to find it because every time it gets the offset value this will be regarded as meaning that no variable was found. 

Which is of course what happened. The problem in caused by a bad design decision (using the data value as a means of signalling errors) and then doing something without considering the consequences. The latest version of findVariablePos looks like this:

int findVariablePos (char * name, int * position)
{
    int result;
     /* Stuff happens in here to find the variable  */
    
    *position = result;
    return FOUND_OK;
}

The result of the call is returned via one channel (the result of function) and the position value is returned by the method setting the value of the second parameter, which is a pointer to the variable. The call is a bit more complicated:

int iPos;
if (findVariablePos ("i",  &iPos) == FOUND_OK)
{
    Serial.println("Found the variable");
}

However, it now doesn't matter what the error numbers are, and whether or not they clash with any valid variable positions. 

"In-band" error handling is great if your'e in a hurry and you're trying to keep the code simple and quick. But they also leave you open to problems further down the tracks. 

It's not always a software problem

/

I've been doing some work to try and improve the reliability of the distance sensor on the Hull Pixelbot. Not that it isn't particularly reliable, but I got to worrying about all the interrupts and timers that are going off as it takes its readings. 

I did some tests today and discovered, to my alarm, that the distance reading was being horribly affected when I turned the motors on to move the robot. This was a problem. I spent a lot of time turning on and off different parts of the software, and getting more and more confused. I'd got to the point where just turning on one port seemed to be affecting the signals on another, completely different, port. Ugly.

Then I remembered. This is hardware. Hardware is not like software. It's, well, harder. Weird things happen in hardware. Things that end with comments in the code like "I'm not sure why this statement is here, but if it isn't here the device doesn't work". 

When I turn the motors on, this makes the robot take quite a bit more juice from the power supply. If you're careful with your cash, like me, then you run your robot of the PC USB cable when you can, and keep the batteries disconnected. Which means that when the motors fire up the supply voltage takes a bit of a nose dive. Now, it turns out that my distance sensor is rather sensitive to low supply voltage, so this seems to offset all the readings.

In other words, I could fix my broken program just by turning the power on. 

3D Printing "Snap Off" Components

/

I'm putting together some Hull Pixelbot kits and one of the components that I need is a set of spacers to separate the circuit boards from the perspex base and top. You can of course buy these, but I'm too mean to do this, and I happen to have a 3D printer that I can play with. 

I wanted to print all the spacers as a single item, so that I don't have to count them into each kit. One way to group a bunch of components together is to print using a "brim". A brim extends around the base of a piece and helps it stick to the printer base. If components are placed close together the brim merges to form a single sheet which holds all the components together. This works well but it can be quite a pain to then peel the brim off the items once they are printed, particularly if the items are small, like the washers above. 

The solution I've come up with is to print a single layer which sticks all the elements together,  followed by another layer on top of that which stiffens the support layer. If you look at the picture above you'll see that the top layer doesn't go all the way up to side of each spacer, there's a tiny gap around each one. This lets you "snap" the spacer out of the base.

One other trick that I'm using with my spacers is to print the first layer of the spacer with a hole which is slightly smaller than the others. This means that the spacer will grip onto a bolt, so that they are a bit easier to fit onto the robot when you are building it. 

Hornsea in the New Year

/

Way back when we used to go to Hornsea on New Year's Day. We didn't manage it this year, the weather wasn't good enough to tempt us out of the house, but we did go today. Of course I took a few pictures. I took the one above on Hornsea Mere. I love the way that the pier creates a calm region of water on the right of the picture. This might be a nice metaphor for people in these fractious times.