Ben's Blog

No description yet.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Archives
    Archives Contains a list of blog posts that were created previously.
  • Login
    Login Login form

DC Motor Controller (3) - Measuring a Motor's Speed Using an Optical Encoder

Posted by on in DC Motor Controllers
  • Font size: Larger Smaller

When most of us get to grips with applying power to a DC motor, to watch it spin round, usually our next task is to determine how fast it is spinning that is, determine it's speed of rotation. There are many different ways of measuring a DC motor's speed including using an optical encoder. Before using a FPGA to automate the task we firstly measured the DC motor's speed of rotation by connecting the digital and analog outputs of a photo-sensor board to an oscilloscope. What we discovered during this first phase of measurements is the subject of this blog post.  


The DC motor that I used in this experiment, to measure a DC motor's speed, is the one that I have described in a previous post. The experimental set-up used can be seen in the Figure above. Apart from the motor itself the set-up consists of a DIY optical encoder, as well as a photo-sensor or photo-interrupter. The motor is connected to a variable power supply that has a voltage range of between 0V and 30V, which can supply a maximum current of 5A. A similar supply is used to power the photo-sensor, although the circuit board it resides on only requires 5V and a few milliamps of current. 

Optical encoder construction

My major concern when I first thought about undertaking this project was the best way to construct the optical encoder. Although I had already bought some OHP transparencies for both laser and inkjet printers, I wasn't quite sure about how to most conveniently create the encoder pattern to print on them.

Initially, I though about using Adobe Illustrator, but the idea had too many holes in it, to be viable. Then while, probably, over-thinking about what to do I had a so-called Eureka! moment. Many moons ago, when I used LaTeX to type up my thesis, I came across a package called PSTricks. A package principally used to embed graphs and diagrams in LaTeX documents, in programmable manner. Could this package be used to create optical encoder patterns in an accurate and repeatable way?

Once I had worked out the segment of code required using PSTricks I quickly made short work of putting together an empty LaTeX document, which I populated with the fragment of LaTeX code seen below.

\multido{\ri=0+15, \rj=7.5+15}{24}
\pscircle[linecolor=red](0,0){1mm} %Inner circle to aid drilling.

This fragment of text produces the pattern seen, on the right-hand side, in the image below, which consists of 24 black and white (transparent) pairs of wedges. When the output of the LaTeX document is saved to a .pdf file the pattern can be conveniently printed onto a transparency. In my case I printed the pattern onto the inkjet OHP transparencies, using an EPSON WF-2530 set to its highest monochrome print settings.


To maximise the use of the transparency I first printed the output of the LaTeX document on to regular A4 paper. I then cut a square of transparency that was slightly larger than the pattern and stuck the transparency, with Sellotape, over the pattern. I then re-printed the document to locate the pattern on the transparency.

This efficient use of the transparency meant that I could experiment quite freely with a variety of patterns without being concerned about the amount of transparency I was using. This efficient use was especially appreciated when occasionally I printed on the wrong side of the transparency, which for your reference is the shinny side (i.e you print your image on the matte side!).

The optical encoder patterns produced using the inkjet OHP transparencies were so good that I didn't have to fall back to plan B and repeat the exercise using the laser printer. The second pattern on the left in the image above was created by replacing the second line of the fragment of code listing above with the line below

\multido{\ri=0+7.5, \rj=3.75+7.5}{48}

This produced the 48 black and white (transparent) wedge pairs seen of the pattern on the left-hand side, in the image above. The experimental results discussed below were accumulated when the first of the two patterns is used.

 Optical Encoder Construction

A block diagram of the layout of the experimental set-up can be seen in the Figure below. Once I had attached the optical encoder, item (2) to the DC motor's, (1), shaft (3) it became quite apparent the whole construction was quite flimsy. The biggest problem seemed to be how to reliably set the photoelectric sensor, (4) to accommodate the DC motor's vibrations. Once this problem was solved measurements were recorded by monitoring both the analog and optical outputs, (5), of the  sensor by using an oscilloscope.


To reliably locate the sensor, I settled for the set-up described previously and repeated in the Figure below, for clarity. In this image it can be seen that the photo-sensor, (4), is attached to a metal bracket. I did this by using hot-glue. The bracket was the attached to a block of wood, which was used to dampen the DC motor's vibrations. I also used hot glue to do this.


