karplus4arduino

2011 July 31

More design errors in hexmotor rev1.3

I should have known better than to send the PC board to fab before I wrote the software.  That’s precisely the sort of optimistic thinking I chide my students for.  There are all sorts of design errors that can be uncovered when you work out the details of how to use the hardware.

In my case, the motor functionality of the board all looks ok (so far), but the extra servo functionality is somewhat messed up, because I had not really understood how servos are controlled and how the Arduino servo library uses pins.  I “knew” that servos used pulse width to control position, but I had not bothered to look into the details or think about exactly what that meant—I just assumed that you had to use the PWM pins for the purpose.  Wrong!  If I’d ever actually used a servo with the Arduino, I would have known better.

Servo control is based on the actual on-time of the pulses, not the ratio of on-time to off-time (as is the case for controlling brushed DC motors).  You do have to give up one of the timers used for PWM in order to control the pulse width, but you can provide the pulses on any output pin.  The Arduino Servo documentation clearly says

The Servo library supports up to 12 motors on most Arduino boards and 48 on the Arduino Mega. On boards other than the Mega, use of the library disables analogWrite() (PWM) functionality on pins 9 and 10, whether or not there is a Servo on those pins. On the Mega, up to 12 servos can be used without interfering with PWM functionality; use of 12 to 23 motors will disable PWM on pins 11 and 12.

So putting servo control on the PWM pins is precisely the wrong choice of pins for maximum flexibility.  The hexmotor rev1.3 board has more or less the capabilities I thought it had (I can do up to 6 servos or up to 6 motors, and I can trade off servos for PWM control of motors, though I always have to give up PWM control of motors 4 and 5 to get any servos).  The initial application of the hexmotor board called for 4 fully PWM-controlled motors and 2 extra controls that could be motors or servos.  We can still do that, though we have a choice of 2 PWM-controlled motors or 2 servos and 2 forward/backward/brake (not PWM control), and can’t mix a servo with a 5th PWM-control motor.

But there is no reason to limit the board the way I did.  With slightly different wiring I could have simultaneously allowed 4 PWM-controlled motors, 2 forward/backward/brake motors, and 5 servos, with the main limitation being the power to the servos (due to the 1.5A limit of the switching regulator).  Three extra servo outputs could be really handy!

I also did not think about making the board compatible with the Arduino Mega board.  The current design does not use the Arduino Mega’s extra pins, which is no big deal, but it also blocks access to those pins, which could be a problem.  Furthermore, I did not look at what pins the Arduino Mega provides PWM on, nor which it gives up for the Servo library.

Incidentally, I was frustrated in looking on the Arduino site for the pin mapping of the Arduino Mega boards—they’d hidden that essential information behind a password (for no discernible reason).  I finally found the Mega pinout info on the forums, where someone frustrated by the inaccessibility of the pin mapping page had re-created it from other documentation.  It turns out that all the digital pins 2 through 13 can be used for PWM on the Mega, so any redesign I do on the board would have at least as much functionality on the Mega as on the standard Arduino.  I will have to be careful to put in conditionals for the pins in the software, though, as some of the pins are mapped from different ports on the Mega.

Redesigning the board to pass through the Arduino Mega pins would be a pain, as the pins take up three sides of the 1.825″×4″ footprint of the Mega board, and the remaining side is where the USB and power connectors are, so through-hole components can’t be mounted there.  I don’t think I can fit in all the TLE-5206-2 chips and screw terminals for the 12v power and motors and stay below the Eagle 8cm×10cm board size limit if I have to put in connectors for all the Arduino Mega pins.

I won’t be able to stack boards above the motor board anyway, as the electrolytic capacitors I’ve designed in to clean up the power are very tall (2cm), as are the TLE-2506-2 chips: particularly if I put on heatsinks.  I’ve bought a strip of 1/8″ thick, 3/4″ wide aluminum bar stock for a heatsink—I plan to drill 6 holes in it to bolt the TLE-5206-2 chips to.  It won’t matter if the bar connects the chips electrically, as they all have a common ground connection anyway.

I think that I’ll populate one rev 1.3 board with only 4 TLE-5206-2 chips, the minimum for the robotics club to be able to experiment with their underwater vehicle, and see how it works before making a new set of boards with full functionality.

