ADC code effecting motor outs???

[Kyveck]

Our robot's motors seem to be receiving some sort of signal even when all pwm outs are hardcoded to zero. We systematically turned off sensors and bits of code, until we isolated the problem with the adc software. Unless we disable the adc code, (by commenting out the adc initialization or the adc/timer interrupt routines) the drive wheels act as if they are set to 10 or 20 above neutral, instead of 127. If we enable the joystick and pull it back about 10 or so, the wheels stop. If we set one wheel to be mapped as (255-p2_y) then ten forward or so stops one wheel and speeds up the other, and vice versa. If we change the sampling rate from 200Hz that we were using to 800Hz, then the wheels spin much faster, but in the same manner.

If anyone has any clue what's going on, I would be very grateful for insight. I realize that both ways that we have found to stop the motor movement have the net effect of not causing any adc interrupts, but I don't see what could be going wrong. The dashboard viewer continues to read neutral pwm values for all RC pwm outs. The gyro is on analog in 1, and the motors are on pwms 13 and 15. We have patched in Kevin Watson's gyro and adc code, version 0.4. Once again, if any one can help, we'd all appreciate it.

KLW,
Controls Software Lead,
Team 1014, Dublin Robotics (Bad Robots)

[kaszeta]

Originally Posted by Kyveck

Our robot's motors seem to be receiving some sort of signal even when all pwm outs are hardcoded to zero. We systematically turned off sensors and bits of code, until we isolated the problem with the adc software. Unless we disable the adc code, (by commenting out the adc initialization or the adc/timer interrupt routines) the drive wheels act as if they are set to 10 or 20 above neutral, instead of 127. If we enable the joystick and pull it back about 10 or so, the wheels stop. If we set one wheel to be mapped as (255-p2_y) then ten forward or so stops one wheel and speeds up the other, and vice versa. If we change the sampling rate from 200Hz that we were using to 800Hz, then the wheels spin much faster, but in the same manner.

This explains the symptoms we've been seeing as well. Our current code (which uses Kevin's ADC code for the gyro, DAA, and one other channel) shows a slightly positive value on the PWMs, but the default code doesn't. It 's not causing us any problems, but it's enough to cause the CIMs to hum even when everything is set to 127.

[Jared Russell]

This is news to me...

Have you tried recalibrating the speed controllers?

[Kyveck]

This is more than a slight hum. At 800Hz, the robot drives about 3 m/s when we take it off blocks.

[kaszeta]

Originally Posted by Abwehr

This is news to me...

Have you tried recalibrating the speed controllers?

Ours are calibrated. For us, the problem is slight (it's just a few steps outside of the Victor's deadband).

[Kevin Watson]

Originally Posted by Kyveck

Our robot's motors seem to be receiving some sort of signal even when all pwm outs are hardcoded to zero. We systematically turned off sensors and bits of code, until we isolated the problem with the adc software. Unless we disable the adc code, (by commenting out the adc initialization or the adc/timer interrupt routines) the drive wheels act as if they are set to 10 or 20 above neutral, instead of 127. If we enable the joystick and pull it back about 10 or so, the wheels stop. If we set one wheel to be mapped as (255-p2_y) then ten forward or so stops one wheel and speeds up the other, and vice versa. If we change the sampling rate from 200Hz that we were using to 800Hz, then the wheels spin much faster, but in the same manner.

If anyone has any clue what's going on, I would be very grateful for insight. I realize that both ways that we have found to stop the motor movement have the net effect of not causing any adc interrupts, but I don't see what could be going wrong. The dashboard viewer continues to read neutral pwm values for all RC pwm outs. The gyro is on analog in 1, and the motors are on pwms 13 and 15. We have patched in Kevin Watson's gyro and adc code, version 0.4. Once again, if any one can help, we'd all appreciate it.

KLW,
Controls Software Lead,
Team 1014, Dublin Robotics (Bad Robots)

The problem is that PWM channels 13-16 are "bit banged" by code running on the user processor. When you have a lot of interrupts firing-off in the background, IFI's code get's interrupted while running, which causes jitter in the outputs. The only solution is to not use PWMs 13-16.

-Kevin

[Kyveck]

Thanks. That makes sence. I tried to find the source for the Generate_pwms function, but it was in a library. Between the adc, timer, serail comms, and encoders, we probably get about 400 interrupts a second. We'll just switch to a different pwm out. Thanks again,
KLW

[kaszeta]

Originally Posted by Kevin Watson

The problem is that PWM channels 13-16 are "bit banged" by code running on the user processor. When you have a lot of interrupts firing-off in the background, IFI's code get's interrupted while running, which causes jitter in the outputs. The only solution is to not use PWMs 13-16.

That's rather what I suspected. I'll try having the guys shuffle around the PWMs.

[Mike Bortfeldt]

Kyveck,

If you still want to use PWMs 13-16, you can try this piece of code (hopefully this is the working version...). It replaces the Generate_Pwms function call and utilizes Timer 3 and the CCP modules to control the pwm 13-16 pulse width. Since the pulse is controlled by hardware, it should be independent of other interrupts. My team was planning on using PWM 13, 15 & 16 this year in order to improve the Victor response time since PWMs 1-12 seem to put around a 50 millisecond delay between setting the pwm output variable and for the Victor to respond (communication to the master processor plus some other delay). But based on the recent comments I've read on CD, having a jittery PWM output would not be unacceptable.

I have not had a chance to do any extensive testing on this code other than a quick check to be sure that it is indeed generating a 1-2 millisecond pulse, so it may still have some bugs. I plan on running more tests over the next week but if you decide to use it and have any questions or problems, let me know.

Mike

[Eldarion]

Thanks for posting that code. I will be trying it out sometime soon, but I will have to port it to Timer 2, as Timer 3 is in use already.

[Kevin Watson]

Originally Posted by Mike Bortfeldt

Kyveck,

If you still want to use PWMs 13-16, you can try this piece of code (hopefully this is the working version...). It replaces the Generate_Pwms function call and utilizes Timer 3 and the CCP modules to control the pwm 13-16 pulse width. Since the pulse is controlled by hardware, it should be independent of other interrupts. My team was planning on using PWM 13, 15 & 16 this year in order to improve the Victor response time since PWMs 1-12 seem to put around a 50 millisecond delay between setting the pwm output variable and for the Victor to respond (communication to the master processor plus some other delay). But based on the recent comments I've read on CD, having a jittery PWM output would not be unacceptable.

I have not had a chance to do any extensive testing on this code other than a quick check to be sure that it is indeed generating a 1-2 millisecond pulse, so it may still have some bugs. I plan on running more tests over the next week but if you decide to use it and have any questions or problems, let me know.

Mike

Mike, this is cool. If someone has some free time <grin>, a good experiment would be to use Mike's code to see if you can wring-out a little more pointing accuracy from the camera servos.

-Kevin

[kaszeta]

Originally Posted by Kevin Watson

Mike, this is cool. If someone has some free time <grin>, a good experiment would be to use Mike's code to see if you can wring-out a little more pointing accuracy from the camera servos.

I'm working on that as a side project.

[Joel J]

This made me smile:

pwm13 * 40; // Calculate the time delay for PWM13
CCPR2 = PROD + 9913;

Beautiful!

[Gary Bonner]

Can someone explain what this does, particularly the first line?

Thanks.

	pwm13 * 40;		// Calculate the time delay for PWM13
	CCPR2 = PROD + 9913;

[Joel J]

The first line does a multiplication. When you do a multiplication on the PIC, it is stored in the PROD register. The second line gets the value from the PROD and uses it. He does it this way so he has one less section to save before servicing the interrupt.