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 23:16] – deva | marvin:ecp3 [2009/01/29 11:01] (current) – rieper | ||
---|---|---|---|
Line 15: | Line 15: | ||
* 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===== | + | =====Theory===== |
- | === DC Motor Drives === | + | ====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:// |
{{ : | {{ : | ||
Line 26: | Line 26: | ||
{{ : | {{ : | ||
- | === Power Electronic Converter === | + | ====Power Electronic Converter==== |
We see that the four quadrants refers to the four combinations of voltage and current directions. As mentioned the motor is actually transferring energy back to the supply when breaking and this requires special attention when designing a motor controller. In order to control the DC motor a Power Electric Converter (PEC) that satisfies the following conditions is needed. ((Power Electronics, | We see that the four quadrants refers to the four combinations of voltage and current directions. As mentioned the motor is actually transferring energy back to the supply when breaking and this requires special attention when designing a motor controller. In order to control the DC motor a Power Electric Converter (PEC) that satisfies the following conditions is needed. ((Power Electronics, | ||
* 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. | ||
Line 43: | Line 43: | ||
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 [[http:// | + | 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 speeds when pivoting "on the spot" | ||
Line 70: | Line 70: | ||
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):\\ | 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. | * 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 in the opposite direction. Based on this observation, | + | * 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 |
- | * 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, but all in vein. If the drift size could be calculated as a function of the angle, it was certainly not a linear | + | * 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 |
- | * We had read somewhere | + | * We had read, on an NXT/ |
- | * We later tried to simply add constant | + | * 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 |
- | * 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, | + | * 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, |
- | * 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. | + | * The last attempt was to simply make a running weighted average of all the gyroscope readings, |
- | =====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 134: | 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.1233180999.txt.gz · Last modified: 2009/01/28 23:16 by deva