Gas station without pumps

2018 March 13

Cabrillo College Robotics

Filed under: Robotics — gasstationwithoutpumps @ 13:56
Tags: , ,

I just donated to the Cabrillo College Robotics Club, to help them send students to the NASA Swarmathon this year:

I am not affiliated with Cabrillo College in any way (except as a resident of the county which they serve), but I’ve been impressed with their recent attempts to better serve the community, with an extensive Extension program of non-credit courses and a new Makerspace. So I look for small ways to support Cabrillo College.

The Cabrillo College Robotics Club looks like a good opportunity.They are trying to raise $7000 in a month, which may be difficult, given the resources available to community-college students.  The goal is to send the team to the NASA Swarmathon in April.  They won the 2016 NASA Swarmathon Virtual Challenge, and they are hoping to win the 2018 in-person competition this year, but first they need the funds to go there.

2018 January 1

Robot moving, but unreliably

Filed under: Robotics — gasstationwithoutpumps @ 10:05
Tags: ,

I got some time last week to play with my uncompleted robot from the mechatronics course.  I wired up all the motor and encoder connections and wrote a short program that was supposed to move the robot in a square (forward for 12″, 90° right turn, repeat).  I did not expect it to work well—some calibration of the distances was clearly going to be needed, but I expected repeatable motion.

I got sort of repeatable motion on the wooden dining-room floor, though the angle of the turns was not right, but on the rougher tile floor in the breakfast room and kitchen it would occasionally get stuck turning in a circle with one wheel stopped and the other running forward continuously.

Diagnosing the problem was fairly simple—the count for the number of steps from the encoder of the continuously turning wheel was not increasing, so the robot thought that no progress was being made and kept running that motor, while slowing down the motor whose count was still increasing until that motor stopped (near the target number of counts).  The reason that the count was not increasing was that the connector from the encoder to the PC board was shaking loose—pressing the connection sideways would often restore the counting and return the robot to its advance-and-turn behavior.

Fixing the problem is more difficult.  I had crimped female headers onto the wires from the motor and encoders to the PC board, and even put a little solder in the crimped joint, because the 28-gauge stranded wires did not work well with the crimped headers.  The connection failure now seems to be between the male header pins and the female crimp-on connector, which is hard to do much about.

The short wires from the motor and encoders are on a 6-pin 2-mm-pitch female connector (similar to the JST PH connector, though probably not a brand-name connector—that connector seems to be made by all the major connector manufacturers and knockoffs made in China are common). I can get cheap cable assemblies for such connectors, with either bare wire ends (as came with the motor) or with the female connector on both ends of the cable.  Because the pitch is 2mm, rather than 2.54mm, such connectors are not usable with breadboards or perfboards.

I’m now facing two choices:

  • Solder the motor/encoder cables to my perfboard, rather than using the failing header-pin connections.
  • Make a custom PC board for the motor controller with the 6-pin 2mm-pitch connectors for pluggable connections.

The soldering would be a quick fix, at least until the thin wires broke, but is a bit of a pain, as my power board was crammed rather tight. The PC board is a better long-term option, but I need to look ahead to all the different things I might want the robot to do, as it will be difficult to rewire or reassign pins with a PC board.  If I do a PC board, I again have two options:

  • Do a motor-controller-only PC board, with 4-pin or 6-pin headers to the existing processor board.
  • Put the processor, motor-controller, and interface electronics all on one mother board, with cable connections to the sensors.

The combined board would reduce the cabling and number of connectors that might fail, as well as taking up less total space (on-board connections are much more compact than connectors and cables), but I’d need to figure out what I want to do with all the pins of the Teensy 3.2, as adding connections later would be tough, unless I allowed for expansion now.

If I’m going to do a custom PC board, I should do it this week, before classes start, as I’ll be spending all my time on the applied electronics course (lecturing, running labs, and grading) once the quarter starts.

