Any of you guys using the timer to make sure that the driver does not “jump the gun” with the minibot deployment? Now the minibot scoring will ultimately come down to the milliseconds. My only worry with this is that the software might not allow the driver to deploy on time. If I allow the minibot to be deployed a little earlier, it defeats the purpose of the timer in the first place; the driver might jump the gun.
One thing to note is the robots perception of time, and the actual field time tends to differ. Trying to get it as exact as you are inferring will most likely be difficult. I think in the end the driver’s perception of match time will be better than the robots. Rather than putting it on a timer, consider using a color sensor or camera to watch the color on the tower base and use that as the indicator.
I heard that sometimes the total match time varies. This is going to throw off your onboard timer. I would rather have the drivers train than program this feature.
My initial choice was to use a camera, but I then realized that due to the configuration of the robot and the chassis, it would be very hard for the camera to actually see the base of the towers. Essentially, no one had taken a serious consideration of that idea when I proposed it several times during the first few days after kickoff… So even the sensors are second rate components for the team. I find it very hard to incorporate the lintrackers to our current chassis…
The onboard timer is not tied directly to the FMS, but it counts beginning with the first enabled packet, which is pretty close. You will probably be more accurate than a human, and your match time will probably lag about 100ms max or so behind FMS. You could compensate for this or leave it, your choice. Still, that’s barely in the range of human perception, so you would probably have an advantage by implementing it in software (although it would probably only be about 1/10th of a second or so)
I would probably just rely on the drive team being conditioned to deploying at a the right time. To many things could happen.
Keep in mind the refs that will DQ you are no more able to see the milisecond differences between legal and illegal than your drivers are. For that reason I think it has to be manual.
I think it’d be a nice touch. When you’re driving, it’s hard to look up at the screen to see the remaining time. (I don’t know how many audible bells there will be this year: just 15 sec mark, just 10 sec mark, or both)
It’d be nice to have it display on the dashboard with indicators relevant to minibot deployment.
That being said, I don’t think there’s any reason to automate or regulate deployment. As long as the driver knows how much time they have, you should be able to trust them to do what they want. You wouldn’t want any “smart” system to get in their way.
Still, it’d be tempting to have the last 15-20 seconds completely automated. 
And for those thinking of implementing a timer, make sure to start when teleop starts! The period between auto & teleop can change by a few seconds.
If there’s any match timers, like said above, that denote 10s, etc, you could have someone hit a button for each one and collate them (as in, you know they should be 5s apart, either take their median as the 7.5s mark, or do something similar but modify the countdown you’ve been doing all along).
It seems like everyone’s forgetting something important here… Yes, it’s difficult for the drivers to watch the timer and drive at the same time. But isn’t that what the COACH is for? I know our COACH is going to be keeping one eye on the clock the entire time, and yelling into the drivers ear when it’s time to deploy.
This is probably a bad idea. The best case scenario here is that you end up exactly the same as a manual deployment. In addition you will be distracting one of your two drivers to try and hit a button when they should probably be doing something else.
The worst case is that the button is not hit and your minibot doesn’t deploy or is hit accidentally and deploys early.
Eagle, if you mean your coach will tell the driver when to lineup for deployment I agree. If you are going to add a second persons reaction time into your loop for the deployment itself I would not do that if I could possibly help it. Average human reaction time is around 200ms, adding the time it would take the coach to verbalize the command means that your minibot is probably a half second or more behind.
The drive base should be next to the goal 5 seconds before the 10 second mark. The driver’s finger needs to be on that button and as soon as the number 10 is on the screen they hit it.
We’re thinking about using a timer, and then putting a (very) slight delay on it to ensure that we don’t have premature deployment…
…and making that code easy to overwrite to driver-triggerable if, during our practice games on Thursday, it draws penalties for some reason.
My team has the Proxy class of our framework (which is a task that updates 50 times a second) handle a timer counting down remaining match time, and are setting the code up so that the robot will essentially ignore that button until 10 seconds remain. This means that they can hold it down, and it will “trip” as soon as the robot sees 10 seconds remaining, or just deploy at will after that time.
Why is everyone talking about looking at the clock when the tower bases change color when it is time to deploy? Seems like a much more convenient place to look at while also driving your robot.
I think that using a timer to deploy is a great idea, one that we have considered and implemented. Every millisecond can count in the minibot race, and a timer could easily shave off a few hundred, perhaps an entire 0.5 seconds. You have practice matches to see if you get penalties. If you do, change it to manual. Prepare both robot codes and have drivers practice both.
I’d advise against it. There is a reason that you have a 3rd coach, whether another student or a mentor. Let them control when you deploy your minibot, its simply not worth the risk of somehow losing sync with the FMS.
Has there been a history of the FMS counting seconds differently than the rest of the planet?
Yes. Last year, and the year before, the teleop time period was significantly longer than it should have been - by 4-8 seconds as I recall. I timed it using a timer on our robot after one of the other mentors brought up the issue here on CD.
I would caution anyone who expects to use a timer to deploy to have some method of testing it during your first couple matches to insure that they’ve corrected the problem.
I’m also sure in your many years of FRC you’ve seen the robots get stuck for a few seconds longer than usual after autonomous. It’s things like this that worry me when designing a timer. We have no idea what’s the cause of pauses like this and what may be happening.
If you start the timer in the wrong place, it may be running during that same pause…
ie the same reason you get a head start to initialize your camera could break your timer because yes it uses the same length of a second, but it may not start with the FMS. I’ve seen all sorts of weird things happen on the official field that I never saw in testing.
All cautionary tales assimilated, gents! Thanks!