So, for rev 2.1 I’m definitely going to change the way that the servo outputs are wired and make sure the software can work with the Arduino Mega boards, but I won’t be trying to connect to the Arduino Mega’s other pins. (Hmmm—I just had an idea for how I could pack everything in, with a massive rearrangement of components.  I might try that as separate branch of the design, to see whether it really is feasible.)

2011 July 23

Possibly salvage the boards

My son and I were looking together about whether we could salvage the board design by using the TLE-5206-2 parts that are available.

The pinout is identical, but the functionality is different.

In1 In2 5205 out1/out2 5206 out1/out2
0 0 1/0 0/0
0 1 0/1 0/1
1 0 0/0 1/0
1 1 Z/Z 1/1

The arrangements of signals that I have available to jumper to were S, PWM, and S+PWM.  The easy jumper arrangements I had were (IN1=S, IN2=PWM) and (IN1=PWM, IN2=S+PWM), which with the TLE-5205 were supposed to give me lock anti-phase drive and sign-magnitude drive.

With the 5206, lock anti-phase would require (IN1=PWM, IN2=not PWM), which I don’t have available, but the jumper setting (IN1=S, IN2=PWM) now almost makes sense as active collapse (run/brake) mode (except that it is not quite sign magnitude, since the interpretation of the pulse width is flipped depending which way the motor is supposed to turn).  The other jumper setting makes no sense.

So now I have choice:

  1. Populate a board with TLE-5206 chips and have only the run/brake mode (I could solder in jumpers, since there are no choices).  I could also omit the now-useless OR gates.
  2. Design a new board with the TLE-5206 chips in mind, with jumpering between two modes:
    • (IN1=S, IN2=S xor PWM)   run/brake with consistent magnitude interpretation
    • (IN1=PWM, IN2=S xor PWM)  lock anti-phase if S=1, brake if S=0

Wait a second!  I don’t need a new board for that! If I replace the 74HC32 quad nor-gate with a 74HC86 quad Xor, then the 5-pin headers will be

S IN1 PWM IN2 S xor PWM

I can solder the IN2 pin to S xor PWM, and just have a 3-pin header to connect IN1 to either S (for run/brake) or PWM (for lock anti-phase). The labeling on the silk screen will be wrong, but the board will be fully usable!

The interpretation of the pulse width modulation if  IN1 is set to PWM is that 0 means always on and 255 means always braking, which is kind of weird, but easily compensated for in the software. S determines the direction the motor turns.

If IN1 is set to S, then S is interpreted as RUN if it is high, STOP if it is low, and PWM gives the direction and magnitude when running (with 0 being full on in one direction and 255 being full on in the opposite direction).  PWM should probably be set to constant 0 when braking.

I think the board can be saved, and still have all the functions we needed, though we switched from sign-magnitude to active collapse as one of the modes.  The next revision of the board (if I need to make more) would fix the silk screen and replace the 5-pin header with a 3-pin header for each chip.

H-bridge not available

I’ll be getting a decorative but useless PC board next week.  It is a good thing it only cost me $50.

It turns out that the H-bridge that was recommended to me, Infineon’s TLE-5205, is made of unobtanium.  I thought I had checked Digi-Key’s stock before starting my design, but I must have mistyped the part number, as Digi-Key customer service just called me to say that they haven’t had any since Sept 2010 and don’t expect any in the next 18 weeks.  They do have a few  TLE-5206-2 still in stock, probably because it is a less useful part, not having the Hi-Z output state. I must have checked that part instead of the TLE-5205-2.  Probably no other distributor has any TLE-5205-2’s either, if Infineon has been unable to make any since last September.

I didn’t know that Digi-Key had customer service reps working at 8p.m. on a Saturday night—it is good to know that a supplier cares enough to keep engineer hours.

In any event, I’m going to have to completely redesign the board. The TLE-5205 is unavailable even in the surface mount packages, so I can’t just change packages.  I’ll have to find and use a different H-bridge, which will be a major pain, as the TLE-5205 came close to being ideal for this application. I suspect that since the 5206 is still available, that the problem might be with the freewheeling diodes.  Since the 5206 always has either the high-side or low-side on, it doesn’t need Schottky freewheeling diodes.  Unfortunately, most of the other H-bridges I’ve looked at expect external diodes—the TLE-5205 was attractive because it had built-in diodes, saving a lot of board space.

Create a free website or blog at WordPress.com.