DIY Dynamic Wheel Balancer, Mark 2

[pmbrunelle]

I found a PCB-mount switch that looks like it would belong on a computer power supply; rated for 100 A inrush (typo?). Perfect. So now I am working on the main shaft quadrature encoder.

The Mk1 encoder is optical, based around a toothed disk. 2x (90 deg out-of-phase for quadrature) slot-type photo-interrupters containing an LED on one side and a light detector on the other side turn on or off depending on the presence of a tooth to block the light beam. There is also a third photo-interrupter which reads a single once-per-revolution reference hole. This produces the index pulse. I have come to realize that a wheel balancer encoder does not really require an index pulse...

However, in Mk2, the mechanical setup could allow the main shaft to move axially, which would crash the disk into the photo-interrupter. The movement would only happen if you exceeded the ~200 lbf bearing preload in one direction (pulling the shaft out), and the movement would be on the order of 0.1".

So, I have been looking at making a magnetic quadrature encoder based on an ABS reluctor (tone?) ring. With this concept, even if the main shaft moves axially, the encoder will probably continue to operate correctly! The basic idea is to have a fixed permanent magnet (perhaps two?) facing the reluctor ring. Then, Hall-effect sensors in the gap measure the magnetic flux density, which depends on the presence of a tooth or gap facing the magnet.

From my preliminary study, which included some analysis in FEMM, I think this type of encoder will have some challenges:

• The presence of a tooth will only increase the flux density by perhaps a factor of two at best.
  
• The nominal flux density will vary, and sensitivity or switchpoint tolerances for Hall-effect sensors are not too good.
  
• Tolerances in general will be all over the place, so analog-output Hall sensors will be required. Then, their outputs will go to comparators, which will need to have their trigger points trimmed for 50% duty cycle in the output pulse train.
  
• Concentricity of the ring with the main shaft could be an issue, because this will cause airgap (significant or not?) changes.
  
• Crosstalk between both quadrature channels may be an issue.
  
• Encoder must be zero-speed capable without losing counts, so a coil pickup is not possible.
  
• Allegro makes a nice gear-tooth Hall-effect sensor with an integrated magnet (with automatic gain control and all sorts of wizardry), but I am not sure if it handles direction changes correctly.
  

If I stay optical, it may be possible to buy photo-interrupters with a greater slot width, so that the disk could move axially 0.1" within the slot and not damage anything. Since I expect to lose the index pulse in Mk2, it should be much easier to shop for photo-interrupters without the constraint of finding one that is index-compatible.

[pmbrunelle]

So I think I have a reasonable concept for an optical quadrature encoder.

It uses a 32-hole disk and two two transmissive IR photo-interrupters. Ideally, I would like to use photo-interrupters with the analog and Schmitt trigger stuff integrated (open-collector output), so I can just wire the photo-interrupters directly to the microcontroller's pins and off I go with bounce-free pin change interrupts.  The packaging and assembly order is way better than with the large diameter toothed disk in my previous post:
https://www.eevblog.com/forum/projects/diy-dynamic-wheel-balancer-mark-2/msg803372/#msg803372

There will only be 128 positions compared to the Mk1's 256 positions, but I feel that 128 will be sufficient for a wheel balancer. Essentially, I've divided the disk diameter and tooth count by two, so the optical window width has not really changed.

Mechanically, it's easier to put the photo-interrupters close to each other. However, to prevent optical crosstalk, the photo-interrupters should be widely separated. So there are some contradictory requirements... For now, I drew what I felt "looks about right".

Does anyone have experience with photo-interrupters located close to each other? I am concerned that crosstalk may be a problem. Is this a geometric exercise to make sure the detector of one channel can never see the LED of the other channel?

In a very worst-case, since the RPM is not too high, I could do a time-division multiplexing scheme:
Turn on channel A LED
Sample channel A detector
Turn off channel A LED
Turn on channel B LED
Sample channel B detector
Turn off channel B LED
Repeat

But I really don't want to go down this road...

[jeroen74]

Why are you designing your own optical encoder? You can buy these! You can get them up to thousands of lines per rotation, with single-ended or RS422 outputs, with or without index etc.

If a complete off-the-shelf device does not cut it, use something like an Avago HEDS-9740 and a Avago codewheel.

http://www.anaheimautomation.com/manuals/forms/encoder-guide.php

[pmbrunelle]

I don't want to change the shaft (direct carryover from Mk1), so the encoder disk needs to install on one of these shaft diameters:
1.000 in +/- uncontrolled tolerance (was a non-functional surface)
1.373 in +/- uncontrolled tolerance (was a non-functional surface)
1.632 in +/- uncontrolled tolerance (was a non-functional surface)

Shaft (total) endplay: approx. 1.6 mm

