Understanding Force vs Speed for Arduino-Based Inverted Pendulum on Cart

[PickyBiker]

TL;DR Summary

I have built a system for balancing an inverted pendulum on a cart. It has a 1 meter rail with a moving cart driven by a stepper motor with a pendulum hinged on the cart. It uses optical encoders to determine the pendulum angle and the cart position. To start, the pendulum is manually inverted. Computer balancing does not begin until the pendulum is almost vertical. (at this point it doesn’t balance well at all)

I am using the Stanford “Dynamics: Inverted pendulum on a cart” document, https://web.stanford.edu/class/me161/documents/InvertedPendulumOnCartSolution.pdf, as the basis for the Arduino c code.

I need help with the term Fc (Feedback force on the cart A) because the motor I’m using is a stepper. A stepper has a a largely fixed force and a variable speed. I need to change “something” in the formulas so Fc is actually the desired speed of the cart not the force on it and I don’t know how to do that.

The attached help.xlsx file has the parameters defined in the Stanford document shown with the particular values for my implementation. For calculated values the C code I use is listed. It also has the reference drawing for the system.

There will no doubt be other questions, but I have been stuck on this force vs speed problem for a while. Can someone help me to understand what needs to change?

 

[hutchphd]

You wish to balance only a vertical pendulum?
Can you quote particular equations for F_c in the paper (like F in equation (45) etc)

 

[PickyBiker]

Yes I wish to balance an inverted pendulum by moving the cart it is hinged to.
At the top of page 81 the equation reads:
11.11 Newton’s law of motion for particle A is FA = mA ∗ NaA, where: FA is the resultant of all forces on A; mA is the mass of A; and NaA is the acceleration of A in N. Substituting into Newton’s law produces(Fc−Rx)nx+(N−mAg−Ry)ny=mA ̈xnx

It is interesting that I do not see where Fc is specifically calculated before it is used in an equation. ?

 

[hutchphd]

Fc is the force pushing the cart (via its wheels).
But you are pushing the cart with a stepper motor? (This would mean controlling the cart position not its speed directly)

 

[PickyBiker]

I think a picture will help here. In some systems the motor drives wheels to move the cart. In this system, the motor drives the cart directly on the rail. This is an older pic with a DC motor. It has been changed to a stepper for more precise control.

The optical encoder on the left end monitors the position and the optical encoder on the pendulum determines the angle.

As I think about what you are saying in your last post, I think what you are saying is, instead of trying to determine the force on the cart or the speed of the cart, I should be looking at the position of the cart.

If that is the case, the position of the cart is measured in meters from the center of the rail and can be positive or negative. I don't think I can simply substitute a distance for Fc. Something else in the formulas must be changed.

 

[hutchphd]

Absolutely it is not the same. Force on the cart and position of the cart are related by Newton's equations and there is also the force from the arm on the cart. The control equations will be different in more or less complicated ways. This is a very good project but one that will require you to learn some control theory. If you wish to attack this be prepared to derive actual control equations and you will get criticism and guidance here.

 

[PickyBiker]

I'm speculating here. If I chose to revert to the DC motor instead of the Stepper Then FC would be force on the cart and through testing and measuring, I could make a map of the motor's applied force at different PWM levels. I'm guessing that would allow me to work with the formulas as given in the Stanford document.

 

[hutchphd]

Steppers are very different animals. They will provide step control until a max torque is reached and then they don't. Better you learn to do the balance by actually using the position control of the stepper. I like a good kluge as well as the next guy but this is not a good kluge...in my estimation.

 

[PickyBiker]

Okay, Stepper it is and the position of the cart will be used instead of force. Now that is settled, I have done a ton of work already so I would guess the next step might be to show what I have done and ask for validation/improvement. In a subsequent post, I will show the major variables and how I calculated them. I think I got most of them right, but I would love some validation. I will start with items regarding the rotation matrix.

 

[pbuk]

Wow, that's a challenging task! Looking at the set up you have clearly put some effort into the hardware; we can help you with the maths but I'm afraid a perfect set of mathematical equations is only a (small) part of robotic engineering, the big challenges are in the hardware and in sensing.

