There has been long threads about static build-up in robots, specifically in FTC and VEX I see many references.

I was wondering if anyone knew of ways to monitor the static buildup that might be occurring within a robot and somehow track that over time (such as writing to a txt file on the NXT).

I am trying to determine if it is a real issue and learn more, and try to develop a method to monitor it.

On a related note I noticed a reply in a VEX thread that v3.6 includes a watchdog timer to possibly reset program lockups that have been historically attributed to static buildup. Any information about this?

This would be tricky to do without external sensors. The reason for this is that the static builds up as the robot is moving around the field, then gets released in on electrostatic discharge (ESD) 'burst' when the robot grounds itself (see Jpearman's thread on the subject on the VEX forums for more information). The problem is that there is currently no way to detect the static build up via a program because the build up occurs on the 'outside' of the robot and gets shorted through the Integrated Motor Encoder's (IME) I2C port, which can cause a CPU lockup on the microcontroller, none of which can be fully prevented with software (again, Jpearman's thread goes over this in great detail and is a very good reference source for this).

The watchdog timer that was implemented in 3.6 helps alleviate the issues robots were having with motor power levels when an ESD through the IME's I2C ports caused a CPU crash, but it's unable to prevent the ESD from happening in the first place.

As far as prevention goes, the simplest and easiest way to avoid the ESD problems is to switch to the quadrature encoders for the time being since they do not utilize the I2C ports and thus will not cause the same issues. Rest assured, VEX is aware of the issue and is working hard on a solution.

My intent is not to prevent it with software, but rather to attempt to track it and quantify it.
(also build a learning experience for the students around it)

I thought I would ask before breaking off into an area that I have no expertise in.
I will take a look a the link and scrape what I think I can apply.

I am pleased that VEX is working on it, but with the NXT I really don't see much. Most all the discussion seems to be VEX oriented.
Nor, if there is anyone attempting to mitigate or protect the I2C port (the actual vector).