http://www.olliw.eu/storm32bgc-v1-wiki/api.php?action=feedcontributions&feedformat=atom&user=Bruce356 2026-04-28T21:33:06Z User contributions MediaWiki 1.43.3 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=I2C_Error_Compendium&diff=1998 2015-01-13T02:31:15Z

<p>Bruce356: </p> <hr /> <div>&lt;span style=&quot;font-size:88%&quot;&gt;''by OlliW&lt;/span&gt;''<br /> <br /> I2C errors are probably the most annoying side effect of the technology we are using in our brushless gimbals.<br /> <br /> I2C errors occur when the signals on the I2C clock and data lines (SCL,SDA) are disturbed beyond certain limits, and this happens for two main reasons:<br /> * capacitive load on the I2C clock and/or data lines<br /> * induced signal disturbances due to capacitive coupling to outside fields<br /> <br /> Importantly, all error sources add up. One therefore can't give decisive threshold values, for example, the length of the I2C wires should not be more than 40 cm long. Without any further error sources one might be able to use much longer wires, but if motor wires are too close to the IMU cabling then shorter wires might be required. <br /> <br /> It's like a glass of wine: When it's full, it's full. It doesn't matter whether it was filled with Bordeaux, Chianti, or any other mixture. When the glass contains only a tiny bit of Bordeaux, one can add a lot of Chianti before it overflows, but when the glass is nearly full of Bordeaux, only a tiny amount of Chianti will fit before it reaches the overflows point. So, its not possible to tell how much Chianti is acceptable, since this depends on how much Bordeaux is already in the glass, the only thing that can be determined is that the more Chianti you poor in the glass the more likely it will overflow.<br /> <br /> == Ways to Reduce the I2C Error Rate ==<br /> <br /> Before looking at the I2C errors, here is a brief summary to help reduce problems with the error-prone I2C connection to an IMU module:<br /> <br /> * reduce length of cable<br /> <br /> * increase spacing between I2C cables and motor wires<br /> <br /> * twist all wires where possible including the IMU cable(reduces Electromagnetic interference); for the IMU this can take several forms, such as twisting all four together, just twisting SCL and SDL, twisting SCL with GND and SDA with VCC etc.<br /> <br /> * shield the wires; using e.g. a coax cable or wrapping the wires with a self adhesive conductive cloth, &quot;EMI shielding&quot;<br /> <br /> * lower the (motor) voltage <br /> <br /> * add ferrite rings; these can be fitted in various ways, such as, putting the rings on the I2C wires and/or the motor wires, they can be fitted at either ends of the wires.<br /> <br /> * reduce the I2C pullup resistors on the IMU module e.g. to 1k<br /> <br /> == Capacitive Load ==<br /> <br /> Capacitive load decreases the slew rate of the signal, and eventually prevents the electronics from detecting the signal correctly, and an I2C error occurs.<br /> <br /> Capacitive load arises from the cables themselves, and the longer the cables are the higher the capacitive load becomes.<br /> <br /> Therefore, for any I2C system there is an &quot;intrinsic&quot; maximum length up to which the I2C communication will work. In practice this maximum length is not achieved, since, as mentioned in the introduction, other I2C error sources may be present reducing the practical length. The capacitive load of the IMU cable depends also on the type of cable. Thin wires for instance have a smaller capacity than thicker wires. In practice, however, there is usually little room to play with this factor. <br /> <br /> Capacitive load also arises from anything conducting in the near surrounding area of the I2C clock and/or data wires.<br /> <br /> This is indeed a major factor, and - fortunately - it is to a high degree under our control. The possible contributors falling into this category are very diverse; they range from things like spacing between the wires themselves or to GND or Vcc, shielding such as in coax wires, twisted or non-twisted wires and the manner in which they are twisted, conducting areas like metal bars or carbon plates to which the IMU module is mounted or the cables are fixed to, connectors, and so on. It is as it was mentioned, it can arise from '''''anything''''' that is conducting in the surrounding area. Fortunately, the rules which determine the value for capacitance are well known. In a nutshell, the larger the conducting area the larger the capacitance, and the further the distance from the conducting area the smaller the capacitance. This immediately gives us the necessary rules to control, and possibly avoid the problem.<br /> <br /> The acceptable capacitive load, from both the cables and the surrounding EMI, depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Induced Signal Disturbances ==<br /> <br /> Wires in close proximity to the I2C clock and data lines may, due to capacitive coupling, induce fault voltages in I2C lines and thus disrupt the I2C signals. This again may prevent the electronics from detecting the I2C signals correctly and therefore may bring it into an unexpected state causing I2C errors to occur. The I2C errors due to induced disturbances are often fatal in the sense that it can be difficult for the electronics to recover from these errors.<br /> <br /> For our gimbals, the primary origin of these interferences are from the motor wires. The motor wires carry high voltage signals, high in comparison to the circa 3 volts of the I2C signals, the motor wires are also pulsed with large slew rates. When these signals come close to the I2C lines, the motor wires can easily disturb the signals on the I2C lines.<br /> <br /> The strength of the induced disturbances depends on some additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Practical Implications ==<br /> <br /> Equipped with the understanding of the origin of the I2C errors, most of the counter measures listed in the above become obvious.<br /> <br /> Some can have both positive and negative effects. For instance, twisting the I2C wires or shielding them can be very successful in protecting the I2C signals from the induced disturbances of the motor wires, but on the other hand they also increase the capacitive load. Whether these counter measures work or not therefore depends on the particular situation, whether the &quot;induced disturbances&quot; or &quot;capacitive load&quot; are the dominating I2C error sources.<br /> <br /> Ferrite rings are very commonly used to suppress I2C errors. When placed on the motor wires they reduce the slew rate of the motor signals and thereby their ability to induce fault voltages in the I2C lines. When placed on the I2C lines they can compensate, to some degree, the capacitive load and thereby improve the I2C signal quality.<br /> <br /> The alert reader will have noticed that increasing the current in the I2C lines or decreasing the pullup resistors, respectively, helps to diminish both the effects of the capacitive load and induced voltage disturbances. This in fact helps quite considerably, and it is also a good idea to use small pullup resistors. One may wonder why not use really small pullup resistors instead of the typical 1k to 10k range. Well, the answer is that the current standard I2C drivers are not designed to handle currents larger than a few mA (and this in turn is also related to the way in which I2C works). Therefore if very small pullup resistors are used this may damage your electronics. Circuitry exists to create low-impedance I2C communications, but it is not used in our low-budget applications.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=I2C_Error_Compendium&diff=1997 2015-01-13T02:13:44Z

<p>Bruce356: </p> <hr /> <div>&lt;span style=&quot;font-size:88%&quot;&gt;''by OlliW&lt;/span&gt;''<br /> <br /> I2C errors are probably the most annoying side effect of the technology we are using in our brushless gimbals.<br /> <br /> I2C errors occur when the signals on the I2C clock and data lines (SCL,SDA) are disturbed beyond certain limits, and this happens for two main reasons:<br /> * capacitive load on the I2C clock and/or data lines<br /> * induced signal disturbances due to capacitive coupling to outside fields<br /> <br /> Importantly, all error sources add up. One therefore can't give decisive threshold values, for example, the length of the I2C wires should not be more than 40 cm long. Without any further error sources one might be able to use much longer wires, but if motor wires are too close to the IMU cabling then shorter wires might be required. <br /> <br /> It's like a glass of wine: When it's full, it's full. It doesn't matter whether it was filled with Bordeaux, Chianti, or any other mixture. When the glass contains only a tiny bit of Bordeaux, one can add a lot of Chianti before it overflows, but when the glass is nearly full of Bordeaux, only a tiny amount of Chianti will fit before it reaches the overflows point. So, its not possible to tell how much Chianti is acceptable, since this depends on how much Bordeaux is already in the glass, the only thing that can be determined is that the more Chianti you poor in the glass the more likely it will overflow.<br /> <br /> == Ways to Reduce the I2C Error Rate ==<br /> <br /> Before looking at the I2C errors, here is a brief summary to help reduce problems with the error-prone I2C connection to an IMU module:<br /> <br /> * reduce length of cable<br /> <br /> * increase spacing between I2C cables and motor wires<br /> <br /> * twist all wires where possible including the IMU cable(reduces Electromagnetic interference); for the IMU this can take several forms, such as twisting all four together, just twisting SCL and SDL, twisting SCL with GND and SDA with VCC etc.<br /> <br /> * shield the wires; using e.g. a coax cable or wrapping the wires with a self adhesive conductive cloth, &quot;EMI shielding&quot;<br /> <br /> * lower the (motor) voltage <br /> <br /> * add ferrite rings; these can be fitted in various ways, such as, putting the rings on the I2C wires and/or the motor wires, they can be fitted at either ends of the wires.<br /> <br /> * reduce the I2C pullup resistors on the IMU module e.g. to 1k<br /> <br /> == Capacitive Load ==<br /> <br /> Capacitive load decreases the slew rate of the signal, and eventually prevents the electronics from detecting the signal correctly, and an I2C error occurs.<br /> <br /> Capacitive load arises from the cables themselves, and the longer the cables are the higher the capacitive load becomes.<br /> <br /> Therefore, for any I2C system there is an &quot;intrinsic&quot; maximum length up to which the I2C communication will work. In practice this maximum length is not achieved, since, as mentioned in the introduction, other I2C error sources may be present reducing the practical length. The capacitive load of the IMU cable depends also on the type of cable. Thin wires for instance have a smaller capacity than thicker wires. In practice, however, there is usually little room to play with this factor. <br /> <br /> Capacitive load also arises from anything conducting in the near surrounding area of the I2C clock and/or data wires.<br /> <br /> This is indeed a major factor, and - fortunately - it is to a high degree under our control. The possible contributors falling into this category are very diverse; they range from things like spacing between the wires themselves or to GND or Vcc, shielding such as in coax wires, twisted or non-twisted wires and the manner in which they are twisted, conducting areas like metal bars or carbon plates to which the IMU module is mounted or the cables are fixed to, connectors, and so on. It is as it was mentioned, it can arise from '''''anything''''' that is conducting in the surrounding area. Fortunately, the rules which determine the value for capacitance are well known. In a nutshell, the larger the conducting area the larger the capacitance, and the further the distance from the conducting area the smaller the capacitance. This immediately gives us the necessary rules to control, and possibly avoid the problem.<br /> <br /> The acceptable capacitive load, from both the cables and the surrounding EMI, depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Induced Signal Disturbances ==<br /> <br /> Wires in the proximity to the I2C clock and data lines may, due to capacitive coupling, induce fault voltages in I2C lines and thus disrupt the I2C signals. This again may prevent the electronics from detecting the I2C signals correctly or even bring it into an unexpected state, and an I2C error occurs. The I2C errors due to induced disturbances are often fatal in the sense that it can be difficult for the electronics to recover from these errors.<br /> <br /> For our gimbals, the primary origin of these interferences are the motor wires. The motor wires carry high voltage signals, high in comparison to the circa 3 volts of the I2C signals, which moreover are pulsed with large slew rates. When these signals come close to the I2C lines, the motor wires can easily disturb the signals on the I2C lines.<br /> <br /> The strength of the induced disturbances depends on some additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Practical Implications ==<br /> <br /> Equipped with the understanding of the origin of the I2C errors, most of the counter measures listed in the above become obvious.<br /> <br /> Some can have both positive and negative effects. For instance, twisting the I2C wires or shielding them can be very successful in protecting the I2C signals from the induced disturbances of the motor wires, but on the other hand they also increase the capacitive load. Whether these counter measures work or not therefore depends on the particular situation, whether the &quot;induced disturbances&quot; or &quot;capacitive load&quot; are the dominating I2C error sources.<br /> <br /> Ferrite rings are very commonly used to suppress I2C errors. When placed on the motor wires they reduce the slew rate of the motor signals and thereby their ability to induce fault voltages in the I2C lines. When placed on the I2C lines they can compensate, to some degree, the capacitive load and thereby improve the I2C signal quality.<br /> <br /> The alert reader will have noticed that increasing the current in the I2C lines or decreasing the pullup resistors, respectively, helps to diminish both the effects of the capacitive load and induced voltage disturbances. This in fact helps quite a lot, and it is a good idea to use small pullup resistors. One may wonder why not use really small pullup resistors instead of the typical resistors in the 1 k to 10 k range. Well, the answer is that the current standard I2C drivers are not designed to handle currents larger than a few mA (and this in turn is also related to the way in which I2C works). Therefore if very small pullup resistors are used this may damage your electronics. Circuitry exists to create low-impedance I2C communications, but it is not used in our low-budget applications.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=I2C_Error_Compendium&diff=1996 2015-01-13T02:08:48Z

<p>Bruce356: </p> <hr /> <div>&lt;span style=&quot;font-size:88%&quot;&gt;''by OlliW&lt;/span&gt;''<br /> <br /> I2C errors are probably the most annoying side effect of the technology we are using in our brushless gimbals.<br /> <br /> I2C errors occur when the signals on the I2C clock and data lines (SCL,SDA) are disturbed beyond certain limits, and this happens for two main reasons:<br /> * capacitive load on the I2C clock and/or data lines<br /> * induced signal disturbances due to capacitive coupling to outside fields<br /> <br /> Importantly, all error sources add up. One therefore can't give decisive threshold values, for example, the length of the I2C wires should not be more than 40 cm long. Without any further error sources one might be able to use much longer wires, but if motor wires are too close to the IMU cabling then shorter wires might be required. <br /> <br /> It's like a glass of wine: When it's full, it's full. It doesn't matter whether it was filled with Bordeaux, Chianti, or any other mixture. When the glass contains only a tiny bit of Bordeaux, one can add a lot of Chianti before it overflows, but when the glass is nearly full of Bordeaux, only a tiny amount of Chianti will fit before it reaches the overflows point. So, its not possible to tell how much Chianti is acceptable, since this depends on how much Bordeaux is already in the glass, the only thing that can be determined is that the more Chianti you poor in the glass the more likely it will overflow.<br /> <br /> == Ways to Reduce the I2C Error Rate ==<br /> <br /> Before looking at the I2C errors, here is a brief summary to help reduce problems with the error-prone I2C connection to an IMU module:<br /> <br /> * reduce length of cable<br /> <br /> * increase spacing between I2C cables and motor wires<br /> <br /> * twist all wires where possible including the IMU cable(reduces Electromagnetic interference); for the IMU this can take several forms, such as twisting all four together, just twisting SCL and SDL, twisting SCL with GND and SDA with VCC etc.<br /> <br /> * shield the wires; using e.g. a coax cable or wrapping the wires with a self adhesive conductive cloth, &quot;EMI shielding&quot;<br /> <br /> * lower the (motor) voltage <br /> <br /> * add ferrite rings; these can be fitted in various ways, such as, putting the rings on the I2C wires and/or the motor wires, they can be fitted at either ends of the wires.<br /> <br /> * reduce the I2C pullup resistors on the IMU module e.g. to 1k<br /> <br /> == Capacitive Load ==<br /> <br /> Capacitive load decreases the slew rate of the signal, and eventually prevents the electronics from detecting the signal correctly, and an I2C error occurs.<br /> <br /> Capacitive load arises from the cables themselves, and the longer the cables are the higher the capacitive load becomes.<br /> <br /> Therefore, for any I2C system there is an &quot;intrinsic&quot; maximum length up to which the I2C communication will work. In practice this maximum length is not achieved, since, as mentioned in the introduction, other I2C error sources may be present reducing the practical length. The capacitive load of the IMU cable depends also on the type of cable. Thin wires for instance have a smaller capacity than thicker wires. In practice, however, there is usually little room to play with this factor. <br /> <br /> Capacitive load also arises from anything conducting in the near surrounding area of the I2C clock and/or data wires.<br /> <br /> This is indeed a major factor, and - fortunately - it is to a high degree under our control. The possible contributors falling into this category are very diverse; they range from things like spacing between the wires themselves or to GND or Vcc, shielding such as in coax wires, twisted or non-twisted wires and the manner in which they are twisted, conducting areas like metal bars or carbon plates to which the IMU module is mounted or the cables are fixed to, connectors, and so on. It is as it was mentioned, it can arise from '''''anything''''' that is conducting in the surrounding area. Fortunately, the rules which determine the value for capacitance are well known. In a nutshell, the larger the conducting area the larger the capacitance, and the further the distance to the conducting area the smaller the capacitance. This immediately gives us the rules at hand to control, and possibly avoid the problem.<br /> <br /> The acceptable capacitive load, from both the cables and the surrounding EMI, depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Induced Signal Disturbances ==<br /> <br /> Wires in the proximity to the I2C clock and data lines may, due to capacitive coupling, induce fault voltages in I2C lines and thus disrupt the I2C signals. This again may prevent the electronics from detecting the I2C signals correctly or even bring it into an unexpected state, and an I2C error occurs. The I2C errors due to induced disturbances are often fatal in the sense that it can be difficult for the electronics to recover from these errors.<br /> <br /> For our gimbals, the primary origin of these interferences are the motor wires. The motor wires carry high voltage signals, high in comparison to the circa 3 volts of the I2C signals, which moreover are pulsed with large slew rates. When these signals come close to the I2C lines, the motor wires can easily disturb the signals on the I2C lines.<br /> <br /> The strength of the induced disturbances depends on some additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Practical Implications ==<br /> <br /> Equipped with the understanding of the origin of the I2C errors, most of the counter measures listed in the above become obvious.<br /> <br /> Some can have both positive and negative effects. For instance, twisting the I2C wires or shielding them can be very successful in protecting the I2C signals from the induced disturbances of the motor wires, but on the other hand they also increase the capacitive load. Whether these counter measures work or not therefore depends on the particular situation, whether the &quot;induced disturbances&quot; or &quot;capacitive load&quot; are the dominating I2C error sources.<br /> <br /> Ferrite rings are very commonly used to suppress I2C errors. When placed on the motor wires they reduce the slew rate of the motor signals and thereby their ability to induce fault voltages in the I2C lines. When placed on the I2C lines they can compensate, to some degree, the capacitive load and thereby improve the I2C signal quality.<br /> <br /> The alert reader will have noticed that increasing the current in the I2C lines or decreasing the pullup resistors, respectively, helps to diminish both the effects of the capacitive load and induced voltage disturbances. This in fact helps quite a lot, and it is a good idea to use small pullup resistors. One may wonder why not use really small pullup resistors instead of the typical resistors in the 1 k to 10 k range. Well, the answer is that the current standard I2C drivers are not designed to handle currents larger than a few mA (and this in turn is also related to the way in which I2C works). Therefore if very small pullup resistors are used this may damage your electronics. Circuitry exists to create low-impedance I2C communications, but it is not used in our low-budget applications.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=I2C_Error_Compendium&diff=1995 2015-01-13T02:03:43Z