The vibration on the rough surface of the tile floor also revealed another problem for the robot—the M3 bolts (machine screws) that held the bumper on vibrated loose, resulting in the bumper drooping and getting caught on my sleeve when I picked the robot up.  The bumper then cracked at the narrowest part.  I need to get some M3 lock nuts, I think, and redesign the bumper to be a little more robust.  Unfortunately, I no longer have access to the labs that have SolidWorks installed (turned off when all the student access to the labs was turned off), though I still have access to the laser cutter—I may have to request access again.

Incidentally, AliExpress recently sent me a suggestion for a slightly better way to connect the bumper switches: These switches are mounted on a PC board with a sturdy connector and an LED that lights up when the switch is pressed.  Unfortunately, the 3-wire connection they use does not follow the standard used for servo wiring, as they put the positive connection on the outside and the GND in the middle, swapping these two wires.

2017 December 1

Unproductive day

Filed under: Robotics — gasstationwithoutpumps @ 16:35
Tags: , , , ,

I’ve had a very unproductive day today.

  • I spent all morning responding to an IRS letter about my 2015 taxes—they wanted an extra $4000 from me, but they were wrong on everything they were asking for.  They claimed I hadn’t reported some of my income: it was on Schedule C (they may have been expecting it on Schedule D, where it would not have been subject to self-employment tax).  They wanted to charge me tax and penalties for withdrawals from my 529 college savings plan, though the qualified expenses (counting just what I paid directly to UCSB) exceeded what I had withdrawn. I had documentation for everything, but it took hours to find it all, print it, write a letter, and mail it.
  • I spent an hour trying to buy tickets to the Actors’ Theatre performances for 2018. The purchase was a simple one: I wanted 2 season tickets to all their shows, plus an extra ticket for the two opening nights of 8 10s @8.  When I went to Brown Paper Tickets, I couldn’t figure out how to specify which shows I wanted tickets to (the subscription purchase had a menu with only one date selectable).  I called their help line (twice—the first time I had not moved up at all in the queue after over 5 minutes), and found out that the subscription tickets only allowed selection of dates after the subscription had been purchased, as something called “pass management”.  There was no indication of this anywhere in their brochures or on the Brown Paper Ticket site.  So I tried again, but when I got to pass management, it told me that I was selecting dates just for the 8 10s @ 8 2-show package, and did not have the number of tickets I needed.  So I called their help line again.  It turns out that the 2-night package for 8 10s @8 doesn’t use pass management—instead you have to buy the ticket twice, with the different dates.  I had the person on the phone cancel that order (it had already been charged to my card) and made a third attempt at purchasing the tickets.  This time I managed to get the tickets I wanted, though there was no e-mail sent acknowledging the dates that I had selected and no e-mail sent for the cancelled order.  This has got to have been one of the worst ticket-ordering experiences I’ve ever had.  Both Brown Paper tickets and Actors’ Theatre are at fault for a very user-unfriendly experience.

In other news, yesterday I got a new third layer laser cut for robot and I soldered up the processor board.  The third layer probably should be cut once more, because one of the mounting holes for the beacon board is partly blocked by the supports from the 2nd layer.  But the beacon board can be mounted with just one screw holding the other standoff and a bit of tape to keep the standoff that can’t be screwed down from rotating, so I probably won’t bother.

I also got the processor board soldered last night:

The processor board was much easier to solder than the other board, because most of the wires are just short jumpers from header pins to the female headers holding the Teensy 3.2.

I do have a diode separating the 5V on the Teensy board from the 5V input from the first layer. This is to prevent power-supply fights if a USB cable is plugged in for reprogramming. I am a little worried that I hooked up the post-diode 5V to the interface pins for the beacon-detector board, which also has a diode to prevent power-supply fights. The double diode drop may be too much—I should probably rewire that pin to be connected to the input 5V instead.

The SPI interface is on the left in this picture, the bumper switch connections are the 3 pairs of pins at the top (though only two are connected to Teensy pins), the run of 4 yellow pins are the encoder connections, and the 4 white pins next to them are the motor-control pins.  Power and gnd come in adjacent to the motor-control pins. The two white-red-black triples on the bottom are for the track-wire detectors, and the 4 white pins next to them are the selection and mux pins for the tape sensors.

