Re: Hot Goal Timing Issues
 

At Dallas I never noticed a problem

At Oklahoma there was no problem with the hot goals, however apparently the FMS was failing to send timing packets and would randomly ruin a robot's awesome autonomous for no problem of their own.

Re: Hot Goal Timing Issues
 

Can you/someone elaborate on this? (Preferably in lay-speak/non-programmer speak)

Re: Hot Goal Timing Issues
 

This means the FMS forgot to follow the game rule (5 seconds per goal, "randomly" light up one goal for first 5 seconds and the other goal after the first 5 seconds) and turned on the hot goal lights and the reflecting tape little too late or little too early. Off recent I am not following the auto-on period, Week 1 Michigan had seen, not 5 bonus points are trivial compared to 50 fould points to worry about.

Re: Hot Goal Timing Issues
 

At Waterford there still appeared to be some delays, but I would have to go back and look at match video to be 100% sure.

We had to continue to increase our hot goal detection delay in our software before we started consistently detecting the hot goal. We were 100% accurate in detecting the hot goal after we bumped up our delay to 1.2 seconds. (The delay you need may be different due to latency within your software due to image processing and communication. We use the lowest camera resolution at 20 FPS. Our image processing is done at the driver station and the hot goal status is then transmitted to the robot over UDP.)

Re: Hot Goal Timing Issues
 

I am by no means a programmer and don't know exactly how it works. This is the way I understand it

You can choose to program your robot to operate its autonomous based on the FMS clock. (Ie: wait for hot goal detector to indicate hot or if it fails just simply shoot at second 9). Instead of relying on your CRIO to keep an active clock it bases its time delays on official markers (timing packets) sent by the FMS.
Apparently it was messing up, in the sense that it is supposed to send (in laymans terms)

Real clock | Packets sent
Second 0 | 10 seconds left
Second 1 | 9 seconds left
Second 2 | 8 seconds left
etc

But was sending instead (in an exaggerated case)
Real clock | Packets sent
Second 0 | 10 seconds left
Second 1 |
Second 2 | 9 seconds left
Second 3 | 8 seconds left
Second 4 |
Second 5 | 7 seconds left
Second 6 | 6 seconds left
Second 7 |
Second 8 | 5 seconds left
Second 9 | 4 seconds left

In this case, it never told the robot there was less than 4 seconds left (autonomous is killed at real time Second 10)

This problem may actually be the exact issue with the hot goals. I never noticed a problem with the hot goals, but I was never specifically watching.

If the hot goal lights are also relying on these packets to work (I cant imagine why they wouldn't be), it would not switch in the above case until second 7 had passed.

Our robot was initially programmed to rely on this system, but all day friday it would never ever shoot the auto ball. We thought it was mechanical problems etc but once we got whiff of this potential problem we (by we I mean the coders :P) changed the code to only operate on an on-board clock, and never had a problem again.

If it works differently than I think it does, please correct me, but this is how I have come to understand it.

Re: Hot Goal Timing Issues
 

If the FMS sends a time stamp, I am unaware of this. So Brian I do not know if your analysis is correct. But in OK City during autonomous the FMS was not sending messages at the normal rate. Practice mode on the DS worked properly. The FMS at Dallas worked properly. But the FMS in OK City would go silent for random amounts of time, often seemed like multiple seconds. The problem seemed to be only during autonomous.

We had to remove any dependencies on the FMS message rate and/or time of arrival to get our autonomous to work correctly. Whether or not any team would experience this depends much on how their autonomous code is structured. Ours is all custom-code and the effect was crippling. We went from hitting 90+% on Saturday in Dallas to not shooting in auto all weekend in OK City. We would run 10 perfect auto sequences on the practice field then go out for a game and some portion of the sequence would run but never all of it. 1296 did not discover this. If other teams at OK City had not figured it out, we still would not know what went wrong.

Re: Hot Goal Timing Issues
 

FMS does not send a time stamp.

Can you post a driver station log from a match where this occurred, as well as from practice mode?

I'm not sure what you mean by GMS, but the FMS talks only to the driver station, and the driver station speaks exclusively to the robot. This is described in the FMS white paper.

If the FMS is telling the DS to go to disabled, this would cause the DriverStation::GetMatchTime() method to reset each time. However, this would also be logged in the driver station log.

Re: Hot Goal Timing Issues
 

The light delay seems better, but not fixed: http://youtu.be/NYgLapDfBkQ?t=1m16s

It has been 5 weeks and this still isn't working correctly so I guess this is the final product we are buying. :(

Re: Hot Goal Timing Issues
 

Bummer. This is a pretty big issue for our 3 ball hot goal routine, since we need to see the vision target within the first .5 seconds to make a decision and have enough time to shoot all three balls. We're not cool enough to shoot all three in <5 seconds... ;)

FIRST is penalizing teams that push the envelope of excellence in auto this year. It's pretty disheartening to tell my kids that their auto modes won't work because FIRST couldn't follow their own game rules. Maybe week 6 will be the golden week, who knows!

Holding out hope.

-Mike

Re: Hot Goal Timing Issues
 

The DS computers are at the school and frankly I'm exhausted, no robot stuff for a few weeks.

I'm pretty sure you know that I used GMS instead of FMS. Perhaps there was something about our DS computer that was not relaying the messages in a timely manner. But it is the same computer we used in Dallas. And like I said, it was others teams that pointed this out. So we were not the only team experiencing the delays.

I didn't say anything about state changes. They seem to work properly and happen at the correct temporal offsets from the start of the match.

We have never used this method. It is the relative time of arrival of the periodic messages from the FMS that hurt our auto code.

Re: Hot Goal Timing Issues
 

At this point, this is the first I've heard of anyone at Oklahoma, or any other event with this type of problem, so I'm poking at the only lead I have. Which of the event volunteers were aware of the problem?
Can you explain exactly what you were measuring, and how you were using it?

Re: Hot Goal Timing Issues
 

I saw a few like this at Hartford. Even on the ones that appear consistent, there's still variation. Our robot activates the solenoid to fire our shooter (which takes a second to fire) at exactly four seconds after autonomous starts. Timing this at home, the ball always entered the goal in the last half of autonomous mode. At competition, the ball sometimes make it in before the goals changed, and sometimes make it in after the goals changed.

I'm not sure why this seems to be such a difficult problem for FIRST. I was told at Hartford that the issue is because the lights aren't responsive enough and can only update once a second, and that the timing variation isn't the field's fault, but the crazy light show they put on during alliance selections seems to prove otherwise. I think the problem is with the FMS sending the data at the right time. There was also a five second delay between assists being counted on the video display with the green dots and the field LEDS being updated, and several times, the match timer stopped working. There were also issues of the pedestal light not lighting the entire match, even though the referees had ended the cycle.

Re: Hot Goal Timing Issues
 

Shooting 3 in 5 seconds doesn't help when the second goal is only hot for 4 seconds.

Re: Hot Goal Timing Issues
 

Truth. Ouch. You guys got hit the hardest by this. Saw you running two hot at Waterloo Elims. We may have to do the same.

Re: Hot Goal Timing Issues
 

I also saw the delay at Waterford, but like at Midland last week, our one ball hot detect worked with a 1 second delay from the start of auto. We only used the 1 ball hot detect twice at Waterford, so there is not many samples. The 2 ball auto does not use hot detect, as we can't load and shoot in under 2.5 seconds.