Inverted pendulum project

[Hell-e-Guy]

Hi Guys,

Need your help in figuring out the simplest hardware to build an Inverted pendulum project (2 wheel self balancing robot).

I already hacked a simple RC gyro and took out the analog output of the gyro sensor and made a board with an ADXL202 for Tilt sensing.

Will a 20MHz (5MHz CPU) PIC16f690 do the job???
Will modified RC servos be fast enough (50Hz bandwidth)???

Some C code for PID will be helpful as a starting point.
If anyone has such a code for an 8 bit micro and is willing to share I will be grateful !!!

I read the microchip application notes on the subject and it is pretty clear (in theory...).

Using only one sensor is confusing enough, but how do I add up the data from the two sensors?

Hell-e-guy

[BushmanLA]

Using only one sensor is confusing enough, but how do I add up the data from the two sensors?

Hell-e-guy


You don't. Let one sensor/axis control the motor on the same axis. Let the other one control the motor on its axis.

They shouldn't really have to know what the other is doing to keep upright.

[Hell-e-Guy]

Thanks Bushman,

The problem is that if I'll use RC servos I will need to add the data from both sensors. The reason is that the bandwidth is only 50hz and if I control the even pulses from one sensor and the odd pulses from the second sensor I will loose bandwidth....

Is there a way to control a servo with an analog voltage or PWM? hacking and fine soldering is no problem if needed.

[Comatose]

There's an easy way to do it, but unfortunately you need one more sensor.

The problem with gyros is that they drift with time. SO, you can use the gyro to hold you in position for a second or two, but not for significantly longer.

The problem with accelerometers is they can't disinguish between acceleration due to gravity and acceleration due to motion. So, you can only get a reliable reading from them if they are not accelerating.

If you add wheel encoders, you're in the gravy. Put the accelerometer at the center of rotation of the wheels. Then, using the wheel encoders and the gyro, determine when you're not accelerating or tipping. Any time you reach a "no acceleration/no tip" moment, use the accelerometer data to give the gyro a new absolute reference.

[Brandano]

saw one made out of lego mindstorm that used no gyros. It just had an IR sensor sensing the distance from the ground, and accelerated towards it if the distance was too small, decelerated if it was too large.

edit: here it is
http://www.youtube.com/watch?v=b3vDnwwBmgQ

[Hell-e-Guy]

Thanks guys,

My main concern is the CPU & RC servo speed. Do you think they are up for the task??

[AndyKunz]

Easily up to speed, not a problem.

There's an app note on the Microchip site that might be of interest to you.

Andy

[Hell-e-Guy]

Hi,

Started building the hardware for the project...
In order to make life a bit simpler I thought to use constant PWM to control the servo.
Is it possible to hack a servo and instead of feeding it with a 1-2ms pulse every 20ms to feed it with constant PWM that gives the same average voltage as the regular pulse sequence?

Hell-e-guy

[AndyKunz]

Servos are not driven by an average voltage. They work based upon the edges of the signal.

Andy

[Hell-e-Guy]

Thanks Andy,

I remember I once saw schematics of a servo PCB, but I can't find this site anymore.
Anyone know where I can find such schematics

[BushmanLA]

servos may not be the way to go, or you might want to control the DC motor inside the servo with your own H bridge but still use the feedback pot for position control.

Most servos will work just fine if you update them faster than 50hz too.

[Flipper_118]

I completed the EXACT same project for my engineering class a few months back:

http://www.rcgroups.com/forums/showthread.php?t=674443

(Video of it working is about 3/4 the way down the 1st page of that thread)

I used assembler, 2 geared drive motors and a SINGLE IR sensor. :D

I researched this for about 8 weeks and took about 8 weeks building and programming it....initally I was going to use wheel encoders...but was able to make it work with just 1 IR sensor. The problem with only using one sensor is you have to take into account the speed of the changing angle...an absolute position sensor relative to ground (IR) and a rate of change sensor (accelerometer...wheel encoder) would be the best way to go about it tho...but it is quite possible to complete using just 1 IR and servo's or drive motors.

Feel free to ask any questions...I remeber quite alot of the code...but if your doing it in C it should be alot easier to program then using assembler. :o

Curt

PS - I think we calculated with the speed of my gear motors (not that fast) that we would only need to update at 20Hz to achieve balance....I am fairly sure its running at 20hz in the video as that was the IR's refresh rate.

[Hell-e-Guy]

Thanks Curt,

Looked at your link...GREAT EXECUTION!!!
I would like to get some help with the programming.
Currently, my program looks like this:
- a free running timer generates an interrupt every 20ms.
- the ADC samples the gyro and the accelerometer.
- the gyro's reading is subtracted from the set point reading (I press a push button to calibrate this set point).
- the error is multiplied by a constant and checked for overflows.
- the error is summed up multiplied by Ki and checked for overflows.
- the error is subtracted from the last error and multiplied by a constant (and checked for overflows)
- the accelerometer reading is multiplied by a constant and checked for overflows.
- everything is added up and scaled.
- a PWM pulse is sent to the modified servo.

Currently its far from being able to stay upright...

How did you calibrate your model?

[Flipper_118]

Thanks Curt,

Looked at your link...GREAT EXECUTION!!!

How did you calibrate your model?

Thankyou for the kind words,

My model was calibrated totally by hand. I actually set the model onto the floor and found its neutral balance point and watched the hex value on the output. I then hard coded the hex output into the program...using this as the neutral point I would run the program. If it fell one way or the other I would change the hex value and try again. After about 5 or 10 quick tests I found that on most surfaces I had the same hex value for a perfect neutral point (plus it only had to balance for 5 secs to get my full marks...my teacher was convinced that 1 form of tilt feedback wasnt going to work well enough for it to balance any more then that..... :) ).

Since my balance algorithm ran fast enuff it was basically ALWAYS in a state of oscillation...the key was finding a gain value where the oscillations wouldn't cause it to wobble out of control. I could never get a good enuff software damping factor to work...so I change the surface it balance and and it worked like you saw in the vid.

If I were to do it again I would implement wheel encoders to help detect if it was moving. That way I could set its balance point by itself for ANY surface:

-Take IR reading and use as balance point.
-Read wheel encoders.
-Rotation one way or another would cause the balance point to be shifted one way or the other and the program would start again.

This is over simplified but is basically what you are doing right now...only a little differently. Anyways....its late here...I best be off as my brain no-workie the later it gets.

Keep me posted on your progress...it's an amazing feeling when you see it balance...

Curt

[mka862000]

i am trying to make a mobile inverted pendulum . i am using an accelerometer ADIS16201 and a gyro rate to measure the angle . as accelerometer can measure angle only when the body is not accelerating , while gyro is having drift problems. i have checked many sites on it . it is said they are using either complementary filter or an extended kalman filter . i am not able to uderstand kalman filter at all , i know a bit about how complementary filter works . could you help me understand how do i get the angle from the signals of accelerometer and gyro rate .

thanks
manoj agrawal
final year elec engg
NIT surat
india