Building an Inverted Pendulum System The Ups and Downs of Defying Gravity…

I experimented with a sinusoidal inputs to see how the system responds.  I started with a sinusoidal PWM, going full range in a 2 second cycle.  I discovered that the cart slowly traveled to the left while cycling.  At the time, I assumed it was due to the cable carrier.

My next test was using PID onboard the FPGA to control the current.  I used a sinusoidal current setpoint.  The cart cycled very nicely, but I discovered it traveled to the right while cycling and did it fairly quickly.  After about 10 cycles, it traveled the entire length of the rack.

To investigate further, I propped up the cart so it wouldn’t move while cycling.  I discovered that the travel had nothing to do with the cable carrier and the motor behaved almost exactly the same when it wasn’t moving the cart.  I figured out that the direction of travel is a significant variable that I will need to deal with.  It may end up being a simple proportional thing, where I use a multiplication factor to make both directions equal.

My plan is to collect a good amount of data while cycling the motor at different rates, then building a table that relates acceleration to speed and current.  I haven’t figured out exactly how I am going to do it yet, but I am working on it.  Once I have the table, I am hoping it will enlighten me on how to model the motor and cart.  If all else fails, the table could be used as the model.

I wired up the encoder for the pendulum and ran a few tests.  It was a major pain to solder the wires into the connector.  The connector is so small and light that it slides all over the place while I am trying to heat up the solder cup and insert the wire.  I melted a big section of the plastic connector base while chasing the connector around.  I ended up plugging the connector into the 9411 module to give it more bulk and managed to complete the job.  It is pretty messy, though.  I decided I need to buy a small vise to hold the parts while I am soldering.  This will make it much easier.  I found a few in the $20 range that look pretty good.

Once I wired it up, I tried out a copy of the position and speed measurement routines that I used for the cart.  I quickly found a major bug in the algorithm – I was storing the space measurements as signed values, and when it was changing direction I was averaging large positive and negative numbers, which gives numbers close to zero.  After division, I was getting very large speeds instead of close to zero like I should.  I separated the signs from the magnitudes and everything was good.  I tweaked a few other parts of the algorithm to get very accurate measurements.  I found the pendulum encoder still has a pattern that repeats every four pulses, but it isn’t nearly as bad as the position encoder.  At higher speeds averaging four spaces works very well to give a smooth speed measurement.  At very low speeds, it is better to use single measurement to minimize the delay of the speed measurement.

Once I was satisfied with the measurements for the pendulum, I copied the changes back to the cart routines.  They probably still need a little tweaking since the cart behaves differently than the pendulum, but it should still be an improvement since I eliminated some major bugs.

I added PID control for the current to the program.  I used the standard NI PID routine that comes with the FPGA toolkit.  All I have to do is feed in my PID coefficients, setpoint and control variable and it takes care of the rest.  I just added it to the output of my current measurement routine so it updates the PWM value once per cycle.  I also added a switch so I can change between PWM control and current control.

The initial tests are promising.  I made the setpoint alternate between small positive and negative currents and watched the current values as it cycled.  I managed to come up with PID coefficients that quickly reach the setpoint values without going unstable.  The values were small enough that nothing moved.  There is still a lot of testing to go, but the PID control of current looks pretty good at first glance.

I wired up the encoder to the 9505 module so I can measure position and speed of the cart.  It is a standard quadrature encoder with 1000 pulses per rev.  Looking at the transition edges, we get 4000 edges per rev.

I started with a LabVIEW example to read the position of the encoder.  This works fine and was very easy to set up.  I also want to measure speed, though, and that gets a little more challenging.  I decided to look at instantaneous speed by measuring the space between consecutive edges.  I started with a routine that outputs the max of either the last space measured (space-1) or the current space being measured.  Including the current measurement helps when the system is slowing down.  I ran the motor at low speed and took a look at the space measurements.  I found out that the pulse edges on the encoder I am using are not equally spaced.  The graph below shows alternating long and short spaces.  The long spaces were about twice the length of the short spaces.  This would make the speed measurements very wild and inaccurate.

