Author
Topic: $50 robot servo drift (Read 1589 times)

Doing the $50 robot as my first ever. (Great tutorial, btw, though it needs a number of tweaks.) Got the chassis mostly built, circuit board done and tested, servos modified, and now I'm working on the servo control in the software, before I build the sensors and put everything together. I'm using the PocketProgrammer from Sparkfun, which has been great so far, and the Atmega8 microcontroller. But I have one problem:

Physical modification of the servos (HS-311, as in the tutorial) was imperfect; I didn't hit the center position on the pots exactly, apparently. So in software, I figured out through some trial and error that using a delay of 49 for one servo stops it from moving (and going above and below that value make it rotate clockwise and ccw, respectively). But for the other servo, I can't get it to stop, entirely. 37 moves it ccw slowly, while 38 moves it cw.

I'm no C expert--can I change the delay value to something other than an integer, like 37.5? Or is there something else I can do in software to fix this problem? Or is there a hardware fix?

I think your best bet would be to try to fix the hardware, rather than trying to mess with it in software. However, it IS possible to get more accurate delay functions. Just look in the ".h" files included with the software you downloaded, you'll see the function for the delay in one of them. From there you can change it around to fit your needs.

I don't think further hardware adjustment will be possible; I superglued the pots in their current position, as per the tutorial.

Can you expand on how to get more accurate delay functions? I tried changing the data type from int to float, but without changing anything else, that made both servos go crazy with jitter. Changed them back to int, and they behaved again, except for the original drift problem.

But thinking about this further, it doesn't seem like I could get any finer delay control anyway, since the resolution of the pulse duration is limited by the length of one cycle. The delay function sets the (integer) number of cycles. Or do I misunderstand something?

Hmmm... I thought his delay functions were built like mine. I can get finer control over my delays, but it seems like you are right, that the length of one cycle is the limit. Maybe someone else will chime in.

Thank you for the tip, Razor Concepts. You're talking about the UART upgrade tutorial (except only doing the clock adjustment part, of course), right? I've been attempting to do that, but when I get to the part where I'm supposed to connect with the microcontroller and AVRstudio is supposed to pop up the programming window, it won't connect.

I can program from the command line with no problems, but it looks like AVR Studio is not compatible with the sparkfun pocket programmer. Is there something I can do to add the pocket programmer to the list (or maybe fool AVR Studio into thinking it's a different programmer?)?

So it looks like it's a compatibility issue, but I tried going with the AVRISP options anyway. It didn't work, but while exploring the help files I ran into another problem. The troubleshooting guide says the AVRISP needs to run off of the target board's power; the pocket programmer can take power from my computer, which is what I've been doing so far. But I thought I'd give that a try, so I hooked up my 9V, checked the power levels (4.94 V coming off the regulator), and flipped the switch on the pocket programmer from "power target" to "no power". Still no success in connecting, but instead it raised another puzzle--when I had the board running off the 9V, and also turned on the 4 AA batteries for the servos, nothing happened. The servos don't budge. But when I unplug the 9V and power the board from the computer again, the servos behave as programmed, even though VCC still measures 4.99V. Does .05V really make a difference?

So now I have two questions:1) How can I connect to the Atmega8 through my pocket programmer to change the clock speed?...so that I can, in turn, fine-tune my servo commands to get both servos to stop.2) Why don't the servos respond when the microcontroller is powered by the 9V, but do respond when it's powered by the computer at the same voltage?

This makes every other pulse 38 cycles long, rotating the servo in the opposite direction from the 37-cycle pulses. Although the wheel still had net rotation, it was very slight. But, unsurprisingly, it was jittery. I tried dividing by 3 instead of 2 in the above code, so that 2 out of every 3 pulses were 37 cycles long, and that seemed to eliminate the net rotation and reduce the jitter. I could probably do it this way in a pinch, but I'd much rather save the wear on the servo and the vibration to the chassis by actually stopping the servo with a (presumably) 298-cycle pulse off an 8MHz clock.

Problem solved! I surfed around and found out how to do it from the command line. Then, after fixing some bugs and recalibrating the servos' zero-points, I finally have full control of both servos. (Including with the 9V--still not sure what was going on there, but it works now.)