Gyro PID User drive - How we did it

[Bongle]

Originally Posted by tdlrali

Looks great!

Hey Alan, is 254 really the max in the IFI setup? I always thought 255 was the max... I think I incorrectly corrected a few people if that is the case.

255 can do some wierd stuff. Way back in 2003, I couldn't figure out why our robot wouldn't drive straight. Another team pointed out that 255 was some sort of null character. I changed it to 254, and the thing started driving perfectly.

The X axis sets the "desired" heading.

Last year we found that our robot could massively out-spin the maximum rotation rate supported by the gyro. What do you do once the gyro reading goes 'beyond' the maximum/minimum of the chip?

[Render]

one way you could improve your code is remove the floats since they are very expensive to the processor and replace them with a numerator and denominator. Then when doing your math you do everything for that portion and divide last.

ex.
char Kp = 5;
char kpDiv = 100;

pTerm = (Kp * p_error) / KpDiv;

You will lose the precision of having a floating point value in the end, but with PWM values I do not think that matters anyways

also I am wondering why your errors are floats?

[adamdb]

Alan,
I did sort of say we weren't using the I component by saying we were using P&D, but should have been a little more clear. I took a pass through the comments, but as usual missed a few that no longer matched up with the code. Odd that you have had issues with 255, we have always used it without issues.

Don,
The drive setup is a typical setup with one motor on each side (facing opposite directions) that power the drive wheels on that side. As the motors face opposite directions we need to do the inversion for (in our case) the right side as shown in the bottom of the PID_adjust() routine.

// Invert the right output and put them to the wheels
OUT_PWM_LM = left_out;
OUT_PWM_RM = 255 - right_out;

I definitely urge you to play with the gyro and this code and the other available examples for driving the robot. We hadn't used a gyro in previous years because I didn't understand them or PID routines, but dug into it this year and did some reading and the result has been great.

Render,
As I mentioned in the original post the code was not optimized for size or speed and we will get rid of the floats in future revisions. The errors were made floats so it didn't have to add code to convert from an integer to floating point before it made the calculations.

Thanks all for the feedback!
Adam

[Alan Anderson]

Originally Posted by tdlrali

Hey Alan, is 254 really the max in the IFI setup?

The proper maximum pwm output is indeed 254. Here is one bit of documentation to that effect:

Originally Posted by IFI Tech Support

In the Robot Controller program, a value of 0 corresponds to a 1ms pulse. A 1.5ms pulse means neutral, or a value of 127, while a 254 corresponds to a 2ms pulse.

See also this post on the IFI Technical Support forum, which shows the range 231-254 as "Full Forward" on a Victor.

Originally Posted by Bongle

255 can do some wierd stuff. Way back in 2003, I couldn't figure out why our robot wouldn't drive straight. Another team pointed out that 255 was some sort of null character. I changed it to 254, and the thing started driving perfectly.

The communication protocol between OI and RC uses a pair of 255 (0xFF) characters to synchronize frames of data. Back in the pre-C days, it might have been possible to confuse it by setting adjacent pwm values to 255. My experience is with the 2004 and later control system, which refuses to report a pwm value greater than 254. I don't know whether the limit is enforced on the actual pwm output or if it's just the dashboard data coming back from the RC that won't go that high.

[adamdb]

Tom,
I saw your post of your PID code, thanks! Reviewing this with my programming students will be a great learning exercise as we haven't covered structures yet.

Alan,
Thanks for the info on the max value of 254. Looks like we need to go through our code and make some changes.

[Tom Bottiglieri]

Originally Posted by adamdb

Tom,
I saw your post of your PID code, thanks! Reviewing this with my programming students will be a great learning exercise as we haven't covered structures yet.

That was Billy's from 1124. Either way, its a pretty good way to get into structures. It covers typedefs, local declarations, and pointers.

[artdutra04]

Originally Posted by Bongle

Last year we found that our robot could massively out-spin the maximum rotation rate supported by the gyro. What do you do once the gyro reading goes 'beyond' the maximum/minimum of the chip?

Team 228 purchased an additional 300 degree/second gyro for use with PID control with our drivetrain, as this proved much more adequate for drive-train use than the Kit of Parts gyro. So we used the stock KoP gyro for PID control on our arm instead.

[ay2b]

Originally Posted by Bongle

255 can do some wierd stuff. Way back in 2003, I couldn't figure out why our robot wouldn't drive straight. Another team pointed out that 255 was some sort of null character. I changed it to 254, and the thing started driving perfectly.

I believe the limit today is actually 255. "Back in the day", when the user microprocessor was a BASIC stamp, instead of a PIC, it used the serial i/o from the stamp to communicate with the master processor. Each packet had a 0xFF 0xFF header (i.e. 255, 255). The PWM out values were interlaced with the relays and the digital outs, and we were told not to run PWMs above 254. If a PWM was run at 255, then being next to some other byte, which could be 255, it could look like a packet header, and throw things off. Now, however, with the use of a PIC instead of the BASIC stamp, the problem of getting this false header no longer exists, so it's safe to run PWM outs at 255. (Tangentially, I think the user and master processors now communicate via shared memory, but I'm not certain of the details.)

The difference in output between 255 and 254 is not going to be noticeable, and Victors have a small center deadband, so both 127 and 128 are going to give you a "full off" from the Victor, so it really doesn't matter which way you do it. Just don't try to use 256 as your "full on" value.

[meatmanek]

Originally Posted by Bongle

255 can do some wierd stuff. Way back in 2003, I couldn't figure out why our robot wouldn't drive straight. Another team pointed out that 255 was some sort of null character. I changed it to 254, and the thing started driving perfectly.

Keep in mind that 2003 was a radically different RC than today's C-based controllers. The radio protocols changed as well in 2004, and so 255 doesn't have the stigma it used to. You may not see any difference between 255 and 254 in actual PWM output, but the only thing weird about 255 now is that 255+1 = 0.

[Dave Flowerday]

Originally Posted by meatmanek

Keep in mind that 2003 was a radically different RC than today's C-based controllers. The radio protocols changed as well in 2004, and so 255 doesn't have the stigma it used to. You may not see any difference between 255 and 254 in actual PWM output, but the only thing weird about 255 now is that 255+1 = 0.

The radio protocol really didn't change. There were minor changes but the protocol still uses (255, 255) as a synch code which is why PWMs aren't allowed to use 255.