DASL: Weekly Update 2007-09-20

Below is the Motor Controller v2

Below is the Motor Controller v2.0 PCB populated and un-populated.  It is important to note that there are a few things that need to be changed on the PCB.

 

Motor Controller PCB v2.0 Top – Populated

 

Please note that we did not have enough of the blue screw on headers but they fit in to the soldering holes nicely.

 

I believe that the capacitors are too close together and will have to be spaced out a little bit more.  Also the power connector is hooked up backwards; it is now setup as center negative and not center positive.

 

Motor Controller PCB v2.0 Bottom – Populated

 

The DB-9 connector was meant to be on the top and facing the other direction.  This needs to be changed unless this location is preferred.

 

Motor Controller PCB v2.0 Top – Unpopulated

 

The red circle indicates that they should nto be all connected at that point.  This will be fixed in the next revision.

 

Motor Controller PCB v2.0 Bottom – Unpopulated

 

 

NI-USB-6211 DAQ hooked up via 10 wires to motor controller board

 

Above is the DAQ hooked up to the motor controller board.  Some of the wires, such as the optical encoder wires, are hooked up to the motor controller board simply as pass through wires with the output going straight to the DB-9 connector that goes right to the cart unit as seen in the picture below.

 

Cart system connected to the motor controller

 

Pivot point of the cart system connected to the controller

 

Cart of the cart system connected to the controller

Control Testing

Below are the screen shots from the Labview VI that I made which just gives a voltage command for velocity

Below are the screen shots from the Labview VI that I made which just gives a voltage command for velocity.  The graphs outputs are as follows, Position Vs. Time, and Velocity Vs. Time.

 

At a constant velocity command we expect to have a linear line with a constant slope for the position and a horizontal linear line for the velocity.  The slope of the position graph should be the value that the velocity graph stays at.  Please note that I am running this experiment with the following equipment.

 

Labview 8.0

Motor controller V2.0 with +-20V @ 1.5A

 

Computer:

-         Processor: Intel Celeron @ 2.60Ghz

-         Ram: 512mb

-         Windows XP SP2

-         USB-2.0

 

DAQ: NI-USB-6211 DAQ

 

Encoders: 300 tick with 4x

 

In this experiment I will test the accuracy of the measurements at different sampling frequencies: N = 3, 10, 20, 30, and 40 where N is the number of samples per second.

 

 

 

Velocity Test VI Front Panel

Velocity Test VI Back Panel

 

Below are the output position and velocity graphs for the command voltage of 2.5V @ N = 3, 10, 20, 30, and 40.

 

Position and Velocity Graphs for N = 3, 10, 20, 30, and 40 samples/sec

 

As you can see from above the velocity is centered slight above 1m/s for all of the tests and the slopes are all about the same, 1.1.  Each window is 5sec wide.  I calculated by using my analog watch for the system to do 7 rotations in about 16 seconds.  Note that the circumference of the circular path is 2.137m.  I got an approximate velocity of 0.9345m/s which is close to that of what the computer calculated.

 

As you can see the position plots of each of the tests look the same because they all have the same time scale.  However the velocity plots of the system for each sampling rate gets more and more “dirty” as we increase the sampling rate.  I believe that this is because the new data for the encoders are not ready each time we ask for the data.

 

Causes:

 

I believe that the cause lies in one of three places;

 

The first cause might be the computer that I am using is not fast enough to run Labview at the desired speed.  I will test the latter by using a much better computer, aka James Hing’s laptop, for a second test run of the data. 

 

The second possibility might be that the command velocity is not fast enough for the encoder to move one, or more, ticks within a sampling period.  I will check this by doing a calculation as to how fast it needs to go to have a single tick in a single sampling period.

 

The third possibility might be that the DAQ is not fast enough to get the new data from the encoders when asked for it.  I believe that this is the problem if that latter two options are not the problem.

 

First Possibility: Computer is too slow

 

I then ran the same VI as above with N = 40 on James Hing’s computer with the following specs:

 

Computer:

-         Intel Core2Duo 2.33GHz

-         Ram: 3Gb

-         Windows XP SP2

-         USB-2.0

 

Position and Velocity at N = 40 samples/sec on James Hing’s good computer

 

The velocity and position graph that I got from the use of the faster computer revealed that the speed of this computer IS probably one of the major factors of the failing of this system. 

 

Second Possibility: Encoders not high enough resolution

 

 

N (sample/sec)

Min Velos m/s

radius (m)

Circumference (m)

# of Ticks

n (m/tick)

1

0.0071

0.34

2.13628

300

0.00712

3

0.0214

 

 

 

 

10

0.0712

 

 

 

 

20

0.1424

 

 

 

 

30

0.2136

 

 

 

 

40

0.2848

 

 

 

 

 

Above you can see the calculations for the minimum velocity for the sampling rate for the given radius and encoders.  I found that the velocity that we are running at it much higher than the minimum velocity.  Thus I believe that the encoder’s resolution is NOT the problem.

 

Third Possibility: DAQ not fast enough

 

Because the system worked a lot better when a faster computer was used I believe that it is safe to say that the NI-USB-6211 DAQ is fast enough for the job and thus is NOT the problem.

 

The Temporary fix:

 

To temporarily solve this problem I closed down all of the other programs on the computer and allowed Labview to have all the resources that it needs.

 

 

PID Tests:

 

I first implemented a negative feedback system with the cart in an attempt to control the velocity.  I would only use P control for this first step.  Please see the figures below for the Labview VI for the PID setup.

 

PID Velocity Control VI Front Panel

 

PID Velocity Control VI Back Panel

 

For my first test I did P control with a negative feedback loop and a command velocity of 2m/sec.  The figure below shows the output graphs of the system moving at about 1.5m/sec with this control loop.  It is important to note that the system has a steady state error because we are only using P control

 

Negative Feedback velocity control (P control only, Kp = 4)

 

I then did a PI control with Kp = 4 and Ki = 0.6 you can see that it is trying to control the velocity more but it is just creating an oscillation.

Negative Feedback velocity control (PI control only, Kp = 4 and Ki = 0.6)

 

I then did a PID control with Kp = 4, Ki = 0.6 and Kd = 0.2.  Please see the figure below for the output graphs.

Negative Feedback velocity control (PID control only, Kp = 4, Ki = 0.6, and Kd = 0.2)

 

Conclusion:

 

I was able to successfully do negative feedback control with this system.  It is important to note that when I increased my Ki or Kd values it made the system oscillate around the steady state.

 

Please click here for the Labview VI for the PID control that was being used above.