Damien works with students and teacher from around the world, bringing the effective use of technology to the classroom.  

Damien is a member of the MCP (Mindstorms Community Program), a small group of experts who collaborate with LEGO to make the MINDSTORM product better.

VEX IQ Robotics
Damien is a member of the VEX IQ Super User group, a small group of experts who collaborate with VEX to make the VEX IQ platform a better product 



Teacher Resource Books

Global Map

See where the DomaBot and RileyRover is being used around the world


New Book! VEX IQ with RobotC Graphical

It's been a while, but the next book is now ready.  If you've been using the VEX IQ robot platform, but prefer the RobotC programming language over Modkit, then here is the book for you!  Click on the pic below to go to the info page with Sample pages and student worksheets.


Testing the Tumblebug (EV3 and VEX IQ)

So the title sounds awfully dry, but this is a project I've been meaning to do for a very long time.  A few years back one of my boys received a 'Tumble Bug' toy for Christmas.  It's a pretty simple thing, you put the balls into the mouth and they tumble down and come out either the left foot or the right foot.  

Being an engineer the second thing I thought of (right after "how do I turn that annoying sound off!?") was "I wonder how statistically fair it is?"  ie.  Does the ball come out the left foot / right foot with a 50% probability?

This would make a great experiment to run in class, not just with the Tumble Bug but all different types of kids toys.  Skip forward a few years of me telling my wife not to throw it out even though our boys have out grown it, and having a little spare time this week now that school has finished.

I've used both the LEGO EV3 and VEX IQ systems to demonstrate the approach I used.  

For the EV3, I put together a program in both EV3-G and RobotC that uses two Ultrasonic Sensors placed either side of the Tumble Bugs feet.  As a ball rolls past, the EV3 recognises a ball has rolled past and increments a variable.  

For the VEX IQ, I had trouble getting the Ultrasonic sensor to detect the balls as they rolled past.  A combination of the curved surface and fast rolling ball was too much for it to recognise.  Instead I used the Colour Sensor in Proximity Mode which worked perfectly.

A little bit of maths figures out the percentages and then displays them on screen.  Full breakdown of how it is done as well as code download is after the video.

Hardware Setup

Not much to this one, just the EV3 Brain with 2 Ultrasonic Sensors and the VEX IQ Brain with 2 Colour Sensors.


EV3-G Code

Each foot waits until the ball rolls past (reading less than 10 cm) and then increments the variable associated with that foot as well as the total count.  It then updates the screen (setup as a My Block in this example) and waits for the ball to roll away.  Repeat as much as you want.

click for larger version

Update-display My Block 

click for larger version


RobotC Code  (EV3)

This is essentially the same as the EV3-G version but with one small difference.  I used sequential IF statements in RobotC and Task Splits in EV3-G.  No idea why, both approaches would work for both software environments.



RobotC Code (VEX IQ)

Do it yourself

Here are the files I used

EV3-G - Tumblrbug.ev3
EV3 RobotC -  EV3_tumblrbug.c
VEX IQ RobotC -  tumblrbug_VEX.c


So I ran the test over 50 cycles with each setup to see what I got.  

VEX IQ - Left 26%, Right 74%
LEGO EV3 - Left  33.3%, Right 66.6%

So there was a definite bias towards the right side of the toy.

What I love about doing these sort of extended investigations in class, is that rather than being a final conclusion, this now opens up a huge range of other questions and scenarios that you can test.

  • Why was there a difference?
  • Was the table level?
  • Do the different balls have an impact?
  • Does the placement speed in the mouth affect the results?

Please have a go your self and see what results you can come up with.


EV3 Linefollowing robot via Bluetooth

A recent discussion on the LEGO Community forum about the WeDo kit led to an interesting question.  'Could you run a simple robot, with off board (on tablet or PC) processing?  ie.  Could you let the computer to the all the tricky computation and just have the robot send sensor values and receive motor commands?'

It isn't yet possible to even try with the WeDo set but I thought I'd give it a go with the EV3.  Don't get me wrong, this is not particularly useful, but I wanted to see if it possible given the probable lag time of the Bluetooth data transfer.

Short answer - Yes it's possible, but you can't go too fast otherwise the robot shoots over the top of the line before a bluetooth command has a chance to be received by the master, processed and sent back to the slave.

Video below of it in action.  Screenshots of the program under that and full .ev3 file to download at the bottom if you want to give it a go yourself.

