Challenge #1: The crossover - is there a better design?


#1

Behold, the crossover:

Its function is simple: Balls coming in from the left go out the right and balls coming in from the right go out the left. But it was one of the most frustrating parts to design.

In the first full prototype of the game, the board didn’t have pins sticking out that the parts fit into. Instead, the parts had pins sticking out of them and the board had holes in it.


(Front view of the holes in the 1st prototype board)


(Back view of the holes in the 1st prototype board)

With this design, the crossovers looked like this:


(Front view of old crossover)


(Back view of old crossover)

The old crossovers worked like a charm.

However, the overall design wasn’t great. The parts were a bit delicate (the pins could break off) and the board used a lot of plastic around each of those holes. So in the current version, the board has sturdy little pins that stick out the front and the parts have holes in them.

This new design worked really well for all of the parts except the crossover. The main problem was that there wasn’t enough space between the pin sticking through the crossover and the bottom platform. Balls dropped onto the platform and would frequently bounce up and hit the pin, sometimes causing them to exit the crossover on the wrong side. Like this:

image

I couldn’t figure out how to make it work by messing with the crossover design. One thing I tried is to put the crossover on top rather than on bottom like this:

But it had a similar problem. The balls would often bounce off the top of the pin and then hit the ceiling on the other side, like this:

I ended up just making the balls smaller to create more space. Rather than using 3/8" diameter balls, I switched to 5/16" balls. That left a little room to allow a small bounce without hitting the pin above it. It was a bummer to have to switch, though. The lighter balls can’t push as many gear bits at once and they are more difficult to manipulate.

Can you create a better crossover?


#2

Could pads be stuck on to cushion the bounce? And maybe make the whole thing quieter?


#3

Thanks for the idea, Blaze. They would have to be very thin pads - maybe even something like masking tape would be enough. It would certainly be worth experimenting.


#4

If the board width and height are your x and y dimensions, could you use a design that makes use of the z dimension to route the balls over to the other side? Instead of both balls using the direction of momentum to determine their path in passing through the same gate, have two “tubes” that balls fall into depending on which direction they enter from. Have one tube swing out from the board and over the other, while the other tube crosses over the top of the pin flush with the board.


#5

Good thinking! I think it might possibly work, but the way things are set up now, pushing out the Z direction can get in the way of nearby gears.

I actually tried going out in the Z direction with some initial prototypes. The one on the left was the first. It was literally a tube. It was supposed to take a ball over another part and down diagonally onto the other side. After building it, I realized there was only one part that would fit behind it - a ramp. So in the next iteration, I just joined the ramp and “tube” into one part. That worked ok, but then you couldn’t have any gears nearby because they’d run into the part. Then I started just making the part flat. It worked perfectly back when I didn’t have a pin sticking through the part. It got harder when I changed things so that the pins went through the parts. Then the pin got in the way as I mentioned in the post.

Still, it might work to go out in the Z direction if the area it sticks out doesn’t interfere with nearby gears. It would be a tricky design problem, though.

Thanks RobsterCraw!


#6

I want to help with this but I realized that I’m missing critical design constraint information.

What are the spacial constraints on the design such that it won’t interfere with other nearby components? Could you post a schematic of a part that takes up the most space possible?

What is the ball diameter? What is the minimum thickness of the plastic parts?

I would expect that the problem of the balls bouncing unpredictably is coming mostly from the balls entering the crossover from ever so slightly different directions and velocities. Perhaps then instead of just channeling the balls to the other side with whatever velocity they come in with, the crossover piece should “reset” the velocity first before dropping the ball through the cossover path.

How about a design something like below, where the first part of the process (1) is the catchment area. The catchment area feeds the ball through a threshold (A) only barely wide enough for the diameter of the ball so that the velocity the ball carried into the catchment area is killed off, then the ball travels through the channel (2) Past (A), (B), and © where the ball has no room to bounce in unpredictable ways as it passes onto the ramp that directs it to crossover at (3).

My rough drawing somewhat exaggerates the elements in a way that makes it look like it only works on a smaller ball. For it to work on the actual balls involved it would look a lot more subtle (if it would work at all).


#7

I just got my Turing Tumble a two weeks ago, and while messing around with it, I have noticed this ball bouncing effect. in particular it has shown up in the first two crossover puzzles. most of the time it bounces the ball into the wrong path, but occasionally will bounce the ball entirely off the board.

How frequently does the current part fail for others, and has anyone found a modification that can be done to decrease the chance of this behavior?


#8

Hi slaybalj,
I see this once in a while - maybe 1 out of every 100 times a ball goes over a crossover. It sounds like you’re seeing it much more frequently than that. If you have a moment, is there any chance you could send a video? I’m really curious what’s going on with yours.
Thanks and sorry that it’s not working right.
Paul