EDU Mini Controller & 2005 Nav Code

[jaustin]

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.

1) 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.

2) 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?

Any advice would be appreciated! Thanks folks!

Jeff Austin
Mentor - Team 372

[Mark McLeod]

Originally Posted by jaustin

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).

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.

[Pat Fairbank]

Originally Posted by jaustin

I'm wondering if there is some inherant issue with either the EDU mini controller or the motors?

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.

[jaustin]

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).

Thanks guys for all your help!

Jeff

[Mark McLeod]

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.

The *.map file has four parts:
1) Section Info
2) Program Memory Usage
3) Symbols - Sorted by Name
4) Symbols - Sorted by Address

Section 2 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.

Section 4 shows the Data Space utilization that you want (ignore for now the Program Space – see column marked “location”). It 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.

-----------------
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.

[jaustin]

[quote=Mark McLeod]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.

Mark,
I've been using the .map file recently thanks to your help. I'm having another problem with my rc variable and when I try to look it up in the .map file (in the symbols-sorted by name) it's not even listed. Shouldn't it be there somewhere or am I looking in the wrong spot?

[Mark McLeod]

.map will only list variables with a fixed, permanent location. Those that are declared to be static or are declared within a project or header file, but outside any function.

The way rc is declared (within a function and not static -- int rc) means it doesn't persist between calls to that function, so it doesn't have a permanent location or home so to speak.
You'll also notice that rc is actually declared 14 or so times, but these are all really different variables, not the same one. By design the code happens to reuse the name just to make it easier for a reader to trace the data flow.

Not having a fixed "home" none of these variables will be explicitly called out in the link map, instead they are dynamically allocated only when the function is active. When the variable is required. When active it will get placed in whatever free data space is available, but the actual location will vary based on what other functions are also active at that particular time.
A chunk of Data space is reserved by the linker for these transient variables, but that space is shared by the transient variables of every function.

If you really want to see the dynamic location allocated for rc you can add a debug printf within the function to print the address of rc, e.g., printf(" rc address=%dr", &rc);

[jaustin]

Mark,
Thanks so much for the continued help! I'll try your suggesion. I know (I think I know) it's an overwrite issue because I can change the value of rc by adding or removing printf's like you mentioned in your previous post. I can't change it to zero or one like it is supposed to be, but rc either equals 10 or 24 depending on what printf's I use. I'll keep trying. Thanks again for your help!

[jaustin]

Mark,
Thanks again for your insight and patience! We are off and running again!

[jaustin]

Hi Guys,
I hope we are not "debugging the debug code" again, but here is the latest situation:

We are trying to modify Kevin's Nav Code (pid.c specifically) to allow a third motor (arm shoulder joint) to be pid controlled using a potentiometer for the feedback device. We have the adc stuff all worked so we are correctly reading the pot and the command.h and robot.c have been modified to include the commands and code for a third motor. But we are currently stuck at the point where robot.c calls the set_pos() function so that pid.c knows where to go. Robot.c is passing the correct motor number and command position to the set_pos function, but when set_pos() function goes to load it into the motor_info structure, the value changes. This change only occurs when we run a command for the third motor. When we use a CMD_DRIVE for example, pos and pos_cmd are always the same value but when we use our CMD_SHOULDER, pos = 760 (correct value) and pos_cmd = 25637.

Kevin's Code from pid.c:
void set_pos(int motor, long int pos) // pos = encoder counts or pot input)
// 256 = 1 rev
{
motor_info[motor].pid_mode = PID_POS;
motor_info[motor].pos_cmd = pos;
pid_time = 1; // Start over
}

Printing the output looks like this:
motor = 3 This is correct
pos = 760 This is correct
pos_cmd = 25637 Not sure what this is
pos_cmd & pos should be the same value

Any ideas?

[Mike Bortfeldt]

Jeff,

Looking at the base EDU PID code, the first two motors, LEFT & RIGHT are defined with values of 0 & 1. I would expect your new motor would have a value of 2 not 3. However, 3 should work fine as long as you've sized the motor_info array with a minimum value of 4. If this is not the problem, perhaps you could post your actual code. This may help isolate the issue.

Mike

[jaustin]

Mike,
You are right on! I defined our shoulder motor as 3 instead of 2. Thanks man, I knew a set of experienced eyes would catch the problem quickly! Now it's on to find the next problem!

Jeff

[Kevin Watson]

Originally Posted by jaustin

...The software compiles and runs but I'm having a few problems...

How many encoder ticks per second are you generating and how fast is the ADC sampling the gyro?

-Kevin

[jaustin]

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.

[Mike Bortfeldt]

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:

#pragma interruptlow InterruptHandlerLow save=PROD, section(".tmpdata"), section("MATH_DATA")

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