Kevin's Navigation Script Working for Your Team?

[Chris_Elston]

Anyone using Kevin's navigation script? How's it going for you? Was you able to get it to work for your team? At one point our team was doing ok then we went away from the software and now we are back to it but can't seem to get the PID to settle down. Actually the PID does settle down, but when we issue a CMD_DRIVE 1500 in the command list, the robot does not drive straight nor is it going the right direction, it's going backwards. We've changed the varibles:

/* Set these to change the motor direction,
1 = forward, -1 = backward. */
#define LEFT_DIR (-1)
#define RIGHT_DIR (1)

to

/* Set these to change the motor direction,
1 = forward, -1 = backward. */
#define LEFT_DIR (1)
#define RIGHT_DIR (-1)

But it still goes backwards and doesn't drive straight.

Also....
Does anyone know what these varibles do for sure?

/* Motor defines */
#define LEFT 0
#define RIGHT 1

I am bit confused at what we've got now. I am certain our encoders are working, checked them with an O-Scope. Any ideas or success stories anyone would like to share about getting your NAV code working?

Any trouble shooting tips would be appreacaited.

[Kevin Watson]

Originally Posted by chakorules

Any trouble shooting tips would be appreacaited.

You might be spinning the encoder(s) too fast. This is addressed in question 6 of the encoder FAQ I've started. Also check that you have the correct sign specified for each of the encoders in encoder.h.

-Kevin

[Chris_Elston]

Originally Posted by Kevin Watson

You might be spinning the encoder(s) too fast. This is addressed in question 6 of the encoder FAQ I've started. Also check that you have the correct sign specified for each of the encoders in encoder.h.

-Kevin

Thanks for the tips Kevin. I'll double check this with our crew tonight and see what we can find.


Any comments on what these varibles do?
/* Motor defines */
#define LEFT 0
#define RIGHT 1


Also, FYI...last night we have a working camera and Kevin Nav script that we are willing to share. We want to clean up the logic flow of the function calls, but from what we can see, we've got it working. Minus the backward glitch above.

Our team will start a new thread on CD once we feel comfortable and have tested all our combo-code to release to everyone.

[Kevin Watson]

Originally Posted by chakorules

Any comments on what these varibles do?
/* Motor defines */
#define LEFT 0
#define RIGHT 1

These #defines are used to identify the motors that belong to the motor_info[] array. See the top of pid.c to see how they're used.

-Kevin

[cabbagekid2]

Originally Posted by Kevin Watson

You might be spinning the encoder(s) too fast. This is addressed in question 6 of the encoder FAQ I've started. Also check that you have the correct sign specified for each of the encoders in encoder.h.

-Kevin

Would changing the code to make the encoders interrupt on both a change in A or B fix this problem? Or would this cause the microcontroller to interrupt too often?

[Kevin Watson]

Originally Posted by cabbagekid2

Would changing the code to make the encoders interrupt on both a change in A or B fix this problem? Or would this cause the microcontroller to interrupt too often?

Two things than can easily be done are: 1) Capture the state of the phase-B signal earlier in the ISR, and 2) use a D-type flip-flop to capture the state of the phase-B signal as the phase-A signal transitions from low to high. You can do this by wiring the phase-A signal to the flip-flop's clock input and to the interrupt input. Wire the phase-B signal to the flip-flop's D input and connect the flip-flop's Q output to the phase-B input on the robot controller. Option one will get you perhaps an extra microsecond or two. Option two will give you a much more significant increase.

-Kevin

[SQUiD]

Also check your encoders wires, and make sure they are going to the correct wheels, and PWM ports.

[gnormhurst]

Originally Posted by chakorules

...the robot does not drive straight nor is it going the right direction, it's going backwards. We've changed the varibles:

/* Set these to change the motor direction,
1 = forward, -1 = backward. */
#define LEFT_DIR (-1)
#define RIGHT_DIR (1)

to

/* Set these to change the motor direction,
1 = forward, -1 = backward. */
#define LEFT_DIR (1)
#define RIGHT_DIR (-1)

But it still goes backwards and doesn't drive straight.

Just a guess:

If the motors are wired so that positive pwm values make both wheels turn the same direction, then I think the LEFT_DIR and RIGHT_DIR values need to be the same. By changing both of them, they are still different, and you haven't really changed anything. There are four combinations to try!

[Astronouth7303]

Originally Posted by gnormhurst

Just a guess:

If the motors are wired so that positive pwm values make both wheels turn the same direction, then I think the LEFT_DIR and RIGHT_DIR values need to be the same. By changing both of them, they are still different, and you haven't really changed anything. There are four combinations to try!

LEFT_DIR and RIGHT_DIR are used to determine if 254 is forward or 0 is forward. See the end of pid() in pid.c. The PWM value internally is stored as a signed int.