Personal Blogs

This is a quick summary of a meeting that occurred on Saturday 27 June 2015 at the university's London regional centre.  The aim of the meeting (or session) was to think about a thought experiment, namely, 'what should the perfect OU Live session look like?'

If you've stumbled across this post via a search engine, then I should (perhaps) say something about what OU Live is: it's a tool that tutors can use to deliver on-line tutorials to their students.  Think of it a bit like Skype with a whiteboard and a bunch of other useful controls (such as a 'happy face' button).

This session was attended by around twelve experienced associate lecturers, all of whom had used OU Live quite extensively with their students. 

This, in essence, is what they said a perfect Computing/ICT session might look like.  (One point to bear in mind is that other disciplines might run slightly different sessions - but more about this later!)

Setting the scene

Firstly, the moment we click on our OU Live room, OU Live should open in an instant.  There should be no delay!  We don't have to download anything extra (or enter any really annoying administrative passwords).  The Java software, which we need to run to use OU Live, should always work perfectly.  We should never have to upgrade it!

With the perfect OU Live session, not only will we have a perfect internet connection (which will never go down), our students will have a perfect internet connection too!  Our connection will be really fast (with little or no latency), and none of our students will be connecting up to our session whilst travelling by train.  An important point is: there will be no delays. 

We should also assume that all students have their own microphones and headsets, all of which are perfect.  This means that there is absolutely no feedback.  Of course, our own audio setup works perfectly, and there are no other software products battling to use our computer's audio channel.

The perfect time, length and group

We decided that the perfect time for the perfect OU Live session would be towards the middle of a module presentation (or, roughly half way through).  This means that, of course, everyone is making pretty good progress, and all students are now familiar with the OU Live interface.  Also, everyone has, what I call, good 'mic hygiene'. This means that students don't leave the microphone switched on (so other students can't speak!)

One important thing to say about our 'perfect group' is that they're all willing to interact; they're all engaged.  No one has kids in the background vying for attention, and there are no cats jumping on keyboards.

A 'perfect size' for an OU Live group would be considered to be around 10-12 students.  Since there would be no technology problems, there won't be any drop outs.  Also, everyone arrives exactly on time.  There will be no one arriving half way through the session asking, 'what have I missed?', or 'could you just go over that bit?'

Ideally, all the students who turn up would belong to our own tutor group.  This way, we know who they are and what their learning needs might be.

Our view was that our perfect session should last anything between 60 and 90 minutes.

