Here’s my Ground-Bot (GBOT) tracker with P-control versus PID-control using ZX-40A microcontroller from zbasic.net. ZX-40A based on ATMEGA644 AVR chip. Inputs include 2 IR range sensors (GP2D12). Outputs include 2 PWM signals to the Pololu motor driver (VNH2SP30).
The GBOT maintains a setpoint distance of 10-inches from a target and maintains that distance, no matter what. The control system was originally programmed with P-control only, but the GBOT tended to overshoot the setpoint and oscillate. So I added PID control. The video shows that the PID subdues the unwanted responses. See video & picture.
Cool, that looks like a fun robot! How did you make the chassis? I’d enjoy seeing a video where you lift up the box and let the robot run towards a wall or a cat or something fragile.
The outer shell is my wife’s old DVD player (she doesn’t recognize it). The venting holes made it easy to attach the inner frames and standoffs. Those are stock material from a local hardware store. I sawed and drilled them to fit.
If I lift the tracking object, the GBOT will keeping going until it tracks something else. Usually the wall baseboard. It simply maintains a 10-inch gap.
Cool, thanks for sharing. Is that mark on the box a burn mark from a soldering iron? (I hope it’s not from the motor driver!)
I did have some trouble with the independent battery that supplied the microcontroller. The jumper wires litterally bubbled, smoked, and burned off the wire insulation. See picture below.
zbasic.net/forum/download-32 … pc_t=74446
I only fried the wires between the battery and voltage-regulator VIN. My theory is that a simple short ocurred somewhere along that wire train. That battery only powers the ZX-40A microcontroller, 1 LED, 2 IR range sensors, 2 PWM signals to the motor driver, and the +5V (IN) to the motor driver. I can not imagine this drew enough power to fry the battery wires. The motors themselves are powered by a separate 7.2V NiCad pack. My other theory is that the motor driver +5V (IN) drew to much power, but that’s unlikely, right? It would be nice if the VNH2SP30 used regulated 5V from its own VIN (+) pin to completely isolate the motor driver from the microcontroller (aside from the PWM signals). Appreciate the comments.
Your short theory sounds accurate. Did this bubbling happen when you were changing the wiring? When did it happen?
The bubbling did not happen while changing the wiring. The incident happened when I programmed unstable gains in the PID controller. As a consequence, the GBOT moved wildly back and forth trying to maintain the tracking setpoint - this must have really worked the motor driver. The wild oscillations stopped and I noticed dense smoke rising then saw the wires bubble. That’s why I suspected the motor driver. The specs say that the +5V (IN) is a low power input, so I attributed the incident to a short. None of this is proven.
Since the incident, I started with a new voltage regulator and moved it to its own circuit board with a massive heat sink and two 1,000uF filters for VIN and VOUT. So far, no fried wires. But then again, I have not attempted the unstable PID gains (I dare not to). The following thread explains the incident in more detail. Thanks for you comments.
zbasic.net/forum/about1258-0 … 5&pc_t=540
Is it possible that the wild gyrations caused two exposed wires to touch?
The battery wires to the breadboard are short and don’t weigh much. They don’t quite respond to wild gyrations. The Tamiya motors are powerful and responsive, but not responsive enough to cause exposure of wires and contact. I don’t have concrete evidence, but I think the “incident” was caused by something between the microcontroller battery and the voltage-regulator input. Overall, I think the VNH2SP30 motor driver is an excellent product. It’d be even better if the driver powered the +5V (IN) low power pin. Its probably not worth the higher product price. Thanks for your comments.
Anyone have experience or information on GP2D12 IR sensor distance variabiability? I have the noise reduced to 0.025" amplitude. Can this be reduced further? Thanks.
0.025" sounds really good to me; are you sure you didn’t mean 1/4"? That’s closer to what I would expect. If you are really getting 0.025", how are you measuring that?
I did mean 0.025" (or 25/1000 of an inch). I simply placed an object 10 inches from the GBOT, killed power to the motor, and plotted IR sensor distance vs. time. See enclosed figure. Adding a digital filter improves the noise to approximately 0.025" amplitude. Notice the 1Hz oscillation. Is this response reasonable for this type of sensor (GP2D12)?
If you are using a filter to process your data, you can’t call 0.025" a characteristic of the sensor, right? If you average for a long enough time with the robot off, you can average the statistical noise down to an arbitrarily small value. There is always a trade-off between the averaging timescale and the noise level, so it would be more interesting to ask how good your measurements are if you average over, say, 0.2s. Also, even if you average the measurement down to 0.025", there will be a much larger absolute, systematic error - how much the number is off by relative to the actual distance measured by a ruler.
By the way, you can try adding a capacitor on the power supply lines close to the sensor to cut the noise down somewhat.
The GP2D12 as a system is showing 0.025" amplitude noise. The system includes low-ESR capacitors (1000uF) on VIN of the voltage regulator, another on VOUT, more for each IR sensor, and an 8th order digital filter on the raw sensor signal. The sensor by itself, with no capacitors, no digital filters, exhibits noise in the order of 0.3" amplitude. This is damaging to my motors and motor controller (heat!). The low-ESR capacitors make a huge difference, but not adequate by themselves. By the way, the previous plots show the effect without the digital filter (see magenta curves), but with the capacitors.
My ZX-40A microcontroller loops at roughly 150Hz, so as long as my program is faster than 25Hz (IR sensor sample rate), the 8th order filter does not interfere with the control system. I can increase the filter order, however I’m saving the throughput for extra code for the GBOT90. This project involves rotating the GBOT 90 degrees to have it balance on its two front wheels. So mitigating sensor noise is central. GP2D12 sensor variability has not been documented, so I thought I’d query the field. Thanks for your comments.
I am from Turkey and i want to ask something about PID control with microprocessors. Can you give some example codes about applying PID to microprocessor ?