I am trying to program my robot for autonomous skills. Is it possible to have the robot automatically calculate the number of balls that have gone through the launcher in RobotC and then have the robot drive to the other side for preloads? I know how to do this in other languages by using event handlers, but C doesn’t have event handlers.
I’ll give an example. This robot had a button that detected the ball. It then looked for the edge from when the ball transitioned from pressed to not pressed.
You can also, depending on the type of launcher, detect either each full gear rotation (puncher/catapult), or each time you experience a significant slowdown (flywheel). The former is not always 100% accurate because you might notice that your shooter slips a little bit at the start of each draw (the gear doesn’t engage properly at first) or you decide to let the puncher dry fire (cycle without a ball) for some reason. The latter requires a stable velocity calculation because if the noise in your velocity matches the velocity lost in a shot, you will have many false positives (thinking the robot shot without actually shooting, or shooting without registering a shot). Your best bet is to add a button to detect the release of a ball. Light sensors might be affected by ambient lighting at a competition and even the position of the loaders, but I’m not sure. The light sensor also requires a little bit of testing that the button doesn’t.
Use a code like this:
Int ballcount=0;
While (ballcount<=32)
{
If (getMotorVelocity()<85)
{
ballcount++
Wait1Msec(500);
}
Wait1Msec(50):
}
You will have to tune all the numbers
I’ve built a function into our PID controller so that it will react (in various ways) to balls being shot. But I find that the count we get from this won’t match the number of balls going through because when we shoot fast the flywheel does not recover to full speed. My plan right now is to use an ultrasonic sensor to count balls as they pass through. I considered a limit switch but didn’t like how it had to touch the balls and how the prong can break off if you move the intake backwards.
@Sunil, that’s a really interesting idea. I think it might be better than the ultrasonic sensor since I’ve found that the ultrasonic sensor readings have a lot of error in them. Have you had any issues with detecting balls in varying light conditions, or is there always a consistent drop in the reading regardless of the surrounding light conditions.
I want to try this with two sensors on opposite sides and color filters to detect only regular and only bonus balls. We won’t have time before Worlds, but if someone else is bored, you would basically use either green & orange or their complements to filter the light, I’m not familiar enough with the behavior of light passing through a semitransparent material to know which, and then program 3 buttons on the launcher for high, low, or no goal. It would automatically score your robot’s points, which would be really useful information for scouting teams (“In a match, we average scoring x number of points on our own, with y% accuracy.”) and impress most judges, which is always a plus.
We haven’t had any issues with different light conditions. The sensor always has a very clear difference (around 1500 with a ball and around 400 without).