Aasimon.org Wiki

User Tools

Site Tools

Trace:
marvin:ecp1

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
marvin:ecp1 [2009/01/29 00:43] – devamarvin:ecp1 [2009/01/29 11:03] (current) – rieper
Line 10: Line 10:
  
 =====Goal===== =====Goal=====
-Make robot able to communicate with gyroscope.+Make Marvin able to communicate with gyroscope.
  
 =====Plan===== =====Plan=====
Line 17: Line 17:
   * Find or create a class for the gyroscope communication.   * Find or create a class for the gyroscope communication.
  
-=====Analysis=====+=====Theory=====
  
  
-====Analogue to digital conversion and limitations====+====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 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. The gyroscope utilizes the ADC so that it is possible to get readings from the gyroscope.
Line 42: Line 42:
 The correct placement of the gyroscope can be seen in 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 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. 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 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. The finished robot can be seen in the picture below.
Line 84: Line 84:
  
 =====Implementation===== =====Implementation=====
 +
 ====Numerical Readings from the Gyroscope==== ====Numerical Readings from the Gyroscope====
 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.      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.     
Line 94: Line 95:
 {{:marvin:projekt_lab1_3.png}}{{:marvin:projekt_lab1_4.png}}  {{: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.
- +
-FIXME: trapezoidal integration ???+
  
 ====Programming==== ====Programming====
Line 155: Line 154:
 </code> </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]])) 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]]))
 +
marvin/ecp1.1233186210.txt.gz · Last modified: 2009/01/29 00:43 by deva