marvin:ecp3
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
marvin:ecp3 [2009/01/28 17:40] – deva | marvin:ecp3 [2009/01/28 22:51] – deva | ||
---|---|---|---|
Line 3: | Line 3: | ||
title=Marvin - The Balancing Robot. | title=Marvin - The Balancing Robot. | ||
</ | </ | ||
- | |||
- | =====Stikord===== | ||
- | * 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!!! | ||
======Lab report 3 - Driving====== | ======Lab report 3 - Driving====== | ||
Line 21: | 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. | ||
+ | =====The Motor in Theory===== | ||
=== DC Motor Drives === | === DC Motor Drives === | ||
{{ : | {{ : | ||
Line 36: | Line 27: | ||
=== 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 53: | Line 44: | ||
=== 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:// |
{{ : | {{ : | ||
Line 59: | Line 50: | ||
=====Driving the Robot===== | =====Driving the Robot===== | ||
====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 | |
- | 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”. Maybe this has to do with the angular momentum that is being build up when turning on the spot - similar to the ice skater doing a pirouette. Also we reduce the slip in the motor by keeping the robot rotating. This can be seen on the following video\\ | + | |
[[http:// | [[http:// | ||
{{youtube> | {{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 | + | 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 |
====Forward/ | ====Forward/ | ||
Line 71: | Line 61: | ||
{{ : | {{ : | ||
- | 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. | + | 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 " | 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 " | ||
+ | |||
+ | |||
+ | ====Gyroscope Offset Drift Problem==== | ||
+ | Easy as it seems, we did not arrive at the goal easily. We had a very annoying problem, with the gyroscope offset drifting when the robot was not standing still balancing.\\ | ||
+ | The offset seemed to drift in the direction of the angle, and the larger the angle, the faster the drift.\\ | ||
+ | We tried several solutions to the problem, in the following they will be drafted, together with the reason that they did not work:\\ | ||
+ | * 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 determine the angle to be zero, thus reset it. This however would make the robot reset its zero angle at a position //not// zero (it would lean forward but stay in that angle for duration of its forward movement). | ||
+ | * When the angle offset had reached a certain level, the robot continuously tried to straighten up, resulting in the wheels spinning up to maximum in the opposite direction. Based on this observation, | ||
+ | * Next we tried to calculate the drift size by multiplying the angle with some constant. We tried to adjust this constant for a long time, with a lot of measurements, | ||
+ | * We had read somewhere that there might be a problem with the ADC based on its reference voltage, due to drop in battery level. This lead to an attempt to calculate the drift size based on the current battery level measured against the initial battery level. This however did not seem to be the way to things either, since the battery level dropped faster than the drift size would grow. | ||
+ | * We later tried to simply add constant number to the calculated angle, and tried to adjust it manually, by modifying it, tweaking it, until we thought it as accurate as possible. This seemed to work to a certain point. The drift grew smaller, but did not seem to disappear. | ||
+ | * We for some time suspected the gyroscope reading in itself of being too inaccurate, which lead to a fix, where we made a number of readouts, averaging them out and using this as the actual reading instead. This seemed to work while the robot was in balance, but had negative effect when it was tilting fast, which made the gyroscope reading smaller than the actual value due to the averaging out, 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, based on the assumption, that the robot is tilting equally forward and backwards. This seemed to work, so that was the solution we chose. | ||
=====MotorControl===== | =====MotorControl===== |
marvin/ecp3.txt · Last modified: 2009/01/29 11:01 by rieper