May 6th, 2010

I couldn’t wait to blog this one, so sleep will wait a little longer.

I recalculated the gains using a less aggressive setting, and came up with coefficients that are about an order of magnitude smaller.  In the simulation, things move a little slower but everything runs very smoothly.  The transition between swingup and a stable inverted pendulum looks a lot smoother also.  I also fixed the issues in the control algorithm from yesterday.

I tried out the new stuff on the real hardware.  First I tried moving from one position to another while hanging.  It moves less smoothly than the simulation (kind of jerky), but it gets there and keeps the pendulum from swinging.  Then I tried inverting the pendulum… (drum roll, please) and it worked great!  The swingup didn’t quite get it all the way up, so I had to tweak the algorithm a little bit.  Once it was inverted, it did a really good job of keeping it inverted.  I can tell it to move to different positions, and it keeps it inverted while moving to those positions.  I also tried tapping the pendulum lightly with my finger, and it recovered nicely.  It is a little slow and kind of jerky, but it is still a success and a great second try.

The cart tends to oscillate while balancing the pendulum.  It isn’t very large, and I guess it is to be expected.  Every now and then, the cart stops completely and the pendulum stays balanced for a second or two, then it starts to fall and the cart zigs out to keep it upright.  When the set screw is tight, the cart oscillates less.

One of my big problems right now is the set screw.  I haven’t done anything about it yet, so it keeps coming lose after running for about a minute.  Right now I just tighten it back up and restart the system.  I really need to decide how to keep it in place and do it.  If I don’t, I am going to shred all the pieces of shim foil that I have.  I would feel silly if I had to go ask for more foil again.

I also want to work on the gains.  I plan on gradually increasing the gains (and system speed) until I reach the limits of the system.  I am just happy I have something that works at the moment.

First inversion try

May 5th, 2010

I worked a little more on the model, and decided it is probably close enough.  I got tired of waiting and decided to just try the current algorithm on the actual pendulum.

I added the control code to the existing pendulum interface, which wasn’t too difficult to do.  I started running the program and immediately discovered a problem.  The gains I had selected, which worked fine on the ideal model, were way too high for the real system.  The noise in the signals made the cart chatter while just trying to maintain a hanging position.  Moving to a new hanging position made the cart go crazy.  For a quick solution, I reduced the gains to about 1/4 their original value, and it seemed okay.  The chatter went away, but the pendulum wasn’t really staying still.  I could move to different positions without too many problems.

After getting the hanging controls in reasonable shape, I decided to try the swingup and had more problems.  It seems like nothing works as easily on a real system as it does in simulation, not that I am surprised.  In my swingup logic, I was using the angular position of the pendulum to make some decisions on control.  In the simulation, looking at the sign of the angle worked great.  The sign was always either +1 or -1.  However, on the real system the encoder makes it possible to have an angle of exactly zero, which gives a sign of zero.  My swingup kept moving in one direction and never reversed directions.  That just doesn’t work if you want to swing up the pendulum.  I did a quick fix that started the pendulum swinging, but the quick fix only worked until the pendulum was halfway up.  I will have to do a more permanent fix to handle the zero angle situation.

It was nice to see the pendulum doing something other than a sinusoid, even though I didn’t have a lot of success on my first try.

Simulation works well

May 3rd, 2010

I used the cart and pendulum models to update a pendulum simulation program I developed long before I started building the pendulum.  I changed the equations to use PWM instead of force, and modified the control algorithms to match.

The simulation works pretty well.  I can swing up the pendulum pretty quickly and maintain the inverted pendulum.  I am not going to share any of my algorithms at this point since I plan on running a competition to design the best algorithm.  Wouldn’t want to make it too easy, would I?

I will share that I started with PID algorithms to maintain the inverted pendulum, but there was a lot of wobble.  The pendulum would sway back and forth several times before settling into the correct position.  I switched to state space control, and it works much better.  The pendulum immediately moves to the right place with no sway or wobble.  It is the control method I would recommend.  I am still learning how to optimize the method, though.

Now I just need to verify my models by collecting some more data from the actual system, then I will try my pendulum inversion algorithm on the actual system.

Cart model

