Let's Make Robots!

The Watcher - update 8 March 2012

forwardesc.pde1.58 KB

Hello everybody! Here is my first robot. It is so sweet:) I love it! :) At the moment it is not autonomous, but in the future it should be. It was not so easy to fit all the components into this little chassis, that’s why there are so many cables and wires. Actually in my plans was to attach ipcam on it, but now there are no place for the cam. Maybe I will build one floor more, or some how else fit the cam on it. Like you saw on the video I`am controlling the robot via Xbee, but in the future I will control it thru the internet(ethernet shield). Adaptive mapping is all so very interesting..:) So the hardware is done and now is start for software:) More pictures you can see here: http://www.instantgallery.de/i/mtik3j/20046216



Update 28.02.2012

Hello everybody,
I have a little problem with my robot. The problem is that it doesn't goes straight forward. Sometimes it change direction by it self.. smiley-roll I wrote the code that I’m using and I shoot a video how it looks like in reality. Maybe someone has a better solution(code) how to get it working. My encoder wheel has 12 counts for one rotation, so every 30 degrees comes a count.
Thank you very much!


Update 08.03.2012

First try that the watcher drives alone:) It was more front sensors test than autonomous driving:)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hi this is a very good begin! But, i dont understand one thing, what's the function of all those sonar? and sorry for my english, i naturaly speak spanish


When the robot will be autonomous, it will need to "look" left and right if in front will be obstacle. 

at the values that L_forward_esc_counter and R_forward_esc_counter contain? It may be that your information is either bad or wrong, thereby causing your robot to arc rather than travel in a straight line.

The other bit I notice is that you are using numbers that are set in stone rather than using the encoders to adjust the speed of the motors.

I would suggest:

void forwardesc() {
   if(L_forward_esc_counter == R_forward_esc_counter) {      //If the left and right wheels has the same counts
      forward();                                                                     //We go forward with both wheels
   else if(L_forward_esc_counter > R_forward_esc_counter) { // If left wheel has more turns then the right
      analogWrite (MOTORAF, (speedo * R_forward_esc_counter / L_forward_esc_counter));  //Slow down left wheel
      digitalWrite(MOTORAB, LOW);
      analogWrite (MOTORBF, speedo); //Move right wheel at commanded speed
      digitalWrite(MOTORBB, LOW);
   else {                                                                             //else if right wheel has more turns then the left
      analogWrite (MOTORBF, (speedo * L_forward_esc_counter / R_forward_esc_counter));  //Slow down right wheel
      digitalWrite(MOTORBB, LOW);
      analogWrite (MOTORAF, speedo);  //Move left wheel at commanded speed
      digitalWrite(MOTORAB, LOW);

**My notes/chicken scratch on figuring this out:

If the left motor is moving at the commanded speed, then the right motor needs to be increased.
If the right motor can not move any faster, then full speed must be limited to the speed at which
the right motor can move.

150L 100R // These are the encoder counts that are read.
and the left wheel is turning faster
speedo * 100 / 150

speedo = 150
150 * 100 = 15000 / 150


Thanks for your replay! I have tried the code below, but it doesn't work better. My code (forwardesc) actually works better. I think speed up on the other side must be. There are reason for that:

150L and 100 R this different between wheels can not be, because if different 8 counts, the robot turns 90 degrees left or right. So when it goes straight forward there are always different 1-2 counts between left and right.


So 102L and 100R. //Right wheel has more counts, so we must turn right. To turn right we need to slow down right wheel

Speedo = 150.

So = speedo * R / L

150 * 100 / 102 = 147;

analogWrite (MOTORBF, 147); //Move right wheel at new speed

analogWrite (MOTORAF, speedo);  //Move left wheel at commanded speed

Now you see the different between speedo and right wheel is only 3. And this is not enough, maybe it will work if robot will drive forward couple hundred meters, but not 1-2 meters.

Or I have don`t understood what you mean?



I believe my thinking is correct, still. Is there any chance you can put higher resolution encoders on your wheels? If they are just printed sheets, there are ways that you can get higher count encoder wheels as an image that you can then cut out after you print them. My thinking is that maybe(?) your encoders are too coarse to get a good read on how far the wheels are off and therefore you can only get close with driving the robot straight.

I am only shooting in the dark here. I have no practical experience.

Yes, I will cut new encoders wheels. Old encoder wheel has 12 counts for 360 degrees. And new encoders will have 16 counts for 360 degrees. But I think it will be still not enough.. I made now a new calculation - speed. So now when the robot goes forward I know the speed. Minimum speed about 10cm/sec. and maximum speed is about 145cm/sec. I think this data is more important then speedo. What you think?

Very nice and smooth obstacle avoidance! Well, at least until the end. ; j

Looks like the addition of some bumpers would be a good idea for when you overdrive your sensors and actually hit something.

Yes, I will add bumpers and maybe couple sensors more:)