# Self Balancing Bot and understanding the setpoint with Code

All,
I have been perplexed for some time regarding the setpoint of the PID for a self balancing bot.
I see from the FRank code and others the setpoint is 174.X to 180.

I will attached that part of the code.

My Question is, where does the setpoint value come from? My understanding is the value the PID attempts to reach as the bot leans (pitches).

Here is the typical code.
Complete code attached

//PID

#if MANUAL_TUNING
double kp , ki, kd;
double prevKp, prevKi, prevKd;
#endif
double originalSetpoint = 174.29;
double setpoint = originalSetpoint;
double movingAngleOffset = 0.3;
double input, output;
int moveState=0; //0 = balance; 1 = back; 2 = forth

#if MANUAL_TUNING
PID pid(&input, &output, &setpoint, 0, 0, 0, DIRECT);
#else
PID pid(&input, &output, &setpoint, 70, 240, 1.9, DIRECT);
#endif

Help appreciated.

Franko.ino (7.47 KB)

My Question is, where does the setpoint value come from?

The person who wrote the program probably experimented, and found that 174.29 worked.

So in theory, my setpoint is imaginary? I can set it to any value and the PIC with attempt to match that value either driving the motors more forward or more reverse

correct?

You can set the setpoint to anything you want. The key is to find a value that makes sense and also works.

dmcland:
My Question is, where does the setpoint value come from? My understanding is the value the PID attempts to reach as the bot leans (pitches).

'Setpoint' is a control systems word/terminology. It's basically the main or master input value to a control system... usually an automatic control feedback system. The output of the system is meant to automatically reach a stable value that is based on the setpoint (or input) value.

The angle '180 degrees' could be a value that is meaningful only to the person that wrote the code. Unless the code has comments that indicate what '180 degrees' means (in terms of the particular control system being implemented), then it would either be necessary to make educated guesses about it, or just start from scratch
(and implement our own code).

Normally, if dealing with pitch, it would be something like 0 degrees for vertical bot position. And the pitch would normally be measured in the range from -90 to +90 degrees. And, if the sensor isn't calibrated (or "zeroed") to give exactly ZERO degrees for VERTICAL bot, and if you suspect that -2 degree is the vertical position, then the "setpoint" (or input value) would be set to "-2 degree". But, if the angle sensor is calibrated (zeroed), then the setpoint should be set to "0 degree". The bot would then always work toward driving the output to the 'zero degree' condition.

The output works toward the 'zero degree' condition when the setpoint (input) is set to '0 degree' for the case when the control system is a 'unity negative feedback system'. Thank you,
I now have the answer I am looking for.

I will start with 0, then see how the bot performs

gratefully,

Darrin

Given the code value of 174.29, it is more likely that 180 should be straight up (in the ideal case), but measured in degrees, it is also possible that zero would be equivalent to 180.

Understood,
when i hold the MPU6050 in my hand it has an X and Y marking

Also,
from what I found so far the MPU does not know the difference between up or down, just pitch, yaw and roll, right?

Also, when I look deeper into the Franko code I find that he added this logging code
#if LOG_INPUT
Serial.print("ypr\t");
Serial.print(ypr * 180/M_PI);
Serial.print("\t");
Serial.print(ypr * 180/M_PI);
Serial.print("\t");
Serial.print(ypr * 180/M_PI);
Serial.print("\tout: ");
Serial.println(ypr[YPR_OUTPUT_SELECT] * 180/M_PI + 180);
#endif
input = ypr[YPR_OUTPUT_SELECT] * 180/M_PI + 180;

So your advice to start at 180 may be where I should start.

More to come.

Darrin

Update, I ran a MPU Test and discovered that the values are impacted by the orientation of the MPU.
With the chip laying flat x to the front and y pointing to the rear, pitch was .04. As I rocked the bot, the pitched changes.

here is the code I used

Enjoy

this provides Pitch, Roll and Yaw

MPU6050_Test_Code.ino (9.56 KB)

All,
the setpoint is important as I discovered. For example, my setpoint is 180.5 and this centers the bot perfectly straight up and down. When I change the setpoint to 178 the bot leans forward trys to keep center of gravity. If I set the setpoint to 182 the bot leans back and then tries to balance.

So I can assume that Franko code uses the 180 as the center position or as close as it can.

thank you all,

next I wan to trade the brushed motors and L298N to steppers.

New thread for that one

cheers