(One thing that we didn't talk about was the best time to hold the perfect tutorial)

The perfect preparation

Preparation can be considered from two different perspectives: the tutor's side, and the student's side.  A tutor might prepare by, perhaps, doing a practice run through.  A tutor could also post a copy of a draft agenda on a tutor group forum.

Of course, in a perfect situation, all students would read the OU Live session agenda, and take the time to prepare for the session, which might mean having read sections of module materials, and having some questions to ask the tutor at the OU Live session.

Another thing that we could do to help with our preparation is to ask all our students in advance what topics they would like you to cover.  Since every student reads every message you post on the forum, you're able to design a session that is just for them.

The perfect OU Live tutorial structure

Since we're running 'the perfect session' in the middle of a module presentation, we can dispense with the idea of running any icebreakers: all the students should know each other already.

In our perfect session we would present a short introduction which relates to a set of really clear learning objectives.  This would be followed with a series of short interactive activities (say, around three).  These activities, of course, would be entirely appropriate for OU Live.

Since we (of course) would have planned out everything (and have a backup plan!) we would know how long each activity should take (also, in a perfect world, we would have run the session before, so we know what to expect!)

Towards the end of our tutorial, we would ask all students if they had any questions about what has happened.  We would then do a quick recap of what has happened, and remind everyone about the next TMA cut-off date.  We would also say something about what is going to happen in the next OU Live session (or module activity).

The perfect use of OU Live features

During our session, we chatted about the perfect use of various OU Live features.  One thing we discussed was the importance of polling, i.e. asking our students to respond during a session; students clicking on the 'tick' or the 'happy face' icon.   One suggestion (which was apparently given as a part of Blackboard training, the company that has created OU Live) is to poll students every 20-30 seconds.  Polling will allow you to keep the students engaged; it enables you to check whether everybody understands all the points that you are making (which is important since there's an obvious lack of visual cues).

Even though all students will have perfectly working microphones (with no crackle, delay or feedback), the text chat channel is still considered to be useful.  Students can ask for clarifications.  It can also be used to share links and other resources.  (Such as links to the OU study guides).

During our activities, we might want to use breakout rooms.  Of course, all our breakout rooms will work perfectly!  (There won't for example, be a situation where one student has a microphone and another hasn't)  We would be able to set a timer and move between different rooms, checking on what is happening in each of the sessions.

One of the things that we can't do in breakout rooms is to make a recording.  A related question is: 'should we record our perfect OU Live sessions?'  Different tutors have different opinions about this.  On one hand, a recording of an OU Live session becomes a useful (perfect) resource (that could be potentially referred back to, perhaps during the revision period).  Alternatively, if we record a session, students might argue that they don't need to turn up.  Also, if students know they're being recorded, they would be reluctant to speak.  (This is clearly an issue that is going to be debated for quite some time; there are clear arguments either way).

All tutors have used the application sharing feature of OU Live to show students how to use features of the programming tools that they need to use.  In the case of TU100, this is the Sense environment.  In the case of TM129, this would be RobotLab.  Sharing an application can allow the tutor to ask students some questions to determine whether they understand certain concepts.  It can also be used to demonstrate what happens when you run some code, and also how to begin to use different debugging strategies.  You might also give control of the application to students, so they can demonstrate their skills.

Of course, in a perfect world, the application sharing feature is really responsive!  (One comment was that, in the real world, we might use quite a small window, since this uses less bandwidth)

After the perfect session

At the end of the session, you would post a copy of the slides to your tutor group forum, and share any other resources.  A tutor might also post a number of follow up questions or activities, and the date and time of the next session.

Closing thoughts and acknowledgements

Before running this meeting I had never explicitly asked myself the question of 'what does a perfect OU Live session look like?'  Instead, I had worked on instinct: trying something out, and then reflect on whether it seemed to work or not. 

I found it really useful to hear everyone's opinions and views about what makes a good session.

During our meeting, I remember there was a conversation about OU Live examples.  I've managed to dig out the resource I was once told about.  It's called:  Teaching with online rooms (OU VLE). The page contains a set of different OU Live examples that have been created by tutors who are working in different disciplines. For those who teach programming and computing modules, the 'writing and running simple code' is a really interesting link.  The other resources about level 1 and academic referencing, and study skills are useful too.

I would like to personally hank all the tutors who attended this session for their contributions: everyone who was at the London region on the afternoon of Saturday 30 June contributed to discussions and ideas that led to the writing of this quick blog.  Thank you all!

On 8 November 2014 I attended the South East region (region 13) associate lecturer development conference held at the University of Sussex.  I felt that this was a really important event to attend, since it was to be the ‘final’ conference that was organised from the regional centre in East Grinstead.  All future conference would be run from the London region that has been re-christened as ‘London and the South East’.

One of the main reasons I wanted to go was to meet some of my colleagues who were leaving the university.  In some ways, it was a really sad day, but in another way, it presented an opportunity for the AL community to offer loud and vociferous thanks for all the great work colleagues from the region had carried out over very many years.

MCT session

The first session of the day was spent in our faculty groups.  The MCT session addressed three topics.  Other than details about the impending closure, the first topic was about changes to AL line management.  The second was about the development of a Group Tuition Policy.  The third and final section was a talk from an AL colleague about a research project about the use of language.

Changes in line management

A really important item was that the line management for some associate lecturers is changing.  What this means is that a line manager for a tutor might be located in a different part of the country.  The reason for this change (which is taking place in the Engineering and Innovation and the Computing and Communications department) is that a line manager will become increasingly specialised in terms of the subjects and topics that they look after.  I view this as a really positive thing: it has the potential to allow line managers (staff tutors) to respond to both student and tutor queries more quickly and efficiently, and enable them to develop more expertise in a smaller number of courses.

Group tuition policy

The university has been working on something called a ‘group tuition policy’.  From my reading of the policy, it seems to have two main objectives.  The first is to offer students flexibility and choice, i.e. they can choose to attend either on-line or face to face tutorials.  The second is that by grouping different sets of students together, it is hoped that tutors end up with more busy tutorials, and this can have a positive effect for everyone: more students means more opinions, which then can mean more learning.  One of the ideas is that students are given information about learning events before a module begins.  To make the policy a reality the university has to make some changes to its tutorial finder system.

During the session we looked at the policy and had a discussion about what we thought about it and how it might potentially impact on our tutoring.

Language use and retention in TU100

The final part of the morning session was presented by Associate Lecturer Heath Morris who tutors on TU100 My Digital Life (OU website).  Heather has been working on a university funded project that has been looking at the use of language in correspondence tuition, in particular, the summary comments that are provided by tutors.  TU100 is a particularly important module since it places quite a bit of emphasis on the development of skills, such as numeracy and academic writing.  OU students can come from very different background, which makes this aspect of teaching and learning all the more important.  The main question is: how do tutors use language and in what way might this language affect students?

Heather mentioned something called an ‘appraisal framework’, which I think is a framework used to assess the types of language used in assignment feedback.  I’ve made a note that it comprises of three different aspects: affect (which conveys emotion), judgement (which is an evaluation of behaviour or work performed) and appreciation (evaluation).  Other key words that I’ve noted from Heather’s presentation include student tenacity (which relate to the evaluation of effort?), and student capacity (which relates to the evaluation of capability). 

A set of questions for the research project are: does the use of language affect performance and retention?  Do those who score low leave?  To what extent would more positive feedback be useful?  Would it helped if we had just decided to give students a ring on the phone to have a chat with them?  What tools or checklists might be useful?

My own view on the language question is that surely good language and detailed explanations can have a positive effect on student retention, but there’s a big difference between having a gut feeling about something and actually showing something empirically.

I thought Heather’s presentation was great.  I would really like her to run a similar session in the London region.  Another thought was: perhaps we could run an AL development event that is specific to TU100 that covers the use of language and also lets us discuss the group tuition policy.  The underlined a simple outcome from attending these AL development conferences: they expose us to new things and help us to come up with new ideas that will help both tutors and students like.

Workshop: Scientix: the community for science education in Europe

The first workshop I went to was ran by Richard Walden.  Richard’s session was split into two parts.  The first was about an EU funded project called Scientix (project website) that he was involved with.  The project is described as an initiative to create a ‘community for science education in Europe, promotes and supports Europe-wide collaboration among STEM (science, technology, engineering and maths) teachers, education researchers, policymakers and other STEM education professionals.’  Scientix offers training resources, access to research, information about applications and opportunities for networking.  There’s also a link to something called the European School Net (EUN website) which I had vaguely heard of before.  If you’re interested in STEM teaching, both sites might be worth having a quick look at.

The second part of Richard’s session was all about how to improve student’s scores in tests without doing a lot of extra work.  To prepare us for this section, he split us into two groups: one group was asked to write about what we did on holiday, and the second group was asked to write about the anxieties that we might feel if we had to go ahead and complete a time limited quiz.  We were then all given a quiz to complete.

The idea was simple, and draws on research by a researcher called Gerardo Ramirez (UCLA website) : by writing about our exam anxieties, we explicitly articulate them, and this can help them to be reduced.  High levels of exam anxiety, can, of course, drastically affect exam performance.  There is an equally simple theory:  if we’re anxious, we occupy our short term memory with our anxieties. Since our short term memory is strictly limited, this will impact on our ability to understand and work through exam questions.  Short term memory, we were also told, is really important when it comes to retrieving essential information from long term memory.  (Having studied aspects of cognitive psychology many moons ago, I found all this especially interesting).

If you’re interested in this subject, I’ve also dug out the following YouTube lecture (YouTube) by Sian Beilock (who Ramirez’s co-author) who talks about some of the science behind this research.  (It’s quite a long video; there may well be some shorter videos out there).

Richard’s reason for sharing this research was simple: perhaps it’s worthwhile telling our students about this research, and the potential benefits that writing about fears and anxieties may provide.  I think it’s a great idea.

Modelling reflexivity in the teaching-learning relationship through distance learning tools

This final workshop of the day, facilitated by fellow tutor, Emily Skye, was rather different to all of the others.  I was attracted to it due to the word ‘reflexivity’ in the title; it was a term that I first came across when I was studying some social science modules, but my memory of it and how it could be used was a bit rusty: I was looking for a refresher.  Straight away, I discovered that the workshop had a very different structure: it was more of an open facilitated discussion rather than a formal ‘talk’.  All participants sat in a rough circle and shared something about ourselves, why we found this particular session of interest, and also something about our understanding of the term reflexivity.

I soon learnt that it might well be one of those terms that has different definitions based on the context it is used.  In essence, I understand that it is about understanding and thinking about yourself and how it relates to a particular context; it is about being self-aware.  It also relates to your own identity.  You can, for example, very easily hide behind a label that is attributed to a role or profession.

Being self-aware, and thinking about our effect on others (and how we are thinking about others) has the potential to help to inform our teaching and learning.  Through selectively sharing, we have the potential to build up trust, which can help us to encourage learners to look at new subjects, issues and areas.  Also, being reflexive also allows us to acknowledge the difficulties of learning, to be empathetic towards the challenges students face and connect with the emotional perspective of learning.

One of the big challenges in the distance education context is the extent to which we are able to relate and understand our students, especially when our interactions may be limited to only key points during a module presentation.  I introduced a term from computer (or, perhaps human-computer interaction) which was: emotional bandwidth.  When we interact with each other through on-line tools such as discussion forums we can easily misunderstand situations and expressions of emotion.

I found this session especially interesting because it was so different to the other sessions I had been to before.  Although I was initially rather worried by the layout of all the chairs, I quickly became relaxed.  It was also great to learn a little bit more about some of my associate lecturer colleagues.

Final thoughts

Like many AL development conferences that have been run by Region 13, this one went very smoothly.  Delegate packs were organised, there were clear signs on rooms, and it was exceptionally well attended.  One part of the day stood out for me, and this was when the Associate Lecturers gave the staff at East Grinstead a standing ovation to both thank them for all their hard work, and to recognise the work that they have given to the university.  There were tears.  I’m glad I was able to be there.

Not only did I learn new things, I took with me some idea that I then transferred to the London AL development conference that was running the following week.  This just went to emphasise my view that regional difference and diversity was (and is) a good thing.

The first Open University Sense Workshop was held at the London School of Economics on Saturday 11 November 2012.

Sense is a computer programming language that has been derived from Scratch, a language that was developed by Massachusetts Institute of Technology.   The aim of the Sense workshop was to allow TU100 My Digital Life students to become more familiar with the Sense environment helping them to learn some of the fundamental principles of computer programming.

This blog post is intended as a summary of the first ever Sense workshop.  It has been written for both students and tutors. If you feel that anyone might find this summary useful, please don't hesitate to distribute widely.

Introductions

The phase 'computer programming' is one that can easily elicit an anxious response.  Programming is sometimes seen as something that is done through a set of mysterious tools.  The good news is that once you have gained some understanding of the fundamental principles of programming (and how to tackle problems and debug programs), the skills that you learn in one language can be transferred between other languages.

Sense is a programming language that uses the same fundamental concepts of languages that are used in industry (such as C++ and Java) but Sense makes the process of writing computer programs (or code) easier by allowing programs to be created from sets of visual building blocks. In some ways, Sense is a visual programming language that is completely analogous to many other languages.  The fundamental difference between Sense and other languages is that it helps students to focus on the fundamental bits of programming by shielding new programmers from the difficulty of writing program instructions in a language that can be quite cryptic and difficult to understand.

The overarching intention of the Sense workshop day (that is described here) was to demystify Sense and encourage everyone to have fun.  The Sense environment allows programming instructions to be manipulated as a series of lego-like blocks.  These snap together to form 'clumps' of instructions which can be attached to either a background (or stage, where things can more about on), or sprites (which are, in essence, graphical objects).  Through Sense it is (relatively) straightforward to create sets of instructions to build simple animations and games.

The workshop is divided up into three different sections.  The first is a broad overview of some of the ideas about programming, followed by a demonstration about how to use the Sense environment.  The second section was a presentation which contained some useful guidance about how to complete an assignment.  The third section was more open... but more of this later.

The lecture bit - stepping towards programming...

The workshop kicked off by a talk by one of our Open University tutors, Tammy.  Tammy made a really good point that 'we can't teach you programming'.  The implication is that only a student can learn how to do it.  The best way to learn how to do it is, of course, to find the time to play with a programming environment and to tackle, head on, the challenge of grappling with a problem.

Tammy asked a couple of people to come up and draw some shapes on the whiteboard.  Different participants drew very different shapes despite being given exactly the same instructions.  The point of the exercise was clear: that it is absolutely essential to provide sets of instructions that are both completely clear and unambiguous (as otherwise you may well be surprised with the results that you come back with).

Tammy talked about the different categories of program instruction, which were: sequence instructions, selection instructions and iteration instructions.  Pretty much all programs are composed of these three different types of operations.  Put simply, a sequence of instructions is where you do one thing after another.  A selection operation is where you make a choice to do something depending upon the status of a condition (for example, if you are cold, you might turn the heating on).  An iteration operation is where you do something either a number of times.

These sets of operations can be used to describe every day actions, such as making a cup of coffee, for instance.  This simple activity can be split into a sequence of steps, which can include iterations where we check to see if the kettle is boiling.  (We might also do some parallel processing, such as making some toast whilst the kettle is boiling, but multi-threading is a whole other issue!)

The main points were (1) programming cannot be taught, it can only be learnt by those who do it, (2) there are some fundamental building blocks that can be combined together and nested within each other; you can have a sequence of steps within an iteration, for instance, and (3) programming requires things to be defined and described unambiguously.

The demonstration bit - creating an animation...

The second part of the morning was hosted by Leslie.  Building on Tammy's summary of programming Leslie showed us what it meant to actually 'write' a program using the Sense environment.

In some respects, you can create anything within the Sense environment.  It provides a set of tools and it is up to you to come up with an idea and figure out how to combine the pieces together to do what you want to do.  In some respects (and getting slightly philosophical for a moment), you can define a whole universe or a world in software.  You can, in effect, define your own laws of physics.  I can't remember who said it, but I have always remembered the phase, 'the universe is mathematical'.  Given that computers only understand numbers, the Sense environment allows you to create and represent your own universe (and interact with it in some way).

Leslie's universe was a fishtank.  She began by drawing the tank, including water weeds.  She then went onto draw a set of different fish characters.  Script was then added to move the fish around the screen (in the tank), first in one direction (from left to right), and then in both directions (from side to side).  Leslie then added more characters and defined interactions between them using something called the 'broadcast' feature to alert some of the virtual fish that a bigger and more dangerous fish had arrived in the tank.

What was really great was how she demonstrated how to connect different instructions together (to create sequences), to have sequences of instructions operate when certain conditions are met (which represent selections), and introduce repeat loops (which represent iterations; carrying out the same instructions over and over again).

The bit about the assignment...

The final 'lecture' part of the day was by Open University tutor Dave, who took everyone through the structure of the forthcoming assignment (without giving any of the answers).  Dave talked about the use of the on-line discussion forums and this gave way to an interesting discussion about the importance of referencing.  Other points that were mentioned included the importance of things such as including word counts (on the TMA), and the learning objectives that are used by the module.

The programming bit...

During the afternoon, we all split into two different groups and got together into small groups of between two and four people.  The intention of the second part of the day was to try to create a small Sense project by huddling around a single laptop on which the Sense environment had been installed. We would then work on something for an hour, and then we would present what we had done to the other groups, describing some of the problems and challenges that we had encountered along the way.

Not having had much experience at using Sense, I was very happy to play an active role within one of the groups.  One of my main intentions at coming along for the day was to learn more about how to use the language and discover more about what it was capable of.  Our group came up with two different ideas: a representation of a car race track and some kind of athletic game or animation.  We settled on the athletic theme and decided we would try to animate a man running around a very simple athletics track.  (Our track became a square as opposed to an oval shape since we decided that re-discovering the mathematics of the circle was probably going to be quite tricky to master in about an hour!)

Within an hour we had drawn some stick figures, got our character doing a really simple 'run' animation and had our figure run around a really simple athletics track.  From memory, one of the challenges was figuring out how to represent program state and have it shared between different scripts that were running within the same sprite (apologies for immediately going into Sense-speak!)  Another challenge was to figure out how to represent state with Boolean variables and have those embedded within a continuous loop (but given enough time, I'm sure that we would have cracked it!)  A final challenge (and surprise) was to understand that the Sense environment automatically 'remembered' how much a character had been rotated between the different times that we 'ran' our scripts.  (We had instances where our running character ran off the side of the screen, much to our surprise!)

After our time was up, we were all asked to demonstrate and talk through our various projects.  I can remember a simple etch-a-sketch game, a demonstration of some bouncing balls (which bounced at different speeds), a space invader game (where the invader was a cat), a Tom and Jerry animation where Tom chased Jerry across a screen, and an animation that involved a balloon and a plane.   It was great to see very different projects since when we were coding our own, we can easily get into the mindset of just solving our own problem; seeing the work of others is something that is very refreshing.  It was inspiring to see what could be created after an hours of programming.

Reflections

The whole day reminded me of the time when I first tried to learn computer programming and I still remember that it was a pretty difficult challenge (in my day!)  I always wanted to rush ahead and solve the bigger more exciting problems but I was often tripped up because I needed to understand the operation of the fundamental instructions and operators (and the way a language worked).  In my own experience the only way to really understand how things work is to find the time to play, to explore the various operators and instructions, but finding both the time and the confidence to do this is perhaps a challenge itself.

All in all, the first Sense Workshop was a fun day.  I certainly got a lot out of it and I hope that everyone did too.  I certainly hope this is going to become a bi-annual event for all our TU100 students.  From my 'I've never really used Sense before to do anything other than to run a demo program' perspective, I certainly came out learning a lot more than I did when I started.  Large parts of Sense was demystified, and I certainly had a lot fun attending.

Additional resources

After sharing a link to this post my colleague Arosha (who also came along to the Sense workshop) has written a short blog post.  Arosha is loads more skilled when it comes to Sense programming and has re-created one of the projects that were demonstrated on the day.  Thanks Arosha!

I think I must have been about 10 years of age when I first heard about the magical device that was the Logo turtle (and the mysterious notion of turtle geometry).  Fast forward two decades and about ten years ago I managed to find a copy of Papert's book Mindstorms in a second hand bookshop in Brighton (a part of me things that it must have been owned by someone who studied cognitive science at the nearby University of Sussex).  I had these two thoughts in mind whilst I was travelling to the University of Derby on the 28 November to attend the HEA BotShop.

This is a quick summary of my own views of the day along with my own take on some of the different themes that emerged.  In fact, there was quite a bit of commonality between this event and the HEA Open University event that was held a week earlier, but more of that later.  In case you're interested, Derby produced a press release for this event which highlights some of the areas of interest, which include neural networks, embedded systems and artificial intelligence.  We were told that this was pounced upon by the local press, proof that mention of robots has a constant and wide appeal.

First Sessions

The day was introduced by Clive Rosen and Richard Hill, subject head for Computing and Mathematics at the University of Derby, jointly welcomed everyone to the workshop.  The first presentation of the day was by Scott Turner from the University of Northampton who gave a presentation entitled Neurones and Robots.  Scott uses the Lego Mindstorms hardware to introduce some of the fundamental concepts of neural networks, such as how learning takes place by the changing of some of the numerical values that are used within a network.  Some of the applications of these robots include following lines, getting robots to follow each other and getting robots to avoid obstacles; seemingly simple actions which enable underlying principles to be both studied and demonstrated.

One of the questions to Scott was, 'what does using a robot add?'  The answer was simple: it can add enjoyment and engagement.  Although similar principles could be studied through the application of other tools, such as Excel spreadsheets, simple robots add a degree of immediacy and physicality that other approaches cannot.  These discussions made me consider whether there is a pedagogic dimension (in terms of educational tools) that has emulation on one end and physical devices on the other, and the extent to which we may wish to consider a balance between the two.

Scott's presentation was followed by Martin Colley from the University of Essex whose presentation was entitled Embedded Systems Teaching.  Having been a postgraduate student at Essex I found Martin's presentation especially interesting.  Although I didn't have direct exposure to the robotics labs during my time at Essex I remember that some of my peers made good use of the research and teaching facilities that the University provided.

Martin gave a quick history of robotics and embedded systems at Essex where he talked about the design and evolution of different devices which culminated in the development of a kit.  The design of the kits had changed along with the development of processors.  Early kits (and robots) made use of the Motorola 68k processor (famed for its use in the original Apple Mac) whereas the current generation of kits made use or ARM processors which are, of course, commonplace with mobile phones and other embedded devices.

One aspect of Martin's kits that I really liked was the range of different input and output devices.  You could write code to drive a 160x128 colour display, you could hook up a board that had light and ultrasound sensors, or you could even connect a memory card reader and a digital to analogue converter to enable students to write their own MP3 player.  Martin also touched upon how the hardware might be used to explore some of the challenges of programming, which includes the use of C and C++, how to work with a real-time clock, the use of interrupts and direct memory access buffers.   Debugging was also touched upon, which, in my opinion is a really important topic when 'students get down to the muddy later between the hardware and software'.  Plus, all these interesting peripherals are so much fun than simply having an embedded system to turn an LED on or off.

All in all, a really interesting presentation which gave way to a discussion about the broader challenge of teaching programming.  One comment that it isn't programming per se that is the main problem.  Instead, it is development the skills of algorithmic thinking, or knowing how to solve problems that represents the biggest challenge.

Using bots to teach programming

The third presentation of the day was by Mark Anderson and Collette Gavan from Edge Hill University who described how the broad idea of robotics has been used to teach fundamentals of programming and how some students have learnt to build their own devices.  Mark and Collette had a surprise in store.  Rather than having to do most of the talking themselves they brought along a number of students who shared with us their own experiences.  This was a great approach; personal accounts of experience and challenges are always useful to hear.

Mark and Collette's slot covered a broad range of technology in what was a short period of time.  They began with describing how they made use of Lego Mindstorms kits (using the NXT brick) with Java, used in the first year of study.  During the second year students move onto Arduino kits, where student negotiate the terms of their own projects.  I seem to remember hearing that students are at liberty to create their own input controllers, which might be used in collaboration with an embedded arcade game, for instance.  There was reference to a device called the Gameduino which allows the Arduino controller to be connected up to a video display.  Not only can I see this as being fun, I can also see this as being pretty challenging too!

Towards the end of the session there was a question and answer and answer session where another introductory to programming tool called Alice was mentioned.  There were two overriding themes that came from this session.  The first was that learning to program (whether it is an embedded device or a computer) isn't easy.   The second is that it's possible to make that learning fun whilst developing essential non-technical skills such as team working.

Micromouse

One of the really interesting things about robotics is that a broad array of disciplines can come into play.  One of the most important of these is engineering, particularly electronic and mechanical engineering.  I guess there's a 'hard side' and a 'soft side' to robotics.  By 'hard side' I mean using the concept of robots to teach about the processes inherent in their design, construction and operation.  The 'soft side', on the other hand, is where robots can be used to teach problem solving skills and introduce the fundamentals of what is meant by programming.  Tony Wilcox from Birmingham City University, who is certainly on the 'hard side' of this continuum, gave a fabulous presentation which certainly gave us software engineers (and I'm talking about myself here!) a lot to think about.

A micromouse is a small buggy (or autonomous robot) that can explore a controlled maze (in terms of its dimensions) and figure out how to get to its centre.  It was interesting to hear that there is such a thing as a micromouse competition (I had heard of robot football, but not mice competitions before!)  Different teams produce different mice, which then compete in a maze finding challenge.  Tony uses his 'mice' to expose a number of different subjects to students.

Thinking about the problem for a moment we begin to see a number of different problems that we need to address, such as, how do we control the wheels and detect how far the mouse has travelled?  What sensors might be used to allow the mouse to discover the junctions in a maze?  What approaches might we used to physically design elements of the mouse?  How might we devise a maze solving algorithm?  Tony mentioned a number of subject areas that can help to solve these problems: closed loop process control (for the control of the wheels) and mechanical engineering, 3D computer aided design, power electronics, and PIC programming (which is done using C).  I'm sure there are others!

It was interesting to hear Tony say something about programming libraries.  Students are introduced to libraries in the in the second year of his teaching.  Whilst libraries can help you to do cool stuff, you need to properly understand the fundamentals (such as bit shuffling and manipulation) to use them properly.  To best teach the fundamentals, you ideally need to do cool stuff!

One thing that I took away with me was that robot control and maze solving software can exist within 32K.  I was reminded that even though there is a lot of commonality between programming on embedded devices and programming applications for a PC they can be almost different disciplines.

Critters

The micromouse robots operate within a controlled physical environment.  Another way to make a controlled environment is to make one using software.  The advantages of using software is that you can control everything.  You can, of course, define your own laws of physics and control time in any ways that you want.  In a way, this makes things both easier and difficult for us software engineers: we've got the flexibility, but we've got to figure out the boundaries of the environment in which we work all the time.

Dave Voorhis from the University of Derby talked about his work on 'emergent critters'.  By critters, Dave means simple 'virtual animals' which hunt around in an environment for food, bumping into others, whilst trying to get to an exit.  There are some parallels with the earlier talks on robotics, since each critter has its own set of inputs and outputs.  Students can write their own critters which can interact with others.  There is parallel to core wars, a historic idea where programmers write programs which fight against each other.

Dave said that some students have written critters which 'hack' the environment, causing the critter world to exhibit unusual behaviour.  Just as with the real world, working against some of the existing laws (and I'm talking those that are socially constructed rather than the other immutable variety) runs the risk of causing unintended consequences!

Final presentations

There were two presentations in the final session of the day.  The first was by Steve Joiner from Coventry University about how robotics can be used to help teach mathematics to key stage 3 and 4.   Steve is a maths graduate and is a part of the Centre of Excellence in Mathematics and Statistics Support (SIGMA), in collaboration with Loughborough University.  Steve showed us a number of videos where students had built robots out of the Lego Mindstorms NXT kit.  Projects included navigation through sensors, launching projectiles (albeit small ones!) and predicting their behaviour, and applications of graph theory.  Steve also demonstrated a self-balancing Lego robot (basically, a bit like a mini-segway) that made use of ultrasonic sensors.  Steve made the good point that through the use and application of kits and projects, students can begin to see the reason behind why particular subjects within mathematics are useful.

The final presentation was an impromptu one by Jon Rosewell, from the C&S department at the Open University.  Jon has been heavily involved with a short module called T184 Robotics and the meaning of life which has just come to the end of its life.  Like so many of the earlier presentations, this module makes use of Lego Mindstorms to introduce the concept of programming to students.  Instead of using the native Lego software, the Open University developed its own programming environment (for the earlier Lego Mindstorms blocks) which is arguably easier to work with.  Students are not given their own robotics kit, but may use their own if they have one available.  If they don't have access to a kit, students can make use of a robotics simulator, which is a part of the same software package.

Towards the end of the day there was some talk about a new Open University undergraduate module called TU100 My Digital Life.  This module makes use of a 'home experiment kit' which contains an Arduino processor, which was mentioned by Mark Anderson earlier in the day.  Whilst the TU100 senseboard, as it is called, cannot directly become a robot, it does contains some of the necessary features that enable students to understand some of the important ideas underpinning robotics, such as different types of input sensors, and output peripherals such as motors.

Plenary

At the end of the day there was sufficient time to have an open discussion about some of the themes that had emerged.  Clive Rosen kicked off the discussions by saying that robots can help teaching become engaging.  I completely agree!  One of the difficulties of teaching subjects such as mathematics and computing is that it can often take a lot of work to get satisfying and tangible results.  Using robots, in their various forms, allow learners to more readily become engaged with the subject that they are exploring.  In my own eyes there are two key things that need to be addressed in parallel: what subjects the application of robots can help to explore, and secondly, how to best make use of them to deliver the most effective pedagogic experience.

These ruminations connect to a plenary discussion which related to the teaching of computing and ICT at school.  There was a consensus that computing and ICT education needs to go so much further than simply teaching how students to make use of Microsoft Office, for instance.   We were all directed to a project called Computing at School and a relatively new education (and hardware) project called RaspberryPi was mentioned.  I'm personally looking forwards to how this project develops (and hopefully being able to mess around with one of these devices!)

There was some debate about individual institutions 'doing their own thing', in terms of building their own teaching hardware, raising the question of whether it might be possible to collaborate further (and the extent to which the higher education hardware might potentially be useful in the school environment).  It was concluded that it isn't just a matter of technology it may be more of a matter of education policy.

In the same vein, it was hypothesised that perhaps the embedded processors within students' mobile telephones might (potentially) be used to explore robotics, perhaps by plugging in a phone to 'extension kit'.  Another point was that little was discussed about fixed or industrial robots, which is almost a discipline in its own right, having its own tools, languages and technologies.  This is a further example of how robotics can connect to other subjects such as manufacturing.

Thinking back to the event, there are a number of other themes that come to mind.  Some of these include the role of simulation (and how this relates to physical hardware), the extent to which we either buy or build our hardware (which might depend on our pedagogic objectives), and the types of projects that we choose.

Through the use of robots students may more directly appreciate how software can change the world.  Robotics is a subject that is thoroughly interdisciplinary.  I've heard artificial intelligence (AI) described as applied philosophy.  Not only can robotics be used to help to study AI, it also has the potential to expose learners to a range of different disciplines, such as mathematics, electronics, physics, engineering and the fundamentals of computing.

Learning how to program a robot is not just about programming.  Instead, it is more about developing general problem solving skills, developing creativity and becoming more aware at how to conduct effective research.