2006 CMUcam2 Code

[Kevin Watson]

As was mentioned during the kick-off, we have new-and-improved, country fresh CMUcam2 code this year. There are two versions available: The "bells and whistles" version contains interactive menu code that allows you to change, on-the-fly, the camera calibration and tracking parameters and save the configuration to EEPROM. And we also have the "streamlined" no nonsense version for the minimalist crowd. Both versions can be found here: http://kevin.org/frc. If you have questions or spot a bug in the code or documentation, please post it in this forum.

-Kevin

[CarpeDiem]

do you use the ifi loader to download the code to the cam via to the frc controller?

[Kingofl337]

You don't download the program to the camera.
You basically give it a string of commands and it responds.
You could hook it to a PC and run it with Hyperterm if you
wanted.

:)

[maniac_2040]

...If you have questions or spot a bug in the code or documentation, please post it in this forum.

-Kevin

Well I'm not sure if this is a bug that's happening with other teams, but our team (1216) has assembled our camera using the instructions provided on your site and also downloaded the most recent camera driver. The demo project that uses the camera driver keeps giving us a "Code error" (dreaded red light of death) at initialization of the controller. Only at initialization and not at a reset. When we upload and run the 2006 default code there are no errors. When we run our own code, using the serial port driver(but not the camera driver) we get the same "Code error" at initialization...is anyone else having similiar problems? This is using the 2006 controller. Thanks in advance.

[Kevin Watson]

If you recently downloaded the camera code, you may have noticed that it doesn't work. No, you're not going crazy, the code on my website was broken because the last time I built the code I forgot to change the baud rate on serial port two to the same baud rate the camera expects. To fix my gaff, open up serial_ports.c, and change line 450 to this: "SPBRG2 = BAUD_115200" and Line 452 to: "TXSTA2bits.BRGH = 1". Sorry 'bout the hassle and yes, Kevin is a doofus.

-Kevin

[billbo911]

If you recently downloaded the camera code, you may have noticed that it doesn't work. No, you're not going crazy, the code on my website was broken because the last time I built the code I forgot to change the baud rate on serial port two to the same baud rate the camera expects. To fix my gaff, open up serial_ports.c, and change line 450 to this: "SPBRG2 = BAUD_115200" and Line 452 to: "TXSTA2bits.BRGH = 1". Sorry 'bout the hassle and yes, Kevin is a doofus.

-Kevin
I just checked the version I have. Those lines already have the correct values, although they were on lines 448 and 450 respectively. have multiple versions of this code been posted on your site in the last couple of days? I think I got mine on 1/8/2006.

[Kevin Watson]

I just checked the version I have. Those lines already have the correct values, although they were on lines 448 and 450 respectively. have multiple versions of this code been posted on your site in the last couple of days? I think I got mine on 1/8/2006.No, there was just a window where the code was messed up. I rebuilt the code after making a few comment changes to the serial port code and a tweak to the #pragma interruptlow line in user_routines_fast.c, but forgot to change serial port two's baud rate to the correct baud rate.

-Kevin

[X-Istence]

This is a diff between the two versions I had available in my repo, so that I could patch my current working sources. I don't gaurantee it working, but it is a straight up diff between the old and the new:

diff -urNp -x *FRC* -x .svn* -x *.lkr -x *.hex ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/ifi_utilities.c ./ifi_utilities.c
--- ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/ifi_utilities.c Thu Jan 12 05:56:02 2006
+++ ./ifi_utilities.c Wed Jan 4 16:33:12 2006
@@ -27,7 +27,6 @@

int ifi_packet_num1 = 0;
int ifi_last_packet1 = 0;
-char ifi_printfBufr[80];
unsigned char *ptr;
unsigned char ifi_count;
unsigned char ifi_analog_channels;
@@ -88,33 +87,6 @@ void PrintWord(unsigned int odata)
TXREG = 13; /* add a carriage return */
Wait4TXEmpty();
}
-
-
-/************************************************** *****************************
-* FUNCTION NAME: PrintString
-* PURPOSE: Prints a string to the serial port.
-* CALLED FROM: anywhere
-* ARGUMENTS: none
-* Argument Type IO Description
-* -------- ------------- -- -----------
-* bufr pointer I word of data to be transmitted
-* RETURNS: void
-************************************************** *****************************/
-void PrintString(char *bufr)
-{
- static int len,I;
-
- strcpypgm2ram (ifi_printfBufr,(rom char *) bufr); /*Move from flash to ram*/
- len = (int) strlen((const char *)ifi_printfBufr);
- if (len > 80) len = 80;
-
- for (I=0;I<len;I++)
- {
- TXREG = ifi_printfBufr[I];
- Wait4TXEmpty();
- }
-}
-

/************************************************** *****************************
* FUNCTION NAME: DisplayBufr
diff -urNp -x *FRC* -x .svn* -x *.lkr -x *.hex ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/ifi_utilities.h ./ifi_utilities.h
--- ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/ifi_utilities.h Thu Jan 12 05:56:02 2006
+++ ./ifi_utilities.h Wed Jan 4 16:33:46 2006
@@ -74,7 +74,6 @@ void Generate_Pwms(unsigned char pwm_1,u
void Wait4TXEmpty(void);
void PrintByte(unsigned char odata);
void PrintWord(unsigned int odata);
-void PrintString(char *bufr);
void DisplayBufr(unsigned char *bufr);
void PacketNum_Check(void);
void Initialize_Serial_Comms (void);
diff -urNp -x *FRC* -x .svn* -x *.lkr -x *.hex ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/readme.txt ./readme.txt
--- ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/readme.txt Wed Dec 31 19:00:00 1969
+++ ./readme.txt Mon Oct 10 14:26:42 2005
@@ -0,0 +1,65 @@
+This directory contains the default code for the Innovation First 2006 Full-size Robot Controller.
+
+To compile this code you must have Microchip's MPLAB IDE (v7.2) with their C18 compiler (v2.4) installed on your system.
+
+If you wish to restore your Full-size Robot Controller to the default functionality as shipped from the factory, use the IFI Loader application to download the FRC_default.hex file to your Robot Controller.
+
+CAUTION: Do not relocate this FrcCode directory very deep in your directory tree. This is because the Microchip compiler has a 64 character path/filename limit. We suggest placing it in a directory named C:\mcc18\Projects\
+
+Notes:
+Use FRC_library.lib (default) if you plan to use the Generate_Pwms() function. This uses Timer0 to synchronize any PWM outputs generated by the User processor to make sure they avoid any SPI interrupts.
+If you want to use Timer0 yourself, then you can replace FRC_library.lib with FRC_alltimers.lib in the project.
+
+
+www.InnovationFirst.com
+10/10/2005
+- Added a checksum to the breaker panel packet
+- now using <stdio.h>, compiler needs -nw=2066 to suppress warnings (under project->build options->project->MPLAB C18->Use Alternate Settings)
+- Note: when using a 'printf' use a '\r' rather than a '\n' with the C18 compiler (v2.4 or later)
+
+11/12/2004
+- Added user_SerialDrv.c - device driver for the uart
+- Added code to handle packets from the breaker panel
+
+2/26/2004
+- ifi_aliases.h
+ Changed "competition_mode" alias to "disabled_mode" to be more accurate.
+ Added comment explaining that this bit is 1 when the RC is disabled.
+- ifi_default.h
+ Corrected comment regarding "disabled" bit. This bit is 1 when disabled.
+
+2/24/2004
+- user_routines_fast.c
+ Added interrupt enable check to interrupt service routine to ensure that disabled interrupts are not serviced.
+ Also all PWM and Relay outputs are initialized to neutral when entering Autonomous. This fixes a problem where the last PWM values are remembered and stuck throughout Autonomous mode when switching from Disabled to Autonomous.
+- ifi_aliases.h
+ Added aliases for the CCP pins (PWM OUTPUTS 13-16).
+ These can be used as digital outputs (not inputs) when properly configured.
+- README.txt (this file)
+ Added recommended directory for code placement.
+
+
+2/18/2004
+- ifi_aliases.h
+ Swapped relayX_fwd and relayX_rev aliases.
+ Added a note that the REV/FWD labels on the Robot Controller are incorrect.
+- FRC_default.hex
+ Recompiled to reflect the correct relay behavior (swapped FWD/REV).
+
+2/10/2004
+- user_routines_fast.c
+ Added Generate_Pwms() function call to User_Autonomous_Code.
+- 18f8520user.lkr
+ Removed debug section of program memory. Now User code can go all the way up to 0x7FFF.
+- FRC_library.lib and FRC_alltimers.lib
+ Now configure TTL Serial Port (USART2) RX2 pin as an input by default.
+
+1/29/2004
+- user_routines.c
+ Corrected Limit Switch section by removing NOT (!) from inputs.
+- ifi_aliases.h
+ Corrected User_Byte1 and User_Byte2 aliases.
+ Added TTL Serial Port aliases.
+
+1/8/2004
+- Initial Release
diff -urNp -x *FRC* -x .svn* -x *.lkr -x *.hex ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/serial_ports.c ./serial_ports.c
--- ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/serial_ports.c Thu Jan 12 05:56:02 2006
+++ ./serial_ports.c Wed Jan 11 22:10:44 2006
@@ -4,7 +4,7 @@
*
* VERSION: 0.4 (Beta)
*
-* DATE: 05-Jan-2006
+* DATE: 10-Jan-2006
*
* AUTHOR: R. Kevin Watson
* kevinw@jpl.nasa.gov
@@ -144,6 +144,8 @@
* 05-Feb-2005 0.3 RKW - Added _user_putc() interface to C18's new output
* stream capabilities. Updated documentation.
* 05-Jan-2006 0.4 RKW - Partial port to 18F8722. Updated documentation.
+* 10-Jan-2006 0.4 RKW - Modified the #pragma interruptlow line to also
+* save the .tmpdata section.
*
************************************************** *****************************/
#include <p18f8722.h>
diff -urNp -x *FRC* -x .svn* -x *.lkr -x *.hex ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/serial_ports.h ./serial_ports.h
--- ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/serial_ports.h Thu Jan 12 05:56:02 2006
+++ ./serial_ports.h Tue Jan 10 21:22:08 2006
@@ -4,7 +4,7 @@
*
* VERSION: 0.4 (Beta)
*
-* DATE: 05-Jan-2006
+* DATE: 10-Jan-2006
*
* AUTHOR: R. Kevin Watson
* kevinw@jpl.nasa.gov
@@ -29,6 +29,8 @@
* 05-Feb-2005 0.3 RKW - Added _user_putc() interface to C18's new output
* stream capabilities. Updated documentation.
* 05-Jan-2006 0.4 RKW - Partial port to 18F8722. Updated documentation.
+* 10-Jan-2006 0.4 RKW - Modified the #pragma interruptlow line to also
+* save the .tmpdata section.
*
************************************************** *****************************/
#ifndef _SERIAL_PORTS_H
diff -urNp -x *FRC* -x .svn* -x *.lkr -x *.hex ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/serial_ports_readme.txt ./serial_ports_readme.txt
--- ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/serial_ports_readme.txt Thu Jan 12 05:56:02 2006
+++ ./serial_ports_readme.txt Tue Jan 10 21:17:20 2006
@@ -16,9 +16,10 @@ on-board serial ports. This software is
designed to work with the output stream functions included
with Microchip's C18 C compiler version 2.4

