Let's Make Robots!

How to build your first robot - Part II - navigation


Your browser is not able to display this multimedia content.

Your browser is not able to display this multimedia content.

clean_navigation.BAS6.17 KB

This is Part II of How to build your first robot - tutorial.

you can just take the cool navigation-code in here and have fun with it, or you can follow the whole instruction, or the parts that you like. I try to make it as general and open as possible.

Here is part III of this tutorial - I recomend that you browse this as well!


You have made a robot, something like this: How to build your first robot

You have read my deep thoughts on how to move on with the programming "Don't program your robot.. Teach it!", and you have made tricks with your robot, messed around with it, had some fun and is ready to move on.

Perhaps you have tried out this little trick of seeing what your robot sees.

You have seen on the video of "Making Skiwalker", and seen on the pictures of "Yellow Drum Machine" (the pics in the bottom) - that you do not need much for materials to make a robot; Melt-glue, double sided tape, sticks, and you are go!

If so, this part II should be a breeze! You can make this robot in 45 minutes, no sweat.


First, let's make the robot on the picture above. Try to duplicate the main parts, that is the main task here.

It shuld not need much explantion, it is excaxtly like the one from How to build your first robot - only differences:

  • Instead of Sharp sensor, I use SRF05
  • The servo is a smaller one, and a fast one - you can get these in any size and speed
  • The gearing on the motors is lower, so I have a faster robot (though it is not a speed-king, lol)
  • instead of just taping it all together, I have used 3 sticks to form some sort of a "chassis"

The closer you get to this, the easier it will be to follow the rest, but of course you can just do it your way, with whatever parts you have etc.

In the first tutorial I wrote that you could make some fancy code for the robot.

I now present you for some code that I have made, it is what is used on the video. It is an example, there are thousands and millions of ways to evolve, you should do it your way. This is just to try to open your eyes, and share what I have learned after countless hours of trial and error.

Try to alter some of the numbers to tune in to your setup, and read the guidelines in the code. That way you can get a robot like the one on the video, and we are going to use that as a base for Part III in this tutorial...

Find the attached code in the top of the post.

.. And the screwdriver-trick on the video?

Well.. Look for places where the code says

servo Servopin,head

and add, just after it

servo 1,head

If you are adding another servo on pin 1.

Think about what to attach instead of the screwdriver?

Something with an LED on? And insert some on/off in the code for the LED? Or a fan? or.. :D


Stay tuned. This bot is getting more enhancements now..

And if some of the comments below does not make sense, please understand that I am changing this over time, so the comments may have been for an earlier text here :)

Thanks, and do post what robots you make, to inspire back. Thank you.

/ Fritsl

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
The problem is, that MayTurn is never initalized with a value. You only add and subtract to/from MayTurn, never assign an initial value to it to begin with. The reason it might work anyway may be because the Picaxe initializes all registers to 0 so your MayTurn has an initial value of 0, but it would have been nicer and more "clean" to have a "MayTurn = 0" line in the beginning.

Uh, no I disagree 100%!

To me the art is really using the chip, not to make long code. I have made many much "worse tricks" than this in my codes, I like it that way, but I guess it is a matter of taste :)

Say instead of writing 


if bit0 = 1 then
bit0 = 0
bit0 = 1
end if


I simply write


inc bit0


Which gives 100% the same result in every way!

Though it may be "ugly" to some, I myself find that to be more correct. The variable overflows, I know it, and I use it.

I find that setting a variable to 0 in the beginning of the code is a mess, absolutely pointless. It IS 0!

But I understand those who like to do it "the hard & correct way", it is just not the way I think, and not the way I like it, I feel more like I am mastering the chip & language the way I do it :)

Well, I would have written bit0 = !bit0. But I'm using C, not BASIC. Is it documented that the PICAXE initializes everything to 0? If not, then it's dangerous to just assume that your variable is 0. Working as a programmer, you learn that it is not a good idea to assume that a variable has some specific value. If you want solid code, you have to initialize your code to a known state and you have to test the state of your program, not just assume that something is as you think, because often it isn't
It would be interesting if variables where not set to zero on "boot", but they are, which is logic to me. However, it would be cool if there where some sort of internal registers with self-writable memory, that would open up new posebilities, and you are right, then one should for sure always initialize everything in the beginning of the code, of course :)
When programming PICs in C, for example, there is no guarantee that your variables are 0.
But this is BASIC code, not C
If is stated somewhere that initial value is x, everything it's ok.

Else,  starting value is undefined. The chance that is zero is very high but remeber: variables are memory positions and if not initialized you can say nothing about its value.

I think the major problem is that when MayTurn reach  MaxNumberTurns value never change,

but the BIGGEST problem is that no one read carefully your (nice and very helpful) code  ;))


Thanks for the nice words :)

However, to end this silly talk once and for all:

Variables in the Picaxe are stored in RAM.

All RAM information is lost when the microcontroller is reset.  Hence, all variables are set to a value of 0.

That is affirmative, and 100% sure, you can rely on it, that is how it works.

And so it is ONLY because you may think it looks nice, that you should "reset" any variables to 0 before you do anything else with it's array or value :) Also, it could be used, if you want to write cross-platform code etc. But when using the Picaxe with the Picaxe basic, there is no reason to initialize any variables to a value of zero.. because that is what they are initialized with upon reset!

(End of Story)


 the code I have write for my robot it's very comparable to yours.

 I haven't a code for avoiding obstacles near left and near right.But my bot bot 'search' something interesting and go to it.

(interesting ? what's interesting? this is a Big question... ;) )

Your code is very very helpful; I think everyone must read you code carefully and after write its own program.

What I have notice is that MayTurn is used correctly but never initialized. Probably all registers are set to zeros and everything works, but it's not correct/clean.

Also it's never resetted to a start value:

look the subroutine ForwardLeft_middle:

     If MayTurn < MaxNumberTurns then
    MayTurn = MayTurn + 1
    end if

Ok, what happen if  MayTurn values reach 5 (==MaxNumberTurns) ? It never change to another value, isn't it?

And look the subroutine Sharp_R:

    If MayTurn > 0 then
    end if

So robot EVER turn.


As written to jka above, it is NOT an error that I do not "initialize" the variable, god forbid! :)

When that is said, I agree, there may be a ghost in the machine in the program - I guess when tidying up the code for public release I never got 100% finished with that part.. but then again, it leaves up some fun for you :)

You should have a look at the red/green illustration on this project to understand what I mean by "interesting".