Could it be done better / more reliable?  Undoubtedly! If you come up with a better way, test it out and let me know how you go!






Full .ev3 file download


Fix a broken EV3 button

I had a student press the cancel button a little too hard today and it got stuck in a 'down' position and wouldn't work any more. You could still run programs as per normal, but you couldn't exit any menus or do a software shutdown of the EV3. It turns out there is a little piece of curved metal under each button which gives it the 'springiness' to pop back up, and this particular bit of metal had shifted under the plastic cover. Taking the cover off is as simple as undoing 4 screws in the battery compartment and then a gentle prod gets the metal spring back in position. Not sure how long it'll last, but it was an easy fix.



Simon Game - VEX-IQ version


The game of Simon is a lot of fun for kids and adults alike.  The basic premise is this:

Device does an action (display a light, plays a sound etc.)  Player has to repeat the action (press a button corresponding to the light/sound etc).  The device then does the original action plus a new action.  Player has to repeat the sequence.  Each time the player gets the sequence right, the device adds another action onto the sequence making it harder and harder to remember.

This is my VEX-IQ version of the Simon Game.


This project uses a VEX-IQ Smart Brain and 3 Touch LED's. Given the VEX-IQ can take up to 12 input/outputs, I could theoretically do one that had 12 TouchLED's (but I think that would prove just a little too difficult).  No other hardware other than some plates and pins to prop it up.


The software is all programmed in RobotC and you can download my software here - simon.c (if you use it, please acknolowgement where appropriate and forgive any glaring errors!)

These are some of the important parts of the code


Fill the sequence array with random numbers between 0-2 to represent which TouchLED's are going to light up.


Flash the right sequence level


Check to see which TouchLED's were pressed

Check to see if the TouchLED that was pressed is the right one, if it is, then allow it to check another.

This is a nice little project for teaching arrays in the classroom.  Let me know if you use it and how you would improve on it!


Simon Game - LEGO EV3 version


The game of Simon has been popular for many years.  The basic premise is this:
Device does an action (display a light, plays a sound etc.)  Player has to repeat the action (press a button corresponding to the light/sound etc).  The device then does the original action plus a new action.  Player has to repeat the sequence.  Each time the player gets the sequence right, the device adds another action onto the sequence making it harder and harder to remember.

This is my EV3 version of the Simon Game.


I'm using 3 colour sensors to represent the actions that the device can show.  If you set the Colour sensor to measure ambient intensity, the LED inside glows blue.  If you set it to measure reflected intensity, then it glows red.  I'll be using these as flashing lights only, and am not interested in the actual sensor readings that they generate.

I'm using the Brick buttons (left, centre, right) as the player inputs.  If the left Colour Sensor goes red, that means the Player has to press the left Brick Button to match the sequence.  



Create a Numeric Variable Array and set it to 0

Set each Colour Sensor to be in Ambient mode (showing a blue light)

Generate sequence
Create a Random number, between 1 and 3, and append it to array (append is a fancy way of saying tack on a new number to the end of the array).  

I then show on the EV3 screen the length of the array to let the Player know what level they're up to.  If the array/sequence is 5 actions long, then they are on Level 5.
Take the random number, if it is 1, play a low note and briefly change Colour Sensor 1 to red and then back to blue.  If the random number is 2 or 3, play a medium / high note and flash the appropriate Colour Sensor.
Repeat this process as many times as there are numbers in the array.  ie. If the array/sequence is 6 numbers long, then repeat this 6 times.


Check the sequence
Wait for either the Left, Centre or Right Brick button to be pressed.  Each button represents a number, and this number is checked with the equivalent position in the array.  If the numbers are equal, it means the Player pressed the right button for that part of the sequence.  A brief high pitched note is played to indicate success and the next number in the sequence is checked.  If the numbers don't matched, then it means they got it out of sequence.  A suitable sound is played and the main loop is interrupted (exited).  The score stays on screen for 5 seconds so you can see what level you got to.



Workshop EV3 Quick Build

My RileyRover is my favourite build when I'm working with groups over more than just a session or two as it relatively sturdy and has a lot of great places to add attachments and modifications.  However, in my shorter workshops (around 2hrs) I was looking for something just a little bit quicker to build and this is what I came up with.  

