robot doesn't turn right (literally)

this is my second problem today, is that normal?
anyhow, for some reason my robot turns left fine(2 driveleft==90 degrees, 2 driveright is SUPPOSED to be 90 degrees too) but right turns, it just jults, as if there is some problem with the loop system. my code is very complex, because out of boredom i decided to code an OS, for the actual code that runs the robot, so i will give all the important bits:
the main, robot code:

void mainrun()
{
  if(dist>myread(1,250)) { //wall nearby
collect();//colect sensor data
 decide();
   Lset(2);//set directions
  Rset(1);//in witch to drive/continue driving
  }else{
  drive();//continue forward
  }
}

the collect:

void collect()
{
  driveright();
  driveright();
  leftside=analogRead(A0);
  driveleft();
  driveleft();
  driveleft();
  driveleft();
  rightside=analogRead(A0);
  //note-robot still faces right!
}

the driveright:

void driveright()
{
  Lset(2);//set directions
  Rset(2);//in witch to drive
  for(times=0;times<myread(2,100);times++)
  {
    drive();//drive for duration
//delay(300);
  }
    Lset(0);//set directions
  Rset(0);//in witch to drive/stop
  delay(500);
  drive();//stop
}

the code for drive left is precicely the same, exept Lset and Rset are both 1 instead of 2. i checked by copying driveleft and changing those 2, but it didnt work.
drive code:

void drive()
{
 switch (Lstatus) {
  case 1:
 Lfront();
break;
case 2:
Lback();
break;
 }
  switch (Rstatus) {
  case 1:
 Rfront();
break;
case 2:
Rback();
break;
 }
}

finaly, Rback/front:

void Rback()
{
 digitalWrite(Rmotpin,HIGH);
delayMicroseconds(0010);
digitalWrite(Rmotpin,LOW); 
}

Rfront is the same, but the delay is 2000, and Lfront/back has Rmotpin swapped with Lmotpin.

wow I have a lota code. I hope I have enough code for you to find the problem, yet not so much so you will actually reply :slight_smile:

delayMicroseconds(0010);

Any particular reason for specifying delays in octal?

because out of boredom i decided to code an OS

?

AWOL:

delayMicroseconds(0010);

Any particular reason for specifying delays in octal?

because out of boredom i decided to code an OS

?

1st one: octal? 2nd one: I had the OS as a seperate sketch, and desided to give it some use and import it into my robot sketch. it now controlls setings, what the remote buttons do, witch program to execute(currently 1, that one, there will be things like dance) and even a mini programming system in witch you enter directions and saves them into an array, although there is no conditional branching, still, usefull. (currentlu this stuff is 6KB out of 32, nice)

whell, what do you do if you have code for an OS, and a robot, and an ardurino board? you combine em all!

1) Yes, octal.

2) OS?

AWOL: 1) Yes, octal.

2) OS?

what is octal??? 2. Operating System. what you are using to type?

and can you find the problem? check my sig to see the setup, if that helps for whatever reason.

http://tinyurl.com/nrmq4s

  1. Operating System. what you are using to type?

An application running in a framework. Why do you ask?

Rfront is the same, but the delay is 2000,

So, for one, the delay is 8 microsceonds, and for the other 2000 microseconds?

AWOL:
http://tinyurl.com/nrmq4s

  1. Operating System. what you are using to type?

An application running in a framework. Why do you ask?

Rfront is the same, but the delay is 2000,

So, for one, the delay is 8 microsceonds, and for the other 2000 microseconds?

yes, its called a SERVO. that is how you controll them! this is a full-rotation servo.
look-it-up.
and i didt use the servo libary, cuz i wanted to write it myself, so i have more controll.

yes, its called a SERVO. that is how you controll them!

I think you're confusing your millis with your micros. (I know what a servo is, I've been connecting them to microprocessors for rather more than 30 years)

yes, its called a SERVO.

First mention of that on this thread - why the attitude?

this is a full-rotation servo

You mean an ex-servo.

AWOL:

yes, its called a SERVO. that is how you controll them!

I think you're confusing your millis with your micros. (I know what a servo is, I've been connecting them to microprocessors for rather more than 30 years)

yes, its called a SERVO.

First mention of that on this thread - why the attitude?

because, for some reason, you keep questioning my questions. coding problem.you=30 years of experience. probably a stupid mistake. you fix error, and tell me how stupid i am to miss that. that is how it works on all other fourms ive been to. dont you understand the question? i diceded to go into microseconds due to the other servo-witch wrks in microseconds. it works, so why shud i change it.

enything else? can you fix/ find what's wrong?

tell me how stupid i am to miss that

I already did that in reply #1

I questioned your questions because you didn't tell us enough information. Like the robot has ex-servos to drive the wheels. Like why you would want to feed an ex-servo an eight microsecond pulse.

OFF TOPIC AGAIN. how is this so hard?(DON'T ANSWER THAT) am i missing something?(DON'T ANSWER THAT)

Can you type "1000" instead of "0010"? Does that fix your problem? It will multiply the length of your pulse by 125, and should get closer to what the ex-servo is expecting.

how is this so hard?(

It is hard because you don't see what I see.

You have all the code (and the "OS") in front of you - I could not have known you were driving an ex-servo, because none of the numbers I saw in the little bit of code you deigned to post related to anything that a servo might expect, and up until you wrote "SERVO" in a stroppy teenage stylee there was no explicit or implicit mention. I still don't know how you're deriving the 20ms frame time.

Stop and think before posting.

somehow, it did.

or it was some other change i made at the time. now i have other infinite loop probs, but im not stuck yet.

Maybe your OS's pre-emption isn't quite right yet.

I am amazed by OP’s attitude, expecting others to fix his issues, but taking offense whenever he has to actually help in the process.

@thatdude624

1st. That is very impressive work you did. Great job !!!

To help you , I may ask questions, so bear in mind with me. I am just trying to be open minded.

I check you program, and the robot work when turning left and not working turning right ? Correct ?

I am just curious, can you please post the code for the “left turn” subroutine, if the code for left work, that it should be the “kind-off” the same for right. And also when I troubleshoot my project, I always check the hardware, test the hardware and make a program to test the hardware. It possible for you to do a program to test your robot.

void driveright()
{
  Lset(2);//set directions
  Rset(2);//in witch to drive
  for(times=0;times<myread(2,100);times++)
  {
    drive();//drive for duration
//delay(300);  <-- This line is inside a comment  Humm...small mistake maybe
  }
    Lset(0);//set directions
  Rset(0);//in witch to drive/stop
  delay(500);
  drive();//stop
}
void Rback()
{
 digitalWrite(Rmotpin,HIGH);
delayMicroseconds(0010); // <--- You mean 10 microseconds right ?
digitalWrite(Rmotpin,LOW); 
}

delayMicroseconds(0010); // <— You mean 10 microseconds right ?

No, he means 1000 microseconds. Read the thread.
A ten microsecond pulse would be about as useless as the eight microsecond pulse specified.

this is my second problem today, is that normal?

No, just another slow day.

@AWOL

opps... To be honnest, It look like a 10 to me.

opps... To be honnest, It look like a 10 to me.

It does, but with the OP's lack of attention to detail (and ignorance of octal), and the requirement to drive an ex-servo from extreme to extreme, 1000 (vs.2000) sounds more likely.