## Why did I use encoders in Vex inverted pendulum?

To make an inverted pendulum behave like a regular pendulum you need to have a torque feedback proportional to tilt angle. A motor is a torque device as long as the back emf voltage generated by the motor speed doesn’t cancel the voltage command. So the torque will “washout” to zero as the motor speeds up and there will be nothing left to stabilize the robot unless you add some more command.

Its kind of a race between the dynamics of the pendulum and the dynamics of the motor/gearing. You want to get to the stable vertical position before the motor torque washes out. The pendulum can remain stable independent of speed so long as there is torque available.

So the motor is really a speed device in the long term and a torque device in the short term ( as long as there is current flowing). It would be nice to have the command increase automatically as the motor speeds up to counter the back emf voltage reduction in command.

Here are two approaches to helping the problem. One is to have a forward path integration on the angle error ( the I in PID) . This can stabilize the vertical but you still don’t know your wheel speed. I tried this but the nonlinearities of my Vex motors complicated the problem so I gave up.

The other way is to estimate motor speed and feed it back with the opposite sign of the back emf voltage so as the motor speeds up the command increases to counter the back emf and you can maintain a torque proportional to angle. We can estimate motor speed from wheel rate derived from differentiating encoder position. I prefer encoders since with wheel position and speed you can now add more PID loops to control velocity, position and turning.

Gear ratio which I define here as motor speed/wheel speed is important to the problem. There is an optimum gear ratio that keeps the motor torque from washing out too fast yet gives you the torque necessary to recover from a given tilt angle. If the gear ratio is too high, the motor sees a small inertia load and gets to speed very fast and you lose your torque. If the gear ratio is too low, the motor maintains its torque longer but the torque is very small on the pendulum body. Hence you can only recover from small tilt deviations from vertical. So there is a trade off. You will have to experiment with different gearing ratios..My robot can handle about 15 degrees off tilt.

### 5 Responses to Why did I use encoders in Vex inverted pendulum?

1. Harley says:

#pragma config(Sensor, in8, , sensorGyro)
#pragma config(Motor, port1, leftmotor, tmotorVex393, openLoop)
#pragma config(Motor, port10, rightmotor, tmotorVex393, openLoop, reversed)
//*!!Code automatically generated by ‘ROBOTC’ configuration wizard !!*//

{
int degrees10 = 10;
int degrees0 = -10;

SensorType[in8] = sensorNone;
SensorType[in1] = sensorNone;

SensorType[in1] = sensorAccelerometer;
SensorType[in8] = sensorGyro;
wait1Msec(2000);

while(1)
{

if(SensorValue[in8] >= degrees10)
{
motor[rightmotor] = -45;
motor[leftmotor] = -45;
}

if(SensorValue[in8] <= degrees0)
{
motor[rightmotor] = 45;
motor[leftmotor] = 45;
}

}

}

This is as close as I've come to your pendulum bot. I'm new to this and am using the Vex encoder and gyro instead of your custom ones. I have no idea how to get the thing to balance out and am asking for your help(like how to integrate the encoder part in).

2. vamfun says:

Sorry, I didn’t notice this comment. How are things going? Can I still help?

• Harley says:

You could try, but as you can see with the code I have no idea where i’m going with it. I have no idea how to integrate the encoders in without it getting to complicated. Without them my balance bot just keeps overshooting. An accelerometers is in the code, but not used.

3. trungvn says:

Hello, Could you give code for blancing robot not use encoder?? Thank you!!!!

4. vamfun says:

Here is a link to the original code that was compiled using MPLAB.