Printing Vases with Ultimaker

Some time back I found the "Spiralize" options in the Expert settings for Cura, the slicing program that I use when I'm printing with Una the Ultimaker. This lets you take a solid object and generates a print that just wraps a single layer print round the outside of the object.

It is called "Spiralize" because the print ends up being one long spiral, with the head laying down successive layers as it goes round and round in circles. The print that you get is very thin, rather like a lampshade, but if you use translucent materials (like the  nice transparent fibre from Faberdashery) the results are rather good. 

Python Constructor Trickery

We are still doing our Python evening courses. Today we are learning more about classes. Which seems appropriate for teachers. We have been looking at how to create and manage data in program objects.

It turns out that Python is very laissez-faire when it comes to object construction (just like it is about most things). As a stalwart C# developer I find this all a bit scary. In C# you have to tell the compiler everything about the design of an object that you might like to create. In other words:

class Player

{

public string Name;

public int Score;

}

This is a C# class that I could create to hold details of a player of a game (perhaps golf or cricket). Each instance of the class will hold the name of the player and their score.  The C# compiler has been told to store a string in the Name property and an integer in the Score. So I can create objects that represent the fact that "Fred" has scored 100 runs, or whatever. And C# will make sure that the value of Name is only ever a string and the value of Score is only ever an integer. I like this a lot. It means that it is very hard for me to get my name and score storage into a mess. If I try to store a string where a number should be, for example put the value "Twenty Five" into the Score property,  then my program won't even get to run. 

In Python you can add things to any object at any time and the system pays no attention to the type of the values until a wheel comes off during program execution. 

class Player:

def writeMessage(self):

print('Nobody here but us chickens')

This Python code defines a Player class that just contains a single method that prints the message 'Nobody here but us chickens' when it is called. Fair enough, but not terribly useful. I can create an instance of the class if I want:

p = Player()
p.writeMessage()

These two statements create an instance of the Player class (referred to by p) and then ask it to print its message. Fair enough. If I want to store data in the class I can just set some attributes, and they are added automatically when the program runs. 

p.name = 'Fred'
p.score= 99

Now my instance of Player holds a couple of attributes, the name and the score of that player. I can go on and add lots of other attributes if I like. The problem is that I could end up in a mess. Suppose that I decide to mark one particular player as the captain of the team. I can add an attribute to denote this:

p.isCaptain = True

Now I can tell which one of the players is the captain, right? Well, yes and no. But mostly no and always dangerous. I might now have a situation where only one player (the one that I have marked as captain) has the isCaptain attribute. The rest of the players in my system don't have the attribute set to false, they just don't have the attribute. This will become a problem if my program ever does something like this:

if p.isCaptain:

print('hello captain')

This statement cause the program to crash if it ever encounters a player without the isCaptain attribute. A C# program would not allow this to happen, since you would be unable to create a player that didn't have the isCaptain attribute.

Python programs are easier and quicker to write because you don't have to tell the compiler everything up front, but the penalty is that they are vulnerable to errors that C# programs can't ever have. My way of fixing this is to make a constructor method for player that allows you to set the initial values there:

class Player:

def __init__(self, name, score):

self.name = "" + name

self.score = 0 + score

self.isCaptain = False

The __init__ method (yes, there are two underscores before and after the word init) is given the name and the score values and sets them into the player. It also sets a default value for the isCaptain property. I can now construct a player and set up the attributes in one statement:

p = Player('Fred', 99)

You may be wondering why I have statements like:

self.score = 0 + score

This is the trickery bit. I'm setting the score of the player to whatever the user of my constructor sent in. They could do something stupid like:

p = Player('Fred', 'har har')

In this case the score value is being delivered as a silly string, which is not what I want. But because the constructor tries to add this parameter to the integer value 0 this means that the program will fail and stop with the message:

self.score = 0 + score
TypeError: unsupported operand type(s) for +: 'int' and 'str'

I could write extra code to check for the type and raise my own exception, but this seems somehow simpler. I'm using this in all my Python constructors now. Maybe there's a better way of doing it, but I don't care because my way works for me. 

Number one son reckons that surviving in languages like Python, which are great fun but inherently dodgy, is just a matter of coding standards. This has now become one of mine. 

Computer Science and the Hour of Code