<p>Bruce356: </p> <hr /> <div>&lt;span style=&quot;font-size:88%&quot;&gt;''by OlliW&lt;/span&gt;''<br /> <br /> I2C errors are probably the most annoying side effect of the technology we are using in our brushless gimbals.<br /> <br /> I2C errors occur when the signals on the I2C clock and data lines (SCL,SDA) are disturbed beyond certain limits, and this happens for two main reasons:<br /> * capacitive load on the I2C clock and/or data lines<br /> * induced signal disturbances due to capacitive coupling to outside fields<br /> <br /> Importantly, all error sources add up. One therefore can't give decisive threshold values, for example, the length of the I2C wires should not be more than 40 cm long. Without any further error sources one might be able to use much longer wires, but if motor wires are too close to the IMU cabling then shorter wires might be required. <br /> <br /> It's like a glass of wine: When it's full, it's full. It doesn't matter whether it was filled with Bordeaux, Chianti, or any other mixture. When the glass contains only a tiny bit of Bordeaux, one can add a lot of Chianti before it overflows, but when the glass is nearly full of Bordeaux, only a tiny amount of Chianti will fit before it reaches the overflows point. So, its not possible to tell how much Chianti is acceptable, since this depends on how much Bordeaux is already in the glass, the only thing that can be determined is that the more Chianti you poor in the glass the more likely it will overflow.<br /> <br /> == Ways to Reduce the I2C Error Rate ==<br /> <br /> Before looking at the I2C errors, here is a brief summary to help reduce problems with the error-prone I2C connection to an IMU module:<br /> <br /> * reduce length of cable<br /> <br /> * increase spacing between I2C cables and motor wires<br /> <br /> * twist all wires where possible including the IMU cable(reduces Electromagnetic interference); for the IMU this can take several forms, such as twisting all four together, just twisting SCL and SDL, twisting SCL with GND and SDA with VCC etc.<br /> <br /> * shield the wires; using e.g. a coax cable or wrapping the wires with a self adhesive conductive cloth, &quot;EMI shielding&quot;<br /> <br /> * lower the (motor) voltage <br /> <br /> * add ferrite rings; these can be fitted in various ways, such as, putting the rings on the I2C wires and/or the motor wires, they can be fitted at either ends of the wires.<br /> <br /> * reduce the I2C pullup resistors on the IMU module e.g. to 1k<br /> <br /> == Capacitive Load ==<br /> <br /> Capacitive load decreases the slew rate of the signal, and eventually prevents the electronics from detecting the signal correctly, and an I2C error occurs.<br /> <br /> Capacitive load arises from the cables themselves, and the longer the cables are the higher the capacitive load becomes.<br /> <br /> Therefore, for any I2C system there is an &quot;intrinsic&quot; maximum length up to which the I2C communication will work. In practice this maximum length is not achieved, since, as mentioned in the introduction, other I2C error sources may be present reducing the practical length. The capacitive load of the IMU cable depends also on the type of cable. Thin wires for instance have a smaller capacity than thicker wires. In practice, however, there is usually little room to play with this factor. <br /> <br /> Capacitive load also arises from anything conducting in the near surrounding of the I2C clock and/or data wires.<br /> <br /> This is indeed a major factor, and - fortunately - it is to a high degree under our control. The possible contributors falling into this category are very diverse; they range from things like spacing between the wires themselves or to GND or Vcc, shielding such as in coax wires, twisted or non-twisted wires and the manner in which they are twisted, conducting areas like metal bars or carbon plates to which the IMU module is mounted or the cables are fixed to, connectors, and so on. It is as it was mentioned, it can arise from '''''anything''''' that is conducting in the surrounding area. Fortunately, the rules which determine the value for capacitance are well known. In a nutshell, the larger the conducting area the larger the capacitance, and the further the distance to the conducting area the smaller the capacitance. This immediately gives us the rules at hand to control, and possibly avoid the problem.<br /> <br /> The acceptable capacitive load, from both the cables and the surrounding EMI, depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Induced Signal Disturbances ==<br /> <br /> Wires in the proximity to the I2C clock and data lines may, due to capacitive coupling, induce fault voltages in I2C lines and thus disrupt the I2C signals. This again may prevent the electronics from detecting the I2C signals correctly or even bring it into an unexpected state, and an I2C error occurs. The I2C errors due to induced disturbances are often fatal in the sense that it can be difficult for the electronics to recover from these errors.<br /> <br /> For our gimbals, the primary origin of these interferences are the motor wires. The motor wires carry high voltage signals, high in comparison to the circa 3 volts of the I2C signals, which moreover are pulsed with large slew rates. When these signals come close to the I2C lines, the motor wires can easily disturb the signals on the I2C lines.<br /> <br /> The strength of the induced disturbances depends on some additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Practical Implications ==<br /> <br /> Equipped with the understanding of the origin of the I2C errors, most of the counter measures listed in the above become obvious.<br /> <br /> Some can have both positive and negative effects. For instance, twisting the I2C wires or shielding them can be very successful in protecting the I2C signals from the induced disturbances of the motor wires, but on the other hand they also increase the capacitive load. Whether these counter measures work or not therefore depends on the particular situation, whether the &quot;induced disturbances&quot; or &quot;capacitive load&quot; are the dominating I2C error sources.<br /> <br /> Ferrite rings are very commonly used to suppress I2C errors. When placed on the motor wires they reduce the slew rate of the motor signals and thereby their ability to induce fault voltages in the I2C lines. When placed on the I2C lines they can compensate, to some degree, the capacitive load and thereby improve the I2C signal quality.<br /> <br /> The alert reader will have noticed that increasing the current in the I2C lines or decreasing the pullup resistors, respectively, helps to diminish both the effects of the capacitive load and induced voltage disturbances. This in fact helps quite a lot, and it is a good idea to use small pullup resistors. One may wonder why not use really small pullup resistors instead of the typical resistors in the 1 k to 10 k range. Well, the answer is that the current standard I2C drivers are not designed to handle currents larger than a few mA (and this in turn is also related to the way in which I2C works). Therefore if very small pullup resistors are used this may damage your electronics. Circuitry exists to create low-impedance I2C communications, but it is not used in our low-budget applications.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=I2C_Error_Compendium&diff=1994 2015-01-13T01:59:25Z

<p>Bruce356: </p> <hr /> <div>&lt;span style=&quot;font-size:88%&quot;&gt;''by OlliW&lt;/span&gt;''<br /> <br /> I2C errors are probably the most annoying side effect of the technology we are using in our brushless gimbals.<br /> <br /> I2C errors occur when the signals on the I2C clock and data lines (SCL,SDA) are disturbed beyond certain limits, and this happens for two main reasons:<br /> * capacitive load on the I2C clock and/or data lines<br /> * induced signal disturbances due to capacitive coupling to outside fields<br /> <br /> Importantly, all error sources add up. One therefore can't give decisive threshold values, for example, the length of the I2C wires should not be more than 40 cm long. Without any further error sources one might be able to use much longer wires, but if motor wires are too close to the IMU cabling then shorter wires might be required. <br /> <br /> It's like a glass of wine: When it's full, it's full. It doesn't matter whether it was filled with Bordeaux, Chianti, or any other mixture. When the glass is filled with only a tiny bit of Bordeaux, one can add a lot of Chianti before it overflows, but when the glass is nearly full of Bordeaux, only a tiny drop of Chianti will fit before it reaches the overflows point. So, its not possible to tell how much Chianti is acceptable, since this depends on how much Bordeaux is already in the glass, the only thing that can be determined is that the more Chianti you poor in the glass the more likely it will overflow.<br /> <br /> == Ways to Reduce the I2C Error Rate ==<br /> <br /> Before looking at the I2C errors, here is a brief summary to help reduce problems with the error-prone I2C connection to an IMU module:<br /> <br /> * reduce length of cable<br /> <br /> * increase spacing between I2C cables and motor wires<br /> <br /> * twist all wires where possible including the IMU cable(reduces Electromagnetic interference); for the IMU this can take several forms, such as twisting all four together, just twisting SCL and SDL, twisting SCL with GND and SDA with VCC etc.<br /> <br /> * shield the wires; using e.g. a coax cable or wrapping the wires with a self adhesive conductive cloth, &quot;EMI shielding&quot;<br /> <br /> * lower the (motor) voltage <br /> <br /> * add ferrite rings; these can be fitted in various ways, such as, putting the rings on the I2C wires and/or the motor wires, they can be fitted at either ends of the wires.<br /> <br /> * reduce the I2C pullup resistors on the IMU module e.g. to 1k<br /> <br /> == Capacitive Load ==<br /> <br /> Capacitive load decreases the slew rate of the signal, and eventually prevents the electronics from detecting the signal correctly, and an I2C error occurs.<br /> <br /> Capacitive load arises from the cables themselves, and the longer the cables are the higher the capacitive load becomes.<br /> <br /> Therefore, for any I2C system there is an &quot;intrinsic&quot; maximum length up to which the I2C communication will work. In practice this maximum length is not achieved, since, as mentioned in the introduction, other I2C error sources may be present reducing the practical length. The capacitive load of the IMU cable depends also on the type of cable. Thin wires for instance have a smaller capacity than thicker wires. In practice, however, there is usually little room to play with this factor. <br /> <br /> Capacitive load also arises from anything conducting in the near surrounding of the I2C clock and/or data wires.<br /> <br /> This is indeed a major factor, and - fortunately - it is to a high degree under our control. The possible contributors falling into this category are very diverse; they range from things like spacing between the wires themselves or to GND or Vcc, shielding such as in coax wires, twisted or non-twisted wires and the manner in which they are twisted, conducting areas like metal bars or carbon plates to which the IMU module is mounted or the cables are fixed to, connectors, and so on. It is as it was mentioned, it can arise from '''''anything''''' that is conducting in the surrounding area. Fortunately, the rules which determine the value for capacitance are well known. In a nutshell, the larger the conducting area the larger the capacitance, and the further the distance to the conducting area the smaller the capacitance. This immediately gives us the rules at hand to control, and possibly avoid the problem.<br /> <br /> The acceptable capacitive load, from both the cables and the surrounding EMI, depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Induced Signal Disturbances ==<br /> <br /> Wires in the proximity to the I2C clock and data lines may, due to capacitive coupling, induce fault voltages in I2C lines and thus disrupt the I2C signals. This again may prevent the electronics from detecting the I2C signals correctly or even bring it into an unexpected state, and an I2C error occurs. The I2C errors due to induced disturbances are often fatal in the sense that it can be difficult for the electronics to recover from these errors.<br /> <br /> For our gimbals, the primary origin of these interferences are the motor wires. The motor wires carry high voltage signals, high in comparison to the circa 3 volts of the I2C signals, which moreover are pulsed with large slew rates. When these signals come close to the I2C lines, the motor wires can easily disturb the signals on the I2C lines.<br /> <br /> The strength of the induced disturbances depends on some additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Practical Implications ==<br /> <br /> Equipped with the understanding of the origin of the I2C errors, most of the counter measures listed in the above become obvious.<br /> <br /> Some can have both positive and negative effects. For instance, twisting the I2C wires or shielding them can be very successful in protecting the I2C signals from the induced disturbances of the motor wires, but on the other hand they also increase the capacitive load. Whether these counter measures work or not therefore depends on the particular situation, whether the &quot;induced disturbances&quot; or &quot;capacitive load&quot; are the dominating I2C error sources.<br /> <br /> Ferrite rings are very commonly used to suppress I2C errors. When placed on the motor wires they reduce the slew rate of the motor signals and thereby their ability to induce fault voltages in the I2C lines. When placed on the I2C lines they can compensate, to some degree, the capacitive load and thereby improve the I2C signal quality.<br /> <br /> The alert reader will have noticed that increasing the current in the I2C lines or decreasing the pullup resistors, respectively, helps to diminish both the effects of the capacitive load and induced voltage disturbances. This in fact helps quite a lot, and it is a good idea to use small pullup resistors. One may wonder why not use really small pullup resistors instead of the typical resistors in the 1 k to 10 k range. Well, the answer is that the current standard I2C drivers are not designed to handle currents larger than a few mA (and this in turn is also related to the way in which I2C works). Therefore if very small pullup resistors are used this may damage your electronics. Circuitry exists to create low-impedance I2C communications, but it is not used in our low-budget applications.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=I2C_Error_Compendium&diff=1993 2015-01-13T01:38:30Z

