[GBC] Let's build ball mechanical flowmeters

[Thierry-GearsManiac]

In great ball contraptions, besides ball transport mechanisms themselves, there are sometimes impressive advanced mechanisms playing secondary roles, for example mechanical ball counters.

However, no working mechanical flowmeter yet. A chance to build something original.

 

Although Nico71 already tried to build one :

... unfortunately, his design has a flaw : the back move of the hand towards MIN is done at a constant speed. As a result, the hand stumbles over either MAX or MIN, depending on whether the average turnstile speed is above or below some threshold. EDIT20200413 : My apologies because he was himself aware of this limitation.

Mechanical devices share similarities with simple analog electronic circuits and therefore can be simulated this way : electrical currents and voltages will represent speeds and positions respectively. By using the online electronics simulator http://www.falstad.com/circuit/ which is animated and also rather indicative, I'll show the behaviours of different solutions by providing links for downloading each simulation model, which can then be opened in the simulator.

Here is Nico71's equivalent :

http://www.mgtx.fr//LEGO/GBC/DeBilleMetre/BallMeter_Nico71.circuitjs.txt

The capacitor simulates the transformation of a speed into a position : the current flowing into or out of it does charge/discharge it quickly or slowly, according to its value.

The Zener diode limits the voltage across the capacitor, as well as the hand can't move beyond MIN and MAX thanks to mechanical stops.

The low side current source (or current sink) slowly discharges the capacitor, simulating the back move of the hand  at one input of the differential.

The high side switched current source circuit (signal generator + relay + current source) simulates balls passing through the turnstile and briefly charges the capacitor (moves the hand forwards).

Try to change the signal generator's duty cycle in order to simulate different ball flow rates : here, with a 4:1 ratio between the current sources, if the duty cycle is even slightly above (respectively below) 25%, then the capacitor will charge and stay around 10V (respectively discharge and stay around 0V).

 

Coming soon in the next days :

• my very first mechanical solution (see video and pictures below), its electronic inspiration and the simulation model, the explanation of its behaviour, and how to implement it the mechanical way (CVT + linear actuation)
• the difficulties I encountered in my first build, how to solve them, other more optimal possibilities etc...
• an alternate solution closer to Nico71's design (found much later, therefore not yet built) in the form of a simulation model
• the general recipes for building ball flowmeters

(PeerTube non-embeddable video link) https://diode.zone/videos/watch/3e64e9b6-f05c-4202-aa66-f37d6e14d61d

 

Edited April 12, 2020 by Thierry-GearsManiac

[Frequenzberater]

This is absolutely brilliant! I like it when people dive deep in complex mechanics and try something unique.

Now its time to polish the module :)

[Thierry-GearsManiac]

@Frequenzberater :

To polish the module : aesthetically speaking, this is in fact my weakness, except if only a few tiles and slopes on the conveyor ramp and perhaps local color standardisation are enough.

The blue return ramp (independant from the module) was purposely built quick-and-dirty, only for testing.

The reliability of the mechanism still needs to be improved and more scaffolding is needed for making the top sturdier and less prone to wobbling, because a few balls miss the output ramp.

 

Now, let's continue :

As a conclusion, the electronic model of Nico71's design shows that, with a back move at constant speed, for any ball flow rate, i.e. an average constant speed of the turnstile, the outcome is a constant speed for the hand, either positive (==> hand bumping against 100%) or negative (hand bumping against 0%).

 

Now, the initial solution I thought about :

http://www.mgtx.fr//LEGO/GBC/DeBilleMetre/BallMeter_VoltageDrivenLowPass.circuitjs.txt

