Navigating a tracked robot accurately with IMU+Encoders

Hi
I have been working on a tracked robot using motors with encoders however this was not navigating accurately(A 90-degree turn would be just under or over, so not good enough for doing what I wanted it to do) so I got an IMU(MPU6050) however while this gave me an angle for changing direction it just wasn't good enough and I am still not getting a crisp 90-degree turn even if the serial monitor says that it has turned exactly 90 degrees. The code I use is attached below, if anybody sees any problem with the code or the hardware selected or knows something that could just solve the robot angle turning problem(it is odd to me that this problem hasn't been addressed by a single sensor made for purpose) that would be greatly appreciated.

(I excluded a bunch of the misc variables)

Code:

void loop() {
  // driveForward(40);
  //  stopFun();
  turnLeft();
  //driveForward(50);
  stopFun();
  //driveBackward();
  delay(200000);
}




void encoderFun()
{
  B = digitalRead(EncB1);
  if (B > 0) {
    pos++;
  }
  else {
    pos--;
  }
}

void gyroFun()
{
  gyroZ = mpu.getRotationZ() / 131.0;
  if (isFirstLoopComplete) {
    timeForOneLoop = micros() - previousTime;
    gyroDegree += gyroZ * timeForOneLoop / 1000000.0;
  }

  previousTime = micros();
  if (!isFirstLoopComplete) {
    isFirstLoopComplete = true;
  }
  Serial.println("Angle: ");
  Serial.println(gyroDegree);
}




void stopFun()
{
  Serial.println ("Stop");
  digitalWrite(INA1, LOW);
  digitalWrite(INA2, HIGH);
  analogWrite (PWMA, 0);


  digitalWrite(INB1, LOW);
  digitalWrite(INB2, HIGH);
  analogWrite (PWMB, 0);

}
void turnLeft()
{
  Serial.println ("Turning Left");
  
  while (abs(gyroDegree) < 90)
  {
    digitalWrite(INA1, LOW);
    digitalWrite(INA2, HIGH);
    analogWrite (PWMA, 150);


    digitalWrite(INB1, LOW);
    digitalWrite(INB2, HIGH);
    analogWrite (PWMB, 150);
    gyroFun();
  }

I don't see anything obvious unless gyroDegree is an integer type and not a floating point type.

You say that you don't get an exact 90 degree turn but you don't mention how far you are off. Is it off by just a few degrees or many tens of degrees?

Gyro integration won't be accurate over more than a couple of minutes, especially if you have not calibrated the gyro, that is, subtracted the offsets.

A magnetometer or electronic compass will give you much more accurate and stable headings, but it absolutely must be calibrated in place, to remove the magnetic offsets.

I have done the calibration, do you have a recommendation for a magnetometer or electric compass? Also, how long would it take to calibrate and if it were to move 100 feet from the calibration location would the accuracy diminish - i don't know much about them so some context would be awesome.

It is a floating point type, it is off by like ~2-10 degrees so not massive but too much to navigate accurately.

The LIS3MDL magnetometer works very well as a digital compass.

Compass calibration takes care of the magnetic field distortions produced by your robot and nearby magnetic materials, and must be done after mounting the magnetometer on the robot. It doesn't matter where the robot is after that, unless the robot is placed near a large bit of iron or magnetic material.

For a "quick and dirty" calibration, try this.

For really accurate calibration, this procedure is much better, but more time consuming.

2 to 10 degrees of error could easily be caused by gyro drift if you have done nothing to calibrate it away. One thing you could do as a test is to sit still for a few seconds before making the turn while keeping a running total of the gyro values you get back, divide that sum by the sample count just before starting to make the turn to calculate the average amount of drift. Subtract this drift estimate from gyroZ in gyroRun() and see if it improves the heading angle at all.

Inside I have found magnetometers to be a bit error prone. On a smaller bot, the magnetometer ended up quite close to the floor since the bot just wasn't that tall. Moving around my living room, I would get a 5 degree deflection is some areas. Probably wiring or duct work under the floor. On another bot that was taller, this wasn't such an issue but when it went anywhere near my refrigerator, it would experience a major deflection in the compass heading.

I did have much better luck with them outside though but I have seen some bots get tricked by something under the ground before and just end up turning in circles around it. I haven't hit this personally yet though.

unfortunately, I don't know how well this would work in my target environment - a restaurant. Stupid Question: would it be easier to just use SLAM or something similar instead?

I have done the calibration that comes wit with the library, I will try that averaging trick however I am not sure if this would even work in my target environment due to the generally large number of metal objects: a restaurant. Stupid Question: should i just use SLAM instead, as it seems more fleshed out. I haven't used it yet because I have no experience with it but if you do how did it go?

All the options are very difficult, especially in a complicated environment like a restaurant. And much worse with people moving about.

I haven't used SLAM yet myself.

Are you trying to cover all of the floor in a restaurant as required for cleaning it or are you trying to follow a certain path as required for moving food, etc around? The reason I ask is that the second one might be more easily done by embedding wires in the floor and tracking them instead. Maybe something like Evolution Robotics NorthStar system, now owned by iRobot and used on the Braava floor cleaners, could also be used as it works by projecting an IR pattern on the ceiling and then using sensors on the robot to detect its placement and orientation.

I am aware of that, I am leaning towards going to SLAM without a better option - as @ibuildrobots said, that North Star would be good but I am planning to use it both inside and curbside in restaurants so mapping seems the best options. My question for using SLAM is, if I map it how would create paths through those maps - that is what I haven't been able to find resources for. I might just be using the wrong search keywords though.

Search for "maze solving algorithms".

And then convert that to working through the mapped areas? That seems like a good idea, thanks, will take a look.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.