Just these two parameters (bore size and endplay) restrict the possibilities of off-the-shelf encoders that will "fit". And then there are two kinds of "the part fits":
1. The part fits with lots of fiddling around and a wacky assembly order
2. The part fits well, the assembly order is easy, no adjusting required

I can cut my own code wheel for near free from plastic scrap, and I plan to use two photo-interrupters at ~7 USD each:
http://optekinc.com/datasheets/opb900-913.pdf

So I expect this solution will be way cheaper... but more importantly, I prefer to DIY. Maybe this is because I am a beginner, but I liked writing a "driver" for the HD44780 display (fine-tuned to the Mk1 balancer's requirements); I don't only want to focus on the "business" front-end application code. I don't think you can become an expert without having been involved in the low-level details. Once you have experience with embedded systems, then there's less value in redoing the same boring display driver stuff over and over again. But I am not at that level of expertise yet.

For a quadrature encoder, the sensors need to be separated by an (arbitrary) odd integer number of angular counts; this will give you the 90 deg phase shift between the channels.

I want to have the minimum separation between the sensors without having crosstalk. I considered separating the sensors by:
7 counts (looks close for crosstalk)
9 counts
11 counts
13 counts (large cutout in the steel tube may reduce stiffness, and the sensors could need to be installed at an angle)

Based on the 0.050 in aperture widths on the OPB900 series photointerrupters, and probable worst-case tolerance errors in the sensor mounting and code disk dimensions, I believe that 11 counts separation is the hot ticket.

It is the minimum separation for which no light ray from the LED of channel A can reach the detector of channel B (or vice versa) through a hole in the code disk. I just need to bench test this encoder configuration before committing to putting it in the Balancer Mk2.

[Kilrah]

Maybe a stupid question, but why not use an accelerometer in place of the problematic load cells? Seems to be the most common method used for these applications, as long as the mechanics are half decent noise should be negligible.

Iterative methods are common on processes where material is removed (e.g. model jet engines, even if the balancing machine says "remove 3mg of metal at 270°" it's still a guy grinding into the part with a tool, i.e. he will necessarily remove either too little or too much material requiring multiple passes to refine until it's good enough). But where material is added you should really be able to do it in one go only as you can weigh the precise amount before adding it.

[pmbrunelle]

I can't say that the load cells have been particularly problematic... if I built an accelerometer-based balancer I would probably just face different kinds of issues.

Firstly, the purpose of a balancer is to measure the vibration forces which act on the rotating assembly at a certain RPM. Then, knowing the vibration forces, you can determine suitable counterweights (which will generate centrifugal forces) to counteract the vibration forces.

Here is a simplified explanation of how an accelerometer-based balancer works:
The shaft's bearings are suspended on flexible supports.
Vibration forces act on the shaft+wheel+tire+bearings+accelerometers assembly (moving assembly).
The moving assembly accelerates according to F = ma (Newton's Law) and the vibration forces which act on it, where "m" is the mass of the entire moving assembly.
The accelerometers measure the accelerations of the moving assembly, from which the correction masses can be determined...

The complicated part here is in F = ma. "m" is unknown. "F" is also some combination of vibration forces and forces from the flexible suspension system. The mass of the moving assembly and the stiffness of the supports create a mechanical low-pass filter with an unknown transfer function (with magnitude and phase shift) that describes the correspondence between the vibration forces and measured accelerations.

Sometimes, the flexible mounted balancers will have you add a known imbalance mass to the assembly, to figure the transfer function at a particular RPM.

Here is how a load-cell-based balancer works:
The shaft's bearings are in rigid contact with fixed load cells.
Vibration forces act on the shaft+wheel+tire+bearings assembly (floating assembly).
The load cells measure the reaction forces required to keep the floating assembly immobilized; the reaction forces have a direct relationship with the vibration forces.

So here, with the assumption of infinite stiffness, it's really a lot more direct; there is no variable low-pass filter.

On a real load-cell based balancer, there is indeed a variable (depends on the wheel's mass) mechanical low-pass filter. At low frequency, the reaction forces are directly related to the vibration forces. As frequency increases, there is a phase shift. When the frequency of the vibration forces is higher than the corner frequency of the filter, there is attenuation.

However, a load-cell based balancer is designed to be as stiff as possible, so that the corner frequency is high enough (even with a heavy wheel) that there is negligible phase shift at the expected balancing RPM. Even if the transfer function is not precisely known, it's close enough to 1:1 at the balancing RPM. Well, that's the design objective anyway

So anyway, I picked a load-cell type because it seems MUCH simpler... The commercial wheel balancers are rigid.

However, balancers for electric motors, turbos are more likely to be flexible suspension. Probably with the higher balancing speeds, there may be unavoidable phase shift, so you just give up on the stiff load cell topology.

As for single-spin balancing, that is the objective. However, I do not expect to meet this objective... I don't think anyone does single-spin balancing. When the commercial balancers claim single-spin balancing, their displays show "0.00" ounces correction mass required, but when the mass is below some tolerance level, the software rounds it down to zero. So that's pretty much cheating.

When I use my balancer (Mk1), I do iterations, but I'm trying to get the imbalance as close to zero as possible (not just "good enough"). In the final iterations, the correction can consist of moving the weight by 2 mm, and then trying again.

[rs20]

But where material is added you should really be able to do it in one go only as you can weigh the precise amount before adding it.

In practice, having accurate, calibrated scales, accurate measurement and placement tools and having a precisely defined reference place on the wheel is faaar more expensive, difficult and time-consuming that just doing it iteratively. Newton-Raphson iteration converges extremely quickly on linear situations like wheel-balancing -- in fact, it converges immediately theoretically, and just very very quickly in the real world.

[pmbrunelle]

During the balancing process, I fix the weights to the wheel with masking tape. The masking tape allows the weights to be easily moved around. Once I am satisfied with the balance, then I carefully peel back the anti-stick strip from the weights, and then I stick it onto the wheel.

One (easily preventable) trap is that as the correction mass becomes high, the strip of weight required becomes longer. So rather than being a point mass, you now have a circular arc segment, and so the center of mass of the circular arc segment has moved towards the shaft axis. So you need more mass than expected for the same mass*radius product.

I imagine that with hammered-on clip weights that iterations would be a real pain, and the rim of the wheel would end up quite scratched up...

[CaveMannDave]

Howdy:

WOW, reviewing your posts, so far, it is my humble opinion that you are diving head-first towards a DEEP rabbit-hole, if not yet within it's Schwarzschild Radius.

Meaning: I believe you are falling into the "Trap For Young Players" of over-thinking the specifications and minutia for a project that doesn't warrant the Hyper-Precision you seem to be chasing.

We had a damn-good balancer at one Automotive shop I worked at, that used two standard issue Pillow-Block bearings, an (approx.) 30-slot optical encoder w/index, a 1 D.O.F. (horizontal) slide on the distal support, a pair of heavy, calibratable springs, a pair of dual-winding coils w/moving iron cores (arranged as an L.V.D.T, w/oscillator excitation), several potentiometers and a measuring gauge to set ID, OD, and Width (calibrated dials), a pair of analogue meter movements, to indicate required weight and null position (where to index weight on wheel, rotate by hand to "zero", add weight at index mark.)

The circuit board was single side, hand-taped, and 'sparsely' populated with, perhaps, two-dozen 14, 16, and 18-pin DIP ICs, lots of passives and 25T precision trimmers:
Most of the ICs were OpAmps and comparators w/some 7400 series for position tracking and memory latching.

A couple of iterations and balance was close to nominal, considering that NO tire is round, and there was no "Road Load" applied to compensate for differences in circumferential resilience.

Do what you want, but you may be dealing w/ a Money Pit.
I admire your diligence, and devotion to your Ideals, but be aware that SOMETIMES accuracy and precision may only rise as the square, cube, or some higher ROOT of complexity and cost.

And, remember, tires wear unevenly, operating temperature changes things, and, on MOST road surfaces, no one will notice the difference.

Good luck, Senoir Quixote:  Strive for Perfect, but know that it is the Enemy of Good Enough.

Cheers,

Dave

Edit: Spelling; L.V.D.T. (in paragraph 3) was typed as D.V.D.T., which means something else.

[Kleinstein]

The encoder for the weel does need to have higher resolution, just a single pulse per revolution is enough. Something like 4 pulse might make analog hardware simpler a little, but for a µC this does not really matter and a single puls can act as an absolute reference for the angle. Usually it a rather good assumption that the RPMs are not changing very much during a single turn - so interpoation can be done in time.

Usually the final calibration on how much unbalance causes how much signal at the vibration or force transducer has to be done by experiment anyway. Depending on the accuracy of calibration the iterative process can be faster of slower - ideally the calculated position and mass could give a perfect balance in one step. If not perfect it takes a few steps, maybe 2 or 3.
The limiting part could be the accuray of mounting the weel anyway.

[pmbrunelle]

Dave, I expect this project to be done within 2 years, and after $2000 of expenditures. There's no point in trying to go fast though, because then you'll just need another project to do...

So the first attempt to calibrate the force sensors was with dead weights. The dead weights pulled on a string, which pulled on the Mk1's bearing supports. This was a complete failure.

Then, we made a calibration disk, this made things better. So by installing known masses into the holes, we can get 2, 10, 20, or 40 oz-in of imbalance. Mk2 will have an automatic calibration by calibration disk.

The centering of the wheel is a huge issue. The rotation axis on the balancer and on the car must be as close as possible. To get things as concentric as possible, the shaft was turned between centers, and the OD on which the centering cones slide on was machined to fit - not meant to be interchangeable with other centering cones.

The constant speed assumption is not a bad one for a high-inertia load, such as a wheel.

However, with the calibration disk on the 40 oz-in setting, the speed is far from constant. The motor slows down to lift the weight, then it accelerates on the way down.

As for the countdown timer approach, it could be possible as long as you always have a high-inertia load; no calibration disk.

However, the encoder facilitates a high force sampling frequency. This is important to avoid aliasing. The force signals do have a bunch of high frequency garbage. Otherwise, in theory, the force signal is a perfect sine with a frequency of once per shaft revolution.

Also, the encoder is useful for weight placement. Otherwise, it is difficult to manually rotate the wheel to the correct angle for counterweight placement.

[CaveMannDave]

Hi:

QUOTE:  "The limiting part could be the accuray of mounting the weel anyway."

Thank You!

I accidentally left that point out, and depending upon concentricity (absolute STRAIGHTNESS) of the balancing machine's shaft (and the balance of ALL rotating components), to say nothing of the axle/spindle/hub/bearing/lug tolerance, of which I DARE anyone to demonstrate is PERFECT, or even capable of perfection, on ANY rolling 1000 KG+ rolling vehicle!   

I can't EVEN enumerate ALL the potential sources of error in any attempt to balance any rotating parts, much less components subjected to the abuse that wheels are expected to tolerate, on a daily basis.

Ask a Turbine Technician how hard it is to balance one of his "clients".

Cheers,

Dave

[CaveMannDave]

pmbrunelle:

Believe me, I DO fully understand your motivation, desires, and logic.  And there is nothing that I would like more than to encourage you in your pursuit, as it is an Honourable one.  I simply believe you are embarking on a path that will have you banging your head on a concrete wall, and I want to help you avoid the frustration.

I was a Young Engineer, 40 years ago, and I believed that if only I put enough thought into it, that I could overcome the Laws of Physics, to read nano Hertz on a 10 GHz counter, but it was not to be.

I suggest you search out the writings of the likes of Bob Widlar, Bob Pease, and Jim Williams, (all of whom have, sadly, 'Shuffled off this Mortal Coil'), but who were Legendary GrayBeards before most of us were out of three-cornered pants.

These were the dudes that made the Analogue and Signal Processing world easy for the rest of us.

Pease was known for "Solder is my favourite Programming Language" and "In theory, it will work, but in practice it won't".  His Passion, as was Williams', was finding the bleeding-edge of what CAN be measured, and then pushing that limit as far as possible, and beyond.

Look up their books and Wisdom, and PAY ATTENTION !
They forgot more than most of us will EVER learn !

The circuits may be from the '60s, but the information is timeless !

I wish you well, and perhaps you can get your project up to spec, but failure is not always a bad thing: It will teach you more than any textbook, if you allow it.

Cheers,

Dave

[pmbrunelle]

I just finished tuning (by experimentation) the constant current braking load so that it works correctly. Right now it's a bit messy with paralleled resistors and flux drippings everywhere, so I will clean it up some.

After a balance cycle is complete, this "constant current" load is connected in parallel with the 90 VDC motor. Braking is much better than with a resistor (which is much further from constant current). It's a 2.6 A rated motor, so the goal was to decelerate the wheel at the motor's nameplate current.

The choice of R2 seems to affect the circuit's stability, but the required bandwidth for this application is slow (human-measureable time-frame). Previously, it appeared to oscillate with a smaller value of R2, and this oscillation could be heard (audio frequency) from the motor. A voltmeter connected across the current sense resistor indicates that the circuit now works as intended. The motor is quiet during braking as well.

It took a bit of searching to find a MOSFET with a SOA that could handle 2.6 A at 90 V. A bipolar transistor seemed to be out of the question for this type of duty.

Obviously, the Mk2 balancer does not yet exist, so I used the Mk1 balancer as the test bed for the constant current braking load.

[pmbrunelle]

I picked up some bearings to support the main shaft.

Even though the RPM is low, I prefer shielded to sealed bearings. The more torque the motor has to provide to keep the wheel spinning, the more potential there is for any torque ripple in the motor output to be reflected in the load cell signals. Besides, the inside of a wheel balancer is a clean and dry environment.

Regarding the power supply, I got an ST VIPER27 flyback converter chip (60 kHz), and the flyback transformer suggested (by digikey) for that chipset. So the next step will be to make a proto-board to test the power supply alone.

The proto-board layout will have to be somewhat similar to the layout as I would expect it in the final design; otherwise, the value of the proto-board is pretty much nil.