Camera Code Update

I’ve made a few changes to the camera code and would like to get some feedback before releasing it. If you can think of something you’d like changed or added, please leave a message here. These are the changes do far:

2/11/07 changes made for version 2.2:

Important: after loading the new software, make sure
you “Load default values” and then “Save changes” from
the tracking menu.

terminal.c/.h:
-Fixed benign bug where old_camera_t_packets was not getting updated in Tracking_Info_Terminal().

-Altered code to use Tracking_Config_Data values for center tilt and pan values instead of hardwired values in Tracking_Info_Terminal().

-Altered code to use Get_Camera_T_Packets() function instead of directly accessing camera_t_packets variable.

camera.c/.h:
-Added Poll_Mode() function.

-Added Get_Camera_ACKs() function.

-Added Get_Camera_NCKs() function.

-Added Get_Camera_T_Packets() function.

tracking.c/.h:
-Altered code to use Get_Camera_T_Packets() function instead of directly accessing camera_t_packets variable.

-Changed default CONFIDENCE_THRESHOLD_DEFAULT values to 10 (was 20).

-Greatly simplified search code (same functionality with less code).

-Changed search parameters so that a fixed tilt angle of about 30 degrees is used.

-For finer control, moved camera pan servo to PWM output 15.

-For finer control, Moved camera tilt servo to PWM output 16.

user_routines_fast.c:
-Replaced call to Generate_Pwms() in User_Autonomous_Code() with a call to PWM().

serial_ports_readme.txt:
-Corrected installation instruction #4.

camera_readme.txt:
-Added Virtual_Window() function description.

-Added Poll_Mode() function description.

-Added Get_Camera_ACKs() function description.

-Added Get_Camera_NCKs() function description.

-Added Get_Camera_T_Packets() function description.

pwm.h:
-Using new PWM() software, optimized camera tilt for a range of 0 to 90 degrees.

-Kevin

After I just finished porting your tracking software to work with WPILib…!!!:mad:

:wink: Can’t wait to test the new stuff out. I’m particularly excited about the increased servo resolution.

This is the new search code:


*///////////////////*
*// //*
*// search code //*
*// //*
*///////////////////*
 
*// To provide a delay for the camera to lock onto the*
*// target between position changes, we only step the camera*
*// to a new position every SEARCH_DELAY times while we're *
*// in search mode. SEARCH_DELAY is #define'd in tracking.h*
loop_count**++**;
 
**if**(loop_count **>=** Tracking_Config_Data**.**Search_Delay)
{
*// reset the loop counter*
loop_count **=**0;
 
*// If we're starting a new search, initialize the pan*
*// and tilt servos to the search starting point.*
*// Otherwise, just continue the search pattern from*
*// where we left off. The variable new_search is reset*
*// to one each time the tracking code (above) executes.*
**if**(new_search **==**1)
{
new_search **=**0;
temp_pan_servo **=** Tracking_Config_Data**.**Pan_Min_PWM;
temp_tilt_servo **=** Tracking_Config_Data**.**Tilt_Center_PWM; 
}
**else**
{
*// calculate new pan position based upon the current pan servo position*
temp_pan_servo **=** (**int**)pan_servo_position;
 
*// step the pan servo to its next destination*
temp_pan_servo **+=** (**int**)Tracking_Config_Data**.**Pan_Search_Step_Size;
 
*// is the new pan servo position beyond the end of its travel?*
**if**(temp_pan_servo **>** (**int**)Tracking_Config_Data**.**Pan_Max_PWM)
{
*// send the pan servo back to the starting position*
temp_pan_servo **=** (**int**)Tracking_Config_Data**.**Pan_Min_PWM;
 
*// calculate new tilt position based upon the current pan servo position*
temp_tilt_servo **=** (**int**)tilt_servo_position;
 
*// step the tilt servo to its next destination*
temp_tilt_servo **+=** (**int**)Tracking_Config_Data**.**Tilt_Search_Step_Size;
 
*// is the new tilt servo position beyond the end of its travel?*
**if**(temp_tilt_servo **>** (**int**)Tracking_Config_Data**.**Tilt_Max_PWM)
{
*// send the tilt servo back to the starting position*
temp_tilt_servo **=** (**int**)Tracking_Config_Data**.**Tilt_Min_PWM;
}
*// update the local variable used to store the current tilt servo positions*
tilt_servo_position **=** (**unsigned****char**)temp_tilt_servo;
}
*// update the local variable used to store the current pan servo positions*
pan_servo_position **=** (**unsigned****char**)temp_pan_servo;
}
 
*// update the pan and tilt servo PWM value*
**Set_Pan_Servo_Position**(pan_servo_position);
**Set_Tilt_Servo_Position**(tilt_servo_position);
}
 
 

The increased servo resolution was mentioned towards the end of this thread:

-Kevin

Thanks for this new version!!!
Our team is having some problems with the CMUCam2.1 version, the tilt and pan is not moving and stuff like this!Well try to test this one. Probably well need to change the PWMs to other outputs. Am I correct??(were newbies, and we need a lot of help!!!)
We hope it works!!!:wink:

