Moving bot once targeted on the light

Technical Programming
#1

Hey, I have this piece of code


if( Get_Tracking_State() == CAMERA_ON_TARGET )
{
    Switch3_LED = 1;
    pwm10 = pwm08 = 135;
}
else
{
    Switch3_LED = 0;
    pwm10 = pwm08 = 127;
}

Really, it’s just the code from the Process_Data_From_Master_uP() in user_routines.c that checks if the camera has targeted the light. pwm10 and pwm08 are the pwms that the wheels are connected to. I was hoping to get very slow movement by setting it to 135.

Once I found that didn’t work. I tried controlling a small motor I setup to it that I had earlier controlled with a potentiometer. That to didn’t work.

Any reason why this isn’t working?

Thanks,
Jedd
Team 1551

#2

Did you try setting the motor to 255? or 0?.. maybe 135 is just to close to neutral

#3

Max is right. 135 is still within the deadband of the speed controller. I wouldn’t try 255 on the first run, but a little more (say, 150) should definitely be enough to get the robot moving. See this page: http://www.ifirobotics.com/victor-884-speed-controller-robots.shtml

The Victor 884 has a deadband with respect to the PWM signal, which is approximately 117 to 137 (127 center). Any PWM signal within the deadband results in no output (neutral).

#4

Thanks.I should of mentioned two other things also.

1.) When I tried the motor I had set it to 255. But that didn’t anything obviously

2.) When the camera picks up the light, it will slowly (but jumply, and jitterly) tilt upwards. As it does this, the red light blinks, instead of steadily staying on. So I suspect that it only is locked on momentarily to light, not giving enough time change the values of the pwms(?).

Sorry I didn’t mention this in the first post.:o

#5

Ok, I fixed problem 2! I’m still unsure of how to actually move the robot now though.

#6

Is your default_routine() call uncommented? If so, something might be mapped to those PWMs, and you might be getting interference between your code and the mapping in default_routine().

#7

Nope, it commented out…

#8

make sure that there is no other drive code in that is setting your motors to joystick inputs later on in the code. you would have to comment those out.

just to make sure you realize this code will drive forward until the camera loses sight of the target. just don’t want you to smash into anyone. :smiley:

#9

Question.

This code goes into the user_routines.c file of the workspace. Does this go into the same section where the mapping of the pwm’s to the joysticks go? And if so, dont you just fix the problem by setting the pwms from the camera imput, AFTER the pwm mapping of the joysticks? Or is it more complicated than this? We are stuck on this same issue.

#10

Try something other than 255… I believe 255 is a special value.

Try like 180, which is in the middle, way out of the deadband and not the maximum

Or, you could try 250, and see if the Victor light becomes red

(FYI: The Victor light is the most accurate source if you are stuck with a PWM value problem… that one light tells you a lot of info. If it is flashing orange, it’s a 3-pin PWM cable problem, or it’s set to a special value that disables it (like if your robot is detached). If it’s completely off once you run the code, the motors are running slowly or half-speed. If it’s solid orange, they are inside the deadband or completely stopped. If it’s bright red or green, it’s running full power in forward or reverse.)

#11

I found that CAMERA_ON_TARGET state goes on and off too much to do any good. I’ve tried this state and it works realiby:


if( Get_Tracking_State() == SEARCHING)
{
    pwm10 = pwm08 = 127;
}
else
{
    pwm10 = pwm08 = 135; // 135 is nothing unless its a really geared down motor :)
}

The SEARCHING state works great and I was able to keep a spike on with relay output.