(50$ robot) Servo modification and AVR programmer questions

[ribs]

Well!  I have to say uploading the "hold_servo" program (to zero out the servos), and then plugging the servos into the board and having them actually snap themselves to 0 was pretty darn exciting for a strictly computer guy like me!  Very cool.  But it didn't actually work as cleanly as I had hoped.  I had a few questions:

1) When I tried to program the atmega8 with AVR Studio (edit: I bought the more expensive ISP2 programmer), it failed, but the message log read something like: connecting - successful, writing flash - successful, reading flash - FAIL, disconnecting - FAIL.  Should I take this to mean that it successfully programmed the microcontroller but failed to verify it?  Or should I take this to mean that it failed altogether?  When I plugged the servos in they did zero themselves out, but for all I know, they would have zeroed themselves out anyways if the microcontroller was "dead" (if the control pins are unset, that means they are low, which means it is telling it to go to zero?  Or is that untrue?).

2) In any case, what should I look at for why the programming was busted (i.e. if  just the read was failing, why would that be the case - is one of my pins not soldered correctly?  But I tested the connections with the multimeter...)

3) AVR Studio can write to "Flash" or "EEPROM".  I tried both, but it said there wasn't enough space on the EEPROM so I am just assuming that I was supposed to write the hex file to Flash memory.  What's the difference between the two?  ...or did I miss something when I RTFM

4) While modifying the servos, I successfully zeroed out the pot head so the servo stopped spinning while it was plugged in, but in both cases, while the superglue was drying to lock the pot head in place the servo started moving (very slowly) again.  So both of my pot heads are locked at not-quite-zero.  How do you guys usually do this just right?  Or do you decide by trial and error what the pot head thinks it's at and code the error into your program (so that "0" is really "3" or whatever?).  I suppose that if my program had completely failed to upload that I could have possibly been trying to lock my servo to a moving target...

5) On my Hitec 311s, the slot in the main gear that was turning the pot (the one that you say to remove in step 7 of this page was not actually on a separate piece that I could pull out of the main gear.  It was all one solid piece, so I had to dremel out a big hole so the pot head could freely move around in there...  No big deal, but FYI.  Unless I completely misread the instructions.


Thanks,

--
Ken

[rgcustodio]

1) When I tried to program the atmega8 with AVR Studio (edit: I bought the more expensive ISP2 programmer), it failed, but the message log read something like: connecting - successful, writing flash - successful, reading flash - FAIL, disconnecting - FAIL.  Should I take this to mean that it successfully programmed the microcontroller but failed to verify it?  Or should I take this to mean that it failed altogether?  When I plugged the servos in they did zero themselves out, but for all I know, they would have zeroed themselves out anyways if the microcontroller was "dead" (if the control pins are unset, that means they are low, which means it is telling it to go to zero?  Or is that untrue?).

Most probably the programming failed altogether.

The servos zeroing out is not a good indicator that the device programming was successful.

2) In any case, what should I look at for why the programming was busted (i.e. if  just the read was failing, why would that be the case - is one of my pins not soldered correctly?  But I tested the connections with the multimeter...)

Maybe your programming settings are incorrect. Verify that the speed is 1/4 that of the oscillator speed. Verify that you have selected the correct part (ie ATmega8 for this project) this is at the top left corner of the window.

One thing to test is to "view" the fuse bits and lock bits tab. If you properly see the correct settings then you are connecting properly. Remember "view" only don't touch anything yet. Search the forums for some information regarding the fuse and lock bits.

3) AVR Studio can write to "Flash" or "EEPROM".  I tried both, but it said there wasn't enough space on the EEPROM so I am just assuming that I was supposed to write the hex file to Flash memory.  What's the difference between the two?  ...or did I miss something when I RTFM

You only need to write the hex file to Flash. Writing to EEPROM is a no-no unless you know what you are doing.

Both are non-volatile memory. EEPROM is smaller than Flash most of the times, When you Flash the device you can leave the EEPROM untouched thus it is a good placeholder for various settings. To access the EEPROM properly you need to modify your code and add certain commands.

[ribs]

