Tag Archives: Software

Year 10 Transition Activity at Gungahlin College

Welcome to our Year 10 transition day, and more specifically the IT Class we’ve got prepared for you.

One of the subjects we offer here at Gungahlin College is an introductory programming class that teaches you the fundamentals of how to program computers to do what you want them to do. We explore a number of different programming languages over the two years, and we’ll program a range of devices from desktop computers through to smartphones and embedded systems. The programming you do for each is a little bit different, and today we’re going to look at some of the intricacies of embedded systems programming using Arduino.

We’ve issued each pair an ed1 board, the details of which you can find here. It has been developed by National ICT Australian as a teaching tool for a couple of competitions and programs run by the National Computer Science School, and contains a whole heap of input sensors and output components that you can interact with directly. In today’s lesson, we’ll be exploring the:

To get started, you’ll need to open the Arduino IDE – you’ll find it in the Start menu under Arduino. It has been pre-installed for you and contains everything we need to program our boards. You’ll also need to collect a board and USB cable from the teacher.

When you get back to your computer, plug the board into the USB cable and the USB cable into the computer. It should light up and the board will start running the last program that was uploaded onto it. The way embedded systems work is that they store a single program that executes continuously once it has been loaded, so when the power is cycled to the board it simply restarts the program. There is a reset button on the board that also restarts the current program – find it now and press it to start the program again.

Back to the IDE – the first thing you need to do is use the Tools menu to select the:

  • Board -> Ardunio Duemilanovae w/ ATmega328
  • Serial Port -> COMX (where X is the highest number available in the list)

This ensures the computer knows how to communicate with the board, and does so over the right connection.

Now that’s done, we’re ready to start writing our first program. We’re going to start by loading a pre-written program that writes custom characters to the LCD screen – it allows us to draw whatever we want by lighting up the individual pixels on the screen. Delete everything in the Arduino IDE window, then copy and paste the code below into the window.

// include the library code:
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(6, 7, 8, 2, 3, 4, 5);

// make some custom characters:
byte heart[8] = {
 0b00000,
 0b01010,
 0b11111,
 0b11111,
 0b11111,
 0b01110,
 0b00100,
 0b00000
};

byte smiley[8] = {
 0b00000,
 0b00000,
 0b01010,
 0b00000,
 0b00000,
 0b10001,
 0b01110,
 0b00000
};

byte frownie[8] = {
 0b00000,
 0b00000,
 0b01010,
 0b00000,
 0b00000,
 0b00000,
 0b01110,
 0b10001
};

byte armsDown[8] = {
 0b00100,
 0b01010,
 0b00100,
 0b00100,
 0b01110,
 0b10101,
 0b00100,
 0b01010
};

byte armsUp[8] = {
 0b00100,
 0b01010,
 0b00100,
 0b10101,
 0b01110,
 0b00100,
 0b00100,
 0b01010
};
void setup() {

 // create the heart character
 lcd.createChar(1, heart);
 // create the smiley character
 lcd.createChar(2, smiley);
 // create the frownie character
 lcd.createChar(3, frownie);
 // create the armsDown character
 lcd.createChar(4, armsDown); 
 // create the armsUp character
 lcd.createChar(5, armsUp); 

 // set up the lcd's number of columns and rows: 
 lcd.begin(16, 2);

 // Print a message to the lcd.
 lcd.print("I "); 
 lcd.write(1);
 lcd.print(" Arduino! ");
 lcd.write(2);

}

void loop() {

 // read the potentiometer on A0:
 int sensorReading = analogRead(A3);

 // map the result to 200 - 1000:
 int delayTime = map(sensorReading, 0, 1023, 200, 1000);

 // set the cursor to the bottom row, 5th position:
 lcd.setCursor(4, 1);

 // draw the little man, arms down:
 lcd.write(4);
 delay(delayTime);
 lcd.setCursor(4, 1);

 // draw him arms up:
 lcd.write(5);
 delay(delayTime); 

}

Assuming you have now completed all of the above steps in the order specified, you should be able to click the Upload button (The little sideways arrow) and you’ll upload the program to the board. You’ll see when the program is uploading because you’ll see a progress bar on the IDE and you’ll see the little Tx/Rx lights (near where the USB cable plugs in) flicker to indicate data is being transferred and received.

