Quote:
Originally Posted by apalrd
Why wait until Auton or Teleop functions are called?
Why don't you just run your code all the time, and then additionally run auton or teleop code based on the driver station data?
|
I take it you are talking about the idea of waiting for auton and telop to start listening. Network tables does like what you say "run your code all the time" so that any c++ programmer can use it without having to know anything about writing a new thread (i.e. task). I agree that this is the best way because it can still work while robot is disabled, and handles 2 way communication.
But let's go back for a moment... when I first did UDP and waited for Auton and Teleop before I knew about this bug. Why did I do it then? Because writing threads is a messy business, and should be avoided if at all possible. I mean look at the trouble that happened with the lockup bug in Network Tables... Using winsock2 I was able to listen to packets on the same thread and it was nice and clean code to work out. So given that... all of our code runs on a single thread... we don't use the PID that comes with WPI... it does not need to be on a separate thread. Instead we introduce a time-slice delta in seconds to the computations... this way the PID can work in 10ms (ish) iterations on the same thead rather than the default 50 on a separate thread... thus being free from any mess of critical sections!