FRC 2012 Beta (Team 1718's First Observations)

[Pi Fighter]

NOTE: This is also posted at http://forums.usfirst.org/showthread.php?t=18078.

Today, Team 1718 received and installed the FRC 2012 Beta version of LabVIEW. Since all of this is still in beta, don't expect the software to be the same at Kickoff.
First, installation is pretty much the same. There are no major differences between the installation from last year to this year.
Since we spent the day installing the software, we didn't have much time to dig around. Luckily, we didn't have to dig very far to see some changes.

The FRC 2012 cRIO Imaging tool is very different. Now, for both the cRIO II and the original cRIO, the modules are assigned slot positions. If a module is not in its assigned spot, it won't work. Also, the cRIO II is missing the physical cRIO switches (SAFE MODE, CONSOLE OUT, IP RESET, NO APP, NO FPGA), so instead they can be used through the Imaging tool.

The Driver Station also has had some changes. Teams no longer need a stop button for the driver station, and the driver station no longer has the option to bypass it. Even without a stop button, you can drive your robot.
The camera screen is split into two interchangeable tabs; one for the normal camera, and one to measure what values the Kinect is receiving from the driver.
Finally, there is a new tab (called #) that graphs packet loss, robot voltage, and driver station CPU %. It also graphs Trip Time, but as of right now I'm unsure what that is.

By Tuesday I'll post more information on LabVIEW, the cRIO Imaging Tool, and the Driver Station.

[linuxboy]

I really like the new # tab on the driver station as it allows you to see some of the more nitty gritty technical details. The trip time and lost packets are measurements similar to that you would receive from the output of a ping command.

Trip Time is the time it takes for a packet to go from the Driver Station to the Robot and is measured in milliseconds. Lower is better when it comes to trip time, also known as latency. Having a high latency is the cause for lag, so if the robot is lagging in response to the driver station this would be a good place to check. The normal latency at competitions is on the order of a few ms.

For anyone that doesn't know packet loss is it is how many packets don't make it to the robot. The Driver Station doesn't send them again because by the time it knows it didn't make it, it is no longer useful.

[~Cory~]

Can you post some screen shots? Or is that against the beta policy?

[Tom Line]

Cory, we'll have a slew of screenshots by this Tuesday, and perhaps sooner. Unfortunately we ran out of time, but Trevor (the face behind pi fighter) took the driver station home to play with it and get some screenies.

[linuxboy]

Attached is a screenshot of the # tab on the Driver Station. As you can see the ping times are pretty low. They (and the dropped packets) increase with increased CPU usage on the Driver Station.

[~Cory~]

This is going to help soooooooo much. Every year we end up with some kind of network problem and having real time data during matches will...

[apalrd]

FYI, the data (except CPU load) - Packet time, packet loss, and robot voltage have all been available on the FMS end for a while (there's a screen dedicated to these three numbers for the 6 robots on the field, it usually runs on its own monitor on the field). The FTA should be able to see if you had an issue in a match due to battery voltage or packet loss.

This was very helpful this year when we were having minibot issues, which we eventually tied to battery voltage.

That said, I'm happy to be able to see it from this end.

[Pi Fighter]

NOTE: This is also posted at http://forums.usfirst.org/showthread.php?p=52798.

After toying around with Kinect and the Driver Station, I do have some screenshots of the new Driver Station and cRIO Imaging Tool. One big observation with the Dashboard is that it now has a Kinect Skeleton tab, along with the normal camera tab. In the Kinect Skeleton tab, you are seeing the movement that the Kinect is picking up. However, I've noticed that it takes around 22 seconds to update the position of the skeleton (a.k.a. the player). This could be because of my computer (AMD E-350 Processor 1.6 GHz, 3GB RAM), though. I also noticed that my CPU% was in the 60's while I was doing these tests, yet the CPU% graph on the Driver Station never updated.

*I cannot post the Driver Station pictures (10KB too much), but they are available at http://forums.usfirst.org/showthread.php?p=52798.

[linuxboy]

Originally Posted by apalrd

FYI, the data (except CPU load) - Packet time, packet loss, and robot voltage have all been available on the FMS end for a while (there's a screen dedicated to these three numbers for the 6 robots on the field, it usually runs on its own monitor on the field). The FTA should be able to see if you had an issue in a match due to battery voltage or packet loss.

This was very helpful this year when we were having minibot issues, which we eventually tied to battery voltage.

That said, I'm happy to be able to see it from this end.

The other nice thing about this is having a graph means being able to see history of voltage and trip time, something the Field Monitor can't do (or at least couldn't this year), and since the FTA tends to be busy during matches they may not notice everything that happens to a particular robot.

[~Cory~]

That is a sexy firmware updater. Do you have to reload the entire system when changing the switches?

[jhersh]

Originally Posted by ~Cory~

That is a sexy firmware updater. Do you have to reload the entire system when changing the switches?

No