-The source code in serial_ports.c/.h will work with the
-Robovation (A/K/A EDU-RC) robot controller and the FIRST
-Robotics robot controller without modification.
+This source code will work with the PIC18F8520-based FIRST
+Robotics robot controller, the PIC18F8722-based FIRST Robotics
+robot controller, and the Robovation (A/K/A EDU-RC) robot
+controller.

Because you can now easily receive data from another computer,
you can interact with your nifty IFI robot controller in real-
@@ -137,7 +138,7 @@ correctly:
1a) FRC-RC: As this software is intended to replace IFI's
serial port driver, the call to Serial_Driver_Initialize()
in user_routines.c / User_Initialization() should be
- removed or commented out. In addition, all references to
+ removed or commented out. In addition, all references to
"user_Serialdrv.c" and "user_Serialdrv.h" must be removed
from the project and all project source files.

@@ -211,7 +212,7 @@ correctly:
This serial port driver can send output stream data to either
of the serial ports by setting the value of the global variable
stdout_serial_port before calling output stream functions like
-printf(). Setting the value to "SERIAL_PORT_ONE" will send the
+printf(). Setting the value to "SERIAL_PORT_ONE" will send the
output to serial port one. Likewise, setting the value to
"SERIAL_PORT_TWO" will send the output to serial port two.
Setting the value to "NUL" will send the output to the null
diff -urNp -x *FRC* -x .svn* -x *.lkr -x *.hex ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/user_routines_fast.c ./user_routines_fast.c
--- ./../FIRST/tags/FRC-StandardCode-2006-[Kevin_Watson Camera]/user_routines_fast.c Thu Jan 12 05:56:02 2006
+++ ./user_routines_fast.c Tue Jan 10 21:47:04 2006
@@ -55,7 +55,7 @@ void InterruptVectorLow (void)
* RETURNS: void
************************************************** *****************************/
#pragma code
-#pragma interruptlow InterruptHandlerLow save=PROD /* You may want to save additional symbols. */
+#pragma interruptlow InterruptHandlerLow save=PROD,section(".tmpdata")