Note that this processor board has connections for all the sensors (motor encoders, tape sensors, track-wire detector, and SPI to beacon detector) but the only actuator connections are the drive motors. I have four unused pins that could be used for the ball launchers, but I’m not planning now on building any launchers—there just isn’t enough time left. I’ll be happy if I can get turtle graphics and tape following implemented by next week.

I still need some cables (one 6-wire for power and motor control, one 4-wire for encoders, and one 4-wire for tape sensors), which I was going to make today, but the IRS thing and the hassle with the Actors’ Theatre ticket purchase sapped me of my desire to do anything.

2017 November 28

More SolidWorks

Filed under: Robotics — gasstationwithoutpumps @ 22:24
Tags: , , , , , ,

I spent most of my day today with SolidWorks, fixing the problems noted in Bugs found in first assembly of robot and adding new layers to the robot. I’m getting a bit better at using SolidWorks, but I still find it to be an overly complicated interface with way too many modes.  I’m sure that there is a way to get it to start up with reasonable document parameters (like using mm instead of inches, or using the same settings as already open documents), but I’ve not taken the time to try to track that down.

Here is the model as it stands so far:

View from the front left of the robot. The octagon floating on top is a the beacon-detector board, which will be on standoffs that I didn’t bother to include in the model.

I cut out the three layers of the robot today, making two mistakes in the process. One mistake I caught right away, and just recut the layer after fixing the problem—there was an extra alignment circle that was not supposed to be cut that I had forgotten to erase. The other error was just as serious, but I didn’t notice it until I got home—the top layer did not have the slots cut in it for the spacers from layer 2 to layer 3. It is hard to notice this problem in looking at the SolidWorks model, as the 3D model looks the same whether the slots are cut or not. I should have noticed it when I created the dxf file for cutting the third layer, but by then I was getting pretty tired and careless. I’ll have to cut another copy on Thursday.  Luckily MDF is cheap—each layer costs me about $1, and I still have half a dozen 1-foot squares of MDF left.

Incidentally, I came up with what I think will be a cheap fix for the potential problem of the bumper springs not being stiff enough.  I added another switch front and center, just for the spring in the switch to push the bumper forward.  At 60¢ a switch, this is not a particularly expensive way to add a spring, and it saved me a lot of modeling and building time.  I could even wire up the switch if I can think of a use for it.

