5
\$\begingroup\$

I have a 1 axis (x) spinning platform, that is spinning pretty fast ~300 RPM. I want to be able to detect with a good degree of precision how many degrees it has travailed from its starting position and the speed it is currently trailing at.

For example: Think of a clock that has a single min hand. The hour hand travels across the face of the clock and I want to measure where it is on the clock face at any given time in degrees.

"3" o-clock it would be 90 degree, "6" o-clock it would be 180 degree, "9" o-clock it would be 270 degree, "12" o-clock it would be 0 degree,

I have both of these sensors

My questions are:

  • Can I use a Gyro or Accelerometer to accurately measure how much rotation has occured on a spinning platform?
  • Is there a better sensor to use to determine rotation in degrees such as a Compass Module - HMC6352
  • Can you use a Gyro or Accelerometer to measure RPM?
\$\endgroup\$
2
  • \$\begingroup\$ I did a project where we tried to compensate for blimp rotation about the z-axis using that exact compass module but could not get anything close to reliable. I would not recommend using that module for anything but determining your current heading. \$\endgroup\$
    – dhsieh2
    Commented Jun 20, 2011 at 8:40
  • \$\begingroup\$ That compass will work fine if your statement "1 axis" is 100% accurate as in there is absolutely no tilt in the other dimensions. If tilt is a problem and you still want to go with the compass solution, the HMC6343 provides a similar device with tilt compensation. \$\endgroup\$
    – NickHalden
    Commented Jun 20, 2011 at 18:32

4 Answers 4

10
\$\begingroup\$

For a problem like this you typically use an optical incremental encoder. Depending on the type it gives a series of pulses per revolution, so your resolution will depend on this number. It also gives you information on the rotation direction. You can find speed by timing the period of time between pulses.
See also this answer for more information on how incremental and absolute encoders work.

If you can't find a suitable encoder, and your motor runs smoothly, it may be sufficient to have just one pulse per revolution. The current position can then be derived from the time since the last pulse divided by the time between pulses (= rotation period). Just like the optical encoder you want a non-contact solution. Optical is one possibility. Use a reflective sensor (like Vishay CNY70) to detect a small reflective area on an otherwise matte disc (or vice versa). A magnetic solution is also possible, and often used in dirty environments where the optical sensor won't work. A small magnet on the motor's shaft will cause a Hall effect sensor (like Infineon TLE4913) to give a pulse each time it passes.

You would think the gyro would be ideal because it gives you angular velocity. To find rotation, however, you have to integrate angular velocity over time, and it's not always easy to maintain accuracy because you also integrate error which will become larger and larger, unless there's a way to recalibrate every rotation.
Like I commented to Mike, when using an accelerometer and a motor which isn't mounted vertically the accelerometer will respond to the earth gravitation and superimpose this as a sine wave to the reading from the centrifugal acceleration. This has to be filtered out, but can also be used to count rotations directly: you get 1 sine cycle per revolution.
important attention point:
Both a gyro and an accelerometer would have to be mounted on the shaft, and you will have to deal with the problem of wiring power and readings to a fixed position.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ I would be careful with the Hall effect solution. I implemented that in a project recently and ran into a ton of errors. First, the hall effect sensor has a very small sensitive area so either your magnet will have to be very strong OR it will have to be positioned very well. If you have any tilt this can again be an issue because the path the magnet traces will look like a circle with a low frequency low amplitude sine wave superimposed on it. I recommend using 2 magnets 180 degrees apart from each other and a latching hall effect sensor. The first magnet turns it on and the... \$\endgroup\$
    – NickHalden
    Commented Jun 20, 2011 at 18:38
  • \$\begingroup\$ second magnet turns it off. They have to have opposite polarities obviously but this allows for more consistent results. At 300 RPM I could definitely see that being a problem, just a heads up. \$\endgroup\$
    – NickHalden
    Commented Jun 20, 2011 at 18:40
3
\$\begingroup\$

While a gyro in theory gives you information to get the answer, in practise the angle will have so much error after a few seconds as to be useless. MEMs gyros put out a signal indicating rotation rate. This needs to be integrated to get angle. However, offset, drift, and other errors will continuously accumulate in the integral. For most MEMs gyros, the result is useless after a second or a few seconds.

Note that real mechanical gyros don't have this problem since they inherently give a angular position signal, not angular rate. However, they are big, klunky, take significant power, are expensive, and need to be "caged" for a minute to 10s of minutes with no motion to calibrate them before use.

If the rotation rate is reasonably constant, a tick once per revolution is good enough. I've worked on several rotating LED signs where that was the only information on position. The system assumed each rotation would take the same time as the previous rotation. The display did get stretched during turn on when the motor was accellerating, but it worked quite well at steady state.

Just this spring I advised a high shool student that wanted to do something similar. I gave him a single opto-interrupter, which he used to compute the time per rotation and generate the pixel clock for the next rotation. His motor was a large fan lying on its side on the floor, with the board battery powered and mounted in the middle. It spelled out "2011 SENIOR PROJECT" using 7 LEDs, and everyone was quite suitably impressed.

If the shaft is horizontal you can use a accellerometer to measure rotation speed and get some idea of the current angle by watching gravity.

Depending on how the motor works, you could possibly have the motor driving electronics report position regularly. If it's a brushless DC and you have access to the controller, this information is available.

