Robot moving, but unreliably

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: https://www.aliexpress.com/item/Endstop-Mechanical-Limit-Switches-3D-Printer-Switch-for-RAMPS-1-4-Free-Shipping-Dropshipping/32640551085.html. 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.

Unproductive day

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.

More SolidWorks

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="http://www.w3.org/2000/svg">');

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,
                r=diam/2*pix_per_unit))

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

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

print ('</svg>')

Power board soldered

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.

Soldering failure

I am in a really bad mood—I’ve wasted an entire day soldering today, with nothing to show for it at the end.

I’ve been putting off soldering up some of my circuits, because I really hate perfboard soldering.  I don’t mind soldering PC boards (though I have a lot of difficulty with surface-mount components, so generally only use through-hole parts), but the need to make solder bridges and add extra wires makes perfboard soldering slow and frustrating.

I finally laid out my power board and started soldering it up today. It was going slowly, but not too badly, and I was 4 wires from the end of the job (after many hours work) when I saw that there were 5 posts left for the 4 wires—something was badly wrong.  I checked carefully, and found that I had put an 18-pin socket in where I needed a 16-pin socket.  I had two choices—leave the 18-pin socket in place and just put the chip in the end of it (with some risk of putting the chip in wrong), or replace the 18-pin socket with a 16-pin one.

I made the mistake of trying to unsolder the 18-pin socket to replace it with a 16-pin one. As I should have expected, I could not get the 18-pin socket out of the perfboard, and my attempt to do so made it nearly impossible to use the perfboard (some rings delaminated without releasing the pins, some of the pins of the socket are now too short to connect wires to, …).

My plan for today was to solder up two boards: the power board and the processor board, so that tomorrow I could start debugging my motor-control code. I’ve come to the end of the day and I have made essentially no progress (possibly negative progress, as I may not have enough spares to make the power board from scratch tomorrow).  I’m not going to try to do anything more tonight (except sleep, which will be a bit difficult given how frustrated I’m feeling).  In the morning, I’ll see if I can resolder the board to use the 18-pin socket, or whether I have to scrap it entirely.

If I take up making robots as a hobby (which I’ve considered), I’m going to do things at a somewhat slower pace, so that I can design PC boards rather than deal with the f***ing perfboard soldering.  I don’t care if it would add three weeks to a project to do a PC board—perfboard soldering is so frustrating that I would never finish a project if I had to do a lot of it. There are other prototyping possibilities besides PC boards and perfboards—for example, Adafruit’s Perma-protoboards or stripboard.  I’ve used the Perma-protoboards, and they are much easier to work with than perfboard, but I don’t have the space in my robot for a full size one (even if I had one at home to build on).

There are only two weeks left of the quarter, and I’m going to have to make a decision soon whether to finish a part of the project (I’ve already given up on the ball launchers) or to drop the whole project and go back to work on my book, which is now several weeks behind schedule.  I had hoped to build a reusable base that I could use for other robotics projects, even if I had nothing that could compete in the mechatronics competition, but even that is beginning to look like it will take more time than I can afford to spend.