Angular Speed Sensor
Project Overview
I’ve taken a bit of a diversion in the RC Truck Project to work through some lower level details. One of these details is creating a speed encoder for the motor and designing a Kalman Filter for the speed estimate. A key piece to this is the angular speed encoder itself. This can be accomplished in a number of ways. I’ve chosen to investigate two of them as options for this project.
General Architectures
In practice, there are many different ways to design this system. I’m not particularly concerned with any top level design objectives at this point. I mostly just want a sort of noisy sensor (otherwise the filtering problem is a little boring)
A purely mechanical tachometer used to be a common solution in vehicles. The principal of operation relies on the flyball governor, originally used for speed control on steam engines!
There are numerous designs which can generate a voltage which scales with the rotational speed. This is often done using some form of magnets and coil windings. The voltage can be read and converted by an analog-to-digital converter. The scaling needs to be calibrated in the software. There are a number of difficulties with this design from the “cleanliness” of the reference voltage to limitations on the precision of the ADC.
This design uses a hardware-based, pulse counting strategy. In this case, the number of pulses per revolution is known, the sampling time is fixed or at least can be measured. The microcontroller or single board computer can periodically read the value from the counter, divide by the time between readings, and voila - rotational speed.
The last case is the one used in this project. It’s very similar to the pulse counting method except in this case, the uC or SBC uses software interrupts attached to a hardware pin to count up the number of ticks and calculate the speed. The downside here of course is the dependence on the software to do the work.
The Electronics: Digital Tick Encoders
Wait a second! Shouldn’t the title of this section be “speed encoder” and not tick encoder? All of these speed encoders I’m working on for this project are the software style tick counters I described above. For this experiment I chose two designs to investigate. One design uses a light gate to generate the pulses (ticks) and the second design uses a hall effect sensor.
There are two main designs I tried for this experiment. One design embedded magnets into the wheel and utilizes a simple hall effect sensor. This sensor output is nominally high and drops low in the presence of a magnetic field.
The light gate design uses a common IR emitter-detector pair with regularly spaced slots in the wheel. Examples of the printed designs are below.
Sensor Performance
Turn that noise down and get off my lawn! Okay, I’m not that old yet, but just like grump curmudgeons, robots like sensors with very little noise. A very high performance sensor in many cases only needs very little filtering to have a high quality signal. For evaluating the sensor design I 3D printed several variations for both types of encoders. In each case I’m simply increasing the number of ticks per revolution. The goal was to understand and characterize the noise as a function on both ticks per revolution and current motor speed.
Generally speaking, the higher the ticks per revolution the higher the precision of what can be measured for angular displacements, which for the case of a speed estimate affects what frequencies of speed change that we can detect. As a thought experiment, an encoder with only one tick per revolution can’t detect any speed changes which happen in the course of a single revolution. If we had a very powerful motor that could adjust it’s speed infinitely fast (infinite acceleration and deceleration capability), we could speed it up and slow it down to extreme speeds, but not detect it. There are some very smart people who have mathematically quantified this. If you’re interested, take a look at the Nyquist Theorem.
So, there is some math that can help us estimate the performance of these different set ups. What does the math say? I’m not sure, but a month in the lab can save a day in the library, so why don’t we just jump into the experiments?
Sensor Noise
Now that the basic set up is explained, let’s look at some data. I ran the motor in a series of step commands and held the motor and a constant command and sampled the speed a number of times. So in theory if the system were perfect, the value sampled at the fixed command should be same each time. Spoiler - it’s not. But that’s okay and to be expected. There are probably variations in the output of the cheap ESC that I’m using and then some noise in the motor itself along with the sensing noise. For now I’m rolling that all up into the sensor noise. In the plot below, the results of both the IR sensor and the Hall effect sensor are shown. The plots on the left show the motor speed as a function on the input command. Overall, the motor speed scales very linearly, as I found before. The plot on the right shows the standard deviation of the motor speed as a function of the current motor speed. In other words, the trend is that as the motor speed increases, the noise increases as well. This seems to fit intution.
In order to make the plots a bit easier to read. The values averaged across all the runs are shown below. Now the trends are a bit easier to see. First, a couple observations.
For a single tick per revolution, the sensor type seems irrelevant.
There is a reduction of speed variance starting from the minimum motor speed when speeding up. The trend soon reverses.
The Hall effect sensor variance increases with tick count much more quickly than the IR sensor.
The 2 tick and the 8 tick hall effect are both the noisiest sensors.
So why might some of this be? Well it seems fairly intuitive that with only 1 tick per revolution, the sensor type doesn’t matter so much.
I think at the absolute lowest motor speed, that the motor noise itself is coming into play. For this effect, I believe the motor speed is in fact fluctuating a fair amount to some physical effects where the motor just barely has enough voltage to move. This is probably not sensor noise
The fact that the speed variance increases with tick count and current motor speed might have one of a few answers. It could be an artifact of the particular sensors being used. This seems to be a reasonable explanation why the Hall effect sensors quickly become noisier. For the small test wheels, the strong magnets are quickly in proximity to one another. Though I’ve not investigated, I image that the magnetic fields soon overlap and create some inconsistencies with the response of the sensor itself.
For the IR sensor, there are two other possible explanations which are worth exploring. As the tick count and or speed increase, the rate of pulses, and therefore software interrupts, begins to increase as well. For the 21 tick wheel at 6,000 RPM, this is only 0.5 milliseconds between ticks. I’m currently running these experiments on a Raspberry Pi, SBC Linux computer which are known to be somewhat limited in their capability to handle time well for sub-millisecond events. This is one hypothesis for the root cause of the noise. The second hypothesis is that with the higher tick count, actual speed fluctuation is able to more easily be observed. Running the motor at high speed with virtually no load, may simply be indicative of the cheap hardware that I’m using and not having a stable open loop speed characteristic.
For both of these hypotheses, there are a few future experiments which I may run. Regarding the software noise, I may switch to a dedicated microcontroller design, which should be much better at handling the high frequency events. The second test, which can be done with the current configuration, is to add a flywheel or some sort of load to help stabilize the system.