In the maths we make assumptions that the hardware is perfect - for instance that bearings are frictionless, rods are perfectly rigid, the stepper motor can provide and the drive belt can deliver infinite torque etc. And we also make assumptions that measurements are perfect and continuous whereas in this set up I think the angular resolution of the optical sensor on the pendulum is going to be a huge problem, and also the linear resolution of the stepper motor. There are also a number of things you are not measuring that would help - think about doing this using your hand, the direction and magnitude of the force exerted by the tip of the rod in your hand is a huge part of achieving balance. We don't make all these computations in our head, all we do is if the rod pushes to the right we move our hand to the left. How far and how fast we do this is a matter of practice.

You could do the same with your set up - rather than try to compute where to move the trolley (with all the errors introduced by the assumptions mentioned above), just move it and see what happens! Vary the amount of movement and the slew rate to build up experience of how the system performs - or better still, create a Machine Learning algorithm to do it - ultimately I suspect this is your biggest chance of success (I'm not sure what microcontroller you are using, I'd go for something like the Adafruit Feather M4 Express to give the maximum amount of computing and memory grunt).

Oh finally, don't rule out the idea of a PWM controlled motor, it may work better - and also consider if you could measure the force on the pendulum pivot, this could probably be measured with greater precision than the angle of the pendulum (although precision and accuracy are not the same thing as I am sure you know!)

Good luck - achieving this would be a huge accomplishment!

 

[PickyBiker]

Wow, thanks for the advice and the encouragement.
I am using an Arduino UNO for this system and I have tried both a PWM controlled DC motor, another couple of DC motors with gear reduction and the current Stepper motor. So far, the Stepper motor version comes closest to actually balancing the pendulum. I can easily determine exactly where the cart is by counting steps and/or using the optical encoder that encoder has 500 pulses per revolution.

I have determined the inertial moment of the pendulum based on it's measured weight, the center of mass (cm) and it's length from the pivot point to the cm.

Not sure why the pendulum optical encoder would be a problem. It has a resolution of 2000 pulses per revolution or about 5.5 pulses per degree of rotation. That plus a little smoothing makes for a nice smooth waveform on the Arduino serial plotter.

I think the main problem I am having is that so far I have been focusing on the pendulum's angle, the cg velocity and the cg acceleration to try to balance it. I have not yet taken into account the position, velocity or acceleration of the cart. Now I'll work on integrating the cart's position into the balancing algorithm. Today I would like to post some of my calculations to see if I interpreted the formulas correctly.

 

[berkeman]

Okay, Stepper it is

Sorry if you already mentioned this, but is this stepper motor a standard stepper or a microstepper motor? How many steps per revolution does it have?

If you are trying to use a standard stepper motor for this, I think you will find that the coarse step resolution is a fundamental problem for the feedback equations you will be deriving. Consider switching to a microstepper motor if you can. Have fun!

 

[PickyBiker]

This is a 1.8 degree nema 17 stepper motor with microsteps set at 16. There are 16 x 200 = 3200 steps per rev. I think that will be smooth enough with a 38.5 mm diameter pulley. That works out to 8.27 revs/meter.

 

[anorlunda]

This is not an answer to the OP question, but I recall that the inverted pendulum was the most spectacular success for fuzzy logic. A quick search found lot of hits for "fuzzy logic" "inverted pendulum" including these.

https://github.com/Dhawgupta/Fuzzy-Control-Inverted-Pendulum

https://forum.arduino.cc/index.php?topic=124827.15

I know you put a lot of work in already, but still fuzzy logic on arduino may be an appealing solution.

 

[PickyBiker]

I am intrigued by the Fuzzy logic idea. I'll look into that a little before continuing.

 

[pbuk]

I am using an Arduino UNO for this system

