The Mayor G1 Update 2

A second Update for my brushless Flywheeler, and may very well be the last. This third iteration is, unlike the other two, completely functional, robust, effective, and is also the first 100%  assembled and working form of the blaster I have to date.

Digital renderings on the top, actual blaster on the bottom.

The biggest issue I have solved when producing this design was the screw issue. With the other two versions, some screws got their hold from exclusively plastic, and in effect, started to loose their hold and shear out of place. I had to reform the STLs, namely the backend piece, to add slots for captive nuts. The slots work, but, they are slightly loose. I used some glue to hold the nuts in place for blaster assembly.

I have also reworked the gearbox to better fit with this design. The original gearbox that I had used came from a version somebody before had designed on Thingiverse. I added a bracket for a NEMA 17 and a slot for an endstop switch, but there were still some flaws with the rotator mech. They worked OK, but I optimized them in this revision. The opening for the Arduino and corresponding circuitry was also made bigger, as I found it challenging to tuck and insert all the electronics into the original space provided.




Legacy versions on the left

New versions on the right



                                                                     



One of the other larger revisions that came with this version is the trigger and gearbox cover. This mainly stemmed from the need to create anchored nuts for the handle (as a large portion of the lower part of the weapon is supported through it). It ended with an almost complete overhaul of the lower portion of this area. I revised it to connect along a flat edge compared to originally coming together at an angle. This gives more room for the gearbox cover to have captive nut slots and a more robust overall structure. The internal handle structure was also redone to better accommodate the microswitch used for the trigger. A channel was added behind for the wires so they would not interfere with the moving parts.

legacy seam is angled

new seam is flat

a 3d printed new seam

Hardware-wise, I also switched to 30a littlebee Blheli ESCs instead of the standard simonK ones used with other blasters. This is mainly due to the fact that these days, simonK is being phased out and Blheli is cheaper, more recent, and more robust. The specific flavor of Blheli I am using is Blheli_S, so the firmware of the blaster also had to be updated to accomodate this. Blheli_32 would be even better, but the current escs I am using do the job more than good enough.
   The firmware works, but up to now, it has been more of an experiment to see if everything worked. It only has 2 modes, full auto and burst (3-4 dart), but since everything functions well up to this point, I will update it to support more features.



Yes, I know that even these are not true Littlebees, but they work just as well, so they might as well be.

Preformance-wise, the blaster does even better than originally expected, topping out at 190 FPS and averaging at 170 FPS. It gets around 4-8 DPS which is OK, but not great. That could be improved by replacing the current stepper with one that is more optimized for the task. The blaster itself it terribly front heavy with the balance point being right in the center of the magwell. This makes sense, as the battery, unlike blasters made by others, is situated in the front above the flywheel cage. Not much can be done to combat this, but it defenitely isn't a deal breaker.

Here are some images of the completed blaster (I will acquire more internal shots when I get the time).

An image of magwell and concealed On/Off toggle



Nothing much about the front end was changed.

Battery tray without battery

Battery tray with battery



Arduino Nano and A4988 driver tucked
 inside a nest of wiring

Backend without cover.
 Everything is nice and snug

As usual, the updated files will be up on Thingiverse right here
Firmware and another set of STLs can be found on Github here

Blog post Update: (update 3)
Didn't think this was wroth a totally new post, so I will slip it in here with the previous update.
This update was more of a addition to the current blaster. 2 parts in total were updated: The handle and the dart tooth.
The original handle works, but is not the most comfortable to use, so an alternative with better form has been produced.
The new dart tooth solves an issue with the original where the first dart would commonly jam when being fed into the cage. The new one is thicker and has 0 slope to it, hopefully resulting in less friction while feeding the initial dart.

Updated files can be found at the links above

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.