void InterruptHandlerLow ()
{

[maniac_2040]

If you recently downloaded the camera code, you may have noticed that it doesn't work. No, you're not going crazy, the code on my website was broken because the last time I built the code I forgot to change the baud rate on serial port two to the same baud rate the camera expects. To fix my gaff, open up serial_ports.c, and change line 450 to this: "SPBRG2 = BAUD_115200" and Line 452 to: "TXSTA2bits.BRGH = 1". Sorry 'bout the hassle and yes, Kevin is a doofus.

-Kevin

...Still doesn't work, even after making those changes. Not every single time, but often, there's a code error at initialization. Sometimes its more often than others, there's no real pattern as to how/when it comes, except that it only happens at the first power up(not a reset). Has the camera code been tested? It's not only the camera code though, it doesnt work even when I have the camera drive disabled. I turned off all of our software features except for the serial drive and I still get this 'random' code error....anyone else having this problem? :confused:

[Vashts6583]

look. i don't know jack squat on all of this, and i know this may not be the right thread to post this in, but I'm getting severely disappointed in my team in the fact that all they seem to be doing is yelling at each other and not being very smart about it. :mad: i don't mind the argument, but they're all being immature about it. :mad:

anyway, i have two questions regarding the camera and the sensor.

Question 1: I don't exactly understand how they want us to build a mock-up sensor target like the one they have on the field. I have the "instructions" (aka, the .pdf file), but I do not understand what the heck some of these pieces look like, how they're supposed to be connected to the base plate, etc. :confused:

Question 2: I like the fact that we have code, but what after calibrating the camera, what files would I need to add to the main workspace (MPLab IDE C18) that I am using for the robot?

Question 3 (ties in with question 2): Proving to the world the fact that I am a n00b programmer, how would I be able to re-program the code for the servos for another type of motor? I know that the code for servos differs from that of say a fisher price or a globe motor.

Any assistance is greatly appreciated, and please, pray for my sanity .. :(

[Joe Hershberger]

Question 2: I like the fact that we have code, but what after calibrating the camera, what files would I need to add to the main workspace (MPLab IDE C18) that I am using for the robot?

Well, it would appear that at first glance the "streamlined" version of the camera software will be the most useful for use on a live robot. In that code you'll find a header file called camera.h. It should contain a whole string of constants that configure the camera. You can use the LabView CMU camera app posted in this thread (http://www.chiefdelphi.com/forums/showthread.php?t=41214) to test the camera and figure out just what parameters you'de like to use. Then plug those numbers into the header file, and you should be good to go.

Question 3 (ties in with question 2): Proving to the world the fact that I am a n00b programmer, how would I be able to re-program the code for the servos for another type of motor? I know that the code for servos differs from that of say a fisher price or a globe motor.

As for replacing a servo with a different type of motor, that is a bit of a challenge. Servos have internal feedback which allows you to tell it to go to a particular position. You may notice that if you have a servo powered and you try to turn it, it fights back to keep the position the same. The servo just has a small motor inside, a controller, and a sensor for feedback. If you want a globe or fisher price motor to act like a servo, then you need those other two components. You can use a sensor like the Gear Tooth Sensor included in the kit as your feedback. For the controller, you can use the FRC and write software! The motor controllers that have available, (victors, and of less usefulness, the spikes) only control the speed of the motors, not the position. This is because they don't know where they are, and therefore don't know where to go from there (where?). Hopefully the servos will work for you, but if not, it's possible to use other motors instead. It's just a lot more work. If you decide you do need a controller and motors, do some research/googling for PID control. It's a pretty straight forward method of control that gives good results. There's probably even code floating around out there if you look hard enough.

Good luck!!

-Joe

[Cuog]

I have been using the camera_s downloaded from your site and i have a quick question as to how can i tell if the camera is searching for the green or if it is following it.

[Kevin Watson]

I have been using the camera_s downloaded from your site and i have a quick question as to how can i tell if the camera is searching for the green or if it is following it.If it's searching, the pan/tilt servos are swinging the camera around in the hope it can find the green thing. It also should say:

Searching...
Searching...
Searching...
Searching...
Searching...
...

on your terminal screen. If it's actively tracking, the camera will be pointed at the green thing, the little red LED on the camera should light up and you should be getting some statistics dumped onto your terminal screen.

-Kevin

[Cuog]

sorry i meant in code how do i tell, i am planning a function that needs to know if the camera has a target

[Kevin Watson]

sorry i meant in code how do i tell, i am planning a function that needs to know if the camera has a targetHave a look at the code in terminal.c. Also keep in mind that just because the camera sees the green light doesn't necessarily mean it's pointed at it. The answer to this dilemma is also in terminal.c.

-Kevin

[Cuog]

k thanks time to search,
Cuog

[Makubesu]

My team is having some problems using the camera code. When we used the code that came with the controller, we were able to get the LEDs to light up for y movement on the joystick, as well as the trigger and thumb button. When we loaded on the camera code, though, none of those did anything. We loaded on the default code provided at IFI's website, and that fixed things, but we can't use the camera with just that code. Any idea what we're doing wrong? The user_routines.c files look the same, so I don't understand why the joystick wouldn't work.

[Cuog]

in the method: Proccess_Data_From_Master_uP(), make a call to Default_Routine, then in Default_Routine comment out the pwm assignment for pwm01 and 02 and you're good to go, i spent all day trying to fix this and hit my head against the wall when i got it.

[Makubesu]

in the method: Proccess_Data_From_Master_uP(), make a call to Default_Routine, then in Default_Routine comment out the pwm assignment for pwm01 and 02 and you're good to go, i spent all day trying to fix this and hit my head against the wall when i got it.
Oh, I see, the call to Default_Routine is actually commented out in the camera code. Why do I need to comment out the assignments for pwm01 and 02 in default routine though?

[X-Istence]

Oh, I see, the call to Default_Routine is actually commented out in the camera code. Why do I need to comment out the assignments for pwm01 and 02 in default routine though?

Because those are standard used for the servo's, and last I checked it was not desirable for the servo's to be changed in position by the robot controller.

[iBheat]

Because those are standard used for the servo's, and last I checked it was not desirable for the servo's to be changed in position by the robot controller.

If by that you mean the PWM outputs for camera servos (pan and tilt) cannot be changed then you are incorrect if you look in tracking.h you see

// By default, PWM output one is used for the pan servo.
// Change it to another value if you'd like to use PWM
// output one for another purpose.
#define PAN_SERVO pwm01

// By default, PWM output two is used for the tilt servo.
// Change it to another value if you'd like to use PWM
// output two for another purpose.
#define TILT_SERVO pwm02

That defines which PWM output is used!

[Windward]

I don't know if this has been answered in one of the above posts or somewhere, but does the camera code (the one for MPLab) interfere with other code that we programmers add in? I can't get any of my personal code, including printfs, to work even though all the camera code works perfectly fine, including printfs. Is there something I'm supposed to edit before I can edit the default code and have it work?

[Alan Anderson]

The call to Default_Routine() is commented out in the camera code. If that's where you're putting your own programming, you now know why it doesn't seem to be doing anything. :)

Uncomment it and your code should run.

[aaeamdar]

Clean: Deleting intermediary and output files.
Clean: Deleted file "G:\Default Code\main.o".
Clean: Deleted file "G:\Default Code\user_routines.o".
Clean: Deleted file "G:\Default Code\user_routines_fast.o".
Clean: Deleted file "G:\Default Code\user_SerialDrv.o".
Clean: Deleted file "G:\Default Code\ifi_startup.o".
Clean: Deleted file "G:\Default Code\ifi_utilities.o".
Clean: Deleted file "G:\Default Code\camera.o".
Clean: Deleted file "G:\Default Code\serial_ports.o".
Clean: Deleted file "G:\Default Code\tracking.o".
Clean: Done.
Executing: "c:\mcc18\bin\mcc18.exe" -p=18F8722 "main.c" -fo="main.o" /i"C:\mcc18\h" -D_FRC_BOARD -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa- -nw=2066
Executing: "c:\mcc18\bin\mcc18.exe" -p=18F8722 "user_routines.c" -fo="user_routines.o" /i"C:\mcc18\h" -D_FRC_BOARD -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa- -nw=2066
G:\Default Code\user_routines.c:252:Warning [2058] call of function without prototype
G:\Default Code\user_routines.c:260:Warning [2058] call of function without prototype
Executing: "c:\mcc18\bin\mcc18.exe" -p=18F8722 "user_routines_fast.c" -fo="user_routines_fast.o" /i"C:\mcc18\h" -D_FRC_BOARD -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa- -nw=2066
Executing: "c:\mcc18\bin\mcc18.exe" -p=18F8722 "user_SerialDrv.c" -fo="user_SerialDrv.o" /i"C:\mcc18\h" -D_FRC_BOARD -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa- -nw=2066
Executing: "c:\mcc18\bin\mcc18.exe" -p=18F8722 "ifi_startup.c" -fo="ifi_startup.o" /i"C:\mcc18\h" -D_FRC_BOARD -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa- -nw=2066
Executing: "c:\mcc18\bin\mcc18.exe" -p=18F8722 "ifi_utilities.c" -fo="ifi_utilities.o" /i"C:\mcc18\h" -D_FRC_BOARD -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa- -nw=2066
Executing: "c:\mcc18\bin\mcc18.exe" -p=18F8722 "camera.c" -fo="camera.o" /i"C:\mcc18\h" -D_FRC_BOARD -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa- -nw=2066
Executing: "c:\mcc18\bin\mcc18.exe" -p=18F8722 "serial_ports.c" -fo="serial_ports.o" /i"C:\mcc18\h" -D_FRC_BOARD -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa- -nw=2066
Executing: "c:\mcc18\bin\mcc18.exe" -p=18F8722 "tracking.c" -fo="tracking.o" /i"C:\mcc18\h" -D_FRC_BOARD -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa- -nw=2066
Executing: "C:\Program Files\Microchip\MPASM Suite\MPLink.exe" /l"C:\mcc18\lib" "18f8722.lkr" "G:\Default Code\main.o" "G:\Default Code\user_routines.o" "G:\Default Code\user_routines_fast.o" "G:\Default Code\user_SerialDrv.o" "G:\Default Code\ifi_startup.o" "G:\Default Code\ifi_utilities.o" "G:\Default Code\camera.o" "G:\Default Code\serial_ports.o" "G:\Default Code\tracking.o" "G:\Default Code\FRC_library.lib" /o"FrcCode.cof"
MPLINK 3.94, Linker
Copyright (c) 2005 Microchip Technology Inc.
Error - section '.udata_user_routines.o' can not fit the section. Section '.udata_user_routines.o' length=0x00000103
Errors : 1



This code gives us the above error. Some insight: hex 103 is just above 256. Are we exceeding some miserly value of MPLAB?

Thanks, I hope I'm not repeating someone.

[Kevin Watson]

This code gives us the above error. Some insight: hex 103 is just above 256. Are we exceeding some miserly value of MPLAB?

Thanks, I hope I'm not repeating someone.Try removing user_SerialDrv.c/.h from your project.

-Kevin

[aaeamdar]

Try removing user_SerialDrv.c/.h from your project.

-Kevin

This worked to fix the error, and I was about to throw a Jubilee Feast when it gave me a different error, about Breaker_Tripped:


MPLINK 3.94, Linker
Copyright (c) 2005 Microchip Technology Inc.
Error - could not find definition of symbol 'Breaker_Tripped' in file 'G:\Default Code\user_routines.o'.
Errors : 1


That's fine, I fixed that (essentially commented it out), and then, BOOM I got the same error again:


MPLINK 3.94, Linker
Copyright (c) 2005 Microchip Technology Inc.
Error - section '.udata_user_routines.o' can not fit the section. Section '.udata_user_routines.o' length=0x00000103
Errors : 1


=(

I HATE MP BLOB

[Kevin Watson]

This worked to fix the error, and I was about to throw a Jubilee Feast when it gave me a different error, about Breaker_Tripped:


MPLINK 3.94, Linker
Copyright (c) 2005 Microchip Technology Inc.
Error - could not find definition of symbol 'Breaker_Tripped' in file 'G:\Default Code\user_routines.o'.
Errors : 1


That's fine, I fixed that (essentially commented it out), and then, BOOM I got the same error again:


MPLINK 3.94, Linker
Copyright (c) 2005 Microchip Technology Inc.
Error - section '.udata_user_routines.o' can not fit the section. Section '.udata_user_routines.o' length=0x00000103
Errors : 1


=(

I HATE MP BLOBPost the .map file.

-Kevin

[aaeamdar]

Post the .map file.

-Kevin


What is the .map file and where can I find it?

Thanks,
Paul

[Kevin Watson]

What is the .map file and where can I find it?

Thanks,
PaulIt should be in your build directory. If not, go to Project -> Build Options... -> Project -> MPLINK Linker tab -> Check "Generate map file" check box and then build all. The <project name>.map should now be in the build directory.

-Kevin

[aaeamdar]

MPLINK 3.94, Linker
Linker Error Map File - Created Sun Jan 22 18:39:54 2006

*Warning* - This is only a partial map file due to a link time error.
Only sections which were allocated prior to the error are shown below.

CODEPAGES:
Memory Start End Section Address Size(Bytes)
--------- --------- --------- --------- --------- ---------
vectors 0x0000 0x07ff

page 0x0800 0xffff _entry_scn 0x0800 0x0006
InterruptVectorHigh 0x0808 0x0006
InterruptVectorLow 0x0818 0x0006
.cinit 0x081e 0x004a
.code_user_routines.o 0x0868 0x1270
.code_vfprintf.o 0x1ad8 0x0c22
.code_pow.o 0x26fa 0x0b2e
.code_ifi_library.o 0x3228 0x0722
PROG 0x394a 0x06a2
.code_camera.o 0x3fec 0x0634
.code_exp.o 0x4620 0x05c2
.code_log.o 0x4be2 0x04f6
.code_tracking.o 0x50d8 0x0408
UTIL_LIB 0x54e0 0x0396
.code_fchop.o 0x5876 0x028e
.code_ifi_utilities.o 0x5b04 0x01de
.code_serial_ports.o 0x5ce2 0x0188
.code_user_routines_fast.o 0x5e6a 0x015a
.code_ldexp.o 0x5fc4 0x0134
.code_frexp.o 0x60f8 0x0120
.code_UnpkMath.o 0x6218 0x011c
.code_PackMath.o 0x6334 0x011a

idlocs 0x0000 0x0007

config 0x0000 0x000d

devid 0xfffe 0xffff

eedata 0x0000 0x03ff


SHAREBANKS:

DATABANKS:
Memory Start End Section Address Size(Bytes)
--------- --------- --------- --------- --------- ---------
gpr0 0x0060 0x00ff COPY_VAR 0x0080 0x0080

gpr1 0x0100 0x01ff

gpr2 0x0200 0x02ff

gpr3 0x0300 0x03ff

gpr4 0x0400 0x04ff

gpr5 0x0500 0x05ff

gpr6 0x0600 0x06ff

gpr7 0x0700 0x07ff

gpr8 0x0800 0x08ff

gpr9 0x0900 0x09ff

gpr10 0x0a00 0x0aff

gpr11 0x0b00 0x0bff

gpr12 0x0c00 0x0cff

gpr13 0x0d00 0x0dff

gpr14 0x0e00 0x0eff .stack 0x0e00 0x0100

gpr15 0x0f00 0x0f5f


ACCESSBANKS:
Memory Start End Section Address Size(Bytes)
--------- --------- --------- --------- --------- ---------
accessram 0x0000 0x005f

accesssfr 0x0f60 0x0fff SFR_UNBANKED0 0x0f62 0x009e



Here it is.

Thanks

[aaeamdar]

user_routines seems to be the largest so anticipating a request for it here it is:


/************************************************** *****************************
* FILE NAME: user_routines.c <FRC VERSION>
*
* DESCRIPTION:
* This file contains the default mappings of inputs
* (like switches, joysticks, and buttons) to outputs on the RC.
*
* USAGE:
* You can either modify this file to fit your needs, or remove it from your
* project and replace it with a modified copy.
*
************************************************** *****************************/

#include <stdio.h>
#include <math.h>

#include "ifi_aliases.h"
#include "ifi_default.h"
#include "ifi_utilities.h"
#include "user_routines.h"
#ifndef _CAMERA
#endif
#ifdef _CAMERA
#include "camera.h"
#include "serial_ports.h"
#endif
#define round(x) ( (int)((x < 127) * (x - .5) + (x > 127) * (x + .5)) )


extern unsigned char aBreakerWasTripped;
extern T_Packet_Data_Type camera;
unsigned char lookTable [255];
unsigned char c = 0;

/*** DEFINE USER VARIABLES AND INITIALIZE THEM HERE ***/
/* EXAMPLES: (see MPLAB C18 User's Guide, p.9 for all types)
unsigned char wheel_revolutions = 0; (can vary from 0 to 255)
unsigned int delay_count = 7; (can vary from 0 to 65,535)
int angle_deviation = 142; (can vary from -32,768 to 32,767)
unsigned long very_big_counter = 0; (can vary from 0 to 4,294,967,295) 32-bit storage, PAUL D
*/

/************************************************** *****************************
* FUNCTION NAME: Limit_Switch_Max
* PURPOSE: Sets a PWM value to neutral (127) if it exceeds 127 and the
* limit switch is on.
* CALLED FROM: this file
* ARGUMENTS:
* Argument Type IO Description
* -------- ------------- -- -----------
* switch_state unsigned char I limit switch state
* *input_value pointer O points to PWM byte value to be limited
* RETURNS: void
************************************************** *****************************/
void Limit_Switch_Max(unsigned char switch_state, unsigned char *input_value)
{
if (switch_state == CLOSED)
{
if(*input_value > 127)
*input_value = 127;
}
}


/************************************************** *****************************
* FUNCTION NAME: Limit_Switch_Min
* PURPOSE: Sets a PWM value to neutral (127) if it's less than 127 and the
* limit switch is on.
* CALLED FROM: this file
* ARGUMENTS:
* Argument Type IO Description
* -------- ------------- -- -----------
* switch_state unsigned char I limit switch state
* *input_value pointer O points to PWM byte value to be limited
* RETURNS: void
************************************************** *****************************/
void Limit_Switch_Min(unsigned char switch_state, unsigned char *input_value)
{
if (switch_state == CLOSED)
{
if(*input_value < 127)
*input_value = 127;
}
}


/************************************************** *****************************
* FUNCTION NAME: Limit_Mix
* PURPOSE: Limits the mixed value for one joystick drive.
* CALLED FROM: Default_Routine, this file
* ARGUMENTS:
* Argument Type IO Description
* -------- ---- -- -----------
* intermediate_value int I
* RETURNS: unsigned char
************************************************** *****************************/
unsigned char Limit_Mix (int intermediate_value)
{
static int limited_value;

if (intermediate_value < 2000)
{
limited_value = 2000;
}
else if (intermediate_value > 2254)
{
limited_value = 2254;
}
else
{
limited_value = intermediate_value;
}
return (unsigned char) (limited_value - 2000);
}


/************************************************** *****************************
* FUNCTION NAME: User_Initialization
* PURPOSE: This routine is called first (and only once) in the Main function.
* You may modify and add to this function.
* CALLED FROM: main.c
* ARGUMENTS: none
* RETURNS: void
************************************************** *****************************/
void User_Initialization (void)
{
Set_Number_of_Analog_Channels(SIXTEEN_ANALOG); /* DO NOT CHANGE! */

/* FIRST: Set up the I/O pins you want to use as digital INPUTS. */
digital_io_01 = digital_io_02 = digital_io_03 = digital_io_04 = INPUT;
digital_io_05 = digital_io_06 = digital_io_07 = digital_io_08 = INPUT;
digital_io_09 = digital_io_10 = digital_io_11 = digital_io_12 = INPUT;
digital_io_13 = digital_io_14 = digital_io_15 = digital_io_16 = INPUT;
digital_io_18 = INPUT; /* Used for pneumatic pressure switch. */
/*
Note: digital_io_01 = digital_io_02 = ... digital_io_04 = INPUT;
is the same as the following:

digital_io_01 = INPUT;
digital_io_02 = INPUT;
...
digital_io_04 = INPUT;
*/
#ifdef _CAMERA
#ifdef TERMINAL_SERIAL_PORT_1
stdout_serial_port = SERIAL_PORT_ONE;
#endif

#ifdef TERMINAL_SERIAL_PORT_2
stdout_serial_port = SERIAL_PORT_TWO;
#endif
#endif

/* SECOND: Set up the I/O pins you want to use as digital OUTPUTS. */
digital_io_17 = OUTPUT; /* Example - Not used in Default Code. */

/* THIRD: Initialize the values on the digital outputs. */
rc_dig_out17 = 0;

/* FOURTH: Set your initial PWM values. Neutral is 127. */
pwm01 = pwm02 = pwm03 = pwm04 = pwm05 = pwm06 = pwm07 = pwm08 = 127;
pwm09 = pwm10 = pwm11 = pwm12 = pwm13 = pwm14 = pwm15 = pwm16 = 127;

/* FIFTH: Set your PWM output types for PWM OUTPUTS 13-16.
/* Choose from these parameters for PWM 13-16 respectively: */
/* IFI_PWM - Standard IFI PWM output generated with Generate_Pwms(...) */
/* USER_CCP - User can use PWM pin as digital I/O or CCP pin. */
Setup_PWM_Output_Type(IFI_PWM,IFI_PWM,IFI_PWM,IFI_ PWM);

/*
Example: The following would generate a 40KHz PWM with a 50% duty cycle on the CCP2 pin:

CCP2CON = 0x3C;
PR2 = 0xF9;
CCPR2L = 0x7F;
T2CON = 0;
T2CONbits.TMR2ON = 1;

Setup_PWM_Output_Type(USER_CCP,IFI_PWM,IFI_PWM,IFI _PWM);
*/

/* Add any other initialization code here. */
#ifdef _CAMERA
Init_Serial_Port_Two();

#define stdout_serial_port SERIAL_PORT_ONE
Track_Color(GREEN);
#endif
for (c = 0; c < STOP; c++)
{
lookTable[c] = 254 - round( (pow( (c-STOP)/STOP, GENTLE_EXP ) + STOP) );
}
for (c = STOP; c < 255; c++)
{
lookTable[c] = round( (pow( (c-STOP)/STOP, GENTLE_EXP ) + STOP) );
}

Putdata(&txdata); /* DO NOT CHANGE! */

#ifndef _CAMERA
Serial_Driver_Initialize();
#endif

printf("IFI 2006 User Processor Initialized ...\r"); /* Optional - Print initialization message. */

User_Proc_Is_Ready(); /* DO NOT CHANGE! - last line of User_Initialization */
}

/************************************************** *****************************
* FUNCTION NAME: Process_Data_From_Master_uP
* PURPOSE: Executes every 26.2ms when it gets new data from the master
* microprocessor.
* CALLED FROM: main.c
* ARGUMENTS: none
* RETURNS: void
************************************************** *****************************/
static unsigned char COUNTERFORDISPLAY;
void Process_Data_From_Master_uP(void)
{
static unsigned char i;

Getdata(&rxdata); /* Get fresh data from the master microprocessor. */

Default_Routine(); /* Optional. See below. */

/* Add your own code here. (a printf will not be displayed when connected to the breaker panel unless a Y cable is used) */
COUNTERFORDISPLAY++;
if(COUNTERFORDISPLAY>=38)
{
COUNTERFORDISPLAY=0;
printf("Port1 Y %3d, X %3d, Fire %d, Top %d\r",pwm01,pwm05,p1_sw_trig,p1_sw_top); /* printf EXAMPLE */
printf("Port2 Y %3d, X %3d, Fire %d, Top %d\r",pwm02,pwm06,p2_sw_trig,p2_sw_top); /* printf EXAMPLE */
}

Generate_Pwms(pwm13,pwm14,pwm15,pwm16);

/* Example code to check if a breaker was ever tripped. */
#ifndef _CAMERA
if (aBreakerWasTripped)
{
for (i=1;i<29;i++)
{
if (Breaker_Tripped(i))
User_Byte1 = i; /* Update the last breaker tripped on User_Byte1 (to demonstrate the use of a user byte)
Normally, you do something else if a breaker got tripped (ex: limit a PWM output) */
}
}
#endif

#ifdef _CAMERA
Camera_Handler();
Servo_Track();
#endif

Putdata(&txdata); /* DO NOT CHANGE! */
}

/************************************************** *****************************
* FUNCTION NAME: Default_Routine
* PURPOSE: Performs the default mappings of inputs to outputs for the
* Robot Controller.
* CALLED FROM: this file, Process_Data_From_Master_uP routine
* ARGUMENTS: none
* RETURNS: void
************************************************** *****************************/
void Default_Routine(void)
{

/*---------- Analog Inputs (Joysticks) to PWM Outputs-----------------------
*--------------------------------------------------------------------------
* This maps the joystick axes to specific PWM outputs.
*/
#if 1 // new version, does it work? 1/20/06
if (p1_y > STOP) // Going fwd
{ if (DIFF < 0) // Going left
LEFT_MOTOR = Limit_Mix(2000 + p1_y + DIFF);
else if (DIFF > 0) // Going right
RIGHT_MOTOR = Limit_Mix(2000 + p1_y - DIFF);
}
else if (p1_y < STOP) // Going bwd
{ if (DIFF < 0) // Going left
LEFT_MOTOR = Limit_Mix(2000 + p1_y - DIFF);
else if (DIFF > 0) // Going right
RIGHT_MOTOR = Limit_Mix(2000 + p1_y + DIFF);
}
else // if stopped
{
LEFT_MOTOR = Limit_Mix(2000 + DIFF);
RIGHT_MOTOR = Limit_Mix(2000 - DIFF);
}
#endif
#if 0 // two joystick drive, left front-back right steering
// p1_y = squareSteer(p1_y);
// p2_x = squareSteer(p2_x);

if(p1_y <= 127+DEAD_ZONE && p1_y >= 127-DEAD_ZONE) //if p1_y in dead zone
{ LEFT_MOTOR = STOP;
RIGHT_MOTOR = STOP;
}
else
{ LEFT_MOTOR = p1_y;
RIGHT_MOTOR = p1_y;
}
printf("Motor 1: %d Motor 2: %d ", LEFT_MOTOR, RIGHT_MOTOR);
printf("Left joy: %d R Joy: %d ", p1_y, p2_x);
if (!(p2_x <= STOP+DEAD_ZONE && p2_x >= STOP-DEAD_ZONE)) // if p2_x not in dead zone
{
if (p2_x > STOP+DEAD_ZONE) //if >than dead zone fwd
{
if (LEFT_MOTOR + (p2_x - STOP) /STEER_FACTOR_FAST > FULL_FWD) // prevents overloading
LEFT_MOTOR = FULL_FWD; // if over 254, 254
else
LEFT_MOTOR += (p2_x - STOP) /STEER_FACTOR_FAST;
if (RIGHT_MOTOR - (p2_x - STOP) / STEER_FACTOR_SLOW < FULL_BWD) // prevents overloading
RIGHT_MOTOR = FULL_BWD; // if below 0, 0
else
RIGHT_MOTOR -= (p2_x - STOP) / STEER_FACTOR_SLOW;
} // end >than dead zone fwd
if (p2_x < STOP-DEAD_ZONE)
{
if (LEFT_MOTOR - (p2_x - STOP) / STEER_FACTOR_SLOW < 0) // prevents overloading
LEFT_MOTOR = FULL_BWD;
else
LEFT_MOTOR -= (p2_x - STOP) /STEER_FACTOR_SLOW;
if (RIGHT_MOTOR + (p2_x - STOP) /STEER_FACTOR_FAST > FULL_FWD) // prevents overloading
RIGHT_MOTOR = FULL_FWD;
else
RIGHT_MOTOR += (p2_x - STOP) /STEER_FACTOR_FAST;
}
}
printf("After: Motor 1: %d Motor 2: %d\n", LEFT_MOTOR, RIGHT_MOTOR);
#endif

#if _TANK_DRIVE // if we want tank drive
if(p1_y <= 127+DEAD_ZONE && p1_y >= 127-DEAD_ZONE)
LEFT_MOTOR = 127;
else
LEFT_MOTOR = p1_y;
if(p2_y <= 127+DEAD_ZONE && p2_y >= 127-DEAD_ZONE)
RIGHT_MOTOR = STOP;
else
RIGHT_MOTOR = p2_y;
#endif // end tank drive
#if _BUTTON_FUN // if we want to have one joystick drive with trig

if (p1_sw_aux1)//Joystick 1 left aux button
LEFT_MOTOR = STOP; //STOP motor 1
if (p2_sw_aux1) //Joystick 2 right aux button
RIGHT_MOTOR = STOP; //STOP motor 2

#endif //end trigger one joystick drive

/*if(p3_y <= 127+DEAD_ZONE && p3_y >= 127-DEAD_ZONE)
pwm03 = STOP;
else
pwm03 = p3_y;
if(p4_y <= STOP+DEAD_ZONE && p4_y >= STOP-DEAD_ZONE)
pwm04 = STOP;
else
pwm04 = p4_y;
if(p1_x <= STOP+DEAD_ZONE && p1_x >= STOP-DEAD_ZONE)
pwm05 = STOP;
else
pwm05 = p1_x;
if(p2_x <= STOP+DEAD_ZONE && p2_x >= STOP-DEAD_ZONE)
pwm06 = STOP;
else
pwm06 = p2_x;
if(p3_x <= STOP+DEAD_ZONE && p3_x >= STOP-DEAD_ZONE)
pwm07 = STOP;
else
pwm07 = p3_x;
if(p4_x <= STOP+DEAD_ZONE && p4_x >= STOP-DEAD_ZONE)
pwm08 = STOP;
else
pwm08 = p4_x;
pwm09 = p1_wheel;
pwm10 = p2_wheel;
pwm11 = p3_wheel;
pwm12 = p4_wheel;
*/
/*---------- 1 Joystick Drive ----------------------------------------------
*--------------------------------------------------------------------------
* This code mixes the Y and X axis on Port 1 to allow one joystick drive.
* Joystick forward = Robot forward
* Joystick backward = Robot backward
* Joystick right = Robot rotates right
* Joystick left = Robot rotates left
* Connect the right drive motors to PWM13 and/or PWM14 on the RC.
* Connect the left drive motors to PWM15 and/or PWM16 on the RC.
*/
pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127);
pwm15 = pwm16 = Limit_Mix(2000 + p1_y - p1_x + 127);

/*---------- Buttons to Relays----------------------------------------------
*--------------------------------------------------------------------------
* This default code maps the joystick buttons to specific relay outputs.
* Relays 1 and 2 use limit switches to stop the movement in one direction.
* The & used below is the C symbol for AND
*/
relay1_fwd = p1_sw_trig & rc_dig_in01; /* FWD only if switch1 is not closed. */
relay1_rev = p1_sw_top & rc_dig_in02; /* REV only if switch2 is not closed. */
relay2_fwd = p2_sw_trig & rc_dig_in03; /* FWD only if switch3 is not closed. */
relay2_rev = p2_sw_top & rc_dig_in04; /* REV only if switch4 is not closed. */
relay3_fwd = p3_sw_trig;
relay3_rev = p3_sw_top;
relay4_fwd = p4_sw_trig;
relay4_rev = p4_sw_top;
relay5_fwd = p1_sw_aux1;
relay5_rev = p1_sw_aux2;
relay6_fwd = p3_sw_aux1;
relay6_rev = p3_sw_aux2;
relay7_fwd = p4_sw_aux1;
relay7_rev = p4_sw_aux2;
relay8_fwd = !rc_dig_in18; /* Power pump only if pressure switch is off. */
relay8_rev = 0;

/*---------- PWM outputs Limited by Limit Switches ------------------------*/

Limit_Switch_Max(rc_dig_in05, &pwm03);
Limit_Switch_Min(rc_dig_in06, &pwm03);
Limit_Switch_Max(rc_dig_in07, &pwm04);
Limit_Switch_Min(rc_dig_in08, &pwm04);
Limit_Switch_Max(rc_dig_in09, &pwm09);
Limit_Switch_Min(rc_dig_in10, &pwm09);
Limit_Switch_Max(rc_dig_in11, &pwm10);
Limit_Switch_Min(rc_dig_in12, &pwm10);
Limit_Switch_Max(rc_dig_in13, &pwm11);
Limit_Switch_Min(rc_dig_in14, &pwm11);
Limit_Switch_Max(rc_dig_in15, &pwm12);
Limit_Switch_Min(rc_dig_in16, &pwm12);

/*---------- ROBOT FEEDBACK LEDs------------------------------------------------
*------------------------------------------------------------------------------
* This section drives the "ROBOT FEEDBACK" lights on the Operator Interface.
* The lights are green for joystick forward and red for joystick reverse.
* Both red and green are on when the joystick is centered. Use the
* trim tabs on the joystick to adjust the center.
* These may be changed for any use that the user desires.
*/

if (user_display_mode == 0) /* User Mode is Off */

{ /* Check position of Port 1 Joystick */
if (p1_y >= 0 && p1_y <= 56)
{ /* Joystick is in full reverse position */
Pwm1_green = 0; /* Turn PWM1 green LED - OFF */
Pwm1_red = 1; /* Turn PWM1 red LED - ON */
}
else if (p1_y >= 125 && p1_y <= 129)
{ /* Joystick is in neutral position */
Pwm1_green = 1; /* Turn PWM1 green LED - ON */
Pwm1_red = 1; /* Turn PWM1 red LED - ON */
}
else if (p1_y >= 216 && p1_y <= 255)
{ /* Joystick is in full forward position*/
Pwm1_green = 1; /* Turn PWM1 green LED - ON */
Pwm1_red = 0; /* Turn PWM1 red LED - OFF */
}
else
{ /* In either forward or reverse position */
Pwm1_green = 0; /* Turn PWM1 green LED - OFF */
Pwm1_red = 0; /* Turn PWM1 red LED - OFF */
} /*END Check position of Port 1 Joystick

/* Check position of Port 2 Y Joystick
(or Port 1 X in Single Joystick Drive Mode) */
if (p2_y >= 0 && p2_y <= 56)
{ /* Joystick is in full reverse position */
Pwm2_green = 0; /* Turn pwm2 green LED - OFF */
Pwm2_red = 1; /* Turn pwm2 red LED - ON */
}
else if (p2_y >= 125 && p2_y <= 129)
{ /* Joystick is in neutral position */
Pwm2_green = 1; /* Turn PWM2 green LED - ON */
Pwm2_red = 1; /* Turn PWM2 red LED - ON */
}
else if (p2_y >= 216 && p2_y <= 255)
{ /* Joystick is in full forward position */
Pwm2_green = 1; /* Turn PWM2 green LED - ON */
Pwm2_red = 0; /* Turn PWM2 red LED - OFF */
}
else
{ /* In either forward or reverse position */
Pwm2_green = 0; /* Turn PWM2 green LED - OFF */
Pwm2_red = 0; /* Turn PWM2 red LED - OFF */
} /* END Check position of Port 2 Joystick */

/* This drives the Relay 1 and Relay 2 "Robot Feedback" lights on the OI. */
Relay1_green = relay1_fwd; /* LED is ON when Relay 1 is FWD */
Relay1_red = relay1_rev; /* LED is ON when Relay 1 is REV */
Relay2_green = relay2_fwd; /* LED is ON when Relay 2 is FWD */
Relay2_red = relay2_rev; /* LED is ON when Relay 2 is REV */

Switch1_LED = !(int)rc_dig_in01;
Switch2_LED = !(int)rc_dig_in02;
Switch3_LED = !(int)rc_dig_in03;

} /* (user_display_mode = 0) (User Mode is Off) */

else /* User Mode is On - displays data in OI 4-digit display*/
{
User_Mode_byte = backup_voltage*10; /* so that decimal doesn't get truncated. */
}

} /* END Default_Routine(); */


/************************************************** ****************************/
/************************************************** ****************************/
/************************************************** ****************************/

[aaeamdar]

Found the little sucker. I practically tore down the building with my screams of joy.

unsigned char lookTable[255] was causing a problem. I guess if I want that, I need to give it values from the start. That'll be a pain.

Am I right about this fixing my problem? It allowed it to compile.

[Kevin Watson]

Found the little sucker. I practically tore down the building with my screams of joy.

unsigned char lookTable[255] was causing a problem. I guess if I want that, I need to give it values from the start. That'll be a pain.

Am I right about this fixing my problem? It allowed it to compile.Yes, that was your problem.

-Kevin

[Mark McLeod]

The linker will only allow you to define a total of 256 bytes of global (or static) variables within any single project file. Individual routines within a file, such as user_routines.c, are each limited to 120 bytes of local variables.

If you want to create lookupTable[256], it'll need to be defined in another file off by itself and referenced from user_routines.c as an extern.

Or as you implied define all the values up front and make it a rom const, then you can be as large as you have program space for.

[aaeamdar]

The linker will only allow you to define a total of 256 bytes of global (or static) variables within any single project file. Individual routines within a file, such as user_routines.c, are each limited to 120 bytes of local variables.

If you want to create lookupTable[256], it'll need to be defined in another file off by itself and referenced from user_routines.c as an extern.

Or as you implied define all the values up front and make it a rom const, then you can be as large as you have program space for.

Thanks very much for the help, Kevin and Mark.

making it this


final unsigned char lookTable[255] = {1,2,3,4,5,6...254};


Is probably what I want, as I have no reason to want to modify those values.

I wish I weren't taking Java, I get confused. in Java class I write printf s and in FRC I write System.out.println s.

Anyway, thanks again for all the help and valuable instruction (and timely responses!)

Paul

[Mark McLeod]

The C18 syntax (well, except for the ... part) is:

rom const unsigned char lookTable[256]={0,1,2,3,4,...255};

See pdf page 22 (document page 14) of the MPLAB C18 C Compiler User's Guide (http://ww1.microchip.com/downloads/en/DeviceDoc/C18_UG_51288e.pdf)

[cvbritton]

If it's searching, the pan/tilt servos are swinging the camera around in the hope it can find the green thing. It also should say:

Searching...
Searching...
Searching...
Searching...
Searching...
...

Mine doesn't... anyone got any suggestions?

[Phalanx]

Kevin,

Thank you very much for you elegant camera code. Took me a while to undertand it all, being I've never used "C" in my entire life (I'm an old time legacy mainframe assembly programmer). We do have it installed and running quite nicely. HOWEVER after reading camera.c, I see where you are performing all the nice initialization for the camera, and you are setting quite a few registers. Unfortunately, no where can I find the documentation for all those registers and what their value(s) actually mean. I have the CMUCAM documents from FIRST and a few others and it only has registers 5-6, 17-19 and vaguely defined, do you have more detailed specs, or know where I can get them?

Thanks

[Kevin Watson]

...HOWEVER after reading camera.c, I see where you are performing all the nice initialization for the camera, and you are setting quite a few registers. Unfortunately, no where can I find the documentation for all those registers and what their value(s) actually mean.The registers are in the OV7620 camera module attached to the CMUcam2. The OV7620 data sheet in on my website: http://kevin.org/frc.

-Kevin

[Phalanx]

Thank you very much... Just don't ask me why I didn't think to look at your sight first. LOL! Again many thanks.

[Bob22341]

With my teams CMU cam, I have run the CMU Cam GUI, and the GUI says that it is "searching for the camera" but it never finds the camera, therefore the camera cannot be calibrated. Does anybody know what to do in this situation?

[Joe Hershberger]

With my teams CMU cam, I have run the CMU Cam GUI, and the GUI says that it is "searching for the camera" but it never finds the camera, therefore the camera cannot be calibrated. Does anybody know what to do in this situation?
You have two options for testing the camera or calibrating it. You can use the old app from last year or you can use the new one that runs in LabVIEW that you can get here (http://www.chiefdelphi.com/forums/showthread.php?t=41214). Assuming everything goes well, you won't have to calibrate the camera, as a good calibration has already been done by Kevin in his camera code. If you don't get a GUI working, the default calibration should be good enough.

Cheers!
-Joe

[nheft]

We at team 533 are seeing two distinct intermittent startup error conditions that are unique to the frc_camera_s code. (haven't spent much time with the bells-and-whistles version). These are problems that do not occur with the IFI default code. The camera code we are using is the 1/11/2006 10:45 PM date stamp.

When the RC starts up correctly (about 90% of the time), the camera handler and servo tracker work perfectly. With the default_routine() call uncommented, we are also able to control other PWM putputs from the joysticks, etc.

The other 10% of the time we get one of two kinds of errors.

The first error is the "Code Error", similar to that reported by team 1216. The Code error only occurs at power-up, not after hitting a reset. When we see a Code Error, a robot reset clears the error.

The second error, far more disturbing than the "Code Error" condition, is one in which there is no code error but the data the user uP receives from the master is corrupted - for example Joystick 1 X and Y data fields are reversed. The disturbing thing about this condition is that everything looks normal on the RC LED's so we would not know the problem is happening until the match starts. Also, the RC does not recover from this case by pressing the reset button. Only cycling power (and waiting another 5 seconds if the backup battery is connected) clears the problem.
I disabled Tracking_Info_Terminal(), Camera_Handler() and Servo_Track() in Process_Data_From_Master_uP() and still get the startup errors.

I spoke to Tom Watson at IFI and he said that if we can't duplicate this with the IFI default code then it must be something in the camera code.

Any help would be appreciated. Thanks in advance.

[Chris Hibner]

You mention that the joystick x and y are inverted. Did you determine by checking the joystick x/y values and/or motor PWM variables via the dashboard or terminal window, or are you determining this because the robot is acting funny?

On Tuesday we discovered that PWMs 13,14,15, and 16 (i.e. the bit-banged PWMs) do not work with the default camera code. The interrupts in the camera code occasionally stretch the pulse widths causing the robot to jump around a bit.

[nheft]

The X and Y values were reversed, not inverted. I was using the "example printf" line in the default code that sends out p1_y, pi_x, p1_trig, and p1_top to the serial port for diagnostic purposes. In the fault condition, the X and Y values are reversed and I am getting garbage for p1_trig and p1_top as well, causing their associated relay outputs to go crazy.

[Kevin Watson]

We at team 533 are seeing two distinct intermittent startup error conditions that are unique to the frc_camera_s code. (haven't spent much time with the bells-and-whistles version). These are problems that do not occur with the IFI default code. The camera code we are using is the 1/11/2006 10:45 PM date stamp.

When the RC starts up correctly (about 90% of the time), the camera handler and servo tracker work perfectly. With the default_routine() call uncommented, we are also able to control other PWM putputs from the joysticks, etc.

The other 10% of the time we get one of two kinds of errors.

The first error is the "Code Error", similar to that reported by team 1216. The Code error only occurs at power-up, not after hitting a reset. When we see a Code Error, a robot reset clears the error.

The second error, far more disturbing than the "Code Error" condition, is one in which there is no code error but the data the user uP receives from the master is corrupted - for example Joystick 1 X and Y data fields are reversed. The disturbing thing about this condition is that everything looks normal on the RC LED's so we would not know the problem is happening until the match starts. Also, the RC does not recover from this case by pressing the reset button. Only cycling power (and waiting another 5 seconds if the backup battery is connected) clears the problem.
I disabled Tracking_Info_Terminal(), Camera_Handler() and Servo_Track() in Process_Data_From_Master_uP() and still get the startup errors.

I spoke to Tom Watson at IFI and he said that if we can't duplicate this with the IFI default code then it must be something in the camera code.

Any help would be appreciated. Thanks in advance.I'd suspect that you've got a questionable robot controller. The addition of the camera code may be pushing executable code into an area of memory that may have access time issues. Call up IFI again and ask to speak with Mark, who is on the software side of the house. Hopefully he can arrange a swap and put your RC on a debugger to determine what's happening.

-Kevin

[Alan Anderson]

It sounds like the problem is with communication, and most of that is handled by the master processor. Reloading the master processor firmware is worth a try.

[nheft]

Thanks - I'll give 'er a try and let you know what happens.

It sounds like the problem is with communication, and most of that is handled by the master processor. Reloading the master processor firmware is worth a try.

[nheft]

Tried reloading master.bin, to no avail.

It sounds like the problem is with communication, and most of that is handled by the master processor. Reloading the master processor firmware is worth a try.

[nheft]

Our controller is en route to IFI as we speak. A swap was not possible; we're taking downtime and focusing on mechanical issues until we get our controller back.

Before sending it back I ran some more tests and made an interesting observation - I placed a light duty Pep Boys automotive switch in series with the HI-AMP circuit breaker and used the switch to turn the controller on and off. Still seeing intermittent failures but significantly less often than when powering up and down with the breaker. These observations were made with the 7.2 backup battery out of the equation. The only difference I can think of is the contact bounce characteristics of the switch versus the HI-AMP breaker. I looked at the turn-on transient of the breaker and the switch on a scope. They each exhibit about 5 ms of contact bounce before finally settling out to +12V. Tom at IFI thinks what I saw was coincidence. Wierd problem. Time will tell what the cause is.

[Anime-niac_2.9]

the camera code is being a pain. tell us kevin, what could we edit so that the camera can scan smoothly instead of quick jolt-stop-quick jolt-stop, and so forth? just what was the purpose of having the camera being able to look directly at the ground.

[Cuog]

you can edit the tracking portion of tracking.c I changed ours to track smoothly and it first tracks where i tell it to(where i predict the light) then it searches a wider pattern until it finds the light

[drinkdhmo]

We are having the same problems with the camera_s code as team 533. Except, the code fault on powerup occurs almost 95% of the time, and this is fixed with a reset. Also, instead of the p1_y and the p_1x being switched, the joystick's y axis is being read as p1_x in the controller and the joystick's x-axis and throttle are unresponsive. The joystick's buttons are also giving very flaky values, even when not pressed. We are watching these values with a printf in the Process_Data_From_Master_uP function with an otherwise fresh copy of the camera_s code that is dated 1/14/06.

[nheft]

When we hit the reset button and the code error goes away, the p1_y still gets read as p1_x. Do you see the same?

It makes a difference how you power up the controller. We placed a toggle switch between the fuse panel and the RC. Sure enough, the power-up fault occurs much less often (but still happens occasionally) when we use the switch to turn the controller on. I think the difference is in the contact bounce of the switch vs the circuit breaker.

Your description of the joystick's p1_y being read as p1_x is exactly what we're getting; my previous statement that x and y were reversed was inaccurate.

I sent our controller back to IFI and they claim they cannot duplicate the problem at IFI.

I spoke to Mark Lambert IFI's RC digital/software guru. He can't identify a mechanism that would explain what we're seeing. Since it does not happen with the IFI default code, they will not spend much time investigating. The only software they "support" is the IFI default code.

Mark did give me some information that might help. The "reserved" word in the rxdata structure always contains the number 12, which is the firmware revision number for the master uP. When the rxdata gets misaligned (p1_y read as p1_x, etc), the reserved word will probably be wrong too. I can use this to detect the error, go into an infinite loop, and force the RC to crash. This way we can tell by looking at the RC LED's that something is wrong and try recycling power. Yes, it's just a band-aid but we don't have time to dig in and find the root cause.

[nheft]

Kevin,

Here is a follow up to my initial post on startup errors.

Suspecting a questionable RC, I did the following:

1. Loaded unmodified hex file from the latest frc_camera_s release
2. Verified that we still see the intermittent code error
3. Sent the controller back to IFI.

Tom Watson and Mark Lambert cycled power on the controller at IFI 150 times (75 with the backup battery and 75 without the backup battery) and they claim they can't duplicate the problem.

Since then, another team, 1566, has reported the exact same problem on this forum.

I have noticed that, strangely enough, when using a toggle switch instead of the HI-AMP kit breaker to power the RC up, the error becomes far less frequent.

Any ideas?

Thanks in advance.

[Mark McLeod]

You might try dumping the entire rx packet to a file so you can do a full compare of good packets against the bad packets. There may be further clues in what's getting corrupted. Since it may be one dropped value at the start causing a shift in all the other packet values (possibly double 255's?).
It would be handier if you have a OI pot/switch box to preset known values to make the proper contents more readily identifiable.

I'll see if I can reproduce the errors you guys are seeing on our 2006 RC this evening. That'll give it third party confirmation.

[Kevin Watson]

Kevin,

Here is a follow up to my initial post on startup errors.

Suspecting a questionable RC, I did the following:

1. Loaded unmodified hex file from the latest frc_camera_s release
2. Verified that we still see the intermittent code error
3. Sent the controller back to IFI.

Tom Watson and Mark Lambert cycled power on the controller at IFI 150 times (75 with the backup battery and 75 without the backup battery) and they claim they can't duplicate the problem.

Since then, another team, 1566, has reported the exact same problem on this forum.

I have noticed that, strangely enough, when using a toggle switch instead of the HI-AMP kit breaker to power the RC up, the error becomes far less frequent.

Any ideas?

Thanks in advance.I think we can go on the assumption that it's not caused by the camera code directly. The only thing that immediately comes to mind is some kind of race condition where the processor comes out of reset before the oscillator is stabilized. If I get a chance, I'll call IFI today and see what can be done about this. As an experiment, you might try holding the processor in a reset state while powering up. Do it enough times to get real statistics.

-Kevin

[nheft]

If you can replicate the problem on your RC then you will be the fourth team to my knowledge that has seek the problem first hand.

If you can try just loading the hex file from frc_camera_s (which can be found on http://www.kevin.org/frc) and try a few power cycles and let me know what you find it would be a tremendous help. I'm going to try the full packet dump idea this afternoon at the school.

You might try dumping the entire rx packet to a file so you can do a full compare of good packets against the bad packets. There may be further clues in what's getting corrupted. Since it may be one dropped value at the start causing a shift in all the other packet values (possibly double 255's?).
It would be handier if you have a OI pot/switch box to preset known values to make the proper contents more readily identifiable.

I'll see if I can reproduce the errors you guys are seeing on our 2006 RC this evening. That'll give it third party confirmation.

[nheft]

Once the corrupt data problem (p1_y being read as p1_x, etc), the reset button does not clear the problem; nothing works except cycling the power off and back on. I have not tried powering up with the reset button pressed as you suggested; I'll try that idea tonight at the school.

Another thing I will try is to put a cheap and dirty delay loop ahead of IFI_Initialization to stall the user processor for a few tenths of a millisecond after a reset.

When I post an observation here at Delphi it is typically based on a collection of 50 trials or more.

I think we can go on the assumption that it's not caused by the camera code directly. The only thing that immediately comes to mind is some kind of race condition where the processor comes out of reset before the oscillator is stabilized. If I get a chance, I'll call IFI today and see what can be done about this. As an experiment, you might try holding the processor in a reset state while powering up. Do it enough times to get real statistics.

-Kevin

[drinkdhmo]

We have explored the problem a little more fully today and have found a few more details:

Powering up the robot with the reset button depressed, then releasing it, still results in a code fault.

The processor results in a code fault only when the controller has been off for more than 5 seconds after running for more than a few minutes. We did some extensive testing and timing and a power cycle (with the breaker, not the reset button). When the processor has not been on as long, more time powered down is required to reproduce the code fault. We could not reproduce the code fault at all by holding down the reset button for an extended period of time (about a minute).

Along with joystick 1's y-axis being mapped to p1_x, we have also noticed that joystick 3's x-axis is being mapped to p1_y. We have not yet explored all of the oi input mappings, but we will post it when we do.

We also found that when we powered up the rc without a radio modem or tether connected, the program does not fault. When we reconnect the radio modem the program will fault again, but only after the processor has been powered down for a varrying period of time.

Whether the code faults on startup or not, the OI input mappings are still messed up.

This is all we have found so far. I will continue our exploration of the problem tomorrow and post anything new.

[Bob22341]

I have tried working with the camera GUI's (java and labview programs) and neither of them work. The java program freezes when i try to change a setting, and it always fails when i try to do a frame grab. The labview program gives me a crash message on startup. I am totally lost! :confused:

If anyone could give me a hand, it would be a big help. Thanks.

[Mark McLeod]

No luck (questionable usage I suppose) duplicating your issues with our RC.

I did power cycles of each of the following variations with preset values through Port 1. Tests were split between using the as-is default frc_camera_s camera.hex and a version modified to include Default_Routine() and a dump of the rx packet. I usually cycled rather quickly, restarting after a 10-count, but tried some varying time spent powered up and resting afterwards.

on tether (30 cycles)
on radio (30 cycles)
w/o backup battery (20 additional tests while on tether)
I have to think as Kevin does that the use of the camera code is just exposing a flaw or a timing issue in your particular RC that the IFI default code does not.

If you're up for a road trip Neil (maybe hard for the Alberta and Idaho folks) and think it could be beneficial you are welcome to try your code and tests on our 2006 RC and we can swap in various cameras as well. Try dropping by a nearby team and repeating your tests.

[nheft]

Here's what we found Thursday night

(1) Same observation on powering up with reset depressed. Doesn't seem to make a difference.

(2) Tracing program flow with printf statements sprinkled throughout Process_Data_From_Master_uP(), we see that it always executes successfully the first time through.

(a) In the no-fault case, Process_Data_From_Master_uP() continues to get called like clock work

(b) In the CODE ERROR case, Process_Data_From_Master_uP() only gets called once. (or possibly it continues to get called but the printf's stop because of a serial port hangup)

(c) In the garbled rxdata case, the first packet comes in OK but from the second packet forward the OI mappings are corrupted. Data fields are always mis-aligned in the same fashion but it's not as simple as a byte shift.

I have incorporated a trap that detects five consecutive packets with 127 in the packet_num field and goes into an infinite loop if this occurs. This forces a code error if the rx packets are corrupted so we know to re-cycle the power. I plan to further refine the logic to only enable the trap during the first few cycles; once we get off to a good start we seem to run OK till the next power-up.

Does your RC ever come up OK with proper OI mappings?

Neil

We have explored the problem a little more fully today and have found a few more details:

Powering up the robot with the reset button depressed, then releasing it, still results in a code fault.

The processor results in a code fault only when the controller has been off for more than 5 seconds after running for more than a few minutes. We did some extensive testing and timing and a power cycle (with the breaker, not the reset button). When the processor has not been on as long, more time powered down is required to reproduce the code fault. We could not reproduce the code fault at all by holding down the reset button for an extended period of time (about a minute).

Along with joystick 1's y-axis being mapped to p1_x, we have also noticed that joystick 3's x-axis is being mapped to p1_y. We have not yet explored all of the oi input mappings, but we will post it when we do.

We also found that when we powered up the rc without a radio modem or tether connected, the program does not fault. When we reconnect the radio modem the program will fault again, but only after the processor has been powered down for a varrying period of time.

Whether the code faults on startup or not, the OI input mappings are still messed up.

This is all we have found so far. I will continue our exploration of the problem tomorrow and post anything new.

[nheft]

I tried holding the reset button while powering up. Still getting random code errors.

I sprinkled some printf's into Process_Data_From_Master_uP - one at the beginning of the module, one to print out the entire rxdata buffer, and one at the end of the module. When the code error occurs I am observing that Process_Data_From_Master_uP executes one time.

When the mis-aligned rx buffer problem occurs, it looks like it's happening from the second message on; the first rxbuffer received after initialization looks OK.

I also tried a simple delay loop before IFI_Initialization to give the oscillator a few tenths of a second to stabilize before trying to do anything. This did not help either.

Another programmer from Team 358 loaded frc_camera_s on his RC and could not find a problem. I tend to believe there is a marginal timing problem somewhere that just doesn't occur with all RC's and does not occur with IFI default code.

For now, my work-around is going to be: (1) if the LED's show a code error, cycle power and (2) if the packets get misaligned, trap on a lack of proper incrementation of packet_num and force a code error via an infinite loop, taking us back to step 1. This trap can be disabled after five consecutive good packets since the RC seems to behave OK once it gets off to a good start.

I think we can go on the assumption that it's not caused by the camera code directly. The only thing that immediately comes to mind is some kind of race condition where the processor comes out of reset before the oscillator is stabilized. If I get a chance, I'll call IFI today and see what can be done about this. As an experiment, you might try holding the processor in a reset state while powering up. Do it enough times to get real statistics.

-Kevin

[drinkdhmo]

ELATION!

The whole time we were trying to get the drive system working, we did not have the camera hooked up. Today I finally tried hooking up the camera while controlling drive. It worked. Silly me, I didn't realize that this code requires the camrea be connected...

Once we hooked up the camera, we reduced our fault frequency to about 1 in 5 powerups as opposed to almost every time. To fix this, we connected a SPST bat-handle toggle switch in series with the power connection to the RC. After doing that, we have not had the processor fault at all.

Hopefully this information can help any of you in fixing your problems.

[nheft]

Thanks for the tests and the offer to let us try our code on your RC.

Looks like I we're going to use the RC the way it is. IFI looked at it and said they can't find anything wrong. So whatever I find from this point looking forward, I'm stuck with it the way it is.

I agree that it's a subtle timing flaw that does not manifest itself with the default code. I don't even think it happens on all RC's. (yours does not seem to have the problem)

I came up with a test that waits for the first 16 packets to come in, verifies that the packet_num increments for the 11th through the 16th consecutive packets. (I noticed that on startup, with the OI getting its power through the tether cable, the packets don't start incrementing regularly until after the tenth packet.) Once this test passes, I never see a failure in the RC. If the test fails, I go into a trap that forces a code error. Now we always get either a good start or a code error, never a bad start that looks like everything is fine.

No luck (questionable usage I suppose) duplicating your issues with our RC.

I have to think as Kevin does that the use of the camera code is just exposing a flaw or a timing issue in your particular RC that the IFI default code does not.

If you're up for a road trip Neil (maybe hard for the Alberta and Idaho folks) and think it could be beneficial you are welcome to try your code and tests on our 2006 RC and we can swap in various cameras as well. Try dropping by a nearby team and repeating your tests.

[charrisTTI]

Programmers from our team have reported similar observations.

I have not yet had a chance to help them investigate.

This is a real shot from the hip, but here goes anyway.

Default code does not turn on interrupt handling for serial communications to/from the camera.

What about an interrupt processing issue?
Does the UART have a funny state on power up (only some of the time)?
Does the power up of the camera enter into the problem?
Camera first then RC. RC first then Camera. Does this change the situation?

How does data get from the master microprocessor to the user microprocessor? DMA, Dual ported ram, serial ????

How can the camera code affect this?

[kc8nod]

Hi There,

We seem to be having the same problem.

Along with joystick 1's y-axis being mapped to p1_x, we have also noticed that joystick 3's x-axis is being mapped to p1_y.Yup, we have confirmed the same behavior.
I came up with a test that waits for the first 16 packets to come in, verifies that the packet_num increments for the 11th through the 16th consecutive packets.We plan to implement the same workaround.

[nheft]

I agree that your observations on interrupt enables and UART state on power-up are on target.

We saw pretty much the same results with or without the camera connected. The camera gets power from one of the PWM outputs so it has to come up after the RC does.

According to IFI the user uP gets data from the Master via a serial SPI interface. I don't know if there is any error checking in the user uP but I suspect not.

Six weeks was not going to be enough time to run this investigation into the ground and still be able to perform our remaining tasks, so I elected to work around the problem as I described in my last post.

[X-Istence]

My RC has been behaving. However, I don't know what you guys have done to get this error to come up. I however have only used it with the Tether cable plugged in.

If someone could give me a rundown as to how this problem should be occurring, and what I should do to get it to show up, I will gladly help out, from previous posts I was unable to get exactly what I had to do to get this error to possibly show up.

[X-Istence]

The first error is the "Code Error", similar to that reported by team 1216. The Code error only occurs at power-up, not after hitting a reset. When we see a Code Error, a robot reset clears the error.

The second error, far more disturbing than the "Code Error" condition, is one in which there is no code error but the data the user uP receives from the master is corrupted - for example Joystick 1 X and Y data fields are reversed. The disturbing thing about this condition is that everything looks normal on the RC LED's so we would not know the problem is happening until the match starts. Also, the RC does not recover from this case by pressing the reset button. Only cycling power (and waiting another 5 seconds if the backup battery is connected) clears the problem.
I disabled Tracking_Info_Terminal(), Camera_Handler() and Servo_Track() in Process_Data_From_Master_uP() and still get the startup errors.


I know my last question was for more info, but I now know what the problem looks like. We have the exact same problems. The first case happens sporadically, as does the second, the second however was easy to find, just turn our belt system on, and then try to turn it back off. The robot would jump all over the place, as would the camera's servo's.

I am going to redo my electrical, and will look through the entire code for possible things that could be going wrong. Ours probably does not have this problem with the default code either. However, what I have noticed, is that turning off the OI and then turning it back on, will ALSO solve the problem for me (unless it says code error).

For now I am going to keep going with what I have, after we ship I am going to see what I can get done, possibly even trade in last years RC for a new one with $150 down (I believe this is what IFI has a deal going for or something, correct me if I am wrong, in which case we may purchase an entirely new one).

[Kevin Watson]

I've posted updated "bells and whistles" camera software here: http://kevin.org/frc. These are the changes:

tracking.c/.h:
Provided two new functions to set the pan and tilt servo position.
This was done to provide a level of indirection so that the servos
could be controlled from the robot controller or the CMUcam2.

Fixed bug in search initialization code where temp_pan_servo was
initialized to zero instead of Tracking_Config_Data.Pan_Min_PWM.

Altered tracking algorithm to use the t-packet confidence value to
determine whether the code should track or search.

Added Get_Tracking_State() function, which can be used to determine
if the camera is pointing at the target.

tracking_menu.c/.h:
Added the ability to set the confidence threshold via the tracking
menu.

terminal.c:
Added "no camera data" diagnostic information.

user_routines.c:
Added code to send tracking state information to the user LEDs on
the operator interface.

-Kevin

[gnirts]

I've posted updated "bells and whistles" camera software here: http://kevin.org/frc. These are the changes:
-Kevin

Can these changes be replicated in the streamlined version as well?

[Kevin Watson]

Can these changes be replicated in the streamlined version as well?Yes, I'm working on it.

-Kevin

[Fritz]

We are currently experiencing a problem getting the 2005 RC to accept any code that uses the current default camera code. It won't accept, at all, and the hex is no larger than any of our other working code... infact, the hex is smaller! If anyone can help, it'd be muuuuch appreciated.

ps. we have set it up with the old linker and even the new ones to see if it will work...

[eugenebrooks]

We are currently experiencing a problem getting the 2005 RC to accept any code that uses the current default camera code. It won't accept, at all, and the hex is no larger than any of our other working code... infact, the hex is smaller! If anyone can help, it'd be muuuuch appreciated.

ps. we have set it up with the old linker and even the new ones to see if it will work...

We did this without problems just in case we would need to switch
to the 2005 controller. We started with the 2005 default code,
version 2.2 without the camera code in it. We then added the 2006
camera code .c and .h files, and our own .c and .h files that handled
other interrupt based functionality, to the folder and they to the project.
You will have to delete the IFI serial driver and header from the folder
and project, and you will have to change stdio to the correct printf_lib
include. You then have to fold in your changes to user_routines and
user_routines_fast. It will work if you catch all the nits, and there
are a few.

[DICKIE]

As for replacing a servo with a different type of motor, that is a bit of a challenge. Servos have internal feedback which allows you to tell it to go to a particular position. You may notice that if you have a servo powered and you try to turn it, it fights back to keep the position the same. The servo just has a small motor inside, a controller, and a sensor for feedback. If you want a globe or fisher price motor to act like a servo, then you need those other two components. You can use a sensor like the Gear Tooth Sensor included in the kit as your feedback. For the controller, you can use the FRC and write software! The motor controllers that have available, (victors, and of less usefulness, the spikes) only control the speed of the motors, not the position. This is because they don't know where they are, and therefore don't know where to go from there (where?). Hopefully the servos will work for you, but if not, it's possible to use other motors instead. It's just a lot more work. If you decide you do need a controller and motors, do some research/googling for PID control. It's a pretty straight forward method of control that gives good results. There's probably even code floating around out there if you look hard enough.


HELP!! :ahh: can we not avoid using the gear tooth sensor by setting our fischer motor, globe, etc. at a low enough speed? then when it finds the light to stop?? if this is possible, where in the code do i do this. i'm not the greatest programmer but i need to figure this one out!! if canybody can help that'd be great :)

[Keith Watson]

HELP!! :ahh: can we not avoid using the gear tooth sensor by setting our fischer motor, globe, etc. at a low enough speed? then when it finds the light to stop?? if this is possible, where in the code do i do this. i'm not the greatest programmer but i need to figure this one out!! if canybody can help that'd be great :)The camera searching/tracking code is in the file tracking.c in the function Servo_Track(). You will need to read the code to understand what the algorithm is doing.

[owner_master]

ok where can i get the 2006 code for the camera i don't see in on the website. What is the file called?

[JBotAlan]

ok where can i get the 2006 code for the camera i don't see in on the website. What is the file called?

Go to: http://kevin.org/frc/ and scroll a little more than halfway down. Under the section titled "2007 FRC-RC Example Code and Utilities", there is a list of ZIP files that contain code for MPLAB. If you are writing in easyC, these probably won't be of any use to you; the easyC code downloads are at: http://www.intelitekdownloads.com/easyCPRO/ under "2007 Kickoff Demo Code".

JBot

[owner_master]

well i went there and these are the four file frc_camera_s_21.zip, frc_camera_21.zip,frc_camera_s_2.zip, frc_camera_2.zip. i am looking for one with ends in ....._2006.zip and it has to be for Mplab

[JBotAlan]

well i went there and these are the four file frc_camera_s_21.zip, frc_camera_21.zip,frc_camera_s_2.zip, frc_camera_2.zip. i am looking for one with ends in ....._2006.zip and it has to be for Mplab

Kevin has updated his site. The files you see are the replacements for the old '06 stuff. If you are looking to base your code off of Kevin's code, you probably want frc_camera_21.zip, and if you are looking to integrate camera code into an existing project, you probably want to get the streamlined version, frc_camera_s_21.zip. It depends on what you are using it for.

JBot