It's ugly and a little bit flimsy, but if you have all the parts already separated from the rest, a novice builder can put it together in around 5-10 minutes.  This means students have a chance for some valuable building time without sacrificing too much programming time.  There is a super simple Light Sensor attachment (the same design as the RileyRover) and UltraSonic Sensor arm as well.

The gripper is the simplest that I could pare it down to.  It's ugly, it sags and is prone to falling apart, but it is quick and can grab paper cups and softdrink cans quite nicely :)

Feel free to use in your class and if you find it useful, please let me know about it.

>> Download the full Colour Pdf <<


Contracting out robot design for competitions?

So I recently had this email land in my mailbox and was quite disturbed.  Identifying details removed.

"I am a teacher of IT and preparing elementary students for participating in a national XXXXXX robotics competition. The truth is that I don't have so much time. I want to give to my students the happiness to make the Robot there and pass to the final of the competition.

I want to ask you if you can help me to build and program the Robot that can give the solution to the XXXXXX challenge. I can pay you of course for your work if you can help me."

I've heard rumours before of this happening and frankly I think it is just about impossible to stop a determined Teacher / Team mentor. 

This was my reply - 


I was disappointed to receive you email.  As you are no doubt aware, these kinds of competitions exist to promote Science, Technology, Engineering and Math skills amongst our students.  By providing them with a ready built solution deprives them of the opportunity to learn themselves through the valuable trail and error process.  Design skills, creative thinking and problem solving techniques are never learnt when someone else does all the work for you.
In addition, these competitions require that the students do the majority of the work, and so to have someone else design and build would go against the ethos of the competition as well as be blatant misrepresentation of the work that they have done.  
I deeply implore you not to go down this route and instead encourage the students to come up with and test their own solutions.  The ultimate aim of these such competitions and initiatives is not to win, and your students would achieve and learn considerably more with a robot that doe not make the finals (that they have built themselves) then they would from a robot that did make the finals (that they had nothing to do with).

Damien Kee


Given how highly regarded all these types of competitions are becoming.  Winning them does bring with it a lot of fantastic publicity as well as financial incentives.  I understand that having the competitive part of a challenge can be a very big drawcard and can often be a big factor in the success of such a program, but how do we combat the 'win at all costs' mentality? 

In RoboCupJunior Australia we are making a concerted effort to not only personally interview every team that comes in, and by initiatives such as rewarding teams that document and share their solutions regardless of how they perform on the day.

I'd love to hear your thoughts. 




Using the LEGO WeDo kits with scratch

I recently ran some workshops for Grade 3 students with the LEGO WeDo kits.  150 students over 3 days, in 2.5hr sessions at a time.  This particular school had a very extensive XO laptop program so they were keen to utlise them as much as possible.  The standard programming language that comes with the WeDo kits however is not supported on the XO laptops, so we used Scratch instead.  While the programming complexity of Scratch is a little higher than the LEGO software, it is still easy enough to use and the grade 3's were up and running within minutes.

I started out just showing them how to enable the WeDo blocks within Scratch and then a quick exploration about motors going 'this way' as opposed to 'that way'.  As usual I played dumb and let the kids discover and teach me which way was clockwise and which way was anti-clockwise (for the record, 'this way' is clockwise when looking at the motor from the front.)



We built a simple gate and had a play around with the duration and power levels to see if we could get fine control of the motor and get it to stop in set positions.  ie.  Gate open / Gate closed.


Once that was under control, students set about building their enclosures.  The only restrictions I gave them was "it has to hold an animal" and "I don't have any animals, so you have to build your own!".  That permission to be creative resulted in some extremely engaged students and a menagerie of animals.  We ended up with ducks, birds, dogs, hippos, snakes, snails, crabs, chickens and so on....  even a 3 eyed monster.  I just wished I had taken more photos!



We did simple programs to open and close the gate based on a keyboard press and then introduced the distance sensor.  This was the framework of the final program that the students did, although most decided to customise with extra sounds and speech bubbles!

A quick video of some of the final creations.




VEX IQ with "Modkit for VEX" Teacher Resource

It's been a long time in the making but I'm finally proud to announce that my next book in the 'Classroom Activities' series is now available!.  This book utilises the new VEX IQ robot kit from VEX along with the freely available Modkit for VEX programming language.  The book is available as either a hard copy or eBook download.

Any questions, don't hesitate to contact me!

More info about the book can be found here - Classroom Activities for the Busy Teacher: VEX IQ with Modkit for VEX