Inverted Pendulum design question

[TheAnalogKid83]

I am doing the inverted pendulum as a side project and I am basically weighing options on how I want this contraption to work mechanically/physically.

I am kind of doing this design on the fly, and I already have my h-bridge circuitry designed and it works (i put a function generator with variable PWM and drove my Pittman motor with the board i made)

I am either going to use an accelerometer or a potentiometer to measure the "levelness" of my pendulum. I am leaning towards a potentiometer because it makes more sense and seems easier with respect to knowing the starting condition of my pendulum (i'd get direct position information instead of an accelerometer of which I would need a way to gather initial conditions on position since accelerometer would not tell me this).

Basically my potentiometer would feed into an A/D, and the voltage would tell my processor the angular position of the pendulum. My controller algorithm would regulate this angle.

My problem comes in that I need to find the right potentiometer, and I don't have much knowledge on them. I need one that will make it possible for me to attach to the pendulum, so a knob or protrusion for me to clamp the twisty part to the pendulum would be nice. I want a very low torque one so that the friction it takes to spin it will have a minimal impact on the response of the pendulum. I also need one with atleast > 180 degrees and preferably a full 360 degrees of operation. It also needs to be fairly rugged to withstand fast and frequent movements. Also, I really would like it to be linear for the most part and have minimum hysteresis so that I can rely on ohm's law instead of a look up table. I intend to model these details in MATLAB for my system model if they have significant affect on the system.

Does anyone know what common parameters I need to look out for on a potentiometer spec and if the kind of potentiometer I'm looking for even exists? I am hoping this doesn't cost me too much . .

 

[TheAnalogKid83]

no one has any good experience or in depth knowledge with potentiometers?

 

[phlegmy]

hey analogue kid
for my fyp in college (mechanical engineering) i took an ip rig and ripped out the analogue controller and put in a digital contoller instead
like your suggestion the angle was determined by a potentiometer [pot]
the pendulum was mounted on a cart on little ball bearings and a little shaft run back to the pot.
the pot in this rig had about 10% dead zone which was a bit arkward
also the biggest complaint i had about the whole rig was the "stickiness" of the pot
every now and then the pendulum would actually stick in the upright which was a bit pointelss.

long story short if you could use a rotary digital encoder this would solve all probs with deadzones and reduce friction by multiples of n. if i'd had more time for my project i'd have taken that potentiometer smashed it burned it and buried the ashes, and then gone out and gotten a rotary digital encoder

also if your going to use an A/D converted with a pot, you may as well go for an encoder!
hope this was some help

as for cost, i don't know, but they'll be more €€€ than pots i'd imagine! may be worth it tho

 

[trambolin]

Rip off one USB mouse and disconnect one of the axis and plug the other one on the rod that is being inverted. Use its circuit directly for counting the pulses and you will have your wonderful encoder. Don't use potentiometers because they are usually not precise and have a high risk of introducing noise to the signal. Unless you want your controller be nervous and oscillatory as phlegmy pointed out why... I hate those brush stuff in them...

 

[TheAnalogKid83]

Cool, thanks to both of you for the great advice :]

 

[Ulysees]

The mouse is a good idea, the only limitation is the resolution of the encoder. Judging from the motion of the mouse pointer on my screen, it must be insufficient.

If it's just for fun, would you be interested in writing a little program to detect the angle accurately on a PC from a webcam? Driving your circuit through the PC's serial port. If you're using a microcontroller you'd have a serial port built in already.

Such a scheme would be open-ended, ie for other controllable objects too, and for other control schemes. In the future you could experiment with neural control if your control is in software: a robot observing the pendulum for a while, learning its inverse dynamics, and driving it over wide angles with accuracy. You'd be trading the low resolution of the mouse against a little extra delay from the webcam. Software would be fast on today's pc's, so the only delay is probably one or two frames worth of time from the webcam.

 

[trambolin]

Yep, might be possible but, please note that if you crank up the mouse sensitivity setting you can see that it is pretty capable. What you see on your screen is resolution*sensitivity factor. Especially new mouses are very adequate. But one must be aware of the fact that velocity estimation with this setup is ill-posed thus you should only feedback the position information.

Regarding the visual feedback, the bottleneck is the image processing delay. In other words, marker or edge detection algorithm that tells you the new position and velocity of the rod.

 

[Ulysees]

Yep, might be possible but, please note that if you crank up the mouse sensitivity setting you can see that it is pretty capable.

