Let's Make Robots!

Don't program your robot.. Teach it!

(Update: Some time after writing the below, I made this, that may interest people doing navigation with Picaxe)


How to make a robot do complicated tasks & "act alive".. With ease..

Here is one guys humble input - I am sure you all have your own ways of programming. Just take it for what it is; My personal thoughts, use what you can :)


Recently, since my "15 minutes of fame" with The drumming robot, I have been asked A LOT about code, how stuff was coded etc.

A nice guy like Fredrik Andersson is one of many who ask about "How to make that navigation of YDM (Yelow Drum Machine)" - A cool dude like Chris the Carpenter asks in general about obsticle avoidance and these things, and I get "wow" from others because I make "such complicated code"

"My secret" - to try to put it in a popular way - is that I do not "program the robot", "I teach the robot".

YDM has only the ability to look forward, and angled to left and right. And from these 3 angles I get distance.

How on earth would I program a robot with only this limited information to find objects worth playing drums on? How would I program it so that it looks "human" and is tracking down flat wide surfaces or stand-alone objects?

Truth is; I would not know how. The math in it would scare me, I would not have a clue.

And as many builders out there, I would start thinking about complicated sollutions to this complicated problem; I would build up neural networks, I would send data to a laptop, and have it calculate some heavy s**t in Java-simulators etc!

I would never get anything done if I where to program something like that!

So I teach the robot what to do instead.

What is the difference?

Well - if you are a good teacher, such as a parent to a child - you are able to, you naturally set yourself in the child´s position and limited understanding of the world.

So I put myself in the robot´s place, and this is what I have got:

3 bars.

Let us say that they look like this:

| |
| | |

Now what would that tell us - "us" being the robot? (Long lines means long distance.)

Well - this graphis shows it quite clearly I hope;


- There is something in front of us (middle one), but we are in an awkward angle to it (Left is much longer than right)

And here comes the teaching:

Look, dear robot, this is easy; For now, don't mind the middle one, try to focus on this: If one of the L/R are longer than the other, then snake with your belt-tracks a little to the side, and then measure again. And of course, dear robot; If there is MUCH difference between, then take a loong snake-step, and tiny if only a small difference.

.. That is what I would do with the information, and so I teach the robot that.

Ok, test see what it does.

Fine!! Of course it will now either face a wall flat, or get close to an object, or face a corner. This is the only 3 situations where L & R are the same length.

So.. when in the "face the object the right-way"- mode, just snake this way, slowly towards the object.

But.. So much snaking!!

If the angle was all right from the start, this snaking, looking, snaking .. is a very slow way to approach an object. And also if the angle was bad at the start, but is fine now, there is no reason to keep snaking.

So again.. Teach the robot;

Dear robot; If you have just snaked L/R/L/R or R/L/R/L .. well should we not think that perhaps half a "snake" to L or R would set it all in place, and you could just drive forward?

So, I enter a check in the code above, are we making L/R/L/R or R/L/R/L? If so go to this routine: Drive ahead, now only looking (and measuring) right ahead.


NEXT, the approach.. This is like kids, teaching one thing at a time..

Because then the robot has to know how close it should get.

I let it drive so close that the sensors still works, and then hard code that it should drive a little longer.

Hey - perhaps we where thrown into this situation, we did not snake into position, we got here somehow else - so let us just make an extra check if L&R are the same distance.


Step by step by step. Teaching it every one.

That way, I make a routine to find an object to play on, in a very short time, and everything works and is realistic all the time. I can tell how far I got; to the point where something is not working.. Teach!


And funny things then happens when it is uoyt in the real world- and you find that it will change from one thing it has learnt to another, acting to the soroundings, acting just as smart, funny and clever as youhave tought it.

But never as you planned - the robot is now on it´s own, with all your good teaching in it's suitcase.


I have only touched a very, very small area of the code in YDM here.

What is the bars looks like this:


- This is bad, we are facing a gap or a corner, etc. Each little situation; Teach the robot.

It is VERY important that each step you teach works.

Ver, as you will rely on it when you go to the next step. "I know that.. because the other routine does wor, so..". It is a good feeling leaving one routine after the other that just works, but it is of paramount importance also; You will get lost if not.


Do not try to make a fantastic robot that can do all sorts of complicated things. You will never get there!

Make sure that you teach your robot every little thing, step by step.

Often hooking up a speaker to a robot is a very good idea.

You can get a lot of feedback fast; High note-beep = this, and 3 low beeps = that etc..


You will be doing your robots over and over if you try to "think it all through". Don't.

Just be friendly and patient, and teach the little fellow one simple task at a time, and be sure he gets it before moving on to the next :)


There is not a way to program a robot to find objects to play drums on, and look human and intelligent while doing it - that is allmost impossible with only one sensor, and the limited CPU-ressources etc.

There are only steps that you can teach your robot, and each step is easy. Afterwards people will look at your child..erh robot, and wonder how you made it do such complicated things, and they will fail when trying to make something just as complicated :)


.. OH yes!! Look; Programming this way still may mean that you will redo code. Like if you climb a tree, even though you got to the top, or close, you may think that it was a stupid route you just took.

Smart thing is, you have done everything step-by step - (not a large fantastic formula) so you can just erase or alter a step or two, and get to the top in a smarter or better way..

But.. - the best thing about this way of coding (lot´s of little routines, one for each situation) is that the robot get's that "I am alive, and have personality - expression".

"Look - the robot saw that it was in a right angle already from a distance, and so it just drove up to the bottle and started playing on it.." "Look, it didn't want to play there, but hey, that is clever, because there is a gap there, and some mess over in the corner" - People may say about YDM.

Well - if you have read and understood the above, you know that the programmer was not really that clever, nor is the robot; It is just tought how to act smart in the situations. Not programmed to be smart and neural and intelligent and high end math and all the things they talk about :)

