Tag Archives: programming

Education, Technology

Year 10 Transition Activity at Gungahlin College

Comment

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.
Education, Technology

Digital Technologies: Now a Subject in the Australian Curriculum

2 Comments

I was thrilled to see that the Australian Curriculum: Technologies has finally been made available online for all teachers to see and begin using in their schools. Sure, it is currently marked as “awaiting endorsement”, but that’s largely due to the Curriculum Review that has been instigated by our current federal minister Christopher Pyne. We’re now at a point where educators can get moving on implementation of the F-10 curriculum.

What excited me about the Digital Technologies curriculum in particular is the way that it has embraced the Digital Technologies as a way of thinking and a tool for creativity. The problem I’ve always had with the teaching of ICT in schools is that it has largely been seen as a tool that should be integrated to assist the teaching of other subjects – that’s fine, but that’s captured in the ICT General Capability in the Australian Curriculum and is very different to the study of ICT as a discipline, sometimes branded as Computer Science, Informatics, Computing or similar. Given the ubiquitous nature of ICT in our world today, it has always struck me as odd that we’ve relegated the understanding of ICT to being all about its use, rather than how it manages to achieve the “magic” that many people mistake it to be.

So finally we have some guidance for teachers, especially in the primary years, about what to teach to impress upon students the fundamental knowledge and skills required to be a developer of ICT solutions. This doesn’t mean we have to make students in Kindergarten write code in Java or anything – in fact, the Digital Technologies curriculum for Foundation to Year 2 instead focuses on pattern recognition and the classification of data in contexts that kids can understand. A significant amount of time was spent during the writing of the curriculum looking at how what students need to know to develop a strong conceptual understanding of the Digital Technologies could be integrated with what they are learning in other subjects. That’s important – it validates what teachers are currently doing to teach these ideas, or provides explicit advice to teachers about what they need to address when they design new lessons.

I accept that not everyone agrees with me – here’s a post from the Conversation written by an academic from the University of Newcastle – but on reading the article (which was forwarded to me by someone I know who has an interest in the DT curriculum), I felt the need to respond to some of the statements being made.

You can see my post in the comment thread at the link above, but I feel so passionate about what I had to say I felt the need to post it here, since I believe it stands on its own.

As an IT teacher who has the skills and knowledge to deliver this curriculum, I get a little bit frustrated about some of the ongoing concerns people keep expressing with the curriculum, largely because I feel like many of the criticisms are being made with underlying assumptions in place that need to be challenged.

The Digital Technologies curriculum does not insist that students become programmers – at least no more so that the English curriculum insists they become authors, the Mathematics curriculum insists they become mathematicians or the Science curriculum insists they become Scientists.

Many of the same arguments and/or questions about the relevance of some of the content included can be asked about other learning areas – such as the need for students to understand stem-and-leaf plots in Mathematics, or the structure of multi-cellular organisms. Look at all of the curriculum documents (and it is important we differentiate the curriculum from a syllabus – they are different things) and you’ll find that if it really came down to it, you could question the inclusion of many of the skills and/or understandings that the writers in each area have decided to focus on.

That aside, the other major consternation people have about it all is the time / crowded nature of the curriculum, however this all comes about because many commentators still insist on looking at the subjects as being independent of one another. We look at the Science curriculum and then, at school, we teach kids Science. We do the same with Maths, English… Why? How many times in the real world do we look at a problem and say “oh, that’s a problem that can only be solved by mathematics, I’m not going to consider any of my scientific or social understanding to come up with an answer”?

The curriculum has been written with the interdependence and relationships between the learning areas in mind – or at least that is my understanding. We talk about falling levels of literacy and numeracy, and then argue that this is a case for eliminating non-critical subjects from the learning of students? Surely the reason they are not engaging with school has to do with the fact that the way they are being taught isn’t working for them? It is possible to teach many numeracy and literacy concepts using much of what has been included in the Digital Technologies curriculum. Similarly, you can teach programming within the context of mathematics, algorithms as recipes in a kitchen, and data representation as an exploration of pattern recognition and language translation.

To simply look at the fact that programming has been included in the curriculum and then dismiss it due to the fact that not every kid needs to be a programmer completely fails to recognise the importance of logical reasoning and the methodical development of algorithmic solutions when faced with complex problems – a critical skill that can be developed through learning computational thinking. Not every student will end up being a mathematician, so why do they need to know about polynomials and parabolas?

And I also don’t think it is sufficient to argue that a lack of trained teachers is reason enough for the subject to be relegated to a position of less importance. The curriculum should be both aspirational and intended – it is up to schools, society and teacher-training programs to find reasons to encourage people with the skills and knowledge required to teach the curriculum to consider joining the profession. The same argument would not be applied to any other learning area – we would never say that not having enough English teachers would be reason enough to stop teaching English, would we?

The use of technology for the “thrill” of using it is fine – I’ve got no problem with people making use of the great technology available to better their lives etc. But accepting technology as “magic” is not acceptable in the longer-term if we want to continue to develop as a society. Would we be where we are today if we had simply accepted the idea that rain just happened and didn’t instead seek out a reason for it? We have the technology that we have today because people who found the passion and excitement to learn more about it did so through curiosity and interest.

We can make the Digital Technologies curriculum interesting for all students, just like we can for every other learning area. The first step in making that a reality is to stop artificially segregating the subjects and to emphasise the interdependence that exists across every discipline of knowledge. When designing a lesson or unit of work, what we need to do is look across multiple learning areas and find ways to engage students with lots of different interests – to connect what they are learning to their world.

Does this mean every child will like learning every aspect of the DT curriculum? No, just like not every child will enjoy Maths, Science or other subjects. But we can at least develop in them an appreciation of the value each discipline has, and the impact of each on their way of life now and in the future.

Oh – and on the last point re: not including Scratch (or anything else) in high school – the curriculum doesn’t do that. There is nothing that precludes the use of visual programming to teach concepts from any learning area. What has been expressly mentioned is that students learn about general purpose programming languages. These languages are different when compared to drag-and-drop type visual languages because they allow us to perform significantly more computation than is possible otherwise. They are important, but that doesn’t mean that other, more familiar platforms or languages can’t be used to address other aspects of the curriculum. I use a similar technique to explore recursion with my students, producing fantastic looking artwork using Context-Free grammars and exploring randomness as well (which is a nice way of visualising genetic mutation).

We need to stop looking at movement through the bands as discrete periods of learning – it is a continuum and the learning that takes place in earlier bands should be used as the foundation for learning in later ones.

I’d be very interested to hear the thoughts of other educators of all disciplines on this issue and those like it. Please join the conversation and post your comments below – this is one of those topics I’d love to see start a very interesting, ongoing dialogue.

Life

#ACTvotes – but why does it take so long?

3 Comments

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.