Line follower at T junction

According to the input given via keypad sometimes the robot must take a left and at times take a right at a tee junction. But the robot always takes only a right or only a left at the tee junction. What must I do?

I have attached my code. I have used an RFID reader and tag to stop.

LFOLL_rfid_key_1_4.ino (17.4 KB)

This is ridiculous.

Do you actually expect someone to figure out and comment on code that contains dozens of if statements like this:

  if(digitalRead(2)==HIGH && digitalRead(3)==HIGH && digitalRead(7)==LOW && digitalRead(4)==HIGH)

and no meaningful comments?

Two weeks from now, even you will forget what a line like that is supposed to do.

I'd add some debug prints, and then fix the problem.

I'd also factor the code to make it smaller and more legible.

Ok. Even if you just ignore the code, my only doubt is how do I make the robot take a right turn at a T junction. At times it takes a left and at times a right.

There's no chance of my forgetting that code because it is completely mine and I work with it for about four hours a day. Those are just sensor positions. But I apologise for not adding comments. I agree it looks a mess for an outsider.

if you just ignore the code,

OK, if you insist.

@sulivuli, In addition to what has already been said it seems to me unreasonable to expect someone to "debug" 17.4k of code without a single indication of where the problem may lie and no indication of the steps you have taken to find the problem yourself.

Debugging requires a a lot of patience and attention to detail and the starting point is to display the progress of the code and the values of key variables with Serial.print() statements. Checking the values of variables immediately before they are used in IF statements can be instructive.

Have a look at how the code is organized in Planning and Implementing a Program. Small single purpose functions can be tested in isolation from the rest of the code. Meaningful function and variable names (including pin references) are essential.

...R

You have 78 occurrences of the following code

analogWrite(5,160);
  analogWrite(6,0);
  analogWrite(10,0);
  analogWrite(11,160);

That should be a single function, called 78 times (and even that could be factored-down, I suspect)

You have 64 occurrences of (digitalRead(2)==HIGH && digitalRead(3)==HIGH && digitalRead(7)==HIGH && digitalRead(4)==HIGH)
That should also be a single function.

Use sensible names for pins, not just numbers.

And auto-format your code - it's virtually illegible.

And comments.
You must comment, and not the sort of comment that repeats verbatim what the code has already told us.

There's no chance of my forgetting that code because it is completely mine and I work with it for about four hours a day.

I think you are in for a surprise.

jremington:
I think you are in for a surprise.

+100

...R

sulivuli:
There's no chance of my forgetting that code because it is completely mine and I work with it for about four hours a day.

This statement is only true now. Tell me you can say the same thing is 30 years after you have written millions of lines of code!

I have had to revise code that I wrote 30 years ago. Without descriptive comments, meaningful variable/function names it is easier to start from scratch.

Have you ever heard of 'DOS' COM files or Overlay's? how about Segments? Interrupt 21? Let alone what the parameters are for:

    lds dx,Buf1
    mov [dx], 7
    mov ah, 10
    int  21h

Any Idea what this code does? It reads upto 7 characters from the keyboard, Storing them in the memory point to by DS:DX

Chuck.

chucktodd:
Tell me you can say the same thing is 30 years after you have written millions of lines of code!

Never mind 30 years. I don't remember after 30 days.

And I suspect the risk of not understanding would be much greater if you are not regularly programming.

...R

Thank you all.
I've solved my problem.
I'll use functions to control my motors as you have suggested @AWOL.