Author Topic: robot twitch (Read 4293 times)

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.

pomprocker · « **Reply #1 on:** August 02, 2008, 12:11:40 PM »

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?

izua · « **Reply #2 on:** August 02, 2008, 12:56:03 PM »

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

pomprocker · « **Reply #3 on:** August 02, 2008, 04:24:17 PM »

$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

izua · « **Reply #4 on:** August 02, 2008, 09:30:07 PM »

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

Admin · « **Reply #5 on:** August 03, 2008, 09:32:09 AM »

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)

pomprocker · « **Reply #6 on:** August 04, 2008, 10:11:07 AM »

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.

pomprocker · « **Reply #7 on:** August 04, 2008, 10:02:05 PM »

ok i completely erased and reset the mcu

reprogrammed it.

still nothing =(

Admin · « **Reply #8 on:** August 05, 2008, 04:46:38 AM »

hmmmm go over everything with a multimeter

check the fuses

seems like its programming without error, so something else is up . . .

pomprocker · « **Reply #9 on:** August 05, 2008, 10:40:23 PM »

multimeter checked out....fuses are good

voltage regulator output is 4.99/4.98 is that ok?

pomprocker · « **Reply #10 on:** August 05, 2008, 11:06:37 PM »

maybe i should just build another $50 robot board now that I know how the circuit works and i'm better at soldering.

dsheller · « **Reply #11 on:** August 05, 2008, 11:19:24 PM »

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?

pomprocker · « **Reply #12 on:** August 06, 2008, 12:42:33 AM »

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

dsheller · « **Reply #13 on:** August 06, 2008, 12:48:46 AM »

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.

pomprocker · « **Reply #14 on:** August 06, 2008, 09:33:28 AM »

yeah it will, ill try it tonight.

pomprocker · « **Reply #15 on:** August 06, 2008, 09:59:25 PM »

i successfully programmed the mega168 as a photovore at 1MHz.

Ill keep trying things

pomprocker · « **Reply #16 on:** August 06, 2008, 11:08:10 PM »

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

pomprocker · « **Reply #17 on:** August 06, 2008, 11:20:42 PM »

ok the photovore code running at 8MHz works

pomprocker · « **Reply #18 on:** August 06, 2008, 11:45:23 PM »

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)

dsheller · « **Reply #19 on:** August 07, 2008, 12:16:51 AM »

Quote from: pomprocker on August 06, 2008, 11:08:10 PM

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.

pomprocker · « **Reply #20 on:** August 07, 2008, 09:41:44 AM »

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

Code: [Select]

cycles*=8;
In my other code I had taken the time to increase all the timing for the pulse widths.

pomprocker · « **Reply #21 on:** August 11, 2008, 10:43:51 PM »

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?

Admin · « **Reply #22 on:** August 12, 2008, 04:41:24 AM »

just to be sure . . . you aren't connecting USB power to your board, right?

or maybe a lose connection somewhere?

pomprocker · « **Reply #23 on:** August 12, 2008, 09:56:58 AM »

no usb power to the board...already been down that path

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.

Admin · « **Reply #24 on:** August 12, 2008, 11:49:10 AM »

Quote

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?

Quote

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.

pomprocker · « **Reply #25 on:** August 12, 2008, 12:22:31 PM »

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

pomprocker · « **Reply #26 on:** August 17, 2008, 09:16:43 PM »

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!!!

Ro-Bot-X · « **Reply #27 on:** August 18, 2008, 05:14:41 AM »

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.

Admin · « **Reply #28 on:** August 18, 2008, 06:10:39 AM »

I think the main failure was lack of debugging technique

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 . . .

News:

Author Topic: robot twitch (Read 4293 times)

Related Topics