diff --git a/README.md b/README.md index e3594c560d1e42dfd5d996c1f4fa3ef89d38907b..6552e4f698102c4b0cd29047349975063eddea6c 100644 --- a/README.md +++ b/README.md @@ -16,12 +16,14 @@ In machining the smaller targets on the ShopBot Desktop, I noticed that some cop ### Accuracy -From the plots below, it would appear that I am acheiving about +/- 1.25deg of accuracy without calibration. On paper this is much worse than I was hoping for. With a 1.8deg step size for a stepper, acheiving at least +From the plots below, it would appear that I am acheiving about +/- 1.25deg of accuracy without calibration. On paper this is much worse than I was hoping for. With a 1.8deg step size for a stepper, acheiving at least 25% accuracy of a full step would be critical, so closer to +/-0.5 deg accuracy. With that said if we look closer at the error data, it is clear that it's highly repetitive between pole pitches. This tells us what's already expected, which is that our accuracy is interpolation limited (on the sensor side). Our interpolation technique assumes a perfectly sinusoidal signal, which is not going to be the case given the physical parameters of the system, and so a calibration should be applied in the form of a lookup table to smooth out some of this error. I made a quick attempt at this in the "Calibrated" Error plot below, by simply taking the first pole transition and subtracting its error from the first and second pole pairs. I didn't have the data bandwidth to do this very well, but given how repeatable the error is, I suspect it should be possible to get that error down to below the 0.5 deg range, or closer to the +/- 0.25 deg error suggested by the repeatability plot. -It's worth noting that the AMT encoder that I am using as a reference is rated to [0.25 deg of accuracy](https://www.cuidevices.com/product/resource/amt10.pdf). So we are definitely within the right order of magnitude for a commercial product. The spec is also ambiguous in that it doesn't specify a +/- +It's worth noting that the AMT encoder that I am using as a reference is rated to [0.25 deg of accuracy](https://www.cuidevices.com/product/resource/amt10.pdf). So we are definitely within the right order of magnitude for a commercial product. The spec is also ambiguous in that it doesn't specify a +/- or full scale accuracy, but I believe it's +/-.  +[<img src="images/encoderError.png" width="800">] +  One big question I had was if EMF from the motor would manifest as noise at the sensor, which fortunately seems to not be the case at all. Noise levels did not change with the motor running or not running, and the error down to +/- 0.25 deg appears highly repeatable. To test this, I ran the motor through a full 720 deg sweep, and then took the difference between errors in the first and second revolution, by manually lining up the data. Ignore the +0.25 deg offset, as that's just a result of my lining things up poorly. @@ -34,7 +36,7 @@ I definitely beleive there's some sort of potential for cross talk between the t [<img src="images/encoderCouplingLargeGap.png" width="800">] -With respect to speed, my SPI bus is clocked at only 3MHz, and transactions are currently taking 50us to transfer two 24 bit integers on a single SPI line. With a 50us transaction, I am able to resolve new rotor angles at 20kHz. A few steps I will take to increase speed are to break out each sensor onto its own SPI bus, which halves the total communication time. I can also increase the SPI bus to 8MHz, and chop off some of the dead time between bits and chip select lines. At the end of the day I believe it should be possible to increase the angular position refresh rate to closer/above 50kHz, which would correspond to a well commutated stepper motor spinning at 15kRPM (well above what any stepper is capable of, so this bandwidth is more useful for BLDCs). +With respect to speed, my SPI bus is clocked at only 3MHz, and transactions are currently taking 50us to transfer two 24 bit integers on a single SPI line. With a 50us transaction, I am able to resolve new rotor angles at 20kHz. A few steps I will take to increase speed are to break out each sensor onto its own SPI bus, which halves the total communication time. I can also increase the SPI bus to 8MHz, and chop off some of the dead time between bits and chip select lines. At the end of the day I believe it should be possible to increase the angular position refresh rate to closer/above 50kHz, which would correspond to a well commutated stepper motor spinning at 15kRPM. This is well above what any stepper is capable of, so this bandwidth is more useful for BLDCs, where with a larger pole pitch this bandwidth should allow for smooth commutation into the upper 10k's. [<img src="images/SPItransaction.png" width="800">] diff --git a/images/calibratedError.png b/images/calibratedError.png new file mode 100644 index 0000000000000000000000000000000000000000..f845676674d795ceebb236543fd6dd87691d65b5 Binary files /dev/null and b/images/calibratedError.png differ