Thank you for the very interesting implementation of a device for balancing rotors. However, one should take into account that, despite the dynamic measuring principle, it is only a static balancing. Because it is only balanced in one plane of rotation, this is completely sufficient for flat rotors such as propellers. As you mentioned at the end of this video, for rotors with an extension in the axial direction, two balancing planes would be required. This is why the balancing weights on car wheels are attached to both rim flanges. In summary, one could say, that a static imbalance alternatively could also be measured statically, whereas a dynamic imbalance has a three-dimensional effect and requires a dynamic measuring principle and counterweights or balancing holes at two planes.
You’re absolutely right, I just reread the Wikipedia article on dynamic balance. I hope the static balance will be enough for these. It’s not hard to figure out the additional planes, but it’s always the testing and verification that take forever.
While looking at it, it's a pretty simple "machine", but the service it provides is invaluable. Just putting a "balanced" tire on the instrument will let you know that any car handling issues are not a balancing issue. Thank you for the ideas and code. Super shoulders to stand on.
If I recall, depending on the gain that the IMU is set to, it will map the acceleration between +-2G, 4G, 8G, or 16G (where G is 9.81m/s^2) to the whole range of the numerical type you're using. There's a super easy way to check/calibrate it: Just turn the device on its side to get the force of gravity, and then its opposite side to get the force in the opposite direction. The average of those two forces is the zero-point, and the range is 2G.
Yes, the sensor does map to those ranges. I actually use the calibration in the MPU6050 library that runs at startup to zero out the static readings. I’m not sure how this works internally, but thus far it’s fairly accurate. It’s hard because I know there’s so many things that could be improved/optimized with a better sensor.
Neat stuff! I love that this sort of tech is so readily available for us hobbyists now. While obtaining the knowledge is still the major barrier to entry, if you're willing to learn, you can make just about anything yourself. Thanks for another interesting video, can't wait for more!
@@IndeterminateDesign You call it esoteric. For an Instrumentation engineer taking care of gearbox manufacture it is called day job. Only the size is weird and I would miss the noise of the V8 (once even a W12) :D.
Agreed, I really love absolute angle sensors. I just didn't have one on hand that was fast enough. I had an AS5600 but that drops out at a few hundred rpm. I really need something like an AS5047P or the like. If you download my cad you'll see there's actually already a hole below the motor for mounting the magnet.
Wow, thanks so much, very detailed. I am trying to replicate this with slightly different code, but having trouble with consistency of results, which makes me think that the interrupt condition (I am using FALLING) does not always trigger, so it skips a pole and slips - and then the accelerometer measurements don't correspond to the poles. Did you have any troubles like that?
Yes, I had that issue sometimes. In the videos I have a pair of magnets mounted in place of where a prop would bolt. I pre-balanced that assembly. I also noticed using a larger motor works better. Ultimately when I did a traction control setup on an RC car I used the DRV5015 hall sensor which is latching. That way it only flips state when the opposite pole magnet on the motor passes by. It’s very consistent at high rpm. An encoder like an AS5047P would work even better but they’re a bit more money.
@@IndeterminateDesign Thank you, more debugging coming. I also thought about using a gimbal motor where we know and control the angle without external sensors.
Will your code run on an arduino 2560, uno r3 or nano? And will it work for balancing props too? Also what program did you write this in? Doesn't look like arduino.
The code is Arduino, but I use VSCode and PlatformIO. The code should run on other Arduino compatible boards. I think the servo library I used will have to be swapped out as it’s specific to the ESP32 but the code is the same. It should work for balancing propellers. I based it off a design someone else on RUclips had come up with for balancing propellers. I’m not sure the ideal RPM for that use case. You’ll need to play with it most likely by adding some tape to one side of the prop and testing to see if it’s accurate enough.
Ah, life just gets in the way and not enough hours. I’m hoping to isolate the individual problems I’m facing with the streamliner and active suspension into some of these more manageable smaller projects which will allow for more focused and frequent updates.
Yes, I think that would increase accuracy. You would need to apply an offset of -90 degrees. I didn’t try it, because I never found in my research whether the 1khz limit was a sensor limitation or an I2C bus limit (I2C being the protocol used to communicate with the MPU6050).
I'm sure you could, but I don't know much about interfacing with a piezo sensor. I know that full size tire balancers use them so they must be fairly accurate. The main reason I picked the MPU6050 for mine was just the price and simplicity of use.
Thank you for the very interesting implementation of a device for balancing rotors. However, one should take into account that, despite the dynamic measuring principle, it is only a static balancing. Because it is only balanced in one plane of rotation, this is completely sufficient for flat rotors such as propellers. As you mentioned at the end of this video, for rotors with an extension in the axial direction, two balancing planes would be required. This is why the balancing weights on car wheels are attached to both rim flanges. In summary, one could say, that a static imbalance alternatively could also be measured statically, whereas a dynamic imbalance has a three-dimensional effect and requires a dynamic measuring principle and counterweights or balancing holes at two planes.
You’re absolutely right, I just reread the Wikipedia article on dynamic balance. I hope the static balance will be enough for these. It’s not hard to figure out the additional planes, but it’s always the testing and verification that take forever.
While looking at it, it's a pretty simple "machine", but the service it provides is invaluable. Just putting a "balanced" tire on the instrument will let you know that any car handling issues are not a balancing issue. Thank you for the ideas and code. Super shoulders to stand on.
If I recall, depending on the gain that the IMU is set to, it will map the acceleration between +-2G, 4G, 8G, or 16G (where G is 9.81m/s^2) to the whole range of the numerical type you're using.
There's a super easy way to check/calibrate it: Just turn the device on its side to get the force of gravity, and then its opposite side to get the force in the opposite direction. The average of those two forces is the zero-point, and the range is 2G.
Yes, the sensor does map to those ranges. I actually use the calibration in the MPU6050 library that runs at startup to zero out the static readings. I’m not sure how this works internally, but thus far it’s fairly accurate. It’s hard because I know there’s so many things that could be improved/optimized with a better sensor.
A little bit over my head as I do not have an engineering background but this is EXCELLENT!
Thanks!
Great job again man, the best prints are those in service of other prints :) Appreciate your narration voice as well.
Neat stuff! I love that this sort of tech is so readily available for us hobbyists now. While obtaining the knowledge is still the major barrier to entry, if you're willing to learn, you can make just about anything yourself. Thanks for another interesting video, can't wait for more!
Thanks so much! I’m glad people enjoy learning about these more esoteric topics.
@@IndeterminateDesign You call it esoteric. For an Instrumentation engineer taking care of gearbox manufacture it is called day job. Only the size is weird and I would miss the noise of the V8 (once even a W12) :D.
Sick! Thanks for sharing your work!
My pleasure!
Really cool! Thanks for sharing the details!
Very interesting setup and video :-)
Nice.
I can only recommend hall effect 360 absolutele angle sensor, which would be easier to read and no zeroing is required.
Agreed, I really love absolute angle sensors. I just didn't have one on hand that was fast enough. I had an AS5600 but that drops out at a few hundred rpm. I really need something like an AS5047P or the like. If you download my cad you'll see there's actually already a hole below the motor for mounting the magnet.
Very very nice work.
This is awesome info. Great video! Can I send you a 3d printed part to balance for me so I don't have to try and build one of these? lol
Wow, thanks so much, very detailed. I am trying to replicate this with slightly different code, but having trouble with consistency of results, which makes me think that the interrupt condition (I am using FALLING) does not always trigger, so it skips a pole and slips - and then the accelerometer measurements don't correspond to the poles. Did you have any troubles like that?
Yes, I had that issue sometimes. In the videos I have a pair of magnets mounted in place of where a prop would bolt. I pre-balanced that assembly. I also noticed using a larger motor works better.
Ultimately when I did a traction control setup on an RC car I used the DRV5015 hall sensor which is latching. That way it only flips state when the opposite pole magnet on the motor passes by. It’s very consistent at high rpm.
An encoder like an AS5047P would work even better but they’re a bit more money.
@@IndeterminateDesign Thank you, more debugging coming. I also thought about using a gimbal motor where we know and control the angle without external sensors.
Will your code run on an arduino 2560, uno r3 or nano? And will it work for balancing props too? Also what program did you write this in? Doesn't look like arduino.
The code is Arduino, but I use VSCode and PlatformIO. The code should run on other Arduino compatible boards. I think the servo library I used will have to be swapped out as it’s specific to the ESP32 but the code is the same.
It should work for balancing propellers. I based it off a design someone else on RUclips had come up with for balancing propellers. I’m not sure the ideal RPM for that use case. You’ll need to play with it most likely by adding some tape to one side of the prop and testing to see if it’s accurate enough.
Great videos, only issue is not enough updates. Is there anything we can do to help you make more videos?
Ah, life just gets in the way and not enough hours. I’m hoping to isolate the individual problems I’m facing with the streamliner and active suspension into some of these more manageable smaller projects which will allow for more focused and frequent updates.
Ive always wondered how those worked 🤔
Would measuring the acceleration in the x direction double the sampling rate?
Yes, I think that would increase accuracy. You would need to apply an offset of -90 degrees. I didn’t try it, because I never found in my research whether the 1khz limit was a sensor limitation or an I2C bus limit (I2C being the protocol used to communicate with the MPU6050).
I did not understand what does this device measure, what imbalance in the wheel ?
Yes, this measures the imbalance in the wheel or really anything you mount to the motor.
Could i also use a piezo sensor instead of an accelerometer ?
I'm sure you could, but I don't know much about interfacing with a piezo sensor. I know that full size tire balancers use them so they must be fairly accurate. The main reason I picked the MPU6050 for mine was just the price and simplicity of use.
Ok thanks for your answer!