PWM problem in autonomous
 

I'm sorry for the newbie post but we just finished trying our robot out for the first time. (It's 4am!) We are a rookie team and we have most things working except autonomous mode. This may have come up before but I don't have time to scan every autonomous thread. If someone would be kind enough to explain why our motor speed controllers flash the orange light (no signal on PWM outputs?) and don't work in autonomous mode. They work fine in manual mode. I checked the code and it seems fine. I stripped the default routinesfast routine down to just moving forward and it won't do that. We can't test any of our code because of this. Help!

Re: PWM problem in autonomous
 

we had the same problem but first released an updated default code on tuesday. download it at innovationfirst.org. it initialize the relays and motors.
and generates pwm signals. Hope that helps and good luck.

Re: PWM problem in autonomous
 

255 is the reset command. Use 254

Re: PWM problem in autonomous
 

We found that if your motors are on PWMs 13-16 and you have more than one interrupt, the PWMs lose signal (blinking orange light on speed controllers) when both interrupts trip. Don't know why, but we moved the motors to PWMs 9-12 and the problem went away.

Re: PWM problem in autonomous
 

From the infrared beacon and tracking FAQ:

Q: I merged the code from the tracker codebase into my code for non-autonomous driving, including dropping the replacement user_routines_fast.c in place of the default one, and things got weird. The trackers would run okay, but the motors, connected to PWM 13 and PWM 15, started running and stopping with a jerking motion. Having read that there is something different about PWMs 13 through 16, I connected my motors to PWM 10 and PWM 11, turned all the tracking code back on, and everything worked nicely! Can you tell me why changing the motors from 13 and 15 to 10 and 11 changed the behavior from erratic to normal? What's going on here?
A: PWMs 13 through 16 are different because they're controlled by the user processor. I saw the wacky behavior you described while developing the receiver and tracking code. The problem isn't with my code (as far as I know). The IFI folks know about this and wrote it up.

Q: We're seeing wacky behavior like that described above, but we're not using PWMs 13 through 16. What's up?
A: Your interrupt handler(s) might not be saving enough context information. I altered the code to be more conservative in this regard. Get the latest version of the code or just alter the #pragma interruptlow line in user_routines_fast.c to look like this:

#pragma interruptlow InterruptHandlerLow save=PROD,section("MATH_DATA"),section(".tmpdata")

If this change causes problems for you (e.g. your encoders stop working correctly), there are other options that you can try. Read section 2.9.2 of the PIC18 compiler user's guide for more information.

-Kevin

Re: PWM problem in autonomous
 

Thanks for the heads up Kevin.
What's interesting, is that we'd been experimenting with 128/rev encoders and you're Quadrature code (sweet find!) for a few nights....seeing if they swamped the processor with interrupts...(they did). And we did not see this effect, at first. Then , last Saturday, we divided down the signals to lower the rate/rev. After that, we could use one encoder but not two. With the chasis up on blocks, we could spin one encoder by hand, but as soon as we turned the second encoder, the signals to the speed controllers on 13-16 would stop. ....very strange indeed.

We switched pwms and put on 64bit/rev encoders,took out the divider circuit, and things "give the appearance of working" :p

Thanks again
Eric Schreffler