I've begun work on the drive system. I'm initially prototyping the motor drive and optical rotation feedback. These are core features with which I have little experience so I'm mocking these up to verify that things work. A good thing too since I initially hooked the p-channel mosfets up backwards. No smoke fortunately.
H-Bridge Motor Drive
I'm using Pololu gear head motors (although continuous rotation servos will also be supported). In order to drive the motors in either direction I'm using H-bridges. This circuit gets it's name from its distinctive shape. It consists of four switches arranged in an H as seen below. The load occupies the bridge of the H. When opposing upper and lower switches as closed, current flows through the load. The direction of the current, and the direction the motor rotates, can be controlled by which pair of switches you close.
I've built a prototype of the H-bridge in order to ensure that it works as planned. In my case, the upper switches are p-channel mosfets and the lower switches are n-channel mosfets. These mosfets are rated in excess of 4A and 30V. The Pololu motors have a stall current of 1.6A and should pose no challenge.
Mosfets have three terminals; gate, source and drain. For n-channel mosfets, when the gate and source are at the same voltage, the resistance between the drain and the source will be very high; effectively the open switch. As the gate voltage (Vgs) rises there comes a point where the drain-source resistance (Rds) begins to drop very rapidly. When the gate voltage is sufficiently high, the drain-source resistance will be very small, often in the milli-ohms. For many mosfets the gate voltage needs to be quite high, perhaps 10 to 12V above the the source voltage to reach this very low resistance state. There are, however, logic level mosfets that can achieve this state when Vgs is only 2.5V (I am using 3.3V).
A similar situation exists for p-channel mosfets. When Vgs is zero (the gate voltage is high), the source-drain resistance is high. To get the mosfet to conduct, you lower the gate voltage. As Vgs passes -2.5V, the mosfet reaches the low source-drain resistance region.
The circuit above reflects what I'm using for my robot. You'll notice a few extra elements. First, I have pull-up resistors on the p-channel gates, and pull-down resistors on the n-channel gates. This is first of all a precaution for when the circuit powers up. In the absence of control signals, I want the gates to be shut.
The pull-up resistors on the p-channel gates serve a second function. My microcontroller and all associated hardware runs at 3.3V. The motors run at 6V. Without some level translation I cannot set the p-channel gates to 6V in order to turn the mosfets off. To get around this, I pull the gate high to 6V. I then use a second n-channel mosfet that I can control using 3.3V to pull the p-channel gate low when I want to turn the upper switch on.
The logic gates attached to the circuit allow me to control the H-bridge using only two control lines. One is direction and the other is PWM. The direction line controls which upper p-channel mosfet is turned on. Using the PWM line I turn on and off the complimentary lower n-channel mosfet. Using PWM allows me to control the speed of the motor. The inherent logic ensures that I cannot turn on both the mosfets on one side of the H-bridge. Doing so results in shoot-through (a short circuit) that will surely release the magic smoke in the mosfets.
Once I flipped the p-channel mosfets around (sigh) the circuit performs very well at a PWM frequency of 20KHz. Lower frequencies work as well but the motor produces progressively larger back-EMF spikes as the frequency drops. I've run the Pololu motors aggressively with a heavy load but the mosfets don't even get warm. In the picture you can see the diminuitive NAND and AND logic packages. Barely larger than the SOT-23 mosfets themselves.
Not shown in the schematic but very important nonetheless (visible on the board by the voltage regulator) is a sizeable capacitor (minimum of 100uF) between the 6V rail and ground. I'm thinking that 330uF would be a good value if I can find a small enough package.
I'd originally planned on using the dsPIC33FJ128GP804 pic chip but now I'll be using the dsPIC33FJ64MC804 of which I have a few in stock. The MC variant includes dual built in quadrature encoders that are just what I need to turn pulses from optical sensors into direction and distance.
The sensor I chose is the OP609 Reflective Object Sensor from OPTEK Technology. It integrates both an IR LED and a matching phototransistor into the same package. In the image you can see the sensor mounted ready for testing. There's a 220 ohm current limiting resistor (~7mA at 3.3V) on the left and a 47Kohm sensing resistor on the right. Since the camera is sensitive to IR you can see the LED glowing blue.
The sensor needs to be very close to the sensing pattern for this to work. A separation of 0.05 to 0.1 inches works well. To test the sensor I laser printed a circular pattern with alternating 5 degree black and white wedges.
The 220 ohm current limiting resistor is probably too large. A target of 20mA current should be better. Also, the sensing resistor shown here is too large. There is a leakage current of about 31uA which drops 1.46V across the 47K resistor. A 10K resistor works much better with the sense voltage swinging from 2.56V to 160mV. I'll be using a schmidt trigger to clean up the analogue signals and these voltages are nicely compatible.
The main drive motors can be gear head motors driven by the H-bridge using the DIR and PWM control lines. The main drive motors can also be continuous rotation servos instead. Then the DIR line will be used to create the requisite servo pulse train. We can take the signal at the p-channel mosfet gate and use this as the servo control line. The software will be able to probe the type of motor present by trying each control scheme and seeing which produces motion.
I'll add additional n-channel mosfets coupled to pull-up resistors to allow controlling a few extra servo motors.
I2C Control Bus
I2C, once you get it working, is a great way to add additional peripherals to a device without sacrificing additional control lines. These are always scarce enough as it is. Currently, the only device that will attach to the I2C bus is an LCD display. This, coupled with a few buttons, will allow us to select functions and view results without having to couple the robot to an external PC. This will be important during calibration, and developing the AI.
The Blueprint (Feb 27, 2012)
The plan shown above is what has materialized as I laid out the PCB for this project. As with all 'good' plans, the scope and mission have expanded to fill all available I/O (shakes head).
The power comes from three Li Ion batteries which will provide 11.1V nominal at in excess of 2000mAH. This will be converted to 6V via a switching regulator to drive the motors. The 6V will be regulated at 3.3V to drive everything else.
The main motors will be 6V gear head motors (continuous rotation servos will be supported by leaving part of the PCB unpopulated). Quadrature encoded optical sensors will monitor rotation of the wheels so the robot can do proper dead reckoning.
Pulse trains to drive two additional servos are provided for future expansion.
I/O is accomplished via an I2C LCD display and four buttons for navigating menus.
The robot uses 3 types of sensors. Standard LED/Phototransistor pairs for close range sensing. A Sharp long range sensor for more distant objects, and a 38KHz sensitive sensor for detecting beacons (a poor man's GPS). While the main board has spots for 4 LED/Phototransistor pairs, an expansion board can be used to expand this to 16.
Finally, the I2C bus is exposed so that future expansions can communicate with the main CPU.
I've laid out the PCB for the project but it is no longer a DIY toner transfer project. I've sent the Gerber files to Gold Phoenix PCB in China and I should get the boards within 8 working days. I will start programming in the meantime. The board is ~2.5" by 4" and double sided. The pads for the Microcontroller can accommodate either a 44 pin TQFP chip, or the legless 44 pin QFN. I designed for the TQFP because they're easier to solder but I have some QFN's in stock and will use these initially. Very exciting.
The main board is competely assembled. You can see two green jumper wires where I forgot to route two lines. Doh! Nonetheless, I was able to connect these up to two pins that are normally used for programming. Fortunately, these can also be used as general purpose I/O lines.
I have the PWM control of the two motors working. As well, I have the I2C up and running and can write to the NewHaven I2C LCD display. Buttons work, and next comes the Quadrature encoders (QEI) that you can see on the four upright PCBs flanking the two motors. Initial tests show that the encoder disks will need to be within one mm of the encoders. This will require some careful wheel construction but otherwise they work as expected.
Attached to the front of the main board you can see the sensor board. This still needs to be populated. I still have to get the A/D up and running for it, the battery monitor and the Sharp sensor. Once I have the QEI working I'll focus on that.
Next Section: See The Fitzy and Carraldo project for further details