Most probably the programming failed altogether.
The servos zeroing out is not a good indicator that the device programming was successful.
...
Maybe your programming settings are incorrect. Verify that the speed is 1/4 that of the oscillator speed. Verify that you have selected the correct part (ie ATmega8 for this project) this is at the top left corner of the window.

When I tried to program it, I did get a little status bar that steadily went across the screen, after which I got "programming flash: successful.  When it tried to read Flash I didn't get a status bar before "FAIL".

In any case, I started putting random numbers into the ISP speed and eventually got it to successfully write.  I assume by oscillator speed you mean clock speed, which is 8Mhz for the atmega8, correct, so 2Mhz for the ISP speed should have worked?  It didn't, and in fact complained about a short in the system, which I am fairly sure that I don't have.  Then I tried 1Mhz and it complained about something else.  I think 100Khz or 20Khz ended up working correctly through the whole thing (programming, reading, etc. all successful), but the whole thing is kind of sketching me out.  I expected it to work or not work, instead of black magic   BTW, the ISP speed that it was originally set to last night before I posted my question was defaulted to 1.02xx Khz (very, very slow).  I don't know where it picked that number from.  Is that an indication that something is wrong in my system?  Why would 1Khz fail but 100Khz succeed?

--
Ken

[rgcustodio]

When I tried to program it, I did get a little status bar that steadily went across the screen, after which I got "programming flash: successful.  When it tried to read Flash I didn't get a status bar before "FAIL".

Hmmn. Try to check the value of the pull up resistor in your RESET line if you have one. Check the data sheets for the allowable values of this resistor. This bit me last week.

In any case, I started putting random numbers into the ISP speed and eventually got it to successfully write.  I assume by oscillator speed you mean clock speed, which is 8Mhz for the atmega8, correct, so 2Mhz for the ISP speed should have worked?  It didn't, and in fact complained about a short in the system, which I am fairly sure that I don't have.  Then I tried 1Mhz and it complained about something else.  I think 100Khz or 20Khz ended up working correctly through the whole thing (programming, reading, etc. all successful), but the whole thing is kind of sketching me out.  I expected it to work or not work, instead of black magic   BTW, the ISP speed that it was originally set to last night before I posted my question was defaulted to 1.02xx Khz (very, very slow).  I don't know where it picked that number from.  Is that an indication that something is wrong in my system?  Why would 1Khz fail but 100Khz succeed?

Yup oscillator is the clock speed.
AVRStudio complained about a "short in the system"? Did I read that correctly?

Check your fuse bits, is a clock divisor enabled? If it is, it divides the value of the oscillator by 8. So if you have set the oscillator at 8MHz and the clock divisor is programmed, you are in fact running at 1MHz!

BTW, were you able to verify that you are indeed using the correct part/device in AVRStudio?

I don't have my development system right now, but I did use 2MHz successfully in past projects. So 2MHz should work if all your settings are correct. Lately I changed my ISP speed to 500kHz... something.

[ribs]

Hmmn. Try to check the value of the pull up resistor in your RESET line if you have one. Check the data sheets for the allowable values of this resistor. This bit me last week.

I don't have one (and don't know what that is).  Ok, I did some research on google, and it looks like it is there to pin a voltage high if it is otherwise unset.  So in the schematic I would connect one end of a resistor to the brown pin (RESET on the microcontroller) and the other end to my 5V bus?  I checked the datasheet here to find out more and am confused.  Fig. 14 on page 38 seems to indicate that there is an internal pull-up resistor inside the chip already.  But page 5 specifically says PB7-PB0 and PC5-PC0 have internal pull-up resistors but says nothing about PC6/RESET, which would indicate to me that it does not have an internal pull-up resistor.  And then (and excuse me again for being obtuse - these datasheets are like greek to me): on page 242, the DC Characteristics table says something about the Reset Pull-up resistor having a min of 30kOhm and a max of 80kOhm, but I can't tell if they mean that I should put in a 30k-80k pull-up resistor or if they are telling me that there is one inside the chip already and that it is somewhere between 30k and 80k ohm.

Yup oscillator is the clock speed.
AVRStudio complained about a "short in the system"? Did I read that correctly?

