Society of Robots - Robot Forum
Electronics => Electronics => Topic started by: pomprocker on August 02, 2008, 12:05:20 PM
-
???
ok what does it mean when your robot works good for a while then one day you go to turn it on and it just twitches once and then doesnt do anything?
battery is fully charged. disconnected and reconnected everything even the mcu.
???
-
ok i just took out my atmega168 and put my atmega8 back in. (which is still programmed)
all the continuos servos on the robot started spinning counter clockwise at full speed. and the regular servo just turned and held counter clockwise.
what the devil is going on?
-
maybe one battery died, one bit of firmware switched, something makes a short (servo controller for instance), there's a dangling wire. you know this is useless if you don't explain your setup :P
-
$50 robot board, atmega168/8, 6v nimh battery pack with micro switch inline, diff drive servos, scanning servos, sharp ir...
the 6v pack tested out ok with 7+ vdc
-
Hmm, this is what i'd do.
First, check the microcontroller alone:
1 - voltage reg output, output under load (with a resistor)
2 - microcontroller - flashing a led, echoing uart data
3 - reconnect one servo, send test signal (left, stop, right, stop for instance)
4 - disconnect servo, reconnect the other servo, test
5 - connect the other servos and test them individually
6 - disconnect all servos, add them one by one (with a test signal applied to all)
7 - if all okay (although i'm pretty sure it's a servo thing), connect the sharp ir sensor, test its output via uart
-
sounds like you erased the program since the last time you used your bot . . .
(the twitching is normal for servos when you first apply power)
-
hmm I read the device with ponyprog and I saw the program hex, and i even scrolled down and saw the bootloader hex. I guess Ill reset it and program it from scratch.
-
ok i completely erased and reset the mcu
reprogrammed it.
still nothing =(
-
hmmmm go over everything with a multimeter
check the fuses
seems like its programming without error, so something else is up . . .
-
multimeter checked out....fuses are good
voltage regulator output is 4.99/4.98 is that ok?
-
maybe i should just build another $50 robot board now that I know how the circuit works and i'm better at soldering.
-
So the Atmega 8 does something other than twitch? I know the Atmega8 is clocked differently than the Atmega 168 out of the box... if you change your code BACK to the original Atmega8 version and program it will it work?
-
ok i put the original atmega8 in, reset..erased..put fuses back to factory settings, and uploaded the stock $50 robot photovore code, hooked up the ole photosensors and wa-la it worked!
now i gotta go from here and find out why my atmega168 suddenly stopped working
-
Alright, now that you know the code you have works, put the Atmega168 in and program the CKDIV8 fuse, I think that will put the Atmega168 to 1 MHz clock speed.
-
yeah it will, ill try it tonight.
-
i successfully programmed the mega168 as a photovore at 1MHz.
Ill keep trying things
-
hmmm as soon as i unprogram that CKDIV8 and upload some 8MHz code, then it stops working.
Maybe ill multiply the delay by 8 in the photovore code and try running it at 8MHz
-
ok the photovore code running at 8MHz works ???
-
i think it might be my code, but i don't remember making any sudden changes to it >:(
can someone peer review my code?
maybe compile it and test it on your atmega168 at 8MHz
(i added .txt to my makefile so that it would let me upload it to here)
-
hmmm as soon as i unprogram that CKDIV8 and upload some 8MHz code, then it stops working.
Maybe ill multiply the delay by 8 in the photovore code and try running it at 8MHz
It stopped working because you're changing the clock from 1 MHz to 8 MHz with out fixing the delay (I saw you did it in another post). The delay is based on clock cycles, so multiplying by 8 makes your code work, you're delaying 8x as much because your clock is 8x as fast.
Servos are moved by control signals sent down a line which are nothing more than pulses every ~20 ms, you pulse the servo from anywhere from 0.5 ms to 2.5 ms (depends on the servo i've had weird values here and there), and it goes to a position... these servos you're using are continous rotation modified, therefore a different pulse gives them a different speed.
NOW the problem was you had code built for a 1MHz clock running on an 8 MHz clock or visa versa, so these pulses were coming in and were either way too short, or way too long.. so the servos didn't do anything.
-
I've already multiplied all my values by 8 in order to compensate for the processor speed increase. This code worked before, but suddenly it stopped working.
To get the photovore code to run at 8MHz I just did the lazy way and did
cycles*=8;
In my other code I had taken the time to increase all the timing for the pulse widths.
-
ok i made a discovery.
when i had my battery plugged in, it twitches.
when i had my battery and usb cable plugged in, it worked fine.
i unhooked my uart connections and it works fine with the battery.
now i have to figure out why?
???
-
just to be sure . . . you aren't connecting USB power to your board, right?
or maybe a lose connection somewhere?
-
no usb power to the board...already been down that path :P
i jiggled the connections nothing wrong there as I am able to upload via my bootloader now....once
I think I've just disproved or added to my above theory, when I upload my latest code that caused all this in the first place the same twitch happens, whether the uart is hooked up or not. back to square one. :(
-
I am able to upload via my bootloader now....once
I had this problem too . . . dont quite remember what caused it.
is this the error you get?
Z:\program>fboot17.exe -b57600 -c3 -pAVR_Fish.hex -vAVR_Fish.hex
COM 3 at 57600 Baud: Connected
Bootloader VFFFFFFFF.FF
Error, wrong device informations
Setting the 2.7V brown-out fuse seemed to fix it.
-
yeah it was saying (one wire) also
bahh these bootloaders seem to be more headache then theyre worth. I had it working great with my ATmega8 and then upgraded to the mega168 and now all these problems again.
I'm also trying to break up my code by putting all the functions in seperate files so it can be more modular, and that way i can comment out the includes and add them one at a time to see what is going wrong in my code.
We need a stable SoR bootloader that uses xmodem protocol in hyperterm ;D
-
im in shock.....
so this whole thing was because I had a sensor plugged into the wrong pin on PORTC, the function for the sensor ( a ping function ) was going into an infinite loop because it was waiting for the sensor to respond.
a NOTE to everyone....if your robot twitches a possible problem is the code is in an infinite loop!!!
:-X
-
The Ping))) sensor has a green LED that shows when it it triggered. If that dows not flicker, the sensor is not working, check the wiring.
Other sensors do not have a visual indication that they are working, so I am using my status LED or the buzzer at the steps in the code that may create problems. For instance, flicker the LED if the sensor measurement was done correctly.
I had another problem. Sensor was working fine, the servo pulses were generated fine ("printed" them on the serial port), but the servos were just twitching. After some fidling with the code, I noticed that I used the name for the variable for both the pulse lenght and for the servo port... This is something harder to debug, since the code is running fine and servos are plugged right. So, if something like this happens, try changing the names you asign to the ports and pins with theyre real values.
-
I think the main failure was lack of debugging technique :P
If something isn't working, load up your code with rprintf statements to narrow down where exactly the code is failing.
If you don't have serial, get creative with LED's . . .