Speed - One Pulse

My second approach was to always average the last two space measurements.  I averaged space-1 and max (space-2, current) to get a smoothed measurement of the spacing.  This worked pretty well and reduced the variation significantly.  The graph below shows there is still a small variation that repeated every four spaces, though.  I realized that the widths of the on and off portions of the A and B pulses were not perfectly spaced either.  I am guessing the on portion is slightly longer or shorter than the off portion of each signal.

Speed - Two Pulses

My third approach was to average the last four space measurements.  I averaged space-1, space-2, space-3, and max (space-4, current) to get a very nice, clean space measurement.  This removed all the cyclical variation from the measurements and gave me a nice smooth curve, which you can see in the graph below.  My only concern was that at low speeds with deceleration the delay for measuring true speed could be significant.  The measured speed is always a couple of counts behind when averaging four values.  I decided that when the current space measurement exceeds 40,000 (1/1000 of a second), I will only use the last two spaces.  This trades a little variation for quicker response.  I may adjust this cutoff level later.

Speed - Four Pulses

Now that I had a very accurate measurement of the spacing between the pulses, I had to convert it to speed.  I ended up using the new high throughput division available in LabVIEW 2009.  I was able to divide 40,000,000 (total counts per second) by the spacing to get pulses per second.  One nice thing is that the high throughput math works inside a single cycle timed loop.  There is a delay of 29 cycles between inputting the numbers and getting the answer, but that is a very short amount of time when each cycle is 25 ns.  Good enough for me!!!

Now I feel I have very accurate measurements of current, position, and speed.  The next step will be adding PID control of the current.

On a side note, there is no noticeable noise in the encoder signals.  Apparently the combination of shielding and differential encoder inputs is enough to eliminate any noise issues.  This means I can run all the cables in the same track when I get some cable carrier, which will save me a little money.  If there was too much noise, I was considering using two cable carriers in opposite directions – one for the encoders and one for the motor cable.  I need to order the carrier soon, because the cables would get very tangled if the cart moves around much, and I am very close to moving the cart.

I thought my plans for scaling the current and calculating the overall current would work well.  The exact factor of two was appealing – until I ran the motor in the other direction.  In that direction, the factor looked closer to 1.8, which totally confused me.  I was frustrated and decided to take a break for while.  In the meanwhile, I continued discussing my issues measuring current on the NI discussion forum.  Yesterday Eric from NI answered all my questions very clearly (see How is NI-9505 current sense measured? for details).  He explained that there are two resistors used to measure the current.  During the On cycle, the resistor that the current passes through depends on the direction of rotation.  During the Off cycle the current goes through both resistors, which makes the measured current twice the actual current and totally explains why the Off cycle was measuring about twice the On cycle.  The different factor for each direction of rotation is because the two resistors have slightly different values.  Once I realized this, I compared the waveforms and found out that for CW my 9505 module has an Off/On ratio of about 2.05, and for CCW the ratio is about 1.95.  Once these correction factors are applied, the On and Off cycles are almost exactly equal for both directions.  Therefore, my current measurement scheme will be:

• Measure at the center of the Off cycle if the PWM < 30% (to avoid spike effects in small pulse widths) and leave the value as is.
• Measure at the center of the On cycle if the PWM > 30%, and multiply it by the appropriate scaling factor (CW = 2.05, CCW = 1.95) to get it to match the Off cycle.

This will give me an accurate current measurement at any PWM and either direction.  The scaling factor for the current measurement will be 3.1 mA/count since I will have twice as many counts during the On cycle.

I believe this resolves my issues measuring current, so I can move on to the next step – reading the encoders to determine position, velocity, and acceleration.  I can also start programming a PID loop to control the current.