I’m attempting to implement Kevin Watson’s 2005 Nav code on our EDU Mini controller to give my team a small scale platform to learn about PID contollers and to expirement with their own code. (this will be the first year we attempt to use encoders & gyros) I basically took the EDU code as written and added pid.c/h, robot.c/h, encoder.c/h, gyro.c/h, commands.h as well as adc.c/h. I updated the ISR’s for adc & encoder.c. I have also updated all the constants to apply to the smaller bot. The software compiles and runs but I’m having a few problems.
I put CMD_GYRO_BIAS at the top of the list and it seems to work fine. However, it seems to go haywire after that. Sometimes it steps through my command list just fine and other times it jumps out of the loop to show “unknown command restarting …”. It’s as if the rc variable is getting randomly set, and when it moves to the next command it does not recognize it (even thought it did the last time it ran). I’ve got the NULL command as the last one.
The PID algorythm does not really monitor the error between the left and right motor speeds and so the bot won’t go straight. This is a known shortcomming and I’ve read all the posts and some friendly folks are helping with code examples to fix that. However, I can’t even get the bot to go straight when contolling on velocity. No mater what setting (pwm value) I use, my left motors alway go faster than my right motors. I’m wondering if there is some inherant issue with either the EDU mini controller or the motors?
Possibly a memory overwrite. You might generate a .map file and check it to see where your arrays are falling relative to the memory location of rc (i.e., those at lower addresses can overwrite higher addresses), and print the values of rc to see if it’s really random. Make sure rc is static or global.
For the unbalance power of the left vs. right drive I’d test both at max pwm (forward and backward) and then begin slowing the faster side until the sides are balanced. That’ll give you a more concrete measurement of the magnitude of the problem. The motors, chain, wheels all contribute to mismatched power, but it’s not usually so severe. This is actually one of the exercises I put the new programmers through, by purposely unbalancing things (through s/w or mechanics) and having them rebalance in software.
P.S. The difference is usually proportional or close to it, so you can apply a percentage of the max correction at slower pwms.
I still own and use one of the old Robovation kits, and I’ve observed that there is in fact a HUGE difference in the forward and reverse speeds of the motors. If this is what is causing the problem in your case, when you run the robot backwards the right motors should now rotate faster than the left motors. I think I’ve had to cut back on the speed of one motor by as much as one half to compensate.
The PID loop in the navigation code probably isn’t designed in a way that would allow it to compensate for this much a speed difference (between the expected and actual speeds for forward and reverse), so your best bet is to follow Mark’s procedure and slow down the motors for the appropriate direction of rotation in the code, after having run the PID loop.
Yes you are both (Pat & Mark) correct relative to the speed differences of the EDU motors in fwd & rev. I have been able to slow the one side down in the code to allow it to track fairly straight. I just added a 60/100 factor at the end of the PID routine to the right sides pwm value and it works ok now.
Mark,
On the other problem I too suspect some kind of memory over-write or over-flow problem. I printed out the rc values and they show up as either 1 or 0 99.9% of the time. But occasionally a random 485 or 2046 shows up and then things go south. I’m kind of a novice with the PIC and C. I not familiar with how to create a .map file to check my memory allocations. Is there a website that explains how to do it? Should I use the “extern int” identifier for rc to ensure it’s a global variable somewhere outside the robot_command() function? (if that’s it, I’m curious why Kevin did not do it that way to start with).
The memory map can be generated by MPLAB whenever you compile your code by going to:
Project -> Build Options… -> Project
then click on the “MPLINK Linker” tab,
then click on “Generate map file”.
After you build your project look in your project directory for a text file ending in “.map”. You can view it in any text editor.
[font=Verdana]The *.map file has four parts: [/font]
[font=Verdana]1) [/font][font=Verdana]Section Info[/font]
2) Program Memory Usage[font=Verdana][/font]
[font=Times New Roman][font=Verdana][size=2]3) [/font][font=Verdana]Symbols - Sorted by Name[/font][/size][/font]
[font=Times New Roman][font=Verdana][size=2]4) [/font][font=Verdana]Symbols - Sorted by Address[/font][/size][/font]
[font=Verdana][font=Courier New][/font][/font]
[font=Times New Roman][font=Verdana][size=2]Section 2[/font][font=Verdana] is pretty useful as it gives the utilization summary for the Program Space directly, but 90% actually represents full as far as the user is concerned.[/font][/size][/font]
[font=Verdana][font=Times New Roman][/font][/font]
[font=Times New Roman][font=Verdana][size=2]Section 4 shows the Data Space utilization that you want (ignore for now the Program Space – see column marked “location”). [/font][/size][/font][font=Verdana][size=2][font=Times New Roman]I[/font][font=Times New Roman][font=Verdana]t provides the starting address of each declared variable. The ending address can be either assumed to be where the next variable starts or calculated from the known size. [/font][/font][/size][/font]
rc is fine declared the way it is. My fault for snapping off a quick afterthought and not checking the code first.
rc’s value is the status returned from each of the driving functions, so the problem is probably within one or more of the driving functions.
Identify the function(s) being executed when it returns the bad values. It could be as simple as just not being assigned before exiting the drive routine.
If it’s an overwrite issue it’ll either be within the drive function or possibly with any debug printfs that occur before you check rc to proceed to the next command.
As regards the printf, the EDU code because of it’s age is probably not using the newest C compiler version, but an old IFI version printf_lib.c/h. That old version has several limitations you should read about in the printf_lib.c header comments. I only mention it because one of the limitations is it will overwrite if you attempt to printf a long message (> 80 characters). I doubt this is your problem because the bad rc numbers you quoted are not the ASCII characters you’d expect if this were happening.
Mark/Kevin,
I’ve been sent out on a business trip. I won’t be back til later this week so please stay tuned!
Mark,
Thanks for the .map info, I’ll give it try.
Kevin,
ACD sampling - I have been trying it at 200, 400 and 800 HZ. It does not seem to matter.
Ticks/sec - I’ll have to confirm the numbers when I get home but I’m using the 128 Grayhill 61K encoder. At ~500mm/sec with 60 mm dia wheels and a 1 to 1 ratio between the encoder gear and the wheel gear, it’s about 340 ticks/sec I’m guessing.
Another possibility since you are using ISRs is that a compiler generated temporary variable (or MATH variable) being used by your main code is being overwritten during the execution of the ISR. If this is happening, then your code can behave very unpredictably. As a quick check, look just before the “void InterruptHandlerLow ()” routine in the user_routines_fast.c file, there should be a line similar to the following:
At a minimum, the PROD & “.tmpdata” section should be in the #pragma statement. While Kevin’s code contains both of these, the default EDU code does not. The MATH_DATA section is probably not needed but for testing purposes it won’t hurt to add it just in case (except for some additional latency executing the interrupts). Kevin’s code usually includes multiple versions of this line, so you may be able to just uncomment the correct one. This may not help, but I thought it was at least worth a mention.
Mike Bortfeldt,
This is what was in the position you noted: #pragma interruptlow InterruptHandlerLow save=PROD /* You may want to save additional symbols. */
I commented that line out and put this line below it: #pragma interruptlow InterruptHandlerLow save=PROD, section(".tmpdata"), section(“MATH_DATA”)
The randomness has gone away and the software steps through my command list without jumping around! Thanks for the help!
Now I need to work on the turning. The gyro code does not seem to be working now… stay tuned for more questions!
I was worried that the gyro was not working or the ADE was not working but they appears to be working fine. All the calculations seem to be working fine until it gets to the “gyro_angle += (long)temp_gyro_rate;” line of code. All that the variable gyro_angle will ever be is -1 or 0. I can move the gyro and get it to change from 0 to -1 and visa versa. Any ideas? I’m guessing my C abilities are getting in the way?
I’m not sure about this, but I believe that the EDU controller shares pins for digital and analog inputs. You need to set the input your gyro is plugged into to be an analog input in user_initialization() which is user_routines.c.
Considering he gets a valid gyro bias and rate, the problem is not the reading.
jaustin,
gyro_angle is declared as a long in Kevin’s code. The comments section of printf_lib.c states that you should use %lx, but I have never tried that.
What will work (and what Kevin’s code does in another section) is to type-cast the long variable. You should print it like that:
Depending on what compiler version you’re using, it should be \r or
.
Anyway, on your code you’re printing three times inside the Process_Gyro_Data function. This is an interrupt service routine, and it should be processed as fast as possible. Printf takes a lot of time, and it is unwise to use it three times (actually, to use it at all) inside an ISR.
Check user_routines.c on Kevin’s code, there are some examples that will print exactly what you want without “side effects”.
Have you run the latest gyro code on your controller without any modifications other than setting the gyro type in gyro.h and compiling? If so, did it work? If not, can you give it a try?
Re-reading your post, I realized that you’re reaching deep into the code and looking at half-baked data. The variable gyro_angle is just a summation of all of the preceeding gyro rate measurements and won’t make sense until you examine the return value of Get_Gyro_Angle( ). Here’s the function:
longGet_Gyro_Angle(void)
{ // Return the calculated gyro angle to the caller. return(((gyro_angle ***** GYRO_SENSITIVITY *****5L) / (ADC_RANGE ***** ADC_UPDATE_RATE)) ***** GYRO_CAL_FACTOR);
}
I only calculate the angle “on demand” to keep the load on the microcontroller to a minimum.
BTW, I’ve spent quite a bit of time in Mukilteo – mostly waiting for the ferry to Whidbey Island <grin>.
Although you probably know already, I tried your edu_gyro code out on the VEX with ver 5 firmware. I have the ADXRS150EB attached and the software worked flawlessly.
Kevin,
Yep, I’ve spent some time in that ferry line myself! It’s a great time to read my Servo Magazine!
Yes, I have run just the gyro code on my EDU controller and it worked fine. When I rotated the bot by hand, the gyro angle changed the apprpriate amount. So I know the hardware is all hooked up correctly. BTW I’m using the ADXRS150EB.
I knew I was digging deep into the code because I was trying to figure out why the angle (as read by a printf statement of “heading” in cmd_turn() in robot.c) was only showing a -1 or a 0.
Could it have anything to do with the fact that in the stand-alone gyro code, you have us read the gyro every cycle in the fast loop i.e. Process_Gyro_Data() is in the fast loop as directed in gyro_readme.txt? In the FRC code, you only read the gyro “on demand”. They way I have it currently set up, it’s doing both - maybe I’m swamping the controller?
prograid,
Yes, You are right about the sharing issue. I checked my code and I’m declaring IO1 = INPUT in User_Initialization() in user_routines.c.
Manoel,
Thanks, I figured I was too liberal with the printf’s! The problem was present though before I put in the printf’s so I don’t think they are a cause. But you are right that maybe it’s not telling me the whole story…
Everyone,
I REALLY appreciate your time and effort!!!
Most, if not all, of my code will work with the Vex. I don’t really advertise it because Vex is more of a commercial enterprise and I’d rather spend my time supporting the FRC.
I remember that you had some problems with your encoders this past build season. Did you get the problem resolved and your 'bot working?
Yes, we had 4 encoders working flawlessly. I thought I had let you know last year! BTW, FIRST is helping to promote the VEX as a way for teams to
a) test the robotic waters
b) allow programming teams to develop code in parallel with the build phase
VEX is certainly cheaper than the Edubot. If it takes a commercial enterprise to help promote FIRST, then so be it!