One other thing I made today was a “drill” test, to see what size holes were really made by the laser cutter from specifications.  I created the guide in SVG using a short Python program (so that I could tweak things easily. It took me quite a while to get the SVG just right, because of weird limitations of SVG, like that the path commands can’t take units for the coordinates. Also because I was using Inkscape to translate the SVG to the DXF format that the RDWorks laser-cutter software needs, and Inkscape assumes that the “pixels” are 90/inch for that conversion.  It is kind of messed up that SVG works in terms of “pixels”, since it is supposed to be Scalable Vector Graphics.  Inkscape only converts paths to DXF (not other shapes, like circles and text), so I wrote the program to generate paths and used Inkscape’s object-to-path conversion to convert the text.

Here is the piece I cut:

The circles were cut at 14mm/s and 100% (actually clipped at 67%) and the numbers were written at 140mm/s and 20%.

The holes were exactly the right size (to the 0.1mm limitations of my calipers), and the circular pieces that were cut out were 0.35–0.4mm smaller in diameter. That is, the kerf is about 0.19±0.02mm and it is on the inside of arcs.

Here is the code I used for generating the SVG file:

#!/usr/bin/env python

from __future__ import division, print_function

# all sizes are given in units of 0.1 mm

# Inkscape coverts pixels to real-world units in DXF at 90 pixels/in

pix_per_inch = 90
mm_per_inch = 25.4
pix_per_mm = pix_per_inch / mm_per_inch
pix_per_unit = 0.1*pix_per_mm

print('<?xml version="1.0" encoding="UTF-8" standalone="no"?>')
print('<svg width="150mm" height="150mm" xmlns="">');

y=100   # y-position of first row of circles

x_space = 60    # spacing between circles
stroke = 1       # stroke-width

xmax = None     # largest value for x

text_space =35  # space from circle to label

for diams in [range(5,50,5), range(50,80,5), range(80,105,5), range(105,130,5)]:
    x=100 # left edge of first circle
    for diam in diams:
        x += diam/2
        print ('<path stroke="red" fill="none" stroke-width="1" d="M {sx},{sy} \
a {r},{r} 0,0,0 {r},{r} \
a {r},{r} 0,0,0 {r},-{r} \
a {r},{r} 0,0,0 -{r},-{r} \
a {r},{r} 0,0,0 -{r},{r} z" />'.format(sx=(x-diam/2)*pix_per_unit, sy=y*pix_per_unit,

        print('<text x="{}" y="{}" stroke="blue" fill="blue" text-anchor="middle" font-family="Verdana" font-size="10">'.format(
        x += diam/2 + x_space
        if xmax is None or x>xmax:
                xmax = x

print('<path stroke="red" fill="none" stroke-width="1" d="M 0,0 h {} v {} h {} z" />'.format(

print ('</svg>')

2017 November 27

Power board soldered

Filed under: Robotics — gasstationwithoutpumps @ 13:26
Tags: , ,

This morning I managed to fix the problems that I had created for myself by my mistakes in soldering yesterday.  The power board is  now soldered and passes continuity tests (no adjacent pins shorted, all header pins connected where they are supposed to be.

Finished board, with annotation for the header pins. The whole board is 5cm×7cm.

The power board has several functions:

  • The pair of H-bridges for the motors, powered directly from battery power input at the lower left, and controlled by PWM and DIR signals from the Teensy board (header pins at the top). The motor output wires are red and white header pins on the left side of the board, to match the red and white wires on the motors.  The two motors have red and white with opposite M1/M2 connections, so that matching DIR signal drives the motors in opposite directions.  Because the motors are mounted with shafts in opposite directions, this should result in the wheels turning the same way.
    There is a row of header pins on the right (input side) of each H-bridge, for hooking up oscilloscopes or other test equipment.  The EN– signal could be shorted to GND with a shorting plug, but the documentation claims that there is a pull-down resistor internally, so floating should be fine.
    The VM pins of the H-bridges have 220µF electrolytic capacitors as bypass, to reduce PWM noise from propagating back through the battery.  I was planning to add 10µF ceramic capacitors at the Vin pins, to reduce high-frequency noise, but I ran out of room.  If the high-frequency noise is a problem, I can try to squeeze in some bypass capacitors.
  • NCP7805 5V 1A regulator (bottom center).  All the red and black pair to the right of the motor control are 5V and GND.  The GND pin of the regulator is the only place where the 5V and battery power systems are connected.
  • The multiplexer connects one of the 8 white pins on the top right to the “out” pin, controlled by S2, S1, and S0. Up to 8 tape sensors can be connected with standard 3-wire servo cables.
  • The 8 yellow pins are not connected to anything—they are there just to provide alignment for servo cables sending 5V power to other boards.  I may not need any of these connections, as the Teensy board can be powered from the 5V and Gnd connections adjacent to the motor signals and tape-sensor signals.
  • There are also 4 pairs of yellow pins just above and to the right of the regulator.  These are intended for gathering the encoder wires from the two motors and transferring them to a single cable up to the Teensy board.  The power and ground connections there can also be used for the encoders.

This board will have a mass of connectors to it:

  • battery (3-wire servo cable)
  • motor connections (4 separate wires)
  • motor encoder connections  (8 separate wires: +5V, GND, ENC1, and ENC2 for each motor)
  • motor cable from Teensy (4 wires or 6 wires, depending whether 5V and GND included)
  • tape-sensor cable to Teensy (4 wires or 6 wires, depending whether 5V and GND included)
  • encoder cable to Teensy (4 wires)
  • tape-wire sensors (3-wire servo cable to each sensor)

I still have to lay out and solder the carrier board for the Teensy, but that should be relatively easy, as I don’t have nearly so many wires and I only need to populate a few of the connectors.

Next Page »

%d bloggers like this: