Differences

This shows you the differences between two versions of the page.

--- marvin:ecp1 [2009/01/29 00:03] – deva
+++ marvin:ecp1 [2009/01/29 11:03] (current) – rieper
@@ Line 10: / Line 10: @@
 =====Goal=====
-Make robot able to communicate with gyroscope.
+Make Marvin able to communicate with gyroscope.
 =====Plan=====
@@ Line 17: / Line 17: @@
   * Find or create a class for the gyroscope communication.
-=====Analysis=====
+=====Theory=====
-====Analogue to digital conversion and limitations====
-The main problem when dealing with sensors is that the real world is continuous and when we want to interpret these data it has to be digitized in some way. This is done with an analogue to digital converter (A/D-converter or simply ADC). The opposite applies when we have a digital value, such as an integer and this is converted to an analogue value (D/A-converter or DAC).  This in itself is a huge area, and the conversion itself will not be covered further. The important thing to remember is that in order to get an appropriate estimate of the real world the samples that you take from your sensor has to often enough so that you will not loose vital data. How often one should sample depends on the application, but as a rule of thumb one should sample minimum twice as fast as the highest rate of different that will occur.  As an example, if you want to reproduce a sinus with the frequency of 100 Hz, you will have to sample with 200 Hz. A higher sample rate will produce a more accurate output, but will also need more computational power.
+====Analogue to Digital Conversion and Limitations====
+The main problem when dealing with sensors is that the real world is continuous and when we want to interpret these data it has to be digitized (discretized) in some way. This is done with an analogue to digital converter (A/D-converter or simply ADC). The opposite applies when we have a digital value, such as an integer and this is converted to an analogue value (D/A-converter or DAC).  This in itself is a huge area, and the conversion itself will not be covered further. The important thing to remember is that in order to get an appropriate estimate of the real world the samples that you take from your sensor has to be taken often enough so that you will not loose vital data. How often one should sample depends on the application, but as a rule of thumb one should sample minimum twice as fast as the highest rate of different that will occur.  As an example, if you want to reproduce a sinus with the frequency of 100 Hz, you will have to sample with 200 Hz. A higher sample rate will produce a more accurate output, but will also need more computational power.
 The gyroscope utilizes the ADC so that it is possible to get readings from the gyroscope.
 ====Gyroscope====
-The gyroscope used is sold by HiTechnic (([[http://www.hitechnic.com/|Hi-Technic]])) and is shown on the picture below. The housing is a standard Lego Mindstorm sensor so it fits with other sensors, and is more easily incorporated in a building scheme which purely uses lego bricks.
+The gyroscope used has been purchased from HiTechnic (([[http://www.hitechnic.com/|Hi-Technic]])) and is shown on the picture below. The housing is a standard Lego Mindstorm sensor so it fits with other sensors, and is more easily incorporated in a building scheme which purely uses LEGO bricks.
 {{ :marvin:p_lab1_gyro1.jpg?200 |Hitechnic gyroscope }}
-The gyroscope is produced to work seamless with the Lego NXT Brick. It connects to the NXT using a standard wire and utilizes the analogue interface. The gyroscope contains a single axis gyroscopic sensor that detects rotation and returns a value representing the number of degrees per second of rotation. The gyroscope sensor measures up to +/- 360 degrees per second of rotation and these readings will be signed if the correct offset is used.
+The gyroscope is produced to work seamless with the LEGO NXT Brick. It connects to the NXT using a standard wire and utilizes the analogue interface. The gyroscope contains a single axis gyroscopic sensor that detects rotation and returns a value representing the number of degrees per second of rotation. The gyroscope sensor measures up to +/- 360 degrees per second of rotation and these readings will be signed if the correct offset is used.
 As not all gyroscopes are identical there will be some minor differences in the offset, but the manual that came along with the gyroscope, indicates this to be around 620. This is the offset value has to be subtracted from the readings from the gyroscope in order to get a signed reading. \\
-The sensor can be read 300 times per second, which correspond to a sample rate of 300 Hz.\\
+The sensor can be read 300 times per second (an interval of 3.33 times per second), which correspond to a sample rate of 300 Hz.\\
+The gyroscope operates in relative values, which means that it can not tell where e.g. upright is. One have to "show" where that is, and from there the gyroscope readings will show how fast the gyroscope is moving from that position. To get an accurate reading it might be necessary to read the value from the right position over some time (e.g. 2 seconds) and from that generate a mean value. This mean value of offset can then be used in further calculations to increase accuracy.
-The gyroscope operates in relative values, which means that it can not tell where e.g. upright is. One have to "show" where that is, and from there the gyroscope readings will show how fast the gyroscope is moving from that position. To get an accurate reading it might be necessary to read the value from the right position over some time (e.g. 2 seconds) on from that generate a mean value. This mean value of offset can then be used in further calculations to increase accuracy.
+The axis of measurement is in the vertical plane with the gyroscope sensor positioned with the black end cap facing upwards, as illustrated in thye figure below.
-The axis of measurement is in the vertical plane with the gyroscope sensor positioned with the black end cap facing upwards. A picture is shown below.\\
 {{ :marvin:p_lab1_gyro2.jpg |Side view of gyroscope}}
-The right placement of the gyroscope can be seen from the [[#Building the robot|building instructions]]
+The correct placement of the gyroscope can be seen in the [[#Building the robot|building instructions]]
-=====Building the robot=====
+====Building the Robot====
-====Preliminary considerations====
+===Preliminary considerations===
-Our primary goal is to make a balancing robot, and therefore it would be nice to eliminate the possible of failure due to a bad build. This is the reason why we chose to re-use the instructions provided as seen in the building manual(([[http://www.mathworks.com/matlabcentral/fileexchange/19147|Math Works]])). We know that this design is working. Another reason for choosing this design is that there exist extensive simulation material on this specific robot, hence making it easier to fine-tune the parameters later on.
+Our primary goal is to make a balancing robot, and therefore it would be nice to eliminate the possibility of failure due to a bad build. This is the reason why we chose to re-use the instructions provided as seen in the building manual(([[http://www.mathworks.com/matlabcentral/fileexchange/19147|Math Works]])). We know that this design is working. Another reason for choosing this design is that there exists extensive simulation material on this specific robot, which might make it easier to fine-tune the parameters later on.
-====The Build====
+===The Build===
 The build is pretty straight forward, as the building instructions is well written and also accompanied by photos. One thing to note though, is that the robot is fairly symmetric, so building instructions is only provided for one side of the robot and it is up to the builder to mirror the other side. This is however no problem because of the good photos.\\
 The finished robot can be seen in the picture below.
@@ Line 49: / Line 52: @@
 {{ :marvin:projekt_lab1_1.jpg?300 |Marvin}}
-One thing worth noting is that the ultrasonic sensor is shifted slightly to the left. This is because it is important that the gyroscopes fixpoint is centered on the vertical axis of the robot. The gyroscope is a one axis gyroscope, and therefore this has to be oriented in the right directions in order to work in the same directions as the robot will be moving, that is forward and backward. Positioning of the gyroscope is well documented in the building instructions. Below is a photo of the gyroscope in place.
+One thing worth noting is that the ultrasonic sensor is shifted slightly to the left. This is because it is important that the gyroscopes fix point is centered on the vertical axis of the robot. Positioning of the gyroscope is well documented in the building instructions. Below is a photo of the gyroscope in place.
 {{ :marvin:p_lab1_behind.png?300 |The gyroscope mounted on Marvin}}
@@ Line 63: / Line 66: @@
 | DC Motor Left * | PWM | % | int8 | 500 | B |
 | DC Motor Right * |PWM | % | int8 | 500 | C |
-*The rotary encoders and DC Motors (left and right respectively) utilizes the same port
+*The rotary encoders and DC Motors (left and right respectively) utilizes the same port.
+====Pros and Cons About the Design====
+As mentioned earlier, this is a well documented and working design. This is of great importance, because we can eliminate this as a factor of error later on. Another issue that have proven important in our experiments is the ability to easily remove the battery for recharging. This may not seem important at this point, but the characteristics of the voltage applied to the motors vary greatly with the charge level of the battery, and therefore the behaviour of the motors varies. It is therefore a nice  feature that the battery is easy to remove without tearing the robot apart.\\
-====Pros and Cons About This Design====
+In the group we discussed what effect the wheel diameter will have on the robot. Wheels with a larger diameter will travel a longer than smaller wheels for the same amount of power applied to the motor on which the wheel is mounted. We decided that the resolution of the wheel rotational properties were accurate enough to go with the larger wheels, and these wheels were also used in the design we used in the first place, and therefore was a well-proven design.
-As mentioned earlier, this is a well documented and working design. This is of great importance, because we thus can eliminate this as a factor of error later on. Another issue that have proven important in our experiments is the ability to easily remove the battery for recharging. This may not seem that important, but the characteristics of the voltage applied to the motors vary greatly with the charge level of the battery, and therefore the behaviour of the motors will vary. It is therefore a nice  feature that the battery is easy to remove without tearing the robot apart.\\
-In the group we discussed what effect the wheel diameter will have on the robot. Wheels with a larger diameter will travel longer than smaller wheels for the same amount of power applied to the motor on which the wheel is attached. We thought that the resolution of the wheel rotational properties were sufficient enough to go with the larger wheels, and these wheels were also used in the design we used in the first place, and therefore was a well-proven design.
 A thing worth mentioning is the construction of the wheel mounting point and wheelbase which can be seen on the picture below
@@ Line 81: / Line 82: @@
 {{ :marvin:p_lab1_slick.jpg?150 |Slick surface wheels}}
-The standard wheels sometimes got stuck in the carpet causing the robot to loose balance. Therefore we switched these with someone of similar diameter, but with a much more slick surface. These had sufficient traction, but did not cause the robot to get stuck in the carpet.
 =====Implementation=====
 ====Numerical Readings from the Gyroscope====
-A gyroscope measures angle per second or simply angle velocity and therefore we must use numerical integration in order to read the angle. A gyroscope has a bias which is simply an offset and naturally we want to eliminate this offset by calibration methods at the beginning of the program. If we do not calibrate, the integration e.g. a running sum will add the offset contribution for every sample and diverge towards infinity resulting in an unstable system. If we calibrate this problem will be reduced, but unfortunately the bias of the gyroscope tends to drift and therefore one needs to recalibrate if possible or find other heuristic methods in order to avoid an escalation of the error. Sensor fusion is suggested, which rely on the somewhat complex implementation of the Kalman filter, which may combine sensor inputs an re-estimate the most likely bias value while offering an indication of how much trust we may put in this value. A sensor fusion could be used to combine an accelerometer or inclinometer with the gyroscope, but it seems a bit ambitious to implement a Kalman solution given the scope of this project - also keeping in mind that there are many other areas of improvement that should be evaluated first.
+A gyroscope measures degrees per second or simply angle velocity and therefore we must use numerical integration in order to get the angle. A gyroscope has a bias which is simply an offset and naturally we want to eliminate this offset by calibration methods at the beginning of the program. If we do not calibrate, the integration, e.g. a running sum, will add the offset contribution for every sample and diverge resulting in an unstable system. If we calibrate the integral, this problem will be reduced, but unfortunately the bias of the gyroscope tends to drift and therefore one needs to recalibrate if possible or find other heuristic methods in order to avoid an escalation of the error. Sensor fusion is suggested, which rely on the somewhat complex implementation of the Kalman filter, which may combine sensor inputs an re-estimate the most likely bias value while offering an indication of how much trust we may put in this value. A sensor fusion could be used to combine an accelerometer or inclinometer with the gyroscope, but it seems a bit ambitious to implement a Kalman solution given the scope of this project - also keeping in mind that there are many other areas of improvement that should be evaluated first.
-In order to to a discrete integration we simply need to look at a simple recursive difference equation, which in this case will be a running sum. Recall The difference equations for simple first order derivatives and and a very simple integration \\
+In order to do a discrete integration we simply need to look at a simple recursive difference equation, which in this case will be a running sum. Recall the difference equations for simple first order derivatives and a very simple integration:\\
 Integration: <latex>y_n=x_n+y_{n-1}</latex><texit>$y_n=x_n+y_{n-1}$</texit>\\
-First Difference: <latex>y_n=x_n+x_{n-1}</latex><texit>$y_n=x_n+x_{n-1}$</texit>\\
+First difference: <latex>y_n=x_n+x_{n-1}</latex><texit>$y_n=x_n+x_{n-1}$</texit>\\
 Each sample in the output signal is a sum of weighted samples from the input. The reason for pointing out the first order derivative as well is that they (of course) are closely related which becomes clear in the illustration below. (([[http://www.dspguide.com/|DSP Guide]]))
 {{:marvin:projekt_lab1_3.png}}{{:marvin:projekt_lab1_4.png}}
-There are many types of algorithms for numerical integrations that are far more advanced and all of them or based on some kind of interpolation technique, but for now we will rely on the simplest form which is the running sum. As an alternative we will implement another solution known as the trapezoidal integration that utilizes a first order polynomial to interpolate between sampled values, hence forming a trapezoidal between every two samples. An illustration of this and further discussion on the topic may be found on wikipidea(([[http://en.wikipedia.org/wiki/Numerical integration|Numerical Integration]])). We will keep the trapezoidal implementation in order to do a comparison between the performance of two methods.
+There are many types of algorithms for numerical integrations that are far more advanced and all of them or based on some kind of interpolation technique, but for now we will rely on the simplest form which is the running sum.
 ====Programming====
@@ Line 106: / Line 102: @@
 {{ :marvin:gyroscopesensor.png?450 }}
-This class wraps the gyroscope sensor, and offers readouts as angle velocities, or as integrated angle velocities over time (angles).\\
+This class wraps the gyroscope sensor, and offers readouts as either angle velocities, or as integrated angle velocities over time (angles).\\
 The angle velocities can be read raw from the sensor port, but must be subtracted with an offset defining the stand-still gyroscope. This value is according to the documentation approximately 620, but may vary from gyroscope to gyroscope. We made some experiments and found the value 595.5 to be pretty accurate.\\
 This value is however not accurate enough when run over a large quantity of time, which will make the integration drift, thereby making Marvin unable to keep its balance.\\
 The solution was to use the measured value as an initial value, and then use a weighted average of all measured angles over time, where the last measured angle is weighted very low. We tested the solution with a variety of values, and found the value 0.999999 to be pretty good (one might think the having a static 595.5 might do the same, but experiments show otherwise).
-These constants are hardcoded into the program with the following names and values:
+These constants are hard coded into the program with the following names and values:
 ^ Variable   ^ Value    ^
@@ Line 116: / Line 112: @@
 | a          | 0.999999 |
-For the integration over time algorithm we use a simple sum multiplied by the delta time since last call. This delta time is acquired by calling the ''System.currentTimeMillis()'' method, which reports the number of milliseconds since the Brick has been turned on.
+For the integration over time algorithm we use a simple sum multiplied by the delta time since last call. This delta time is acquired by calling the ''System.currentTimeMillis()'' method, which reports the number of milliseconds since the NXT was been turned on.
 In the following excerpt from the ''GyroscopeSensor'' class can be seen the weighted average algorithm in the ''getAngleVelocity()'' method, and the integration over time algorithm in then ''getAngle()'' method.\\
@@ Line 158: / Line 154: @@
 </code>
 The full source code for this class can be found in the file ''GyroscopeSensor.java'' in the Marvin code tarball (([[http://wiki.aasimon.org/lib/exe/fetch.php?media=marvin:marvin-1.0.tar.gz|marvin-1.0.tar.gz]]))