pwm signal delay

[3dude_2231]

hi there,
it is known that there are intervals between pwm signals,
these intervals can vary between 10mS and 20mS,

my question is, where is the code that handles the pwm signals?
well, our team's camera servos are tweeching,
and I suspect it may be caused by irregulations in the pwm signal.

many operations are done in the period between signals,
and that fact might cause the intervals to extend beyond range.

for example, it was written in CD, that ini one team, tweeching occured
while writing to EEPROM,
an action (for those who aren't familiar with EEPROM),
that consists of a few cycles => it takes some time to finish.

is it possible to change the default delay period?

thanks in advance,
Ran.

[Alan Anderson]

Originally Posted by 3dude_2231

...where is the code that handles the pwm signals?
well, our team's camera servos are tweeching,
and I suspect it may be caused by irregulations in the pwm signal.

If you're using PWMs 13-16, your suspicion is justified. It isn't a matter of time delay between PWM pulses, though. It's the width of the PWM pulse itself that makes it happen.

The last four PWM signals are generated by the user CPU. The default code does not deal with interrupts perfectly, and the pulse width can sometimes be longer than desired when serial port and wheel encoder interrupts occur. Kevin Watson wrote some code to correct the jittery behavior, which you can find here:

http://www.kevin.org/frc/frc_pwm.zip

There is still some occasional twitchiness with Kevin's code when writing EEPROM. It doesn't affect normal robot operation, and I haven't taken the time to figure out whether it's due to interrupts being disabled briefly or some other cause.

The code for PWMs 1-12 runs in the master CPU, and is not usually a problem. If you're seeing twitchy camera servos connected to one of those signals, you are probably getting interference from the serial data signal. Try rerouting the wires to keep the servo and serial data physically separated.

[3dude_2231]

thanks
I'll try fixing it as quickly as possible, as it's a holiday here in Israel.

BTW,
it's a good opertnity to say "Happy Sukkot" to everyone who celebrates it.

Ran.

[Jon236]

Happy Sukkot!

[Qbranch]

If you are having huge gigantic problem, you could just run your own pwms using (E)CCP modules.

-q

[bear24rw]

Your twitching is most likely from motors and static electricity. We had a bad problem with this two years ago because one of our motors what right need the wire going up to the servo and caused bad twitching.. are you running motors by the the camera or pwm wires?

[Kevin Watson]

Originally Posted by Alan Anderson

There is still some occasional twitchiness with Kevin's code when writing EEPROM. It doesn't affect normal robot operation, and I haven't taken the time to figure out whether it's due to interrupts being disabled briefly or some other cause.

The PWM code should be pretty solid at this point. If the twitchiness occurs while saving camera parameters to EEPROM, the likely problem is that I call printf() many times in rapid succession to draw the menu on the terminal screen. This bogs down the CPU and causes a long delay between PWM pulses. If the delay is long enough, the servos assume something is wrong and attempt to center the output shaft. In practice this isn't a problem and can be fixed by using a state machine to dole out the printf()s a few at a time.

-Kevin

[Alan Anderson]

Originally Posted by Kevin Watson

If the twitchiness occurs while saving camera parameters to EEPROM, the likely problem is that I call printf() many times in rapid succession to draw the menu on the terminal screen. This bogs down the CPU and causes a long delay between PWM pulses. If the delay is long enough, the servos assume something is wrong and attempt to center the output shaft.

That doesn't sound right to me, for two reasons. First, the servo twitch occurs only when EEPROM is written. It does not happen when the menu is written to the terminal at other times. Second, servos don't "attempt to center" when they lose signal. They stop driving the shaft completely.

But we agree that it isn't a problem in practice. I consider it a minor cosmetic blemish on otherwise shiny code.

[Kevin Watson]

Originally Posted by Alan Anderson

That doesn't sound right to me, for two reasons. First, the servo twitch occurs only when EEPROM is written. It does not happen when the menu is written to the terminal at other times. Second, servos don't "attempt to center" when they lose signal. They stop driving the shaft completely.

But we agree that it isn't a problem in practice. I consider it a minor cosmetic blemish on otherwise shiny code.

Hmmm... Maybe I'm clueless here (wouldn't be the first time <grin>). I guess I'll have to crack the code open and have a look at what's going on.

BTW, when you say it only happens when EEPROM is being written, is it my code that's doing the writing? Is my camera code running too?

-Kevin

[Gdeaver]

The data sheet shows a byte erase write cycle taking 4ms. The question is for multiple writes are interrupts enabled between writes?

[bear24rw]

whats your setup is this a benchtest or is it on a robot? Are you extending the pwm cables at all?

[Kevin Watson]

Originally Posted by Gdeaver

The data sheet shows a byte erase write cycle taking 4ms. The question is for multiple writes are interrupts enabled between writes?

Interrupts are only disabled for a about a microsecond each time a byte is written and interrupts are serviced while waiting for the write to complete.

-Kevin

[Alan Anderson]

Originally Posted by Kevin Watson

BTW, when you say it only happens when EEPROM is being written, is it my code that's doing the writing? Is my camera code running too?

Yes to both. I've only noticed it when writing camera configuration, so it could be an issue with how the pan/tilt control software changes menu modes and might turn out not be related to EEPROM at all. Or it could be that the camera EEPROM data structure is long enough for it to show an effect where a shorter EEPROM structure does not.

In our software, we've generalized the EEPROM and menuing support and added several additional menus (drivebase PID tuning, arm PID tuning, sensor and navigation status, and automode targeting setup). To keep from rewriting what's already provided to us, there is a small bit of "wrapper" code around the calls to the camera and tracking menuing functions. However, those functions do still get called just as often as they do in the unmodified camera code.

[Qbranch]

Well since those servos use a linear carbon filament pot for feedback, and simply use proportional control for positioning (Just P, not PI, PD, etc...) then if your supply voltage to the servo(s) is/are too low (I believe 5v is the absolute minimum) then the voltage reference onboard the servo for the analog feedback may be skewed... or it might dip too low whenever the servo attempts to move... causing a 'twitch' as the position the porportional chip in the servo gets back would vary with a low voltage reference. Maybe when you write to your EEPROM your voltage dips ever so slightly and this occurs.

Or, as a more probable option, some EEPROM uses a very high voltage to flash the bits into memory. This could theoretically casue a high voltage spike to go out of the processor as the lines driving the EEPROM decay after flashing a bit in.

Maybe i'm barking up the wrong tree... but it sounds like most other things have been defined as working.

-q

[3dude_2231]

thanks for your response, guys.
I'll be checking it out soon.