Working Vex Pendulum Balance Robot

VEX V5 General Discussion VEX Robot Showcase
#1

I finally have a working inverse pendulum robot (bbot as I call it).
It uses Vex motors , Vex parts and the following non Vex sensors:

5 DOF IMU from Spark (3 axis accelerometer and 2 axis rate gyro) $100

Absolute analog output encoders from US Digital MA3-A-B8. [http://www.usdigital.com/products/ma3 ($35 each) These are neat little magnetic encoders that can be read by a/d inputs rather that fooling with interrupts.

I programmed using MPLAB and also EasyC.

The bbot has a noticeable limit cycle about vertical because of the large nonlinearity in the motors due to friction and slop in the transmission of force between the motor and wheel. Both are significant contributors. The a/d sampling is too coarse for this IMU but I had it around and used it anyway. The LS Bit of the rate gyro represents about 2.5 deg/s and is difficult to integrate without some drift due to sampling errors. However, I blend the integrated pitch rate with fwd/aft accelerometer to get a better measure of vertical.

I used MATLAB control systems tool box to design the feedback gains using linear quadratic regulator optimization (LQR) in the discrete domain. They were pretty close to the final settings I used. The feedback command u=k1angle_error +k2angle_rate + k3encoder_rate_symmetric + k4encoder_pos.
Seems to work ok with k4=0. There is not a stable solution if k3=0. So those who try to use just a PD controller on angle will have some trouble if encoder rate is not included.

The angle_error and angle_rate are a blend of accelerometer derived tilt and rate gyro output combined in a complementary filter. The accelerometer is lagged with a time constant =1/k_filter and then blended with gyro_rate to eliminate the lags in the short term and retain accelerometer angle in the long term. In pseudo code it looks something like this:

angle_rate= (ax-angle_error)*k_filter + gyro_rate ;
angle_error=angle_error+ angle_rate *dt ;

Note the correction term to the gyro_rate based on the difference between the tilt angle derived from acceleration “ax” and the angle_error used by the system. This effectively converts gyro_rate drift into an angle_error offset rather than a increasing ramp angle_error. For example , if the gyro_rate had a bias of .1deg/sec without the filter blending, the expected error would be 1 deg in 10 seconds. With the filter, the error would only be .1 deg in 10 seconds assuming k_filter is 1. The second line is just the integration of the angle_rate with an update time of dt (=18.5ms)

On the to do list is doing the optimization with integral feedback (simulating a PID controller) and adding the remote control inputs to the software.

Please feel free to contact me for further information. I will eventually post video on Youtube.

I am doing a summer workshop on control theory of a pendulum robot for Robodox team of Granada Hills in LA if anybody wants to participate.

Enjoy,
Chris S.
vamfun@yahoo.com
Retired Lockheed Control System Engineer](http://www.usdigital.com/products/ma3 ($35 each) These are neat little magnetic encoders that can be read by a/d inputs rather that fooling with interrupts. )
vex_bbot_front_forum.JPG
VexBbot_back_forum.JPG

#2

Very cool. I’d love to see a video of that thing.

#3

Absolute analog output encoders from US Digital MA3-A-B8. http://www.usdigital.com/products/ma3 ($35 each) These are neat little magnetic encoders that can be read by a/d inputs rather that fooling with interrupts.

I programmed using MPLAB and also EasyC.

The bbot has a noticeable limit cycle about vertical because of the large nonlinearity in the motors due to friction. The a/d sampling is too coarse for this IMU but I had it around and used it anyway. The LS Bit of the rate gyro represents about 2.5 deg/s and is difficult to integrate without some drift due to sampling errors. However, I blend the integrated pitch rate with fwd/aft accelerometer to get a better measure of vertical.

Please feel free to contact me for further information. I will eventually post video on Youtube.

I am doing a summer workshop on control theory of a pendulum robot for Robodox team of Granada Hills in LA if anybody wants to participate.

Enjoy,
Chris S.
[EMAIL=“vamfun@yahoo.com”]vamfun@yahoo.com
Retired Lockheed Control System Engineer

WOW!! When is the Video comming out!!!

I would encourage you to think, about doing an Article for Robot Magazine or Nuts and Volts.

Have you found Back Lash in the Gears of the Vex Drive System to be a contributer, or is it the Friction in the Motors that is the Major cause of the limit cycle about vertical? This issue has been raised before…

Another “Lockheed Engineer”!!! Awsome!!! And a “Lockheed Control System Engineer” at that… What do you think of the Vex System in General???

Also, the link for:
5 DOF IMU from Spark (3 axis accelerometer and 2 axis rate gyro) $100
[http://www.sparkfun.com/commerce/product_info.php?products_id=741

Works better with the “park” removed from the end. You only have 24 Hours after posting to re-edit your messages…](http://www.sparkfun.com/commerce/product_info.php?products_id=741 )

#4

wow, that looks incredible:eek::eek: i would love to see a video. now you just have to make it work with vex sensors:p

#5

thanks, see my edit of original post. Nuts and Volts has done a balance bot with the Stamps processor and using the same IMU. I have not read the article but have come across web references to it.

I have tried to tighten up the linkages by inserting paper shims where the axle joins the wheels and motors. It helped a little but still probably 5 -10 degs of slop. My MATLAB model has a friction term that attempts to model Coulomb friction but I only have two free body elements (wheels and body) so it is difficult to model the slop. I don’t seem to get the limit cycle behavior unless I crank the model gains up by 150%. Eventually, I will add the axle as a free body and I’ll be able to estimate the relative effects.

As far as Vex system is concerned I’m fairly new to it but its pretty cool.
So far I’d like to see improvments in a few areas.
First…get rid of those encoders. It is hard to imagine selling a product that cannot get direction when it is so easy to do!@##$$. They are sloppy and much larger than they need to be.
Second…the documentation on the timing of the Vex EasyC is sure sparce and at least some explanation of how the EasyC master code works relative to the MPLAB software would help. Ie where are the routines called from relative to the interupt timing loops and how are the interrupts that are accessable to EasyC integrated into the processor software.
Third:I had to buy a $35 crimp kit just to add a few wires to the processor input. I’d like to see a few wired pins included with the kit so you can easily add your own sensors.
Forth: Include data sheets on the motors and servos… I think I have the right stuff from your forum but not sure.
Fifth: lets get most of this stuff made out of aluminum. My bbot weights a ton.
Sixth:It would not be hard to tighten up the tolerances on the axles by providing metal hubs or at least provide a set screw collar attached to the wheels and motors which can be tighten to eliminate slop. I was thinking of epoxying the set screw collars included with the kit to the wheels and motors but even then it would be easy to score the axle if high loads were experienced.
Well, TTFN

#6

The Link works correctly now…

Here is a link to the thread ** Vegway, Balencing Vex Robot** that was discussed previously on this forum.

What will “add the axle as a free body” do for the linkages???

I am older than most here :slight_smile: But I don’t know all the Terminology of Control System Engineers… I would believe that others don’t either. So please educate us :slight_smile:

#7

Well , Classical Control Theory involved adjusting feedback gains and creating compensators using frequency domain (Bode , Nichols, Nyquist) or root locus techniques. Now days with the advent of computers, Modern Control Theory emerged which uses optimization of cost functions to determine gains assuming full state feedback. Instead of adjusting the gains directly, we adjust the weighting factors of the state variables and the control input in the cost function. This is an iterative process. We pick a cost function, look at the response and if it isn’t fast enough, we increase the weighting on the state variables. This then uses more control input but the system error converges faster. On the reverse side, if our control inputs tend to saturate because of high gains, we weight them higher in the cost function relative to the state varables. Eventually, a balance is reached and we go with those gains.
Generally, all states are not measured in the actual system due to limited sensors so we create observers that generate the missing states based on error signals from the states that we do measure.
When noise is present on the signals we use stochastic control techniques which minimize the error variances. This gets into estimation theory and one of the more common optimal estimators is a KALMAN filter which assumes the noise is a random variable with normal distribution.

Rather than try to give a controls course here, try looking up the following on wikipedia or look for tutorials using the following key words.

Optimal control theory
Linear Quadratic Regulator
Kalman filter
Estimation Theory

Although the theory is upper division college level, a high school kid can use MATLAB with a little calculus under his/her belt to easily design control gains. A good MATlAB controls tutorial : http://www.engin.umich.edu/group/ctm/examples/pend/invpen.html

MATLAB control tutorial

#8

third.you dont need wire pins cause though this can come loose its cheaper to just solder normal wire to breadboard wire u get at radio shack and connect the 2-3 wires to a vex extender cable http://www.radioshack.com/product/index.jsp?productId=2103801&cp=2032058.2032230.2032265&parentPage=family
fourth. theres information on the vexlabs site if you click on the motor kit http://www.vexlabs.com/vex-robotics-motor-kit.shtml
fifth. there are already aluminum vex parts sold separately http://www.vexlabs.com/vex-robotics-all-products.shtml (7th one down)

#9

i think i know wat u mean
u want the lock to be inside the wheels center so it wont come loose faster i like it:D

#10

Hmmm…I’m well aware of these items and of course have used all of them at some time. My beef is with the price that they charge these kids for extender cables. To interface my sensors , I needed 7 male servo connectors. A 4 pack kit extender with male and female ends costs $20 so we have $40 total cost to get 7 male ends. (One might be cleaver and cut them in half and insert wires into the female ends) The Hansen servo wire hobby kit http://www.hansenhobbies.com/products/connectors/connectorkits/ck_sck/
which has enough for 10 male and 10 female servo connectors including wire and crimp tool for $35 seemed a much better deal but requires a little more work. Since the 5v and grounds were common to several signal leads, I saved on some pins as well.

#11

Chris,
I was pretty amazed at seeing it this week in action. Just needs less wobble, but thats because the Vex parts are not highly tuned. Oh, and I found the answer to the homework, just from research, I dont have time to derive it until the weekend.

See you monday,
Eric

P.S. Its really cool to see, but it tends to fall over every once in a while as the shafts and motor have a lot of “give” for what this robot does. Its cool none the less.

#12

can u post a video of your bot plz just a plain digital camera recording is good enough to see how it works

#13

Ok, I finally got this on youtube:

I will post another showing the stability with and without encoder feedbacks.

http://www.youtube.com/watch?v=2UqIXdxdQBY

#14

I will post another showing the stability with and without encoder feedbacks.

Verrt Cool!!! (and Chase-Manhattan Bank is running the same Chase Freedom ads in your area as in mine.)

Are the Wheels at the Top of the Pendulum from the Vexplorer Kit??

Also a related Video on YouTube is the Inverted Pendulum

#15

I will post another showing the stability with and without encoder feedbacks.

http://www.youtube.com/watch?v=4loT_Xfhvbk

These are the same Video…

#16

Thanks Mark,
See edit. Those top tire bumpers are off an old rc car. They are soft enough to absorb the shock. Sorry about the Chase add on the TV in background. First time using a friends digital camera and it sure picks up everything:)

#17

Very nice.
I studied this stuff back in college, but have not actually had to use that part of my education. So I am curious about how you stabilized the robot. Did you make some measurements of its dynamics to apply to a model? If so, I’d love to see what measurements you made, how you made them, and how you used them to tune the control loop. Or perhaps you just made some educated guesses as to the dynamics and then tuned it by hand?
Perhaps you could post the code?

#18

Ok, a few have asked for the Vex Pendulum Balance Bbot code so you can find it in the Vex Code subforum or use this link:
https://vexforum.com/local_links.php?action=jump&id=53&catid=26

#19

Hi Itk,
The control laws are touched upon in earlier posts to this thread eg #1,#7. I plan to eventually upload the analysis program that we used with MATLAB . The student version of MATLAB costs about $100 but everything can be done with a free program called OCTAVE. OCTAVE doesn’t have a great GUI so I prefer to use MATLAB. The analysis program has the input parameter calculations, state space matrix equations, optimal feedback gain computations and a nonlinear simulation to allow tweaking of theoretical gains before using them on the target robot. The gains we derived in OCTAVE were close to what we finally used for the video. As a teaser to the start of the analysis I have enclosed a free body diagram to define the notation.

As you might expect , we just need a few mass properties: the weights and cg locations of the body and wheels plus the principle body moments about the cg’s. These were initially computed based upon uniform mass assumptions and dimensions but after the robot was built, we measured the moment of inertia of the body indirectly by determining the period of oscillation about its wheel axis. Once this is known, it is not to hard to use the parallel axis theorem and the measured cg locations to translate the moment to the cg. The details of this are included in the analysis program.

The wheel moment of inertia was just approximated by assuming a uniform disk with the measured wheel weight.

We also simulated the sensors in detail, even including the a/d quantization effects plus some simple models of friction/dz effects found in the motors.

The rotational axis is not modeled, so the gains for heading and heading rate were derived by trial and error on the robot.
PendProblem.zip (5.56 KB)

#20

Hi all,
Ray and I are having an email dialog re his vex balance bot that is similar to mine. He is an electrical engineer coming up to speed in robotics and is going to try to get my code running with his balance bot and hopefully improve upon it. We decided to post our discussions in this thread so others can learn from his experience.

Vamfun last reply:
RaAN-13 doesnt need to be enabled. I put my main.c routine calls to avoid this.
You will not be able to stabilize without encoders. The gains I spoke of relate to encoders only so wont see a difference until you implement the encoders. You should at least see a short term oscillation as the bot falls without the encoders that I put on youtube.

I am going to use a servo current sensor to try to eliminate the need for encoders. If you drive current instead of speed then bot will stabilize with just tilt_angle and tilt_angle_rate. I may use a high side Maxor current sense amp or possibly a hall effect sensor. This will be read by the a/d and close a current feedback loop around servo controller or I might even modify a vex servo and feed the current amp output voltage to the vex controller in place of the feedback potentiometer. This would provide a hardware feedback loop with less phase lag but would limit programming flexibility. I think this may deserve a separate thread eventually.

----- Original Message ----
From: "radem2@comcast.net" radem2@comcast.net
To: Quality Man vamfun@yahoo.com
Sent: Tuesday, November 20, 2007 6:11:45 PM
Subject: Re: vex balbot - first run update

Thanks Chris. Got the bbot working with the remote, before seeing your e-mail, but it doesn’t balance at all, only moves in the right direction when tilted. Watch for the short video coming and the pics. I think the bot could do better, even without the encoders, maybe after changing the k_xwd and k_wheel_rate it will perform better. That is the next thing I’ll try tonight, as well as putting the bbot in autonomous mode. VEX guys say that AN-13 needs to be shorted for the autonomous mode to be enabled. Is this needed if I enable it in main.c? The bbot seems to be too slow in responding to the tilt.

I need to play both of your videos again, to see again the performance with and without the encoders.