Yes.  It complained about a short once out of maybe 6 or 7 failures, only at 2MHz ISP speed.  I am almost positive I don't have a short - I was pretty anal about testing with the multimeter.

Check your fuse bits, is a clock divisor enabled? If it is, it divides the value of the oscillator by 8. So if you have set the oscillator at 8MHz and the clock divisor is programmed, you are in fact running at 1MHz!

I'll check when I get home tonight.  I haven't looked at any fuse bits, or know what they are yet.  More user manual reading for me   Will setting the clock divisor only affect programming speed, or does it affect the speed of the chip as it is running the program?

BTW, were you able to verify that you are indeed using the correct part/device in AVRStudio?

Yep, I've been doing that correctly.

Thanks, again,

--
Ken

[rgcustodio]

I don't have one (and don't know what that is).  Ok, I did some research on google, and it looks like it is there to pin a voltage high if it is otherwise unset.  So in the schematic I would connect one end of a resistor to the brown pin (RESET on the microcontroller) and the other end to my 5V bus?  I checked the datasheet here to find out more and am confused.  Fig. 14 on page 38 seems to indicate that there is an internal pull-up resistor inside the chip already.  But page 5 specifically says PB7-PB0 and PC5-PC0 have internal pull-up resistors but says nothing about PC6/RESET, which would indicate to me that it does not have an internal pull-up resistor.  And then (and excuse me again for being obtuse - these datasheets are like greek to me): on page 242, the DC Characteristics table says something about the Reset Pull-up resistor having a min of 30kOhm and a max of 80kOhm, but I can't tell if they mean that I should put in a 30k-80k pull-up resistor or if they are telling me that there is one inside the chip already and that it is somewhere between 30k and 80k ohm.

Me and my big mouth.... sorry disregard my babling. You can actually use the RESET pin without a pull-up. Sorry for the confusion.

When it comes to the RESET pin I always refer to the DC Characteristics table, the one near the end of the document. The internal pull up of RESET is not used unless you specifically program a fuse bit to set the RESET pin as an I/O pin.

Will setting the clock divisor only affect programming speed, or does it affect the speed of the chip as it is running the program?

I am sure that this setting affects the speed of the MCU when running your program, but I am unsure of its effects when performing SPI programming. BTW, don't bother checking the clock divisor, I just reviewed my notes and the ATmega8 does not have this fuse bit. You are using an ATmega8, no?

[ribs]

Yep, using Atmega8.

