I worked on the space game more tonight. In particular, I made the logic that guides an alien toward a citizen a bit more sophisticated by implementing moving target interception. Without this, if the alien just moves along the A to B path to the citizen, the alien ends up lagging behind the citizen because the citizen is in motion.
I described the derivation of this calculation in LaTeX a while back for a friend who was curious about it. I’ll attach the PDF here for anyone who’s interested.
Otherwise, the aliens now pick a target, descend to it, and freeze it in place to abduct it. I need to create an abduction animation to use. Maybe I’ll do that next time.
I thought I’d share a couple of the animated sprites I worked on tonight. I use PyxelEdit (http://pyxeledit.com/) to create my sprites–I really like it. Tonight I made a flying saucer and a radar dish.
At the start of the winter, I set a goal for myself to create a simple PC game I could play in the living room on my Steam Link with my son. Winter wears on, and I’ve been so focused on the motor and other hardware projects, I really haven’t done much with this goal.
Today I set aside the motor project (which is waiting on the 4mm parts from England) and worked a bunch on the game.
The game will be like Space Invaders or Galaga, but you shoot at the invading aliens from stationary positions, like Missile Command. The aliens’ goal is to descend and abduct citizens, who run in hapless panic back and forth across the bottom of the screen. Ideally you kill the aliens before they abduct anyone, but if someone does get picked up, you can safely rescue them by deploying a Sky Commando. Sky Commandos swoop in with wingsuits from the nearest side of the screen, and if you aim their arc correctly, they’ll grab onto the alien ship and attack it from within, destroying it and rescuing any abductees. Sky Commandos are a limited but reusable resource, which just means you can only have a finite number of them in play at a time.
The game is meant to be played with a gamepad since I intend to play it in the living room. I’ll release it for free if it shapes up into something worth releasing.
Today’s progress was implementing the alien AI that allows them to identify and move in on a potential abductee. Otherwise, I have the game engine in place (using the entity/component/system, or ECS, model) with an observer pattern to inform systems about entities they should care about or stop caring about. I’m implementing it all in C# using MonoGame. Currently the player can shoot at aliens with a rapid-fire weapon, and as I said, aliens will now pick a citizen to abduct and descend to get them.
I discovered while messing around with some of my gears that I can use pliers to force them onto the 2mm steel shafts I have, so I rigged up a simple transmission using some Stevens International plastic gears. Here’s a video (sorry about the quality, I need to work on that):
I mounted the gears on a piece of 2×4 today using 1/4″ threaded rods (1/4″ 20) for axles. They seem to spin really well. I only have a 3:1 ratio with these, but it’s a good proof of concept and not a bad place to start for the coil-winding device.
I’m going to wind some new coils and see how they compare to the old ones. These will be superior in a couple of ways: better cores, and better winding technique.
For the winding technique, I’m working on building a winding jig out of plywood. The idea is to make a gear system out of wooden gears using the approach detailed here: https://woodgears.ca/gear/howto.html
A crank handle will turn the gears, which then turn a cheap drill chuck that will hold the workpiece (in this case one of the ferrite rods mentioned above). Wire feeds onto the rotating workpiece from a spool after a tensioning device applies tension to the wire. I’m not sure what I’ll use for a tensioning device yet, but it could be as simple as a series of holes or pegs for the wire to pass through or a clamp that squeezes the spool of wire. Having a set of gears allows me to get several turns of the workpiece for each turn of the crank.
I used a different template generator the create the gears than the one provided on woodgears.ca. It creates involute gears, which aren’t as easy to cut out, but transfer power more efficiently: http://geargenerator.com/
I drilled and cut out the gears using a drill press and scroll saw. They’re not perfect, but they may answer the purpose. If these don’t work well, I may try again with the woodgears.ca template generator, which creates less complicated geometries for the teeth.
The new block works nicely. At 2 amps, the motor has some of the most torque I’ve seen yet. It was able to continue turning as I attempted to stop the rotor by dragging my finger along its top.
You may notice the wooden shaft collar above the Erector set rotor parts. This is meant to be a cheap and disposable way to permanently fix the 2mm shaft to the Erector set parts, which I don’t want to commit permanently to the project. Two Erector machine screws go up from the bottom of the rotor assembly, through the yellow plate and one of the silver crosspieces, and up into the wood. I used a 1/8″ drill bit to make the holes for these screws, and the holes took the threads from the screws really well.
My gears arrived today. I ordered three packs of plastic Stevens International hobby gears from https://hobbymasters.com/ :
Crown gear set (SVM-101)
Pinion gear set (SVM-102)
Worm gear set (SVM-103)
All of them say they have an inner diameter of 1.9mm, so I also bought some 2mm steel rods on Amazon (pictured, left). Sorry about the quality of the mise-en-scène; I got excited and opened them before I remember to take the picture. Anyway, the crown and pinion gears mesh really nicely together. The worm gears have three different pitches to them, and only one of them meshes with the other pieces, so that’s a little odd. But they fit snugly on the 2mm rods, so I’m hoping they will be the solution to the problem of how to transfer power from the vertically-rotating motor shaft to the horizontal axle.
I’m also currently moving all the coils to a new plywood engine block that has the appropriate hole in the center for the 2mm shafts (the Erector set shafts I was using are 4mm).
(EasyEDA rocks, by the way, for the hobbyist like me. It’s free for most of what I want to do, it has schematic and package definitions for lots of real-world components, and you can even order little PCBs directly from them.)
Here’s the image:
Update (2021/11/11): This image was lost, but the updated motor circuit can be found in a more recent post.
So, here’s the idea. I’ll explain the mechanics of how this all makes the rotor spin at the end of this post.
The 74LS chip (U1) is an S-R latch chip. I use it to remember which Hall-effect sensor was last triggered, allowing the motor to stay in that state until another sensor changes the state. Otherwise, the motor would only be in a given state as long as the rotor was near a sensor, and this is only a fraction of the time needed.
One sensor sets the latch, while the other resets it. The output of the latch goes into U4, a logic buffer, and U5, a logical inverter, which then passes its output into the logic buffer U4. The inverter gives us an output that is always the opposite of what the latch (U1) is currently remembering, which is important later. The logic buffer (U4) just ensures we have the desired voltage level after all the latching and inverting.
The outputs from U4 are GA and HB, and these two are understood to be opposites of one another thanks to the inverter (U5). GA and HB each go to a power P-channel MOSFET, which does the heavy lifting of switching the several amps of current. The MOSFETS–Q3 and Q4–act as high-side switches for the coil pairs, which are represented by R1 and R2. Each coil pair has a diode (D1 and D2) connected across it to safely discharge the back-EMF the coils inevitably present when you switch off their current.
And that’s it! This is the circuit in use in the latest video, “The motor, revived.”
So how does all this make the rotor spin?
As I mentioned, the motor uses Hall-effect sensors to detect where the rotor is located. This allows the circuit to switch one pair of coils off and the other on to keep pulling the rotor around in a circle like a horse trying to get a carrot on a stick. The rotor is made up of four groups of little neodymium magnets whose outward-facing poles are arranged like this:
N
S S
N
This means opposite coils turn on or off together; they’re paired up. When a given coil is ON, it attracts the nearest arm of the rotor going clockwise and repels the nearest arm of the rotor going counter-clockwise. The very same thing happens on the opposite side of the motor, with the paired coil. While this is happening, the other coil pair is simply off.
When the rotor gets far enough around that the active coils would start slowing it down–because if the power situation doesn’t change, the rotor will at some point just be locked in a position aligned with the active coils and stop moving–a Hall-effect sensor detects this situation and triggers the circuit to switch off the active coils and switch on the inactive coils, starting the whole thing over again. This happens many times per second (76 times, in fact, lately) and results in the spinning motion. The S-R latch remembers which sensor was last seen so that the coils can keep pulling the rotor even when the sensor is no longer triggered.
There are some inefficiencies here. Ideally both pairs of coils would be on at all times because that should deliver more power to the rotor. But that requires actually switching the current direction through the coils instead of just turning it on and off, and that proved challenging in my early attempts. Schmitt triggers may help with this problem, however, by discretizing the turn-on/turn-off characteristics of the MOSFETs. Or it may require matched transistor pairs.
It would also be nice to not have like magnetic poles opposite each other. There is likely some power leakage here as the inward-facing poles work in opposite to the outward-facing poles.
I was able to use my DS0138 oscilloscope to measure the RPM of the latest motor. I took a signal reading from one of the two coil pairs, and as it switched on and off, it formed a square wave. The scope measured the frequency of the wave at 76hz. Multiplying by 30, I got the result: 2,280 RPM. Not bad!
Why multiply by 30? In this configuration, each coil pair turns on and off twice per full revolution of the rotor (the wave changes every quarter turn of the rotor). That means there is only half of a revolution in each cycle, or period, of the wave. So when the scope showed a frequency of 76hz, I had to first divide that by 2 to get revolutions/second, then I could multiply by 60 to get revolutions/minute.