When the program is finished, you should see a message on the LCD screen, and a few custom icons like a heart, smiley face and man. That’s what your program does!

But, you can also interact with it. The dial on the bottom left of the board (called the potentiometer) can be turned, and when you turn it you should see the speed with which the little man flap his arms up and down change.

Let’s take a look at the program in more detail:

// include the library code:
#include 

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(6, 7, 8, 2, 3, 4, 5);

The above code block does two things – it includes the library (the pre-written code that defines what the LCD can do) so that we can make use of it to manipulate the LCD screen more easily. Without this library, writing to the LCD can be very difficult to do. Once we’ve included it, we then initialise the LCD panel by connecting the pins on the board up correctly – this makes sure the computer knows which signals to send to which pins that connect the LCD to the rest of the ed1. The code above is only ever run once – and needs to be done first so that we can make use of the LCD throughout the rest of our program.

// make some custom characters:
byte heart[8] = {
 0b00000,
 0b01010,
 0b11111,
 0b11111,
 0b11111,
 0b01110,
 0b00100,
 0b00000
};

byte smiley[8] = {
 0b00000,
 0b00000,
 0b01010,
 0b00000,
 0b00000,
 0b10001,
 0b01110,
 0b00000
};

byte frownie[8] = {
 0b00000,
 0b00000,
 0b01010,
 0b00000,
 0b00000,
 0b00000,
 0b01110,
 0b10001
};

byte armsDown[8] = {
 0b00100,
 0b01010,
 0b00100,
 0b00100,
 0b01110,
 0b10101,
 0b00100,
 0b01010
};

byte armsUp[8] = {
 0b00100,
 0b01010,
 0b00100,
 0b10101,
 0b01110,
 0b00100,
 0b00100,
 0b01010
};

The code above creates all of our custom characters using arrays of bytes – groups of single bits of information that can take on the values of 1 and 0. Here, a value of 1 indicates that the display should show a black dot, and a value of 0 means the display should leave that pixel clear.

You’ll notice that all of the bytes in the arrays are made up of 5 bits, and that each array has 8 bytes in it. This means that each character is made up of 40 individual pixels in a box that is 5 wide by 8 high. If you look closely, you’ll see how the patterns of 1s and 0s create the shapes we’re after – the heart is probably the easiest one to see, but the other shapes are also visible now that you know what you’re looking for.

We create the custom characters at the top of the program so that they can be used everywhere we want them to be used.

void setup() {
...
}

The setup() function is run as soon as the board is turned on, and is only run once. We can put any code we want to inside the curly braces (where the … is above) and that code will be run in that order as soon as the board has power. Let’s see what we do inside our setup() function:

 // create the heart character
 lcd.createChar(1, heart);
 // create the smiley character
 lcd.createChar(2, smiley);
 // create the frownie character
 lcd.createChar(3, frownie);
 // create the armsDown character
 lcd.createChar(4, armsDown); 
 // create the armsUp character
 lcd.createChar(5, armsUp); 

First, we create the characters by assigning each of our patterns to a single integer value (a number). You’ll see that the lcd.createChar() function requires 2 parameters – the first is the number you want to use to represent that character, and the second is the character itself (so in our case, 1 will be for the heart we created earlier). We assign all 5 of our characters to a number.

 // set up the lcd's number of columns and rows: 
 lcd.begin(16, 2);

This code tells the program that the LCD has 16 columns and 2 rows.

 // Print a message to the lcd.
 lcd.print("I "); 
 lcd.write(1);
 lcd.print(" Arduino! ");
 lcd.write(2);

Using the lcd.print() command, we can write text to the LCD. The print command understands how to display each of the standard symbols on the keyboard (letters, numbers etc), so we can specify any words or phrases we might want directly to print(). Notice how we use quotes (“) around the words? That’s so the program knows we want to print those actual characters to the screen.

You’ll see that we then use the lcd.write() function, and that corresponds to our heart on the display. By specifying a number inside the brackets of the write() function, it tells the lcd to draw the custom character we set up earlier to be assigned to our number 1. Notice also that we don’t use quotes this time – the value 1 will be substituted instead of the array of bytes we made earlier.

You can mix write() and print() statements together to print a combination of custom and regular characters to the screen. It will print them in order from left to right.