So I got rid of the hold_servo program and brought in the photovore program instead, and commented out all the sensor logic (haven't hooked up the photoresistors yet) and uncommented the test code (and modified it a little) so it would rotate the two servos in opposite directions, and flop directions every few seconds.  Again, 2MHz ISP speed failed, 1MHz failed, but at 250kHz it went right through and programmed and verified in <1 second, and immediately started driving the servos back and forth. 

I started playing with the servo speeds and it looks like the control I have is very, very coarse.  e.g. telling the servo to go at speed "35" is almost motionless, but not quite, but speed "36" is quite fast already.  I looked at the code that actually sends the signals and it looks like the number I'm sending is simply the number of cycles it waits after it turns the signal high till when it turns if off again, so I'm not sure how I get finer resolution than that.  i.e. how do I tell my servo to go at the speed "35.125" or whatever?  How do I get finer resolution control over how long a pulse I send to the servo?


I am pretty excited though - this is the first thing I've "made" that isn't just data on a hard drive somewhere!  The only thing that doesn't work at all is the LED status light!  I can't get it to turn on no matter what I send to port 4 (where the LED is plugged into).  I got it to light up once by measuring the voltage drop between ground and VCC (I think)  with my multimeter, I think, but it doesn't seem to turn on normally.

[rgcustodio]

250kHz it went right through and programmed and verified in <1 second, and immediately started driving the servos back and forth.

The good thing is that it works! Compared to other programmers that is already fast.

I looked at the code that actually sends the signals and it looks like the number I'm sending is simply the number of cycles it waits after it turns the signal high till when it turns if off again, so I'm not sure how I get finer resolution than that.  i.e. how do I tell my servo to go at the speed "35.125" or whatever?  How do I get finer resolution control over how long a pulse I send to the servo?

Servos normally have a specific speed and you can't actually tell a servo to speed up. This fact has been mentioned in other threads ie number of seconds to rotate 60 degrees.  We can't do anything about that, unless you change the gearing of the servo or applying more voltage to the servo. Most servos work with 4.8V up to 6V. Never go over the max rated voltage for a servo.

The length of the pulse is decoded by in on-board servo controller and this determines the direction of the rotation of the horn/arm/hub/or whatever is connected to the servo. This is Pulse Code Modulation. For an unmodified servo, ending a pulse of 1500uS centers the servo to its neutral position. Sending a value less than 1500uS the servo move and holds it position at a certain angle counterclockwise of the neutral angle. The opposite occurs when you send a pulse wider than 1500uS. Most servos expect to receive a pulse every 20ms, if it doesn't receive any it holds it's current position.

I haven't gleaned over the Photovore code long enough to fully understand it.

Lookie here:
http://www.uoguelph.ca/~antoon/hobby/servo1.htm
I think its a very good introduction, not only on the electronics of a servo but on other aspects as well.

The only thing that doesn't work at all is the LED status light!  I can't get it to turn on no matter what I send to port 4 (where the LED is plugged into).  I got it to light up once by measuring the voltage drop between ground and VCC (I think)  with my multimeter, I think, but it doesn't seem to turn on normally.

LEDs are polarized. Maybe you forgot to wire it correctly? One of its legs is slightly longer the other, this is the leg that needs to be connected to VCC.

[ribs]

The good thing is that it works!

I know!  I can't tell you how exciting that is   It's like getting "helloworld.c" to compile and run for the very first time.  Geektastic!

I
Servos normally have a specific speed and you can't actually tell a servo to speed up.
...
The length of the pulse is decoded by in on-board servo controller and this determines the direction of the rotation of the horn/arm/hub/or whatever is connected to the servo. This is Pulse Code Modulation. For an unmodified servo, ending a pulse of 1500uS centers the servo to its neutral position.
...
http://www.uoguelph.ca/~antoon/hobby/servo1.htm

Thanks for the link.  I had no idea how that worked.  I'm not at home so I can't check the code, but if I remember right the comments said something like "23 delay cycles is about .992 milliseconds" so it makes sense that my turning on the port and delaying for 35 cycles (about
1.51 milliseconds) before turning it off would roughly stop the servo.  Still, it seems like I can get more accurate than doing this pulse timing by "delay cycles", whatever those are, which are ~43uS, when the processor is running at 8MHz (which is a cycle every .125uS, if my math is right.  There must be some timing method that I'm overlooking.

As for the (lack of) speed control, that makes sense.  When I was read the servo modification tutorial though at the bottom it says "You will notice that by telling the servo to go to a particular angle, instead it will rotate at a particular speed.", but maybe he just means directional control.  I noticed that when the servo was intact (main gear was driving the pot) that the rotational speed would not noticably decrease when the servo began to approach its target (e.g. it was not turning 15 times slower when it was only 2 degrees away from 0 than when it was 30 degrees away), so I suppose I should not have expected to gain direct speed control.

[rgcustodio]

I'm not at home so I can't check the code, but if I remember right the comments said something like "23 delay cycles is about .992 milliseconds" so it makes sense that my turning on the port and delaying for 35 cycles (about 1.51 milliseconds) before turning it off would roughly stop the servo.

For a continuous rotation servo (cont rot servo), turning off the port doesn't stop the servo because there is no potentiometer inside the servo it doesn't know that it has reached or exceeded a certain angle. The potentiometer is used by the servo circuitry as a feedback mechanism.

This is where

Most servos expect to receive a pulse every 20ms, if it doesn't receive any it holds it's current position.

comes in. The above statement is only true for unmodified servos (ie not the continuous rotation variety like the one in the $50 Robot). For a cont rot servo, this just means it continues what it is doing, provided at the 20th ms, the same pulse length is received.

though at the bottom it says "You will notice that by telling the servo to go to a particular angle, instead it will rotate at a particular speed.", but maybe he just means directional control.

Hmmnn... need to check the code.