<p>Bruce356: </p> <hr /> <div>&lt;span style=&quot;font-size:88%&quot;&gt;''by OlliW&lt;/span&gt;''<br /> <br /> I2C errors are probably the most annoying side effect of the technology we are using in our brushless gimbals.<br /> <br /> I2C errors occur when the signals on the I2C clock and data lines (SCL,SDA) are disturbed beyond certain limits, and this happens for two main reasons:<br /> * capacitive load on the I2C clock and/or data lines<br /> * induced signal disturbances due to capacitive coupling to outside fields<br /> <br /> Importantly, all error sources add up. One therefore can't give decisive threshold values, for example, the length of the I2C wires should not be more than 40 cm long. Without any further error sources one might be able to use much longer wires, but if motor wires are too close to the IMU cabling then shorter wires might be required. <br /> <br /> It's like a glass of wine: When it's full, it's full. It doesn't matter whether it was filled with Bordeaux, Chianti, or any other mixture. When the glass is filled with only a tiny bit of Bordeaux, one can add a lot of Chianti before it overflows, but when the glass is nearly full of Bordeaux, only a tiny drop of Chianti will fit before it reaches the overflows point. So, its not possible to tell how much Chianti is acceptable, since this depends on how much Bordeaux is already in the glass, the only thing that can be determined is that the more Chianti you poor in the glass the more likely it will overflow.<br /> <br /> == Ways to Reduce the I2C Error Rate ==<br /> <br /> Before looking at the I2C errors, here is a brief summary to help reduce problems with the error-prone I2C connection to an IMU module:<br /> <br /> * reduce length of cable<br /> <br /> * increase spacing between I2C cables and motor wires<br /> <br /> * twist all wires where possible including the IMU cable(reduces Electromagnetic interference); for the IMU this can take several forms, such as twisting all four together, just twisting SCL and SDL, twisting SCL with GND and SDA with VCC etc.<br /> <br /> * shield the wires; using e.g. a coax cable or wrapping the wires with a self adhesive conductive cloth, &quot;EMI shielding&quot;<br /> <br /> * lower the (motor) voltage <br /> <br /> * add ferrite rings; these can be fitted in various ways, such as, putting the rings on the I2C wires and/or the motor wires, they can be fitted at either ends of the wires.<br /> <br /> * reduce the I2C pullup resistors on the IMU module e.g. to 1k<br /> <br /> == Capacitive Load ==<br /> <br /> Capacitive load decreases the slew rate of the signal, and eventually prevents the electronics from detecting the signal correctly, and an I2C error occurs.<br /> <br /> Capacitive load arises from the cables themselves, and the longer the cables are the higher the capacitive load becomes.<br /> <br /> Therefore, for any I2C system there is an &quot;intrinsic&quot; maximum length up to which the I2C communication will work. In practice this maximum length is not achieved, since, as mentioned in the introduction, other I2C error sources may be present reducing the practical length. The capacitive load of the IMU cable depends also on the type of cable. Thin wires for instance have a smaller capacity than thicker wires. In practice, however, there is usually little room to play with this factor. <br /> <br /> Capacitive load also arises from anything conducting in the near surrounding of the I2C clock and/or data wires.<br /> <br /> This is indeed a major factor, and - fortunately - it is to a high degree under our control. The possible contributors falling into this category are very diverse; they range from things like spacing between the wires themselves or to GND or Vcc, shielding such as in coax wires, twisted or non-twisted wires and the manner in which they are twisted, conducting areas like metal bars or carbon plates to which the IMU module is mounted or the cables are fixed to, connectors, and so on. It is as it was mentioned, it can arise from '''''anything''''' that is conducting in the surrounding area. Fortunately, the rules which determine the value for capacitance are well known. In a nutshell, the larger the conducting area the larger the capacitance, and the further the distance to the conducting area the smaller the capacitance. This immediately gives us the rules at hand to control, and possibly avoid the problem.<br /> <br /> The acceptable capacitive load, from both the cables and the surrounding EMI, depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Induced Signal Disturbances ==<br /> <br /> Wires in the proximity to the I2C clock and data lines may, due to capacitive coupling, induce fault voltages in I2C lines and thus disrupt the I2C signals. This again may prevent the electronics from detecting the I2C signals correctly or even bring it into an unexpected state, and an I2C error occurs. The I2C errors due to induced disturbances are often fatal in the sense that it can be difficult for the electronics to recover from these errors.<br /> <br /> For our gimbals, the primary origin of these disturbances is the motor wires. The motor wires carry high voltage signals, high in comparison to the ca. 3 V of the I2C signals, which moreover are pulsed with large slew rates. When they come close to the I2C lines, the motor wires can easily disturb the signals on the I2C lines.<br /> <br /> The strength of the induced disturbances depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Practical Implications ==<br /> <br /> Equipped with that understanding of the origin of the I2C errors, most of the counter measures listed in the above become obvious now.<br /> <br /> Some of them can have both positive and negative effects. For instance, twisting the I2C wires or shielding them can be very successful in protecting the I2C signals from the induced disturbances by the motor wires, but on the other hand they also increase the capacitive load. Whether these counter measures work or not hence depends on the particular situation, if induced disturbances or capacitive load are the dominating I2C error sources.<br /> <br /> Ferrite rings are very commonly used to suppress I2C errors. When placed on the motor wires they reduce the slew rate of the motor signals and whereby their ability to induce fault voltages in the I2C lines. When placed on the I2C lines they can compensate, to some extend, the capacitive load and thereby improve the I2C signal quality.<br /> <br /> The alert reader has noticed that increasing the currents in the I2C lines or decreasing the pullup resistors, respectively, helps to diminish both the effects of the capacitive load and induced voltage disturbances. This in fact helps very well, and it is a good idea to use small pullup resistors. One may wonder why not to use really small pullup resistors instead of the typical resistors in the 1 k - 10 k range. Well, the answer is that the standard I2C current drivers are not designed to handle currents larger than a few mA (and this in turn is of course related to the way I2C works). So, too small pullup resistors may damage your electronics. Circuitry exists to create low-impedance I2C communications, but it is not used in our low-budget applications.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=I2C_Error_Compendium&diff=1992 2015-01-13T01:15:36Z

<p>Bruce356: </p> <hr /> <div>&lt;span style=&quot;font-size:88%&quot;&gt;''by OlliW&lt;/span&gt;''<br /> <br /> I2C errors are probably the most annoying side effect of the technology we are using in our brushless gimbals.<br /> <br /> I2C errors occur when the signals on the I2C clock and data lines (SCL,SDA) are disturbed beyond certain limits, and this happens for two main reasons:<br /> * capacitive load on the I2C clock and/or data lines<br /> * induced signal disturbances due to capacitive coupling to outside fields<br /> <br /> Importantly, all error sources add up. One therefore can't give decisive threshold values, for example, the length of the I2C wires should not be more than 40 cm long. Without any further error sources one might be able to use much longer wires, but if motor wires are too close to the IMU cabling then shorter wires might be required. <br /> <br /> It's like a glass of wine: When it's full, it's full. It doesn't matter whether it was filled with Bordeaux, Chianti, or any other mixture. When the glass is filled with only a tiny bit of Bordeaux, one can add a lot of Chianti before it overflows, but when the glass is nearly full of Bordeaux, only a tiny drop of Chianti will fit before it reaches the overflows point. So, its not possible to tell how much Chianti is acceptable, since this depends on how much Bordeaux is already in the glass, the only thing that can be determined is that the more Chianti you poor in the glass the more likely it will overflow.<br /> <br /> == Ways to Reduce the I2C Error Rate ==<br /> <br /> Before looking at the I2C errors, here is a brief summary to help reduce problems with the error-prone I2C connection to an IMU module:<br /> <br /> * reduce length of cable<br /> <br /> * increase spacing between I2C cables and motor wires<br /> <br /> * twist all wires where possible including the IMU cable(reduces Electromagnetic interference); for the IMU this can take several forms, such as twisting all four together, just twisting SCL and SDL, twisting SCL with GND and SDA with VCC etc.<br /> <br /> * shield the wires; using e.g. a coax cable or wrapping the wires with a self adhesive conductive cloth, &quot;EMI shielding&quot;<br /> <br /> * lower the (motor) voltage <br /> <br /> * add ferrite rings; these can be fitted in various ways, such as, putting the rings on the I2C wires and/or the motor wires, they can be fitted at either ends of the wires.<br /> <br /> * reduce the I2C pullup resistors on the IMU module e.g. to 1k<br /> <br /> == Capacitive Load ==<br /> <br /> Capacitive load decreases the slew rate of the signal, and eventually prevents the electronics from detecting the signal correctly, and an I2C error occurs.<br /> <br /> Capacitive load arises from the cables themselves, and the longer the cables are the higher the capacitive load becomes.<br /> <br /> Therefore, for any I2C system there is an &quot;intrinsic&quot; maximum length up to which the I2C communication will work. In practice this maximal length is not achieved, since, as discussed in the introduction, other I2C error source may be present, reducing the practical length. The capacitive load by the cables depends also on the type of cables. Thin wires for instance have a smaller capacity than thicker wires. In practice, however, there is usually little room to play with that factor. <br /> <br /> Capacitive load also arises from anything conducting in the surrounding of the I2C clock and/or data wires.<br /> <br /> That's indeed a major factor, and - fortunately - it is under our control to a high degree. The possible contributors falling into this category are very diverse; they range from things such as spacing between the wires among themselves or to GND or Vcc, shielding such as in coax wires, twisted or non-twisted wires and how they are twisted, conducting areas like metal bars or carbon plates to which the IMU module is mounted or the cables are fixed to, connectors, and so on. It is as it was said, it arises from '''''anything''''' conducting in the surrounding. Fortunately, the rules which determine the value of capacitors are well known. In a nutshell, the larger the conducting area the larger the capacitance, and the larger the distance to the conducting area the smaller the capacitance. This immediately gives us the rules at hand to control, and possibly avoid them.<br /> <br /> The acceptable capacitive load, from both the cables and the surrounding, depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Induced Signal Disturbances ==<br /> <br /> Wires in the proximity to the I2C clock and data lines may, due to capacitive coupling, induce fault voltages in I2C lines and thus disturb the I2C signals. This again may prevent the electronics to detect the I2C signals correctly or even bring it into an unexpected state, and an I2C error occurs. The I2C errors due to induced disturbances are often fatal in the sense that it can be hard for the electronics to recover properly from them.<br /> <br /> For our gimbals, the primary origin of these disturbances is the motor wires. The motor wires carry high voltage signals, high in comparison to the ca. 3 V of the I2C signals, which moreover are pulsed with large slew rates. When they come close to the I2C lines, the motor wires can easily disturb the signals on the I2C lines.<br /> <br /> The strength of the induced disturbances depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Practical Implications ==<br /> <br /> Equipped with that understanding of the origin of the I2C errors, most of the counter measures listed in the above become obvious now.<br /> <br /> Some of them can have both positive and negative effects. For instance, twisting the I2C wires or shielding them can be very successful in protecting the I2C signals from the induced disturbances by the motor wires, but on the other hand they also increase the capacitive load. Whether these counter measures work or not hence depends on the particular situation, if induced disturbances or capacitive load are the dominating I2C error sources.<br /> <br /> Ferrite rings are very commonly used to suppress I2C errors. When placed on the motor wires they reduce the slew rate of the motor signals and whereby their ability to induce fault voltages in the I2C lines. When placed on the I2C lines they can compensate, to some extend, the capacitive load and thereby improve the I2C signal quality.<br /> <br /> The alert reader has noticed that increasing the currents in the I2C lines or decreasing the pullup resistors, respectively, helps to diminish both the effects of the capacitive load and induced voltage disturbances. This in fact helps very well, and it is a good idea to use small pullup resistors. One may wonder why not to use really small pullup resistors instead of the typical resistors in the 1 k - 10 k range. Well, the answer is that the standard I2C current drivers are not designed to handle currents larger than a few mA (and this in turn is of course related to the way I2C works). So, too small pullup resistors may damage your electronics. Circuitry exists to create low-impedance I2C communications, but it is not used in our low-budget applications.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=I2C_Error_Compendium&diff=1990 2015-01-12T14:33:31Z

<p>Bruce356: </p> <hr /> <div>&lt;span style=&quot;font-size:88%&quot;&gt;''by OlliW&lt;/span&gt;''<br /> <br /> I2C errors are probably the most annoying side effect of the technology we are using in our brushless gimbals.<br /> <br /> I2C errors occur when the signals on the I2C clock and data lines (SCL,SDA) are disturbed beyond certain limits, and this happens for two main reasons:<br /> * capacitive load on the I2C clock and/or data lines<br /> * induced signal disturbances due to capacitive coupling to outside fields<br /> <br /> Importantly, all error sources add up. One therefore can't give decisive threshold values, for example, the length of the I2C wires should not be more than 40 cm long. Without any further error sources one might be able to use much longer wires, but if motor wires are too close to the IMU cabling then shorter wires might be required. <br /> <br /> It's like a glass of wine: When it's full, it's full. It doesn't matter whether it was filled with Bordeaux, Chianti, or any other mixture. When the glass is filled with only a tiny bit of Bordeaux, one can add a lot of Chianti before it overflows, but when the glass is nearly full of Bordeaux, only a tiny drop of Chianti will fit before it reaches the overflows point. So, its not possible to tell how much Chianti is acceptable, since this depends on how much Bordeaux is already in the glass, the only thing that can be determined is that the more Chianti you poor in the glass the more likely it will overflow.<br /> <br /> == Ways to Reduce the I2C Error Rate ==<br /> <br /> Before looking at the I2C errors, here is a brief summary to help reduce problems with the error-prone I2C connection to an IMU module:<br /> <br /> * reduce length of cable<br /> <br /> * increase spacing between I2C cables and motor wires<br /> <br /> * twist wires of the IMU cable; this can take several variations, such as twisting all four together, just twisting SCL and SDL, twisting SCL with GND and SDA with VCC etc.<br /> <br /> * shield the wires; using e.g. a coax cable or wrapping the wires with (self adhesive) conductive cloth, EMI shielding<br /> <br /> * lower the (motor) voltage <br /> <br /> * remove multiple connectors<br /> <br /> * add ferrite rings; these can be fitted in various ways, such as, put the rings on the I2C wires and/or the motor wires, or to either ends of the wires etc.<br /> <br /> * reduce the I2C pullup resistors on the IMU module e.g. to 1k<br /> <br /> == Capacitive Load ==<br /> <br /> Capacitive load decreases the slew rate of the signal, and eventually prevents the electronics to detect it correctly, and an I2C error occurs.<br /> <br /> Capacitive load arises from the cables itself, and the longer the cables are the higher is the capacitive load.<br /> <br /> Thus, for any I2C system there is an &quot;intrinsic&quot; maximal length up to which the I2C communication works. In practice this maximal length is not achieved, since, as discussed in the introduction, other I2C error source may be present, reducing the practical length. The capacitive load by the cables depends also on the type of cables. Thin wires for instance have a smaller capacity than thicker wires. In practice, however, there is usually little room to play with that factor. <br /> <br /> Capacitive load also arises from anything conducting in the surrounding of the I2C clock and/or data wires.<br /> <br /> That's indeed a major factor, and - fortunately - it is under our control to a high degree. The possible contributors falling into this category are very diverse; they range from things such as spacing between the wires among themselves or to GND or Vcc, shielding such as in coax wires, twisted or non-twisted wires and how they are twisted, conducting areas like metal bars or carbon plates to which the IMU module is mounted or the cables are fixed to, connectors, and so on. It is as it was said, it arises from '''''anything''''' conducting in the surrounding. Fortunately, the rules which determine the value of capacitors are well known. In a nutshell, the larger the conducting area the larger the capacitance, and the larger the distance to the conducting area the smaller the capacitance. This immediately gives us the rules at hand to control, and possibly avoid them.<br /> <br /> The acceptable capacitive load, from both the cables and the surrounding, depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Induced Signal Disturbances ==<br /> <br /> Wires in the proximity to the I2C clock and data lines may, due to capacitive coupling, induce fault voltages in I2C lines and thus disturb the I2C signals. This again may prevent the electronics to detect the I2C signals correctly or even bring it into an unexpected state, and an I2C error occurs. The I2C errors due to induced disturbances are often fatal in the sense that it can be hard for the electronics to recover properly from them.<br /> <br /> For our gimbals, the primary origin of these disturbances is the motor wires. The motor wires carry high voltage signals, high in comparison to the ca. 3 V of the I2C signals, which moreover are pulsed with large slew rates. When they come close to the I2C lines, the motor wires can easily disturb the signals on the I2C lines.<br /> <br /> The strength of the induced disturbances depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Practical Implications ==<br /> <br /> Equipped with that understanding of the origin of the I2C errors, most of the counter measures listed in the above become obvious now.<br /> <br /> Some of them can have both positive and negative effects. For instance, twisting the I2C wires or shielding them can be very successful in protecting the I2C signals from the induced disturbances by the motor wires, but on the other hand they also increase the capacitive load. Whether these counter measures work or not hence depends on the particular situation, if induced disturbances or capacitive load are the dominating I2C error sources.<br /> <br /> Ferrite rings are very commonly used to suppress I2C errors. When placed on the motor wires they reduce the slew rate of the motor signals and whereby their ability to induce fault voltages in the I2C lines. When placed on the I2C lines they can compensate, to some extend, the capacitive load and thereby improve the I2C signal quality.<br /> <br /> The alert reader has noticed that increasing the currents in the I2C lines or decreasing the pullup resistors, respectively, helps to diminish both the effects of the capacitive load and induced voltage disturbances. This in fact helps very well, and it is a good idea to use small pullup resistors. One may wonder why not to use really small pullup resistors instead of the typical resistors in the 1 k - 10 k range. Well, the answer is that the standard I2C current drivers are not designed to handle currents larger than a few mA (and this in turn is of course related to the way I2C works). So, too small pullup resistors may damage your electronics. Circuitry exists to create low-impedance I2C communications, but it is not used in our low-budget applications.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=I2C_Error_Compendium&diff=1989 2015-01-12T14:26:51Z

