Brief review of the 6V 1000 RPM gearmotor from ebay

This is an attempt to find a less expensive replacement for the pricey but effective FingerTech Silver Sparks for use in beetleweight (3 lb) combat robots. Note, Gold Sparks are so bad they really shouldn't be sold as robot gearboxes. A gearbox that strips under the load of driving straight is a little ridiculous.

The rundown of this motor with a 4S, 16.6 V battery:

Max speed: 2400 RPM
No load current: 90 mA
Stall current: 1.7 A
Torque: unsuitable for a 3 lb robot, unless you use many motors or small wheels

Comparing with a Silver Spark under the same conditions:

Max speed: 1200 RPM
No load current: 130 mA
Stall current: >2 A
Torque: previously used on 3 lb robots to good results

The torque on the chinamotor was significantly less, but expected, given its higher speed, smaller size, and lower current.

 The chinamotor gearbox disassembled.

 The silver spark gearbox disassembled. It seems like it has an extra stage.

 The motor gears have the same size and pitch.

And the gearboxes are pretty similar. The chinamotor gearbox isn't crimped together, so it likes to come apart, and it has a longer bushing.

What about a gearbox swap?

It produces what feels like enough torque for a two motor beetleweight and tops out around 1200 RPM, similar to the Silver Spark. The downside is that due to a smaller size, it heats up much faster, so proper driving to avoid stalling is important. Seems like I should get the 500 RPM variant instead.


When I get a robot together I'll see how these do.

Agent Colson: The combat robot that's mostly wheel

Agent Colson is a continuation of 6" Colson wheel based robots started by Jamo and Colson Bot.

Expected

Result

The robot is as simple as it gets. All the components strapped to an aluminum plate. A pair of Pololu/Sanyo 10:1 micro gearmotors pushes this thing at 5 ft/s. A 26 x 28 mm brushless spins the Colson wheel, though it is a touch underpowered. A pair of vextrollers (Vex Motor Controller 29) move the drive motors.

The Colson wheel itself is hollowed out on the lathe and the rotor of the motor pressed into it.

So much swarf.

So many voids

The two halves are held together only by the magnetism within the two sections of the brushless motor. It works okay, only coming apart during significant impact. In the spinup test video below, Youtube chopped and clipped the audio to hell, so mute the video for your ears.

PA Bot Blast

Meeting colsonbot

Agent Colson took a beating during PA Bot Blast 2013 (but is still alive?). During its first match with the Weta clone Mondo Bizarro, it was beat on until it flew apart into two halves.

Reassembled, but only slightly dented.

Then it was experimented on with Final Exam to see how hard Final Exam hits.

Final Exam hits hard when given the chance.

In the end, all the hot glue holding everything together came off, the brushless controller died, and a drive motor disassembled itself.

It was really fun though. Maybe I'll fix it up with a bigger drive motor for Dragoncon (but not really).

Gyro King Performance

Gyro King was a finicky robot. Xo and I never got it spinning at our hoped for 6000 RPM, only reaching a measly 2000 RPM. In addition, motors have really low bandwidth compared to their drive circuitry, thanks to inertia and inductance. Thus, while the robot can drift and move while spinning, it was incredibly slow, and by the time you moved anywhere significant, the internal heading would have changed, and your target is somewhere else. Thus, it performed like other melty robots - waiting for the other robot to run into it and break itself. Not very fun, especially when your robot speed determines how much bite the weapon gets, leading to how much energy gets transferred.

In this 2 vs 2 match Gyro King is basically stuck in the corner the entire match. Granted, it only had one motor working at this time, but I don't think the second motor would have changed much.

A much more interesting match. This is at GMX 2012, with both motors working. This match also shows another problem: the weapon teeth have an annoying habit of flying off by shearing the four 6-32 screws holding it on. Here it was because The Hammer's weapon was able to dig underneath the teeth and pull them out. Since the frame is aluminum, it didn't offer much resistance. Gyro King won through a stroke of luck. The Hammer used a toggle switch for main power. It was hit so hard the switch toggled and shut down the robot halfway in the match.

The same competition, but against a nimble opponent. As you can see Gyro King cannot really do anything. It wins only through the error of the opposing operator accidentally driving into the pit, taking himself out of the match.

A fun match against a very capable robot. In the first couple of hits Gyro King's teeth are knocked out. One hit almost sends Gyro King out of the arena. You can really see how the limited mobility prevents it from taking advantage of Dominant Mode's inversion.

In conclusion, Gyro King was a fun project, an experiment in high impact and high strength components and seeing how many types of electronics we can stuff onto a single board, and a test of mettle, but next time I'm building something a little more aggressive.

A Guide to Better Dithering on Laser Engravers

Introduction

