Let's Make Robots!

A teaching experiment

Today in the robotics class I wanted to try an experiment. We have covered lots of stuff over the past few months, but not so much programming. In these next few weeks we will be concentrating on programming until we get some sweet kits, more news on that later. 

I have been trying to think up cool and interesting ways that the kids can learn programming whilst getting their hands dirty. It's hard to install software on the school computers so we don't have the IDE up and running yet, but I'm working with the IT admin on that. 

Some of these ways has been whiteboard representations of a robot and the kids have to use combinations of move commands to get the robot to the destination.

But today I wanted to try something. I had an idea a while ago to cut up a code so that the kids could re-arrange it to make a working code. I saw some problems with this method, not everyone programs the same way for starters and it could be hard for them to understand how I went about the task.

Never the less I went ahead I broke one of my simplest obstacle avoidance codes into snippets.

Each student was given the cut up code. I explained some of the more complicated parts of the code and what the goal of the code was, then they set off putting it back together. 

At the start of the lesson most of them had no idea what was going on and just blankly looked at their pile of paper. After some more explanation to the individuals they started to pick up pace. 

About half way through the lesson all the students knew what they were doing and were making some real headway.

At the end of the lesson all the students had put the code back together, some doing it in a slightly different order, but they would've worked. 

It was a really interesting experiment. It seemed that chucking them in the deep end payed off, they understood a majority of it already, but it really cemented the idea of structure and the logic behind obstacle avoidance.

Next lesson I will hopefully have the Arduino IDE up and running on their computers, they are definitely ready.

 

Just thought you might like to hear about what I have been doing as I haven't been able to record these lessons.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
MetalmonkeeLad's picture
Have you tried doing the flowcharting first? In our programming class, we use flowcharting and ipo chart and then the programming, it makes everything much understandable.
chickenparmi's picture

Yer we did flowcharting right at the start of the year. This was a test to see how much they remembered from the start of the year and combine that with the movement functions we were using the week before to control robots. They now are able to program obstacle avoidance capabilities quite well.

MetalmonkeeLad's picture
That's cool, cheers
bdk6's picture

That is an interesting experiment.  I think I would ask the students for feedback to see how much THEY think it helped them.  The C family of languages might not be the best choice for trying it in a general sense, but obviously it worked out.  C and friends can be rather cryptic, especially out of context.  Other languages that use more words (BEGIN, END etc, like Pascal, or ADA, or others) might be easier to do.  In any event, I am very interested in hearing any results / conclusions you get from it.

Another experiment I have heard of that you may be interested in.  This one is mostly geared toward younger kids, but I think may be worthwhile.  Have one student "be" the robot, following the commands given by another student.  Working in pairs, they take turn creating a "program" to get the other student to reach some goal.  

You are doing great work, cp.  Keep it up.

 

chickenparmi's picture

Well I always have a 3 minute talk with them at the end of the lesson and get them to tell me how they thought the lesson was. Turns out they actually learnt quite a lot. One of the things they were having trouble understanding during the course of putting it together was the delays and the blocks. I can understand why they were having difficulty understanding delays because it is quite an arbitary thing, but through the lesson I sort of drilled it into them :) The blocks (round brackets) I think were difficult for them to understand because it was on paper. I took the concept onto the board and explained how they are effectively boxes and everything inside this box refers to the statement at the start. Difficult to explain in words, might draw a picture.

By the end of the lesson they could all tell me what both delays and the curly brackets did, so I was pretty impressed.

I am choosing to teach them with a C langauage because as soon as we get some kits, I want them to be able to program them, no having to learn another language. We had already covered programming in gamemaker with is effectively a drag and drop programming UI, some kids even made pacman clones!

 

Funny you mention that! We have done that already, except I was the robot. Ofcourse me being the robot meant that I was most of the time programmed to walk into a wall, but it was fun all the same. We first covered sending movement commands to me, just to make me move around. After they could get me to move around we started adding AI capabilities, it wasn't in any formal language, just one I made up, but it was really fun all the same!

Thanks bdk! :)

bdk6's picture

I think you have this teaching gig down pretty well.  I am constantly impressed.  From my experiences teaching I think feedback on several levels is one of the best things you can do.

I wasn't suggesting you use another language, merely saying it might work better with others.  I feel strongly that C and family are NOT the right languages for beginners.  I am even starting to move to the camp that they aren't appropriate for pros, either.  (ADA is my current favorite candidate as a replacement.) But, they are the closest thing we have to a common standard, so it makes sense to teach it.  Arduino, the king of newbie embedded programming, is C based.  No sense starting with something else then switching midstream.  I won't go into all the reasons I feel that, way.  Don't get me wrong, I like C and C++, but I also like guns, saws, motorcycles, and lots of other things you can hurt yourself with if you don't handle them properly.

I find it interesting you used a flowchart for your example.  Flowcharts have fallen out of favor in computer science in recent years, but I think they are valuable for teaching programming basics.  I 'm a firm believer that anyone who can read can learn to program if taught properly.  That may not always be easy to do, but it really sounds like you are doing a great job.  I have a strong interest in programs teaching people to program.  I think it offers many, many benefits even for people who never do it again.  I really believe you are doing a great service, and doing it quite well.  I offer my thanks and congratulations.  If you do decide to be a teacher, I am sure you will be a great one.

birdmun's picture
We did that in programming class way back in high school. The teacher was the robot and we had to tell him/it how to make a peanut butter and jelly sandwich. I believe we failed. :P
6677's picture

we had to make a ham sandwich. We also failed, turned out he wanted us to specify where things were.

bdk6's picture

I do hope your PB&J skills have improved since then! :-)

 

birdmun's picture

Thanks for sharing.

I still think it is too bad you can't get a linux distro up and running from flash drives.