<p>Bruce356: </p> <hr /> <div>&lt;span style=&quot;font-size:88%&quot;&gt;''by OlliW&lt;/span&gt;''<br /> <br /> I2C errors are probably the most annoying side effect of the technology we are using in our brushless gimbals.<br /> <br /> I2C errors occur when the signals on the I2C clock and data lines (SCL,SDA) are disturbed beyond certain limits, and this happens for two main reasons:<br /> * capacitive load on the I2C clock and/or data lines<br /> * induced signal disturbances due to capacitive coupling to outside fields<br /> <br /> Importantly, all error sources add up. One hence can't give decisive threshold values, for example, that the length of the I2C wires should not be more than 40 cm long. Without any further error sources one might be able to use much longer wires, but if for example motor wires are nearby then shorter wires might be required. <br /> <br /> It's like a glass of wine: When it's full, it's full. It doesn't matter whether it was filled with Bordeaux, Chianti, or any other mixture. When the glass is filled with e.g. only a tiny bit of Bordeaux, one can add a lot of Chianti or something else before it overflows, but when the glass is nearly full of Bordeaux, only a tiny drop of Chianti will fit before it reaches the overflows point. So, its not possible to tell how much Chianti is acceptable, since this depends on how much Bordeaux is already in the glass, the only thing that can be determined is that the more Chianti you poor in the glass the more probable it is that it will overflow.<br /> <br /> == Ways to Reduce the I2C Error Rate ==<br /> <br /> Before looking at the I2C errors, here is a brief summary to help reduce problems with the error-prone I2C connection to an IMU module:<br /> <br /> * reduce length of cable<br /> <br /> * increase spacing between I2C cables and motor wires<br /> <br /> * twist wires of the IMU cable; this can take several variations, such as twisting all four together, just twisting SCL and SDL, twisting SCL with GND and SDA with VCC etc.<br /> <br /> * shield the wires; using e.g. a coax cable or wrapping the wires with (self adhesive) conductive cloth, EMI shielding<br /> <br /> * lower the (motor) voltage <br /> <br /> * remove multiple connectors<br /> <br /> * add ferrite rings; these can be fitted in various ways, such as, put the rings on the I2C wires and/or the motor wires, or to either ends of the wires etc.<br /> <br /> * reduce the I2C pullup resistors on the IMU module e.g. to 1k<br /> <br /> == Capacitive Load ==<br /> <br /> Capacitive load decreases the slew rate of the signal, and eventually prevents the electronics to detect it correctly, and an I2C error occurs.<br /> <br /> Capacitive load arises from the cables itself, and the longer the cables are the higher is the capacitive load.<br /> <br /> Thus, for any I2C system there is an &quot;intrinsic&quot; maximal length up to which the I2C communication works. In practice this maximal length is not achieved, since, as discussed in the introduction, other I2C error source may be present, reducing the practical length. The capacitive load by the cables depends also on the type of cables. Thin wires for instance have a smaller capacity than thicker wires. In practice, however, there is usually little room to play with that factor. <br /> <br /> Capacitive load also arises from anything conducting in the surrounding of the I2C clock and/or data wires.<br /> <br /> That's indeed a major factor, and - fortunately - it is under our control to a high degree. The possible contributors falling into this category are very diverse; they range from things such as spacing between the wires among themselves or to GND or Vcc, shielding such as in coax wires, twisted or non-twisted wires and how they are twisted, conducting areas like metal bars or carbon plates to which the IMU module is mounted or the cables are fixed to, connectors, and so on. It is as it was said, it arises from '''''anything''''' conducting in the surrounding. Fortunately, the rules which determine the value of capacitors are well known. In a nutshell, the larger the conducting area the larger the capacitance, and the larger the distance to the conducting area the smaller the capacitance. This immediately gives us the rules at hand to control, and possibly avoid them.<br /> <br /> The acceptable capacitive load, from both the cables and the surrounding, depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Induced Signal Disturbances ==<br /> <br /> Wires in the proximity to the I2C clock and data lines may, due to capacitive coupling, induce fault voltages in I2C lines and thus disturb the I2C signals. This again may prevent the electronics to detect the I2C signals correctly or even bring it into an unexpected state, and an I2C error occurs. The I2C errors due to induced disturbances are often fatal in the sense that it can be hard for the electronics to recover properly from them.<br /> <br /> For our gimbals, the primary origin of these disturbances is the motor wires. The motor wires carry high voltage signals, high in comparison to the ca. 3 V of the I2C signals, which moreover are pulsed with large slew rates. When they come close to the I2C lines, the motor wires can easily disturb the signals on the I2C lines.<br /> <br /> The strength of the induced disturbances depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Practical Implications ==<br /> <br /> Equipped with that understanding of the origin of the I2C errors, most of the counter measures listed in the above become obvious now.<br /> <br /> Some of them can have both positive and negative effects. For instance, twisting the I2C wires or shielding them can be very successful in protecting the I2C signals from the induced disturbances by the motor wires, but on the other hand they also increase the capacitive load. Whether these counter measures work or not hence depends on the particular situation, if induced disturbances or capacitive load are the dominating I2C error sources.<br /> <br /> Ferrite rings are very commonly used to suppress I2C errors. When placed on the motor wires they reduce the slew rate of the motor signals and whereby their ability to induce fault voltages in the I2C lines. When placed on the I2C lines they can compensate, to some extend, the capacitive load and thereby improve the I2C signal quality.<br /> <br /> The alert reader has noticed that increasing the currents in the I2C lines or decreasing the pullup resistors, respectively, helps to diminish both the effects of the capacitive load and induced voltage disturbances. This in fact helps very well, and it is a good idea to use small pullup resistors. One may wonder why not to use really small pullup resistors instead of the typical resistors in the 1 k - 10 k range. Well, the answer is that the standard I2C current drivers are not designed to handle currents larger than a few mA (and this in turn is of course related to the way I2C works). So, too small pullup resistors may damage your electronics. Circuitry exists to create low-impedance I2C communications, but it is not used in our low-budget applications.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=I2C_Error_Compendium&diff=1988 2015-01-12T14:25:25Z

<p>Bruce356: </p> <hr /> <div>&lt;span style=&quot;font-size:88%&quot;&gt;''by OlliW&lt;/span&gt;''<br /> <br /> I2C errors are probably the most annoying side effect of the technology we are using in our brushless gimbals.<br /> <br /> I2C errors occur when the signals on the I2C clock and data lines (SCL,SDA) are disturbed beyond certain limits, and this happens due to two main reasons:<br /> * capacitive load on the I2C clock and/or data lines<br /> * induced signal disturbances due to capacitive coupling to outside fields<br /> <br /> Importantly, all error sources add up. One hence can't give decisive threshold values, for example, that the length of the I2C wires should not be more than 40 cm long. Without any further error sources one might be able to use much longer wires, but if for example motor wires are nearby then shorter wires might be required. <br /> <br /> It's like a glass of wine: When it's full, it's full. It doesn't matter whether it was filled with Bordeaux, Chianti, or any other mixture. When the glass is filled with e.g. only a tiny bit of Bordeaux, one can add a lot of Chianti or something else before it overflows, but when the glass is nearly full of Bordeaux, only a tiny drop of Chianti will fit before it reaches the overflows point. So, its not possible to tell how much Chianti is acceptable, since this depends on how much Bordeaux is already in the glass, the only thing that can be determined is that the more Chianti you poor in the glass the more probable it is that it will overflow.<br /> <br /> == Ways to Reduce the I2C Error Rate ==<br /> <br /> Before looking at the I2C errors, here is a brief summary to help reduce problems with the error-prone I2C connection to an IMU module:<br /> <br /> * reduce length of cable<br /> <br /> * increase spacing between I2C cables and motor wires<br /> <br /> * twist wires of the IMU cable; this can take several variations, such as twisting all four together, just twisting SCL and SDL, twisting SCL with GND and SDA with VCC etc.<br /> <br /> * shield the wires; using e.g. a coax cable or wrapping the wires with (self adhesive) conductive cloth, EMI shielding<br /> <br /> * lower the (motor) voltage <br /> <br /> * remove multiple connectors<br /> <br /> * add ferrite rings; these can be fitted in various ways, such as, put the rings on the I2C wires and/or the motor wires, or to either ends of the wires etc.<br /> <br /> * reduce the I2C pullup resistors on the IMU module e.g. to 1k<br /> <br /> == Capacitive Load ==<br /> <br /> Capacitive load decreases the slew rate of the signal, and eventually prevents the electronics to detect it correctly, and an I2C error occurs.<br /> <br /> Capacitive load arises from the cables itself, and the longer the cables are the higher is the capacitive load.<br /> <br /> Thus, for any I2C system there is an &quot;intrinsic&quot; maximal length up to which the I2C communication works. In practice this maximal length is not achieved, since, as discussed in the introduction, other I2C error source may be present, reducing the practical length. The capacitive load by the cables depends also on the type of cables. Thin wires for instance have a smaller capacity than thicker wires. In practice, however, there is usually little room to play with that factor. <br /> <br /> Capacitive load also arises from anything conducting in the surrounding of the I2C clock and/or data wires.<br /> <br /> That's indeed a major factor, and - fortunately - it is under our control to a high degree. The possible contributors falling into this category are very diverse; they range from things such as spacing between the wires among themselves or to GND or Vcc, shielding such as in coax wires, twisted or non-twisted wires and how they are twisted, conducting areas like metal bars or carbon plates to which the IMU module is mounted or the cables are fixed to, connectors, and so on. It is as it was said, it arises from '''''anything''''' conducting in the surrounding. Fortunately, the rules which determine the value of capacitors are well known. In a nutshell, the larger the conducting area the larger the capacitance, and the larger the distance to the conducting area the smaller the capacitance. This immediately gives us the rules at hand to control, and possibly avoid them.<br /> <br /> The acceptable capacitive load, from both the cables and the surrounding, depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Induced Signal Disturbances ==<br /> <br /> Wires in the proximity to the I2C clock and data lines may, due to capacitive coupling, induce fault voltages in I2C lines and thus disturb the I2C signals. This again may prevent the electronics to detect the I2C signals correctly or even bring it into an unexpected state, and an I2C error occurs. The I2C errors due to induced disturbances are often fatal in the sense that it can be hard for the electronics to recover properly from them.<br /> <br /> For our gimbals, the primary origin of these disturbances is the motor wires. The motor wires carry high voltage signals, high in comparison to the ca. 3 V of the I2C signals, which moreover are pulsed with large slew rates. When they come close to the I2C lines, the motor wires can easily disturb the signals on the I2C lines.<br /> <br /> The strength of the induced disturbances depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Practical Implications ==<br /> <br /> Equipped with that understanding of the origin of the I2C errors, most of the counter measures listed in the above become obvious now.<br /> <br /> Some of them can have both positive and negative effects. For instance, twisting the I2C wires or shielding them can be very successful in protecting the I2C signals from the induced disturbances by the motor wires, but on the other hand they also increase the capacitive load. Whether these counter measures work or not hence depends on the particular situation, if induced disturbances or capacitive load are the dominating I2C error sources.<br /> <br /> Ferrite rings are very commonly used to suppress I2C errors. When placed on the motor wires they reduce the slew rate of the motor signals and whereby their ability to induce fault voltages in the I2C lines. When placed on the I2C lines they can compensate, to some extend, the capacitive load and thereby improve the I2C signal quality.<br /> <br /> The alert reader has noticed that increasing the currents in the I2C lines or decreasing the pullup resistors, respectively, helps to diminish both the effects of the capacitive load and induced voltage disturbances. This in fact helps very well, and it is a good idea to use small pullup resistors. One may wonder why not to use really small pullup resistors instead of the typical resistors in the 1 k - 10 k range. Well, the answer is that the standard I2C current drivers are not designed to handle currents larger than a few mA (and this in turn is of course related to the way I2C works). So, too small pullup resistors may damage your electronics. Circuitry exists to create low-impedance I2C communications, but it is not used in our low-budget applications.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=I2C_Error_Compendium&diff=1987 2015-01-12T13:38:17Z

<p>Bruce356: </p> <hr /> <div>&lt;span style=&quot;font-size:88%&quot;&gt;''by OlliW&lt;/span&gt;''<br /> <br /> I2C errors are probably the most annoying side effect of the technology we are using in our brushless gimbals.<br /> <br /> I2C errors occur when the signals on the I2C clock and data lines (SCL,SDA) are disturbed beyond certain limits, and this happens due to two main reason:<br /> * capacitive load on the I2C clock and/or data lines<br /> * induced signal disturbances due to capacitive coupling to outside fields<br /> <br /> Importantly, all error sources add up. One hence can't give decisive threshold values, such as, for instance, that the length of the I2C wires should not be longer than 40 cm. Without any further error sources one might be able to use even much longer wires, while if motor wires are nearby only shorter wires might be acceptable. <br /> <br /> It's like a glass of wine: When it's full, it's full. It doesn't matter if it had been filled with Bordeaux, Chianti, or any mixture. When the glass is filled with only a tiny bit of Bordeaux, one can add a lot of Chianti before it overflows, but when the glass is nearly filled with Bordeaux, only a tiny drop of Chianti is acceptable. So, you're not going to get an answer here to how much Chianti is acceptable, since this depends on how much Bordeaux is there, but &quot;only&quot; that the more Chianti you poor in the more probable it is that the glass spills over.<br /> <br /> == Methods to Reduce I2C Error Rate ==<br /> <br /> Before we look at the I2C errors, the methods shall be briefly summarized which can help to reduce the error-proneness of the I2C connection to the IMU module:<br /> <br /> * reduce length of cable<br /> <br /> * increase spacing between I2C cables and motor wires<br /> <br /> * twist wires of the cable; this comes in many variants such as twisting all four, just twisting SCL and SDL, twisting SCL with GND and SDA with VCC, and so on<br /> <br /> * shield the wires; using e.g. a coax cable or wrapping the wires with (self adhesive) conductive cloth EMI shielding<br /> <br /> * lower the (motor) voltage <br /> <br /> * remove connectors<br /> <br /> * add ferrite rings; this comes in many variants such as to put it to the I2C wires and/or the motor wires, or to the left and/or right ends of the wires, and so on<br /> <br /> * reduce the I2C pullup resistors on e.g. the IMU module<br /> <br /> == Capacitive Load ==<br /> <br /> Capacitive load decreases the slew rate of the signal, and eventually prevents the electronics to detect it correctly, and an I2C error occurs.<br /> <br /> Capacitive load arises from the cables itself, and the longer the cables are the higher is the capacitive load.<br /> <br /> Thus, for any I2C system there is an &quot;intrinsic&quot; maximal length up to which the I2C communication works. In practice this maximal length is not achieved, since, as discussed in the introduction, other I2C error source may be present, reducing the practical length. The capacitive load by the cables depends also on the type of cables. Thin wires for instance have a smaller capacity than thicker wires. In practice, however, there is usually little room to play with that factor. <br /> <br /> Capacitive load also arises from anything conducting in the surrounding of the I2C clock and/or data wires.<br /> <br /> That's indeed a major factor, and - fortunately - it is under our control to a high degree. The possible contributors falling into this category are very diverse; they range from things such as spacing between the wires among themselves or to GND or Vcc, shielding such as in coax wires, twisted or non-twisted wires and how they are twisted, conducting areas like metal bars or carbon plates to which the IMU module is mounted or the cables are fixed to, connectors, and so on. It is as it was said, it arises from '''''anything''''' conducting in the surrounding. Fortunately, the rules which determine the value of capacitors are well known. In a nutshell, the larger the conducting area the larger the capacitance, and the larger the distance to the conducting area the smaller the capacitance. This immediately gives us the rules at hand to control, and possibly avoid them.<br /> <br /> The acceptable capacitive load, from both the cables and the surrounding, depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Induced Signal Disturbances ==<br /> <br /> Wires in the proximity to the I2C clock and data lines may, due to capacitive coupling, induce fault voltages in I2C lines and thus disturb the I2C signals. This again may prevent the electronics to detect the I2C signals correctly or even bring it into an unexpected state, and an I2C error occurs. The I2C errors due to induced disturbances are often fatal in the sense that it can be hard for the electronics to recover properly from them.<br /> <br /> For our gimbals, the primary origin of these disturbances is the motor wires. The motor wires carry high voltage signals, high in comparison to the ca. 3 V of the I2C signals, which moreover are pulsed with large slew rates. When they come close to the I2C lines, the motor wires can easily disturb the signals on the I2C lines.<br /> <br /> The strength of the induced disturbances depends on additional factors, such as the current capabilities of the I2C drivers and the pullup resistors.<br /> <br /> == Practical Implications ==<br /> <br /> Equipped with that understanding of the origin of the I2C errors, most of the counter measures listed in the above become obvious now.<br /> <br /> Some of them can have both positive and negative effects. For instance, twisting the I2C wires or shielding them can be very successful in protecting the I2C signals from the induced disturbances by the motor wires, but on the other hand they also increase the capacitive load. Whether these counter measures work or not hence depends on the particular situation, if induced disturbances or capacitive load are the dominating I2C error sources.<br /> <br /> Ferrite rings are very commonly used to suppress I2C errors. When placed on the motor wires they reduce the slew rate of the motor signals and whereby their ability to induce fault voltages in the I2C lines. When placed on the I2C lines they can compensate, to some extend, the capacitive load and thereby improve the I2C signal quality.<br /> <br /> The alert reader has noticed that increasing the currents in the I2C lines or decreasing the pullup resistors, respectively, helps to diminish both the effects of the capacitive load and induced voltage disturbances. This in fact helps very well, and it is a good idea to use small pullup resistors. One may wonder why not to use really small pullup resistors instead of the typical resistors in the 1 k - 10 k range. Well, the answer is that the standard I2C current drivers are not designed to handle currents larger than a few mA (and this in turn is of course related to the way I2C works). So, too small pullup resistors may damage your electronics. Circuitry exists to create low-impedance I2C communications, but it is not used in our low-budget applications.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=Quick_Start_Guide&diff=1663 2014-12-04T08:42:43Z

