This is a bit of a long spiel, of a topic that I've been mulling over for the last few years.

I’ve been teaching with robots for over 15 years now and one of the most common question I get from Teachers is “Which robot platform should I get for my school?” I’ve used over a dozen different platforms quite extensively and at the end of the day, I truly believe that it doesn’t really matter :)

In the education realm, we should never be solely focusing on ‘Teaching Robotics’; instead we should be using ‘Robots to Teach’. Just like any other educational tool, Robotics platforms are just a means to teach different concepts. Technology comes and goes, and in this day and age is seems to be coming and going faster every day. Teaching students a very specific tool (such as just a single specific robot platform) is fine for the moment, but unless the students understand the broader concepts behind the technology, once something newer and shinier comes along, they will be right back at the beginning, learning a new technology.

By using the platform to teach (rather than teaching the platform), we instil in our kids the ability to solve higher order problems, think more broadly and be more adaptable with the tools they have on hand. When a new technology comes along, they are more likely to understand the tool more rapidly and begin using the tool to help solve their challenges.

We use these platforms to teach programming, computational thinking, problem decomposition, mechanical engineering, branching statements, directional terminology and so on, and so on. The robot itself is just a platform that is used to teach these concepts so it doesn’t really matter which one you choose. There will be a variety of factors that will guide teachers in to choosing a platform that suits their school best and they should include;

Price. If there is a robot platform that is amazing, but it costs $5000 / robot, is that a better investment than an adequate platform that is $200 / robot? For the same amount of money, a cheaper robot can engage more students.

Availability: Can you easily get them in / into Australia (or whichever country you are in)? Are spare parts or add-ons easy to source?

Age appropriate Programming Language: Graphical or Text based? Do you need a platform that can span across both to appeal to a wide range of ages?

Curriculum Resources: Are educational based activities easy to come by? While it would be awesome to have the time to use robots in class because they are fun, in reality everything we do needs to be meeting some parts of our Curriculum. Are those activities affordable/ adaptable / assessable?

Teacher support: Often the ‘robotics’ teacher/s at a school might be only one or two teachers, which makes it a little more difficult to bounce ideas around. Many robotics platforms have good extended Educator communities in the form of mailing lists, forums etc.

Professional Development opportunities: Are your staff comfortable in using the equipment in class. Too often I’ve seen cupboards of equipment sitting idle in a classroom because the teacher who originally used it has now moved on and no-one else at school knows how to use the gear. Is the equipment easy to use and it is just missing a teacher willing to take it on?

Reliability: If you are spending too much time just getting the platform up and running, then that is time that could have been time spent solving challenges.

At the end of the day, I think the best robotics platform is the one that teacher feels most comfortable using. If they are comfortable with it, then they will teach with it, just like any other tool at their disposal.

I'd really appreciate any thoughts / comments / rebuttals you may have in relation to this. I'd prefer to keep all the conversation centrally located on my facebook page (www.facebook.com/domabotics) but feel free to reply on whatever platform you have read this on.

I was recently interviewed on our local radio station as part of their Education2.1 segment.

It's 10 minutes long and Wayne Chalmers and I chat about robots in the classroom, how I got into the field and some suggestions for teachers that may be looking to incorporate robotics in their classroom.

I had an email from a teacher recently asking for some advice on how to put together a voting machine using the LEGO MINDSTORMS EV3. I quickly put together this example as a starting point.

The build is ridiculously easy - The EV3 and 2 Touch Sensors.

The program however is a little more complex. It would be a great way to teach a variety of more complex concepts like variables, parallel processing and looping.

(click for larger version)

There are three parallel tasks; Task 1 sets up a variable (Bob) and makes sure it is zero when the program starts. It then runs an unlimited loop in which it waits for a touch sensor to be 'bumped' (pressed and released). It then takes that variable and adds one to it and stores the number back into the variable. Task 2 does exactly the same thing for a different variable (Sue). Task 3 takes the Bob variable and combines it with some text so that the display says 'Bob: 7" as opposed to just the number by itself. It then displays that Text on the screen at position 0,0 (Top left). It then does the same thing with the Sue variable and puts it at position 0,3 (Middle left roughly). The important thing to note is that this second display block has the 'Clear Screen' input parameter set to FALSE to make sure that we don't clear out our Bob Text.

If you wanted to extend it further, you could set the loops to run for only a few minutes, and then you a Compare Block and Switch Statement to declare a winner (or a draw!)

I'm often asked to give quick demos of my robots to show off what they would be capable of in a classroom setting. I have three different models that I regularly fall back to to show off basic movement, the Ultrasonic Sensor, the Colour Sensor and the EV3's ability to play music. Description and Project file under the video.

1. Line follower. A simple line following robot using a single Colour Sensor in 'reflected light' mode. The program is a basic edge follower using a Switch statement inside a Loop

2. Obstacle Avoider. Using the Ultrasonic Sensor, this robot backs up when it gets close to an object. I put in an extra little 'back up and shake' routine as well as a sound effect to give it a little more personality.

3. Music Maker. This design only needs a Colour Sensor being used in 'Colour' mode. An extended Switch statement identifies which colour is under the sensor and then plays the appropriate note.

I've included the .ev3 file below if you want to use them for your self.

So the last few weeks / months have been pretty crazy/busy so over this last week I've done something that I haven't done in quite a while - build something cool just because I want to. I don't normally do remote control robots (preferring to focus on programming) but for this one I made an exception. VEX2-D2!

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.

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.

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!

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.