Arduino Uno 16 MHz software floating point USD 20, Feather M4 120 MHz hardware FP USD 23 (I'm guessing you are in the US from your picture!)

...that encoder has 500 pulses per revolution.

(just hold that point for a moment)

I have determined the inertial moment of the pendulum based on it's measured weight, the center of mass (cm) and it's length from the pivot point to the cm.

Not sure why the pendulum optical encoder would be a problem. It has a resolution of 2000 pulses per revolution or about 5.5 pulses per degree of rotation.

[EDIT - corrected to match provided position of CoM] So with a CoM at 0.37 m that's $\frac{2 \pi \times 0.37}{2,000} \approx 1.16 \times 10^{-3}$ m i.e. about 1.2 mm resolution for the CoM, or 2.3 mm for the tip of the rod. Hmmm, may be OK but may not - and if you miss a pulse it is going to go very wrong.

Now coming back to those 500 pulses per rev for the linear scale and 2000 pulses per rev for the pendulum, how are you driving these? If it's polling then is your timing loop fast enough not to miss any edges (you mention 50 fps somewhere else, that doesn't sound fast enough to me)? If it's inturrupts then no matter how short your handlers are you may have a problem with collisions between the two rotary sensors - if you find that you are missing edges then try running one of them on an inturrupt and the other in the loop (and use a faster processor - see the first point).

I have not yet taken into account the position, velocity or acceleration of the cart.

Acceleration is going to be a problem, because it changes over time: the rate of change of acceleration is called jerk and an ideal (i.e. theoretical) stepper moter has infinite jerk. Of course in practice this will not be the case but it will depend on the maximum torque of the stepper moter, any stretch or slack in the drive belt (which will vary over the length of the track), wether the step is starting from static or a reversal etc.

Even if you could measure all of these and allow for them in your computations, you still have the problem that these rates of change are continuous whereas you are computing them in discrete steps - there is no exact solution.

So although I'm not a big fan of the term "Fuzzy Logic" I'm glad you are looking into it.

 

[pbuk]

but still fuzzy logic on arduino may be an appealing solution.

Congratulations on finding a more appealing buzzword

 

[PickyBiker]

Good points on the optical encoders. Both are interrupt driven as is the stepper. When using the stepper however, the 500 PPS encoder is not necessary because the step count is trivial to track. The ISR's are devoid of any floating point math and those routines are extremely brief with only what is absolutely necessary to determine a direction and inc/dec a counter. I have been working on the software and hardware for several months now and If it would be helpful, I could post the sketches as they now stand.

 

[PickyBiker]

Well after a good bit of testing and filtering, the angle from the optical encoder is very smooth, but as predicted above, the acceleration is quite jerky I haven't found a way to smooth that out. I would expect to see a rise as it accelerates and fall back to zero as as it levels off. Unfortunately each 20 ms loop produces what resembles a sine wave. I even increased the loop speed to 200 HZ (5ms) and it still is quite erratic.

Plan B for this is to switch out the encoder for an accelerometer. The most common of these the the MPU6050 but that can be quite noisy. The Adafruit BNO055 unit has a fusion mode to integrate the angle and acceleration and is supposed to be less noisy. It is $35 + shipping. Of course I am open to suggestions for other high quality IMU's that can easily be connected to an Arduino UNO and is in a reasonable price range. For me a reasonable price would be something up to about $100.

BTW: I am experimenting with the Arduino eFLL fuzzy logic library and reading up on fuzzy logic in general.

 

[pbuk]

That Adafruit board is a great piece of kit (and does a lot of heavy lifting with its own ARM Cortex M0 to take the strain off your poor little ATmega328P ), but at 100Hz measurement rate I think it is still going to struggle with the rapid change in acceleration of a stepper motor. And even if it could, what would you do with that information? All you can do is move the truck left or right and the angle of the pendulum tells you which way to go; the difficult bit is tuning the feedback and damping to suit the imperfections of the system.

But that board looks like a lot of fun, I'd buy it anyway and maybe stick it on the end of the pendulum.

 

[PickyBiker]

Most of what I see regarding fuzzy controlled inverted pendulums include modeling with MATLAB / simulink. Obviously as a retured hobbyist, I'm not going to be able to acquire those tools. So the question is, are there any less expensive or free tools for modeling this type of project?

 

[berkeman]

BTW, I don't know if it's been mentioned already, but one of the driven modes of a stepper motor is "hold". You could cheat a bit and just hold the pendulum near the zero degree top...

 

[PickyBiker]

The stepper moves the cart, not the pendulum. In any case, I want a mechanical, electrical, computerized system with software that truly balances the pendulum and I want it on the lowly Arduino UNO. First goal is balancing, second goal is automatic swinging up to the balance position. Ironically, swinging up to the balance position was very easy to do. Balancing and tending to keep near the center is far more challenging.

 

[berkeman]

The stepper moves the cart, not the pendulum.

Whoops, sorry.