<p>Bruce356: /* After motors have been enabled for the first time */</p> <hr /> <div>On this page, I (OlliW) will briefly describe the initial steps which are required to set up the STorM32-BGC to function correctly. ''Descriptions refer to firmware v0.56.''<br /> <br /> '''Ultra-Quick Start Guide:'''<br /> * Use the &quot;Calibrate Acc&quot; tab to calibrate the imus.<br /> * Use the &quot;Configure Gimbal Tool&quot; to set the Imu1 Orientation, Imu2 Orientation, and Motor Pole parameters correctly, and to set the Motor Direction parameters to &quot;auto&quot;. <br /> * Use the &quot;Get Current Motor Directions&quot; option to set the Motor Direction parameters.<br /> * Use the &quot;Get Current Pitch and Roll Motor Positions&quot; option to set the Startup Motor Pos parameters for pitch and roll.<br /> * Use the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot; to align the yaw axis to point forward at startup.<br /> <br /> Below a somewhat less quick &quot;Quick Start Guide&quot; follows. It tells you what you need to know and what to do.<br /> <br /> == Supported Gimbals ==<br /> The STorM32 controller can currently be used for the following setups:<br /> * '''3-Axis with single Camera IMU:''' Only one IMU, connected to the I2C port and mounted to the camera, is used.<br /> * '''3-Axis with Camera &amp; on-board IMU:''' In addition to the camera IMU the StorM32 on-board IMU is used as a 2nd IMU. The StorM32 board must be mounted on the gimbal '''''above''''' the yaw motor. <br /> * '''3-Axis with Camera &amp; separate 2nd IMU:''' In addition to the camera IMU a further IMU connected to the I2C#2 port is used as 2nd IMU. The board can be mounted anywhere, but the 2nd IMU must be mounted on the gimbal '''''above''''' the yaw motor. <br /> * '''2-Axis:''' This is not &quot;officially&quot; supported but users figured out that the controller can be set up to work fine with a 2-axis gimbal (check the [http://www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups thread]). Only one Camera IMU is attached to the I2C port. The 2nd IMU is not supported in this configuration. <br /> Both the 3-axis and 2-axis gimbals with single IMU are obviously easier to set up since one doesn't need to be concerned about the 2nd IMU and what's required to get it working correctly. The following focuses on the 3-axis dual-IMU setups.<br /> <br /> == Preparation ==<br /> Things to know before starting: <br /> * Comprehend the [[Getting Started#Dos and Dont's|Dos and Dont's]].<br /> * Understand the importance of a proper gimbal mechanics, read [[Getting Started#The Gimbal|The Gimbal]] and especially [[Tuning_Recipe#Balancing the Gimbal|Balancing the Gimbal]]!<br /> * Get familiar with the board, inspect the [[Pins and Connectors]].<br /> * Use the latest firmware and GUI. To download the latest firmware package see [[Downloads]]. To flash the firmware to the board see [[How to flash firmware]]. Read the updates and installation instructions in the respective posts at the [http://www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups thread], also check these posts for known bugs.<br /> * Check that your setup matches one of the supported setups mentioned previously.<br /> * Understand the &quot;Read&quot;, &quot;Write&quot;, and &quot;Write+Store&quot; mechanism in the GUI.<br /> <br /> Finally, good advice:- Please take any recommendations from these links seriously!<br /> <br /> == Calibration ==<br /> The accelerometers within the IMU modules need to be calibrated for optimal performance (the gyros would also, but that's currently beyond reach). Several calibration techniques are available, and two are implemented in the STorM32 project, these are the &quot;1-point&quot; and &quot;6-point&quot; calibrations. <br /> <br /> Unfortunately, it is not absolutely clear as to which method is the best. This is because I don't have the resources for an extensive research project, this is what would possibly be needed for a determination. Hence, the situation currently is a bit experimental and might appear fuzzy to many users, but - on the positive side - knowledge and experience is increasing and therefore calibration procedures may improve with time. <br /> <br /> The reasons for a calibrating are different for the camera IMU versus the 2nd IMU. <br /> <br /> '''Camera IMU:''' Calibration mainly affects &quot;horizontal drift&quot;, i.e. the accuracy with which the horizon is held in quick yaw turns and other high-g manoeuvers. It also determines the accuracy of how well the camera is leveled, but this can in principle be tuned out easily by other means (e.g. offset parameters). The main concern is the performance in high-g manoeuvers. <br /> <br /> '''Second IMU:''' The measurement accuracy of the 2nd IMU is in itself not very important, it is however very important that the 2nd IMU data is consistent with the camera IMU, and it is even more important with higher poled motors e.g. poles greater than the basic 14 poles. <br /> <br /> It has been found that the calibration issue depends strongly on the orientation of the IMU module. <br /> <br /> '''Imu Orientation:''' In general, the z axis is more often wrong than the x and y axes.<br /> <br /> Of course, the care with which a calibration is performed very much affects the final quality results of the calibration. <br /> <br /> '''Calibration Accuracy:''' A 6-point calibration is meaningful only if it is done very accurately. A poorly undertaken 6-point calibration can easily result in poorer performance than a supposedly &quot;lesser&quot; 1-point calibration. The resulting quality factor under the 6-point calibration option can give a good indication as to the results (a value of 80 very good, 150 average, 250 not so good). <br /> <br /> From the above information these are rules of thumb to follow: <br /> <br /> '''Rules of thumb:'''<br /> * The calibration only needs to be as good as you need it to be. If you are happy with the way your gimbal performs, you don't need to spend time on a (better) calibration.<br /> * IMU orientations with the Z-axis pointing up or down seems preferable, as it lessens the need for calibration. But don't be fooled here, equally good results can be obtained for other orientation. Some of the best videos out there were in fact recorded with the imu's Z-axis in a horizontal orientation. It just means that with the Z-axis pointing up or down it's more likely that one can get away with a &quot;lesser&quot; calibration for a desired level of performance.<br /> * The calibration of the camera IMU is more important than for the 2nd IMU, i.e. for the 2nd IMU a &quot;lesser&quot; calibration might be fully sufficient. <br /> * The calibration of the 2nd IMU becomes more important as the motor pole count increases (e.g. 14 pole versus 22 pole). <br /> <br /> ⦁ Even though, for the reasons mentioned previously, a clear cut calibration recipe cannot currently be offered, although there are some recommendations in place: <br /> <br /> '''Current Recommendations:'''<br /> * A 1-point calibration is fairly simple, and is hence recommended for both the camera and the 2nd IMU. <br /> * If possible choose imu orientations with the Z-axis pointing up or down, but that's not a must as explained before. <br /> * Don't do a 6-point calibration unless you plan to do it very accurately (check out the rcgroups thread). <br /> * If motors with 12 or 14 poles are used, a 1-point calibration of the 2nd IMU is most likely sufficient. In contrast Higher-pole motors require a careful 2nd IMU calibration. <br /> <br /> '''Video Calibration Tutorial:''' Rcgroups user mackar made a great video on the 6-point calibration. Go to [[6-Point Calibration]].<br /> <br /> Finally, some important advice: <br /> <br /> Save your calibration data to a file! <br /> <br /> Ideally save it from within the Calibration dialog window, as this stores the most detailed information. Consider also, posting your calibration files in the rcgroups thread, so that the firmware author and others can enhance their knowledge and hopefully develop better calibration schemes.<br /> <br /> == Basic Controller Configuration ==<br /> The algorithms used in the STorM32 controller need to know some aspects of your gimbal in order to work correctly. If any of this information is incorrect, the controller will misbehave. Unfortunately, an incorrect setup will not always immediately reveal itself, but will lead to misbehaviour at a later stage, e.g. when a new function is activated, and therefore you might not associate it with the earlier faulty setup. So, please accept the following statement: <br /> <br /> Just because a setting seems to work correctly doesn't mean that it is correct!<br /> <br /> One implication is that adjusting the fundamental parameters by trial-and-error is the best approach in producing all sorts of non-obvious problems. Fortunately, a straight-forward setup procedure is available and if followed, guarantees correct settings. So, the above could be rephrased as &quot;Don't try to be smart, just shut up and follow the recipe&quot;. That's in fact the best advice possible here. <br /> <br /> The parameters we are talking about are those mainly contained under the &quot;Gimbal Configuration&quot; tab in the GUI:<br /> * Imu-1 Orientation<br /> * Imu-2 Orientation<br /> * Motor Poles<br /> * Motor Directions<br /> * Motor Startup Positions<br /> Some of these should be adjusted &quot;before&quot; the motors are activated, some can only be adjusted with the motors enabled. <br /> <br /> === Before the motors are enabled for the first time ===<br /> The Imu-1 and Imu-2 orientations and number of motor poles should be adjusted before the motors are activated, and the motor direction settings, initially set to Auto in order to find correct rotation directions. <br /> <br /> This is most easily done by using the &quot;Configuration Gimbal Tool&quot; option (accessible under the &quot;Gimbal Configuration&quot; Tab in the GUI), which is started by clicking on the respective button. Just follow the instructions step by step: <br /> <br /> * It will guide you through a simple procedure which determines the Imu-1 and Imu-2 Orientations.<br /> * It will then ask you to enter the number of poles of your motors. The number of poles for your motors should be available in the motor data sheets. For example, a 12N14P motor has 14 poles. The number of poles corresponds to the number of magnets, which you can be seen on the inner side of the motor bell. So, if in doubt you can quite easily determine the number of poles by simply counting the number of magnets. <br /> * Finally, as mentioned above, the Motor Direction parameters must be set to &quot;Auto&quot;. <br /> <br /> === After motors have been enabled for the first time ===<br /> With the Imu-1 and Imu-2 orientations, and motor poles set correctly, and the motor direction set to &quot;auto&quot;, one can enable the motors (all motors!) and start the gimbal. The controller should go through the initialization steps and level the camera (green led blinks), and then reach the &quot;Normal&quot; state (green led continuously On). Note: You can see what is happening by initiating and starting the &quot;Data Display&quot;. Once the &quot;Normal&quot; state is reached the Motor Directions and the Startup Motor Pos parameters can be set using the Tools tab: <br /> <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Get Current Motor Directions&quot; option. This will copy the auto determined motor directions into the Motor Direction fields. <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Get Current Pitch and Roll Motor Positions&quot; option. This will copy the current pitch and roll motor positions into the Pitch and Roll Startup Motor Pos parameter fields. <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot;. This opens a dialog box which allows you to align the yaw axis such that the camera points to the forward position. Don't worry that the alignment is undone, when closing the dialog box, this is normal as the adjustments just made become effective after the next re-start of the gimbal controller. <br /> '''Note!''' adjustments made in these steps only become Active after a re-start of the StorM32 gimbal controller.<br /> <br /> == The Next Steps ==<br /> The next steps are to tune the PID parameters. It is not part of this Quick Guide, since the PID values are not fundamental for the controller to work correctly; they are (very) important for the performance. Once tuned, one can start to enjoy all the great and partly unique possibilities of the STorM32 controller. :)</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=Quick_Start_Guide&diff=1662 2014-12-04T08:39:52Z