Communicating to the rotating board from outside can be done several ways. In the rotating LED sign, we used a hollow shaft with a IR LED on the fixed end and a photodiode on the rotating end. This was used as a one way data stream at about 1Mbit/s. Getting power to the rotating board is also interesting. The high school student used batteries. That was easy and worked fine for his presentation. One version of the LED sign needed 70W and had to run continuously, so that wasn't possible. We used a transformer where the primary and secondary could rotate with respect to each other. This was driven by a switcher at high frequency. A small secondary winding on the fixed side was used for feedback, and the rotating secondary was regulated well enough. There was a additional switching power supply on the rotating board to trim the power loss in driving the RGB LEDs to as little as possible.

\$\endgroup\$
2
  • \$\begingroup\$ The way I did in my project (youtube.com/watch?v=v6fGjcZuSXI) was to use the motor shaft and a wrapped wire as a brush system. It would be even better to have a spring system rather than a wire wrap but it should work fine. The top shaft was GND and the bottom shaft was +5V. You can also use insulating shaft couplers to build multiple layers of conduction if you need a communication channel or multiple voltages. It's an extremely simple method for prototyping and very expandable. \$\endgroup\$
    – NickHalden
    Commented Jun 20, 2011 at 18:45
  • \$\begingroup\$ Oh, I also just found electronics.stackexchange.com/questions/11946/… which is a lot better than the one I implemented \$\endgroup\$
    – NickHalden
    Commented Jun 20, 2011 at 18:47
2
\$\begingroup\$

RPM is usually calculated using a tachometer system whereby a pulse is generated once (sometimes twice - see CPU fans) for each revolution. These are then counted over a predetermined period and the RPM calculated from that.

As for the position in the rotation, that's more tricky. Because of the rotation speed you are using there's not alot that springs to mind to accurately report the rotational position - not that is fast responding enough to get it right.

If you know the rotational velocity (RPM) fairly accurately, then you can calculate how far it has rotated past a known point in the time elapsed - for instance how long since the last tachometer pulse - to give a fairly accurate position if the velocity is constant.

Another option would be to have multiple sensors in a ring around the axis and a point of reference on the axis which passes these sensors - be it magnetic, or optical, - but that only gives a limited resolution. These are known as Absolute Optical Encoders (or Absolute Magnetic Encoders, if you are using magnetism).

Optical Incremental Encoders, like the kind used in mouse wheels etc, are one way of doing it, but it doesn't give an absolute position, only a relative one, so you'd need to couple it with some absolute reference point as well.

\$\endgroup\$
7
  • 1
    \$\begingroup\$ @Matt - There are also absolute encoders which will give you the (surprise!) absolute position. Follow the link in my answer for details. \$\endgroup\$
    – stevenvh
    Commented Jun 20, 2011 at 8:30
  • 1
    \$\begingroup\$ @stevenvh That's basically what paragraph 4 of my answer describes, but doesn't name it as such. \$\endgroup\$
    – Majenko
    Commented Jun 20, 2011 at 8:33
  • \$\begingroup\$ @Matt - OK, basically you're right, but that's not the way absolute encoders usually work. (Maybe that's why I missed it.) The reason is that it would be terribly expensive to get high resolution; you wouldn't want to place a thousand sensors around the shaft. Common absolute encoders would obtain the same resolution using just 10 sensors. \$\endgroup\$
    – stevenvh
    Commented Jun 20, 2011 at 11:07
  • \$\begingroup\$ Well, yes, I guess they have 1 rotational start sensor and a small number of incremental sensors that offset the value from the start? \$\endgroup\$
    – Majenko
    Commented Jun 20, 2011 at 11:43
  • \$\begingroup\$ @Matt - yes, that is if you mean by "a small number of incremental sensors" just one. :-) That's all you need if you don't mind doing an extra rotation to find the reference point. \$\endgroup\$
    – stevenvh
    Commented Jun 20, 2011 at 11:48
1
\$\begingroup\$

Measuring angular velocity is exactly what the gyro does. In the case of your gyro the output will be full-scale at a rate of 300 deg/sec. A linear accelerometer could also measure angular velocity if aligned towards the axis of rotation since acceleration = \$r\omega^2\$, ie angular velocity \$\omega=\sqrt{\frac{acceleration}{radius}}\$but this would be less convenient.

To measure angular displacement you would need to integrate the angular velocity over time and you will have difficulty getting accurate results over long time periods due to offset & drift.

\$\endgroup\$
10
  • \$\begingroup\$ @MikeJ-UK: the acceleration detected by the acceleration sensor is due to the centrifugal force, but this is constant, so you can't measure rotation this way. \$\endgroup\$ Commented Jun 20, 2011 at 9:20
  • \$\begingroup\$ @Federico Russo: The force would be proportional to the square of the angular velocity. \$\endgroup\$
    – MikeJ-UK
    Commented Jun 20, 2011 at 9:33
  • \$\begingroup\$ Yes, and if the motor runs smoothly that's constant. \$\endgroup\$ Commented Jun 20, 2011 at 9:55
  • \$\begingroup\$ @Federico Russo: Of course, and the output of a gyro would also be constant at constant angular velocity which is what the OP was asking in his third bullet-point. To get angular displacement he would need to integrate this, hence my comment about drift. \$\endgroup\$
    – MikeJ-UK
    Commented Jun 20, 2011 at 10:15
  • \$\begingroup\$ OK, got it, my apologies. I was focusing on a signal which would vary with rotation, such that you would directly get RPMs. Good point about drift. \$\endgroup\$ Commented Jun 20, 2011 at 10:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.