In a previous blog post, we started the process of using the Altair portfolio of simulation software to design the subsystems for a small robotic car and then build it in the real world. We will continue that project in this blog, as we add the ability to measure the speed of the motor and begin applying control logic to the driving motor portion of this vehicle.
To accomplish this on our test bed, we will need to include some new hardware. This will include adding a speed encoder to the wheel attached to the drive motor, adding a system to generate an oscillating signal from this encoder, and finally adding a system to decode this frequency as a voltage that can be interpreted as a linear speed. The first two parts of this list, the encoder and frequency generator, actually go hand in hand, as they will be tied into one subsystem together. We will place an encoder wheel on the tire of the car, which will include alternating and evenly sized reflective and non-reflective sections, as shown in Figure 1 below.
Fig 1. Encoder wheel mounted to wheel and drive motor.
To extract the useful information from this encoder wheel, we will implement a component called an “arrowhead” sensor (its part number is OPB704WZ, to be specific). This device is an optocoupler containing an infrared LED and a photosensitive transistor. Figure 2 below shows the packaging of this device, as well as the circuit schematic representation. We will then point the LED and light sensor of the arrowhead at the encoder wheel; as the encoder rotates with the motor, the LED will shine its infrared light on the alternating reflective and non-reflective portions, causing the transistor to open and close in tandem with the rotation. This will generate an oscillating voltage across the output resistor that we can measure.
Fig 2. Physical OPB704WZ (left); OPB704WZ schematic (middle); OPB704WZ connections (right).
We will simulate this portion of the circuit using the default optocoupler model in Altair PSIM, shown in Figure 3 below. While this device doesn’t technically function the same as the arrowhead sensor we have on hand, it is close enough for our demonstrative purposes. Instead of modelling the change in reflection, we will simply assume the LED is always reflecting properly into the transistor, but we will toggle the LED on and off. Our toggling frequency will require some manual experimentation to identify the range of frequencies we can expect from our arrowhead-encoder subsystem, but we will start with an assumption of 50 Hz for the initial simulation.
Fig 3. Altair PSIM simulation of OPB704WZ input (green) and output (red).
Now we will verify or correct the frequency assumption by directly reading the frequency generated on the arrowhead sensor when pointed at our encoder wheel on the DC motor. Figure 4 below shows the experimental results at a relatively high speed. With this information on hand, we can eventually begin to convert this ‘rough’ square wave into a measurable speed. We can see that these real-world results closely match the shape of the results simulated in PSIM, with the addition of some noise, which is to be expected.
Fig 4. Physical output of OPB704WZ.
We will use the measurement tools within the oscilloscope to determine the frequency of the encoder wheel at this motor speed. Figure 5 below shows that one cycle (one reflective to non-reflective section) takes approximately 69 ms, so our frequency is about 14.4 Hz.
Fig 5. Measured frequency of one cycle of output of OPB704WZ.
However, we can see that not all ‘high’ values (reflective areas) are the same, which is likely due to inconsistencies in the size of the reflective and non-reflective portions of the encoder wheel. In this project, the wheel was created by hand, so some inconsistencies are not completely unexpected, but it is something an engineer would need to address before moving to full-scale production. To account for this inconsistency in the measurement, we can look at the time and frequency over an entire rotation of the wheel, which is equivalent to 4 cycles of reflective to non-reflective sections. Figure 6 below shows that the approximate frequency is 3.5 Hz, which is very close to our 14.4 Hz when multiplied by 4 to find the frequency of an individual cycle.
Fig 6. Measured frequency of four cycles of output of OPB704WZ (one complete tire rotation).
We can re-check the simulation in PSIM using the updated measurements from the benchtop test. Figure 7 below shows the measured output of the simulation at approximately 14.4 Hz (the value measured in the real world above). Again, we can see the same general shape on the output at a more realistic frequency.
Fig 7. Updated PSIM simulation using approximate max frequency from benchtop test.
We know that the minimum frequency is 0 Hz (if the motor is stopped and not spinning at all), and we have experimentally found that our maximum frequency of the encoder is around 15 Hz. We can now use this information to devise a plan to measure and interpret this frequency to correspond to a more tangible speed value; in other words, we will develop a tachometer. Finally, we can see how all of these subsystems begin to interact when we connect everything. We will follow the following steps:
- Attach the encoder wheel to the tire and motor.
- Connect the motor to the buck converter we created in the previous blog post.
- Position the arrowhead sensor to point directly at the encoder.
- Implement a system to measure the frequency provided by the arrowhead sensor.
- Calibrate the tachometer and prepare it as a feedback for measurement and control.
- Measure the relationship between the motor voltage and the tachometer output.
Now we have a measurable motor speed system. I intentionally left out the word “control” at this stage because everything is still ‘open-loop,’ and there is no feedback or control logic. However, you can see the relationship between the supply voltage across the motor, and the measured frequency of the arrowhead. Lastly, since we know the number of repeated reflective and non-reflective sections of the encoder per full rotation, and we know that we can convert Hz to rad/sec, we can derive a relationship between the motor voltage and the angular velocity of the wheel. Furthermore, we can use the angular velocity and the radius of the wheel to calculate a linear velocity, which will be necessary to continue with the future stages of this project.
For anyone who wishes to follow along in a similar project, there are a few key aspects to be aware of that may cause issues. There are some obvious ones, such as ensuring that integrated circuits and sensors are connected correctly. Additionally, always ensure to check datasheets for maximum operating conditions of each device to ensure that you won’t damage or destroy components. More specific to this exact configuration, you will need to make sure that the arrowhead sensor is extremely close to (but not touching) the encoder wheel to ensure reliable frequency measurements.
We now have everything we need to design and implement a closed-loop speed control system for our DC motor. In our next blog, we will take full advantage of Embed to close the loop, devise a control scheme, and execute everything on a microcontroller. Make sure to check our blogs and YouTube channel routinely for updates on this project, as we will continue to use the power of Altair simulation to expedite the design and experiment process of building this robotic car. As always, please do not hesitate to reach out directly to us with any questions or comments!
Submit a comment