When laser engraving images that are not binary black and white, you usually get a couple options. The first is to use relief engraving, which uses the grayscale version of the image to control the power of the laser. This creates nifty 3D contours of your image, but often the difference in "colors" is small. The image only becomes visible when looking at it at an angle, if at all. The second option is to use the built in dithering. By using a pattern of dark or light dots, this ensures gives better control of how dark colors appear. However, the built in dithering is, in my opinion, pretty dumb. With the power of GIMP and a bunch of test engraves, we can do better.

From source image to engraving! Source image by jtobijah.
The dots are slightly different because I lost the original processed image, and forgot the settings.

Improving on vanilla dithering

The major improvements I worked out are:

• Using the actual colors of the engraved material when calculating dithering.
• Using a low DPI image, so the laser makes multiple passes per image pixel.

Each additional color added into the dithering algorithm vastly improves the range of shades represented by dithering and the quality of each shade. Since my method allows different "colors" to be etched at different speeds and powers, more colors can be squeezed out the material.

The Tutorial

Step 1

First, collect the tools. I used GIMP for all my image processing. I'm sure you can find the equivalent commands in your program of choice.

Step 2

Next is to figure out what colors you can etch onto your material. The more distinct colors you can make, the better, giving the dithering more options. A good way I find is to etch a bunch of these gradients at various speeds and work from there.

Test gradient!

For wood, etching makes things darker, but for acrylic, etching makes things lighter. Make a bunch of test cuts at different speeds and powers to see what colors you can get. I find slow cuts at low power create good darks on wood without etching too deep.

There is a problem, when you etch very dark colors the surrounding areas are scorched. While sanding off the scorches works, there are a couple exceptions. When you have standalone unetched pixels surrounded by light pixels, sanding tends to break them off. Or, if you're working with the cheapest craft plywood in existence you found in the scrap bin, any kind of sanding will quickly eat through the very thin veneer and reveal the glue below. What I did was use an low power at the highest speed to blast off a extremely thin layer off the top without any significant darkening.

Make sure you write down what laser settings you used for each power. As learned from experience, don't trust yourself to remember it.

Once the colors have been determined fire up GIMP to enter the colors into a custom palette. To do this first open up the palette window by clicking Windows -> Dockable Dialogs -> Palettes.

Palette window on the left, new palette on the right, with dark etch, light etch, and unetched material color.

Do not forget the color of the unetched or "laser sanded" material as well. Try to match the colors as close as possible.

Step 3

The classic test image.

Open up your image of choice. First we lower the source image's dots/pixels per inch (hereby referred to as DPI) to match that of the laser. I find 100 DPI is the highest resolution I can go before single pixels start failing to form. Make sure your image still fits on your material after changing the DPI. In GIMP you can do this through Image -> Scale Image.

It also helps to change image size to inches/mm to get a good idea of its real size at this low DPI.

Then comes the magic. Change the color mode from RGB or whatever it started as to indexed. Do this by Image -> Mode -> Indexed. The dialog below will come up. Choose the palette you created in Step 2, and pick a good dithering mode. The Floyd-Steinberg flavors creates dithering without (intentional) patterns while Positioned does. This converts your image to use only the colors in your palette, which in turn are all the colors your laser can recreate. If the output is too much of one shade, try tweaking the brightness and contrast before converting your image to indexed mode.

Converting to indexed. If you get big blotches of color, you either forgot to turn on dithering or actually have big blotches of color in your source image.

Since the material colors are input into GIMP, this is what the engraved material will actually look like.

When the image looks good, the next step is to convert it into an image with colors the laser software can use to define different layers (like solid red, green, blue, etc). To do this first convert the image back to RGB by Image -> Mode -> RGB. Then use the select by color tool to select a color, making sure the threshold is zero and no feathering or antialiasing nonsense is turned on, and set it to the laser software friendly color by using the fill tool set to fill the entire selection. It will look a litte funny.

Don't worry, the laser will know what's going on.

Finally increase the resolution to some multiple of what it was (here it was 100 DPI), so the laser makes multiple passes per pixel. I used 400. So, through the same image scaling dialog as before, first change the pixels per inch to 400, then change the image size to the same physical dimensions as before. This means multiplying its width and height by 4. Make sure you set interpolation to none or all your colors are going to be messed up.

Step 4

Unfortunately, I have no pictures of the laser setup because I don't have a laser anymore. I just have to believe in you, the reader, to get it right, eventually.

Set your laser cutting speeds. Based on the colors you used in your source image, set the laser speeds and powers corresponding to that color. So if you set the dark engrave to red in your image, set red to make the dark engrave in your laser program. Import the image into your laser cutter software and do whatever tweaks you need (adding a cut line, etc). Print your image, making sure the DPI setting on the laser is the same as your source image (here I used 400). Enjoy the wait.