I did that, before the previous post. One movement was a jump of several pixels, that's where I got my conclusion about resolution. Ideally we'd like to know the number of gray codes per revolution, maybe new mice have more (I guess that's why you said "usb mouse").

Regarding the visual feedback, the bottleneck is the image processing delay. In other words, marker or edge detection algorithm that tells you the new position and velocity of the rod.

I worked on a real-time mpeg2 encoder as far back as 2001, on a PC. I am sure that the detection of the pendulum's angle can be very fast on todays PCs, well below the duration of a frame. USB and serial ports are very fast too for this app, so the main delay should be the compression inside the webcam, a frame or two.

 

[TheAnalogKid83]

eh, the image processing technique sounds really cool, and I did take a DIP course, but I think that would be a whole project in itself to track the pendulum, and I really want to concentrate on the control aspects rather than sensing. I have definitely been thinking about making a target and track system with a webcam though. Also, I'm using a coldfire devkit, so I don't know how much the webcam would slow things down. My webcam is on USB. My programming skills are not phenomenal, especially down at the interface level to talk to a webcam . . I prefer MATLAB and vhdl. After I get this project done, I might be able to tackle the webcam idea.

One thing that would concern me with the webcam would be that the pendulum will have a sideways movement to where the perspective of the webcam to the angle of the pendulum would be changing, and that might be a complicated problem depending on if the webcam is stationary or not relative to the pendulum cart.

 

[trambolin]

I have to warn you again, the image processing algorithm gives you approx. 50-60 Hz sampling rate of the position and considerable uncertainty due to the detection procedure. Thus designing a discrete time control (you know z domain, unit disc etc.) might be your only option,

Also you are right about the perspective issue. That causes the center of the area algorithms go crazy and give you other coordinates than your original marker. So, I would say it is not a trivial subject if you want something decent.

By the way, I assume that you don't use any swing up action. You start from the upright position.

 

[TheAnalogKid83]

I'm planning on the discrete z-domain control anyway since I am doing digital control with a cpu. And I didn't realize the sampling rate was so low for the webcam, although that makes complete sense for a visual device. I might be concerned with frequencies much higher than 50-60hz in terms of the system response, even though I'm sure the frequency response of the system is not incredibly high as it is a mechanical system. I would have to figure out how to mathematically incorporate the delay of the webcam into my control algorithm, which might not be too hard . . once its a part of the system model, then the controller will inherently have this compensated for as it is designed off of the transfer function which includes the time delay. If the time delay is variable (dependent on how the webcam functions and interfaces), then it is definitely much less trivial.

I would think that there would be some kind of matrix transformation that could be used to translate the pendulum angle as it moves across a horizontal axis for fast calculations, but you are right it is definitely not easy no matter how it would be done. It might almost be easier to fix the camera to move with the cart so that it just sees the pendulum angle straight on the entire time. Overall I think I would be biting off more than I can chew with the webcam method initially.

I'm not too familiar with the mouse wheel, except that when I use one I can feel discrete clicks, so it would be really easy to read from an interface point of view; however I don't know if it has the resolution I want, and there is definitely some force to overcome to get it to move. I do like this idea still and might try to use it. I haven't looked into rotary encoders in general, but that might be what I'm looking for.

 

[Ulysees]

So it's a pendulum on a cart? I must warn you this is a hard control problem. It is something of a test-bed for new control schemes in literature, chosen because it's simple and yet non-linear, unstable and of limited controllability (=you can't go from any state to any state).

I don't see why perspective is a problem. Can't the orientation of the pendulum be detectable? Eg, if it's a little wide and flat? I'd find it far more fun myself, if it involved a little AI.

By the way, visual studio comes with a sample called "vidcap" that reads any camera and shows the video on the screen.

 

[TheAnalogKid83]

So it's a pendulum on a cart? I must warn you this is a hard control problem. It is something of a test-bed for new control schemes in literature, chosen because it's simple and yet non-linear, unstable and of limited controllability (=you can't go from any state to any state).

I don't see why perspective is a problem. Can't the orientation of the pendulum be detectable? Eg, if it's a little wide and flat? I'd find it far more fun myself, if it involved a little AI.

By the way, visual studio comes with a sample called "vidcap" that reads any camera and shows the video on the screen.

Yes I'm doing the classic control problem, atleast from what I've gathered that its a classic project to do. I just saw some youtube videos of it a few months ago and thought it looked really cool, so I got started on my own. The nonlinear aspect of saturating scares me the most of this project, both in position and velocity, but especially position (where I hit the end of the horizontal rail) so I know the problem has built in limitations on what can be accomplished. I might make my pendulum taller or heavier than normal, so that I have more resolution while moving at smaller distances on the rail (like balancing a baseball bat vs. a pen on the palm of your hand). I don't know if that can work out, but it makes sense when I think about it. That aspect of figuring out the physics and mathematics is going to be the most fun when I'm designing the model.

Also, you're right it would be a lot of fun to determine the angle on a webcam, and that complication of knowing your viewing angle when trying to figure out your pendulum angle could be an interesting problem to solve, but then I would be doing a DIP project before I got to tackle the controls project, and I'm not ready for that quite yet, especially since I'm doing this sort of as a refresher/primer in embedded programming on an embedded uC devkit and have little experience programming in C on anything outside of a PC using windows. The most related programming to this project that I've done has been in assembly language to control the PWM using a few timers and displaying it on a segmented LCD.