Hi Jason,

I've got a wandering robot when trying to do a PID line follow on the Obstacle Course.

It follows the line (very very slowly!) staying within +- 5 of the threshold.

Problems start when the robot almost completes the first turn and the compass reads about 138. The error gets really big and the robot begins to wobble and not move forward any more. I suspect it is shooting over the line and freaking out with the maths.

The robot is going slowly because I thought slow would be more accurate, but the same thing happens when power is big (say 25 or 35).

Any ideas?

Cheers

Leslie

while (nMotorEncoder[leftMotor]<4000)
{
float turn;
float targetPower=10;
float error;
float kp=1;
float powerRight;
float powerLeft;
int threshold=50;

error=threshold-SensorValue(light);
turn = kp * error;
powerRight= targetPower + turn;
powerLeft= targetPower - turn;

motor[leftMotor]=powerLeft;
motor[rightMotor]=powerRight;
}

This is not a PID algorithm, it is simply a P algorithm. That is, you only have the P value. It's directly proportional. The problem with this, is that it can get very "freaked out" as you put it and just wobble back and forth. PID is really not needed in VW, but I can give you some sample code if you want true PID. Because, as I said, this is just using the P parameter.

Hello again.

Thanks for getting back to me so quickly. I've just had a look at the class from 01 July, and seen the part on the I and the D. I'll give it a whirl.

Cheers

Leslie

Hi Leslie,
The other thing you could try is bounding the control signal:



As you've noticed, if the error becomes too large, then your forward movement command can essentially become a point turn. By limiting the magnitude of turn to be no more than targetPower, the robot will only ever do swing turns. You may need to tune the bounds to get the best behavior.

Cheers,
--Ryan

Hi Guys,

It's still wigging out at about the same place, even with programming out the errors that get too large.

Any suggestions?

Many thanks in advance for having a look.

Leslie

Hi Leslie,
Usually when coding bounds you have the value in the if-comparison and the value set in the if-block as the same, so your code would be something like:



otherwise your power values will jump around in weird ways. That aside, I just tried running the code from your original post on the Obstacle Course virtual world, and it worked fine for me for the entire length of the line. One thing that comes to mind is if the virtual world is running slowly, the sensor value may not be updating very often. Can you load one of the utility tables and check what framerate you're getting while your program is running? It's displayed on the utility tables in the bottom right corner of the screen in white text, so it might be easier to read on one of the tables with a surface that isn't white.

Thanks,
--Ryan

Hey Ryan,

Thanks for checking my code. That's great news that it works on your system.

I looked at the fps rate and it's mostly hovering in the 90s with dips down to 47 and sometimes up to 118. What do you reckon it is supposed to be? Is it meant to be this volatile? I am working on a laptop with display of Mobile Intel 4 Series with 1300 MB graphics memory and 32 of video (this hardware stuff is not my forte!).

Thanks for your help.

Leslie

Hi Leslie,
Those numbers sound high enough. The framerate will fluctuate to a certain degree; it is marginally possible this could be the source of the problems, but I doubt it.

Something I should have checked initially: which versions of ROBOTC and Curriculum Companion are you using? The latest is 3.61 for ROBOTC and 2.4.0 for Curriculum Companion. If you're not using the latest, can you upgrade and see if that helps?

Thanks,
--Ryan

Hi Ryan,

Thanks for getting back to me about my PID issue.

My gear is fully updated. I think I will take it on the nose and move on now and out the whi,e thing down to a gena, weirdness. I enjoyed learning about the PID, and if it runs on your system, then fab,

Cheers,

Leslie