Team 3620 2015 code release and white paper

[fovea1959]

FRC Team 3620, "The Average Joes", from St. Joseph High School in St. Joseph, Michigan, is releasing their 2015 Java code. The code is available on github: https://github.com/FRC3620/FRC3620_2015_AverageJava (http://www.chiefdelphi.com/media/papers/3189).

Most of the code is pretty typical FRC code (complete with warts). There are a few unusual things in there, though, that other teams may find useful:

event logging.
data logging.
UDP transmission of JSON encoded data to an onboard co-processor.
UDP reception of JSON encoded data from an onboard co-processor.
adding third party jars to the build.


We have posted a CD white paper (http://www.chiefdelphi.com/media/papers/3189) going into a little detail on those 5 items.

We hope that the logging and UDP stuff is helpful to someone else. Let me know if it is!

[Jaci]

Nice code, it seems your team programmers are far from inexperienced.

Interesting choice with the "No Logging until we've received the correct time from the Driver Station". I've been having this problem myself in the development of Toast (since everything is formatted with a datetime). It's such a shame the RoboRIO doesn't have an internal clock.

Well, at least I can say I have a time machine. Everything else in my room is in 2016 and the RoboRIO is stuck in 1970

[Joe Ross]

For 2016, the wpilib ant files are being updated to allow inclusion of additional libraries, so you'll only need to define a variable in the project build.properties.

We logged all the time. When our code detected there was a jump in time, we would rename the log file, but not do anything about each individual timestamp in the file.

[fovea1959]

Joe: how were you timestamping? If the clock shifted, could you tell the amount of elapsed time between log entries on either side of the clock stutter?

[Joe Ross]

Joe: how were you timestamping? If the clock shifted, could you tell the amount of elapsed time between log entries on either side of the clock stutter?

We did it really simplistically and converted System.getTimeinMillis to dates, and looked for a jump from before 2015 to 2015 or greater. This worked since the default was 1970.

[fovea1959]

...so you could tell that the time shifted, but you can't tell the elapsed time between events on either side of the timeshift?