Designing a Speed Measurement System Using Altair Embed

In a series of previous blog posts, we have been using the power of Altair to simulate the necessary subsystems of a small robotic car as we progress through the process of constructing it in the real world.

Previously, we designed and constructed an encoder subsystem so that we can generate a square wave representing the angular frequency of the drive tires. Figure 1 shows a reminder of the encoder we created and the output of this portion of the project. In this post, we will continue this work to transform this signal into useful information. This will involve two main steps: devising a method to read the frequency from the encoder and converting that frequency into a linear velocity.

Fig 1. Encoder Wheel (left) and encoder subsystem output signal (right).

Step One: Reading Frequency from the Encoder

There are many approaches available to convert this signal into a linear speed; a common approach for this scale of project is to use a frequency-to-voltage converter. The integrated circuit (IC) that I had on hand for this task was an LM2907, which can be used, in conjunction with a simple circuit of passive elements, to convert a known frequency range to a known voltage range in a linear fashion. The sample schematic for this circuit is shown in Figure 2 below. However, this encoder outputs a relatively low frequency (approximately 15 Hz at max speed), which makes it challenging to use the LM2907 due to the very large values needed for passive components.

Fig 2. Sample tachometer schematic using LM2907 IC.

Instead, we will use a digital approach to measure this signal. We can get a very good approximation using a microcontroller to read the time between peaks in our encoder output signal. We will use Altair Embed to assist in the design and simulation of this measurement. Embed is a powerful software that uses a ‘block diagram’ interface to create and analyze the performance of embedded systems, and it has true hardware-in-the-loop (HIL) simulation capabilities. To begin this phase, we will use the software to generate a representative square wave in place of the output of the encoder. Figure 3 shows the signal that we will use, and there are a few things to note: we can use a combination of the multiplication and summing junctions to scale the square wave to the same range as our real-world values (2 V – 5 V), and there is no noise in this simulated signal. That is acceptable for our purposes, as we will only consider when the signal switches from a high voltage to a low voltage.

Fig 3. Simulation setup in Altair Embed to generate encoder output.

To extract the useful information from this signal, we will implement a crossing detection block, and we will specify the crossover value to be halfway point between the two extremes of the input signal (3.5 V is the middle of 2 V and 5 V). Traditionally, this block will produce a positive value if the signal is going up when it crosses 3.5 V, and a negative value when it is decreasing through the crossover value. We are only interested in seeing one ‘spike’ per cycle, so we will limit this output to remain positive. Figure 4 depicts this setup, comparing the input signal and the output cycle detector; we can use a variable block to save this signal as “0x-trigger” or our ‘zero-crossing’ trigger, which generates a pulse for each whole cycle.

Fig 4. Pulse train generated by cycle detection in encoder signal in Altair Embed.

Now, we can design perhaps the most intricate part of this subsystem: the period approximator. For this, we will take the pulse train (“0x-trigger” signal) from earlier, and introduce some new logic. First, we will use a Sample & Hold (S&H) block with the 0x-trigger signal and a ramp signal that increases linearly with time (i.e., the value of the ramp is equal to the current time relative to the start of the simulation). This will generate an output equal to the “real-world” time for each pulse of the 0x-trigger. Next, we will use the 0x-trigger again and the output of the S&H as inputs to the Unit Delay (1/Z) block. This will allow us to preserve the “real-world” time value from the pulse immediately preceding the current pulse from the 0x-trigger.

With these pieces of information, we now have the time values for two consecutive pulses, and taking the difference between them will provide us with the time between them, which is equal to the period of our encoder signal. Figure 5 depicts the Embed schematic to accomplish these calculations. You will also notice that we add a very small value to the period and calculate the inverse. The small value is to ensure that we do not divide by zero when inverting the period, and the inversion provides the measured frequency of the encoder wheel in Hertz.

Fig 5. Frequency measurement operators in Altair Embed.

In Figure 5, it is difficult to see the measured wheel frequency (red line), as it very closely matches the true frequency set by the “wheelFreqHz” variable (brown line), so a display has been added to view the exact calculated value. We know that our system is working as anticipated, as the measurement states 14.9925 Hz, which is very close to the actual value of 15 Hz. Finally, we will convert this frequency into a linear speed using the equation below. The ¼ comes from the fact that the encoder wheel has the pattern repeated 4 whole times in one rotation of the wheel, and the remainder of the calculation is a trivial conversion from rotations per second to linear velocity using the circumference (the diameter d [m] multiplied by π). With the diameter measured to be 0.065 m, and the encoder frequency at a maximum of 15 Hz, this will yield a linear speed of 0.766 m/s, or roughly 77 cm/s.

Step Two: Implementation and Conversion to Linear Velocity

We are now ready to implement this logic into the real-world device. We can do this by using the Code Generation capabilities of Embed to automatically create the code that will execute our designed logic. The software will consider many aspects, such as the target device (which kind of microcontroller you are using), any inputs or output pins on the target device (which can be defined within the block diagram), and any custom logic implemented via block diagrams. Figure 6 below shows an example of automatically generated code based on the schematic we have created so far.

Fig 6. Automatic Code Generation in Altair Embed.

Now it is time to test the code with an actual input signal. For this initial test, I provided an input of a 12 Hz square wave oscillating from 2 V to 5 V. Figure 7 displays the measured frequency (in Hz) of this signal. Each line on the output is generated on each new rising edge, as defined in the Embed schematic. We can see some slight variation in the results, which is most likely due to the fact that we are handling multiplication and division using numbers with many decimal places, such as the timestamps we are using to find the time between pulses. We can also see that the initial measurement is very low (~0.0004), which is due to the fact that this is the first pulse measured, so it has no actual previous time value to determine the period and subsequent frequency.

Fig 7. Output of Frequency Estimator when true frequency is 12 Hz on microcontroller.

To get a better understanding of how this measurement works in the real world, Figure 8 shows the comparison of the true input frequency and the calculated frequency using our devised logic. To demonstrate its capabilities, the input frequency increases over the time frame of the trial. This shows that the speed measurement is fast and accurate enough for our system.

Fig 8. Comparison of True and Measured Frequency over a range of values on microcontroller.

Similarly, we can convert these frequencies values to a linear speed using the equation mentioned earlier. Figure 9 displays this information, which, as expected, is effectively the same as Figure 8, but the y-axis now shows us the linear speed of the wheel. This allows us to understand how fast the car will potentially be moving once all the parts are put together.

Fig 9. Comparison of True and Measured velocity over a range of values on microcontroller.

We now have everything we need to close the loop on our motor control! We will incorporate this speed measurement as feedback to compare against a desired speed, which will allow our microcontroller to implement the necessary control scheme to adjust the buck converter powering the drive motors accordingly. Once that is complete, we will be ready to tackle the steering system in a similar approach, but we will need to use different inputs and feedback. Be sure to check out our blog often and subscribe to our YouTube channel to stay up to date on this project, to learn about more tips and tricks in Altair Embed and other tools, and to see how the powerful suite of Altair engineering software can help you!