marvin:ecp2
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
marvin:ecp2 [2009/01/29 08:49] – deva | marvin:ecp2 [2009/01/29 11:02] (current) – rieper | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | |||
<texit info> | <texit info> | ||
author=Johnny Rieper, Bent Bisballe Nyeng and Kasper Sohn | author=Johnny Rieper, Bent Bisballe Nyeng and Kasper Sohn | ||
Line 9: | Line 8: | ||
**Duration of activity:** 8-12\\ | **Duration of activity:** 8-12\\ | ||
**Participants: | **Participants: | ||
+ | //Note that we returned to this subject several times during the following lab sessions.// | ||
=====Project Goal===== | =====Project Goal===== | ||
Line 21: | Line 21: | ||
- | =====Our Angle of Approach Towards Control Theory===== | + | ===== Theory ===== |
+ | ====Our Angle of Approach Towards Control Theory==== | ||
- | Basically there are three approaches to our control problem, which we will describe briefly in an increasing order of complexity. | + | Basically there are three approaches to our control problem, which we will describe briefly in an increasing order of complexity. |
- | The second approach is again to consider the control plant as a black box, but here we wish to estimate the characteristic transfer function of the plant. Recall that if we give an impulse to a filter we are given the filter characteristic by means of the impulse response. The analogy to control theory is to apply a step function and observe the transient response, which is illustrated on the figures in the following section | + | The second approach is again to consider the control plant as a black box, but here we wish to estimate the characteristic transfer function of the plant. Recall that if we give an impulse to a filter we are given the filter characteristic by means of the impulse response. The analogy to control theory is to apply a step function and observe the transient response, which is illustrated on the figures in the following section |
- | The third method is to derive a mathematical model of the dynamics of the control plant and this can be somewhat complex. In the case of a balancing robot it is helpful to look at the mathematical modelling of an inverted pendulum and there next to add the physical dimensions of the balancing robot. When working with modelling we end up with non linear equations, which is a problem as our controllers are linear. One common method is to use the state space representation and then to make a linearization | + | The third method is to derive a mathematical model of the dynamics of the control plant and this can be somewhat complex. In the case of a balancing robot it is helpful to look at the mathematical modelling of an inverted pendulum and there next to add the physical dimensions of the balancing robot. When working with modelling we end up with non linear equations, which is a problem as our controllers are linear. One common method is to use the state space representation and then to make a linearisation |
- | =====Introducing the PID Controller===== | + | ====Introducing the PID Controller==== |
The digital implementation of a PID controller is actually based on very simple filtering techniques similar to what we described in the [[http:// | The digital implementation of a PID controller is actually based on very simple filtering techniques similar to what we described in the [[http:// | ||
Line 111: | Line 112: | ||
The above pictures are from (([[http:// | The above pictures are from (([[http:// | ||
- | By inspection we summarize the following. An increase in the proportional gain will create a larger overshoot, but reduce the steady state error and rise time. An increase in the integral controller also increase the overshoot, while eliminating the steady state error. If we increase the differential controller, we decrease the overshoot with no affect on the steady state error, but the bandwith | + | By inspection we summarize the following. An increase in the proportional gain will create a larger overshoot, but reduce the steady state error and rise time. An increase in the integral controller also increase the overshoot, while eliminating the steady state error. If we increase the differential controller, we decrease the overshoot with no affect on the steady state error, but the bandwidth |
Line 129: | Line 130: | ||
</ | </ | ||
- | Further readings and inspiration are found at " | + | Further readings and inspiration are found at this homepage(([[http:// |
- | ===== Defining the States in the Control Loop ===== | + | ==== Defining the States in the Control Loop ==== |
Now that we have established our choice of control loop, we must determine an error function. In a state space representation this corresponds to determining the states, which are defined through differential equations describing the dynamics of the control plant. Therefore we may turn to the model described in the documentation of Rich Chi Ooi((Balancing a Two-Wheeled Autonomous Robot, Author Rich Chi Ooi, The University of Western Australia | Now that we have established our choice of control loop, we must determine an error function. In a state space representation this corresponds to determining the states, which are defined through differential equations describing the dynamics of the control plant. Therefore we may turn to the model described in the documentation of Rich Chi Ooi((Balancing a Two-Wheeled Autonomous Robot, Author Rich Chi Ooi, The University of Western Australia | ||
Line 142: | Line 143: | ||
{{ : | {{ : | ||
- | This makes perfectly sense, since we need to drive the wheels in a direction that keeps the upper body of the robot in equilibrium. We therefore need sensor readings regarding the position of the wheels and the upper body in order to keep the wheels under the robot’s | + | This makes perfectly sense, since we need to drive the wheels in a direction that keeps the upper body of the robot in equilibrium. We therefore need sensor readings regarding the position of the wheels and the upper body in order to keep the wheels under the robot’s |
{{ : | {{ : | ||
Line 148: | Line 149: | ||
- | ===== Parameters and Stability | + | ==== Parameters and Stability ==== |
- | The calculation of the right PID control parameters is essential to secure a stable system. This is called loop tuning. If loop tuning is not done according to the task at hand, the control system will become unstable i.e. the output will diverge. Oscillation might occur in this case. The only thing that will prevent | + | The calculation of the right PID control parameters is essential to secure a stable system. This is called loop tuning. If loop tuning is not done according to the task at hand, the control system will become unstable i.e. the output will diverge. Oscillation might occur in this case. The only thing that will prevent |
Loop tuning could be defined as adjusting the control loop parameters (Proportional gain(P), Integral gain (I) and Derivative gain(D)) to the optimum value for a desired control response. The z-transform for the controller should, in order to be stable obey the rules for a stable system, that is poles of the system should be located inside the unity circle, see diagram below. | Loop tuning could be defined as adjusting the control loop parameters (Proportional gain(P), Integral gain (I) and Derivative gain(D)) to the optimum value for a desired control response. The z-transform for the controller should, in order to be stable obey the rules for a stable system, that is poles of the system should be located inside the unity circle, see diagram below. | ||
Line 157: | Line 158: | ||
There are a number of different approaches when tuning PID parameters of which three will be described below. | There are a number of different approaches when tuning PID parameters of which three will be described below. | ||
- | The methods that can be used range from no knowledge of the system to a full simulation of the system that can be used to calculate stability and set the exact parameters of the PID controller for optimum performance. One thing to note before talking about parameter tuning is the difference between online tuning and offline tuning. Online tuning means tuning when the system is running. That means one adjust parameters while the system is running. Offline tuning means take the control out of the plant, adjust the parameters and then re-engage the system. It is the later method we have used. The robot have been stopped, the parameters have en adjusted in the software, and lastly new firmware have been uploaded. Online tuning could have been used with a bluetooth | + | The methods that can be used range from no knowledge of the system to a full simulation of the system that can be used to calculate stability and set the exact parameters of the PID controller for optimum performance. One thing to note before talking about parameter tuning is the difference between online tuning and offline tuning. Online tuning means tuning when the system is running. That means one adjust parameters while the system is running. Offline tuning means take the control out of the plant, adjust the parameters and then re-engage the system. It is the later method we have used. The robot have been stopped, the parameters have en adjusted in the software, and lastly new firmware have been uploaded. Online tuning could have been used with a Bluetooth |
- | === Manual | + | === Manual |
This is a trial and error approach. You do not need to have any idea about the plant. The procedure is as follows: | This is a trial and error approach. You do not need to have any idea about the plant. The procedure is as follows: | ||
* Set I and D values to zero | * Set I and D values to zero | ||
Line 186: | Line 187: | ||
There exist different kinds of tuning software. One of these could be (([[http:// | There exist different kinds of tuning software. One of these could be (([[http:// | ||
- | === Summarize of approaches | + | === Summarize of Approaches |
The three different approaches can be seen from the table below. In that table the advantages an disadvantages can me seen together with what knowledge is required. | The three different approaches can be seen from the table below. In that table the advantages an disadvantages can me seen together with what knowledge is required. | ||
^ Method ^ Advantages ^ Disadvantage ^ Requirements ^ | ^ Method ^ Advantages ^ Disadvantage ^ Requirements ^ | ||
^ Manual Tuning | No math required (Online*) | Inaccurate | ^ Manual Tuning | No math required (Online*) | Inaccurate | ||
- | ^ Ziegler-Nichols | Proven method (Online*)| Trial and error, pretty | + | ^ Ziegler-Nichols | Proven method (Online*)| Trial and error, pretty |
^ Software Tools | Consistent tuning, Online or offline tuning, Allow for simulation beforehand | Expensive, knowledge about plant and development tools are required | Mathematical model | | ^ Software Tools | Consistent tuning, Online or offline tuning, Allow for simulation beforehand | Expensive, knowledge about plant and development tools are required | Mathematical model | | ||
* Online can in some cases be a disadvantage, | * Online can in some cases be a disadvantage, | ||
Line 198: | Line 199: | ||
- | ===== Results | + | ===== Implementation |
First we present the software implementation, | First we present the software implementation, | ||
Line 205: | Line 206: | ||
This class contains all the PID magic happening that makes Marvin keep its balance. | This class contains all the PID magic happening that makes Marvin keep its balance. | ||
- | The balancing module reads the angles and the angle velocities from the gyro and motors, and uses these values (weighted) to feed to the PID control calculation which again produces the new power to apply to the motors. | + | The balancing module reads the angles and the angle velocities from the gyroscope |
These are the constants used as weights in PID control, and the error calculation: | These are the constants used as weights in PID control, and the error calculation: | ||
Line 222: | Line 223: | ||
velocities) < | velocities) < | ||
- | The sleep call at the end of the loop, reflects the max sample speed of the Gyroscope, which should be is 300 times per second, 3.33msec between calls, but since the code itself takes up some time, the actual sleep value of 3msec seem to work appropriately. | + | The sleep call at the end of the loop, reflects the max sample speed of the gyroscope, which should be is 300 times per second, 3.33msec between calls, but since the code itself takes up some time, the actual sleep value of 3msec seem to work appropriately. |
The controls are added, in two places: | The controls are added, in two places: | ||
- | * To make Marvin move forward and backwards we add the tilt offset to the gyro angle (at the '' | + | * To make Marvin move forward and backwards we add the tilt offset to the gyroscope |
* To make Marvin rotate wee add the left and right motor offsets directly to the right and left motor power (at the '' | * To make Marvin rotate wee add the left and right motor offsets directly to the right and left motor power (at the '' | ||
Line 239: | Line 240: | ||
public void run() | public void run() | ||
+ | |||
{ | { | ||
MotorControl motors = new MotorControl(Motor.C, | MotorControl motors = new MotorControl(Motor.C, | ||
Line 275: | Line 277: | ||
- | ====Hardware Related Issues==== | ||
- | At first we experienced severe problems with the gyroscope readings as the gyroscope tends to drift over time. This was actually expected, but though we knew of this problem we had no experience of how to resolve the drifting - nor did we know the impact of this problem. Unfortunately the stability of the robot was highly sensitive to the offset of the gyroscope and the drifting would constantly lead to diverging oscillations in the beginning, which caused Marvin to crash over and over. (Fortunately the NXT module is quite solid.) We used great effort to find a solution to this problem, where some were well thought out while others were of the more desperate kind. Here follows a short listing of some of our efforts. | ||
- | |||
- | * The gyroscope is an analogue sensor so the output is measured by the NXT A/D hardware and the suspicion was that the gyroscope readings were being influenced by a possible drop in reference voltage in the A/D converter, which is changing the reading. this is backed up by the discussion concerning low batteries at the nxtasy forum.(([[http:// | ||
- | * We tried to compensate the drifting of the gyroscope by implementing a running average in the gyroscope readings. This did not produce lasting results, but would aid for a short while. We also tried a weighted average, which is basically a low pass filter mechanism that uses a forgetting factor. The forgetting factor (filter coefficient) will weight how much trust we put in the incoming reading in proportion to the older samples. This kind of a Markov assumption, where we believe that the measurements are correlated within a given time frame, which we believe they are. If we were to continue in this direction we could have chosen to work with a sensor fusion which could be to add an accelerometer and then combining the to sensors by low pass filtering the gyroscope readings while using a high pass filter for the accelerometer. We then would need to find a compromise for the optimal cross-over frequency. Others have done this, but as usual the practical implementation is not trivial and we did not have an available accelerometer. | ||
- | |||
- | * Another attempt was to calculate the standard deviation of the gyroscope readings and then to auto calibrate the gyroscope readings based on a given threshold. The assumption was, if the standard deviation was low within a time frame, the system ought to be stable and we should recalibrate. The problem was, that the gyroscope sometimes failed to read really fast movements, which could cause the integration to fail. This may be another argument for adding an accelerometer since it will perform better at higher frequencies that the gyroscope and visa versa. | ||
- | |||
- | During these frustrating hours we were able to find a stable combination of the tuning parameters, where the robot was able to balance. The problem was the forward and backward driving, which continuously caused Marvin to oscillate and ultimately crash. At this point we did not use all the aforementioned states as all four states contributed to an increasing set of gain combinations - it is not that easy to set all seven gains intuitively! We were only using the integration part of the gyroscope readings, but our suspicion at this point was closing in on the (lack of) states in the control loop. As we finally decided to work with all four states in the control loop, we were perhaps quite lucky to find the right combination of the four feedback gains. By adding these extra features we found a way to overcome the drifting of the gyroscope to a satisfying degree. After some longer fine tuning of the parameters we found that Marvin was pretty stable and hereafter we were confident that he would be able to drive properly. It had to be a matter of finding the right approach, but this problem was addressed in the following lab session. | ||
+ | ====Hardware Related Issues==== | ||
+ | At first we experienced severe stability problems as Marvin was highly sensitive to the offset of the gyroscope. The offset calibration did not appear to be stationary and this lead to diverging oscillations, |
marvin/ecp2.1233215365.txt.gz · Last modified: 2009/01/29 08:49 by deva