<p>Bruce356: /* After motors have been enabled for the first time */</p> <hr /> <div>On this page, I (OlliW) will briefly describe the initial steps which are required to set up the STorM32-BGC to function correctly. ''Descriptions refer to firmware v0.56.''<br /> <br /> '''Ultra-Quick Start Guide:'''<br /> * Use the &quot;Calibrate Acc&quot; tab to calibrate the imus.<br /> * Use the &quot;Configure Gimbal Tool&quot; to set the Imu1 Orientation, Imu2 Orientation, and Motor Pole parameters correctly, and to set the Motor Direction parameters to &quot;auto&quot;. <br /> * Use the &quot;Get Current Motor Directions&quot; option to set the Motor Direction parameters.<br /> * Use the &quot;Get Current Pitch and Roll Motor Positions&quot; option to set the Startup Motor Pos parameters for pitch and roll.<br /> * Use the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot; to align the yaw axis to point forward at startup.<br /> <br /> Below a somewhat less quick &quot;Quick Start Guide&quot; follows. It tells you what you need to know and what to do.<br /> <br /> == Supported Gimbals ==<br /> The STorM32 controller can currently be used for the following setups:<br /> * '''3-Axis with single Camera IMU:''' Only one IMU, connected to the I2C port and mounted to the camera, is used.<br /> * '''3-Axis with Camera &amp; on-board IMU:''' In addition to the camera IMU the StorM32 on-board IMU is used as a 2nd IMU. The StorM32 board must be mounted on the gimbal '''''above''''' the yaw motor. <br /> * '''3-Axis with Camera &amp; separate 2nd IMU:''' In addition to the camera IMU a further IMU connected to the I2C#2 port is used as 2nd IMU. The board can be mounted anywhere, but the 2nd IMU must be mounted on the gimbal '''''above''''' the yaw motor. <br /> * '''2-Axis:''' This is not &quot;officially&quot; supported but users figured out that the controller can be set up to work fine with a 2-axis gimbal (check the [http://www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups thread]). Only one Camera IMU is attached to the I2C port. The 2nd IMU is not supported in this configuration. <br /> Both the 3-axis and 2-axis gimbals with single IMU are obviously easier to set up since one doesn't need to be concerned about the 2nd IMU and what's required to get it working correctly. The following focuses on the 3-axis dual-IMU setups.<br /> <br /> == Preparation ==<br /> Things to know before starting: <br /> * Comprehend the [[Getting Started#Dos and Dont's|Dos and Dont's]].<br /> * Understand the importance of a proper gimbal mechanics, read [[Getting Started#The Gimbal|The Gimbal]] and especially [[Tuning_Recipe#Balancing the Gimbal|Balancing the Gimbal]]!<br /> * Get familiar with the board, inspect the [[Pins and Connectors]].<br /> * Use the latest firmware and GUI. To download the latest firmware package see [[Downloads]]. To flash the firmware to the board see [[How to flash firmware]]. Read the updates and installation instructions in the respective posts at the [http://www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups thread], also check these posts for known bugs.<br /> * Check that your setup matches one of the supported setups mentioned previously.<br /> * Understand the &quot;Read&quot;, &quot;Write&quot;, and &quot;Write+Store&quot; mechanism in the GUI.<br /> <br /> Finally, good advice:- Please take any recommendations from these links seriously!<br /> <br /> == Calibration ==<br /> The accelerometers within the IMU modules need to be calibrated for optimal performance (the gyros would also, but that's currently beyond reach). Several calibration techniques are available, and two are implemented in the STorM32 project, these are the &quot;1-point&quot; and &quot;6-point&quot; calibrations. <br /> <br /> Unfortunately, it is not absolutely clear as to which method is the best. This is because I don't have the resources for an extensive research project, this is what would possibly be needed for a determination. Hence, the situation currently is a bit experimental and might appear fuzzy to many users, but - on the positive side - knowledge and experience is increasing and therefore calibration procedures may improve with time. <br /> <br /> The reasons for a calibrating are different for the camera IMU versus the 2nd IMU. <br /> <br /> '''Camera IMU:''' Calibration mainly affects &quot;horizontal drift&quot;, i.e. the accuracy with which the horizon is held in quick yaw turns and other high-g manoeuvers. It also determines the accuracy of how well the camera is leveled, but this can in principle be tuned out easily by other means (e.g. offset parameters). The main concern is the performance in high-g manoeuvers. <br /> <br /> '''Second IMU:''' The measurement accuracy of the 2nd IMU is in itself not very important, it is however very important that the 2nd IMU data is consistent with the camera IMU, and it is even more important with higher poled motors e.g. poles greater than the basic 14 poles. <br /> <br /> It has been found that the calibration issue depends strongly on the orientation of the IMU module. <br /> <br /> '''Imu Orientation:''' In general, the z axis is more often wrong than the x and y axes.<br /> <br /> Of course, the care with which a calibration is performed very much affects the final quality results of the calibration. <br /> <br /> '''Calibration Accuracy:''' A 6-point calibration is meaningful only if it is done very accurately. A poorly undertaken 6-point calibration can easily result in poorer performance than a supposedly &quot;lesser&quot; 1-point calibration. The resulting quality factor under the 6-point calibration option can give a good indication as to the results (a value of 80 very good, 150 average, 250 not so good). <br /> <br /> From the above information these are rules of thumb to follow: <br /> <br /> '''Rules of thumb:'''<br /> * The calibration only needs to be as good as you need it to be. If you are happy with the way your gimbal performs, you don't need to spend time on a (better) calibration.<br /> * IMU orientations with the Z-axis pointing up or down seems preferable, as it lessens the need for calibration. But don't be fooled here, equally good results can be obtained for other orientation. Some of the best videos out there were in fact recorded with the imu's Z-axis in a horizontal orientation. It just means that with the Z-axis pointing up or down it's more likely that one can get away with a &quot;lesser&quot; calibration for a desired level of performance.<br /> * The calibration of the camera IMU is more important than for the 2nd IMU, i.e. for the 2nd IMU a &quot;lesser&quot; calibration might be fully sufficient. <br /> * The calibration of the 2nd IMU becomes more important as the motor pole count increases (e.g. 14 pole versus 22 pole). <br /> <br /> ⦁ Even though, for the reasons mentioned previously, a clear cut calibration recipe cannot currently be offered, although there are some recommendations in place: <br /> <br /> '''Current Recommendations:'''<br /> * A 1-point calibration is fairly simple, and is hence recommended for both the camera and the 2nd IMU. <br /> * If possible choose imu orientations with the Z-axis pointing up or down, but that's not a must as explained before. <br /> * Don't do a 6-point calibration unless you plan to do it very accurately (check out the rcgroups thread). <br /> * If motors with 12 or 14 poles are used, a 1-point calibration of the 2nd IMU is most likely sufficient. In contrast Higher-pole motors require a careful 2nd IMU calibration. <br /> <br /> '''Video Calibration Tutorial:''' Rcgroups user mackar made a great video on the 6-point calibration. Go to [[6-Point Calibration]].<br /> <br /> Finally, some important advice: <br /> <br /> Save your calibration data to a file! <br /> <br /> Ideally save it from within the Calibration dialog window, as this stores the most detailed information. Consider also, posting your calibration files in the rcgroups thread, so that the firmware author and others can enhance their knowledge and hopefully develop better calibration schemes.<br /> <br /> == Basic Controller Configuration ==<br /> The algorithms used in the STorM32 controller need to know some aspects of your gimbal in order to work correctly. If any of this information is incorrect, the controller will misbehave. Unfortunately, an incorrect setup will not always immediately reveal itself, but will lead to misbehaviour at a later stage, e.g. when a new function is activated, and therefore you might not associate it with the earlier faulty setup. So, please accept the following statement: <br /> <br /> Just because a setting seems to work correctly doesn't mean that it is correct!<br /> <br /> One implication is that adjusting the fundamental parameters by trial-and-error is the best approach in producing all sorts of non-obvious problems. Fortunately, a straight-forward setup procedure is available and if followed, guarantees correct settings. So, the above could be rephrased as &quot;Don't try to be smart, just shut up and follow the recipe&quot;. That's in fact the best advice possible here. <br /> <br /> The parameters we are talking about are those mainly contained under the &quot;Gimbal Configuration&quot; tab in the GUI:<br /> * Imu-1 Orientation<br /> * Imu-2 Orientation<br /> * Motor Poles<br /> * Motor Directions<br /> * Motor Startup Positions<br /> Some of these should be adjusted &quot;before&quot; the motors are activated, some can only be adjusted with the motors enabled. <br /> <br /> === Before the motors are enabled for the first time ===<br /> The Imu-1 and Imu-2 orientations and number of motor poles should be adjusted before the motors are activated, and the motor direction settings, initially set to Auto in order to find correct rotation directions. <br /> <br /> This is most easily done by using the &quot;Configuration Gimbal Tool&quot; option (accessible under the &quot;Gimbal Configuration&quot; Tab in the GUI), which is started by clicking on the respective button. Just follow the instructions step by step: <br /> <br /> * It will guide you through a simple procedure which determines the Imu-1 and Imu-2 Orientations.<br /> * It will then ask you to enter the number of poles of your motors. The number of poles for your motors should be available in the motor data sheets. For example, a 12N14P motor has 14 poles. The number of poles corresponds to the number of magnets, which you can be seen on the inner side of the motor bell. So, if in doubt you can quite easily determine the number of poles by simply counting the number of magnets. <br /> * Finally, as mentioned above, the Motor Direction parameters must be set to &quot;Auto&quot;. <br /> <br /> === After motors have been enabled for the first time ===<br /> With the Imu-1 and Imu-2 orientations, and motor poles set correctly, and the motor direction set to &quot;auto&quot;, one can enable the motors (all motors!) and start the gimbal. The controller should go through the initialization steps and level the camera (green led blinks), and then reach the &quot;Normal&quot; state (green led continuously On). Note: You can see what is happening by initiating and starting the &quot;Data Display&quot;. Once the &quot;Normal&quot; state is reached the Motor Directions and the Startup Motor Pos parameters can be set using the Tools tab: <br /> <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Get Current Motor Directions&quot; option. This will copy the auto determined motor directions into the Motor Direction fields. <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Get Current Pitch and Roll Motor Positions&quot; option. This will copy the current pitch and roll motor positions into the Pitch and Roll Startup Motor Pos parameter fields. <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot;. This opens a dialog box which allows you to align the yaw axis such that the camera points to the forward position. Don't worry that the alignment being undone, when closing the dialog box, this is normal as the just made adjustments become effective only after the next startup of the gimbal. <br /> Note! adjustments made in these steps only become Active after a restart of the StorM32 gimbal controller.<br /> <br /> == The Next Steps ==<br /> The next steps are to tune the PID parameters. It is not part of this Quick Guide, since the PID values are not fundamental for the controller to work correctly; they are (very) important for the performance. Once tuned, one can start to enjoy all the great and partly unique possibilities of the STorM32 controller. :)</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=Quick_Start_Guide&diff=1661 2014-12-04T08:37:35Z

<p>Bruce356: /* The Next Steps */</p> <hr /> <div>On this page, I (OlliW) will briefly describe the initial steps which are required to set up the STorM32-BGC to function correctly. ''Descriptions refer to firmware v0.56.''<br /> <br /> '''Ultra-Quick Start Guide:'''<br /> * Use the &quot;Calibrate Acc&quot; tab to calibrate the imus.<br /> * Use the &quot;Configure Gimbal Tool&quot; to set the Imu1 Orientation, Imu2 Orientation, and Motor Pole parameters correctly, and to set the Motor Direction parameters to &quot;auto&quot;. <br /> * Use the &quot;Get Current Motor Directions&quot; option to set the Motor Direction parameters.<br /> * Use the &quot;Get Current Pitch and Roll Motor Positions&quot; option to set the Startup Motor Pos parameters for pitch and roll.<br /> * Use the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot; to align the yaw axis to point forward at startup.<br /> <br /> Below a somewhat less quick &quot;Quick Start Guide&quot; follows. It tells you what you need to know and what to do.<br /> <br /> == Supported Gimbals ==<br /> The STorM32 controller can currently be used for the following setups:<br /> * '''3-Axis with single Camera IMU:''' Only one IMU, connected to the I2C port and mounted to the camera, is used.<br /> * '''3-Axis with Camera &amp; on-board IMU:''' In addition to the camera IMU the StorM32 on-board IMU is used as a 2nd IMU. The StorM32 board must be mounted on the gimbal '''''above''''' the yaw motor. <br /> * '''3-Axis with Camera &amp; separate 2nd IMU:''' In addition to the camera IMU a further IMU connected to the I2C#2 port is used as 2nd IMU. The board can be mounted anywhere, but the 2nd IMU must be mounted on the gimbal '''''above''''' the yaw motor. <br /> * '''2-Axis:''' This is not &quot;officially&quot; supported but users figured out that the controller can be set up to work fine with a 2-axis gimbal (check the [http://www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups thread]). Only one Camera IMU is attached to the I2C port. The 2nd IMU is not supported in this configuration. <br /> Both the 3-axis and 2-axis gimbals with single IMU are obviously easier to set up since one doesn't need to be concerned about the 2nd IMU and what's required to get it working correctly. The following focuses on the 3-axis dual-IMU setups.<br /> <br /> == Preparation ==<br /> Things to know before starting: <br /> * Comprehend the [[Getting Started#Dos and Dont's|Dos and Dont's]].<br /> * Understand the importance of a proper gimbal mechanics, read [[Getting Started#The Gimbal|The Gimbal]] and especially [[Tuning_Recipe#Balancing the Gimbal|Balancing the Gimbal]]!<br /> * Get familiar with the board, inspect the [[Pins and Connectors]].<br /> * Use the latest firmware and GUI. To download the latest firmware package see [[Downloads]]. To flash the firmware to the board see [[How to flash firmware]]. Read the updates and installation instructions in the respective posts at the [http://www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups thread], also check these posts for known bugs.<br /> * Check that your setup matches one of the supported setups mentioned previously.<br /> * Understand the &quot;Read&quot;, &quot;Write&quot;, and &quot;Write+Store&quot; mechanism in the GUI.<br /> <br /> Finally, good advice:- Please take any recommendations from these links seriously!<br /> <br /> == Calibration ==<br /> The accelerometers within the IMU modules need to be calibrated for optimal performance (the gyros would also, but that's currently beyond reach). Several calibration techniques are available, and two are implemented in the STorM32 project, these are the &quot;1-point&quot; and &quot;6-point&quot; calibrations. <br /> <br /> Unfortunately, it is not absolutely clear as to which method is the best. This is because I don't have the resources for an extensive research project, this is what would possibly be needed for a determination. Hence, the situation currently is a bit experimental and might appear fuzzy to many users, but - on the positive side - knowledge and experience is increasing and therefore calibration procedures may improve with time. <br /> <br /> The reasons for a calibrating are different for the camera IMU versus the 2nd IMU. <br /> <br /> '''Camera IMU:''' Calibration mainly affects &quot;horizontal drift&quot;, i.e. the accuracy with which the horizon is held in quick yaw turns and other high-g manoeuvers. It also determines the accuracy of how well the camera is leveled, but this can in principle be tuned out easily by other means (e.g. offset parameters). The main concern is the performance in high-g manoeuvers. <br /> <br /> '''Second IMU:''' The measurement accuracy of the 2nd IMU is in itself not very important, it is however very important that the 2nd IMU data is consistent with the camera IMU, and it is even more important with higher poled motors e.g. poles greater than the basic 14 poles. <br /> <br /> It has been found that the calibration issue depends strongly on the orientation of the IMU module. <br /> <br /> '''Imu Orientation:''' In general, the z axis is more often wrong than the x and y axes.<br /> <br /> Of course, the care with which a calibration is performed very much affects the final quality results of the calibration. <br /> <br /> '''Calibration Accuracy:''' A 6-point calibration is meaningful only if it is done very accurately. A poorly undertaken 6-point calibration can easily result in poorer performance than a supposedly &quot;lesser&quot; 1-point calibration. The resulting quality factor under the 6-point calibration option can give a good indication as to the results (a value of 80 very good, 150 average, 250 not so good). <br /> <br /> From the above information these are rules of thumb to follow: <br /> <br /> '''Rules of thumb:'''<br /> * The calibration only needs to be as good as you need it to be. If you are happy with the way your gimbal performs, you don't need to spend time on a (better) calibration.<br /> * IMU orientations with the Z-axis pointing up or down seems preferable, as it lessens the need for calibration. But don't be fooled here, equally good results can be obtained for other orientation. Some of the best videos out there were in fact recorded with the imu's Z-axis in a horizontal orientation. It just means that with the Z-axis pointing up or down it's more likely that one can get away with a &quot;lesser&quot; calibration for a desired level of performance.<br /> * The calibration of the camera IMU is more important than for the 2nd IMU, i.e. for the 2nd IMU a &quot;lesser&quot; calibration might be fully sufficient. <br /> * The calibration of the 2nd IMU becomes more important as the motor pole count increases (e.g. 14 pole versus 22 pole). <br /> <br /> ⦁ Even though, for the reasons mentioned previously, a clear cut calibration recipe cannot currently be offered, although there are some recommendations in place: <br /> <br /> '''Current Recommendations:'''<br /> * A 1-point calibration is fairly simple, and is hence recommended for both the camera and the 2nd IMU. <br /> * If possible choose imu orientations with the Z-axis pointing up or down, but that's not a must as explained before. <br /> * Don't do a 6-point calibration unless you plan to do it very accurately (check out the rcgroups thread). <br /> * If motors with 12 or 14 poles are used, a 1-point calibration of the 2nd IMU is most likely sufficient. In contrast Higher-pole motors require a careful 2nd IMU calibration. <br /> <br /> '''Video Calibration Tutorial:''' Rcgroups user mackar made a great video on the 6-point calibration. Go to [[6-Point Calibration]].<br /> <br /> Finally, some important advice: <br /> <br /> Save your calibration data to a file! <br /> <br /> Ideally save it from within the Calibration dialog window, as this stores the most detailed information. Consider also, posting your calibration files in the rcgroups thread, so that the firmware author and others can enhance their knowledge and hopefully develop better calibration schemes.<br /> <br /> == Basic Controller Configuration ==<br /> The algorithms used in the STorM32 controller need to know some aspects of your gimbal in order to work correctly. If any of this information is incorrect, the controller will misbehave. Unfortunately, an incorrect setup will not always immediately reveal itself, but will lead to misbehaviour at a later stage, e.g. when a new function is activated, and therefore you might not associate it with the earlier faulty setup. So, please accept the following statement: <br /> <br /> Just because a setting seems to work correctly doesn't mean that it is correct!<br /> <br /> One implication is that adjusting the fundamental parameters by trial-and-error is the best approach in producing all sorts of non-obvious problems. Fortunately, a straight-forward setup procedure is available and if followed, guarantees correct settings. So, the above could be rephrased as &quot;Don't try to be smart, just shut up and follow the recipe&quot;. That's in fact the best advice possible here. <br /> <br /> The parameters we are talking about are those mainly contained under the &quot;Gimbal Configuration&quot; tab in the GUI:<br /> * Imu-1 Orientation<br /> * Imu-2 Orientation<br /> * Motor Poles<br /> * Motor Directions<br /> * Motor Startup Positions<br /> Some of these should be adjusted &quot;before&quot; the motors are activated, some can only be adjusted with the motors enabled. <br /> <br /> === Before the motors are enabled for the first time ===<br /> The Imu-1 and Imu-2 orientations and number of motor poles should be adjusted before the motors are activated, and the motor direction settings, initially set to Auto in order to find correct rotation directions. <br /> <br /> This is most easily done by using the &quot;Configuration Gimbal Tool&quot; option (accessible under the &quot;Gimbal Configuration&quot; Tab in the GUI), which is started by clicking on the respective button. Just follow the instructions step by step: <br /> <br /> * It will guide you through a simple procedure which determines the Imu-1 and Imu-2 Orientations.<br /> * It will then ask you to enter the number of poles of your motors. The number of poles for your motors should be available in the motor data sheets. For example, a 12N14P motor has 14 poles. The number of poles corresponds to the number of magnets, which you can be seen on the inner side of the motor bell. So, if in doubt you can quite easily determine the number of poles by simply counting the number of magnets. <br /> * Finally, as mentioned above, the Motor Direction parameters must be set to &quot;Auto&quot;. <br /> <br /> === After motors have been enabled for the first time ===<br /> With the Imu-1 and Imu-2 orientations, and motor poles set correctly, and the motor direction set to &quot;auto&quot;, one can enable the motors (all motors!) and start the gimbal. The controller should go through the initialization steps and level the camera (green led blinks), and then reach the &quot;Normal&quot; state (green led continuously On). Note: You can see what is happening by initiating and starting the &quot;Data Display&quot;. Once the &quot;Normal&quot; state is reached the Motor Directions and the Startup Motor Pos parameters can be set using the Tools tab: <br /> <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Get Current Motor Directions&quot; option. This will copy the auto determined motor directions into the Motor Direction fields. <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Get Current Pitch and Roll Motor Positions&quot; option. This will copy the current pitch and roll motor positions into the Pitch and Roll Startup Motor Pos parameter fields. <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot;. This opens a dialog box which allows you to align the yaw axis such that the camera points to the forward position. Don't worry that the alignment being undone when closing the dialog box, this is normal as the just made adjustments become effective only after the next startup of the gimbal. <br /> Note! adjustments made in these steps only become Active after a restart of the StorM32 gimbal controller.<br /> <br /> == The Next Steps ==<br /> The next steps are to tune the PID parameters. It is not part of this Quick Guide, since the PID values are not fundamental for the controller to work correctly; they are (very) important for the performance. Once tuned, one can start to enjoy all the great and partly unique possibilities of the STorM32 controller. :)</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=Quick_Start_Guide&diff=1660 2014-12-04T08:36:41Z