void loop() {
...
}

In addition to our setup() function, we also need a loop() function to be written. The loop() function runs as soon as the setup() function finishes, but unlike the setup() function, the loop() function repeats forever, so when it it finishes it starts itself again.

Let’s see what happens in the loop function:

 // read the potentiometer on A0:
 int sensorReading = analogRead(A3);

 // map the result to 200 - 1000:
 int delayTime = map(sensorReading, 0, 1023, 200, 1000);

The first two lines of code read from the potentiometer (it is on pin A3) and map the result of the reading from a number between 0 and 1023 to a number between 200 and 1000. What this means is that when you turn the potentiometer to a zero value, the program sets the delayTime to a value of 200 (instead of 0), and when the potentiometer is at 1023 it sets delayTime to 1000. This makes it easy for us to convert one range of numbers to a more useful one. The computer automatically works out what values the numbers between 0 and 1023 take on by breaking the range up into equal parts.

 // set the cursor to the bottom row, 5th position:
 lcd.setCursor(4, 1);

 // draw the little man, arms down:
 lcd.write(4);
 delay(delayTime);
 lcd.setCursor(4, 1);

 // draw him arms up:
 lcd.write(5);
 delay(delayTime); 

}

By writing the above code into the loop() function, the program will repeatedly perform the following code:

  1. It will set the cursor to the fifth position on the second row (we count the first row/column as number 0, so the second is 1, third is 2 and so on…)
  2. It will then draw the armsDown character (character number 4)
  3. It will then wait for the delayTime worked out by the potentiometer (i.e. it will do nothing for between 200 and 1000 milliseconds)
  4. It will then set the cursor back to the fifth position on the second row, and…
  5. Overwrite the armsDown character with the armsUp character (5)
  6. Then wait for another 200-1000 milliseconds

Since the reading is taken each time that block of code starts, every time the loop gets run a different value can be read from the potentiometer, which is what allows you to alter the time that it takes for the man to wave his arms up and down.

So, thats what our code does – cool, huh? Now its your turn to do something of your own using the bit of knowledge we’ve given you today. Here are some tasks you can try for yourself, and don’t forget, ask for help if you need it:

  1. Write your own message to the LCD screen, and try centring your top and bottom rows;
  2. Make up your own set of custom characters, and write them to different locations around the board;
  3. Use the potentiometer to change between different custom characters/numbers on the screen;
  4. See if you can make the potentiometer move a character across/around the screen; and
  5. If you finish the above, ask what other activities you might be able to do.

#ACTvotes – but why does it take so long?

For those of you from outside of the ACT, you may not be aware that we’ve just had our ACT Election for our next term of government. The election coverage can be followed in a few places:

Of course, there are a myriad of other places for information too, but these tend to be the ones I use each time there is an election on I’m interested in following. This post hasn’t happened as a result of me wanting to talk about the results (although another minority government in the ACT isn’t anything new), but about the length of time it takes to get a result after each poll.

You see, the ACT has only one house of parliament (most States and the Federal government in Australia are bicameral and have a lower and upper house), and the Legislative Assembly is made up of 17 members spread across 3 electorates. As such, the election uses a quota-based system known as Hare-Clark, combined with a Robson Rotation for listing candidates on the ballot paper. As Antony points out on his blog and in the coverage on the ABC last night, the results can take a long time to finalise because:

  1. A single transferable vote method means that until all votes are distributed to lower preferences, candidates may not meet the required quota and therefore it cannot be determined who has won a seat;
  2. Robson rotation means there are a LOT of different ballot papers (since candidates are in a different order) so the scrutineering process takes longer since you cannot use the position of the preference on the ballot as an indication of who the vote is for; and
  3. Historically, the ACT always ends up with minority governments, so the cross bench needs time to negotiate with the major parties to determine who will be supported to form government.

It amazes me that we still rely on a manual count of votes to determine our winner given what computers are capable of today. Security is often raised as the reason why voting cannot occur over the Internet or via electronic means, and although the ACT has electronic voting facilities available, these are only installed in about 6 or so polling places and are used predominantly for pre-polling. So, although about 20% of the vote is entered electronically, the greater majority of votes are done by filling out ballot papers.

