marvin:ecp3
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
marvin:ecp3 [2009/01/28 13:37] – deva | marvin:ecp3 [2009/01/29 11:01] (current) – rieper | ||
---|---|---|---|
Line 4: | Line 4: | ||
</ | </ | ||
- | =====Stikord===== | + | ======Lab report 3 - Driving====== |
- | * Stadigt voksende klassediagram | + | |
- | * Styring | + | |
- | * Dreje (gammel / alternativ metode) | + | |
- | * Frem / Tilbage (gammel / alternativ metode) | + | |
- | * Stabilisering ved sinus | + | |
- | * Nye hjul. Stor friktion på gulvtæppe ved gamle hjul --> Motivation til at skifte til nye hjul (slicks) | + | |
- | * Gyro offset float/drift problemet | + | |
- | * Hjul amok løsningen | + | |
- | * Udret fejl jvf. vinkel | + | |
- | * Batteri korrektion (fejl på reference til A/D konverter, drift i denne pga batteri spænding) | + | |
- | * Lille spredning i gyro --> nulstil gyro | + | |
- | * Addering af konstant offset | + | |
- | * Gennemsnitsmålinger på gyro | + | |
- | * Vægtet midling af alle gyrolæsninger --> VIRKER!!! | + | |
- | + | ||
- | + | ||
- | ======End course project, lab report 3====== | + | |
**Date:** January 14nd 2009\\ | **Date:** January 14nd 2009\\ | ||
**Duration of activity:** 8-16\\ | **Duration of activity:** 8-16\\ | ||
Line 28: | Line 11: | ||
=====Project Goal===== | =====Project Goal===== | ||
Make robot able to drive a predefined pattern. | Make robot able to drive a predefined pattern. | ||
+ | |||
=====Plan===== | =====Plan===== | ||
* Create a Motor Control class that can append extra power to the motors individually to control how the robot is behaving. | * Create a Motor Control class that can append extra power to the motors individually to control how the robot is behaving. | ||
- | === DC Motor Drives === | + | =====Theory===== |
- | {{ : | + | ====DC Motor Drives==== |
- | The Lego Mindstorm kit comes with a set of DC Motors and therefore we shall give a short introduction to the DC motor and the DC motor controller. This will hopefully add nicely to the presentation of the H-bridge and DC servo motors | + | {{ : |
+ | The Lego Mindstorm kit comes with a set of DC Motors and therefore we shall give a short introduction to the DC motor and the DC motor controller. This will hopefully add nicely to the presentation of the H-bridge and DC servo motors(([[http:// | ||
- | {{ : | + | {{ : |
The DC motor is illustrated with a permanent magnet, but in many cases a electromagnet is used instead as it improves the performance of the DC servo motor. In a DC motor the rotor carries the electrical power as opposed to the AC motor, where the stator handles the power. The armature winding needs to be in the rotor of a DC motor to provide a rectification of the voltages and currents, which enables the motor to drive in all four quadrants. As we see on the illustration, | The DC motor is illustrated with a permanent magnet, but in many cases a electromagnet is used instead as it improves the performance of the DC servo motor. In a DC motor the rotor carries the electrical power as opposed to the AC motor, where the stator handles the power. The armature winding needs to be in the rotor of a DC motor to provide a rectification of the voltages and currents, which enables the motor to drive in all four quadrants. As we see on the illustration, | ||
- | {{ : | + | {{ : |
- | === Power Electronic Converter === | + | ====Power Electronic Converter==== |
- | We see that the four quadrant | + | We see that the four quadrants |
* The converter must allow both output voltage and current to reverse in order to yield a four-quadrant operation. | * The converter must allow both output voltage and current to reverse in order to yield a four-quadrant operation. | ||
* For accurate control of position, the average voltage output of the converter should vary linearly with its control input, independent of the load on the motor. | * For accurate control of position, the average voltage output of the converter should vary linearly with its control input, independent of the load on the motor. | ||
Line 50: | Line 34: | ||
Further demands may be required, but these are essentials and adequate for our purpose. A linear power amplifier would be highly ineffective and therefore a switch mode dc-dc converter is used. A full bridge (H-bridge) converter is in fact capable of operating in all four quadrants and is illustrated on the following diagram. | Further demands may be required, but these are essentials and adequate for our purpose. A linear power amplifier would be highly ineffective and therefore a switch mode dc-dc converter is used. A full bridge (H-bridge) converter is in fact capable of operating in all four quadrants and is illustrated on the following diagram. | ||
- | {{ : | + | {{ : |
Observe that it contains an energy absorption circuit in order to waste the kinetic energy from the motor load inertia by heating up a resistor. A more advanced solution would be to store the energy back to the battery, which we may assume in the NXT kit. Lastly we will demonstrate the four-quadrant behaviour of the full-bridge dc-dc converter. | Observe that it contains an energy absorption circuit in order to waste the kinetic energy from the motor load inertia by heating up a resistor. A more advanced solution would be to store the energy back to the battery, which we may assume in the NXT kit. Lastly we will demonstrate the four-quadrant behaviour of the full-bridge dc-dc converter. | ||
- | {{ : | + | {{ : |
The top left illustration show forward motion, where two transistors are connected to guide the current forward through the DC motor - notice that the transistors are always connected pairwise. As we decide to change direction the transistors are disconnected in the blanking time, whereafter the other two transistors are connected. The rectifiers are mounted anti parallel and works as a valve for the aforementioned extra energy, that is either eliminated by the resister or fed back to the battery. This is illustrated on the top right, which indicates the forward breaking of the motor. Notice how the voltage and current directions are maintained in the breaking phase, since the motor is incapable of altering its direction instantaneous cf. our explanation regarding kinetic energy. The lower left illustrates the backward motion of the motor and finally lower right shows the backward breaking loop. We therefore see that the H-bridge is in fact capable of four quadrant motion, which is cleverly implemented using transistors and rectifiers. (The diagram is simplified, naturally). | The top left illustration show forward motion, where two transistors are connected to guide the current forward through the DC motor - notice that the transistors are always connected pairwise. As we decide to change direction the transistors are disconnected in the blanking time, whereafter the other two transistors are connected. The rectifiers are mounted anti parallel and works as a valve for the aforementioned extra energy, that is either eliminated by the resister or fed back to the battery. This is illustrated on the top right, which indicates the forward breaking of the motor. Notice how the voltage and current directions are maintained in the breaking phase, since the motor is incapable of altering its direction instantaneous cf. our explanation regarding kinetic energy. The lower left illustrates the backward motion of the motor and finally lower right shows the backward breaking loop. We therefore see that the H-bridge is in fact capable of four quadrant motion, which is cleverly implemented using transistors and rectifiers. (The diagram is simplified, naturally). | ||
Fortunately the motor control is linear, which is a requirement in our control loop as it is a linear controller. However, the average voltage output does not vary linear with the control input voltage during the blanking time, which occurs when the motor direction changes. In our case this happens all the time to keep the robot in state of equilibrium and we may therefore expect some non linear behaviour from the motors. | Fortunately the motor control is linear, which is a requirement in our control loop as it is a linear controller. However, the average voltage output does not vary linear with the control input voltage during the blanking time, which occurs when the motor direction changes. In our case this happens all the time to keep the robot in state of equilibrium and we may therefore expect some non linear behaviour from the motors. | ||
- | === Motor Encoder/ | + | ====Motor Encoder/ |
- | When designing the motors, wheels and drive train, it will almost always be important to have some sort of encoder feedback. In the Lejos framework there are methods to get readings from the tacho counters and these sensor readings have proven to be very useful when designing a balancing robot cf. the research literature in the [[marvin: | + | When designing the motors, wheels and drive train, it will almost always be important to have some sort of encoder feedback. In the LeJOS framework there are methods to get readings from the tacho counters and these sensor readings have proven to be very useful when designing a balancing robot cf. the research literature in the [[http:// |
- | + | ||
- | {{ : | + | |
- | + | ||
- | + | ||
- | + | ||
- | =====Driving the Robot===== | + | |
- | + | ||
+ | {{ : | ||
+ | =====Implementation===== | ||
====Right/ | ====Right/ | ||
+ | Now that the robot is balancing it ought to be simple to make it drive around. We expect the controller to maintain its balance even though we apply the necessary offset to the PWM in order to make it move. At first we added a small offset to one wheel and subtracted from the other, which caused the robot to drive in a circle. The robot actually seemed to be more robust when turning and we were able to reach a high speeds when pivoting "on the spot" | ||
- | Now that the robot is balancing it ought to be simple to make it drive around. We expect the controller to maintain its balance even though we apply the necessary offset to the PWM in order to make it move. At first we added a small offset to one wheel and subtracted from the other, which caused the robot to drive in a circle. The robot actually seemed to be more robust when turning and we were able to reach a high speed when doing a circle “on the spot”. | + | [[http:// |
+ | {{youtube> | ||
- | [[http:// | + | As you may have noticed on the video we did also change the tires. The tires in the original model had a course pattern and this caused it to get stuck on the carpet and so the robot did not behave equally on both carpets and hard surfaces. By changing to a very flat and smooth |
- | {{ youtube> | + | |
- | + | ||
- | As you may have noticed on the video we did also change the tires. The tires in the original model had a course pattern and this caused it to get stuck on the carpet and so the robot did not behave equally on both carpets and slippery | + | |
====Forward/ | ====Forward/ | ||
- | |||
The idea was then to make the robot move forward by adding a small offset on both wheels, but clearly this was not the right approach. Either the controller does not allow the robot to move, or it oscillates and crashes. The reason for this is actually quite clear if we recall our control loop. \\ | The idea was then to make the robot move forward by adding a small offset on both wheels, but clearly this was not the right approach. Either the controller does not allow the robot to move, or it oscillates and crashes. The reason for this is actually quite clear if we recall our control loop. \\ | ||
- | {{: | + | {{ : |
- | + | ||
- | If we apply an offset to both wheels we are removing control from the controller and disturbing the calculated error. Either the control loop will overcome this disturbance by some minor oscillations or it will become unstable as we are really adding to the overshoot. This does not happen when we add a small offset to one wheel and subtract from the other since this does not affect the overall error signal. The natural place to control a closed loop control is of course the reference values, which are applied for each state. The reason that we did not use this approach immediately is probably that the reference values have been left unused as we want all the states to be zero in order for the robot to remain in equilibrium. If a small offset is added to the tilt angle (psi) the robot must remain in motion to stay balanced. Although the robot is capable of moving forward and backward it showed an undesired tendency to oscillate between forward and backward commands. As the contra steering used to turn the robot did seem to stabilize the robot, it seemed important to make the robot occupied in between commands by adding a small amount of contra steering. This will keep the motors busy and reduce the slip when the motors are changing from forward to backward motion simultaneously. We used a sine function to add a small offset to one wheel and subtract from the other as the sine function overall should make the robot remain in the same position - also we can quite easily alter the amount of offset. The real benefit from this is due to high amount of slip in the motors in the instant where they are not active. Before, this slip would point in the same direction, but with the small contra steering it actually points in separate directions, hence stabilizing the robot. | + | |
- | Using this approach we are now able to control the robot as expected, thus we are able to make the robot drive a predefined pattern. It is important to mention that the robot still has a tendency to oscillate, which often requires the control loop to " | + | |
- | + | ||
- | Har vi ikke en video vi kan indsætte her!! | + | |
- | + | ||
- | + | ||
- | ====Problems==== | + | |
- | Side ... | + | |
- | Har vi implementeret en hjul synkronisering? | + | |
- | + | ||
- | Side 22 | + | |
- | DC motor maximum voltage is necessary to calculate PWM duty. In the Cal vol_max subsystem, we use the | + | |
- | following experimental equation which is a conversion rule between the battery voltage V_b and the maximum | + | |
- | DC motor voltage V_max | + | |
- | V_max = 0.001089 * V_b - 0.625 | + | |
- | + | ||
- | Side 23 | + | |
- | Gyro kalibrering | + | |
- | + | ||
- | Side 26 | + | |
- | Forskellige opgaver køres med forskelligt tids interval | + | |
- | + | ||
- | Side 55 | + | |
- | PID kontrol af Servo | + | |
+ | If we apply an offset to both wheels we are removing control from the controller and disturbing the calculated error. Either the control loop will overcome this disturbance by some minor oscillations or it will become unstable as we are really adding to the overshoot. This does not happen when we add a small offset to one wheel and subtract from the other since this does not affect the overall error signal. The natural place to control a closed loop control is of course the reference values, which are applied for each state. The reason that we did not use this approach immediately is probably that the reference values have been left unused as we want all the states to be zero in order for the robot to remain in equilibrium. If a small offset is added to the tilt angle (< | ||
+ | Using this approach we are now able to control the robot as expected, thus we are able to make the robot drive a predefined pattern. It is important to mention that the robot still has a tendency to oscillate, which often requires the control loop to " | ||
+ | The goal of this lab session was to make Marvin capable of driving a predefined pattern, but we did not specify anything about the accuracy of its position or which type of pattern. We are currently satisfied with the progress and we find the result satisfactory with respect to the next lab session in which we shall implement the behaviour based control model. | ||
+ | ====Gyroscope Offset Drift Problem==== | ||
+ | Easy as it seems, we did not arrive at the goal without bumps. We had a very annoying problem, where the gyroscope offset was drifting whenever the robot was not standing still in equilibrium (i.e. driving somewhere).\\ | ||
+ | The offset seemed to drift in the direction of the angle (and thereby driving direction), and the larger the angle, the faster the drifting.\\ | ||
+ | We tried several solutions to the problem, in the following they will be outlined, together with the reasons for why they did not work (apart from the last one which in fact worked):\\ | ||
+ | * The first approach was based on the fact that when the robot was in perfect balance (the angle velocities were below a threshold for some amount of time) we could redefine the angle as zero, thus reset the gyroscope angle. This however would make the robot reset its angle at a position //not// vertical whenever driving forward, for some period of time long enough to exceed the threshold buffer length. | ||
+ | * Second we used the fact that when the angle offset had reached a certain level, the robot continuously tried to straighten up, resulting in the wheels spinning up to maximum speed in the opposite direction. Based on this observation, | ||
+ | * Next we tried to calculate the drift size by multiplying the angle with a constant. We put a lot of effort into tuning this constant, but all in vein. If the drift size can be calculated as a function of the angle, it is certainly not a linear one. | ||
+ | * We had read, on an NXT/ | ||
+ | * We later tried to simply add a constant to the calculated angle after each iteration, and tried to adjust it manually, by modifying it, tweaking it, until we thought it as accurate as we could possibly make it. This seemed to work to a certain point. The drift grew smaller, but never seemed to disappear entirely. | ||
+ | * For some time we suspected the gyroscope reading in itself of being too inaccurate, which lead to a fix, where we replaced every reading with the average of a number of readouts, each with a 3ms interval. This seemed to work while the robot was in balance, but had negative effect when it was tilting fast, since this very same method would dampen the large values of the gyroscope, so this was obviously not a satisfying solution either. | ||
+ | * The last attempt was to simply make a running weighted average of all the gyroscope readings, with an initial value measured by hand. This method was based on the assumption, that the robot would be tilting equally much forward and backwards, which seems plausible. This seemed to work, so that was the solution we chose. | ||
- | =====MotorControl===== | + | All of these considerations lead to the programming of the '' |
+ | ====The MotorControl | ||
{{ : | {{ : | ||
- | The MotorControl class handles the motors. It works as a control interface on top of the actual Motor ports, and ca report angle and angle velocity (using the TACHO counter) of both of them, as well as set the power and direction.\\ | + | The MotorControl class handles the motors |
- | A small stabilizing algorithm is located at the top of the '' | + | The small stabilizing algorithm is located at the top of the '' |
- | This is done by adding a small amount of power controlled | + | The small amount of power added by the sine function, makes the robot wriggle a little |
The motor angle and angle velocity methods simply uses the average of the values from the actual motor ports.\\ | The motor angle and angle velocity methods simply uses the average of the values from the actual motor ports.\\ | ||
- | The code for these things | + | The code for these methods |
<code java> | <code java> | ||
class MotorControl | class MotorControl | ||
Line 170: | Line 135: | ||
- | =====Ctrl===== | + | ====Ctrl==== |
{{ : | {{ : | ||
The Ctrl class is used to handle the control parameters of Marvin. | The Ctrl class is used to handle the control parameters of Marvin. | ||
- | It is used for cross thread communication, | + | It is used for cross thread communication, |
The parameters are left and right motor power offsets, and gyroscope tilt angle offset. | The parameters are left and right motor power offsets, and gyroscope tilt angle offset. | ||
- | A way to make Marvin drive in a hardcoded | + | The way we made Marvin drive in a hard coded path was to set these values directly in the Ctrl class, and use a counter to switch values after a predefined number of iterations (simply increment the counter upon each '' |
The code for the '' | The code for the '' |
marvin/ecp3.txt · Last modified: 2009/01/29 11:01 by rieper