April 27th, 2010

I finally figured out the cart model.  I had to take a different approach that took a while to figure out.

I used the fact that the back emf of a motor is proportional to the speed of rotation, and the torque plus back emf are equal to the PWM voltage (with a few constants mixed in).  Since the force is proportional to the torque (related by the diameter of the gear), I was able to write the following equation:

ddx = C PWM – D dx – E (dT*dT sinT – ddT cosT)

C and D are constants related to the force (torque).  D includes the back emf and the friction term.  E is the constant that defines the interaction between pendulum motion and cart motion.

After smoothing data and using a least squares fit, I came up with the values C=0.017, D=40.49, and E=0.02915.  When looking at the best fit curve, it matches pretty well except at the points where the speed crosses zero.  At those points, the speed lags briefly before catching up and there is a mismatch.  Looking back at the data that correlates speed to PWM value, I decided to linearize the PWM requested by the user so that the steady state speed is always a fixed multiple of the requested PWM value.  To do this, I fit separate lines to the positive and negative portions of the speed vs PWM data.  The final result was to increase the PWM magnitude of negative values by 41.  For positive values, the magnitude is multiplied by 1.025 then increased by 34.  Previously, the magnitude was just increased by 27 with no scaling.  These new values are expected to eliminate the gap when the PWM is near zero.  I still need to do further testing to verify this.  After I verify the PWM scaling works well, I will collect several sets of data and verify the values for my models of the pendulum and the cart.  I know they are very close now, but I would like them to be even better.  I want the most accurate model possible for designing control algorithms without using the hardware.

Pendulum model

April 26th, 2010

I am still having trouble figuring out how to model the cart.  I have one equation that relates the PWM output to the torque, which can easily be converted to force.  I have a second equation that relates force to the motion of the cart.  If I knew all the coefficients in the equations, it would be pretty easy, but most of the coefficients are unknown at this point.  Another problem is that the two equations are in different forms (Laplace and differential), so I can’t just set them equal to each other.

I decided to look at the pendulum side of the model.  I added a little code to the sine program to record data and oscillated the cart at 1600 msec/cycle, which appears to be close to the natural frequency of the pendulum.  The pendulum alternated between large and small oscillations several times.

From the recorded data, I have cart position (x), cart speed (dx), pendulum position (T), and pendulum speed (dT).  My first step was to heavily filter the data to eliminate noise, then calculate the accelerations of both (ddx, ddT).  I also converted the units from counts to meters and radians.

The equilibrium equation for the pendulum is:  ddT = 1/(I+L^2m) [Lm(ddx cosT – g sinT) – c dT]

Since I don’t care about the individual constants, I simplified it to:  ddT = A (ddx cosT – g sinT) + B dT]

Using the collected data, I rearranged it to get a curve for (ddx cosT – g sinT), then used linear regression to get the best fit for the constants A and B.  It gives me values of A=1.9217 and B=-0.024.

The fit worked really well and the best fit curve almost exactly matches the ddT curve.  I was going to post a plot comparing the fit data to actual data, but they were so close that you can’t see the difference.  This makes me pretty confident in this part of the model.  It should be plenty close to the actual system for testing algorithms.  Now I just need to figure out the cart model.

Replaced shim

April 25th, 2010

I picked up some more shim foil from Shaltz and cut a strip to fit the gear.  It was much easier the second time around – I just rolled up the foil, inserted it into the hole in the gear, then slid it onto the shaft of the motor and tightened the set screw.  The system works fine with the new shim.

I did discover why the first shim failed, because it started happening again.  After attaching the pendulum and doing a simple sine motion for a while, I noticed some spikes in the PID output at zero speed points.  I thought they were caused by the pendulum swinging, because I saw them shortly before the shim self destructed the other day.  To be sure, I removed the pendulum but they stayed there.  Pretty soon I realized the set screw was loose, even though I had it nice and tight about ten minutes earlier.  It came loose a few more times while I was running the pendulum, so I need a more permanent solution.  I am thinking either superglue or lock-tite.  I suspect superglue might be a little more permanent than I like.