We’ll put the costs of printing and the environmental impact of the campaigns aside for the time being – I want to focus on the actual counting process. I’ve thought about this a lot, and one of the most frustrating things about the whole thing is that any voting system, including Hare-Clark, can be easily represented algorithmically. So, this would mean it would be trivial to write a computer program that could use the voting data to automatically determine the winner of the election in a small amount of time. In fact, one of the tasks I’m setting for some students involves writing a program to do just this, and I’m pretty confident that these Year 10 students with about a year of programming experience will be able to do just that. So, that clearly isn’t a deal breaker in terms of improving the efficiency of the process.

The biggest hurdle, then, would appear to be taking the votes themselves and converting them into an electronic format that could be used by the computer program to generate the result. If electronic voting and/or Internet voting are still a way off, then with the advances in OCR I can’t see why the paper ballots couldn’t be processed using a workflow like:

  1. Ballot papers are scanned into a computer;
  2. The OCR reads the vote to determine:
    1. The position of each candidate on the ballot paper; and
    2. The preference, if any, awarded to each candidate on that particular vote;
  3. The OCR-generated data is then displayed on a screen next to the scanned copy of the ballot paper, and is checked by 2 or more scrutineers for accuracy (this step currently takes place with paper ballots, but this approach could allow the workload to be distributed much more easily):
    1. If accurate, the scrutineers approve the result;
    2. If OCR has generated an error, the scrutineers manually correct the error, then approve the result;
  4. The accurate data is then formatted and stored in a database so that it can be read by the ccounting program/algorithm;
  5. At any stage, the votes that have been entered can be analysed using the algorithm, and this could generate not just first preference votes, but the final result of the Hare-Clark allocation based on the votes that have been collected.

Given the manual process still required to transfer the votes from paper form into an appropriate digital format, it would probably still take an evening to have all of the votes entered into the computer and processed. However, at any time during the evening, a full analysis of the outcome of the vote could be determined (based on a partial vote count) and this would make it easier for analysts like Antony Green to predict not just the parties that would win the seats, but the candidates as well. By 11pm that night, I dare say that everyone would know which candidates had achieved a quota, and by Monday morning negotiations could begin between the cross-benches and major parties with the result of the election known and confirmed.

It seems absurd to me that this kind of process isn’t already in place – not only does it make sense economically, but it’d also mean that our pollies could get on with running the place rather than being forced to wait for two weeks to determine what the composition of the parliament would actually look like.

I’d be interested to hear from people who have either been involved in the scrutineering or counting process, or from one of the analysts like Antony Green himself, to try to determine why we haven’t got a system like the one I’ve described in place already. Given it could be used for any voting system currently in use in Australia (since they all need to have defined algorithms that can easily be programmed into a computer), there has to be an incentive for the AEC to implement such a solution.

Educational developers?

I’ve been working on a web-based application recently that I intend to demonstrate to my bosses at school that would make life a whole lot easier for teachers, students and parents and at the same time provide even greater accountability to the community and the departmental office for what goes on in the classroom at a school. It’s the kind of thing that only an educator would understand the intricacies of, and it’s got me thinking – how much of a role do educators play in the development of the systems we use in schools today? And, if educators were involved when those systems were developed, how often are educators consulted or involved in the upgrade/update process?

We use an administration, budgeting and timetabling package in our schools and there are a myriad of things I don’t like about it. To be fair, there are a number of things it does well, too, and I wonder how many of the problems we do experience are related to infrastructure or configuration issues on our networks. However, all that said, I wonder sometimes if we are forced to bend, twist and re-shape what we do to fit within the framework provided by these applications, rather than them acting as tools to assist us in our tasks. I know there are a number of teachers in the schools I’ve been in that don’t want to go anywhere near the system, simply because it just isn’t easy for those who don’t understand it – the interface alone is enough to scare away the timid computer user!

So, when developing my application, I’ve kept a few things in the forefront of my mind:

  1. What I’m doing should HELP the teacher do what THEY want to do, not force them to work within a specific set of rules that forces them to change what they do;
  2. It should be easy to use and not require any specific software download; and
  3. There should be plenty of opportunities for collaboration on the software, and for feedback and comment to take place between those using it.

It’s still a little way off yet, but I hope that working on it between now and going back to school should be long enough to get a fairly robust demonstration of its capabilities finished.