[Jared]

Originally Posted by GeeTwo

The most likely thing to cause this sort of behavior is if some piece of hardware (probably a sensor) other than the 'RIO needs a few hundred milliseconds to initialize. Once this initialization is done, the 'RIO initialization works.

Have you tried inspecting your 10MB data block to see what is different between a successful and a jerky startup?

Also you indicated that

If this data is only used for autonomous, and you can spare the half second, try moving this array generation to the beginning of autonomousInit() rather than robotInit().

We can't spare the time, as the generation has occasionally taken 1000+ ms to generate, and we need that time to back into the auto zone and drop the stack. However, I think I'll try having the generation happen a few seconds after the controller boots up instead.

Originally Posted by virtuald

If I were to guess at this problem without looking at your code, I would say it has something to do with how you're dealing with time. In particular, this sounds like a system that doesn't allow 'missed frames', and tries to catch up to where it wanted to be, so it keeps executing them until it's caught up.

After looking at it, I noticed that your Updater thing uses a Timer.scheduleAtFixedRate, which looks like it might have a behavior similar to what I'm describing.

"If an execution is delayed for any reason (such as garbage collection or other background activity), two or more executions will occur in rapid succession to "catch up." In the long run, the frequency of execution will be exactly the reciprocal of the specified period (assuming the system clock underlying Object.wait(long) is accurate). As a consequence of the above, if the scheduled first time is in the past, then any "missed" executions will be scheduled for immediate "catch up" execution."

That sounds exactly like what's happening.

I agree that we're "missing/skipping frames". However, this happens even 20 minutes after robot startup. What is different about background tasks 20 minutes after a cold boot and 20 minutes after pressing the restart code or reset buttons?

Originally Posted by virtuald

After thinking some more, one thing that ties into this, is that the RoboRIO doesn't have a battery holding the system's time. So when your RoboRIO starts up it thinks the time is... some time in the past. Maybe an hour, maybe a day, who knows.

However, when the DS connects to your roboRIO, the time is synchronized to the DS's time. So time all of a sudden goes from 0 to 1 billion something.

If your code started before the DS synchronized time, then the fixed time delay mechanism would kick in and try to 'catch up'.

There's a few ways to fix this. One way that pops into my head is only start your updater thing upon the robot being enabled for something. Other solutions involve basing the time delay on something that isn't tied to the robot's datetime... I'm sure there's a source somewhere.

I think you're right. The other code that I used timer.scheduleAtFixedRate() for won't have any issues with running too fast, but the autonomous driving stuff relies on that timing being spot on. The way updater works now is it starts the timer tasks on robot startup, which is unnecessary. We could likely have the updater not call timer.scheduleAtFixedRate() until the first updatable is passed to it, which would be as autonomous mode starts.

Originally Posted by MrRoboSteve

virtuald makes good points. You could log the actual execution time and easily see whether that is happening.

Has anyone documented the GC settings on the roboRIO? I've wondered, but we're a C++ team and a bit busy right now to go figure it out. -XX:MaxGCPauseMillis would be really useful.

I'd move the autonomous selection logic from disabledPeriodic to autonomousInit().

Can you do your profile generation earlier (e.g., via an instance initializer) and see if that helps?

It looks like you know the size of the list of Elements wrapped by Profile in advance. Consider modifying Profile's constructor to receive an initial capacity, and use that to set the size of the ArrayList<Element>. This will help your perf.

We could figure out the size of the arraylist right now, but if we needed to change the auto mode to avoid colliding with other robots, the length of the list would change. We don't have a spare roboRIO, and our current one is in the bag, so I won't have be able to test any of my changes for a few weeks.

Thanks to everybody for the great advice- I'm really hoping we can fix this.