Bye!

Kevin’s revised code takes advantage of the ability to use hardware built into the PIC to generate higher-precision PWM signals on PWM 13-16. This allows you finer control over the tilt and pan of the camera for better triangulation.

So, you could modify the code to use the PWMs you were before, but I would recommend moving to PWM 15 and 16 as Kevin has done.

Sounds excellent. I think you should release it as soon as possible; time is running short :slight_smile:

What you mean when you say better triangulation??
And where do I add this new search code that Kevin has created??
Probably I will do a lot of questions don`t be mad please:rolleyes:
Thanks for your help!

If you don’t already understand the innards of tracking.c, I think you’re better off leaving it alone. The 2.1 code does exactly the same thing as this update, just not as elegantly.

Request: Please release the streamlined version of this too.

Yes, once I’m reasonably happy with the code, I’ll quickly port it over to the streamlined version. Unless I need to make some last minute changes, I’ll zip-up the bells & whistles code tonight and post a link here.

-Kevin

Kevin, PWM outputs 15 and 16 are used for the (left?) motors. If you take those PWM outputs, we won’t be able to use the camera to move the robot to the light. But of course, that’s not a real issue, since I can change the Servo PWM outputs. But mabye others don’t know how do to it and could freak out a bit because some of thier engines are not working.
I don’t mind you have changed it, but just thinking about the weaker ones. :slight_smile:

Our team will check the code tommorow, tweak it as needed.

Thanks for the update.:wink:

I’m not sure the new code is elegant, but I am sure the old search code is not elegant :).

-Kevin

Yes, it’s a pain, but I need to move the pan and tilt servos to the range 13 through 16 to exploit the new PWM() functionality. You make a good point and I’ll make sure it’s very clear in the readme_first.txt document that the assignments have changed.

-Kevin

Considering you’ve got a get, you may very well be including it already, but we would definitely appreciate Reset_Camera_ACKs() and Reset_Camera_NCKs() functions. Not a real big deal, but it would save us a variable.

I’ve noticed that when the camera is in a search, if the camera is resetting its pan for a new sweep:
“if(temp_pan_servo >= PAN_MAX_PWM_DEFAULT)
{
temp_pan_servo = PAN_MIN_PWM_DEFAULT;”

and if the camera sees the light during this motion of resetting the pan to its minimum, when it arrives at this new pan position, the camera tilts down. It continues to search at this lower tilt, reaches the maximum pan, tilts back up, sweeps to its minimum pan, sees the light during this trip, and tilts down again. It continues this loop and never tracks the light. We don’t usually have this problem, but at certain distances from the light it becomes impossible to track. What can we do to fix this?

You can change the search pattern code to do a zigzag sweep instead of always going left-to-right. That way it will never be panning too fast to stop when it sees the light, and it won’t need to restart the search immediately upon glimpsing and then losing it.

Here’s an overview of one way to go about it. Where it tests for the pan value being greater than the maximum limit, set a flag instead of resetting to minimum. Add a similar test for the pan value being less than the minimum and reset the flag if it is. Where the code adds the step size to the current pan value, have it subtract instead if the flag is set.

I’ve uploaded version 2.2 of the bells & whistles camera code. See the attached document for a list of changes. As it’s very close to the ship date, I would caution everyone to think really, really hard before ripping open your nearly complete code and dumping my changes in. For this reason I’m not sure if I’ll add a link to this code on my website before the ship date. I guess I’ll wait to see what the Chief Delphi crowd thinks. As always, please let me know if you find any bugs in the code or documentation. Anyway, here’s a link: http://kevin.org/frc/frc_camera_22.zip.

Edit: I found a bug in the search code I published above, so don’t use it.

-Kevin

readme_first.txt (5.24 KB)


readme_first.txt (5.24 KB)

I found a bug in the old search code. Not sure if someone has seen this before or not. We have our camera mounted upside down. So, top is bottom and left is right. The camera still tracks the right way because the image is flipped, but the search code looks at the floor instead of the ceiling. When we have the target in front of the robot and elevated a bit, the search code freaks out. As it transitions from its max tilt pwm to its min tilt pwm, it does a diagonal. While traveling this path, it gets a new t packet (I see the red light on the camera flash) as it passes where the light is. As soon as it gets to the other corner, it doesn’t see the light anymore, but it continues to drop to the middle tilt search pwm and scan on that level, at which it does not get a new t packet.

This problem will go away when we change the search code to our own algorithm, but I still think it is a bit of a problem.

I’d like to make one suggestion - we’ve found the common sense says the light is probably closest to the position that you lost at it. If you comment out the “New_Search = 1” line in the old code, the camera will just continue searching from it’s current location.

Generally it results in a much quicker lock, because if it was only a temporary loss of the light (say a robot drives in front of you) the camera may well catch the light on the next pan, rather than resetting the tilt completely and starting a new search.

This is especially true when the robot is under the light to score. It also fixes the issue some teams are having where the camera “freaks out” and starts doing the tilt down then pan that someone else mentioned here.

Don’t use what? Are you saying not to use v2.2 altogether?