<p>Bruce356: /* Basic Controller Configuration */</p> <hr /> <div>On this page, I (OlliW) will briefly describe the initial steps which are required to set up the STorM32-BGC to function correctly. ''Descriptions refer to firmware v0.56.''<br /> <br /> '''Ultra-Quick Start Guide:'''<br /> * Use the &quot;Calibrate Acc&quot; tab to calibrate the imus.<br /> * Use the &quot;Configure Gimbal Tool&quot; to set the Imu1 Orientation, Imu2 Orientation, and Motor Pole parameters correctly, and to set the Motor Direction parameters to &quot;auto&quot;. <br /> * Use the &quot;Get Current Motor Directions&quot; option to set the Motor Direction parameters.<br /> * Use the &quot;Get Current Pitch and Roll Motor Positions&quot; option to set the Startup Motor Pos parameters for pitch and roll.<br /> * Use the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot; to align the yaw axis to point forward at startup.<br /> <br /> Below a somewhat less quick &quot;Quick Start Guide&quot; follows. It tells you what you need to know and what to do.<br /> <br /> == Supported Gimbals ==<br /> The STorM32 controller can currently be used for the following setups:<br /> * '''3-Axis with single Camera IMU:''' Only one IMU, connected to the I2C port and mounted to the camera, is used.<br /> * '''3-Axis with Camera &amp; on-board IMU:''' In addition to the camera IMU the StorM32 on-board IMU is used as a 2nd IMU. The StorM32 board must be mounted on the gimbal '''''above''''' the yaw motor. <br /> * '''3-Axis with Camera &amp; separate 2nd IMU:''' In addition to the camera IMU a further IMU connected to the I2C#2 port is used as 2nd IMU. The board can be mounted anywhere, but the 2nd IMU must be mounted on the gimbal '''''above''''' the yaw motor. <br /> * '''2-Axis:''' This is not &quot;officially&quot; supported but users figured out that the controller can be set up to work fine with a 2-axis gimbal (check the [http://www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups thread]). Only one Camera IMU is attached to the I2C port. The 2nd IMU is not supported in this configuration. <br /> Both the 3-axis and 2-axis gimbals with single IMU are obviously easier to set up since one doesn't need to be concerned about the 2nd IMU and what's required to get it working correctly. The following focuses on the 3-axis dual-IMU setups.<br /> <br /> == Preparation ==<br /> Things to know before starting: <br /> * Comprehend the [[Getting Started#Dos and Dont's|Dos and Dont's]].<br /> * Understand the importance of a proper gimbal mechanics, read [[Getting Started#The Gimbal|The Gimbal]] and especially [[Tuning_Recipe#Balancing the Gimbal|Balancing the Gimbal]]!<br /> * Get familiar with the board, inspect the [[Pins and Connectors]].<br /> * Use the latest firmware and GUI. To download the latest firmware package see [[Downloads]]. To flash the firmware to the board see [[How to flash firmware]]. Read the updates and installation instructions in the respective posts at the [http://www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups thread], also check these posts for known bugs.<br /> * Check that your setup matches one of the supported setups mentioned previously.<br /> * Understand the &quot;Read&quot;, &quot;Write&quot;, and &quot;Write+Store&quot; mechanism in the GUI.<br /> <br /> Finally, good advice:- Please take any recommendations from these links seriously!<br /> <br /> == Calibration ==<br /> The accelerometers within the IMU modules need to be calibrated for optimal performance (the gyros would also, but that's currently beyond reach). Several calibration techniques are available, and two are implemented in the STorM32 project, these are the &quot;1-point&quot; and &quot;6-point&quot; calibrations. <br /> <br /> Unfortunately, it is not absolutely clear as to which method is the best. This is because I don't have the resources for an extensive research project, this is what would possibly be needed for a determination. Hence, the situation currently is a bit experimental and might appear fuzzy to many users, but - on the positive side - knowledge and experience is increasing and therefore calibration procedures may improve with time. <br /> <br /> The reasons for a calibrating are different for the camera IMU versus the 2nd IMU. <br /> <br /> '''Camera IMU:''' Calibration mainly affects &quot;horizontal drift&quot;, i.e. the accuracy with which the horizon is held in quick yaw turns and other high-g manoeuvers. It also determines the accuracy of how well the camera is leveled, but this can in principle be tuned out easily by other means (e.g. offset parameters). The main concern is the performance in high-g manoeuvers. <br /> <br /> '''Second IMU:''' The measurement accuracy of the 2nd IMU is in itself not very important, it is however very important that the 2nd IMU data is consistent with the camera IMU, and it is even more important with higher poled motors e.g. poles greater than the basic 14 poles. <br /> <br /> It has been found that the calibration issue depends strongly on the orientation of the IMU module. <br /> <br /> '''Imu Orientation:''' In general, the z axis is more often wrong than the x and y axes.<br /> <br /> Of course, the care with which a calibration is performed very much affects the final quality results of the calibration. <br /> <br /> '''Calibration Accuracy:''' A 6-point calibration is meaningful only if it is done very accurately. A poorly undertaken 6-point calibration can easily result in poorer performance than a supposedly &quot;lesser&quot; 1-point calibration. The resulting quality factor under the 6-point calibration option can give a good indication as to the results (a value of 80 very good, 150 average, 250 not so good). <br /> <br /> From the above information these are rules of thumb to follow: <br /> <br /> '''Rules of thumb:'''<br /> * The calibration only needs to be as good as you need it to be. If you are happy with the way your gimbal performs, you don't need to spend time on a (better) calibration.<br /> * IMU orientations with the Z-axis pointing up or down seems preferable, as it lessens the need for calibration. But don't be fooled here, equally good results can be obtained for other orientation. Some of the best videos out there were in fact recorded with the imu's Z-axis in a horizontal orientation. It just means that with the Z-axis pointing up or down it's more likely that one can get away with a &quot;lesser&quot; calibration for a desired level of performance.<br /> * The calibration of the camera IMU is more important than for the 2nd IMU, i.e. for the 2nd IMU a &quot;lesser&quot; calibration might be fully sufficient. <br /> * The calibration of the 2nd IMU becomes more important as the motor pole count increases (e.g. 14 pole versus 22 pole). <br /> <br /> ⦁ Even though, for the reasons mentioned previously, a clear cut calibration recipe cannot currently be offered, although there are some recommendations in place: <br /> <br /> '''Current Recommendations:'''<br /> * A 1-point calibration is fairly simple, and is hence recommended for both the camera and the 2nd IMU. <br /> * If possible choose imu orientations with the Z-axis pointing up or down, but that's not a must as explained before. <br /> * Don't do a 6-point calibration unless you plan to do it very accurately (check out the rcgroups thread). <br /> * If motors with 12 or 14 poles are used, a 1-point calibration of the 2nd IMU is most likely sufficient. In contrast Higher-pole motors require a careful 2nd IMU calibration. <br /> <br /> '''Video Calibration Tutorial:''' Rcgroups user mackar made a great video on the 6-point calibration. Go to [[6-Point Calibration]].<br /> <br /> Finally, some important advice: <br /> <br /> Save your calibration data to a file! <br /> <br /> Ideally save it from within the Calibration dialog window, as this stores the most detailed information. Consider also, posting your calibration files in the rcgroups thread, so that the firmware author and others can enhance their knowledge and hopefully develop better calibration schemes.<br /> <br /> == Basic Controller Configuration ==<br /> The algorithms used in the STorM32 controller need to know some aspects of your gimbal in order to work correctly. If any of this information is incorrect, the controller will misbehave. Unfortunately, an incorrect setup will not always immediately reveal itself, but will lead to misbehaviour at a later stage, e.g. when a new function is activated, and therefore you might not associate it with the earlier faulty setup. So, please accept the following statement: <br /> <br /> Just because a setting seems to work correctly doesn't mean that it is correct!<br /> <br /> One implication is that adjusting the fundamental parameters by trial-and-error is the best approach in producing all sorts of non-obvious problems. Fortunately, a straight-forward setup procedure is available and if followed, guarantees correct settings. So, the above could be rephrased as &quot;Don't try to be smart, just shut up and follow the recipe&quot;. That's in fact the best advice possible here. <br /> <br /> The parameters we are talking about are those mainly contained under the &quot;Gimbal Configuration&quot; tab in the GUI:<br /> * Imu-1 Orientation<br /> * Imu-2 Orientation<br /> * Motor Poles<br /> * Motor Directions<br /> * Motor Startup Positions<br /> Some of these should be adjusted &quot;before&quot; the motors are activated, some can only be adjusted with the motors enabled. <br /> <br /> === Before the motors are enabled for the first time ===<br /> The Imu-1 and Imu-2 orientations and number of motor poles should be adjusted before the motors are activated, and the motor direction settings, initially set to Auto in order to find correct rotation directions. <br /> <br /> This is most easily done by using the &quot;Configuration Gimbal Tool&quot; option (accessible under the &quot;Gimbal Configuration&quot; Tab in the GUI), which is started by clicking on the respective button. Just follow the instructions step by step: <br /> <br /> * It will guide you through a simple procedure which determines the Imu-1 and Imu-2 Orientations.<br /> * It will then ask you to enter the number of poles of your motors. The number of poles for your motors should be available in the motor data sheets. For example, a 12N14P motor has 14 poles. The number of poles corresponds to the number of magnets, which you can be seen on the inner side of the motor bell. So, if in doubt you can quite easily determine the number of poles by simply counting the number of magnets. <br /> * Finally, as mentioned above, the Motor Direction parameters must be set to &quot;Auto&quot;. <br /> <br /> === After motors have been enabled for the first time ===<br /> With the Imu-1 and Imu-2 orientations, and motor poles set correctly, and the motor direction set to &quot;auto&quot;, one can enable the motors (all motors!) and start the gimbal. The controller should go through the initialization steps and level the camera (green led blinks), and then reach the &quot;Normal&quot; state (green led continuously On). Note: You can see what is happening by initiating and starting the &quot;Data Display&quot;. Once the &quot;Normal&quot; state is reached the Motor Directions and the Startup Motor Pos parameters can be set using the Tools tab: <br /> <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Get Current Motor Directions&quot; option. This will copy the auto determined motor directions into the Motor Direction fields. <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Get Current Pitch and Roll Motor Positions&quot; option. This will copy the current pitch and roll motor positions into the Pitch and Roll Startup Motor Pos parameter fields. <br /> * Click on the &quot;Tools&quot; menu tab and execute the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot;. This opens a dialog box which allows you to align the yaw axis such that the camera points to the forward position. Don't worry that the alignment being undone when closing the dialog box, this is normal as the just made adjustments become effective only after the next startup of the gimbal. <br /> Note! adjustments made in these steps only become Active after a restart of the StorM32 gimbal controller.<br /> <br /> == The Next Steps ==<br /> The next steps are to tune the PID parameters. It is not part of this Quick Guide, since the PID values are not fundamental for the controller to work correctly; they are (very) important for the performance. Once tuned, one can start to enjoy all the great and partly unique possibilities of the STorM32 controller.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=Quick_Start_Guide&diff=1659 2014-12-04T08:21:14Z

