Beaglebone: To the Batcave! Wiring up a CAPE

Previous Post: accessing GPIO off the PRU

6/22/17:  Last summer, I did fry my first beaglebone.  Then, remoteproc arose.  I’m almost back to cape-wiring after that learning curve.

2/10/16: After many stops and starts, a couple of redesigns, some burned out circuits, and some wiring, the cape is finished.  I have to wire a harness for the motors and the i2c and then test them.  However, unless these system tests reveal something that I missed (again!), I’ll be posting the “how to make a cape” pretty soon.

1/24/16: It’s been a while since I posted to this thread.  My previous post accurately predicted that this was going to be slow going.  Anyway, I’m almost at the point of completing the wiring of the cape.  I’ve been through many loops.

I’ve completed wiring and testing the bumper switches.  I haven’t posted the cape wiring yet, but it’s done.

I’ve completed wiring and testing the encoders.  This became a challenge, since the 5v off the beaglebone didn’t source enough current to power the encoder modules reliably. I had to detour into an external battery powered regulator, which led me into 3D printing mounting parts to protect the regulator from shocks and jars. The encoder was 5v logic, and I needed to  drop that down to 3.3v for the digital inputs on the beaglebone.  This took me to the world of level adjuster circuits.  I went through many iterations before finding one that did exactly what I wanted.  I was going to have to do these steps anyway, but I put them ahead of the cape.  I’ll put a separate post on that subject when I’ve finished that project.

I’ve redesigned around a pololu motor control circuit.  Although my motor control circuit was adequate, the pololu costs about the same and has many features that make it more desirable.  I’ve tested the beaglebone with the pololu and turned a motor.  Now, I need to modify the cape to include this wiring.  That’s the last hold-up on this part of the project, and it should be done next weekend.

I’ve moved away from the analog yaw rate sensor that was on the old CASSY.  I’m going to try an adafruit 9dof sensor.  This sensor speaks i2c.  I’ve wired the cape to pull out i2c1 from the beaglebone, and I’ve modified my 3D printed mounting boards to mount the sensor close to the robot’s CoM.  I should be a cable and some programming away from reading that sensor.

My final parlour trick will be to daisy chain a flora color sensor from adafruit with the 9dof sensor through i2c.

Eventually, I’ll still have to figure out the adc so that the inverted pendulum potentiometer can be included.  However, that will be well into the future before I worry about that.

———

I’m waiting for parts to come in.  When they do, I’ll get the circuit diagrams up and take some pictures showing a motor turning.

If you’ve been avidly following this blog, you can probably guess that it’s going to be a while to get such a substantial piece of work completed and documented.

So, rather than waiting for a month, I’m going to move forward to implement the encoder interface (see Next Post below).

The Vex 393 motor has a stall current of 5 amps and a continuous current of 3 amps.  This makes it a good fit to work with the Freescale MC33926 chip.  Pololu sells a motor driver that uses this chip (Item 1213).  This might be a better option than using the L293 or other lower current PWM driver.

If all motors are operating near stall at the same time, that’s 4 * 5 amps * 7.2v = 140W for a little robot.  If you use 6 1.2v, 2.4 A-h batteries, they’ll be drained in  8 minutes of continuous operation.  Realistically, the robot shouldn’t be pushed to this extreme, but the system design should be ready to operate under these conditions if you’re going to invest the resources to beef up one part of the system. In other words, it might be a good idea to put two battery packs in parallel to extend life.

———–

Things I learned early on but which I abandoned …

A 7408 quad AND chip will take the single PWM signal and a direction signal to create two PWM signals for the h-bridge. A CD7404 hex inverter is also needed to convert the direction signal into its inverse.  If these chips are powered by 5v, the 3.3v input signal from the Beaglebone will work just fine.

In order to increase current to the motor, multiple h-bridges can be wired in parallel.  The L293 supplies 1 amp continuous.  In order to use this with the Vex 393 motor, which has a stall current of nearly 5 amps, at least 4 h-bridges need to be wired in parallel.  This means, two L293 chips per motor, for a total of 8 chips for the system.

I tried a Vishay ILQ2 optoisolator to interface between the Beaglebone and the h-bridge circuit.  The ‘2’ in the ILQ2 means that the part has a 5 ma forward current to turn on the LED.  A quick calculation reveals that a 540 ohm resistor in line with the digital outs will gives the desired current.  The ‘Q’ in the package stands for quad.  The data sheet recommends a 75 ohm resistor on the ILQ2’s output.  This gives a 60 ma current limit from the 5v source.  That’s probably much higher than needed, so a larger resistance might be in order.  The ILQ2 comes in a surface mount package and a DIP package, so it can be incorporated into a cape or breadboard.

As it turns out, opto-isolation is unnecessary on the outputs.  The advantages being ground plane isolation and level shifting.  The former task is unnecessary and the latter task can be accomplished with much less current consumption.  So, I abandoned the ILQ2.

I used a Texas Instruments SN754410 quad half-h-bridge circuit for the motor drive section in another application and intended to reuse it here.  These bridges will be driven by the 5V logic level out of the optoisolator and will switch a 7.2v battery.  It might be a good idea (for control purposes) to set up a regulator on the 7.2 v battery.  This way, battery fluctuations won’t affect robot performance.  But, for now, we’re going with raw battery.

I shifted from this chip to the L293 chip.  They had mostly the same statistics, but the 293 had a surface mount version.

Next Post: Beaglebone: A novel encoder interface for measuring speed

Posted in: Robotics

Comments are closed.