Triwheel theory: Rival

Earlier I posted a theory about a three motored flywheel cage I deemed a 'Triwheel". The theory was, that, the more wheels added to the cage, the less of a speed difference there would be between the corners and center of a complete encapsulation cage (or HyCon). I was thinking of dart applications when I was developing this, but somebody suggested using it on rival balls. I thought, "hey, they have a point". You see, spheres fly differently than cylinders and as a result, this cage can use this difference to its advantage. Spheres (unlike darts which fly forwards and not sideways) succumb to the Magnus effect, a property that creates lift when the ball is spinning. If you have ever seen one of those basketball-dam videos you will see what I mean. The person spins the ball and when it falls fast enough, it starts to glide sideways. Interestingly enough, the Nerf rival blasters also use the Magnus effect. They have what is called a hop-up on the muzzle of the blaster which is, in essence, a little rubber flap hanging down from the top of the shaft. This flap strikes the ball when it flies out the barrel, creating spin and keeping it in the air longer.

With the triwheel cage, I hope to control this effect. In theory, just by varying the speeds of the 3 motors, one should be able to create spin in whatever direction they want, essentially controlling the direction of the HIR without even moving the blaster! You could even do this to a degree with standard biwheel blasters, moving the HIRs up and down (or side-to-side), but you can not move them in every direction. The third wheel makes this possible. (four could also work, but 3 is cheaper and more practical)

The challenge comes when trying to write the code. I hope to eventually control this setup with a videogame joystick similar to the ones found in Xbox or PS controllers. These joysticks utilize 2 potentiometers (one in the X and one in the Y axis) to map location. The triwheel has 3 flywheels. Four wheels would definitely be easier when it comes to this fact, but since it can be done with 3, it will be. If we set up the POT readings like a graph with x being POT1 and y being POT2, then we are essentially trying to go from a square to a triangle. For this reason I worked the code around a little diagram I made to help me along:

In this diagram, I have inlaid a square inside of a triangle. The POT readings will never leave the square, but depending on their location inside it, it will have an influence on motor speed (each triangle "point" represents a motor). The closer the mapped POT reading is to a point (on the triangle, that is), the slower the corresponding wheel will turn. This creates hop-up in the direction of the joystick. Success.

Here is where I will submit my simple angle calculator for others to try out and verify (or just to have fun with). Everything is simulated and over the serial monitor so there is no need for components. It simulates potentiometers and servo angles (the two inputs and outputs it will normally use), so the input has to be as if it is a POT reading (0 to 1023, 511.5 is center or 0).

FORMAT:

X: input x value (I.E x 55) from 0 to 1023 (to simulate a pot)

Y: input y value (I.E y 55) from 0 to 1023 (to simulate a pot)

C: calculate angles (what brushless ESCs deal in)

you can use x and y in the same line, but c has to be executed separately.

Example: X450 Y230 (enter something like this first

C (send this after you have entered the first digits)

the code will send back the mapped x and y coordinates from -100 to 100 when you send either of them.