What all the theoretical stuff of an RC charge/discharge circuit says is that : the closer the capacitor voltage is to the end voltage, the slower it gets charged/discharged (because, as the voltage across the resistor decreases, so does the current through the resistor --Ohm's law--, as well as the (dis-)charging speed of the capacitor, i.e. the variation of its voltage).

With a ball flow rate of, for example 75%, then the capacitor gets :

• charged 3/4 of the time at 1/4 of its max speed
• discharged 1/4 of the time at 3/4 of its max speed

(for simplicity, we assume that the switching is fast enough so that we can neglect the speed variation)

Therefore, the hand ends up rippling around 75%.

 

Now, when building real mechanics :

• balls have to be forced to move one by one by the means of any suitable mover mechanism (conveyor belt, elevator wheel, piston, tipping arm...)
• a mechanical sensor (pivoting arm, piston...) detects balls. In some cases, in order to cover 100% of of the mover's cycle duration, then we can parallel several movers with shifted phases. For example, let's imagine a piston raising a ball : if the sensor sees a present ball only 50% of its cycle time, then you'll need two alternating pistons.
• a mechanism for reproducing the behavior of the capacitor (dis-)charged through a resistor to a target voltage of either 0V or a defined supply voltage (10V in the simulation model)

For the latter, several physical devices may fit the puropse :

• a fan immersed in a fluid (which brings viscuous friction) and attached to a spiral spring that we tension either in one direction or the opposite. And if we even add some mass to this fan, then we even get some inertia (=> 2nd-order low-pass filter) which smoothes the ripple better. Unfortunately, harder to build in LEGO : the force for tensioning the spring (even if motor-assisted) has to stay low, which means that the fan's rotation must be very slow while  exhibiting neglectible dry friction (i.e. constant friction which stalls an axle below a given torque)
• a CVT (Continuously Variable Transmission) coupled to a linear actuator, which is the solution I retained.

The simplest way I found for implementing such a CVT (whose output speed must be able to come close to zero) is the disc (input) + a sliding tyre (output) :

the tyre's speed is proportional to its distance from the center of the disc (which spins at a constant speed in the correct direction). And if this tyre drives a linear actuator which slides it towards the center of the disc, then we achieve the desired effect of mimicking the charging of a capacitor : the sliding of the tyre towards the center progressively slows down.

Now, if we want to emulate the discharge, then we add a 2nd tyre at the opposite and some switching mechanism (clutch) so that it can drive the linear actuator in reverse direction. Here is a closer viev to my current solution :

In my case, the linear actuation is achieved through racks and pinions, driven by the tyres through a worm gear (high ratio, and locking for preventing the carriage to fall).

The hand stroke gets doubled with respect to the carriage's one thanks to another rack (almost the same as on telescopic sliding doors).

The clutch is done by tilting the carriage, so that only one of both tyres comes into contact with the spinning disc (because both tyres are mechanically linked). However the experience shows that the carriage becomes simpler... at the expense of its switching : on my conveyor implementation (small chain links), the sensor exhibits a weak force and short stroke, not enough for pressing the carriage in either direction. That's why, after a lot of unsuccessful attempts to directly tilt the carriage by the sensor, I resorted to motor assistance :

The sensor engages the sensitive clutch (blue Z20 gear + 3L driving ring around a smooth, not ribbed 3L axle joiner), forcing the input lever (green) to pivot counterclockwise (then pushing the yellow groove to the rear which tilts the carriage downwards). On the imput lever, a friction clutch (Z8 pinion on a friction pin) overcomes the tension of a rubber band intended to return this lever to its original position, as soon as the clutch gets disengaged. In this position, the green lever exhibits a too low force due to the relaxation of the rubber band, which can't tilt the carriage upwards. That's why the 4-bar linkage between this green lever and the one (hidden gray beam and orange liftarm) holding the groove has been designed for amplifying the force to almost infinity (when the green input lever and the intermediate green link are almost aligned).

 

Possible simpler alternative implementations, not yet built :

• same CVT carriage with no motor assistance, but a more performant transport mechanism (sturdier conveyor made of big treads, long stroke piston, ball-triggerred lifter, slotted lifter or wheel...) where the sensor will have a longer and stronger stroke
• another CVT carriage design in which both tires are permanently pressed against the spinning disc, but not linked together and, instead, part of an on-carriage standard clutch mechanism (which only requires low forces to be operated)

 

To be continued...

 

Edited April 9, 2020 by Thierry-GearsManiac
correcting mistakes and adding a few words

[Thierry-GearsManiac]

And later, when my build was already in good progress, when thinking again about Nico71's build and the corresponding electronic model, this 3rd idea emerged from my mind : how to mod Nico71's design, so that the hand slows down as it approaches MIN (0%) ? By inserting a CVT between the motor drive and the corresponding input of the differential (at the place of the Z40 gear), whose speed ratio would be controlled by the hand's position = coming from the differential's body. In this case, what happens ?

• if no ball spins the turnstile, the hand returns to almost 0% with an exponential decrease (the closer to the target position, the slower)
• if balls spin the turnstile all the time, then the hand begins to move at full speed towards 100% (because the speed of the turnstile -- which moves the hand forwards-- initially overcomes the speed at the output of the CVT --which moves the hand backwards)
• as the hand comes closer to 100%, the speed of the CVT output (responsible of the hand's back move) increases so much that it eventually cancels the speed of the turnstile, slowing down and stopping the spinning of the differential's body, thus the hand
• for any other intermediate average turnstile's speed, the hand will again stabilize itself around the corresponding position

The interesting aspect of this mechanical implementation is that the CVT has no switching/clutch mechanism : probably simpler to build and to make reliable.

On the electronic simulation side, it corresponds to the replacement of the low-side current source (which acts as a current sink) by a resistor

==> what we get as a result is again a RC low-pass filter, but the current-controlled variant this time :

http://www.mgtx.fr//LEGO/GBC/DeBilleMetre/BallMeter_CurrentDrivenLowPass.circuitjs.txt

(again, try to download this simulation model, then play with it in the simulator)

 

A last word : the differential could even be custom built, right at the hand's level, like the base of Froden's GoPro dolly design, which is a linear differential (the inputs are the external cranks and the hand is the carriage itself) !

(Froden is also a well-known GBC designer too !)

 

End of the study.

 

At last, a general word about the time I spent for building my almost working prototype : it really takes a very long time to adjust such mechanisms, as well as GBC module designs in general. I spent tenths of days before coming to acceptable results, taking into account that I'm not totally at ease with beam-based frame building yet : several abandoned solutions before finding an acceptable one for each part of the module (the conveyor, the CVT itself --begun in December 2019--, a frame, failed direct switching mechanisms then the motor-assisted switching after a lot of adjustments, then the drivetrain and some beam building... and at last a lot of failed input bin designs before an almost right one).

 

What do you think about all of these ideas ? Are some of you ready to design your own unique flowmeters ?

[ord]

27 minutes ago, Thierry-GearsManiac said:

What do you think about all of these ideas ?

Fascinating.

Can you define what the output dial actually reads (in your initial model)? i.e. it is the average flowrate of the balls but across what period? 

For example, a real life situation might be: 10 balls, 10 no balls, 10 balls, 10 no balls...

In this situation will the dial tend towards 100%, 0%, 100%, 0% or hover closer to 50%. Is changing the period simply a matter of adjusting the speed of the cvt?

[Thierry-GearsManiac]

Indeed, the period depends on the speed of the CVT (speed of the spinning disc, overall gear ratio on the tilting carriage between the tyres and the horizontal output axle).

This isn't actually a period of measurement that will be changed, but rather a cutoff frequency (the averaging mechanism acts as a low-pass filter over the pulses generated by the balls on the sensor), and a compromise has to be found :

• make the mechanism react faster and it will show a flowrate over a shorter period, i.e. with a shorter response delay, at the expense of a higher ripple rate of the hand
• make the mechanism react slowlier and it will show a flowrate over a longer period, but with higher response delays to flowrate changes

This will be true with the 3rd technical idea as well, i.e. the fixing of Nico71's build.

In my case, the order of magnitude of the period is roughly 30-60s.

The dial will stabilize around any figure that reflects the load rate of the conveyor (whose speed has been set up slightly above 1 ball/s) as seen by the sensor : with no ball at all, it'll go down to 0% ; loaded all the time, it'll go up to 100% ; with one ball every 3 slots in average, it will tend towards 33% ; with 3 balls every 4 slots, then 75% etc... (approximately, because of some losses in accuracy caused by the imperfections in the mechanism).

 

If we ever wanted to make a mechanism responding faster but with less ripple, then it should get its inspiration from higher order low-pass filters and, as a consequence, become much more complex and bulky (except, perhaps, for the heavy fan immersed in a liquid). Welcome to the marvellous world of frequency filters !

[Thierry-GearsManiac]

Another note : if you are not familiar with frequency filtering concepts, a cutoff frequency is a frequency above which (in the case of low-pass filters) the amplitude of the output (in our case, the hand's position) will decrease along with the increase of the frequency, in a more or less steep slope (see Bode plots) : there is no sharp frequency cutting.

This applies to pure sinusoidal signals. Therefore, with our ON-OFF input signal, which is made of an infinite sum of sinusoidal signals (according to Fourier's theory), the attenuation will be stronger on harmonics (depending on their range) than on the fundamental frequency.

[Thierry-GearsManiac]

For the attention of Nico71 : here is a rather optimized mock-up (not yet tested and set up for correct gear ratios) of a fix for your module :

On the left, one possible design for the spinning disc that would be placed below of above the tyre on the assembly on the right.

On the right, the rest of the mechanism, including the interfacing with the differential :

• the hidden Z8 pinion on the sliding axle with the tyre is the free-sliding variant (11955)
• Credit to Yoshihito ISOGAWA for the trick used for sliding this axle  (Simple Machines, p. 153), i.e. the worm gear-based linear drive by meshing a half-bushing with the worm gear : this really helps to make the design so compact !

A constant speed (and correct direction) will be supplied to the disc which will drive the sliding tyre.

And the turnstile input and the output to the hand will be placed the same way as on your original mechanism, i.e. respectively the 4L axle side on the differential and its body.

 

Hope this helps.

[ord]

Thanks for the explanation @Thierry-GearsManiac - a truly unique concept

P.S. That linear drive by Yoshihito ISOGAWA is great

[Thierry-GearsManiac]

Thanks to @nico71 who answered me personally about my design idea for him, he even made me discover an innovative mechanical recipe from The Bananaman 2018 (unfortunately not registered here) in his ultra-recent build :

... and I've quickly understood what's going on mechanically.

if we increase the space between the input turnstile (which increases the counter) and the output turnstile (which decreases the counter), let's say, to ten places instead of two, then the counter continuously shows the number of busy places between the turnstiles, which is almost the same as a moving average. For example, 5 busy places = 50% of the maximum flow rate = (for this conveyor speed) the nominal 1 ball/s rate.

 

If we again look for similarities with electronics, if I built an analog flowmeter, The Bananaman 2018 on his side invented the digital mechanical flowmeter (which outputs discrete values) !

Electronically implemented, it would look like an "up/down/none" differential synchronous counter (typically on an FPGA or CPLD).

 

 

Edited April 14, 2020 by Thierry-GearsManiac