<p>Bruce356: /* Calibration */</p> <hr /> <div>On this page, I (OlliW) will briefly describe the initial steps which are required to set up the STorM32-BGC to function correctly. ''Descriptions refer to firmware v0.56.''<br /> <br /> '''Ultra-Quick Start Guide:'''<br /> * Use the &quot;Calibrate Acc&quot; tab to calibrate the imus.<br /> * Use the &quot;Configure Gimbal Tool&quot; to set the Imu1 Orientation, Imu2 Orientation, and Motor Pole parameters correctly, and to set the Motor Direction parameters to &quot;auto&quot;. <br /> * Use the &quot;Get Current Motor Directions&quot; option to set the Motor Direction parameters.<br /> * Use the &quot;Get Current Pitch and Roll Motor Positions&quot; option to set the Startup Motor Pos parameters for pitch and roll.<br /> * Use the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot; to align the yaw axis to point forward at startup.<br /> <br /> Below a somewhat less quick &quot;Quick Start Guide&quot; follows. It tells you what you need to know and what to do.<br /> <br /> == Supported Gimbals ==<br /> The STorM32 controller can currently be used for the following setups:<br /> * '''3-Axis with single Camera IMU:''' Only one IMU, connected to the I2C port and mounted to the camera, is used.<br /> * '''3-Axis with Camera &amp; on-board IMU:''' In addition to the camera IMU the StorM32 on-board IMU is used as a 2nd IMU. The StorM32 board must be mounted on the gimbal '''''above''''' the yaw motor. <br /> * '''3-Axis with Camera &amp; separate 2nd IMU:''' In addition to the camera IMU a further IMU connected to the I2C#2 port is used as 2nd IMU. The board can be mounted anywhere, but the 2nd IMU must be mounted on the gimbal '''''above''''' the yaw motor. <br /> * '''2-Axis:''' This is not &quot;officially&quot; supported but users figured out that the controller can be set up to work fine with a 2-axis gimbal (check the [http://www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups thread]). Only one Camera IMU is attached to the I2C port. The 2nd IMU is not supported in this configuration. <br /> Both the 3-axis and 2-axis gimbals with single IMU are obviously easier to set up since one doesn't need to be concerned about the 2nd IMU and what's required to get it working correctly. The following focuses on the 3-axis dual-IMU setups.<br /> <br /> == Preparation ==<br /> Things to know before starting: <br /> * Comprehend the [[Getting Started#Dos and Dont's|Dos and Dont's]].<br /> * Understand the importance of a proper gimbal mechanics, read [[Getting Started#The Gimbal|The Gimbal]] and especially [[Tuning_Recipe#Balancing the Gimbal|Balancing the Gimbal]]!<br /> * Get familiar with the board, inspect the [[Pins and Connectors]].<br /> * Use the latest firmware and GUI. To download the latest firmware package see [[Downloads]]. To flash the firmware to the board see [[How to flash firmware]]. Read the updates and installation instructions in the respective posts at the [http://www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups thread], also check these posts for known bugs.<br /> * Check that your setup matches one of the supported setups mentioned previously.<br /> * Understand the &quot;Read&quot;, &quot;Write&quot;, and &quot;Write+Store&quot; mechanism in the GUI.<br /> <br /> Finally, good advice:- Please take any recommendations from these links seriously!<br /> <br /> == Calibration ==<br /> The accelerometers within the IMU modules need to be calibrated for optimal performance (the gyros would also, but that's currently beyond reach). Several calibration techniques are available, and two are implemented in the STorM32 project, these are the &quot;1-point&quot; and &quot;6-point&quot; calibrations. <br /> <br /> Unfortunately, it is not absolutely clear as to which method is the best. This is because I don't have the resources for an extensive research project, this is what would possibly be needed for a determination. Hence, the situation currently is a bit experimental and might appear fuzzy to many users, but - on the positive side - knowledge and experience is increasing and therefore calibration procedures may improve with time. <br /> <br /> The reasons for a calibrating are different for the camera IMU versus the 2nd IMU. <br /> <br /> '''Camera IMU:''' Calibration mainly affects &quot;horizontal drift&quot;, i.e. the accuracy with which the horizon is held in quick yaw turns and other high-g manoeuvers. It also determines the accuracy of how well the camera is leveled, but this can in principle be tuned out easily by other means (e.g. offset parameters). The main concern is the performance in high-g manoeuvers. <br /> <br /> '''Second IMU:''' The measurement accuracy of the 2nd IMU is in itself not very important, it is however very important that the 2nd IMU data is consistent with the camera IMU, and it is even more important with higher poled motors e.g. poles greater than the basic 14 poles. <br /> <br /> It has been found that the calibration issue depends strongly on the orientation of the IMU module. <br /> <br /> '''Imu Orientation:''' In general, the z axis is more often wrong than the x and y axes.<br /> <br /> Of course, the care with which a calibration is performed very much affects the final quality results of the calibration. <br /> <br /> '''Calibration Accuracy:''' A 6-point calibration is meaningful only if it is done very accurately. A poorly undertaken 6-point calibration can easily result in poorer performance than a supposedly &quot;lesser&quot; 1-point calibration. The resulting quality factor under the 6-point calibration option can give a good indication as to the results (a value of 80 very good, 150 average, 250 not so good). <br /> <br /> From the above information these are rules of thumb to follow: <br /> <br /> '''Rules of thumb:'''<br /> * The calibration only needs to be as good as you need it to be. If you are happy with the way your gimbal performs, you don't need to spend time on a (better) calibration.<br /> * IMU orientations with the Z-axis pointing up or down seems preferable, as it lessens the need for calibration. But don't be fooled here, equally good results can be obtained for other orientation. Some of the best videos out there were in fact recorded with the imu's Z-axis in a horizontal orientation. It just means that with the Z-axis pointing up or down it's more likely that one can get away with a &quot;lesser&quot; calibration for a desired level of performance.<br /> * The calibration of the camera IMU is more important than for the 2nd IMU, i.e. for the 2nd IMU a &quot;lesser&quot; calibration might be fully sufficient. <br /> * The calibration of the 2nd IMU becomes more important as the motor pole count increases (e.g. 14 pole versus 22 pole). <br /> <br /> ⦁ Even though, for the reasons mentioned previously, a clear cut calibration recipe cannot currently be offered, although there are some recommendations in place: <br /> <br /> '''Current Recommendations:'''<br /> * A 1-point calibration is fairly simple, and is hence recommended for both the camera and the 2nd IMU. <br /> * If possible choose imu orientations with the Z-axis pointing up or down, but that's not a must as explained before. <br /> * Don't do a 6-point calibration unless you plan to do it very accurately (check out the rcgroups thread). <br /> * If motors with 12 or 14 poles are used, a 1-point calibration of the 2nd IMU is most likely sufficient. In contrast Higher-pole motors require a careful 2nd IMU calibration. <br /> <br /> '''Video Calibration Tutorial:''' Rcgroups user mackar made a great video on the 6-point calibration. Go to [[6-Point Calibration]].<br /> <br /> Finally, some important advice: <br /> <br /> Save your calibration data to a file! <br /> <br /> Ideally save it from within the Calibration dialog window, as this stores the most detailed information. Consider also, posting your calibration files in the rcgroups thread, so that the firmware author and others can enhance their knowledge and hopefully develop better calibration schemes.<br /> <br /> == Basic Controller Configuration ==<br /> The algorithms used in the STorM32 controller need to know some aspects of your gimbal in order to work correctly. If any of this information is incorrect, the controller will misbehave. Unfortunately, an incorrect setup will not always immediately reveal itself, but will lead to misbehavior at a later stage, e.g. when a new function is activated, and therefore you might not associate it with the earlier faulty setup. So, please accept the following statement:<br /> <br /> Just because a setting seems to work correctly doesn't mean that it is correct!<br /> <br /> One implication is that adjusting the fundamental parameters by trial-and-error is the best approach in producing all sorts of non-obvious problems. Fortunately, a straight-forward setup procedure is available and if followed, guarantees correct settings. So, the above could be rephrased also as &quot;Don't try to be smart, just follow the recipe&quot;. That's in fact the best advice possible here.<br /> <br /> The parameters we are talking about are contained under the &quot;Gimbal Configuration&quot; tab in the GUI:<br /> * Imu1 Orientation<br /> * Imu2 Orientation<br /> * Motor Poles<br /> * Motor Directions<br /> * Motor Startup Positions<br /> Some of them should be adjusted before the motors are activated, some can only be adjusted with the motors enabled.<br /> <br /> === Before the motors are enabled for the first time ===<br /> The Imu-1 and Imu-2 orientations and number of motor poles should be adjusted before the motors are activated, and the motor direction settings, initially set to &quot;auto&quot; in order to find correct rotation directiony.<br /> <br /> This is most easily done by using the &quot;Configure Gimbal Tool&quot; (accessible under the &quot;Gimbal Configuration&quot; tab in the GUI), which is started by clicking on the respective button. Just follow the instructions step by step:<br /> <br /> * It will guide you through a simple procedure which determines the Imu1 and Imu2 Orientation parameters. <br /> * It then will ask you to enter the number of poles of your motors. The number of poles for your motor should be available in the motor data sheets. For instance, a 12N14P motor has 14 poles. The number of poles corresponds to the number of magnets, which you can see on the inner side of the motor bell. So, if in doubt you can easily determine the number of poles by simply counting the magnets. <br /> * Finally, as mentioned above, the Motor Direction parameters are set to &quot;auto&quot;.<br /> <br /> === After motors have been enabled for the first time ===<br /> With the Imu-1 and Imu-2 orientations, and motor poles set correctly, and the motor directions set to &quot;auto&quot;, one can enable the motors (all motors!) and start the gimbal. The controller should go through the initialization steps and level the camera (green led blinks), and then reach the &quot;Normal&quot; state (green led continuously On). Note: You can see what is happening by initiating and starting the &quot;Data Display&quot;. Once the &quot;Normal&quot; state is reached the Motor Direction and the Startup Motor Pos parameters can be set using the &quot;Tools&quot; menu:<br /> <br /> * Go to the &quot;Tools&quot; menu and execute the &quot;Get Current Motor Directions&quot; option. This will copy the auto determined motor directions into the Motor Direction fields.<br /> * Go to the &quot;Tools&quot; menu and execute the &quot;Get Current Pitch and Roll Motor Positions&quot; option. This will copy the current pitch and roll motor positions into the Pitch and Roll Startup Motor Pos parameter fields.<br /> * Go to the &quot;Tools&quot; menu and execute the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot;. This opens a dialog box which allows you to align the yaw axis such that the camera points to the forward position. Don't worry that the alignment being undone when closing the dialog box, this is normal.<br /> <br /> The adjustments made in these steps become effective only at the next startup of the gimbal.<br /> <br /> == The Next Steps ==<br /> The next steps are to tune the PID parameters. It is not part of this Quick Guide, since the PID values are not fundamental for the controller to work correctly; they are (very) important for the performance. Once tuned, one can start to enjoy all the great and partly unique possibilities of the STorM32 controller.</div>

Bruce356 http://www.olliw.eu/storm32bgc-v1-wiki/index.php?title=Quick_Start_Guide&diff=1644 2014-12-03T13:37:34Z

<p>Bruce356: Minor alteration</p> <hr /> <div>On this page, I (OlliW) will briefly describe the initial steps which are required to set up the STorM32-BGC to function correctly.<br /> <br /> '''Ultra-Quick Start Guide:'''<br /> * Use the &quot;Calibrate Acc&quot; tab to calibrate the imus.<br /> * Use the &quot;Configure Gimbal Tool&quot; to set the Imu-1 Orientation, Imu-2 Orientation, and the Motor Poles correctly, and to set the Motor Directions to &quot;auto&quot;. <br /> * Use the &quot;Get Current Motor Directions&quot; option to set the Motor Directions.<br /> * Use the &quot;Get Current Pitch and Roll Motor Positions&quot; option to set the Startup Motor Pos parameters for pitch and roll.<br /> * Use the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot; to align the yaw axis to point forward at startup.<br /> <br /> Below a somewhat less quick &quot;Quick Start Guide&quot; follows. It tells you what you need to know and what to do.<br /> <br /> == Supported Gimbals ==<br /> The STorM32 controller can currently be used for the following setups:<br /> * '''3-Axis with single Camera IMU:''' Only one IMU, connected to the I2C port and mounted to the camera, is used.<br /> * '''3-Axis with Camera &amp; on-board IMU:''' In addition to the camera IMU the Storm32 on-board IMU is used as a 2nd IMU. The Storm32 board must be mounted on the gimbal ~Above~ the yaw motor. <br /> * '''3-Axis with Camera &amp; separate 2nd IMU:''' In addition to the camera IMU a further IMU connected to the I2C#2 port is used as 2nd IMU. The board can be mounted anywhere, but the 2nd IMU must be mounted on the gimbal ~Above~ the yaw motor. <br /> * '''2-Axis:''' This is not &quot;officially&quot; supported but users figured out that the controller can be set up to work fine with a 2-axis gimbal. Only one Camera IMU is attached to the I2C port. The 2nd IMU is not supported in this configuration. <br /> Both the 3-axis and 2-axis gimbals with single IMU are obviously easier to set up since one doesn't need to be concerned about the effects of the 2nd IMU and what's required to get it working correctly. The following focuses on the dual-IMU setups. <br /> <br /> == Preparation ==<br /> Things to know before starting: <br /> * Comprehend the [[Getting Started#Dos and Dont's|Dos and Dont's]].<br /> * Understand the importance of a proper gimbal mechanics, read [[Getting Started#The Gimbal|The Gimbal]] and especially [[Tuning_Recipe#Balancing the Gimbal|Balancing the Gimbal]]!<br /> * Get familiar with the board, inspect the [[Pins and Connectors]].<br /> * Use the latest firmware and GUI. To download the latest firmware package see [[Downloads]]. To flash the firmware to the board see [[How to flash firmware]]. Read the updates and installation instructions in the respective posts at the [http://www.rcgroups.com/forums/showthread.php?t=2055844 rcgroups thread], also check these posts for known bugs.<br /> * Check that your setup matches one of the supported setups mentioned previously.<br /> * Understand the &quot;Read&quot;, &quot;Write&quot;, and &quot;Write+Store&quot; mechanism in the GUI.<br /> <br /> Finally, good advice:- Please take any recommendations from these links seriously!<br /> <br /> == Calibration ==<br /> The accelerometers of the IMU modules need to be calibrated for optimal performance (the gyros too, but that's beyond reach). Several calibration techniques are known, and two of them are implemented in the STorM32 project, called 1-point and 6-point calibration. <br /> <br /> Unfortunately, it is not finally clear what method is the best. This is because not much useful info is in the web and I don't have the resources for an extensive research project on this, but this is what would be needed. Hence, the situation is currently a bit experimental and might appear fuzzy to many users, but - to also have a good message - the knowledge and experience increases and calibration procedures might improve with time.<br /> <br /> The reasons for a calibration are different for the camera and the 2nd IMU.<br /> <br /> '''Camera IMU:''' The calibration mainly affects the &quot;horizont drift&quot;, i.e. the accuracy with which the horizont is hold in quick yaw turns and other high-g maneuvers. It also determines the accuracy of how well the camera is level, but this could in principle be tuned out easily by other means (e.g. offset parameters). The main concern is the performance in high-g maneuvers.<br /> <br /> '''Second IMU:''' The measurement accuracy of the 2nd IMU is by itself not very important, it is however very important that the 2nd IMU data is consistent with the camera IMU, and it is the more important the higher the number of motor poles is.<br /> <br /> Some insights have been made so far.<br /> <br /> '''Imu Orientation:''' As a general trend, the z axis is much more wrong than the x and y axes. <br /> <br /> '''Calibration Accuracy:'''<br /> A 6-point calibration is meaningful only if it is done very accurately. A poorly undertaken 6-point calibration can easily result in a poorer performance than a supposedly &quot;lesser&quot; 1-point calibration. The quality factor can give an indication.<br /> <br /> From that these rule of thumbs follow:<br /> <br /> '''Rules of thumb:'''<br /> * The calibration only needs to be as good as you need it to be. If you are happy with how your gimbal works, you don't have to spend time on a (better) calibration. <br /> * IMU orientations with the z-axis up or down seem preferable, as it lessens the need of a calibration. But don't get fooled here, equally good results can be obtained for any orientation. Some of the best videos out there were in fact recorded with the IMU's z axis horizontal. It just means that with the z axis up or down it's more likely to get away with a lesser calibration for a desired level of performance.<br /> * The calibration of the camera IMU is more important than for the 2nd IMU, i.e. for the 2nd IMU a &quot;lesser&quot; calibration might be fully sufficient.<br /> * The calibration of the 2nd IMU is the more important the higher the motor pole count is. <br /> <br /> Even though, for the reasons mentioned before, a clear cut calibration recipe cannot be offered currently, some recommendations seems at place:<br /> <br /> '''Current Recommendations:'''<br /> * A 1-point calibration is fairly simple, and is hence recommended for both the camera and 2nd IMU.<br /> * If possible choose IMU orientations with the z-axis up or down, but that's no must as explained before.<br /> * Don't do a 6-point calibration if you don't plan to do it really accurately (check out the rcgroups thread). <br /> * If motors with 12 or 14 poles are used, a 1-point calibration of the 2nd IMU is most likely sufficient. High-pole motors require in contrast a careful 2nd IMU calibration.<br /> <br /> '''Video Calibration Tutorial:''' Rcgroups user mackar did a great video on the 6-point calibration. Go to [[6-Point Calibration]].<br /> <br /> Finally, this important advice: <br /> <br /> Safe your calibration data to a file! <br /> <br /> Ideally safe it from within the Calibration dialog, as this stores the most detailed information. Consider also to post your calibration files in the rcgroups thread, so that I and others can enhance our knowledge and hopefully develop better calibration schemes.<br /> <br /> == Basic Controller Configuration ==<br /> The algorithms used in the STorM32 controller need to know some aspects of your gimbal in order to work correctly. If any of this info is wrong, the controller will misbehave. Unfortunately, an incorrect setup will not always reveal itself immediately, but will lead to misbehavior at a later stage, e.g. when a new function is activated, and you might not associate it to the earlier faulty setup. So, accept this:<br /> <br /> Just because a setting seems to work correctly doesn't mean that it is correct!<br /> <br /> One implication is that adjusting the fundamental parameters by trial-and-error is the best approach to produce all sorts of non-obvious problems. Fortunately, a straight-forward setup procedure is available, which guarantees correct settings, if followed. So, the above could be rephrased also as &quot;Don't try to be smart, just shut up and follow the recipe&quot;. That's in fact the best advice possible here.<br /> <br /> The parameters we are talking about are those centralized in the GUI's &quot;Gimbal Configuration&quot; tab:<br /> * Imu1 Orientation<br /> * Imu2 Orientation<br /> * Motor Poles<br /> * Motor Directions<br /> * Motor Startup Positions<br /> Some of them should be adjusted before the motors are activated, some of them can only be adjusted with the motors enabled.<br /> <br /> === Before motors are enabled first time ===<br /> The Imu1 and Imu2 orientations and motor poles should be adjusted before the motors are activated, and the motor direction settings prepared properly.<br /> <br /> This is most easily done by using the &quot;Configure Gimbal Tool&quot;, which is started by hitting on the respective button in the tab. Just follow it step by step:<br /> <br /> * It will guide you through a simple procedure which determines the Imu1 and Imu2 Orientations. <br /> * It then will ask you to enter the number of poles of your motors. The motor pole number you should find in the data sheet of the motors. For instance, a 12N14P motor has 14 poles. The number of poles corresponds to the number of magnets, which you can see in the inner side of the motor bell. So, in case of doubt you can easily determine the number by just counting the magnets. <br /> * Finally, the Motor Direction parameters are set to &quot;auto&quot;.<br /> <br /> === After motors were enabled first time ===<br /> With the Imu1 and Imu2 orientations, and motor poles set correctly, and the motor direction set to &quot;auto&quot;, one can enable the motors (all motors!) and start the gimbal. The controller should go through the initialization steps and level the camera (green led blinks), and reach the &quot;Normal&quot; state (green led goes continuous). Note: You may watch what's going on by running the Data Display. Once the &quot;Normal&quot; state is reached the Motor Directions and the Startup Motor Pos parameters can be set:<br /> <br /> * Go to the &quot;Tools&quot; menu and execute the &quot;Get Current Motor Directions&quot; option. This will copy the auto determined motor directions into the Motor Direction fields.<br /> * Go to the &quot;Tools&quot; menu and execute the &quot;Get Current Pitch and Roll Motor Positions&quot; option. This will copy the current pitch and roll motor positions into the Pitch and Roll Startup Motor Pos parameter fields.<br /> * Go to the &quot;Tools&quot; menu and execute the &quot;Adjust Yaw Startup Motor Pos Parameter Tool&quot;. It opens a dialog which allows you to align the yaw axis such that the camera points to the forward. Don't worry about the fact that the alignment is undone with closing the dialog, that's how it is.<br /> <br /> The just made adjustments become effective only at the next startup of the gimbal.<br /> <br /> == Next Steps ==<br /> The next step is to tune the PID parameters. It is not part of this Quick Guide, since the PID values are not fundamental for the controller to work correctly; they are though (very) important for the performance. Once tuned, one can start to enjoy all the great and partly unique possibilities of the STorM32 controller. :)</div>

Bruce356