Finally, the whole construction was clamped to a vice and the output of the photo-sensor (or photo-interrupter) was monitored using two channels of an oscilloscope. The typical output of the sensor board can be seen in the oscilloscope plot below. Channel 1, the green plot, corresponds to the digital output, while Channel 2 is the analog one. The digital output, which is typically the output of a LM311 comparator on these devices, measures 5V when the sensor's IR transmitter is blocked from its IR receiver. Conversely, it measures 0V when there is transmission between the IR's transmitter and receiver. Correspondingly, for this particular measurement the analog output of the sensor measures 3.3V and 0V respectively.


In this plot (above) there are 2.00ms per time division, thus one black and transparent wedge pair, of the optical encoder pattern, rotates in 2.4ms. Hence, a single 360 degrees rotation of the optical encoder occurs in 24 x 2.4 ms or 57.6 ms. Now, since the period, T,  of 1 rotation is 57.6ms, then the frequency, f,  is 1/T or 17.36 revolutions per second i.e 17.36Hz. Therefore, in this particular case the motor is rotating at 17.36 revolutions per second x 60 seconds or approximately 1042 rpm.

Results and Analysis

In the previous plot the peak analog voltage is comparatively high, because the transition between the transparent and black wedges is slow, at 1024rpm. As the motor speed is increased towards the constant voltage of 13V, the value in the DC motor's datasheet, the voltage reduces and the analog pulse is not sustained long enough to trigger the comparator. This occurs because the receiver sees the transmitted IR signal for a smaller period of time and as a consequence produces a corresponding smaller amount of current.

Hence, for this particular pattern of 24 alternating black and transparent wedge pairs, at modest rotational speeds there is no digital output. To remedy this situation the number of wedge pairs, used to construct the optical encoder, could be reduced to allow longer transitions between them, which would correspondingly increase the analog voltage output of the sensor.

To corroborate our results the DC motor's supply voltage is experimentally set to 8.5V and 13V, two values found in the datasheet. Also, for all experiments the motor is considered to be minimally loaded with a coupler, an extension shaft and a small quadcopter's propeller. When the motor's supply voltage is set to 8.5V it consumes approximately  0.18A of current. At this setting the motor rotates with a frequency of 51.628Hz or with a period of 19.369ms. Therefore when 8.5V is applied to the DC motor's input terminals it rotates at 51.628 x 60 revolutions per minute or approximately 3098 rpm, which is remarkably close to the 3000 rpm, under no load conditions, quoted in the datasheet. These results are depicted in the plot below.


Another useful figure quoted in the DC motor's datasheet is the no load speed of 4580 rpm at 13V. When I set the DC motor's supply voltage to 13V it rotated with a period of 12.945ms or at a frequency of 72.252Hz. This means that at this supply voltage the motor rotates at a speed of 72.252Hz x 60s or 4335 rpm, which again is remarkably close to the quoted figure of 4580 rpm. The plot below shows this result. Note that at this speed the digital voltage cannot be read, (1), and secondly that some aberrations, (2), occur when the optical encoder rotates too close to either the sensor's transmitter or receiver.



I would like to classify the result of conducting this experiment as an unmitigated success. This is not only because of the corroboration of the results obtained with those in the datasheet, but also because of the discovery of the technical aspects of the wedge pairs of the optical encoder. Before I started this project I was focused on developing the optical encoder pattern without thinking too much about the effect it has on the analog output voltage relative to the DC motor's speed. 

One of the findings of the experiment is that the choice of the number of wedge pairs should be determined by the range of speeds that are anticipated to be measured. Also, it may be prudent not to buy a ready made circuit, but a photo-sensor on its own. Then, an analog circuit can be designed to amplify the sensor's output to suit one's needs. Also, an ADC is likely to be needed in a real system to measure the analog voltage.

The main problem encountered, while conducting this experiment, was in the precision required to mount the optical encoder. The fragility of the optical encoder, constructed from the OHP transparency, could be replaced with a more sturdy version printed with a 3D printer.

The next stage of this project will be to use a DC motor controller, like the L298N,  connected to a FPGA to control the speed of a motor with feedback being provided by an optical encoder. However, I suspect that rather than using the digital output to provide feedback the analog output should be read by an ADC connected to the FPGA. This sounds like a job that is perfect for the DE0-Nano or the Cyclone V GX Starter Kit.

Last modified on