Sunday's paper had a big section on how important it is to learn to program. I agree. There was a lot of kerfuffle a few weeks ago when Lottie Dexter, a Conservative activist hired to manage a "Year of Code" initiative, admitted that she didn't know how to write software. Lots of people got very cross about that and they got even crosser when she went on to say that you can learn how to teach programming in a day or so. 

Oh well.  I think/hope that what she meant to say was that you can learn to do something useful/fun with a program and tell someone about it in one day. And I suppose that you don't need to be an active practitioner of a field to promote it. Nobody seems to expect the head of British Airways to be a qualified pilot. 

You can watch the item on Newsnight here. For me the most unwholesome aspect of the whole interview is offhand manner of the interviewer, Jeremy Paxman, who gives the impression that learning how to instruct the machines that control our lives today is somehow beneath him and that's how it should be. Oh well again. 

Of course if Lottie Dexter had said "Learning to program is very hard, takes ages,  and you need an enormous brain to be able to be able to do it" she would have been in about the same amount of trouble. I reckon I've been learning to program for the last forty years or so, and I wouldn't put myself forward as that much of an expert. But I can get useful things done. And I know (mostly) which things are impossible to do with computers.  

For me the important thing about the whole learning to program business is that if you have a go you know what you can and can't do with computers. You get a feel for what is possible and you are motivated to have a go. And maybe you'll like doing so much that you will decide to learn a bit more....

And with that I present "Rob's Things to Do if you want to learn about computers (or indeed science and technology in general)"

  • Have a go. Go to the hour of code site and have a play.
  • Don't expect to learn everything at once. One of my favourite tweets was from someone who said "It seems to have taken me around 20 years longer than I expected to become a good programmer". It won't take you 20 years to learn how to do be useful with a computer, but just like a great concert pianist is always finding new things in pieces of music and new ways to express them, programming has a lot of art in it and you are always discovering new ways to do things. But you can't ever say you've learned all there is to know about the subject. The good news though is that you don't have to.
  • Have an aim in mind. Programming is all about making things. You can't just learn it in isolation, you have to be building something. Set out to make a silly game, a clever web page, a moving robot, a musical instrument or anything that you find fun and engaging.  I'm presently trying to make some remote controlled table lights for a wedding. I've learned about a whole new branch of embedded technology and I'm still finding out new things. I'm having a great time. And I might even make some lights by the end of it. 
  • Find friends. Working together is much more fun. You can solve problems by just explaining them to each other. Join a group. Start a group. Look for STEM ambassadors in your area and find out what is going on. 
  • Keep it simple. Get something simple working and add things to it. Don't have a huge, complicated idea and then fail to make it work. 
  • Remember it is supposed to be fun. If you start to fret about whether you can make your thing work then take a step back, change what you do, or go and listen to music or play computer games for a while and then come back and try again.

I've no idea how my life would have turned out if my school hadn't pointed me at a teletype connected to a computer all those years ago. But I'm jolly glad they did. Perhaps you should take a look too. 

Using Big Led Panels with Arduino

So last week I found these Big Led Panels at Cool Components. And today I got one working. The wiring was quite fun, pushing jumper wires into connectors.  Turns out that was the easy part though. Once I'd got the hardware connected I had to get the software working. There are a couple of libraries out there that you can just download and use. But they didn't work. 

Whenever I tried a build I got loads of messages about symbols not being present in my code. I'm not sure why, but the build process seems to search the entire library structure for include files and it found some Adafruit_GFX ones in the Robot_Control folder that caused real problems. The solution was just to remove the Robot_Control folder from the Arduino libraries folder. After that the programs built and I got some stunning displays. The picture above, even after some serious tinkerage, doesn't really do them justice. 

This is a bit better, but doesn't really capture the eye-watering brightness of the pixels. The display is quite solid, but my little Arduino Uno is going pretty much flat out just to generate the colours. There was noticeable flicker during the display updates and so I think I need something with a bit more processing grunt to get smooth animation on it.

One plan is to make a coffee table, but I've just found some 8x8 inch picture frames that I think would take a panel very nicely. So maybe I put the panels in frames and turn them into works of art. Either way, great fun is being had....

Rampage Board Game