The good new is that the motion of the pendulum does not appear to affect the motion of the cart.  As far as I could tell, no matter how much the pendulum was swinging, the cart tracked a sine wave very well.  I tried both position and speed control, and both worked well.  The feedforward portion of the control does most of the work, and the PID feedback provides the corrections to keep it on track.  I did notice more PID output while the pendulum was swinging, so I will probably need to figure out how to model it to have an accurate model of the entire system.

PID Cart Control Works

April 21st, 2010

After a bit more experimenting, I ended up eliminating current as a method for controlling the cart.  I couldn’t see any simple relationship between the current and the motion of the cart.  There was so much noise that I couldn’t get as tight of control of speed as I would have liked.  There was also the fact that current measurements were very different depending on the direction of travel.

My current version uses a PID algorithm on the RT side of the cRIO.  The input of the PID is either position or speed, and the output of the PID is the PWM value.  I also added a feed forward algorithm that predicts what the PWM value should be since the relationship between PWM and speed is highly linear.  With the two algorithms combined, the cart can track any desired speed or position almost perfectly.  There is still an issue with the speed oscillation, but that is much smaller when the cart is engaged on the rack.

I set up the test program to generate a sine, triangle, or square (step) setpoint cycling once per second.  The program can control either position or speed.  After trying all the combinations, I am pretty satisfied with this method of control.  If I only had a cart to control, I would probably be done.

Now I need to figure out how the swinging of the pendulum affects the motion of the cart.  When I was originally going to use a force input, I was going to use the standard equations of motion that you find derived in practically every paper about inverted pendulums.  Now that I am using a PWM output to control either speed or position, those equations don’t exactly work.  I can’t measure the force applied – I only see the resulting motion.

One possibility is that the motor is strong enough to control the position of the cart without the pendulum motion affecting it.  If this is true, I will just use PID to control the cart, and the pendulum motion will only depend on the cart acceleration.  I assume this is how systems that use a stepper motor work – the stepper motor moves at whatever speed you provide pulses, and just provides enough force to achieve that speed.

The other possibility is that the pendulum motion will overpower the motor in certain situations.  I suspect this is the case.  I will have to investigate it.

I started looking at the interaction between the pendulum and the cart, but I ended up shredding the brass shim foil that is wrapped around the shaft of the motor to hold the gear in place.  I suspect too much high speed acceleration wore out the foil.  I set a limit on the acceleration, but I think it needs to be a little lower.  I will need to stop by Shaltz to pick up some more foil before I can run the system again.

Step measurements

March 20th, 2010

I propped up the cart so it wouldn’t move and ran it at a variety of steady state PWM rates.  I collected the data and plotted the average current and speed versus PWM rate.  I plotted clockwise motion in white and counterclockwise motion in red.

Speed versus PWM cycle

Speed versus PWM cycle

The speed appears to be very linear versus the PWM cycle.  At low PWM values under 50, the motor does not move.  At 50, it jumps a little bit then is very linear from that point on.  For a given PWM cycle, the CCW speed is about 2% larger than the CW speed.  This explains the slight drift to the left when cycling the PWM sinusoidally.

Current versus PWM cycle

Current versus PWM cycle

The current ramps up somewhat linearly while the motor is not turning.  Once the motor starts turning, the current drops a little bit then increases very slowly.  This indicates the motor is overcoming friction and other forces to maintain a steady speed.  The interesting thing is that the CCW current is significantly larger than the CW current, by about 20%.  This explains the rapid drift to the right when cycling the current sinusoidally.

This causes problems when trying to control the cart using PID.  If I try to control the current, I need to somehow balance the left and right directions of travel.  Perhaps it could be accounted for by the controlling program, which would just boost the current in one direction.  I would also have to figure out the relationship while the cart is moving so that speed and acceleration are accounted for.

Another option would be controlling the PWM cycle directly.  The speed is almost perfectly linear to the PWM value.  Adding a factor of 2% to correct for direction would be easy.  The cart is so light relative to the amount of torque in the motor that it can accelerate almost instantly to the steady state speed that goes with the PWM.  I could limit the rate of change of the PWM cycle to prevent acceleration values that exceed the safe values.

I think I need to do further tests to figure this all out.  This was a good start, though.