Gallery

It even works on pictures. Source image by CopyX.
The dots are slightly different because I lost the original processed image, and forgot the settings. 

Paper Mario sprite.

Another Paper Mario sprite.

Marceline from Adventure Time. The chipping at the bottom can happen when you try to sand cheap craft plywood.

Somewhat irrelevant, but you can also laser engrave mashed potatoes.

Gyro King Electronic Design and the STM32F40RGT6 Microcontroller

Gyroscope

The control board is centered one of Analog Devices' highest rate gyro, the ADXRS649, rated for 20000 degrees per second but extendible to 50000 degrees per second, or around 8000 RPM. We chose the gyroscope as opposed to Open Melt's accelerometer method to avoid noise issues. While accelerometers will pick up any and all vibrations, gyroscopes are quite a bit more noise resistant. This is offset by the difficulty of finding a gyro with a large enough range and having to place the gyro at the exact center of rotation, since applying acceleration to a gyroscope causes error. Otherwise, all the other challenges are there, such as keeping the sensor in a constant position and orientation as the robot spins around and smashes things.

Analog to Digital Converter (ADC)

The gyroscope outputs a 5V analog signal, with zero rotation at 2.5V. This works out to 50 uV per degree, ideally. Our gyroscope ended up with a range of around 65000 degrees per second due to some curious part choices, making it 38 uV per degree. Thus, we needed accuracy in converting the analog to a digital signal. We used a 24-bit, 14 kSPS ADC from TI, the ADS1259.

Microcontroller

The ADC feeds into the STM32F405RGT6, an ARM Cortex-M4 32 bit microcontroller. The microcontroller was provided from Newark, a pretty good place to get parts. Why this microcontroller?

What stands out is this is an extremely high power chip without being weird. First thing we noticed is how little physical space it needs. It uses a standard 3.3 volt input, avoiding a separate 1.7 volt supply. There's no external RAM or even an oscillator required. All it needed was power. Instead of using the giant 20 pin ARM JTAG nonsense, it uses just 4 wires. On a space limited board such as Gyro King's, every square millimeter counts. And in return we got a 168 MHz processor with a floating point unit, allowing us to avoid the performance vs. fixed point tradeoff, extremely powerful timers, which was used in a previous project to control two three-phase motors with center-aligned PWM, dead time, and ADC triggers, and DMA on many peripherals to save your cycles and automate data capture. Notably, it has a completely free toolchain for compiling programs. Although difficult to set up on OSX, it is possible and certainly usable. Finally, this STM32 is RTOS (Real Time Operating System) friendly. We used the open source ChibiOS. This let us use higher level programming, such as multiple threads, and abstracted a lot of the lower level access. All things considered, a solid microcontroller.

Three Phase Motor Control and Drive

While it is entirely possible to generate the drive motors' three phase commutation signals and sense the rotor position directly from the microcontroller, we were pressed on time and feeling a bit lazy. We turned to Allegro MicroSystems' A4960 Automotive Sensorless BLDC controller. These chips perform sensorless commutation, start up, directly drive the motor MOSFETS, and current limiting all from some configuration from the microcontroller and a PWM signal. Using these significantly reduced development time, though we still have to tune all the parameters of commutation, such as dead time, zero crossing window, phase advance, and commutation blank time.

The Allegro controllers directly connect to a trio of half bridges composed of the IRFH5301TR1PBF N-channel MOSFETS, rated for 35A at 30V.

Board Layout and other Doodads

Connectivity was handled by a little Bluetooth doodad, the Roving Networks RN41-I/RM board. It was directly soldered on to the control board. It connected to a laptop running a pygame based GUI displaying things like spin speed, power, and direction. The controller is a PS3 controller.

The control board also had some good ideas, like a few status LEDs and what looks like a bar of ceramic bus capacitors, since electrolytics would not fit height-wise. A digital Hall-effect sensor was also on there to be used for calibration. Ideally, it would function as an on-board tachometer to a magnet held above it, providing an absolute reference for the rate of rotation, but was never implemented in software.

The board used four layers, to provide full ground planes to try to separate the combination of sensitive analog, digital, power regulation, and motor control on a tiny single board.

A notable bad idea was using test pads as the programming header. Due to space limitations we couldn't fit a full through hole header, so we used surface mount test pads. Of course they ripped out.

Conclusion

This was a pretty solid control board, surviving the impacts of robot battle while tracking well enough to provide a near constant direction at speeds up to 2000 RPM, the max we've seen it spin at. The component choices were all well made. We wouldn't use test pads as headers again though. Xo would go on to make a variation of this board with one brushless driver and two brushed drivers, but otherwise similar hardware.

I should also take pictures next time too.