Rampage is a deeply silly game. Each player is a monster intent on wreaking havoc on a carefully set up gameboard full of  buildings ripe for destruction and citizens ripe for eating. The game moves are great (one of them involves dropping your monster from a great height onto the population underneath), but things are  balanced so that you have to carefully manage the mayhem that you make. 

We had a go tonight and it was great fun. I really like playing board games, and this is one like nothing I've seen before. 

Return of XNA

Now here's a sight for sore eyes

Now here's a sight for sore eyes

I've mentioned this before, but I think it is worthy of mention again (since I've just done it and it works really well). If you are running later versions of Visual Studio (2010, 2012 or 2013) you can now get XNA goodness onto your machine really easily. Download the files from here and then just follow the instructions in the readme. Once you have installed the four components,  run the Visual Studio Extension file (don't do this first, that will end badly) and you can get a cornflower blue screen of your very own. 

Marvelous. 

Developer Meetup at C4DI

Last night we had a Developer Meetup at C4DI. I really like these, they give you a chance to find out what other folks do with their computers. 

First up was Jon Polling, speaking on behalf of the Ruby programming language. I didn't know much about Ruby, but I know quite a bit more now. It looks like a great way to build applications, particularly the way that you can reuse code by importing Ruby "gems" that have been written by other folk. It looks like it would be perfect for writing server based stuff, although there are also toolkits for Android and ios. The syntax of the language looks interesting too, the way that you can integrate frameworks was very impressive. For me personally it looks like a solution to a problem I don't have at the moment, but if I ever have to write a hosted solution I'll be taking a closer look. 

Next up was Steve Bowman talking about Continuous Integration. This was another very interesting talk. To understand what it was about you have to first think about how people write software.

If there are several people working together they will have central code repository which holds the latest version of all the code being written. If Ethel wants to work on the menu system she will check out the code for that module, make some changes, test them, and then check her code back in again.

Every now and then a complete new version of the system is built from the code and tested. Sometimes this build process or one of the tests will fail and "break the build". Breaking the build by checking in dodgy code is seen as a bad thing, and usually involves the guilty person having to buy everyone donuts for the next week.

The problem with this model is that there can be quite a delay between the breaking changes being checked in and the fault being detected. If you only build a new version every day or so it can take a while to notice that something is broken and if there have been a large number of changes in that time it can take a while to figure out the cause of the problem. 

Continuous integration involves you having a build server which is constantly scanning your code base for changes, rebuilding your solution and testing each time new content arrives. Faulty code is detected very quickly, the person checking in the faulty code (along with the rest of the team) will get an error report within minutes.

Steve gave a demonstration of the system in action, and explained that the build server doesn't have to be one of your own computers, you can actually do all your building in the cloud by renting some space and spinning your own build server there. This also allows the build process to scale if you have a very large system and lots of developers.

Apparently people like Google, Amazon and Facebook do this kind of thing a lot. It is common practice to create and even deploy their latest code with bits of the user interface "switched off". Then, when all your tests in the field turn out OK you can switch on the new features. 

You can get started with Continuous Integration for free. Steve recommended the TeamCity platform which is free for up to 20 projects. He also made the point that the approach works very well even for an individual developer. It looks very interesting, I think I'll have a go with this. 

The third talk of the evening was by John Connolly. This was all about the awesome work that is going on between C4DI and Hull City Council. For me this was a follow on from a Meetup in 2012 when Adam Jennison and Benjamin Welby talked about plans to make available the huge amounts of data held by the council. It seems that things have moved on a bit since them. C4DI and the Council are now working together on the "City Engine" which will provide a central point of access to all this lovely data. We are so going to have to run some hackathons with this stuff, stay tuned for a proper Three Thing Thing event built around making the most of open data.

Finally Mike said a quick word about our Hardware Meetup next week. We are going to be firing up some Arduinos and seeing what we can do with them. Stay tuned for more details.

To me this all looks like the "Perfect Storm of Fun". We've got C4DI and Platform Expo providing a great environment for startups from games to data mining. We've got Hull City of Culture in 2017 to aim at, with the potential for all kinds of interesting things, and we've got the council making available tons of data to that can be combined to make ground breaking applications and services. Truly a very interesting time to be in Hull. 

Alien Banjos in Space

This year for the 08120 Programming 2 course I'm providing two coursework options. The first, as chosen by a SurveyMonkey poll, is to create a management system for the "Banjos4Hire", the only banjo hire shop in the country. The second option is a game with the title "Alien Banjo Attackers from Space". The gameplay will involve shooting musical notes at invading banjos whilst avoiding the "strum of death". I mentioned on Twitter that I could use some artwork for the game and I got this sent through from Orb 12

Amazing.

Wednesday Open Day with Light Panels

We had another Open Day today. A slightly more select gathering than the last jam-packed one. I showed off my Windows Phone remote controlled coloured light to good effect, and then I went on to mention to folks that, for some reason, I had bought one of these:

It is a whacking great big display panel, like the ones you see on the side of buildings. It is 7.5 inches across and contains 1,024 RGB leds in a 32x32 matrix. I've been playing with light panels for a while, and this one is awesome. 

The only snag is that, unlike the Adafruit Neopixel devices that I'm familiar with, on this one the led's don't remember the colour they've been asked to display. The computer controlling the panel must constantly light rows of leds in turn. repeatedly switching them to the required colour for a while before moving on to the next. If you do this fast enough you get the appearance of a steady image. This is hard work for the controlling computer, one panel would pretty much tie up an Ardunio completely.  But the good news is that there are a couple of really interesting controller chips that I've been looking for a reason to play with which should be able to drive this, and more, panels. 

First up is the Parallax Propellor, which should give me eight parallel processor cores, one of which should be able to drive a single panel. I've found a device on eBay and I'm looking forward to having a play when it arrives.

The other (and much more interesting) device is brand shiny new. It is from XMOS,  a company in Cambridge, and builds on expertise from ARM and Transputer to deliver a multi-cored device which has as its focus high performance, zero latency and total determinacy. In other words you can be sure that you will get processing power when you need it, and you can be absolutely sure how long something will take to complete. This, coupled with the raw power that is on offer would seem to make it perfect for driving these panels.

You can pick up development kits (with a processor, some inputs and outputs and access to the hardware) for around ten pounds from Farnell in the UK. The board looks quite spiffy and if you are into embedded you really should get one to play with I reckon. The XMOS web site makes it really easy to buy the board if you are in the USA, but the UK links are more tricky to track down. You can find it on the Farnell site here.

The funny thing is that I mentioned my ongoing obsession with bright coloured lights and this was seen to be a good thing by folks present at the open day. My ultimate plan, a coffee table with four of these panels in the surface, was actually lauded as a good idea. We shall see.....

A Headphone Amplifier in a Tin

I've been looking at little headphone amplifiers for a while. These are things that do a better job at driving your 'phones than the overworked, made for a price, components you find in most things with headphone outputs. To be fair, the output of my Lovely Lumia 1520 sounds splendid, particularly if I plug it into an amplifier, but as someone with pretensions to High Fidelity (tm), I thought that a little extra amplification might make things even better.

And then I found this on Tindie. I think I'm becoming addicted to Tindie, in that they have lovely stuff and buying from all over the world is very easy. Apart from the pesky import duty thing of course.

I must admit that the packaging had me won over before I looked into the quality of the electronics. The device is packed into an Altoids tin (you can choose your design) and the board is beautifully made and assembled. The total price, including import duty, is well less than a video game, and listening tests have revealed (at least to my ears) a more solid bass and clearer midrange to the sound.

If you are into sound quality, want a bit more volume to your music, or like the idea of having a tin packaged gadget like this, then I reckon they are well worth the money. 

Printing in the air

This is the kind of thing we want to see.....

This is the kind of thing we want to see.....

I found out something kind of interesting today. Turns out that if you print things which are 1 mm above the print surface they don't actually print very well. I'd designed a little plastic lid with mounting pillars and placed them on the base, but i'd left a gap of 1 mm underneath the pillars, so the poor printer tried to print them in the air, with  "hilarious" consequences. 

Thinking about this, it would be great if the design programs displayed shadows because if I'd seen the gap underneath the pillars I could have fixed it straight away.

PInball Arcade for PS4

Real or Fake?

Real or Fake?

I'm quite a fan of pinball. Not very good at it, but quite a fan. I've payed with the Pinball Arcade program on my PS Vita, but today I got a copy for the PS 4. And it is ace. It really works well on the big screen, and the implementation of the Twilight Zone table is really, really, good. I've actually played the real table quite a lot, and the emulation is very faithful. I reckon it is slightly easier than the real deal, but that is not a bad thing as far as I'm concerned.

On a big screen the program looks very good. I'm not sure how much of the rendering  power of the PS4 is actually being used by the game, but it looks very good with faithful reflections of the table design in the ball is it whizzes around,and no hint of slowdown when you get some multiball action. 

The only criticism I can make is that the game sound effects don't sound very good through "proper" speakers. This is more to do with their origins as eight bit samples I suppose, but it does detract a bit from the game. I think a bit of judicious filtering on them to remove the slightly rough sound might be a help. 

But if you are into pinball, and want to try out loads of tables and get something very close to a real experience, then this is a really good bet. 

Open Day Crew

This is the audience from today. You can see that they are all budding students, as the lecture room has filled up from the back...

We had another great audience for the Open Day today. Lots of good questions, free food and drink, and of course we gave away a Raspberry Pi to one lucky winner.

One thing did come out of discussions though and I thought I'd clarify it here. I put a lot of emphasis on programming in the introductory talk that I do. I see this as reasonable, because a lot of Computer Science is the business of telling the computer what to do, and programming is all about that. 

But what I didn't make clear is that you don't need to be able to program before you start our course. We teach you everything from first principles (and in fact the Yellow Book is written that way) and so if you have never programmed before you don't need to worry. 

One of the best parts of my job is saying to students "You must have been coding for a while" and having them reply "No, I only started learning in September..."

Making a quick Batch File

batchFile.PNG

It's not often that I get to show off my Command Prompt smarts. But now and again they are useful. The Command Prompt is the place in Microsoft operating systems where you type, er, commands. In the days of MS-DOS it was the only way that you told the computer what to do and it has survived, mostly unscathed, all the way into Windows 8.1 

Of course, in these days of touch and windows you don't often have to give commands at the console, but every now and then you do, and today I got to show off a trick that I've used for years. We were typing in long commands to start up services in the Microsoft Robotics Framework and I suggested that we make a batch file rather than type everything in each time. You can use the "up arrow trick" (press up arrow to get the previous command) but that doesn't work if you close the command prompt and re-open it, as this clears the command buffer. 

A batch file is simply a sequence of console commands that are stored in a text file and can be executed just by giving the name of the file. It has the language extension ".bat". You can run them from within Windows too just by clicking on them. 

What you can see above is a way that you can take a long and complicated command that you have typed in and convert it into a batch file.  You use a few tricks. First trick:

copy con doit.bat

This connects the console (your keyboard and screen) to a file called doit.bat. Essentially, everything I type from now on will go into this file. 

Second trick:

(press up arrow to get your command)

Remember that I said you can press up arrow to get back things you have previously typed. This works when you are copying into a batch file too. So to my recover my echo command in the above screenshot I just pressed up a few times. Once I had the command on the screen I just had to press Enter to put the text into the batch file. Note that if you want to enter a sequence of commands that you have typed into your batch file you just have to recover each one in turn. 

Final trick:

^Z

This is CTRL+Z. It tells the command prompt you've finished entering stuff into the file and want to return to typing commands. The destination (in this case the file doit.bat) is closed and then you can just run the batch file by giving the name. 

The console is a powerful thing in the command prompt. You can copy things to it (which can gives a behaviour similar to typing a file) and you can copy things from it. You can also do stupid things:

copy con con

This works, I'll leave you to figure out what it does. And how to get out of it. 

Mastering the Crimp Tool

crimptool.PNG

I spent some (oh, alright, quite a lot) of today fiddling with hardware, as is my wont. I've been buying cables with ready fitted pins and sockets on them, but last week I thought that it might be useful if I could crimp my own pins, so to speak. So I bought a crimp tool like this one.

The theory is/was that I could make up custom cables of just the right length and with just the right arrangement of plugs and sockets on each end to fit in what ever I was building. And it sort of works. There's a very useful howto on the Hobbytronics web site and by the end of the day I was able to make pretty good connections, which is nice.

Having said that, you can get ready made cables of ebay for around 3 pounds each, which give you forty connections, and so I think I'll just get this out for special occasions. It's one thing to be able to use it, but another to have to do it a lot.