Hi Austin,
Here are some links that I think are relevant to your questions:
- Collecting Sensors Data Using Raspberry Pi
- Changing Speed Of T100 Thruster
- https://www.kernel.org/doc/Documentation/i2c/smbus-protocol
I like your idea, and I appreciate the in-depth explanation of the problem you are trying to tackle. I have some questions and some thoughts that I think you should consider.
Are you going to use a gyroscope/accelerometer on your quadcopter?
What should matter is not the absolute speed of the rotors, but the lift that it is actually producing, and the lift that the rotors are producing relative to each other. 4 rotors, each spinning at a constant exact 5000 RPM is probably not going to keep your quadcopter level. Each rotor will produce slightly different amount of lift based on factors that vary locally at each rotor like imperfections of the propeller, shaft alignment, turbulence, air pressure, and vibration.
Multirotors generally work by measuring their attitude, or orientation, and adjusting the error between the desired and measured attitude by telling the different motors to ‘speed up’ or ‘slow down’, in relative terms. I can’t think of any advantage you would gain in telling a motor that you know is spinning at 5000RPM to speed up by telling it to spin at 5250RPM, rather than just saying spin a little bit faster than you are currently spinning. One advantage that knowing the current RPM would provide is that you would be able to detect if a motor has stopped spinning and be able to crash more gracefully (or less violently 
).
A digital accelerometer/gyroscope can be interrogated very quickly and give you an accurate measurement of the copter’s current attitude. The way the RPM counter on the BlueESC works is by counting rotations since the last time you interrogated it. The faster you interrogate it, the less accurate and less useful this information becomes. If you interrogate the RPM on the BlueESC once per minute, the BlueESC may return 5000 RPM, and you can be pretty confident that it is in fact spinning at 5000RPM, on average. However, if you interrogate it at 100Hz, then it may return 42 rotations for one 10ms interval, and 54 the next. On average, the rotor is spinning at 5000 RPM, but when you sample in very small intervals you will probably get noisy results, which won’t be useful for what you want to do.
Beyond that, +/- 50 RPM seems like a very good tolerance to me when the rotor is spinning at many thousand RPM.
Some code that should help you figure out how to get the motor speed (I don’t know what language you are using). You should also take a look at the Arduino example code on the Blue Robotics github:
uint8_t lowBits;
uint8_t highBits;
highBits = read_byte_data(0x29, 0x02);
lowBits = read_byte_data(0x29, 0x03);
uint16_t pulseCount = (highBits << 8) | lowBits;
(RPM = pulseCount/dt*60/motor_pole_count)
Some code that should help you write the throttle value:
int16_t throttle = 12345;
uint8_t throttleLow = throttle & 0x00FF;
uint8_t throttleHigh = throttle & 0xFF00;
write_byte_data(0x29, 0x01, throttleLow);
write_byte_data(0x29, 0x00, throttleHigh);
It would be better to read/write a word at a time rather than a byte at a time, but there are some nuances relating to smbus and the way that the BlueESC registers are arranged that I won’t get into for now.
-Jacob