Have fun, teach and whatch and teach and whatch, don't try to program and get frustrated:)



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
I have read this article, and found your conversations intriguing. You both have very valid points. I did not understand Fritsl initial description of teaching. As the conversation progressed it became more clear. This is how it relates to my interests. I have always been interested in the idea of very simple modular parts working togther in some way to construct an unexpected and incredibly complex whole. Fritsl, describes how he did this. First the Master Program was trying to do too much. Then he deconstructed it, into a few simple algorithms. The simple rules are added incrementally (e.g. if you have just snaked -> drive ahead only looking and measuring.)

In AI trying to match all environment cases with "what to do" is called Frame logic, this can be useful when your environment is extremely controlled. But, this form of processing can get overwhelming quickly if your environmet is rich and full of unexpected variable like steps, cliffs, cars, etc.

Subsumption Architecture is a bit like the inverse of Frame logic. It was championed by Rodney Brooks (robot god). His premise was, You should make small modular rules (just like Fritsl) and let the robot work it out. Again he experienced strange or unexpected behavior with his robots using this method.

Another example of this paradigm would be John Conway's Game of Life programs. Where a very simple set of rules are used to generate extremely complex entities.
There are a bunch versions you can play online e.g. check it out @http://en.wikipedia.org/wiki/Conway's_Game_of_Life

So, what if our programs worked like the "Game of Life" where they are all heaped together and influenced by sensors in the environment. In some aspects this models our own behavior. "I'm hungry->go eat" + "I'm sleepy->go sleep" + "I got to go to the bathroom->go pee" + "I want to explore->go somewhere" <- which one will we do? It depends on how the rules interact with themselves and the environment, "bladder_sensor=.5, hunger_sensor=.6, power_sensor=.2"

This way it might suprise you, rather than frustrate you.

So, what can I say, I like playing with blocks :) and being suprised!


Kizz and hugz from me, boy :D

/ Frits

LOL, you evil critter :-)

Anyway... I'm building on my robot... right now... isn't that amazing?! :-D

- Jimmy

About a year ago I was building my first real robot, after having played around with picaxe a motor, a sensor, an LED etc.

This was what I build

Try to whatch the video, and see what a cool routine there is for navigating!

This was what I wanted to build, but I could not.

I tried and tried, and made all sorts of complicated bases for my grant code that I tried to make. This should be an autonomous robot, one that thought it´s way.

But the thing never worked 100%

In the end I got mad, and just started cheating:

Instead of thinking "I am the robot, I make all decissions in my One Fantastic Master Program", I swallowed my pride, and just took it one step at a time.

What I got out of it was.. One Fantastic Master Program. A piece of code I myself am extremely proud of, and would never be able to do if I was to think it out. Look how the robot navigates so clever.. I made it do that! This IS a REAL program, it just felt like cheating because I found the method; Teach, don't program.


Of course what comes out in the end is great code. What happens is of course that you start re-using routines, put functions into each other (you might as well, it is easy), create master-routines and sub routines etc. But you do not focus on this, the programming.

I am just saying that I learned that teaching is not cheating - it was a mental thing for me to first swallow the pride, and then actually come out on the other end with a cool autonomous robot in my hands, and being able to make more, and more complicated robots with great ease.

That is the experiance I am trying to give to you.


It took me some time before I could admit that this was actually just how I do it. No neural networking here in the little Picaxe-brains.

But I realized that most people see the robot for what it does, for the fact that I really made it.

I am a very happy and inspired robot-builder now, I can build in no time, make robots do all sorts of things - I want you to feel the same way, that is my only mission. If you have fun in other ways.. that is just as cool, and I want to hear about that as well, and get inspired and learn from you as well :)

/ Frits

Ah yes I think I know what you're talking about when you say "teach"...

You're quite right that you will never be able to predict everything and make one grand program that just works and doesn't need tweaking or alterations. This is actually one aspect of the agile method of developing software... recognizing that writing software is an iterative process and you just go ahead and write the code you see is necessary for meeting the demands you see right now and then maybe there appears a new demand and you then modify the code to take that into consideration also.

I was just barking at your use of "teaching"... yes, I'm that kind of barking guy :-D

Also I think that it's awesome that you want to share your experiences of success. You're an awesome builder that really can build in no time (I saw that when I visited you once and we were to build a robot each... mine just never happened :-)).

I'm looking forward to seeing your new projects!

- Jimmy

I don't mean to put you down or anything but since you have bugged me so many times I think I'm allowed to bug you just a little :-)

IMHO your YDM is really great and innovative (along with many of your other robots) but there is no teaching involved in the way you program it. The way I see it teaching is performed when the robot is actually alive and not while it is laying dead with a programming cable attached to it. What you are doing seems to be specializing the program to every situation you put it in according to what you want it to do. It works for you so that's great. Others might not like working that way and want to test sophisticated algorithms and stuff.

Since you mention them... using neural networks would be more like teaching since the robot would be alive and it would probably feed its sensor inputs into the neural network and act based on that input. You would then maybe reward it or punish it somehow (would be neat to be able to kick it for punishment) and it would adapt and learn from that.

I know you also want people to build a lot of robots and publish them on this site but I remember some old guy saying that quality beats quantity. I say that people should build robots the way they feel like it and that lives up to their own goals and expectations. Some users are great programmers and probably want to implement advanced stuff like fuzzy logic or neural networks with image processing, some are great electronics wizards and probably want to make awesome circuit boards with wifi and other cool stuff and yet some are trying to grasp the whole electronics/programming thing for the very first time (and will be very happy to read you "first robot" walkthrough.

Oh well that's just my opinion, now I will go back to building on my simple line follower :-D

- Jimmy