Quote:
Originally Posted by slibert
Typically, in a field-oriented drive (or auto-rotate-to-zero) application, the robot's drive train Z-axis rotation is impacted by gyro data; in other words, a gyro anomaly should impact only rotational motion. So while unexpected turning (e.g., spinning in circles) could point to a gyro issue, a robot that unexpectedly "jumps" and "moves" may be a sign of other control-path issues (Joystick->DriverStation->Network->RoboRio).
Please send along any information you can, it's not clear what's different about robots that are FMS-connected, other than the communication path between the Driver Station and the Robot software. The on-field log data for lost packets between DS and RoboRio, CPU time and communication latency might provide valuable info that might help other teams.
|
This thread is tracking an issue with Timers in Java acting differently immediately after a cold boot vs. after a warm boot. It's not directly FMS related, but it's something. The issue seems to be related to the Java Timer class depending on the RoboRIO system datetime, and the datetime initializing to 1970-something on cold start, and getting sync'd to the DS datetime on connection. The problem might just seem related to FMS connection because teams are using a different workflow during match vs. in the pit or practicing.
Also note the post in that thread about SmartDashboard logging buffering during long delays on the field and bogging things down after connection to the robot. There's definitely differences in the order and timing of control system events on the field vs. in the pits.